too long lines were shrinked: make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-14.1.1_p20240518/work/build/x86_64-pc-linux-gnu/libgcc' make[5]: Entering directory '/var/tmp/portage/sys-devel/gcc-14.1.1_p20240518/work/build/x86_64-pc-linux-gnu/32/libgcc' echo timestamp > libgcc_tm.stamp make[5]: Leaving directory '/var/tmp/portage/sys-devel/gcc-14.1.1_p20240518/work/build/x86_64-pc-linux-gnu/32/libgcc' make[5]: Entering directory '/var/tmp/portage/sys-devel/gcc-14.1.1_p20240518/work/build/x86_64-pc-linux-gnu/32/libgcc' /var/tmp/portage/sys-devel/gcc-14.1.1_p20240518/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-14.1.1_p20240518/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fno-che cc1: error: '-fcf-protection' is not compatible with this target make[5]: *** [/var/tmp/portage/sys-devel/gcc-14.1.1_p20240518/work/gcc-14-20240518/libgcc/shared-object.mk:36: avx_savms64_s.o] Error 1 make[5]: Leaving directory '/var/tmp/portage/sys-devel/gcc-14.1.1_p20240518/work/build/x86_64-pc-linux-gnu/32/libgcc' ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0_llvm-20240607-115521 UNMASKED: ~dev-libs/icu-75.1 ~dev-libs/icu-layoutex-75.1 The attached etc.portage.tar.xz has all details. ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-13 * clang/llvm (if any): clang version 18.1.6+libcxx Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/18/bin Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg /usr/lib/llvm/18 18.1.6+libcxx Python 3.12.3 Available Ruby profiles: (none found) php cli (if any): HEAD of ::gentoo commit 53e6779fb42ba449740b8aae94de19960bbb1d5b Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Fri Jun 7 18:28:18 2024 +0000 2024-06-07 18:28:17 UTC emerge -qpvO sys-devel/gcc [ebuild NS ] sys-devel/gcc-14.1.1_p20240518 [13.2.1_p20240210] USE="cet (cxx) debug* (default-stack-clash-protection) (default-znow) fortran (multilib) openmp (pie) sanitize ssp valgrind* -ada (-custom-cflags) -d -doc (-fixed-point) -go -graphite -hardened (-ieee-long-double) -jit (-libssp) -lto -modula2 -nls* -objc -objc++ -objc-gc (-pch) -pgo -rust% -systemtap -test -vanilla -vtv -zstd*"
Created attachment 895335 [details] emerge-info.txt
Created attachment 895336 [details] emerge-history.txt
Created attachment 895337 [details] environment
Created attachment 895338 [details] etc.clang.tar.xz
Created attachment 895339 [details] etc.portage.tar.xz
Created attachment 895340 [details] gcc-build-logs.tar.xz
Created attachment 895341 [details] logs.tar.xz
Created attachment 895342 [details] qlist-info.txt
Created attachment 895343 [details] sys-devel:gcc-14.1.1_p20240518:20240607-185945.log.xz
Created attachment 895344 [details] temp.tar.xz
*** Bug 934790 has been marked as a duplicate of this bug. ***
Happens when building with Clang.
Wasn't bug 928460 supposed to fix this?
Well apparently, it didn't
(In reply to zachariah.cabelly from comment #14) > Well apparently, it didn't It wasn't really a question to you, more a note to whoever is going to work on it...
(In reply to Sam James from comment #15) > (In reply to zachariah.cabelly from comment #14) > > Well apparently, it didn't > > It wasn't really a question to you, more a note to whoever is going to work > on it... Ok, I was making a joke, but to each their own
Forcing GCC on sys-devel/gcc in the meantime. That's the workaround I have.
Root cause: xgcc (bootstrapper) in 14.1.1 does not resolve `-march=native`, then in cc1 invocation there is no -march=..., due to `-m32` cc1 fallbacks to some ancient i386, which does not support stack-protection. This problem applies only to xgcc; final gcc-14 resolves `-march=native` fine. The issue occurs only with `sys-devel/gcc[hardened]`. Workaround in make.conf: replace `-march=native` with `-march=<whatever arch you use>`. Or remove `-march=native` (in that case xgcc adds `-march=x86-64` to cc1 which prevents fallback to i386). Minimal reproducer: /var/tmp/portage/sys-devel/gcc-14.1.1_p20240622/work/build/gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-14.1.1_p20240622/work/build/gcc/ -march=native -m32 -fcf-protection test.c -### 2>&1 | grep cc1 >>> .../cc1 ... test.c ... -m32 "-fcf-protection=full" ... It worked fine in gcc-13.2.1: /var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/gcc/ -march=native -m32 -fcf-protection test.c -### 2>&1 | grep cc1 >>> .../cc1 ... test.c "-march=znver4" -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -msse4a -mno-fma4 -mno-xop -mfma -mavx512f -mbmi -mbmi2 -maes -mpclmul -mavx512vl -mavx512bw -mavx512dq -mavx512cd -mno-avx512er -mno-avx512pf -mavx512vbmi -mavx512ifma -mno-avx5124vnniw -mno-avx5124fmaps -mavx512vpopcntdq -mavx512vbmi2 ... -m32 "-fcf-protection=full" ...
(In reply to Sv. Lockal from comment #18) > Root cause: xgcc (bootstrapper) in 14.1.1 does not resolve `-march=native`, > then in cc1 invocation there is no -march=..., due to `-m32` cc1 fallbacks > to some ancient i386, which does not support stack-protection. This problem > applies only to xgcc; final gcc-14 resolves `-march=native` fine. > Note that depending on the point in the process you're at, `xgcc` is sometimes just a wrapper around the original CC (e.g. clang). But if it worked with GCC 13, that's obviously far more curious...
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d6cb7a61dad7e9672a8448597835dbbf9b9e0ccf commit d6cb7a61dad7e9672a8448597835dbbf9b9e0ccf Author: Ian Jordan <immoloism@gmail.com> AuthorDate: 2024-11-12 18:32:15 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-11-12 19:18:51 +0000 toolchain.eclass: Disable CET on x86 Remove enable_cet_for 'i[34567]86' 'gnu' 'cet' from to prevent -fcf-protection on x86 systens where CET support will never be fully enabled anyway. This should help with bug #933772 also but I was unable to reproduce to confirm. Closes: https://bugs.gentoo.org/943332 Bug: https://bugs.gentoo.org/933772 Thanks-to: Sam James <sam@gentoo.org> Signed-off-by: Ian Jordan <immoloism@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> eclass/toolchain.eclass | 1 - 1 file changed, 1 deletion(-)
Build failed with clang with -fcf-protection error. I removed cet to remove that flag, it failed in comparison b/wn stage 2/3. I readded cet and changed -march=native to -march=rocketlake. I don't encounter the -fcf-protection error with -march=rocketlake. GCC built successfully by changing -march=native to -march=rocketlake with the cet use flag set!
*** Bug 932258 has been marked as a duplicate of this bug. ***
We discussed this a bit on IRC and amonakov pointed out it implies stage1 may be miscompiled by clang.
Comparing both: * /tmp/bisect-gcc-bld/./gcc/xgcc -B/tmp/bisect-gcc-bld/./gcc/ -B/tmp/bisect-gcc-pfx/x86_64-pc-linux-gnu/bin/ -B/tmp/bisect-gcc-pfx/x86_64-pc-linux-gnu/lib/../lib -B/tmp/bisect-gcc-pfx/x86_64-pc-linux-gnu/lib/ -isystem /tmp/bisect-gcc-pfx/x86_64-pc-linux-gnu/include -isystem /tmp/bisect-gcc-pfx/x86_64-pc-linux-gnu/sys-include -fno-checking -m32 -c -g -O2 -ggdb3 -march=native -fdiagnostics-color=always -fcf-protection=full /tmp/a.c -### and * /usr/bin/gcc -fno-checking -m32 -c -g -O2 -ggdb3 -march=native -fdiagnostics-color=always -fcf-protection=full /tmp/a.c -### we can see it's already broken when passing args to cc1. host_detect_local_cpu is where the magic happens and it: * returns null in the bad case * returns "-march=znver2 -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -msse4a -mno-fma4 -mno-xop -mfma -mno-avx512f -mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx51"... in the happy case Opening up the file: ``` const char *host_detect_local_cpu (int argc, const char **argv); #if defined(__GNUC__) && (__GNUC__ >= 5 || !defined(__PIC__)) [...] #else const char *host_detect_local_cpu (int, const char **) { return NULL; } #endif which changed in r5-4194-g021478683cc091. I think this unintentionally excludes Clang by not realising Clang still identifies as GCC 4.8 or whatever? I am not sure what the significance of GCC 5 is here though. I see: * https://inbox.sourceware.org/gcc-patches/CAFULd4Yt89-2SXfd3EAQMyfXfVFh_uz5at+yDRBvKCQ9gp5Mzw@mail.gmail.com/ * https://inbox.sourceware.org/gcc-patches/CAFULd4Ze8=Y5vB7oqcOvHZfpu8B9nY4kA1jXMT4hmOsuZoqrtQ@mail.gmail.com/
Reported upstream at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117952. I'll apply the obvious workaround in a minute.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ec6ccd63bb77770eeeb8eb220d66efafc91ac572 commit ec6ccd63bb77770eeeb8eb220d66efafc91ac572 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-12-07 23:21:14 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-12-07 23:21:14 +0000 toolchain.eclass: pass -fcf-protection=none for stage1 builds with Clang GCC's host_detect_local_cpu returns NULL when built with Clang (see bug for details) so pass -fcf-protection=none for stage1 (where it doesn't really matter anyway) to avoid a failure when -march=native ends up resolving to nothing (b/c NULL) and then erroring out as CET isn't supported for the baseline -m32 CPU. Bug: https://gcc.gnu.org/PR117952 Closes: https://bugs.gentoo.org/933772 Signed-off-by: Sam James <sam@gentoo.org> eclass/toolchain.eclass | 7 +++++++ 1 file changed, 7 insertions(+)
(In reply to Chase Phelps from comment #21) > I removed cet to remove that flag, it failed in comparison b/wn stage 2/3. Please file a new bug for the bootstrap comparison failure if you can still hit that.
My fix isn't quite right, it needs adjusting because -fcf-protection gets appended.
(if USE=cet)
commit f82ed28a4cbf188cac0d20175d7fea963a742e25 (HEAD -> master, origin/master, origin/HEAD) Author: Sam James <sam@gentoo.org> Date: Sat Dec 7 23:36:33 2024 +0000 toolchain.eclass: disable CET if stage 1 compiler is Clang and -march=native It's too much hassle to make this edge-case work for now (not really worth it given kind of niche, not like glibc even defaults to enforcement yet or even has a mechanism to set a default) and I've filed a bug upstream. The problem with my previous approach (even after then trying STAGE1_TFLAGS) is that w/ --enable-cet or bootstrap-cet at least, we end up adding -fcf-protection after our added -fcf-protection=none. This partly reverts commit ec6ccd63bb77770eeeb8eb220d66efafc91ac572. Signed-off-by: Sam James <sam@gentoo.org>
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=94cfc2abd5924cc71314e28fb9f26e147ed9659e commit 94cfc2abd5924cc71314e28fb9f26e147ed9659e Author: Sam James <sam@gentoo.org> AuthorDate: 2025-01-03 00:58:00 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-01-03 00:58:41 +0000 toolchain.eclass: move Clang CET hack earlier to influence tc_enable_hardened_gcc Otherwise, we may still set -DEXTRA_OPTIONS_CF. Bug: https://bugs.gentoo.org/933772 Signed-off-by: Sam James <sam@gentoo.org> eclass/toolchain.eclass | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dcaab8c1db8a33cfc110c1aecfef799b26be65ae commit dcaab8c1db8a33cfc110c1aecfef799b26be65ae Author: Sam James <sam@gentoo.org> AuthorDate: 2025-02-23 03:57:57 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-02-23 05:09:00 +0000 toolchain.eclass: strip -march=native when building with Clang -march=native doesn't work correctly in the stage2 compiler when the stage1 compiler is Clang (see PR117952 for details). We have two options until that is fixed: 1) strip -march=native, or 2) do 'bootstrap4' (which isn't super well-tested at the moment, see e.g. https://trofi.github.io/posts/301-another-gcc-profiling-bug.html) Choose 1). Thanks to immolo for testing. Bug: https://gcc.gnu.org/PR117952 Bug: https://bugs.gentoo.org/933772 Closes: https://bugs.gentoo.org/947752 Signed-off-by: Sam James <sam@gentoo.org> eclass/toolchain.eclass | 1 + 1 file changed, 1 insertion(+)