[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #36 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Fri Jan 15 08:46:49 2016 New Revision: 232403 URL: https://gcc.gnu.org/viewcvs?rev=232403&root=gcc&view=rev Log: gcc 2015-01-16 Christian Bruel PR target/65837 * config/arm/arm-builtins.c (ARM_BUILTIN_CRYPTO_BASE): New enum tag. (arm_init_neon_builtins_internal): Rename arm_init_neon_builtins, (arm_init_crypto_builtins_internal): Rename arm_init_crypto_builtins. use add_builtin_function_ext_scope instead of add_builtin_function. (neon_set_p, neon_crypto_set_p): Remove. (arm_init_builtins): Always call arm_init_neon_builtins and arm_init_crypto_builtins. (arm_expand_builtin): Check that builtins are allowed for the arch. * config/arm/arm-protos.h (arm_init_neon_builtins): Remove prototype. * config/arm/arm.c (arm_valid_target_attribute_tree): Remove arm_init_neon_builtins call. gcc/testsuite 2015-01-16 Christian Bruel PR target/65837 * gcc.target/arm/attr-neon-builtin-fail2.c: New test. * gcc.target/arm/lto/pr65837-attr_0.c: New test. * gcc.target/arm/lto/pr65837_0.c: Fix skip condition and use ACLE name. Added: trunk/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c trunk/gcc/testsuite/gcc.target/arm/lto/pr65837-attr_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-builtins.c trunk/gcc/config/arm/arm-protos.h trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/lto/pr65837_0.c
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #30 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Fri Nov 13 15:19:19 2015 New Revision: 230327 URL: https://gcc.gnu.org/viewcvs?rev=230327&root=gcc&view=rev Log: 2015-11-13 Christian Bruel PR target/65837 * config/arm/arm.c (arm_option_override): Move NEON check... (arm_option_check_internal): here (arm_file_start): Move .fpu print... (arm_declare_function_name): here (arm_option_print): Dump current fpu name. * config/arm/arm.opt (arm_fpu_index): Mark Save. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.opt
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #31 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Mon Nov 16 08:46:42 2015 New Revision: 230404 URL: https://gcc.gnu.org/viewcvs?rev=230404&root=gcc&view=rev Log: 2015-11-16 Christian Bruel PR target/65837 * config/arm/arm.c (arm_fpu_desc): Remove. (all_fpus): Make global. (arm_option_override): Use FPU TARGET accessors. (arm_declare_function_name): Likewise. * config/arm/arm.h (TARGET_VFP, TARGET_VFPD32, TARGET_VFP5) (TARGET_VFP_SINGLE, TARGET_VFP_DOUBLE, TARGET_NEON_FP16) (TARGET_FP16, TARGET_FMA, TARGET_FPU_ARMV8, TARGET_CRYPTO) (TARGET_NEON): Likewise. (all_fpus): Declare extern. (TARGET_FPU_NAME, TARGET_FPU_MODEL, TARGET_FPU_REV) (TARGET_FPU_REGS, TARGET_FPU_FEATURES): Define all_fpus accessors. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.h
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #32 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Mon Nov 16 09:00:09 2015 New Revision: 230406 URL: https://gcc.gnu.org/viewcvs?rev=230406&root=gcc&view=rev Log: 2015-11-16 Christian Bruel PR target/65837 * config/arm/arm-protos.h (arm_init_neon_builtins): Declare. * config/arm/arm.c (arm_valid_target_attribute_tree): Call arm_init_neon_builtins. * config/arm/arm-builtins.c (arm_init_neon_builtins): Split into... (arm_init_neon_builtins_internal) (arm_init_crypto_builtins_internal): Test and set neon_set_p, neon_crypto_set_p. (neon_set_p, neon_crypto_set_p): New static booleans. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-builtins.c trunk/gcc/config/arm/arm-protos.h trunk/gcc/config/arm/arm.c
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #33 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Mon Nov 16 10:21:09 2015 New Revision: 230408 URL: https://gcc.gnu.org/viewcvs?rev=230408&root=gcc&view=rev Log: 2015-11-16 Christian Bruel PR target/65837 * config/arm/arm-c.c (arm_cpu_builtins): Set or reset __ARM_FEATURE_CRYPTO, __VFP_FP__, __ARM_NEON__ (arm_pragma_target_parse): Change check for arm_cpu_builtins. undefine __ARM_FP. * config/arm/arm.c (arm_can_inline_p): Check FPUs. (arm_valid_target_attribute_rec): Handle -mfpu attribute target. * doc/invoke.texi (-mfpu=): Mention attribute and pragma. * doc/extend.texi (-mfpu=): Describe attribute. 2015-11-16 Christian Bruel PR target/65837 gcc.target/arm/lto/pr65837_0.c gcc.target/arm/attr-neon2.c gcc.target/arm/attr-neon.c gcc.target/arm/attr-neon-builtin-fail.c gcc.target/arm/attr-crypto.c Added: trunk/gcc/testsuite/gcc.target/arm/attr-crypto.c trunk/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail.c trunk/gcc/testsuite/gcc.target/arm/attr-neon.c trunk/gcc/testsuite/gcc.target/arm/attr-neon2.c trunk/gcc/testsuite/gcc.target/arm/lto/pr65837_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-c.c trunk/gcc/config/arm/arm.c trunk/gcc/doc/extend.texi trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #34 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Mon Nov 16 11:20:02 2015 New Revision: 230410 URL: https://gcc.gnu.org/viewcvs?rev=230410&root=gcc&view=rev Log: 2015-11-16 Christian Bruel PR target/65837 * config/arm/arm-c.c (arm_cpu_builtins): Conditionally set and reset __ARM_FEATURE_FMA and __ARM_NEON_FP, __ARM_FP. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-c.c
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #35 from chrbr at gcc dot gnu.org --- Specific NEON case fixed with the attribute/pragma target support for fpu= attribute support can now be extended for other target flags that need to be propagated to LTO (-mcpu=, -mtune=, -munaligned-access...)
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #1 from Richard Biener ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Comment #2 from Ramana Radhakrishnan ---
(In reply to Richard Biener from comment #1)
> 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)
Well, we defined TARGET_BUILTIN_DECL a few years back for precisely supporting
LTO streaming of builtins - can you elaborate further what target support is
missing and for quite a while this was working ?
What did we miss when adding that support ?
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #4 from Ramana Radhakrishnan ---
(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 ?
regards
Ramana
>
> Thank you
> Prathamesh
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #6 from 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 Richard Biener changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2015-04-23 Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #7 from Richard Biener --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #8 from ramana.radhakrishnan at arm dot com --- On 23/04/15 09:18, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 > > Richard Biener changed: > > What|Removed |Added > > Status|RESOLVED|REOPENED > Last reconfirmed||2015-04-23 > Resolution|INVALID |--- > Ever confirmed|0 |1 > > --- Comment #7 from Richard Biener --- > Not really - it's supported with GCC 5 that way as it uses target attributes. > The ARM backend doesn't support target attributes either as attributes to functions or as #pragmas. That's the real issue not that we don't initialize and stream the builtins in this corner case. While doing that work we need to make sure we initialize the builtins for the appropriate options. So the Chromium usecase is INVALID, I'd think. But an additional PR to support target attributes in the ARM backend. There's a start with Christian Bruel's patches for arm and thumb but it needs extension to other options as well. Ramana
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #9 from Richard Biener ---
(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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #11 from 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #12 from Ramana Radhakrishnan ---
(In reply to rguent...@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
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 rguent...@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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 Ramana Radhakrishnan 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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #16 from clyon at gcc dot gnu.org --- (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?
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #19 from prathamesh3492 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. Instead of modifying COLLECT_GCC_OPTIONS, maybe create another environment variable say COLLECT_GCC_OPTIONS_EXPLICIT and if an option is passed on command line, put it in COLLECT_GCC_OPTIONS_EXPLICIT, so lto-wrapper can distinguish between default defined options and options passed on command line. Thank you, Prathamesh > > Thank you, > Prathamesh
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #20 from 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #21 from Richard Biener --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #22 from Ramana Radhakrishnan --- (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" ? No, otherwise users will have to rebuild their compilers for different defaults, thus defeating the whole purpose of having command line 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #23 from Ramana Radhakrishnan ---
(In reply to rguent...@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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #24 from 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 ---
> (In reply to rguent...@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.
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.
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #25 from 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 ---
> 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 ---
>> (In reply to rguent...@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 pr
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #28 from Ramana Radhakrishnan ---
(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
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
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
