public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH][ARM] Split out armv7ve effective target check
@ 2016-03-02 13:32 Kyrill Tkachov
  2016-03-09  9:33 ` Kyrill Tkachov
  2016-03-16 15:54 ` Ramana Radhakrishnan
  0 siblings, 2 replies; 6+ messages in thread
From: Kyrill Tkachov @ 2016-03-02 13:32 UTC (permalink / raw)
  To: GCC Patches; +Cc: Ramana Radhakrishnan, Richard Earnshaw

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

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.

[-- Attachment #2: arm-v7ve-check.patch --]
[-- Type: text/x-patch, Size: 2307 bytes --]

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)
 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH][ARM] Split out armv7ve effective target check
  2016-03-02 13:32 [PATCH][ARM] Split out armv7ve effective target check Kyrill Tkachov
@ 2016-03-09  9:33 ` Kyrill Tkachov
  2016-03-16 15:54 ` Ramana Radhakrishnan
  1 sibling, 0 replies; 6+ messages in thread
From: Kyrill Tkachov @ 2016-03-09  9:33 UTC (permalink / raw)
  To: GCC Patches; +Cc: Ramana Radhakrishnan, Richard Earnshaw

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH][ARM] Split out armv7ve effective target check
  2016-03-02 13:32 [PATCH][ARM] Split out armv7ve effective target check Kyrill Tkachov
  2016-03-09  9:33 ` Kyrill Tkachov
@ 2016-03-16 15:54 ` Ramana Radhakrishnan
  2016-03-23 11:09   ` Kyrill Tkachov
  1 sibling, 1 reply; 6+ messages in thread
From: Ramana Radhakrishnan @ 2016-03-16 15:54 UTC (permalink / raw)
  To: Kyrill Tkachov; +Cc: GCC Patches, Ramana Radhakrishnan, Richard Earnshaw

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH][ARM] Split out armv7ve effective target check
  2016-03-16 15:54 ` Ramana Radhakrishnan
@ 2016-03-23 11:09   ` Kyrill Tkachov
  2016-03-23 11:29     ` Kyrill Tkachov
  0 siblings, 1 reply; 6+ messages in thread
From: Kyrill Tkachov @ 2016-03-23 11:09 UTC (permalink / raw)
  To: Ramana Radhakrishnan; +Cc: GCC Patches, Ramana Radhakrishnan, Richard Earnshaw


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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH][ARM] Split out armv7ve effective target check
  2016-03-23 11:09   ` Kyrill Tkachov
@ 2016-03-23 11:29     ` Kyrill Tkachov
  2016-03-23 11:41       ` Ramana Radhakrishnan
  0 siblings, 1 reply; 6+ messages in thread
From: Kyrill Tkachov @ 2016-03-23 11:29 UTC (permalink / raw)
  To: Ramana Radhakrishnan; +Cc: GCC Patches, Ramana Radhakrishnan, Richard Earnshaw


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH][ARM] Split out armv7ve effective target check
  2016-03-23 11:29     ` Kyrill Tkachov
@ 2016-03-23 11:41       ` Ramana Radhakrishnan
  0 siblings, 0 replies; 6+ messages in thread
From: Ramana Radhakrishnan @ 2016-03-23 11:41 UTC (permalink / raw)
  To: Kyrill Tkachov, Ramana Radhakrishnan; +Cc: GCC Patches, Richard Earnshaw

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-03-23 11:32 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-02 13:32 [PATCH][ARM] Split out armv7ve effective target check Kyrill Tkachov
2016-03-09  9:33 ` Kyrill Tkachov
2016-03-16 15:54 ` Ramana Radhakrishnan
2016-03-23 11:09   ` Kyrill Tkachov
2016-03-23 11:29     ` Kyrill Tkachov
2016-03-23 11:41       ` Ramana Radhakrishnan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).