[Bug target/65837] New: [arm-linux-gnueabihf] lto1 target specific builtin not available

[Bug target/65837] New: [arm-linux-gnueabihf] lto1 target specific builtin not available

[prathamesh3492 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

            Bug ID: 65837
           Summary: [arm-linux-gnueabihf] lto1 target specific builtin not
                    available
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: prathamesh3492 at gcc dot gnu.org

Hi,
I got the following error while building chromium on arm-linux-gnueabihf with
LTO enabled
when linking libshared_memory_support.so:
lto1: fatal error: target specific builtin not available
Full command line used for linking: http://pastebin.com/2ANsEyMn

This appears to be same as PR45790
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45790), which was opened for
rs6000 for gcc-4.6.
Since it is fixed for rs6000, I am not sure if I should have re-opened it.

gcc -v:
Using built-in specs.
COLLECT_GCC=/home/prathamesh.kulkarni/gcc-linaro-6.0/bin/arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/prathamesh.kulkarni/gcc-linaro-6.0/bin/../libexec/gcc/arm-linux-gnueabihf/6.0.0/lto-wrapper
Target: arm-linux-gnueabihf
Configured with:
'/home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git~gcc-chromium/configure'
SHELL=/bin/bash --with-bugurl=https://bugs.linaro.org
--with-mpc=/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/builds/destdir/x86_64-unknown-linux-gnu
--with-mpfr=/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/builds/destdir/x86_64-unknown-linux-gnu
--with-gmp=/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/builds/destdir/x86_64-unknown-linux-gnu
--with-gnu-as --with-gnu-ld --disable-libstdcxx-pch --disable-libmudflap
--with-cloog=no --with-ppl=no --with-isl=no --disable-nls --enable-multiarch
--disable-multilib --enable-c99 --with-tune=cortex-a9 --with-arch=armv7-a
--with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-shared
--enable-static
--with-build-sysroot=/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/sysroots/arm-linux-gnueabihf
--enable-lto --enable-linker-build-id --enable-long-long --enable-shared
--with-sysroot=/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/builds/destdir/x86_64-unknown-linux-gnu/libc
--enable-languages=c,c++,lto --enable-fix-cortex-a53-835769
--enable-checking=yes --disable-bootstrap --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --target=arm-linux-gnueabihf
--prefix=/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/builds/destdir/x86_64-unknown-linux-gnu
Thread model: posix
gcc version 6.0.0 20150418 (experimental) (GCC)

Thank you,
Prathamesh

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well,

/* Return the ARM builtin for CODE.  */

tree
arm_builtin_decl (unsigned code, bool initialize_p ATTRIBUTE_UNUSED)
{
  if (code >= ARM_BUILTIN_MAX)
    return error_mark_node;

  return arm_builtin_decls[code];
}

and LTO passes in true for initialize_p ...

Thus it looks like arm is simply missing LTO support for builtins
(eventually a new symptom here because of the way we stream compiler
options now, with target attributes)

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[prathamesh3492 at gcc dot gnu.org]

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

