Re: [PATCH][ARM] Split out armv7ve effective target check

2016-03-23 Thread Ramana Radhakrishnan 
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
>>>  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  

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

Re: [PATCH][ARM] Split out armv7ve effective target check

2016-03-23 Thread Kyrill Tkachov 


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

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

Re: [PATCH][ARM] Split out armv7ve effective target check

2016-03-23 Thread Kyrill Tkachov 


On 16/03/16 15:54, Ramana Radhakrishnan wrote:

On Wed, Mar 2, 2016 at 1:32 PM, 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?

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  

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

Re: [PATCH][ARM] Split out armv7ve effective target check

2016-03-19 Thread Ramana Radhakrishnan 
On Wed, Mar 2, 2016 at 1:32 PM, 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?

Ok, but please follow up with updating sourcebuild.texi.

Ramana

>
> Thanks,
> Kyrill
>
> 2016-03-02  Kyrylo Tkachov  
>
> * 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.

Re: [PATCH][ARM] Split out armv7ve effective target check

2016-03-09 Thread Kyrill Tkachov 

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  

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

[PATCH][ARM] Split out armv7ve effective target check

2016-03-02 Thread Kyrill Tkachov 

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  

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