| View previous topic :: View next topic |
| Author |
Message |
mich
Tux's lil' helper
Joined: 29 Sep 2007
Posts: 116
|
 Posted: Fri May 10, 2024 7:18 pm Post subject: sys-devel/llvm-17.0.6 failed (SOLVED-CLOSED) |
 |
|
Hello,
Need help please.
Here the files:
https://file.io/FzKemxEOKYER
Thanks in advance,
Michel
Last edited by mich on Sat May 18, 2024 6:15 am; edited 1 time in total |
|
| Back to top |
|
 |
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 30993
Location: here
|
| Posted: Sat May 11, 2024 5:51 am Post subject: |
|
|
I can't open link.
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
mich
Tux's lil' helper
Joined: 29 Sep 2007
Posts: 116
|
|
| Back to top |
|
|
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 30993
Location: here
|
| Posted: Sat May 11, 2024 6:39 am Post subject: |
|
|
| Code: | /usr/lib/gcc/i686-pc-linux-gnu/13/include/g++-v13/bits/move.h: In instantiation of ‘constexpr typena
me std::remove_reference<_Tp>::type&& std::move(_Tp&&) [with _Tp = llvm::SmallVector<llvm::MachineFu
nction::ArgRegPair, 1>&; typename remove_reference<_Tp>::type = llvm::SmallVector<llvm::MachineFunct
ion::ArgRegPair, 1>]’:
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/include/llvm/ADT/SmallVector.h:1252:48: required
from ‘llvm::SmallVector<T, N>::SmallVector(llvm::SmallVector<T, N>&&) [with T = llvm::MachineFunctio
n::ArgRegPair; unsigned int N = 1]’
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/include/llvm/CodeGen/SelectionDAG.h:2296:73: requ
ired from here
/usr/lib/gcc/i686-pc-linux-gnu/13/include/g++-v13/bits/move.h:98:77: internal compiler error: Segmentation fault
98 | { return static_cast<typename std::remove_reference<_Tp>::type&&>(__t); }
| ^
0x99450a7 internal_error(char const*, ...)
???:0
0x8562af8 ggc_set_mark(void const*)
???:0
0x84b9ee0 gt_ggc_mx(spec_entry*&)
???:0
0x8452462 gt_ggc_mx_hash_table_spec_hasher_(void*)
???:0
0x872aa9c ggc_mark_roots()
???:0
0x856335f ggc_collect(ggc_collect)
???:0
0x85e4e69 cgraph_node::finalize_function(tree_node*, bool)
???:0
0x849d17f expand_or_defer_fn(tree_node*)
???:0
0x846caab instantiate_decl(tree_node*, bool, bool)
???:0
0x8487d2c instantiate_pending_templates(int)
???:0
0x83829d7 c_parse_final_cleanups()
???:0
0x8537ae5 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions. |
Usually an “internal compiler error: Segmentation fault” is caused by a hardware problem. Try checking the dmesg.
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
mich
Tux's lil' helper
Joined: 29 Sep 2007
Posts: 116
|
| Posted: Sun May 12, 2024 7:45 am Post subject: |
|
|
| fedeliallalinea wrote: | | Code: | /usr/lib/gcc/i686-pc-linux-gnu/13/include/g++-v13/bits/move.h: In instantiation of ‘constexpr typena
me std::remove_reference<_Tp>::type&& std::move(_Tp&&) [with _Tp = llvm::SmallVector<llvm::MachineFu
nction::ArgRegPair, 1>&; typename remove_reference<_Tp>::type = llvm::SmallVector<llvm::MachineFunct
ion::ArgRegPair, 1>]’:
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/include/llvm/ADT/SmallVector.h:1252:48: required
from ‘llvm::SmallVector<T, N>::SmallVector(llvm::SmallVector<T, N>&&) [with T = llvm::MachineFunctio
n::ArgRegPair; unsigned int N = 1]’
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/include/llvm/CodeGen/SelectionDAG.h:2296:73: requ
ired from here
/usr/lib/gcc/i686-pc-linux-gnu/13/include/g++-v13/bits/move.h:98:77: internal compiler error: Segmentation fault
98 | { return static_cast<typename std::remove_reference<_Tp>::type&&>(__t); }
| ^
0x99450a7 internal_error(char const*, ...)
???:0
0x8562af8 ggc_set_mark(void const*)
???:0
0x84b9ee0 gt_ggc_mx(spec_entry*&)
???:0
0x8452462 gt_ggc_mx_hash_table_spec_hasher_(void*)
???:0
0x872aa9c ggc_mark_roots()
???:0
0x856335f ggc_collect(ggc_collect)
???:0
0x85e4e69 cgraph_node::finalize_function(tree_node*, bool)
???:0
0x849d17f expand_or_defer_fn(tree_node*)
???:0
0x846caab instantiate_decl(tree_node*, bool, bool)
???:0
0x8487d2c instantiate_pending_templates(int)
???:0
0x83829d7 c_parse_final_cleanups()
???:0
0x8537ae5 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions. |
Usually an “internal compiler error: Segmentation fault” is caused by a hardware problem. Try checking the dmesg. |
Hello,
I checked dmesg but notthing at all. I know that "segmentation fault" occur when a program tries to access memory that is not authorized to access, or that does not exist. So i think is not hardware problem but the way the compiler is doing it's job.
For the story recently I did an upgrade of my profile and all the problem is coming from that. Now I am doing "emerge -a --emptytree @world".
Hope this solve the problem. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21773
|
| Posted: Sun May 12, 2024 3:11 pm Post subject: |
|
|
| Software only works correctly when the hardware does as it is told. If the software tries to read from 0x400000, and due to a hardware error, the read is dispatched to 0x80000000400000, you will get a segmentation fault, despite that the program was correct as written. That is why we suggest validating hardware when a non-reproducible segmentation fault is reported. |
|
| Back to top |
|
|
mich
Tux's lil' helper
Joined: 29 Sep 2007
Posts: 116
|
| Posted: Wed May 15, 2024 9:47 am Post subject: |
|
|
| Hu wrote: | | Software only works correctly when the hardware does as it is told. If the software tries to read from 0x400000, and due to a hardware error, the read is dispatched to 0x80000000400000, you will get a segmentation fault, despite that the program was correct as written. That is why we suggest validating hardware when a non-reproducible segmentation fault is reported. |
Hello Hu,
Thanks for the answer. As I stated before I don't see hardware problem. But what I did is remerge gcc and after that the emerge of llvm-17.0.6 worked!
As emerge --empytree @world continue it's job, clang-17.0.6 failed. So i did the same manipulation and now it seems clang emerge is doing well.
After clang finished I'll continue with the last packages to emerge with my new profile. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 1697
|
| Posted: Wed May 15, 2024 2:06 pm Post subject: |
|
|
| An ICE in the garbage collection functions means it's a memory issue. Please do a memtest. |
|
| Back to top |
|
|
mich
Tux's lil' helper
Joined: 29 Sep 2007
Posts: 116
|
| Posted: Thu May 16, 2024 7:58 am Post subject: |
|
|
| sam_ wrote: | | An ICE in the garbage collection functions means it's a memory issue. Please do a memtest. |
Hello Sam,
Actually the emerge --emptytree @world against my new profile finished well.
I think that sometimes when the compiler is working long time I have this problem.
The problem of compilation is solved.
Now I'll try memtest. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21773
|
| Posted: Thu May 16, 2024 2:15 pm Post subject: |
|
|
Intermittent failures after extended use usually indicates that the system has inadequate cooling, and that keeping the CPU under constant load compiling a large package pushes the temperature up so high that the hardware behaves incorrectly. Most modern systems try to counter this by throttling down, or in extreme cases even halting. However, there may be cases when that does not happen soon enough.
If overheating is your problem, memtest will likely come back clean. What was the ambient temperature and CPU temperature when these random failures were occurring? |
|
| Back to top |
|
|
mich
Tux's lil' helper
Joined: 29 Sep 2007
Posts: 116
|
| Posted: Thu May 16, 2024 2:58 pm Post subject: |
|
|
| Hu wrote: | Intermittent failures after extended use usually indicates that the system has inadequate cooling, and that keeping the CPU under constant load compiling a large package pushes the temperature up so high that the hardware behaves incorrectly. Most modern systems try to counter this by throttling down, or in extreme cases even halting. However, there may be cases when that does not happen soon enough.
If overheating is your problem, memtest will likely come back clean. What was the ambient temperature and CPU temperature when these random failures were occurring? |
Is an old laptop with pentium (Lenovo G550), I wanted to give it a use instead of throw it:) |
|
| Back to top |
|
|
mich
Tux's lil' helper
Joined: 29 Sep 2007
Posts: 116
|
| Posted: Sat May 18, 2024 6:15 am Post subject: |
|
|
| Hu wrote: | Intermittent failures after extended use usually indicates that the system has inadequate cooling, and that keeping the CPU under constant load compiling a large package pushes the temperature up so high that the hardware behaves incorrectly. Most modern systems try to counter this by throttling down, or in extreme cases even halting. However, there may be cases when that does not happen soon enough.
If overheating is your problem, memtest will likely come back clean. What was the ambient temperature and CPU temperature when these random failures were occurring? |
Hello Hu,
Yesterday I tried memtest and saw "status" failed, in a lot of address was not good, but the temperature was at 70 degrees, I think is high.
Anyway, as is an old laptop that I give one more live, when the compile is long and fail I'll stop the machine and redo again the compile after some time and is good as I did with firefox.
I close the ticket.
Thanks everybody for your help. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21773
|
| Posted: Sat May 18, 2024 1:19 pm Post subject: |
|
|
| If the RAM is returning incorrect values under memtest, then I think you have more serious problems than mere overheating. You may notice the problems more when under heavy load, but if RAM intermittently returns invalid values, then any compilation you do on that machine is suspect, and any program may crash any time it depends on a value loaded from a bad RAM address. If you want to continue using this, I think you need to find all the broken addresses and instruct the kernel not to use them. This is typically done through the kernel command line with memmap=. After that, restore from a known good source anything that was created using bad RAM, as the result from the bad RAM may be corrupt. |
|
| Back to top |
|
|
|
Portage & Programming