Thank you,
Prathamesh

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[prathamesh3492 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

prathamesh3492 at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #5 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Ramana Radhakrishnan from comment #4)
> (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
> > lto1: fatal error: target specific builtin not available
> > compilation terminated.
> 
> Ofcourse, that's expected behaviour - you don't have support for the SIMD
> intrinsics if you don't ask for it on the command line or your compiler
> doesn't default to generating code for the SIMD unit.
> 
> > 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
> 
> RESOLVED INVALID then ?
Yeah, silly mistake from my side, sorry for the noise.

Regards,
Prathamesh
> 
> regards
> Ramana
> 
> > 
> > Thank you
> > Prathamesh

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2015-04-23
         Resolution|INVALID                     |---
     Ever confirmed|0                           |1

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Not really - it's supported with GCC 5 that way as it uses target attributes.

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[rguenther at suse dot de]

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.

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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)?

> 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

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[prathamesh3492 at gcc dot gnu.org]

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'

/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

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> ---
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?

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
> 
>

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[ramana at gcc dot gnu.org]

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
> > 
> >

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[prathamesh3492 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #13 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Ramana Radhakrishnan from comment #12)
> (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.
Hi,
Is it okay if I start investigating this tomorrow ? I am busy with something
else at the moment, sorry about that.

Regards,
Prathamesh
> 
> 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
> > > 
> > >

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |prathamesh3492 at gcc dot gnu.org

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[prathamesh3492 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

prathamesh3492 at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mkuvyrkov at gcc dot gnu.org

--- Comment #14 from prathamesh3492 at gcc dot gnu.org ---
Hi,
Following Maxim's suggestion I tried to build with x86_64-gcc passing -mtune=k8
at compile-time but not at link time and the same thing happens.

gcc -flto -mtune=k8 foo.c -v:

Without passing -mtune=k8 at link-time, -mtune=generic overrides -mtune=k8
gcc -flto foo.o -v:

COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math'
'-fno-trapv' '-fno-strict-overflow' '-fno-openmp' '-fno-openacc' '-mtune=k8'
'-march=x86-64' '-v' '-mtune=generic' '-march=x86-64'
'-fltrans-output-list=/tmp/cc415lAT.ltrans.out' '-fwpa'
'-fresolution=/tmp/ccuL4EuS.res'

/home/prathamesh.kulkarni/fsf-toolchain/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto1
-quiet -dumpbase foo.o -mtune=k8 -march=x86-64 -mtune=generic -march=x86-64
-auxbase foo -version -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv
-fno-strict-overflow -fno-openmp -fno-openacc
-fltrans-output-list=/tmp/cc415lAT.ltrans.out -fwpa
-fresolution=/tmp/ccuL4EuS.res @/tmp/ccXLZx2S

Passing -mtune=k8 at link-time, passes only -mtune=k8 to lto1 
gcc -flto -mtune=k8 foo.o -v:

COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math'
'-fno-trapv' '-fno-strict-overflow' '-fno-openmp' '-fno-openacc' '-mtune=k8'
'-march=x86-64' '-mtune=k8' '-v' '-march=x86-64'
'-fltrans-output-list=/tmp/ccK0THy1.ltrans.out' '-fwpa'
'-fresolution=/tmp/ccqMHR7Y.res'

/home/prathamesh.kulkarni/fsf-toolchain/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto1
-quiet -dumpbase foo.o -mtune=k8 -march=x86-64 -mtune=k8 -march=x86-64 -auxbase
foo -version -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv
-fno-strict-overflow -fno-openmp -fno-openacc
-fltrans-output-list=/tmp/ccK0THy1.ltrans.out -fwpa
-fresolution=/tmp/ccqMHR7Y.res @/tmp/ccxcdoB1

So this looks like a target independent bug ? I am continuing to investigate
it.

Thank you,
Prathamesh

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[prathamesh3492 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #15 from prathamesh3492 at gcc dot gnu.org ---
Hi,
I am not entirely sure, the issue seems to be in lto-wrapper.
In lto-wrapper.c:run_gcc():
fdecoded_options, which are compiler options contains "-mfpu=neon"
decoded_options, which are linker options contains "-mfpu=vfpv3-d16".
decoded_options are populated by 
lto-wrapper.c:get_options_from_collect_gcc_options() from environment
variable COLLECT_GCC_OPTIONS.

fdecoded_options are appended after decoded_options in run_gcc():

  append_linker_options (&argv_obstack, decoded_options,
decoded_options_count);
  append_compiler_options (&argv_obstack, fdecoded_options,
                           fdecoded_options_count);

which is why -mfpu=vfpv3-d16 overrides -mfpu=neon.

Reversing the order of above function calls works fine for me
for the above test-case.

However I am not sure if this is the right approach,
It now passes -mfpu=vfpv3-d16 and then it's overriden by -mfpu=neon
since we reversed the order.
Ideally we don't want -mfpu=vfpv3-d16 to appear ?

I am not understanding why vfpv3-d16 appears in collect_gcc_options in
run_gcc().
While writing COLLECT_GCC_OPTIONS in
lto-opts.c:append_to_collect_gcc_options(), -mfpu=vfpv3-d16 is not present,
Only -mfpu=neon is present, which is correct since it was passed as a command
line option.

I am not sure what modifies COLLECT_GCC_OPTIONS before it is read by run_gcc()
in lto-wrapper.

Thank you,
Prathamesh

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[prathamesh3492 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #17 from prathamesh3492 at gcc dot gnu.org ---
(In reply to clyon from comment #16)
> (In reply to prathamesh3492 from comment #15)
> 
> > I am not understanding why vfpv3-d16 appears in collect_gcc_options in
> > run_gcc().
> Isn't this because you configured GCC --with-fpu=vfpv3-d16?

COLLECT_GCC_OPTIONS is set by gcc.c:set_collect_gcc_options():
/* Build COLLECT_GCC_OPTIONS to have all of the options specified to
     the compiler.  */
  obstack_grow (&collect_obstack, "COLLECT_GCC_OPTIONS=",
                sizeof ("COLLECT_GCC_OPTIONS=") - 1);

and at the end of set_collect_gcc_options():
xputenv (XOBFINISH (&collect_obstack, char *));
which makes it environment variable.

set_collect_gcc_options() is called by do_spec, which is called by
driver::maybe_run_linker(), before executing linker.
So the driver has no knowledge of options passed at compile-time,
it sets the default -mfpu=vfpv3-d16.

When lto-wrapper executes,
it gets linker command line options from environment variable
COLLECT_GCC_OPTIONS,
which contains -mfpu=vfpv3-d16.
and since that was being appended after compile-time options
(fdecoded_options), -mfpu=vfpv3-d16 overrides -mfpu=neon.

This also explains why it works in one shot
arm-linux-gnueabihf -flto -mfpu=neon test.c

COLLECT_GCC_OPTIONS will have "-mfpu=neon" since it's mentioned on command
line, and lto-wrapper has access to this COLLECT_GCC_OPTIONS.

When compiler and linker are run separately, at link time, the driver has no
knowledege of flags of compile-time run,
and hence sets default flags in COLLECT_GCC_OPTIONS.

I think correct way to fix would be in run_gcc() to get values from
COLLECT_GCC_OPTIONS in decoded_options as is currently done.
run_gcc() walks through options in object file and saves it in
fdecoded_options. So override the value in
decoded_options for the same option found in fdecoded_options. 
Would that be a right approach ?

Thank you,
Prathamesh

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[prathamesh3492 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #18 from prathamesh3492 at gcc dot gnu.org ---
Created attachment 35420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35420&action=edit
patch to override default options by options in object file

Hi,

The following untested patch gives preference to option value in object file.
In run_gcc(),
options from COLLECT_GCC_OPTIONS which are taken from command line are stored
in decoded_options.
options from object file are stored in fdecoded_options.
so override the option in decoded_options if it is present in fdecoded_options.

With the patch this works:
arm-linux-gnueabihf-gcc test.c -mfpu=neon -flto -c
arm-linux-gnueabihf-gcc test.o -flto 
only passes -mfpu=neon to lto1

However the patch doesn't work when same option is passed different values at
compile and link-time:
arm-linux-gnuebihf-gcc test.c -mfpu=neon -flto -c
arm-linux-gnueabihf-gcc test.o -mfpu=vfpv3-d16 -flto

In this case, -mfpu=neon is still passed to lto1, since the patch prefers
option value from object file.
Without the patch, the option from the command line was given preference.

for both the following cases: 
arm-linux-gnueabihf-gcc test.o -flto
arm-linux-gnueabihf-gcc test.o -flto -mfpu=vfpv3-d16

COLLECT_GCC_OPTIONS contains "-mfpu=vfpv3-d16", however in the first case it
isn't explictly passed by user, so passing -mfpu=neon
would be correct. In the second case, since -mfpu=vfpv3-d16 is passed
intentionally by user, should it be considered
as an error - "conflicting options" ?

Unfortunately, it looks like there is no way to distinguish between options
defined by default and explicitly passed options from COLLECT_GCC_OPTIONS and
that's the only way command line options are passed to lto-wrapper from the
driver. One way would be to modify COLLECT_GCC_OPTIONS in the driver to
indicate which options were explicitly passed from command line.
For instance, additionally COLLECT_GCC_OPTIONS would contain 
"-mfpu=vfpv3-d16-explicit" to indiciate that -mfpu=vfpv3-d16 was
passed from command line and not set by default. In lto-wrapper the options
could be parsed to check if they have "explicit" suffix and thus distinguish
between explicit and defualt defined options.
Does that sound reasonable ? I would be grateful for suggestions.

Thank you,
Prathamesh

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to prathamesh3492 from comment #18)
> Created attachment 35420 [details]
> patch to override default options by options in object file
> 
> Hi,
> 
> The following untested patch gives preference to option value in object file.
> In run_gcc(),
> options from COLLECT_GCC_OPTIONS which are taken from command line are
> stored in decoded_options.
> options from object file are stored in fdecoded_options.
> so override the option in decoded_options if it is present in
> fdecoded_options.
> 
> With the patch this works:
> arm-linux-gnueabihf-gcc test.c -mfpu=neon -flto -c
> arm-linux-gnueabihf-gcc test.o -flto 
> only passes -mfpu=neon to lto1
> 
> However the patch doesn't work when same option is passed different values
> at compile and link-time:
> arm-linux-gnuebihf-gcc test.c -mfpu=neon -flto -c
> arm-linux-gnueabihf-gcc test.o -mfpu=vfpv3-d16 -flto
> 
> In this case, -mfpu=neon is still passed to lto1, since the patch prefers
> option value from object file.
> Without the patch, the option from the command line was given preference.
> 
> for both the following cases: 
> arm-linux-gnueabihf-gcc test.o -flto
> arm-linux-gnueabihf-gcc test.o -flto -mfpu=vfpv3-d16
> 
> COLLECT_GCC_OPTIONS contains "-mfpu=vfpv3-d16", however in the first case it
> isn't explictly passed by user, so passing -mfpu=neon
> would be correct. In the second case, since -mfpu=vfpv3-d16 is passed
> intentionally by user, should it be considered
> as an error - "conflicting options" ?
> 
> Unfortunately, it looks like there is no way to distinguish between options
> defined by default and explicitly passed options from COLLECT_GCC_OPTIONS
> and that's the only way command line options are passed to lto-wrapper from
> the driver. One way would be to modify COLLECT_GCC_OPTIONS in the driver to
> indicate which options were explicitly passed from command line.
> For instance, additionally COLLECT_GCC_OPTIONS would contain 
> "-mfpu=vfpv3-d16-explicit" to indiciate that -mfpu=vfpv3-d16 was
> passed from command line and not set by default. In lto-wrapper the options
> could be parsed to check if they have "explicit" suffix and thus distinguish
> between explicit and defualt defined options.
> Does that sound reasonable ? I would be grateful for suggestions.
> 
> Thank you,
> Prathamesh

As said the patch is wrong.

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 28 Apr 2015, prathamesh3492 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
> 
> --- Comment #17 from prathamesh3492 at gcc dot gnu.org ---
> (In reply to clyon from comment #16)
> > (In reply to prathamesh3492 from comment #15)
> > 
> > > I am not understanding why vfpv3-d16 appears in collect_gcc_options in
> > > run_gcc().
> > Isn't this because you configured GCC --with-fpu=vfpv3-d16?
> 
> COLLECT_GCC_OPTIONS is set by gcc.c:set_collect_gcc_options():
> /* Build COLLECT_GCC_OPTIONS to have all of the options specified to
>      the compiler.  */
>   obstack_grow (&collect_obstack, "COLLECT_GCC_OPTIONS=",
>                 sizeof ("COLLECT_GCC_OPTIONS=") - 1);
> 
> and at the end of set_collect_gcc_options():
> xputenv (XOBFINISH (&collect_obstack, char *));
> which makes it environment variable.
> 
> set_collect_gcc_options() is called by do_spec, which is called by
> driver::maybe_run_linker(), before executing linker.
> So the driver has no knowledge of options passed at compile-time,
> it sets the default -mfpu=vfpv3-d16.
> 
> When lto-wrapper executes,
> it gets linker command line options from environment variable
> COLLECT_GCC_OPTIONS,
> which contains -mfpu=vfpv3-d16.
> and since that was being appended after compile-time options
> (fdecoded_options), -mfpu=vfpv3-d16 overrides -mfpu=neon.
> 
> This also explains why it works in one shot
> arm-linux-gnueabihf -flto -mfpu=neon test.c
> 
> COLLECT_GCC_OPTIONS will have "-mfpu=neon" since it's mentioned on command
> line, and lto-wrapper has access to this COLLECT_GCC_OPTIONS.
> 
> When compiler and linker are run separately, at link time, the driver has no
> knowledege of flags of compile-time run,
> and hence sets default flags in COLLECT_GCC_OPTIONS.
> 
> I think correct way to fix would be in run_gcc() to get values from
> COLLECT_GCC_OPTIONS in decoded_options as is currently done.
> run_gcc() walks through options in object file and saves it in
> fdecoded_options. So override the value in
> decoded_options for the same option found in fdecoded_options. 
> Would that be a right approach ?

No, link-time options always override compile-time ones.

I suspect the fix will be to somehow avoid setting defaults when linking?

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #23 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #20)
> On Tue, 28 Apr 2015, prathamesh3492 at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
> > 
> > --- Comment #17 from prathamesh3492 at gcc dot gnu.org ---
> > (In reply to clyon from comment #16)
> > > (In reply to prathamesh3492 from comment #15)
> > > 
> > > > I am not understanding why vfpv3-d16 appears in collect_gcc_options in
> > > > run_gcc().
> > > Isn't this because you configured GCC --with-fpu=vfpv3-d16?
> > 
> > COLLECT_GCC_OPTIONS is set by gcc.c:set_collect_gcc_options():
> > /* Build COLLECT_GCC_OPTIONS to have all of the options specified to
> >      the compiler.  */
> >   obstack_grow (&collect_obstack, "COLLECT_GCC_OPTIONS=",
> >                 sizeof ("COLLECT_GCC_OPTIONS=") - 1);
> > 
> > and at the end of set_collect_gcc_options():
> > xputenv (XOBFINISH (&collect_obstack, char *));
> > which makes it environment variable.
> > 
> > set_collect_gcc_options() is called by do_spec, which is called by
> > driver::maybe_run_linker(), before executing linker.
> > So the driver has no knowledge of options passed at compile-time,
> > it sets the default -mfpu=vfpv3-d16.
> > 
> > When lto-wrapper executes,
> > it gets linker command line options from environment variable
> > COLLECT_GCC_OPTIONS,
> > which contains -mfpu=vfpv3-d16.
> > and since that was being appended after compile-time options
> > (fdecoded_options), -mfpu=vfpv3-d16 overrides -mfpu=neon.
> > 
> > This also explains why it works in one shot
> > arm-linux-gnueabihf -flto -mfpu=neon test.c
> > 
> > COLLECT_GCC_OPTIONS will have "-mfpu=neon" since it's mentioned on command
> > line, and lto-wrapper has access to this COLLECT_GCC_OPTIONS.
> > 
> > When compiler and linker are run separately, at link time, the driver has no
> > knowledege of flags of compile-time run,
> > and hence sets default flags in COLLECT_GCC_OPTIONS.
> > 
> > I think correct way to fix would be in run_gcc() to get values from
> > COLLECT_GCC_OPTIONS in decoded_options as is currently done.
> > run_gcc() walks through options in object file and saves it in
> > fdecoded_options. So override the value in
> > decoded_options for the same option found in fdecoded_options. 
> > Would that be a right approach ?
> 
> No, link-time options always override compile-time ones.
> 
> I suspect the fix will be to somehow avoid setting defaults when linking?

Well I'm not sure how easy that's going to be - You will need some amount of
defaults to get through especially if the user hasn't provided the options in
the first place :( .

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[ramana.radhakrishnan at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #25 from ramana.radhakrishnan at arm dot com <ramana.radhakrishnan at arm dot com> ---
On 29/04/15 09:09, rguenther at suse dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
>
> --- Comment #24 from rguenther at suse dot de <rguenther at suse dot de> ---
> On Wed, 29 Apr 2015, ramana at gcc dot gnu.org wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
>>
>> --- Comment #23 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
>> (In reply to rguenther@suse.de from comment #20)
>>> On Tue, 28 Apr 2015, prathamesh3492 at gcc dot gnu.org wrote:
>>>
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
>>>>
>>>> --- Comment #17 from prathamesh3492 at gcc dot gnu.org ---
>>>> (In reply to clyon from comment #16)
>>>>> (In reply to prathamesh3492 from comment #15)
>>>>>
>>>>>> I am not understanding why vfpv3-d16 appears in collect_gcc_options in
>>>>>> run_gcc().
>>>>> Isn't this because you configured GCC --with-fpu=vfpv3-d16?
>>>>
>>>> COLLECT_GCC_OPTIONS is set by gcc.c:set_collect_gcc_options():
>>>> /* Build COLLECT_GCC_OPTIONS to have all of the options specified to
>>>>       the compiler.  */
>>>>    obstack_grow (&collect_obstack, "COLLECT_GCC_OPTIONS=",
>>>>                  sizeof ("COLLECT_GCC_OPTIONS=") - 1);
>>>>
>>>> and at the end of set_collect_gcc_options():
>>>> xputenv (XOBFINISH (&collect_obstack, char *));
>>>> which makes it environment variable.
>>>>
>>>> set_collect_gcc_options() is called by do_spec, which is called by
>>>> driver::maybe_run_linker(), before executing linker.
>>>> So the driver has no knowledge of options passed at compile-time,
>>>> it sets the default -mfpu=vfpv3-d16.
>>>>
>>>> When lto-wrapper executes,
>>>> it gets linker command line options from environment variable
>>>> COLLECT_GCC_OPTIONS,
>>>> which contains -mfpu=vfpv3-d16.
>>>> and since that was being appended after compile-time options
>>>> (fdecoded_options), -mfpu=vfpv3-d16 overrides -mfpu=neon.
>>>>
>>>> This also explains why it works in one shot
>>>> arm-linux-gnueabihf -flto -mfpu=neon test.c
>>>>
>>>> COLLECT_GCC_OPTIONS will have "-mfpu=neon" since it's mentioned on command
>>>> line, and lto-wrapper has access to this COLLECT_GCC_OPTIONS.
>>>>
>>>> When compiler and linker are run separately, at link time, the driver has no
>>>> knowledege of flags of compile-time run,
>>>> and hence sets default flags in COLLECT_GCC_OPTIONS.
>>>>
>>>> I think correct way to fix would be in run_gcc() to get values from
>>>> COLLECT_GCC_OPTIONS in decoded_options as is currently done.
>>>> run_gcc() walks through options in object file and saves it in
>>>> fdecoded_options. So override the value in
>>>> decoded_options for the same option found in fdecoded_options.
>>>> Would that be a right approach ?
>>>
>>> No, link-time options always override compile-time ones.
>>>
>>> I suspect the fix will be to somehow avoid setting defaults when linking?
>>
>> Well I'm not sure how easy that's going to be - You will need some amount of
>> defaults to get through especially if the user hasn't provided the options in
>> the first place :( .
>
> The other option is to special-case only those options that are slipping
> in that way (-march, -mtune, -mcpu, -mfpu?) and emit those always first,
> hoping that explicit ones will override that.  Of course lto-wrapper
> cannot distinguish between implicitely and explicitely such given
> arguments at link-time.  Which means the only solution would be to
> completely ignore these at link-time.

IMHO that will cause more problems.

Alternatively, add options_default_specs in the beginning and then 
filter out all those values of options that are the same as the default 
options hoping that the user doesn't put that back in again.
But again it's sticky tape and doesnt' really fix the problem.

I'm not sure we're improving the situation in anyway by putting in the 
hack - it just pushes a compile time breakage into possibly subtle 
runtime failure which can easily be achieved by adding the "relaxed 
option" in this case -mfpu=neon to the command line at link time.

At least then it's evident to the user that they need to do something 
specific to their use-case to get LTO working or fail very quickly if 
their code relies on absence of SIMD code in the default case or in the 
case without auto-detection.

I'm pretty sure this will be the first thing to sort out when trying to 
build kernels with LTO for e.g.. .....

So, I guess I'm voting for doing this properly with target attributes 
rather than putting one more bit of sticky tape in a pretty painful area 
of the compiler.

>
> But I suspect this might break otherwise working cases (due to the fact
> that which -march/-mtune/-mcpu/-mfpu options lto-wrapper chooses from
> the object files is essentially "random" if they don't agree for all
> objects).
>
> It's really unfortunate that these configure-time defaults appear
> as regular user command-line arguments :(  I suppose this was done
> to make them visible to specs processing.
>


Yeah, sigh.

regards
Ramana

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #26 from ktkachov at gcc dot gnu.org ---
So, out of interest, what is needed to make this work properly with target
attributes?

What hooks do we need to implement?
Looking at
https://gcc.gnu.org/onlinedocs/gccint/Target-Attributes.html#Target-Attributes

I think it should be TARGET_OPTION_SAVE and TARGET_OPTION_RESTORE and also the
builtin initialisation hook should be changed, but I can't figure out how
TARGET_OPTION_{SAVE, RESTORE} are used (are they even relevant?)

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[chrbr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

chrbr at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chrbr at gcc dot gnu.org

--- Comment #27 from chrbr at gcc dot gnu.org ---

> 
> Should be reproducible without LTO with
> 
> int __attribute__((target("fpu=neon"))) main() 
> {
> ...
> }
> 
> and compiling without -mfpu=neon.
> 

note that #include "arm_neon.h" can't be preprocessed and that the builtins are
not recognized without a global flag:

"arm_neon.h:31:2: error: #error You must enable NEON instructions (e.g.
-mfloat-abi=softfp -mfpu=neon) to use arm_neon.h"

A further improvement for that might be to set the attribute for all the
functions defines in  neon.h and remove the #error check.

e.g:

__extension__ static __inline float32x2_t 
__attribute__ ((__always_inline__))
__attribute__((target("fpu=neon")))
vadd_f32 (float32x2_t __a, float32x2_t __b)
{
  return (float32x2_t) __builtin_neon_vaddv2sf (__a, __b);
}

or use a #pragma target (("mfpu=neon")) region.

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #28 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to chrbr from comment #27)
> > 
> > Should be reproducible without LTO with
> > 
> > int __attribute__((target("fpu=neon"))) main() 
> > {
> > ...
> > }
> > 
> > and compiling without -mfpu=neon.
> > 
> 
> note that #include "arm_neon.h" can't be preprocessed and that the builtins
> are not recognized without a global flag:
> 
> "arm_neon.h:31:2: error: #error You must enable NEON instructions (e.g.
> -mfloat-abi=softfp -mfpu=neon) to use arm_neon.h"
> 
> A further improvement for that might be to set the attribute for all the
> functions defines in  neon.h and remove the #error check.
>   
> e.g:
> 
> __extension__ static __inline float32x2_t 
> __attribute__ ((__always_inline__))
> __attribute__((target("fpu=neon")))
> vadd_f32 (float32x2_t __a, float32x2_t __b)
> {
>   return (float32x2_t) __builtin_neon_vaddv2sf (__a, __b);
> }
> 
> or use a #pragma target (("mfpu=neon")) region.

The #pragma is what I would expect.

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[chrbr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

chrbr at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |52144

--- Comment #29 from chrbr at gcc dot gnu.org ---
Extend the attribute_target thumb/arm support to -mfpu isas


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144
[Bug 52144] ARM should support arm/thumb function attribute to permit different
instruction sets in the same source

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[chrbr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
Bug 65837 depends on bug 52144, which changed state.

Bug 52144 Summary: ARM should support arm/thumb function attribute to permit different instruction sets in the same source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED