https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71777
--- Comment #1 from Peter Bergner <bergner at gcc dot gnu.org> ---
The documentation doesn't mention this (and I should probably add it), but the
__builtin_cpu_is() and __builtin_cpu_supports() builtins rely on support from
glibc (glibc 2.23 and later to be exact). If you build against an oldish glibc
(2.22 and earlier), the builtins will always return 0. You can verify whether
your gcc was built with a new enough glibc by looking at the assembly output of
a call to one of the builtins. For example:
bergner@genoa:~/gcc/BUGS/CPU_IS$ cat cpu.c
int
foo (void)
{
return __builtin_cpu_is ("power8");
}
bergner@genoa:~/gcc/BUGS/CPU_IS$
/home/bergner/gcc/build/gcc-fsf-mainline-debug-2/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-debug-2/gcc -O2 -S cpu.c
bergner@genoa:~/gcc/BUGS/CPU_IS$ cat cpu.s
...
foo:
li 3,0 <- No support from glibc.
blr
If your gcc/glibc both support the builtins, then you'd see a load off of r13
and some logical instructions on the result, like so:
foo:
lwz 3,-28764(13)
xori 3,3,0x2d
cntlzw 3,3
srwi 3,3,5
blr
Another check is to see whether the libc.a and/or ld.so export the symbol
__parse_hwcap_and_convert_at_platform. If it doesn't, then your glibc is too
old:
linux%: objdump -x /usr/lib/debug/lib/powerpc64le-linux-gnu/ld-2.23.so | grep
__parse_hwcap_and_convert_at_platform
00000000000289d0 g F .text 0000000000000348 0x60
__parse_hwcap_and_convert_at_platform@@GLIBC_2.23
My guess if this is your problem. If not, I can help you diagnose further to
see what the problem is.
You can read my post here on why we need glibc for these builtins:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01012.html
