Created attachment 645118 [details] build.log /tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/config/i386/i386-expand.c:7898:7: note: 'vec[1]' was declared here 7898 | rtx vec[3]; | ^ /tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/config/i386/i386-expand.c: In function 'ix86_expand_call': /tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/emit-rtl.c:1090:1: warning: 'vec[1]' may be used uninitialized in this function [-Wmaybe-uninitialized] 1090 | rt_val->elem[i] = *argp++; | ^ /tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/config/i386/i386-expand.c:7898:7: note: 'vec[1]' was declared here 7898 | rtx vec[3]; | ^ during RTL pass: loop2_done /tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/tree-ssa-reassoc.c: In function 'remove_visited_stmt_chain': /tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/tree-ssa-reassoc.c:4754:1: internal compiler error: Segmentation fault 4754 | } | ^ 0x7f91b49557df ??? /tmp/portage/sys-libs/glibc-2.31-r5/work/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions. make[4]: *** [/tmp/portage/sys-devel/gcc-10.1.0-r1/temp/ccvsgKx0.mk:176: /tmp/portage/sys-devel/gcc-10.1.0-r1/temp/cc1.fi4uN2.ltrans58.ltrans.o] Error 1 lto-wrapper: fatal error: make returned 2 exit status compilation terminated. /usr/x86_64-pc-linux-gnu/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status make[3]: *** [/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/c/Make-lang.in:85: cc1] Error 1 See attached build.log
Created attachment 645120 [details] emerge --info
Any chance it sould be a resource (RAM / disk) exhaustion? Does 'dmesg' report any OOMs? I think 'during RTL pass: loop2_done' implies it's an internal gcc memory corruption. Can you reliably reproduce the failure if you build with MAKEOPTS=-j1? We'll need to narrow down set of special options. Some examples: - USE=-lto - USE=-pgo - -march=native -> -march=${cpu} - lg.gold -> ld.lfd Also, to get a better backtrace try to add '-g' to CFLAGS and CXXFLAGS and get a gdb backtrace. Should be a matter of: $ file path/to/core $ gdb path/to/file path/to/core $ bt
Created attachment 645188 [details] build.log -j4, now with gcc-10.1.0-r1 (In reply to Sergei Trofimovich from comment #2) > Any chance it sould be a resource (RAM / disk) exhaustion? Does 'dmesg' > report any OOMs? No, I'm doubtful this is the case as I have plenty of free RAM (even while compiling in tmpfs). > Can you reliably reproduce the failure if you build with MAKEOPTS=-j1? emerging was successful with -j1. Switching back to -j4 (now with the -r1 compiler) produces a similar ICE. Based on log size, it seems to happen earlier in the process now, although I've yet to rebuild with the same configuration twice to see if it happens in a predictable place every time. > We'll need to narrow down set of special options. Now rebuilding with USE='-lto -pgo' and -j4.
Created attachment 645198 [details] build.log Disabled many USE flags in an attempt at minimization: [ebuild R ] sys-devel/gcc-10.1.0-r1 USE="(cxx) fortran lto (multilib) nptl openmp (pie) ssp vtv zstd (-ada) -d -debug -doc (-fixed-point) -go -graphite* (-hardened) (-jit) (-libssp) -nls -objc -objc++ -objc-gc -pch* -pgo* -sanitize* -systemtap -test -vanilla"
Created attachment 645274 [details] build.log without -pipe This build was the same as above, without -pipe now.
I attempted to reproduce the crash on skylake machine and did not succeed with either all of your MAKEOPTS/CFLAGS/CXXFLAGS/LDFLAGS/USE flags or -march=native changed to march=skylake. That might suggest it's a race in build system or a tricky hardware problem. You might want to start a fresh stage3 chroot and gradually add flags there to see what adds to the trigger. So far you still have too many unique CFLAGS and packages form overlays.
