https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 22 Apr 2015, prathamesh3492 at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 > > --- Comment #3 from prathamesh3492 at gcc dot gnu.org --- > Hi, > I tried to reproduce the error with a reduced test-case: > > #include "arm_neon.h" > > float32x2_t a, b, c, e; > > int main() > { > e = __builtin_neon_vmls_lanev2sf (a, b, c, 0); > return 0; > } > > arm-linux-gnueabihf-gcc -mfpu=neon test.c -flto test.c -c > arm-linux-gnueabihf-gcc test.o -flto -o test > lto1: fatal error: target specific builtin not available > compilation terminated. > lto-wrapper: fatal error: > /home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/builds/destdir/x86_64-unknown-linux-gnu/bin/arm-linux-gnueabihf-gcc > returned 1 exit status > compilation terminated. > > However passing -mfpu=neon for linking works: > arm-linux-gnueabihf-gcc -mfpu=neon test.o -flto -o test > > I suppose similar thing must be happening during linking > libshared_memory_support.so for chromium build ? > I couldn't see -mfpu=neon in the command line used for linking > libshared_memory_support.so What needs to happen is that -mfpu=neon should be enabled for main() via TARGET_OPTION_NODE streaming. And switching to main() the needs to initialize the builtins enabled by -mfpu=neon. Should be reproducible without LTO with int __attribute__((target("fpu=neon"))) main() { ... } and compiling without -mfpu=neon. Richard.
