Hello, I tried to update the the recent revision sys-devel/gcc-11.1.0-r2 and the compiler seems to get an internal error. It is a PGO+LTO build. Interestingly enough, the compiler does not ICE at the same file when the compilation is done with -j32 or -j1
Created attachment 722968 [details] emerge info
Created attachment 722971 [details] emerge pqv
Created attachment 722974 [details] Build log with -j32
Created attachment 722977 [details] Build log with -j1
If you do a few -j1 builds, do the crash the same?
Posting a few unutual things: > CFLAGS="-O3 -march=native -pipe" > [ebuild U ] sys-devel/gcc-11.1.0-r2 [11.1.0-r1] USE="... lto ... pgo ..." """ | ^ during RTL pass: reload options.c: In function ‘cl_enum_evrp_mode_set’: options.c:312: internal compiler error: Segmentation fault 312 | cl_enum_evrp_mode_set (void *var, int value) | """
I will try again with another -j1, the crash happens several hours after the emerge process starts, I will report back as soon as I get the ICE.
(In reply to Sergei Trofimovich from comment #6) > Posting a few unutual things: > > > CFLAGS="-O3 -march=native -pipe" > > [ebuild U ] sys-devel/gcc-11.1.0-r2 [11.1.0-r1] USE="... lto ... pgo ..." I failed to reproduce locally :( I believe I have access to the same CPU as your's: System uname: Linux-5.13.0-11856-g55e748397e9a-x86_64-AMD_Ryzen_9_5950X_16-Core_Processor-with-glibc2.33 That might be either a sign of very elusive bug: - in userspace (unlikely elusive as you are able to consistently hit it) - in kernel (might be?) - in hardware USE='lto' and USE='pgo' are heavyweight flags that "allow" you to generate effectively unique binaries for your system. Would be nice to narrow down to smaller set of changes from default stage3 to get to that broken state. I suggest a few things: 1. Try vanilla kernel (maybe, gentoo-sources; ideally built on non-O3 system) 2. Try sys-apps/memtest86+ and make sure RAM is not outright broken 3. Try disabling USE='lto' (might require 2 gcc rebuilds) 4. Try disabling USE='pgo' 5. Add -ggdb to CFLAGS/CXXFLAGS. That should make gcc crashes more informative. Might not yield too much information to narrow it down precisely. But worth a try.
My second -j1 build is still ongoing... Thank you for your suggestions! - I went through 4 passes of memtest86+ few days ago, and it successfully passed them, I will retry because I am aware that sometimes things just randomly change. - The last times I tried to compile GCC my CPU was actually dropping to 0.5Ghz all core because of PBO and a motherboard with poor VRM, I had to disable it. Maybe that actually broke something in the motherboard, I will be receiving a new motherboard tomorrow and I will retry with it. Maybe my CPU is actually erroring out. - I will actually save my current GCC-11.1.0-r1 in a binpkg and will try to rebuild that same version. To see if it still works, if it doesn't then that may point towards hardware error. I will rebuild glibc with -O2 because I have it built with USE=custom-cflags. - I will build a standard kernel with an archlinux config to see, too.
> ideally built on non-O3 system Isn't the compiler entirely bootstrapped from what's in the system ? I have seen it rebuilt itself with the past version of itself during the emerge.
(In reply to Adel KARA SLIMANE from comment #10) > > ideally built on non-O3 system > > Isn't the compiler entirely bootstrapped from what's in the system ? I have > seen it rebuilt itself with the past version of itself during the emerge. Oh, I only meant to build a kernel by a compiler that was built with -O2 itself to avoid use of potentially broken compiler (it crashes on us after all).
Created attachment 723022 [details] Second -j1 build Alright, here's the second -j1 build. It ICEs at a different file. ``` /var/tmp/portage/sys-devel/gcc-11.1.0-r2/work/gcc-11.1.0/gcc/profile-count.h: In member function ‘profile_count profile_count::apply_probability(int) const’: /var/tmp/portage/sys-devel/gcc-11.1.0-r2/work/gcc-11.1.0/gcc/profile-count.h:1046:26: internal compiler error: Aborted 1046 | if (!initialized_p ()) | ~~~~~~~~~~~~~~^~ ```
> Oh, I only meant to build a kernel by a compiler that was built with -O2 itself to avoid use of potentially broken compiler (it crashes on us after all). Alright! I will add building an -O2 kernel with gcc to the list of things I need to try (because I have that built too with -O3, clang and LTO... xD). I do not have USE=custom-cflags with GCC so it is already -O2 built as the -O3 flag gets stripped. > strip-flags: CFLAGS: changed '-O3 -march=native -pipe' to '-march=native -pipe -O2'
Okay, some new elements: - memtest86-efi for 35 minutes doesn't give any errors - I successfully built gcc-11.1.0-r1 again. So something changed between these two. - I will retry to emerge gcc-11.1.0-r2, maybe it will work this time, who knows.
After re-emerging gcc-11.1.0-r1 with the same usual flags (includes LTO and PGO), gcc-11.1.0-r2 successfully got built. I have no idea why this is the case... Thank you for your help and your time!