| Message ID | 56D6EB74.6070702@foss.arm.com |
|---|---|
| State | New |
| Headers | show |
Ping. https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00162.html Thanks, Kyrill On 02/03/16 13:32, Kyrill Tkachov wrote: > Hi all, > > I'm seeing the fails: > FAIL: gcc.target/arm/atomic_loaddi_2.c scan-assembler-times ldrd\tr[0-9]+, r[0-9]+, \\[r[0-9]+\\] 1 > FAIL: gcc.target/arm/atomic_loaddi_5.c scan-assembler-times ldrd\tr[0-9]+, r[0-9]+, \\[r[0-9]+\\] 1 > FAIL: gcc.target/arm/atomic_loaddi_8.c scan-assembler-times ldrd\tr[0-9]+, r[0-9]+, \\[r[0-9]+\\] 1 > > when testing an arm multilib with /-march=armv7-a. > > The tests have an effective target check for armv7ve but it doesn't work because > under the hood the check is the same as for armv7-a, that is it checks for the __ARM_ARCH_7A__ > predefine which is set for both march values. > > To check for armv7ve using predefines we need to check for both __ARM_ARCH_7A__ and for the hardware > integer division predefine, making armv7ve special. > > So this patch separates the effective target check definition from the rest of the architectures > and defines it appropriately. > > With this patch the aforementioned tests appear UNSUPPORTED when testing the /-march=armv7-a multilib. > > Ok for trunk? > > Thanks, > Kyrill > > 2016-03-02 Kyrylo Tkachov <kyrylo.tkachov@arm.com> > > * lib/target-supports.exp: Remove v7ve entry from loop > creating effective target checks. > (check_effective_target_arm_arch_v7ve_ok): New procedure. > (add_options_for_arm_arch_v7ve): Likewise.
On Wed, Mar 2, 2016 at 1:32 PM, Kyrill Tkachov <kyrylo.tkachov@foss.arm.com> wrote: > Hi all, > > I'm seeing the fails: > FAIL: gcc.target/arm/atomic_loaddi_2.c scan-assembler-times ldrd\tr[0-9]+, > r[0-9]+, \\[r[0-9]+\\] 1 > FAIL: gcc.target/arm/atomic_loaddi_5.c scan-assembler-times ldrd\tr[0-9]+, > r[0-9]+, \\[r[0-9]+\\] 1 > FAIL: gcc.target/arm/atomic_loaddi_8.c scan-assembler-times ldrd\tr[0-9]+, > r[0-9]+, \\[r[0-9]+\\] 1 > > when testing an arm multilib with /-march=armv7-a. > > The tests have an effective target check for armv7ve but it doesn't work > because > under the hood the check is the same as for armv7-a, that is it checks for > the __ARM_ARCH_7A__ > predefine which is set for both march values. > > To check for armv7ve using predefines we need to check for both > __ARM_ARCH_7A__ and for the hardware > integer division predefine, making armv7ve special. > > So this patch separates the effective target check definition from the rest > of the architectures > and defines it appropriately. > > With this patch the aforementioned tests appear UNSUPPORTED when testing the > /-march=armv7-a multilib. > > Ok for trunk? Ok, but please follow up with updating sourcebuild.texi. Ramana > > Thanks, > Kyrill > > 2016-03-02 Kyrylo Tkachov <kyrylo.tkachov@arm.com> > > * lib/target-supports.exp: Remove v7ve entry from loop > creating effective target checks. > (check_effective_target_arm_arch_v7ve_ok): New procedure. > (add_options_for_arm_arch_v7ve): Likewise.
On 16/03/16 15:54, Ramana Radhakrishnan wrote: > On Wed, Mar 2, 2016 at 1:32 PM, Kyrill Tkachov > <kyrylo.tkachov@foss.arm.com> wrote: >> Hi all, >> >> I'm seeing the fails: >> FAIL: gcc.target/arm/atomic_loaddi_2.c scan-assembler-times ldrd\tr[0-9]+, >> r[0-9]+, \\[r[0-9]+\\] 1 >> FAIL: gcc.target/arm/atomic_loaddi_5.c scan-assembler-times ldrd\tr[0-9]+, >> r[0-9]+, \\[r[0-9]+\\] 1 >> FAIL: gcc.target/arm/atomic_loaddi_8.c scan-assembler-times ldrd\tr[0-9]+, >> r[0-9]+, \\[r[0-9]+\\] 1 >> >> when testing an arm multilib with /-march=armv7-a. >> >> The tests have an effective target check for armv7ve but it doesn't work >> because >> under the hood the check is the same as for armv7-a, that is it checks for >> the __ARM_ARCH_7A__ >> predefine which is set for both march values. >> >> To check for armv7ve using predefines we need to check for both >> __ARM_ARCH_7A__ and for the hardware >> integer division predefine, making armv7ve special. >> >> So this patch separates the effective target check definition from the rest >> of the architectures >> and defines it appropriately. >> >> With this patch the aforementioned tests appear UNSUPPORTED when testing the >> /-march=armv7-a multilib. >> >> Ok for trunk? > Ok, but please follow up with updating sourcebuild.texi. sourcebuild.texi shouldn't need any updating as I'm not adding a new effective target check, I'm just fixing the way one of the already existing ones is defined. Committed with r234420. Thanks, Kyrill > > Ramana > >> Thanks, >> Kyrill >> >> 2016-03-02 Kyrylo Tkachov <kyrylo.tkachov@arm.com> >> >> * lib/target-supports.exp: Remove v7ve entry from loop >> creating effective target checks. >> (check_effective_target_arm_arch_v7ve_ok): New procedure. >> (add_options_for_arm_arch_v7ve): Likewise.
On 23/03/16 10:33, Kyrill Tkachov wrote: > > On 16/03/16 15:54, Ramana Radhakrishnan wrote: >> On Wed, Mar 2, 2016 at 1:32 PM, Kyrill Tkachov >> <kyrylo.tkachov@foss.arm.com> wrote: >>> Hi all, >>> >>> I'm seeing the fails: >>> FAIL: gcc.target/arm/atomic_loaddi_2.c scan-assembler-times ldrd\tr[0-9]+, >>> r[0-9]+, \\[r[0-9]+\\] 1 >>> FAIL: gcc.target/arm/atomic_loaddi_5.c scan-assembler-times ldrd\tr[0-9]+, >>> r[0-9]+, \\[r[0-9]+\\] 1 >>> FAIL: gcc.target/arm/atomic_loaddi_8.c scan-assembler-times ldrd\tr[0-9]+, >>> r[0-9]+, \\[r[0-9]+\\] 1 >>> >>> when testing an arm multilib with /-march=armv7-a. >>> >>> The tests have an effective target check for armv7ve but it doesn't work >>> because >>> under the hood the check is the same as for armv7-a, that is it checks for >>> the __ARM_ARCH_7A__ >>> predefine which is set for both march values. >>> >>> To check for armv7ve using predefines we need to check for both >>> __ARM_ARCH_7A__ and for the hardware >>> integer division predefine, making armv7ve special. >>> >>> So this patch separates the effective target check definition from the rest >>> of the architectures >>> and defines it appropriately. >>> >>> With this patch the aforementioned tests appear UNSUPPORTED when testing the >>> /-march=armv7-a multilib. >>> >>> Ok for trunk? >> Ok, but please follow up with updating sourcebuild.texi. > > sourcebuild.texi shouldn't need any updating as I'm not adding a new effective > target check, I'm just fixing the way one of the already existing ones is defined. > > Committed with r234420. > Is it ok to also backport this to the branches? We'll need to it for multilib testing of: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00924.html and https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00923.html Thanks, Kyrill > >> >> Ramana >> >>> Thanks, >>> Kyrill >>> >>> 2016-03-02 Kyrylo Tkachov <kyrylo.tkachov@arm.com> >>> >>> * lib/target-supports.exp: Remove v7ve entry from loop >>> creating effective target checks. >>> (check_effective_target_arm_arch_v7ve_ok): New procedure. >>> (add_options_for_arm_arch_v7ve): Likewise. >
On 23/03/16 11:09, Kyrill Tkachov wrote: > > On 23/03/16 10:33, Kyrill Tkachov wrote: >> >> On 16/03/16 15:54, Ramana Radhakrishnan wrote: >>> On Wed, Mar 2, 2016 at 1:32 PM, Kyrill Tkachov >>> <kyrylo.tkachov@foss.arm.com> wrote: >>>> Hi all, >>>> >>>> I'm seeing the fails: >>>> FAIL: gcc.target/arm/atomic_loaddi_2.c scan-assembler-times ldrd\tr[0-9]+, >>>> r[0-9]+, \\[r[0-9]+\\] 1 >>>> FAIL: gcc.target/arm/atomic_loaddi_5.c scan-assembler-times ldrd\tr[0-9]+, >>>> r[0-9]+, \\[r[0-9]+\\] 1 >>>> FAIL: gcc.target/arm/atomic_loaddi_8.c scan-assembler-times ldrd\tr[0-9]+, >>>> r[0-9]+, \\[r[0-9]+\\] 1 >>>> >>>> when testing an arm multilib with /-march=armv7-a. >>>> >>>> The tests have an effective target check for armv7ve but it doesn't work >>>> because >>>> under the hood the check is the same as for armv7-a, that is it checks for >>>> the __ARM_ARCH_7A__ >>>> predefine which is set for both march values. >>>> >>>> To check for armv7ve using predefines we need to check for both >>>> __ARM_ARCH_7A__ and for the hardware >>>> integer division predefine, making armv7ve special. >>>> >>>> So this patch separates the effective target check definition from the rest >>>> of the architectures >>>> and defines it appropriately. >>>> >>>> With this patch the aforementioned tests appear UNSUPPORTED when testing the >>>> /-march=armv7-a multilib. >>>> >>>> Ok for trunk? >>> Ok, but please follow up with updating sourcebuild.texi. >> >> sourcebuild.texi shouldn't need any updating as I'm not adding a new effective >> target check, I'm just fixing the way one of the already existing ones is defined. >> >> Committed with r234420. >> > > Is it ok to also backport this to the branches? > We'll need to it for multilib testing of: > https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00924.html > and > https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00923.html > OK. Ramana > Thanks, > Kyrill > >> >>> >>> Ramana >>> >>>> Thanks, >>>> Kyrill >>>> >>>> 2016-03-02 Kyrylo Tkachov <kyrylo.tkachov@arm.com> >>>> >>>> * lib/target-supports.exp: Remove v7ve entry from loop >>>> creating effective target checks. >>>> (check_effective_target_arm_arch_v7ve_ok): New procedure. >>>> (add_options_for_arm_arch_v7ve): Likewise. >> >
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp index 0b4252f6434fb8223423e06882a061ccf0f5a015..b4374cac83e02ec1867cd590bcca052df81642f1 100644 --- a/gcc/testsuite/lib/target-supports.exp +++ b/gcc/testsuite/lib/target-supports.exp @@ -3158,7 +3158,9 @@ proc check_effective_target_arm_fp16_ok { } { # Creates a series of routines that return 1 if the given architecture # can be selected and a routine to give the flags to select that architecture # Note: Extra flags may be added to disable options from newer compilers -# (Thumb in particular - but others may be added in the future) +# (Thumb in particular - but others may be added in the future). +# -march=armv7ve is special and is handled explicitly after this loop because +# it needs more than one predefine check to identify. # Usage: /* { dg-require-effective-target arm_arch_v5_ok } */ # /* { dg-add-options arm_arch_v5 } */ # /* { dg-require-effective-target arm_arch_v5_multilib } */ @@ -3173,7 +3175,6 @@ foreach { armfunc armflag armdef } { v4 "-march=armv4 -marm" __ARM_ARCH_4__ v6z "-march=armv6z" __ARM_ARCH_6Z__ v6m "-march=armv6-m -mthumb" __ARM_ARCH_6M__ v7a "-march=armv7-a" __ARM_ARCH_7A__ - v7ve "-march=armv7ve" __ARM_ARCH_7A__ v7r "-march=armv7-r" __ARM_ARCH_7R__ v7m "-march=armv7-m -mthumb" __ARM_ARCH_7M__ v7em "-march=armv7e-m -mthumb" __ARM_ARCH_7EM__ @@ -3208,6 +3209,26 @@ foreach { armfunc armflag armdef } { v4 "-march=armv4 -marm" __ARM_ARCH_4__ }] } +# Same functions as above but for -march=armv7ve. To uniquely identify +# -march=armv7ve we need to check for __ARM_ARCH_7A__ as well as +# __ARM_FEATURE_IDIV otherwise it aliases with armv7-a. + +proc check_effective_target_arm_arch_v7ve_ok { } { + if { [ string match "*-marm*" "-march=armv7ve" ] && + ![check_effective_target_arm_arm_ok] } { + return 0 + } + return [check_no_compiler_messages arm_arch_v7ve_ok assembly { + #if !defined (__ARM_ARCH_7A__) || !defined (__ARM_FEATURE_IDIV) + #error !armv7ve + #endif + } "-march=armv7ve" ] +} + +proc add_options_for_arm_arch_v7ve { flags } { + return "$flags -march=armv7ve" +} + # Return 1 if this is an ARM target where -marm causes ARM to be # used (not Thumb)
Hi all, I'm seeing the fails: FAIL: gcc.target/arm/atomic_loaddi_2.c scan-assembler-times ldrd\tr[0-9]+, r[0-9]+, \\[r[0-9]+\\] 1 FAIL: gcc.target/arm/atomic_loaddi_5.c scan-assembler-times ldrd\tr[0-9]+, r[0-9]+, \\[r[0-9]+\\] 1 FAIL: gcc.target/arm/atomic_loaddi_8.c scan-assembler-times ldrd\tr[0-9]+, r[0-9]+, \\[r[0-9]+\\] 1 when testing an arm multilib with /-march=armv7-a. The tests have an effective target check for armv7ve but it doesn't work because under the hood the check is the same as for armv7-a, that is it checks for the __ARM_ARCH_7A__ predefine which is set for both march values. To check for armv7ve using predefines we need to check for both __ARM_ARCH_7A__ and for the hardware integer division predefine, making armv7ve special. So this patch separates the effective target check definition from the rest of the architectures and defines it appropriately. With this patch the aforementioned tests appear UNSUPPORTED when testing the /-march=armv7-a multilib. Ok for trunk? Thanks, Kyrill 2016-03-02 Kyrylo Tkachov <kyrylo.tkachov@arm.com> * lib/target-supports.exp: Remove v7ve entry from loop creating effective target checks. (check_effective_target_arm_arch_v7ve_ok): New procedure. (add_options_for_arm_arch_v7ve): Likewise.