https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117952
Bug ID: 117952
Summary: host_detect_local_cpu returns NULL when built with
Clang
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
CC: uros at gcc dot gnu.org
Target Milestone: ---
Originally reported downstream in Gentoo at https://bugs.gentoo.org/933772.
We had reports of some people trying to build GCC with Clang where they have
-fcf-protection=full in *FLAGS (or GCC is patched to do that by default) but
failing with 'cc1: error: -fcf-protection is not compatible with this target'
once stage1 was just-built and starting to be used for target libraries.
The issue is -march=native resolves to nothing if building
config/i386/driver-i386.c with Clang.
Quoting myself from https://bugs.gentoo.org/933772#c24:
"""
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+ydrbvkcq9gp5...@mail.gmail.com/
*
https://inbox.sourceware.org/gcc-patches/CAFULd4Ze8=y5vb7oqcovhzfpu8b9ny4ka1jxmt4hmosuzoq...@mail.gmail.com/
"""
On our end, the easy workaround is to pass -fcf-protection=none for stage1 when
building with Clang.
On the GCC side, I don't know whether the condition there is intentionally
excluding Clang or if it's accidental. Uros?
