public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "ramana at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available Date: Thu, 23 Apr 2015 13:17:00 -0000 [thread overview] Message-ID: <bug-65837-4-CEM1XOfiBi@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-65837-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #12 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> --- (In reply to rguenther@suse.de from comment #11) > On Thu, 23 Apr 2015, prathamesh3492 at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 > > > > --- Comment #10 from prathamesh3492 at gcc dot gnu.org --- > > (In reply to Richard Biener from comment #9) > > > (In reply to prathamesh3492 from comment #3) > > > > 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 > > > > > > this should still work according to my experiments. -mfpu=neon should > > > be passed to lto1 at link time - can you verify it's in the lto option > > > section in test.o and on lto1 (by adding -v)? > > -fmpu=neon is present, however it seems it's overriden by -mfpu=vfpv3-d16 in > > the test.o file > > arm-linux-gnueabihf-gcc -v -flto test.o > > > > COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math' > > '-fno-trapv' '-fno-strict-overflow' '-fno-openmp' '-fno-openacc' '-mfpu=neon' > > '-march=armv7-a' '-mtune=cortex-a9' '-mfloat-abi=hard' '-mthumb' > > '-mtls-dialect=gnu' '-v' '-march=armv7-a' '-mtune=cortex-a9' '-mfloat-abi=hard' > > '-mfpu=vfpv3-d16' '-mthumb' '-mtls-dialect=gnu' > > '-fltrans-output-list=/tmp/cc43ypaC.ltrans.out' '-fwpa' > > '-fresolution=/tmp/ccmDzd6z.res' > > Huh. Can you see where that comes from? Yeah that's odd - it's almost like the command line options passed to the TU precede the defaults of the compiler. Prathamesh, can you dig further - it sounds like we have a real issue here. Ramana > > Richard. > > > /home/prathamesh.kulkarni/gcc-linaro-6.0/bin/../lib/gcc/../../libexec/gcc/arm-linux-gnueabihf/6.0.0/lto1 > > -quiet -dumpbase test.o -mfpu=neon -march=armv7-a -mtune=cortex-a9 > > -mfloat-abi=hard -mthumb -mtls-dialect=gnu -march=armv7-a -mtune=cortex-a9 > > -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -mtls-dialect=gnu -auxbase test > > -version -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv > > -fno-strict-overflow -fno-openmp -fno-openacc > > -fltrans-output-list=/tmp/cc43ypaC.ltrans.out -fwpa > > -fresolution=/tmp/ccmDzd6z.res @/tmp/ccus6SMC > > > > adding -mfpu=neon in the command line, only has -mfpu=neon > > arm-linux-gnueaihf-gcc -v -mfpu=neon -flto test.o > > > > COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math' > > '-fno-trapv' '-fno-strict-overflow' '-fno-openmp' '-fno-openacc' '-mfpu=neon' > > '-march=armv7-a' '-mtune=cortex-a9' '-mfloat-abi=hard' '-mthumb' > > '-mtls-dialect=gnu' '-v' '-mfpu=neon' '-march=armv7-a' '-mtune=cortex-a9' > > '-mfloat-abi=hard' '-mthumb' '-mtls-dialect=gnu' > > '-fltrans-output-list=/tmp/ccCo0pAW.ltrans.out' '-fwpa' > > '-fresolution=/tmp/ccRqEsoP.res' > > /home/prathamesh.kulkarni/gcc-linaro-6.0/bin/../lib/gcc/../../libexec/gcc/arm-linux-gnueabihf/6.0.0/lto1 > > -quiet -dumpbase test.o -mfpu=neon -march=armv7-a -mtune=cortex-a9 > > -mfloat-abi=hard -mthumb -mtls-dialect=gnu -mfpu=neon -march=armv7-a > > -mtune=cortex-a9 -mfloat-abi=hard -mthumb -mtls-dialect=gnu -auxbase test > > -version -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv > > -fno-strict-overflow -fno-openmp -fno-openacc > > -fltrans-output-list=/tmp/ccCo0pAW.ltrans.out -fwpa > > -fresolution=/tmp/ccRqEsoP.res @/tmp/ccArRJjW > > > > Thanks, > > Prathamesh > > > > > > > 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 > > > > > > > > Thank you, > > > > Prathamesh > > > >
next prev parent reply other threads:[~2015-04-23 13:17 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-04-21 20:28 [Bug target/65837] New: " prathamesh3492 at gcc dot gnu.org 2015-04-22 8:54 ` [Bug target/65837] " rguenth at gcc dot gnu.org 2015-04-22 19:53 ` prathamesh3492 at gcc dot gnu.org 2015-04-22 23:38 ` prathamesh3492 at gcc dot gnu.org 2015-04-23 8:18 ` rguenth at gcc dot gnu.org 2015-04-23 8:18 ` rguenther at suse dot de 2015-04-23 11:46 ` rguenth at gcc dot gnu.org 2015-04-23 12:18 ` prathamesh3492 at gcc dot gnu.org 2015-04-23 12:20 ` rguenther at suse dot de 2015-04-23 13:17 ` ramana at gcc dot gnu.org [this message] 2015-04-23 13:50 ` prathamesh3492 at gcc dot gnu.org 2015-04-23 13:52 ` ramana at gcc dot gnu.org 2015-04-28 10:48 ` prathamesh3492 at gcc dot gnu.org 2015-04-28 14:14 ` prathamesh3492 at gcc dot gnu.org 2015-04-28 19:22 ` prathamesh3492 at gcc dot gnu.org 2015-04-28 22:40 ` prathamesh3492 at gcc dot gnu.org 2015-04-29 7:42 ` rguenther at suse dot de 2015-04-29 7:42 ` rguenth at gcc dot gnu.org 2015-04-29 8:00 ` ramana at gcc dot gnu.org 2015-04-29 11:30 ` ramana.radhakrishnan at arm dot com 2015-05-05 15:18 ` ktkachov at gcc dot gnu.org 2015-05-19 13:44 ` chrbr at gcc dot gnu.org 2015-05-19 15:49 ` ramana at gcc dot gnu.org 2015-05-20 13:21 ` chrbr at gcc dot gnu.org 2015-06-22 8:22 ` chrbr at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-65837-4-CEM1XOfiBi@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).