[committed 00/22] arm: testsuite: clean up some architecture-specific tests

[committed 00/22] arm: testsuite: clean up some architecture-specific tests

[Richard Earnshaw]

A lot of the arm-specific compiler tests require a specific CPU or
architecture to be specified.  This causes problems if the test suite
run is set up to test a specific architecture or CPU that differs from
the test's requirements.  An exmple I use commonly is

	set target_list { "arm-qemu{,-mthumb}" }

but it is possible to also test other architectures or CPUs this way, for
example,

	set target_list { "arm-qemu{,-mthumb,
	  -march=armv6t2+fp/-mfloat-abi=hard,
	  -march=armv8-a+simd/-mthumb/-mfloat-abi=hard,
	  -mcpu=cortex-m33/-mfloat-abi=softfp,
	  -mcpu=cortex-m55/-mfloat-abi=hard,
	  -mcpu=cortex-m23}" }

[line breaks inserted for readability]

tests 7 permutations of
 - base configuration
 - base configuration with -mthumb
 - armv6t2 with FP and a hard-float ABI
 - armv8-a with Neon and thumb and the hard-float ABI
 - cortex-m33 with the softfp ABI
 - cortex-m55 with the hard-float ABI
 - cortex-m23

Over time we have developed a series of checks that can be used to
ensure that we test what we want to test and don't test if the options
conflict, but these have been applied somewhat haphazzardly and as the
framework has been improved tests haven't been updated to make full
use of the tests.

This patch series deploys the framework dg- directives more widely
across the arm-specific tests to make testing more consistent.  On
that long list of permutations above this results in the following
changes:

16 tests move from FAIL to PASS.
21 new FAILS.  
562 new tests that PASS
74 tests that passed have been removed

The new FAILs are real issues on targets that only support
single-precision FP and should be investigated at some point, but
probably aren't urgent given the use cases for cores with this issue.

The tests that have been removed come from the fact that we now more
accurately test that option combinations won't cause problems; they
are related to the fact that if the testrun config specifies -mcpu,
but the test sets -march, then we can get an architecture conflict.
I have some ideas about how to address this, but that's for a later
test series.

committed to master branch.

R.

Richard Earnshaw (22):
  arm: testsuite: correctly detect armv6t2 hardware for acle execution
    tests
  arm: testsuite: correctly detect hard_float
  arm: testsuite: avoid hard-float ABI incompatibility with -march
  arm: testsuite: avoid problems with -mfpu=auto in pacbti-m-predef-11.c
  arm: testsuite: avoid problems with -mfpu=auto in attr-crypto.c
  arm: testsuite: avoid problems with -mfpu=auto in attr_thumb-static2.c
  arm: testsuite: tidy up pre-run check for g2.c
  arm: testsuite: improve compatibility of arm/lto/pr96939_1.c
  arm: testsuite: tidy up pr65647-2.c pre-checks.
  arm: testsuite: improve compatibility of arm/pr78353-*.c
  arm: testsuite: improve compatibility of pr88648-asm-syntax-unified.c
  arm: testsuite: improve compatibility of pragma_arch_attribute*.c
  arm: testsuite: improve compatibility of pragma_arch_switch_2.c
  arm: testsuite: modernize framework usage for arm/scd42-2.c
  arm: testsuite: improve compatibility of ftest-armv7m-thumb.c
  arm: testsuite: improve compatibility of gcc.target/arm/macro_defs*.c
  arm: testsuite: improve compatibility of
    gcc.target/arm/optional_thumb-*.c
  arm: testsuite: improve compatibility of gcc.target/arm/pr19599.c
  arm: testsuite: improve compatibility of gcc.target/arm/pr59575.c
  testsuite: arm: tighten up mode-specific ISA tests
  arm: testsuite: fix some more architecture tests
  arm: testsuite: improve compatibility of gcc.dg/debug/pr57351.c

 gcc/testsuite/gcc.dg/debug/pr57351.c          |  7 +-
 .../arm/acle/data-intrinsics-armv6.c          |  2 +-
 .../arm/acle/data-intrinsics-rbit.c           |  2 +-
 .../gcc.target/arm/acle/pacbti-m-predef-11.c  |  2 +-
 gcc/testsuite/gcc.target/arm/attr-crypto.c    |  2 +-
 .../gcc.target/arm/attr_thumb-static2.c       |  2 +-
 .../gcc.target/arm/ftest-armv7m-thumb.c       |  3 +-
 gcc/testsuite/gcc.target/arm/g2.c             | 10 +-
 gcc/testsuite/gcc.target/arm/lto/pr96939_1.c  |  2 +-
 gcc/testsuite/gcc.target/arm/macro_defs0.c    |  7 +-
 gcc/testsuite/gcc.target/arm/macro_defs1.c    |  6 +-
 gcc/testsuite/gcc.target/arm/macro_defs2.c    |  6 +-
 .../gcc.target/arm/optional_thumb-1.c         |  2 +-
 .../gcc.target/arm/optional_thumb-3.c         |  4 +-
 gcc/testsuite/gcc.target/arm/pr19599.c        |  2 +-
 gcc/testsuite/gcc.target/arm/pr59575.c        |  4 +-
 gcc/testsuite/gcc.target/arm/pr60650-2.c      |  4 +-
 gcc/testsuite/gcc.target/arm/pr60657.c        |  4 +-
 gcc/testsuite/gcc.target/arm/pr60663.c        |  4 +-
 gcc/testsuite/gcc.target/arm/pr65647-2.c      |  3 +-
 gcc/testsuite/gcc.target/arm/pr78353-1.c      |  3 +-
 gcc/testsuite/gcc.target/arm/pr78353-2.c      |  3 +-
 gcc/testsuite/gcc.target/arm/pr81863.c        |  4 +-
 .../arm/pr88648-asm-syntax-unified.c          |  2 +-
 gcc/testsuite/gcc.target/arm/pr97969.c        |  4 +-
 gcc/testsuite/gcc.target/arm/pr98931.c        |  5 +-
 .../gcc.target/arm/pragma_arch_attribute.c    |  6 +-
 .../gcc.target/arm/pragma_arch_attribute_2.c  |  2 +-
 .../gcc.target/arm/pragma_arch_attribute_3.c  |  2 +-
 .../gcc.target/arm/pragma_arch_switch_2.c     |  5 +-
 gcc/testsuite/gcc.target/arm/scd42-2.c        |  9 +-
 gcc/testsuite/gcc.target/arm/tail-long-call.c |  6 +-
 gcc/testsuite/lib/target-supports.exp         | 92 +++++++++++++------
 33 files changed, 130 insertions(+), 91 deletions(-)

-- 
2.34.1

[committed 01/22] arm: testsuite: correctly detect armv6t2 hardware for acle execution tests

[Richard Earnshaw]

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


Some of the ACLE tests for Arm are executable, but we were only testing
that the compiler could generate code for them, not that the hardware
was capable of executing them.  Fix this by adding an execution test for
suitable hardware.

gcc/testsuite:

	* lib/target-supports.exp (check_effective_target_arm_arch_v6t2_hw_ok):
	New function.
	* gcc.target/arm/acle/data-intrinsics-armv6.c: Use it.
	* gcc.target/arm/acle/data-intrinsics-rbit.c: Likewise.
---
 .../arm/acle/data-intrinsics-armv6.c           |  2 +-
 .../gcc.target/arm/acle/data-intrinsics-rbit.c |  2 +-
 gcc/testsuite/lib/target-supports.exp          | 18 ++++++++++++++++++
 3 files changed, 20 insertions(+), 2 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-arm-testsuite-correctly-detect-armv6t2-hardware-for-.patch --]
[-- Type: text/x-patch; name="0001-arm-testsuite-correctly-detect-armv6t2-hardware-for-.patch", Size: 2036 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/acle/data-intrinsics-armv6.c b/gcc/testsuite/gcc.target/arm/acle/data-intrinsics-armv6.c
index 988ecac3787..6dc8c55e2f9 100644
--- a/gcc/testsuite/gcc.target/arm/acle/data-intrinsics-armv6.c
+++ b/gcc/testsuite/gcc.target/arm/acle/data-intrinsics-armv6.c
@@ -1,5 +1,5 @@
 /* { dg-do run } */
-/* { dg-require-effective-target arm_arch_v6t2_ok } */
+/* { dg-require-effective-target arm_arch_v6t2_hw_ok } */
 /* { dg-add-options arm_arch_v6t2 } */
 
 #include "arm_acle.h"
diff --git a/gcc/testsuite/gcc.target/arm/acle/data-intrinsics-rbit.c b/gcc/testsuite/gcc.target/arm/acle/data-intrinsics-rbit.c
index d1fe274b5ce..b01c4219a7e 100644
--- a/gcc/testsuite/gcc.target/arm/acle/data-intrinsics-rbit.c
+++ b/gcc/testsuite/gcc.target/arm/acle/data-intrinsics-rbit.c
@@ -1,6 +1,6 @@
 /* Test the ACLE data intrinsics existence for specific instruction.  */
 /* { dg-do run } */
-/* { dg-require-effective-target arm_arch_v6t2_ok } */
+/* { dg-require-effective-target arm_arch_v6t2_hw_ok } */
 /* { dg-additional-options "--save-temps -O1" } */
 /* { dg-add-options arm_arch_v6t2 } */
 /* { dg-final { check-function-bodies "**" "" "" } } */
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 1a7bea96c1e..d414cddf4dc 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5590,6 +5590,24 @@ proc check_effective_target_arm_thumb1_cbz_ok {} {
     }
 }
 
+# Return 1 if this is an Arm target which supports the Armv6t2 extensions.
+# This can be either in Arm state or in Thumb state.
+
+proc check_effective_target_arm_arch_v6t2_hw_ok {} {
+    if [check_effective_target_arm_thumb1_ok] {
+	return [check_no_compiler_messages arm_movt object {
+	    int
+	    main (void)
+	    {
+	      asm ("bfc r0, #1, #2");
+	      return 0;
+	    }
+	} [add_options_for_arm_arch_v6t2 ""]]
+    } else {
+	return 0
+    }
+}
+
 # Return 1 if this is an ARM target where ARMv8-M Security Extensions is
 # available.
 

[committed 02/22] arm: testsuite: correctly detect hard_float

[Richard Earnshaw]

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


Add an arm-specific test to check_effective_target_hard_float for
Arm to handle cases where we only have single-precision FP in hardware.

gcc/testsuite:

	* lib/target-supports.exp (check_effective_target_hard_float): Add
	arm-specific test.
---
 gcc/testsuite/lib/target-supports.exp | 11 +++++++++++
 1 file changed, 11 insertions(+)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-arm-testsuite-correctly-detect-hard_float.patch --]
[-- Type: text/x-patch; name="0002-arm-testsuite-correctly-detect-hard_float.patch", Size: 906 bytes --]

diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index d414cddf4dc..ee173b9fb6b 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -1420,6 +1420,17 @@ proc check_effective_target_mpaired_single { args } {
 # Return true if the target has access to FPU instructions.
 
 proc check_effective_target_hard_float { } {
+    # This should work on cores that only have single-precision,
+    # and should also correctly handle legacy cores that had thumb1 and
+    # lacked FP support for that, but had it in Arm state.
+    if { [istarget arm*-*-*] } {
+	return [check_no_compiler_messages hard_float assembly {
+		#if __ARM_FP == 0
+		#error __arm_soft_float
+		#endif
+	}]
+    }
+
     if { [istarget loongarch*-*-*] } {
 	return [check_no_compiler_messages hard_float assembly {
 		#if (defined __loongarch_soft_float)

[committed 03/22] arm: testsuite: avoid hard-float ABI incompatibility with -march

[Richard Earnshaw]

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


A number of tests in the gcc testsuite, especially for arm-specific
targets, add various flags to control the architecture.  These run
into problems when the compiler is configured with -mfpu=auto if the
new architecture lacks an architectural feature that implies we have
floating-point instructions.

The testsuite makes this worse as it falls foul of this requirement in
the base architecture strings provided by target-supports.exp.

To fix this we add "+fp", or something equivalent to this, to all the
base architecture specifications.  The feature will be ignored if the
float ABI is set to soft.

gcc/testsuite:

	* lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok):
	Add base FPU specifications to all architectures that can support
	one.
---
 gcc/testsuite/lib/target-supports.exp | 50 +++++++++++++--------------
 1 file changed, 25 insertions(+), 25 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0003-arm-testsuite-avoid-hard-float-ABI-incompatibility-w.patch --]
[-- Type: text/x-patch; name="0003-arm-testsuite-avoid-hard-float-ABI-incompatibility-w.patch", Size: 3604 bytes --]

diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index ee173b9fb6b..7d83bd8740f 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5408,36 +5408,36 @@ foreach { armfunc armflag armdefs } {
 	v5t "-march=armv5t -mfloat-abi=softfp" __ARM_ARCH_5T__
 	v5t_arm "-march=armv5t -marm" __ARM_ARCH_5T__
 	v5t_thumb "-march=armv5t -mthumb -mfloat-abi=softfp" __ARM_ARCH_5T__
-	v5te "-march=armv5te -mfloat-abi=softfp" __ARM_ARCH_5TE__
-	v5te_arm "-march=armv5te -marm" __ARM_ARCH_5TE__
-	v5te_thumb "-march=armv5te -mthumb -mfloat-abi=softfp" __ARM_ARCH_5TE__
-	v6 "-march=armv6 -mfloat-abi=softfp" __ARM_ARCH_6__
-	v6_arm "-march=armv6 -marm" __ARM_ARCH_6__
-	v6_thumb "-march=armv6 -mthumb -mfloat-abi=softfp" __ARM_ARCH_6__
-	v6k "-march=armv6k -mfloat-abi=softfp" __ARM_ARCH_6K__
-	v6k_arm "-march=armv6k -marm" __ARM_ARCH_6K__
-	v6k_thumb "-march=armv6k -mthumb -mfloat-abi=softfp" __ARM_ARCH_6K__
-	v6t2 "-march=armv6t2" __ARM_ARCH_6T2__
-	v6z "-march=armv6z -mfloat-abi=softfp" __ARM_ARCH_6Z__
-	v6z_arm "-march=armv6z -marm" __ARM_ARCH_6Z__
-	v6z_thumb "-march=armv6z -mthumb -mfloat-abi=softfp" __ARM_ARCH_6Z__
+	v5te "-march=armv5te+fp -mfloat-abi=softfp" __ARM_ARCH_5TE__
+	v5te_arm "-march=armv5te+fp -marm" __ARM_ARCH_5TE__
+	v5te_thumb "-march=armv5te+fp -mthumb -mfloat-abi=softfp" __ARM_ARCH_5TE__
+	v6 "-march=armv6+fp -mfloat-abi=softfp" __ARM_ARCH_6__
+	v6_arm "-march=armv6+fp -marm" __ARM_ARCH_6__
+	v6_thumb "-march=armv6+fp -mthumb -mfloat-abi=softfp" __ARM_ARCH_6__
+	v6k "-march=armv6k+fp -mfloat-abi=softfp" __ARM_ARCH_6K__
+	v6k_arm "-march=armv6k+fp -marm" __ARM_ARCH_6K__
+	v6k_thumb "-march=armv6k+fp -mthumb -mfloat-abi=softfp" __ARM_ARCH_6K__
+	v6t2 "-march=armv6t2+fp" __ARM_ARCH_6T2__
+	v6z "-march=armv6z+fp -mfloat-abi=softfp" __ARM_ARCH_6Z__
+	v6z_arm "-march=armv6z+fp -marm" __ARM_ARCH_6Z__
+	v6z_thumb "-march=armv6z+fp -mthumb -mfloat-abi=softfp" __ARM_ARCH_6Z__
 	v6m "-march=armv6-m -mthumb -mfloat-abi=soft" __ARM_ARCH_6M__
-	v7a "-march=armv7-a" __ARM_ARCH_7A__
-	v7r "-march=armv7-r" __ARM_ARCH_7R__
+	v7a "-march=armv7-a+fp" __ARM_ARCH_7A__
+	v7r "-march=armv7-r+fp" __ARM_ARCH_7R__
 	v7m "-march=armv7-m -mthumb" __ARM_ARCH_7M__
-	v7em "-march=armv7e-m -mthumb" __ARM_ARCH_7EM__
-	v7ve "-march=armv7ve -marm"
+	v7em "-march=armv7e-m+fp -mthumb" __ARM_ARCH_7EM__
+	v7ve "-march=armv7ve+fp -marm"
 		"__ARM_ARCH_7A__ && __ARM_FEATURE_IDIV"
-	v8a "-march=armv8-a" __ARM_ARCH_8A__
-	v8a_hard "-march=armv8-a -mfpu=neon-fp-armv8 -mfloat-abi=hard" __ARM_ARCH_8A__
-	v8_1a "-march=armv8.1-a" __ARM_ARCH_8A__
-	v8_2a "-march=armv8.2-a" __ARM_ARCH_8A__
-	v8r "-march=armv8-r" __ARM_ARCH_8R__
+	v8a "-march=armv8-a+simd" __ARM_ARCH_8A__
+	v8a_hard "-march=armv8-a+simd -mfpu=auto -mfloat-abi=hard" __ARM_ARCH_8A__
+	v8_1a "-march=armv8.1-a+simd" __ARM_ARCH_8A__
+	v8_2a "-march=armv8.2-a+simd" __ARM_ARCH_8A__
+	v8r "-march=armv8-r+fp.sp" __ARM_ARCH_8R__
 	v8m_base "-march=armv8-m.base -mthumb -mfloat-abi=soft"
 		__ARM_ARCH_8M_BASE__
-	v8m_main "-march=armv8-m.main -mthumb" __ARM_ARCH_8M_MAIN__
-	v8_1m_main "-march=armv8.1-m.main -mthumb" __ARM_ARCH_8M_MAIN__
-	v9a "-march=armv9-a" __ARM_ARCH_9A__ } {
+	v8m_main "-march=armv8-m.main+fp -mthumb" __ARM_ARCH_8M_MAIN__
+	v8_1m_main "-march=armv8.1-m.main+fp -mthumb" __ARM_ARCH_8M_MAIN__
+	v9a "-march=armv9-a+simd" __ARM_ARCH_9A__ } {
     eval [string map [list FUNC $armfunc FLAG $armflag DEFS $armdefs ] {
 	proc check_effective_target_arm_arch_FUNC_ok { } {
 	    return [check_no_compiler_messages arm_arch_FUNC_ok assembly {

[committed 04/22] arm: testsuite: avoid problems with -mfpu=auto in pacbti-m-predef-11.c

[Richard Earnshaw]

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


This test overrides the architecture, but fails to describe which
floating-point features are needed.  This causes problems if the ABI
requires FP for parameter passing and -mfpu=auto is selected, so ensure
that one is specified.

gcc/testsuite:

	* gcc.target/arm/acle/pacbti-m-predef-11.c: Add +fp to the -march
	specification.
---
 gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0004-arm-testsuite-avoid-problems-with-mfpu-auto-in-pacbt.patch --]
[-- Type: text/x-patch; name="0004-arm-testsuite-avoid-problems-with-mfpu-auto-in-pacbt.patch", Size: 653 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c
index 9f2711097ac..6a5ae92c567 100644
--- a/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c
+++ b/gcc/testsuite/gcc.target/arm/acle/pacbti-m-predef-11.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" "-mcpu=*" "-mfloat-abi=*" } } */
-/* { dg-options "-march=armv8.1-m.main+pacbti" } */
+/* { dg-options "-march=armv8.1-m.main+fp+pacbti" } */
 
 #if (__ARM_FEATURE_BTI != 1)
 #error "Feature test macro __ARM_FEATURE_BTI_DEFAULT should be defined to 1."

[committed 05/22] arm: testsuite: avoid problems with -mfpu=auto in attr-crypto.c

[Richard Earnshaw]

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


This test overrides the architecture, but fails to describe which
floating-point features are needed.  This causes problems if the ABI
requires FP for parameter passing and -mfpu=auto is selected, so ensure
that one is specified.

gcc/testsuite:

	* gcc.target/arm/attr-crypto.c: Add +simd to the -march
	specification.
---
 gcc/testsuite/gcc.target/arm/attr-crypto.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0005-arm-testsuite-avoid-problems-with-mfpu-auto-in-attr-.patch --]
[-- Type: text/x-patch; name="0005-arm-testsuite-avoid-problems-with-mfpu-auto-in-attr-.patch", Size: 595 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/attr-crypto.c b/gcc/testsuite/gcc.target/arm/attr-crypto.c
index 05e458f36b6..3959d0b67e7 100644
--- a/gcc/testsuite/gcc.target/arm/attr-crypto.c
+++ b/gcc/testsuite/gcc.target/arm/attr-crypto.c
@@ -3,7 +3,7 @@
    pragma.  */
 /* { dg-skip-if "-mpure-code supports M-profile only" { *-*-* } { "-mpure-code" } } */
 /* { dg-require-effective-target arm_fp_ok } */
-/* { dg-options "-O2 -march=armv8-a" } */
+/* { dg-options "-O2 -march=armv8-a+simd" } */
 /* { dg-add-options arm_fp } */
 
 /* Reset fpu to a value compatible with the next pragmas.  */

[committed 06/22] arm: testsuite: avoid problems with -mfpu=auto in attr_thumb-static2.c

[Richard Earnshaw]

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


This test overrides the architecture, but fails to describe which
floating-point features are needed.  This causes problems if the ABI
requires FP for parameter passing and -mfpu=auto is selected, so ensure
that one is specified.

gcc/testsuite:

	* gcc.target/arm/attr_thumb-static2.c: Add +fp to the -march
	specification.
---
 gcc/testsuite/gcc.target/arm/attr_thumb-static2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0006-arm-testsuite-avoid-problems-with-mfpu-auto-in-attr_.patch --]
[-- Type: text/x-patch; name="0006-arm-testsuite-avoid-problems-with-mfpu-auto-in-attr_.patch", Size: 474 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/attr_thumb-static2.c b/gcc/testsuite/gcc.target/arm/attr_thumb-static2.c
index 77454343b23..a38f9a95607 100644
--- a/gcc/testsuite/gcc.target/arm/attr_thumb-static2.c
+++ b/gcc/testsuite/gcc.target/arm/attr_thumb-static2.c
@@ -2,7 +2,7 @@
 
 /* { dg-do compile } */
 /* { dg-require-effective-target arm_arch_v7a_ok } */
-/* { dg-options "-O0 -march=armv7-a" } */
+/* { dg-options "-O0 -march=armv7-a+fp" } */
 
 struct _NSPoint
 {

[committed 07/22] arm: testsuite: tidy up pre-run check for g2.c

[Richard Earnshaw]

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


gcc.target/arm/g2.c is an xscale-only test, but the test is quite old
and we have improved the infrastructure for setting up such tests now.
So make use of that to reduce the number of cases where this test fails
to run.

gcc/testsuite:

	* lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok):
	Add entry to check for xscale.
	* gcc.target/arm/g2.c: Use it.
---
 gcc/testsuite/gcc.target/arm/g2.c     | 10 ++++------
 gcc/testsuite/lib/target-supports.exp |  1 +
 2 files changed, 5 insertions(+), 6 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0007-arm-testsuite-tidy-up-pre-run-check-for-g2.c.patch --]
[-- Type: text/x-patch; name="0007-arm-testsuite-tidy-up-pre-run-check-for-g2.c.patch", Size: 1678 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/g2.c b/gcc/testsuite/gcc.target/arm/g2.c
index ca5e3ccff66..04334c97713 100644
--- a/gcc/testsuite/gcc.target/arm/g2.c
+++ b/gcc/testsuite/gcc.target/arm/g2.c
@@ -1,11 +1,9 @@
 /* Verify that hardware multiply is preferred on XScale. */
 /* { dg-do compile } */
-/* { dg-options "-mcpu=xscale -O2 -marm" } */
-/* { dg-skip-if "Test is specific to the Xscale" { arm*-*-* } { "-march=*" } { "-march=xscale" } } */
-/* { dg-skip-if "Test is specific to the Xscale" { arm*-*-* } { "-mcpu=*" } { "-mcpu=xscale" } } */
-/* { dg-skip-if "Test is specific to ARM mode" { arm*-*-* } { "-mthumb" } { "" } } */
-/* { dg-require-effective-target arm_arch_v5te_arm_ok } */
-/* { dg-require-effective-target arm32 } */
+/* { dg-options "-O2" } */
+/* { dg-require-effective-target arm_arch_xscale_arm_ok } */
+/* { dg-add-options arm_arch_xscale_arm } */
+
 
 /* Brett Gaines' test case. */
 unsigned BCPL(unsigned) __attribute__ ((naked));
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 7d83bd8740f..9d2958626ad 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5411,6 +5411,7 @@ foreach { armfunc armflag armdefs } {
 	v5te "-march=armv5te+fp -mfloat-abi=softfp" __ARM_ARCH_5TE__
 	v5te_arm "-march=armv5te+fp -marm" __ARM_ARCH_5TE__
 	v5te_thumb "-march=armv5te+fp -mthumb -mfloat-abi=softfp" __ARM_ARCH_5TE__
+	xscale_arm "-mcpu=xscale -mfloat-abi=soft -marm" __XSCALE__
 	v6 "-march=armv6+fp -mfloat-abi=softfp" __ARM_ARCH_6__
 	v6_arm "-march=armv6+fp -marm" __ARM_ARCH_6__
 	v6_thumb "-march=armv6+fp -mthumb -mfloat-abi=softfp" __ARM_ARCH_6__

[committed 08/22] arm: testsuite: improve compatibility of arm/lto/pr96939_1.c

[Richard Earnshaw]

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


This test overrides the architecture, but fails to specify the
floating point architecture.  This causes problems if -mfpu=auto is
used.

gcc/testsuite:

	* gcc.target/arm/lto/pr96939_1.c: Add +simd to the architecture
	specification.
---
 gcc/testsuite/gcc.target/arm/lto/pr96939_1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0008-arm-testsuite-improve-compatibility-of-arm-lto-pr969.patch --]
[-- Type: text/x-patch; name="0008-arm-testsuite-improve-compatibility-of-arm-lto-pr969.patch", Size: 402 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/lto/pr96939_1.c b/gcc/testsuite/gcc.target/arm/lto/pr96939_1.c
index 53c6093e803..4afdbdaf5ad 100644
--- a/gcc/testsuite/gcc.target/arm/lto/pr96939_1.c
+++ b/gcc/testsuite/gcc.target/arm/lto/pr96939_1.c
@@ -1,5 +1,5 @@
 /* PR target/96939 */
-/* { dg-options "-march=armv8-a+crc" } */
+/* { dg-options "-march=armv8-a+simd+crc" } */
 
 #include <arm_acle.h>
 

[committed 09/22] arm: testsuite: tidy up pr65647-2.c pre-checks.

[Richard Earnshaw]

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


Another case where we can make better use of the infrastructure to
improve the compatibility of this test.

gcc/testsuite:

	* gcc.target/arm/pr65647-2.c: Use dg-add-options to manage target
	flags.
---
 gcc/testsuite/gcc.target/arm/pr65647-2.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0009-arm-testsuite-tidy-up-pr65647-2.c-pre-checks.patch --]
[-- Type: text/x-patch; name="0009-arm-testsuite-tidy-up-pr65647-2.c-pre-checks.patch", Size: 493 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/pr65647-2.c b/gcc/testsuite/gcc.target/arm/pr65647-2.c
index e3978e512ea..79637bfd9d7 100644
--- a/gcc/testsuite/gcc.target/arm/pr65647-2.c
+++ b/gcc/testsuite/gcc.target/arm/pr65647-2.c
@@ -1,6 +1,7 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target arm_arch_v6_arm_ok } */
-/* { dg-options "-O3 -marm -march=armv6 -std=c99" } */
+/* { dg-options "-O3 -std=c99" } */
+/* { dg-add-options arm_arch_v6_arm } */
 
 typedef struct {
   int i;

[committed 10/22] arm: testsuite: improve compatibility of arm/pr78353-*.c

[Richard Earnshaw]

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


Again, use the infrastructure available to improve the compatibility
of these tests.

gcc/testsuite:

	* gcc.target/arm/pr78353-1.c: Use dg-add-options to manage target
	flags.
	* gcc.target/arm/pr78353-2.c: Likewise.
---
 gcc/testsuite/gcc.target/arm/pr78353-1.c | 3 ++-
 gcc/testsuite/gcc.target/arm/pr78353-2.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0010-arm-testsuite-improve-compatibility-of-arm-pr78353-..patch --]
[-- Type: text/x-patch; name="0010-arm-testsuite-improve-compatibility-of-arm-pr78353-..patch", Size: 1098 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/pr78353-1.c b/gcc/testsuite/gcc.target/arm/pr78353-1.c
index a107e300269..56480774ce4 100644
--- a/gcc/testsuite/gcc.target/arm/pr78353-1.c
+++ b/gcc/testsuite/gcc.target/arm/pr78353-1.c
@@ -1,6 +1,7 @@
 /* { dg-do link }  */
 /* { dg-require-effective-target arm_arch_v7a_multilib } */
-/* { dg-options "-march=armv7-a -mthumb -O2 -flto -Wa,-mimplicit-it=always" }  */
+/* { dg-options "-mthumb -O2 -flto -Wa,-mimplicit-it=always" }  */
+/* { dg-add-options arm_arch_v7a } */
 
 int main(int x)
 {
diff --git a/gcc/testsuite/gcc.target/arm/pr78353-2.c b/gcc/testsuite/gcc.target/arm/pr78353-2.c
index 2589e6135aa..c070d7275bc 100644
--- a/gcc/testsuite/gcc.target/arm/pr78353-2.c
+++ b/gcc/testsuite/gcc.target/arm/pr78353-2.c
@@ -1,6 +1,7 @@
 /* { dg-do link }  */
 /* { dg-require-effective-target arm_arch_v7a_multilib } */
-/* { dg-options "-march=armv7-a -mthumb -O2 -flto -Wa,-mimplicit-it=always,-mthumb" }  */
+/* { dg-options "-mthumb -O2 -flto -Wa,-mimplicit-it=always,-mthumb" }  */
+/* { dg-add-options arm_arch_v7a } */
 
 int main(int x)
 {

[committed 11/22] arm: testsuite: improve compatibility of pr88648-asm-syntax-unified.c

[Richard Earnshaw]

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


Fix another test that was trying to set the architecture directly
rather than using the infrastructure as intended.

gcc/testsuite:

	* gcc.target/arm/pr88648-asm-syntax-unified.c: It isn't necessary
	to try to override the architecture flags specified by arm_arch_v7a.
---
 gcc/testsuite/gcc.target/arm/pr88648-asm-syntax-unified.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0011-arm-testsuite-improve-compatibility-of-pr88648-asm-s.patch --]
[-- Type: text/x-patch; name="0011-arm-testsuite-improve-compatibility-of-pr88648-asm-s.patch", Size: 621 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/pr88648-asm-syntax-unified.c b/gcc/testsuite/gcc.target/arm/pr88648-asm-syntax-unified.c
index 251b4d5bc9d..53d0bb053fc 100644
--- a/gcc/testsuite/gcc.target/arm/pr88648-asm-syntax-unified.c
+++ b/gcc/testsuite/gcc.target/arm/pr88648-asm-syntax-unified.c
@@ -1,8 +1,8 @@
 /* Test for unified syntax assembly generation.  */
 /* { dg-do compile } */
 /* { dg-require-effective-target arm_arch_v7a_ok } */
+/* { dg-options "-marm -masm-syntax-unified" } */
 /* { dg-add-options arm_arch_v7a } */
-/* { dg-options "-marm -march=armv7-a -masm-syntax-unified" } */
 
 void test ()
 {

[committed 12/22] arm: testsuite: improve compatibility of pragma_arch_attribute*.c

[Richard Earnshaw]

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


These tests use pragmas adn attributes to change the architecture.
Sometimes they simply add a feature using "+crc", but other times they
try to completely reset the architecture using "arch=armv8-a+crc".
The latter fails on a hard-float ABI with -mfpu=auto because it also
clears the FP capability.  Fix by adding +simd when the full
architecture is specified.

gcc/testsuite:

	* gcc.target/arm/pragma_arch_attribute.c: Add +simd to pragmas that
	set an explicit architecture.
	* gcc.target/arm/pragma_arch_attribute_2.c: Likewise.
	* gcc.target/arm/pragma_arch_attribute_3.c: Likewise.
---
 gcc/testsuite/gcc.target/arm/pragma_arch_attribute.c   | 6 +++---
 gcc/testsuite/gcc.target/arm/pragma_arch_attribute_2.c | 2 +-
 gcc/testsuite/gcc.target/arm/pragma_arch_attribute_3.c | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0012-arm-testsuite-improve-compatibility-of-pragma_arch_a.patch --]
[-- Type: text/x-patch; name="0012-arm-testsuite-improve-compatibility-of-pragma_arch_a.patch", Size: 2110 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/pragma_arch_attribute.c b/gcc/testsuite/gcc.target/arm/pragma_arch_attribute.c
index a06dbf04037..a5e1edad3a4 100644
--- a/gcc/testsuite/gcc.target/arm/pragma_arch_attribute.c
+++ b/gcc/testsuite/gcc.target/arm/pragma_arch_attribute.c
@@ -10,7 +10,7 @@
 #endif
 
 #pragma GCC push_options
-#pragma GCC target ("arch=armv8-a+crc")
+#pragma GCC target ("arch=armv8-a+simd+crc")
 #ifndef __ARM_FEATURE_CRC32
 # error "__ARM_FEATURE_CRC32 is not defined in push 1."
 #endif
@@ -41,7 +41,7 @@ void test_crc_unknown_ok_attr_1 ()
 # error "__ARM_FEATURE_CRC32 is defined after attribute set 1."
 #endif
 
-__attribute__((target("arch=armv8-a+crc")))
+__attribute__((target("arch=armv8-a+simd+crc")))
 void test_crc_unknown_ok_attr_2 ()
 {
 	__crc32b (0, 0);
@@ -51,4 +51,4 @@ void test_crc_unknown_ok_attr_2 ()
 # error "__ARM_FEATURE_CRC32 is defined after attribute set 2."
 #endif
 
-#pragma GCC reset_options
\ No newline at end of file
+#pragma GCC reset_options
diff --git a/gcc/testsuite/gcc.target/arm/pragma_arch_attribute_2.c b/gcc/testsuite/gcc.target/arm/pragma_arch_attribute_2.c
index 2e8e385774b..189af170096 100644
--- a/gcc/testsuite/gcc.target/arm/pragma_arch_attribute_2.c
+++ b/gcc/testsuite/gcc.target/arm/pragma_arch_attribute_2.c
@@ -8,7 +8,7 @@
 
 extern uint32_t bar();
 
-__attribute__((target("arch=armv8-a+crc"))) uint32_t crc32cw(uint32_t crc, uint32_t val)
+__attribute__((target("arch=armv8-a+simd+crc"))) uint32_t crc32cw(uint32_t crc, uint32_t val)
 {
     uint32_t res;
     asm("crc32cw %0, %1, %2" : "=r"(res) : "r"(crc), "r"(val));
diff --git a/gcc/testsuite/gcc.target/arm/pragma_arch_attribute_3.c b/gcc/testsuite/gcc.target/arm/pragma_arch_attribute_3.c
index 3714812cf26..eb7f990477b 100644
--- a/gcc/testsuite/gcc.target/arm/pragma_arch_attribute_3.c
+++ b/gcc/testsuite/gcc.target/arm/pragma_arch_attribute_3.c
@@ -9,7 +9,7 @@
 extern uint32_t bar();
 
 #pragma GCC push_options
-#pragma GCC target("arch=armv8-a+crc")
+#pragma GCC target("arch=armv8-a+simd+crc")
 uint32_t crc32cw(uint32_t crc, uint32_t val)
 {
     uint32_t res;

[committed 13/22] arm: testsuite: improve compatibility of pragma_arch_switch_2.c

[Richard Earnshaw]

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


This test was explicitly setting the architecture on the command-line and
in the body of the test.  In both cases this causes problems with the auto
FPU setting.  Fix by using the testsuite infrastructure correctly and by
adding +fp to the pragma.

gcc/testsuite:

	* gcc.target/arm/pragma_arch_switch_2.c: Use testsuite infrastructure
	to set the architecture flags.  Add +fp to the pragma that changes the
	architecture.
---
 gcc/testsuite/gcc.target/arm/pragma_arch_switch_2.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0013-arm-testsuite-improve-compatibility-of-pragma_arch_s.patch --]
[-- Type: text/x-patch; name="0013-arm-testsuite-improve-compatibility-of-pragma_arch_s.patch", Size: 730 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/pragma_arch_switch_2.c b/gcc/testsuite/gcc.target/arm/pragma_arch_switch_2.c
index 5080d2c7a91..567943bd8ed 100644
--- a/gcc/testsuite/gcc.target/arm/pragma_arch_switch_2.c
+++ b/gcc/testsuite/gcc.target/arm/pragma_arch_switch_2.c
@@ -3,9 +3,10 @@
 /* { dg-do assemble } */
 /* { dg-require-effective-target arm_arm_ok } */
 /* { dg-require-effective-target arm_arch_v5te_arm_ok } */
-/* { dg-additional-options "-Wall -O2 -march=armv5te -std=gnu99 -marm" } */
+/* { dg-additional-options "-Wall -O2 -std=gnu99" } */
+/* { dg-add-options arm_arch_v5te_arm } */
 
-#pragma GCC target ("arch=armv6")
+#pragma GCC target ("arch=armv6+fp")
 int test_assembly (int hi, int lo)
 {
    int res;

[committed 14/22] arm: testsuite: modernize framework usage for arm/scd42-2.c

[Richard Earnshaw]

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


Make this test more useful by using dg-require-effective-target/
dg-add-options.

gcc/testsuite:

	* gcc.target/arm/scd42-2.c: Use modern dg- flags.
---
 gcc/testsuite/gcc.target/arm/scd42-2.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0014-arm-testsuite-modernize-framework-usage-for-arm-scd4.patch --]
[-- Type: text/x-patch; name="0014-arm-testsuite-modernize-framework-usage-for-arm-scd4.patch", Size: 988 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/scd42-2.c b/gcc/testsuite/gcc.target/arm/scd42-2.c
index 3c9768d22d9..cd416885a80 100644
--- a/gcc/testsuite/gcc.target/arm/scd42-2.c
+++ b/gcc/testsuite/gcc.target/arm/scd42-2.c
@@ -1,11 +1,8 @@
 /* Verify that mov is preferred on XScale for loading a 2 byte constant. */
 /* { dg-do compile } */
-/* { dg-skip-if "Test is specific to the Xscale" { arm*-*-* } { "-march=*" } { "-march=xscale" } } */
-/* { dg-skip-if "Test is specific to the Xscale" { arm*-*-* } { "-mcpu=*" } { "-mcpu=xscale" } } */
-/* { dg-skip-if "Test is specific to ARM mode" { arm*-*-* } { "-mthumb" } { "" } } */
-/* { dg-require-effective-target arm32 } */
-/* { dg-require-effective-target arm_arch_v5te_arm_ok } */
-/* { dg-options "-mcpu=xscale -O -marm" } */
+/* { dg-require-effective-target arm_arch_xscale_arm_ok } */
+/* { dg-options "-O" } */
+/* { dg-add-options arm_arch_xscale_arm } */
 
 unsigned load2(void) __attribute__ ((naked));
 unsigned load2(void)

[committed 15/22] arm: testsuite: improve compatibility of ftest-armv7m-thumb.c

[Richard Earnshaw]

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


This test is specific to armv7m cores which do not support hardware
floating-point.  We can improve its compatibility by having the default
options for this core specify -mfloat-abi=soft.

gcc/testsuite:

	* lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok):
	Use soft-float ABI for armv7m.
	* gcc.target/arm/ftest-armv7m-thumb.c: Use dg-require-effective-target
	to check flag compatibility.
---
 gcc/testsuite/gcc.target/arm/ftest-armv7m-thumb.c | 3 +--
 gcc/testsuite/lib/target-supports.exp             | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0015-arm-testsuite-improve-compatibility-of-ftest-armv7m-.patch --]
[-- Type: text/x-patch; name="0015-arm-testsuite-improve-compatibility-of-ftest-armv7m-.patch", Size: 1288 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/ftest-armv7m-thumb.c b/gcc/testsuite/gcc.target/arm/ftest-armv7m-thumb.c
index 363b48b7516..ba1985f5b0d 100644
--- a/gcc/testsuite/gcc.target/arm/ftest-armv7m-thumb.c
+++ b/gcc/testsuite/gcc.target/arm/ftest-armv7m-thumb.c
@@ -1,6 +1,5 @@
 /* { dg-do compile } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-march=*" } { "-march=arm7-m" } } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" } { "" } } */
+/* { dg-require-effective-target arm_arch_v7m_ok }
 /* { dg-options "-mthumb" } */
 /* { dg-add-options arm_arch_v7m } */
 
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 9d2958626ad..316e34a34be 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5425,7 +5425,7 @@ foreach { armfunc armflag armdefs } {
 	v6m "-march=armv6-m -mthumb -mfloat-abi=soft" __ARM_ARCH_6M__
 	v7a "-march=armv7-a+fp" __ARM_ARCH_7A__
 	v7r "-march=armv7-r+fp" __ARM_ARCH_7R__
-	v7m "-march=armv7-m -mthumb" __ARM_ARCH_7M__
+	v7m "-march=armv7-m -mthumb -mfloat-abi=soft" __ARM_ARCH_7M__
 	v7em "-march=armv7e-m+fp -mthumb" __ARM_ARCH_7EM__
 	v7ve "-march=armv7ve+fp -marm"
 		"__ARM_ARCH_7A__ && __ARM_FEATURE_IDIV"

[committed 16/22] arm: testsuite: improve compatibility of gcc.target/arm/macro_defs*.c

[Richard Earnshaw]

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


Convert these tests to use dg-add-options for increased compatibilty.
Since they also result in an empty translation unit, override the
default testsuite options.

gcc/testsuite:

	* gcc.target/arm/macro_defs0.c: Use dg-effective-target and
	dg-add-options.
	* gcc.target/arm/macro_defs1.c: Likewise.
	* gcc.target/arm/macro_defs2.c: Likewise.
---
 gcc/testsuite/gcc.target/arm/macro_defs0.c | 7 +++----
 gcc/testsuite/gcc.target/arm/macro_defs1.c | 6 ++----
 gcc/testsuite/gcc.target/arm/macro_defs2.c | 6 ++----
 3 files changed, 7 insertions(+), 12 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0016-arm-testsuite-improve-compatibility-of-gcc.target-ar.patch --]
[-- Type: text/x-patch; name="0016-arm-testsuite-improve-compatibility-of-gcc.target-ar.patch", Size: 2225 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/macro_defs0.c b/gcc/testsuite/gcc.target/arm/macro_defs0.c
index 684d49ffafa..17fd157452e 100644
--- a/gcc/testsuite/gcc.target/arm/macro_defs0.c
+++ b/gcc/testsuite/gcc.target/arm/macro_defs0.c
@@ -1,8 +1,7 @@
 /* { dg-do compile } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-march=*" } { "-march=armv7-m" } } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-mfloat-abi=*" } { "-mfloat-abi=soft" } } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" } { "" } } */
-/* { dg-options "-march=armv7-m -mcpu=cortex-m3 -mfloat-abi=soft -mthumb" } */
+/* { dg-require-effective-target arm_arch_v7m_ok } */
+/* { dg-options "" } */
+/* { dg-add-options arm_arch_v7m } */
 
 #ifdef __ARM_FP
 #error __ARM_FP should not be defined
diff --git a/gcc/testsuite/gcc.target/arm/macro_defs1.c b/gcc/testsuite/gcc.target/arm/macro_defs1.c
index 655ba9334f3..bd22154321e 100644
--- a/gcc/testsuite/gcc.target/arm/macro_defs1.c
+++ b/gcc/testsuite/gcc.target/arm/macro_defs1.c
@@ -1,10 +1,8 @@
 /* { dg-do compile } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-march=*" } { "-march=armv6-m" } } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" } { "" } } */
 /* { dg-require-effective-target arm_arch_v6m_ok } */
-/* { dg-options "-march=armv6-m -mthumb" } */
+/* { dg-options "" } */
+/* { dg-add-options arm_arch_v6m } */
 
 #ifdef __ARM_NEON_FP
 #error __ARM_NEON_FP should not be defined
 #endif
-
diff --git a/gcc/testsuite/gcc.target/arm/macro_defs2.c b/gcc/testsuite/gcc.target/arm/macro_defs2.c
index 9a960423562..a26fc237611 100644
--- a/gcc/testsuite/gcc.target/arm/macro_defs2.c
+++ b/gcc/testsuite/gcc.target/arm/macro_defs2.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
-/* { dg-options "-march=armv7ve -mcpu=cortex-a15 -mfpu=neon-vfpv4" } */
-/* { dg-add-options arm_neon } */
 /* { dg-require-effective-target arm_neon_ok } */
+/* { dg-options "" } */
+/* { dg-add-options arm_neon } */
 
 #ifndef __ARM_NEON_FP
 #error  __ARM_NEON_FP is not defined but should be
@@ -10,5 +10,3 @@
 #ifndef __ARM_FP
 #error  __ARM_FP is not defined but should be
 #endif
-
-

[committed 17/22] arm: testsuite: improve compatibility of gcc.target/arm/optional_thumb-*.c

[Richard Earnshaw]

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


These tests deliberately pass invalid option combinations to check
that the compiler is generating the correct diagnostic.  Nevertheless,
we can improve their compatibility with other testsuite options.  For
optional_thumb-1.c we use a soft-float ABI, while for
optional_thumb2.c we use arm_arch_v7em as the target architecture,
then set the architecture manually.

gcc/testsuite:

	* gcc.target/arm/optional_thumb-1.c: Force a soft-float ABI.
	* gcc.target/arm/optional_thumb-3.c: Check for armv7e-m compatibility,
	then set the architecture explicitly.
---
 gcc/testsuite/gcc.target/arm/optional_thumb-1.c | 2 +-
 gcc/testsuite/gcc.target/arm/optional_thumb-3.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0017-arm-testsuite-improve-compatibility-of-gcc.target-ar.patch --]
[-- Type: text/x-patch; name="0017-arm-testsuite-improve-compatibility-of-gcc.target-ar.patch", Size: 1374 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/optional_thumb-1.c b/gcc/testsuite/gcc.target/arm/optional_thumb-1.c
index 99cb0c3f33b..90d9ada6ade 100644
--- a/gcc/testsuite/gcc.target/arm/optional_thumb-1.c
+++ b/gcc/testsuite/gcc.target/arm/optional_thumb-1.c
@@ -1,6 +1,6 @@
 /* { dg-do compile { target { ! default_mode } } } */
 /* { dg-skip-if "-marm/-mthumb/-march/-mcpu given" { *-*-* } { "-marm" "-mthumb" "-march=*" "-mcpu=*" } } */
-/* { dg-options "-march=armv6-m" } */
+/* { dg-options "-march=armv6-m -mfloat-abi=soft" } */
 
 /* Check that -mthumb is not needed when compiling for a Thumb-only target.  */
 
diff --git a/gcc/testsuite/gcc.target/arm/optional_thumb-3.c b/gcc/testsuite/gcc.target/arm/optional_thumb-3.c
index d9150e09e47..a6c661ac031 100644
--- a/gcc/testsuite/gcc.target/arm/optional_thumb-3.c
+++ b/gcc/testsuite/gcc.target/arm/optional_thumb-3.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target arm_cortex_m } */
+/* { dg-require-effective-target arm_arch_v7em_ok } */
 /* { dg-skip-if "-mthumb given" { *-*-* } { "-mthumb" } } */
-/* { dg-options "-marm" } */
+/* { dg-options "-march=armv7e-m+fp -marm" } */
 /* { dg-error "target CPU does not support ARM mode" "missing error with -marm on Thumb-only targets" { target *-*-* } 0 } */
 
 /* Check that -marm gives an error when compiling for a Thumb-only target.  */

[committed 18/22] arm: testsuite: improve compatibility of gcc.target/arm/pr19599.c

[Richard Earnshaw]

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


Add +fp to the architecture specification, so that -mfpu=auto works
with the hard-float ABI.

gcc/testsuite:

	* gcc.target/arm/pr19599.c: Add +fp to the architecture.
---
 gcc/testsuite/gcc.target/arm/pr19599.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0018-arm-testsuite-improve-compatibility-of-gcc.target-ar.patch --]
[-- Type: text/x-patch; name="0018-arm-testsuite-improve-compatibility-of-gcc.target-ar.patch", Size: 598 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/pr19599.c b/gcc/testsuite/gcc.target/arm/pr19599.c
index a536548442f..d2f15ae4499 100644
--- a/gcc/testsuite/gcc.target/arm/pr19599.c
+++ b/gcc/testsuite/gcc.target/arm/pr19599.c
@@ -1,6 +1,6 @@
 /* { dg-skip-if "need at least armv5te" { *-*-* } { "-march=armv[234]*" "-mthumb" } { "" } } */
 /* { dg-skip-if "FDPIC does not support armv5te" { arm*-*-uclinuxfdpiceabi } "*" "" } */
-/* { dg-options "-O2 -march=armv5te -marm" }  */
+/* { dg-options "-O2 -march=armv5te+fp -marm" }  */
 /* { dg-final { scan-assembler "bx" } } */
 
 int (*indirect_func)();

[committed 19/22] arm: testsuite: improve compatibility of gcc.target/arm/pr59575.c

[Richard Earnshaw]

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


Use dg-require-effective-target/dg-add-options to improve
compatibility of this test with various compiler configurations.

gcc/testsuite:

	* gcc.target/arm/pr59575.c: Use dg-require-effective-target and
	dg-add-options.
---
 gcc/testsuite/gcc.target/arm/pr59575.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0019-arm-testsuite-improve-compatibility-of-gcc.target-ar.patch --]
[-- Type: text/x-patch; name="0019-arm-testsuite-improve-compatibility-of-gcc.target-ar.patch", Size: 598 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/pr59575.c b/gcc/testsuite/gcc.target/arm/pr59575.c
index cc49be3d61f..27d7d40526e 100644
--- a/gcc/testsuite/gcc.target/arm/pr59575.c
+++ b/gcc/testsuite/gcc.target/arm/pr59575.c
@@ -1,7 +1,9 @@
 /* PR target/59575 */
 /* { dg-do compile } */
+/* { dg-require-effective-target arm_arch_v7a_ok } */
 /* { dg-skip-if "-mpure-code supports M-profile only" { *-*-* } { "-mpure-code" } } */
-/* { dg-options "-Os -g -march=armv7-a" } */
+/* { dg-options "-Os -g" } */
+/* { dg-add-options arm_arch_v7a } */
 
 void foo (int *);
 int *bar (int, long long, int);

[committed 20/22] testsuite: arm: tighten up mode-specific ISA tests

[Richard Earnshaw]

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


Some of the standard Arm architecture tests require the test to use a
specific instruction set (arm or thumb).  But although the framework
was checking that the flag was accepted, it wasn't checking that the
flag wasn't somehow being override (eg by run-specific options).  We
can improve these tests easily by checking whether or not __thumb-_ is
defined.

gcc/testsuite:

	* lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok):
	For instruction-set specific tests, check that __thumb__ is, or
	isn't defined as appropriate.
---
 gcc/testsuite/lib/target-supports.exp | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0020-testsuite-arm-tighten-up-mode-specific-ISA-tests.patch --]
[-- Type: text/x-patch; name="0020-testsuite-arm-tighten-up-mode-specific-ISA-tests.patch", Size: 2715 bytes --]

diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 316e34a34be..3d504d26164 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5403,25 +5403,25 @@ proc check_effective_target_arm_fp16_hw { } {
 foreach { armfunc armflag armdefs } {
 	v4 "-march=armv4 -marm" __ARM_ARCH_4__
 	v4t "-march=armv4t -mfloat-abi=softfp" __ARM_ARCH_4T__
-	v4t_arm "-march=armv4t -marm" __ARM_ARCH_4T__
-	v4t_thumb "-march=armv4t -mthumb -mfloat-abi=softfp" __ARM_ARCH_4T__
+	v4t_arm "-march=armv4t -marm" "__ARM_ARCH_4T__ && !__thumb__"
+	v4t_thumb "-march=armv4t -mthumb -mfloat-abi=softfp" "__ARM_ARCH_4T__ && __thumb__"
 	v5t "-march=armv5t -mfloat-abi=softfp" __ARM_ARCH_5T__
-	v5t_arm "-march=armv5t -marm" __ARM_ARCH_5T__
-	v5t_thumb "-march=armv5t -mthumb -mfloat-abi=softfp" __ARM_ARCH_5T__
+	v5t_arm "-march=armv5t -marm" "__ARM_ARCH_5T__ && !__thumb__"
+	v5t_thumb "-march=armv5t -mthumb -mfloat-abi=softfp" "__ARM_ARCH_5T__ && __thumb__"
 	v5te "-march=armv5te+fp -mfloat-abi=softfp" __ARM_ARCH_5TE__
-	v5te_arm "-march=armv5te+fp -marm" __ARM_ARCH_5TE__
-	v5te_thumb "-march=armv5te+fp -mthumb -mfloat-abi=softfp" __ARM_ARCH_5TE__
-	xscale_arm "-mcpu=xscale -mfloat-abi=soft -marm" __XSCALE__
+	v5te_arm "-march=armv5te+fp -marm" "__ARM_ARCH_5TE__ && !__thumb__"
+	v5te_thumb "-march=armv5te+fp -mthumb -mfloat-abi=softfp" "__ARM_ARCH_5TE__ && __thumb__"
+	xscale_arm "-mcpu=xscale -mfloat-abi=soft -marm" "__XSCALE__ && !__thumb__"
 	v6 "-march=armv6+fp -mfloat-abi=softfp" __ARM_ARCH_6__
-	v6_arm "-march=armv6+fp -marm" __ARM_ARCH_6__
-	v6_thumb "-march=armv6+fp -mthumb -mfloat-abi=softfp" __ARM_ARCH_6__
+	v6_arm "-march=armv6+fp -marm" "__ARM_ARCH_6__ && !__thumb__"
+	v6_thumb "-march=armv6+fp -mthumb -mfloat-abi=softfp" "__ARM_ARCH_6__ && __thumb__"
 	v6k "-march=armv6k+fp -mfloat-abi=softfp" __ARM_ARCH_6K__
-	v6k_arm "-march=armv6k+fp -marm" __ARM_ARCH_6K__
-	v6k_thumb "-march=armv6k+fp -mthumb -mfloat-abi=softfp" __ARM_ARCH_6K__
+	v6k_arm "-march=armv6k+fp -marm" "__ARM_ARCH_6K__ && !__thumb__"
+	v6k_thumb "-march=armv6k+fp -mthumb -mfloat-abi=softfp" "__ARM_ARCH_6K__ && __thumb__"
 	v6t2 "-march=armv6t2+fp" __ARM_ARCH_6T2__
 	v6z "-march=armv6z+fp -mfloat-abi=softfp" __ARM_ARCH_6Z__
-	v6z_arm "-march=armv6z+fp -marm" __ARM_ARCH_6Z__
-	v6z_thumb "-march=armv6z+fp -mthumb -mfloat-abi=softfp" __ARM_ARCH_6Z__
+	v6z_arm "-march=armv6z+fp -marm" "__ARM_ARCH_6Z__ && !__thumb__"
+	v6z_thumb "-march=armv6z+fp -mthumb -mfloat-abi=softfp" "__ARM_ARCH_6Z__ && __thumb__"
 	v6m "-march=armv6-m -mthumb -mfloat-abi=soft" __ARM_ARCH_6M__
 	v7a "-march=armv7-a+fp" __ARM_ARCH_7A__
 	v7r "-march=armv7-r+fp" __ARM_ARCH_7R__

[committed 21/22] arm: testsuite: fix some more architecture tests

[Richard Earnshaw]

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


This fixes a bunch more tests that try to override the default architecture;
some partially used the framework for doing this, others just blindly
added a -march option, which was doomed to cause problems.  In most cases
we can now run these tests regardless of the users testing options and
the base compiler configuration.

gcc/testsuite:

	* lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok):
	Add test for v7a_arm.
	* gcc.target/arm/pr60650-2.c: Use require-effective-target and
	add-options.
	* gcc.target/arm/pr60657.c: Likewise.
	* gcc.target/arm/pr60663.c: Likewise.
	* gcc.target/arm/pr81863.c: Likewise.
	* gcc.target/arm/pr97969.c: Likewise.
	* gcc.target/arm/pr98931.c: Likewise.
	* gcc.target/arm/tail-long-call.c: Likewise.
---
 gcc/testsuite/gcc.target/arm/pr60650-2.c      | 4 +++-
 gcc/testsuite/gcc.target/arm/pr60657.c        | 4 +++-
 gcc/testsuite/gcc.target/arm/pr60663.c        | 4 +++-
 gcc/testsuite/gcc.target/arm/pr81863.c        | 4 +++-
 gcc/testsuite/gcc.target/arm/pr97969.c        | 4 +++-
 gcc/testsuite/gcc.target/arm/pr98931.c        | 5 +++--
 gcc/testsuite/gcc.target/arm/tail-long-call.c | 6 ++++--
 gcc/testsuite/lib/target-supports.exp         | 1 +
 8 files changed, 23 insertions(+), 9 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0021-arm-testsuite-fix-some-more-architecture-tests.patch --]
[-- Type: text/x-patch; name="0021-arm-testsuite-fix-some-more-architecture-tests.patch", Size: 5208 bytes --]

diff --git a/gcc/testsuite/gcc.target/arm/pr60650-2.c b/gcc/testsuite/gcc.target/arm/pr60650-2.c
index c44d7b5f9d2..36d57f08676 100644
--- a/gcc/testsuite/gcc.target/arm/pr60650-2.c
+++ b/gcc/testsuite/gcc.target/arm/pr60650-2.c
@@ -1,6 +1,8 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target arm_arch_v7a_ok } */
 /* { dg-skip-if "-mpure-code supports M-profile only" { *-*-* } { "-mpure-code" } } */
-/* { dg-options "-O2 -fno-omit-frame-pointer -march=armv7-a" } */
+/* { dg-options "-O2 -fno-omit-frame-pointer" } */
+/* { dg-add-options arm_arch_v7a } */
 
 int a, h, j;
 long long d, e, i;
diff --git a/gcc/testsuite/gcc.target/arm/pr60657.c b/gcc/testsuite/gcc.target/arm/pr60657.c
index ca121526bb3..e608dd39355 100644
--- a/gcc/testsuite/gcc.target/arm/pr60657.c
+++ b/gcc/testsuite/gcc.target/arm/pr60657.c
@@ -1,6 +1,8 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target arm_arch_v7a_ok } */
 /* { dg-skip-if "-mpure-code supports M-profile only" { *-*-* } { "-mpure-code" } } */
-/* { dg-options "-O2 -march=armv7-a" } */
+/* { dg-options "-O2" } */
+/* { dg-add-options arm_arch_v7a } */
 
 
 void foo (void);
diff --git a/gcc/testsuite/gcc.target/arm/pr60663.c b/gcc/testsuite/gcc.target/arm/pr60663.c
index 8d76d79301a..bb48d7fdae8 100644
--- a/gcc/testsuite/gcc.target/arm/pr60663.c
+++ b/gcc/testsuite/gcc.target/arm/pr60663.c
@@ -1,7 +1,9 @@
 /* PR rtl-optimization/60663 */
 /* { dg-do compile } */
+/* { dg-require-effective-target arm_arch_v7a_ok } */
 /* { dg-skip-if "-mpure-code supports M-profile only" { *-*-* } { "-mpure-code" } } */
-/* { dg-options "-O2 -march=armv7-a" } */
+/* { dg-options "-O2" } */
+/* { dg-add-options arm_arch_v7a } */
 
 int
 foo (void)
diff --git a/gcc/testsuite/gcc.target/arm/pr81863.c b/gcc/testsuite/gcc.target/arm/pr81863.c
index 85bfab144c0..a96f3b58411 100644
--- a/gcc/testsuite/gcc.target/arm/pr81863.c
+++ b/gcc/testsuite/gcc.target/arm/pr81863.c
@@ -1,8 +1,10 @@
 /* testsuite/gcc.target/arm/pr48183.c */
 /* { dg-do compile } */
+/* { dg-require-effective-target arm_arch_v7a_arm_ok } */
 /* { dg-skip-if "-mslow-flash-data and -mword-relocations incompatible" { *-*-* } { "-mslow-flash-data" } } */
 /* { dg-skip-if "-mpure-code and -mword-relocations incompatible" { *-*-* } { "-mpure-code" } } */
-/* { dg-options "-O2 -mword-relocations -march=armv7-a -marm" } */
+/* { dg-options "-O2 -mword-relocations" } */
+/* { dg-add-options arm_arch_v7a_arm } */
 /* { dg-final { scan-assembler-not "\[\\t \]+movw" } } */
 
 int a, d, f;
diff --git a/gcc/testsuite/gcc.target/arm/pr97969.c b/gcc/testsuite/gcc.target/arm/pr97969.c
index 714a1d18870..b8c3a23676a 100644
--- a/gcc/testsuite/gcc.target/arm/pr97969.c
+++ b/gcc/testsuite/gcc.target/arm/pr97969.c
@@ -1,5 +1,7 @@
 /* { dg-do compile } */
-/* { dg-options "-std=c99 -fno-omit-frame-pointer -mthumb -w -Os" } */
+/* { dg-require-effective-target arm_arch_v6m_ok } */
+/* { dg-options "-std=c99 -fno-omit-frame-pointer -w -Os" } */
+/* { dg-add-options arm_arch_v6m } */
 
 typedef a[23];
 enum { b };
diff --git a/gcc/testsuite/gcc.target/arm/pr98931.c b/gcc/testsuite/gcc.target/arm/pr98931.c
index 66070ad7298..56f66a3b82f 100644
--- a/gcc/testsuite/gcc.target/arm/pr98931.c
+++ b/gcc/testsuite/gcc.target/arm/pr98931.c
@@ -1,6 +1,7 @@
 /* { dg-do assemble } */
-/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm" "-mcpu=*" } } */
-/* { dg-options "-march=armv8.1-m.main -O3 --param=max-completely-peeled-insns=1300 --save-temps -mthumb" } */
+/* { dg-require-effective-target arm_arch_v8_1m_main_ok } */
+/* { dg-options "-O3 --param=max-completely-peeled-insns=1300 --save-temps" } */
+/* { dg-add-options arm_arch_v8_1m_main } */
 
 extern long long a[][20][26][26][22];
 
diff --git a/gcc/testsuite/gcc.target/arm/tail-long-call.c b/gcc/testsuite/gcc.target/arm/tail-long-call.c
index f70e9cf3938..6a130063fcc 100644
--- a/gcc/testsuite/gcc.target/arm/tail-long-call.c
+++ b/gcc/testsuite/gcc.target/arm/tail-long-call.c
@@ -1,6 +1,8 @@
-/* { dg-skip-if "need at least armv5te" { *-*-* } { "-march=armv[234]*" "-mthumb" } { "" } } */
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_arch_v5te_arm_ok } */
 /* { dg-skip-if "FDPIC does not support tailcall optimization" { arm*-*-uclinuxfdpiceabi } "*" "" } */
-/* { dg-options "-O2 -march=armv5te -marm" } */
+/* { dg-options "-O2" } */
+/* { dg-add-options arm_arch_v5te_arm } */
 /* { dg-final { scan-assembler "bx" } } */
 /* { dg-final { scan-assembler-not "blx" } } */
 
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 3d504d26164..ae43dc97872 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5424,6 +5424,7 @@ foreach { armfunc armflag armdefs } {
 	v6z_thumb "-march=armv6z+fp -mthumb -mfloat-abi=softfp" "__ARM_ARCH_6Z__ && __thumb__"
 	v6m "-march=armv6-m -mthumb -mfloat-abi=soft" __ARM_ARCH_6M__
 	v7a "-march=armv7-a+fp" __ARM_ARCH_7A__
+	v7a_arm "-march=armv7-a+fp -marm" "__ARM_ARCH_7A__ && !__thumb__"
 	v7r "-march=armv7-r+fp" __ARM_ARCH_7R__
 	v7m "-march=armv7-m -mthumb -mfloat-abi=soft" __ARM_ARCH_7M__
 	v7em "-march=armv7e-m+fp -mthumb" __ARM_ARCH_7EM__

[committed 22/22] arm: testsuite: improve compatibility of gcc.dg/debug/pr57351.c

[Richard Earnshaw]

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


This test is arm specific and requires neon.  To improve compatibility
add a new test for armv7-a with neon and use that.

gcc/testsuite:

	* lib/target-supports.exp (v7a_neon): New feature-test target.
	* gcc.dg/debug/pr57351.c: Use it.
---
 gcc/testsuite/gcc.dg/debug/pr57351.c  | 7 +++----
 gcc/testsuite/lib/target-supports.exp | 1 +
 2 files changed, 4 insertions(+), 4 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0022-arm-testsuite-improve-compatibility-of-gcc.dg-debug-.patch --]
[-- Type: text/x-patch; name="0022-arm-testsuite-improve-compatibility-of-gcc.dg-debug-.patch", Size: 1357 bytes --]

diff --git a/gcc/testsuite/gcc.dg/debug/pr57351.c b/gcc/testsuite/gcc.dg/debug/pr57351.c
index 236d74ddedb..50861a4bf88 100644
--- a/gcc/testsuite/gcc.dg/debug/pr57351.c
+++ b/gcc/testsuite/gcc.dg/debug/pr57351.c
@@ -1,8 +1,7 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target arm_neon }  */
-/* { dg-require-effective-target arm_arch_v7a_ok }  */
-/* { dg-options "-std=c99 -Os -g -march=armv7-a" } */
-/* { dg-add-options arm_neon } */
+/* { dg-require-effective-target arm_arch_v7a_neon_ok }  */
+/* { dg-options "-std=c99 -Os -g" } */
+/* { dg-add-options arm_arch_v7a_neon } */
 
 typedef unsigned int size_t;
 typedef int ptrdiff_t;
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index ae43dc97872..43a040e135c 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5425,6 +5425,7 @@ foreach { armfunc armflag armdefs } {
 	v6m "-march=armv6-m -mthumb -mfloat-abi=soft" __ARM_ARCH_6M__
 	v7a "-march=armv7-a+fp" __ARM_ARCH_7A__
 	v7a_arm "-march=armv7-a+fp -marm" "__ARM_ARCH_7A__ && !__thumb__"
+	v7a_neon "-march=armv7-a+simd -mfpu=auto -mfloat-abi=softfp" "__ARM_ARCH_7A__ && __ARM_NEON__"
 	v7r "-march=armv7-r+fp" __ARM_ARCH_7R__
 	v7m "-march=armv7-m -mthumb -mfloat-abi=soft" __ARM_ARCH_7M__
 	v7em "-march=armv7e-m+fp -mthumb" __ARM_ARCH_7EM__

Re: [committed 01/22] arm: testsuite: correctly detect armv6t2 hardware for acle execution tests

[Christophe Lyon]

Hi,

On 11/13/23 15:26, Richard Earnshaw wrote:
> diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
> index 1a7bea96c1e..d414cddf4dc 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -5590,6 +5590,24 @@ proc check_effective_target_arm_thumb1_cbz_ok {} {
>       }
>   }
>   
> +# Return 1 if this is an Arm target which supports the Armv6t2 extensions.
> +# This can be either in Arm state or in Thumb state.
> +
> +proc check_effective_target_arm_arch_v6t2_hw_ok {} {
> +    if [check_effective_target_arm_thumb1_ok] {

Why arm_thumb1_ok and not arm_arch_v6t2_ok ?

Thanks,

Christophe


> +	return [check_no_compiler_messages arm_movt object {
> +	    int
> +	    main (void)
> +	    {
> +	      asm ("bfc r0, #1, #2");
> +	      return 0;
> +	    }
> +	} [add_options_for_arm_arch_v6t2 ""]]
> +    } else {
> +	return 0
> +    }
> +}
> +
>   # Return 1 if this is an ARM target where ARMv8-M Security Extensions is
>   # available.
>   

Re: [committed 01/22] arm: testsuite: correctly detect armv6t2 hardware for acle execution tests

[Richard Earnshaw]

On 14/11/2023 17:01, Christophe Lyon wrote:
> Hi,
> 
> On 11/13/23 15:26, Richard Earnshaw wrote:
>> diff --git a/gcc/testsuite/lib/target-supports.exp 
>> b/gcc/testsuite/lib/target-supports.exp
>> index 1a7bea96c1e..d414cddf4dc 100644
>> --- a/gcc/testsuite/lib/target-supports.exp
>> +++ b/gcc/testsuite/lib/target-supports.exp
>> @@ -5590,6 +5590,24 @@ proc check_effective_target_arm_thumb1_cbz_ok {} {
>>       }
>>   }
>> +# Return 1 if this is an Arm target which supports the Armv6t2 
>> extensions.
>> +# This can be either in Arm state or in Thumb state.
>> +
>> +proc check_effective_target_arm_arch_v6t2_hw_ok {} {
>> +    if [check_effective_target_arm_thumb1_ok] {
> 
> Why arm_thumb1_ok and not arm_arch_v6t2_ok ?

Because I cloned the function immediately above, then only half fixed 
it.  That's not the only bug though.  It never tries to run the test 
(object only runs the compiler with '-c', so it stops after assembly), 
which it should if it's checking if the HW can run a test.

Ooops!

I'll fix that.  Thanks for catching.

R.

> 
> Thanks,
> 
> Christophe
> 
> 
>> +    return [check_no_compiler_messages arm_movt object {
>> +        int
>> +        main (void)
>> +        {
>> +          asm ("bfc r0, #1, #2");
>> +          return 0;
>> +        }
>> +    } [add_options_for_arm_arch_v6t2 ""]]
>> +    } else {
>> +    return 0
>> +    }
>> +}
>> +
>>   # Return 1 if this is an ARM target where ARMv8-M Security 
>> Extensions is
>>   # available.

Re: [committed 03/22] arm: testsuite: avoid hard-float ABI incompatibility with -march

[Christophe Lyon]

Hi Richard,

On Mon, 13 Nov 2023 at 15:28, Richard Earnshaw <rearnsha@arm.com> wrote:
>
>
> A number of tests in the gcc testsuite, especially for arm-specific
> targets, add various flags to control the architecture.  These run
> into problems when the compiler is configured with -mfpu=auto if the
> new architecture lacks an architectural feature that implies we have
> floating-point instructions.
>
> The testsuite makes this worse as it falls foul of this requirement in
> the base architecture strings provided by target-supports.exp.
>
> To fix this we add "+fp", or something equivalent to this, to all the
> base architecture specifications.  The feature will be ignored if the
> float ABI is set to soft.
>
> gcc/testsuite:
>
>         * lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok):
>         Add base FPU specifications to all architectures that can support
>         one.
> ---
>  gcc/testsuite/lib/target-supports.exp | 50 +++++++++++++--------------
>  1 file changed, 25 insertions(+), 25 deletions(-)
>

Our CI has detected some regressions with this patch, in particular
when testing for cortex-m55:

with -mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto
and GCC configured with --disable-multilib --with-mode=thumb
--with-arch=armv8.1-m.main+mve.fp+fp.dp --with-float=hard

you can see our logs here:
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/

Thanks,

Christophe

Re: [committed 02/22] arm: testsuite: correctly detect hard_float

[Christophe Lyon]

Hi Richard,


On Mon, 13 Nov 2023 at 15:27, Richard Earnshaw <rearnsha@arm.com> wrote:
>
>
> Add an arm-specific test to check_effective_target_hard_float for
> Arm to handle cases where we only have single-precision FP in hardware.
>
> gcc/testsuite:
>
>         * lib/target-supports.exp (check_effective_target_hard_float): Add
>         arm-specific test.
> ---
>  gcc/testsuite/lib/target-supports.exp | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>

Our CI has detected a problem when testing this patch for cortex-m33:
with -mthumb/-march=armv8-m.main+dsp+fp/-mtune=cortex-m33/-mfloat-abi=hard/-mfpu=auto
and GCC configured with --disable-multilib --with-mode=thumb
--with-cpu=cortex-m33 --with-float=hard

FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c
  -O0  execution test
FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c
  -O1  execution test
FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c
  -O2  execution test
FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c
  -O2 -flto -fno-use-linker-plugin -flto-partition=none  execution
test
FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c
  -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c
  -O3 -g  execution test
FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c
  -Os  execution test

We use qemu for testing. Do these tests pass in your configuration?

Thanks,

Christophe

Re: [committed 02/22] arm: testsuite: correctly detect hard_float

[Richard Earnshaw]

On 20/11/2023 10:41, Christophe Lyon wrote:
> Hi Richard,
> 
> 
> On Mon, 13 Nov 2023 at 15:27, Richard Earnshaw <rearnsha@arm.com> wrote:
>>
>>
>> Add an arm-specific test to check_effective_target_hard_float for
>> Arm to handle cases where we only have single-precision FP in hardware.
>>
>> gcc/testsuite:
>>
>>         * lib/target-supports.exp (check_effective_target_hard_float): Add
>>         arm-specific test.
>> ---
>>  gcc/testsuite/lib/target-supports.exp | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
> 
> Our CI has detected a problem when testing this patch for cortex-m33:
> with 
> -mthumb/-march=armv8-m.main+dsp+fp/-mtune=cortex-m33/-mfloat-abi=hard/-mfpu=auto
> and GCC configured with --disable-multilib --with-mode=thumb
> --with-cpu=cortex-m33 --with-float=hard
> 
> FAIL: 
> gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c
>    -O0  execution test
> FAIL: 
> gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c
>    -O1  execution test
> FAIL: 
> gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c
>    -O2  execution test
> FAIL: 
> gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c
>    -O2 -flto -fno-use-linker-plugin -flto-partition=none  execution
> test
> FAIL: 
> gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c
>    -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  execution test
> FAIL: 
> gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c
>    -O3 -g  execution test
> FAIL: 
> gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c
>    -Os  execution test
> 

I think this technically is a real bug in the port.  This test changes 
the rounding modes, but cortex-m33 only has a single-precision FP unit, 
so single-precision is handled in HW, while double-precision is handled 
in SW.  The soft-float functions don't support changing the rounding 
mode, and certainly not through fesetround(), so we don't get the 
expected results.  I think the test would always have failed, but we 
didn't run it in the past as the default test for HW fp only checked for 
double precision HW.

Fixing the real problem is not trivial though, especially in a mixed 
hard/soft environment.


> We use qemu for testing. Do these tests pass in your configuration?
> 
> Thanks,
> 
> Christophe

R.

Re: [committed 03/22] arm: testsuite: avoid hard-float ABI incompatibility with -march

[Richard Earnshaw]

On 20/11/2023 10:23, Christophe Lyon wrote:
> Hi Richard,
> 
> On Mon, 13 Nov 2023 at 15:28, Richard Earnshaw <rearnsha@arm.com> wrote:
>>
>>
>> A number of tests in the gcc testsuite, especially for arm-specific
>> targets, add various flags to control the architecture.  These run
>> into problems when the compiler is configured with -mfpu=auto if the
>> new architecture lacks an architectural feature that implies we have
>> floating-point instructions.
>>
>> The testsuite makes this worse as it falls foul of this requirement in
>> the base architecture strings provided by target-supports.exp.
>>
>> To fix this we add "+fp", or something equivalent to this, to all the
>> base architecture specifications.  The feature will be ignored if the
>> float ABI is set to soft.
>>
>> gcc/testsuite:
>>
>>         * lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok):
>>         Add base FPU specifications to all architectures that can support
>>         one.
>> ---
>>  gcc/testsuite/lib/target-supports.exp | 50 +++++++++++++--------------
>>  1 file changed, 25 insertions(+), 25 deletions(-)
>>
> 
> Our CI has detected some regressions with this patch, in particular
> when testing for cortex-m55:
> 
> with 
> -mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto
> and GCC configured with --disable-multilib --with-mode=thumb
> --with-arch=armv8.1-m.main+mve.fp+fp.dp --with-float=hard
> 
> you can see our logs here:
> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/ <https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/>
> 
> Thanks,
> 
> Christophe

What exactly am I supposed to be looking at here?  I see no description 
of what those logs represent.  If they are supposed to be before and 
after, then why does the after only run a tiny fraction of the testsuite 
(Running gcc.git~master/gcc/testsuite/gcc.target/arm/arm.exp ...
Running gcc.git~master/gcc/testsuite/gcc.target/arm/cmse/cmse.exp ...
Running gcc.git~master/gcc/testsuite/gcc.target/arm/lto/lto.exp ...)

The logs give no clue as to why the reminder of the testsuite wasn't run.

Please don't make me guess.

R.

Re: [committed 03/22] arm: testsuite: avoid hard-float ABI incompatibility with -march

[Christophe Lyon]

On Mon, 20 Nov 2023 at 13:44, Richard Earnshaw
<Richard.Earnshaw@foss.arm.com> wrote:
>
>
>
> On 20/11/2023 10:23, Christophe Lyon wrote:
> > Hi Richard,
> >
> > On Mon, 13 Nov 2023 at 15:28, Richard Earnshaw <rearnsha@arm.com> wrote:
> >>
> >>
> >> A number of tests in the gcc testsuite, especially for arm-specific
> >> targets, add various flags to control the architecture.  These run
> >> into problems when the compiler is configured with -mfpu=auto if the
> >> new architecture lacks an architectural feature that implies we have
> >> floating-point instructions.
> >>
> >> The testsuite makes this worse as it falls foul of this requirement in
> >> the base architecture strings provided by target-supports.exp.
> >>
> >> To fix this we add "+fp", or something equivalent to this, to all the
> >> base architecture specifications.  The feature will be ignored if the
> >> float ABI is set to soft.
> >>
> >> gcc/testsuite:
> >>
> >>         * lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok):
> >>         Add base FPU specifications to all architectures that can support
> >>         one.
> >> ---
> >>  gcc/testsuite/lib/target-supports.exp | 50 +++++++++++++--------------
> >>  1 file changed, 25 insertions(+), 25 deletions(-)
> >>
> >
> > Our CI has detected some regressions with this patch, in particular
> > when testing for cortex-m55:
> >
> > with
> > -mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto
> > and GCC configured with --disable-multilib --with-mode=thumb
> > --with-arch=armv8.1-m.main+mve.fp+fp.dp --with-float=hard
> >
> > you can see our logs here:
> > https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/ <https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/>
> >
> > Thanks,
> >
> > Christophe
>
> What exactly am I supposed to be looking at here?  I see no description
> of what those logs represent.  If they are supposed to be before and
> after, then why does the after only run a tiny fraction of the testsuite
> (Running gcc.git~master/gcc/testsuite/gcc.target/arm/arm.exp ...
> Running gcc.git~master/gcc/testsuite/gcc.target/arm/cmse/cmse.exp ...
> Running gcc.git~master/gcc/testsuite/gcc.target/arm/lto/lto.exp ...)
>
> The logs give no clue as to why the reminder of the testsuite wasn't run.
>
> Please don't make me guess.
>

Here is a summary with the list of regressions:
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/notify/regressions.sum/*view*/

I thought you'd be able to find your way in the logs above, the .0
files contain the logs of the initial full testsuite run, and .1 ones
contain the logs of the second run of the testsuite, restricted to the
.exp files where we detected regressions. So looking at gcc.log.1.xz
will give you details of the regressions shown in the link above.

Christophe

> R.

Re: [committed 03/22] arm: testsuite: avoid hard-float ABI incompatibility with -march

[Richard Earnshaw]

On 20/11/2023 13:36, Christophe Lyon wrote:
> On Mon, 20 Nov 2023 at 13:44, Richard Earnshaw
> <Richard.Earnshaw@foss.arm.com> wrote:
>>
>>
>>
>> On 20/11/2023 10:23, Christophe Lyon wrote:
>>> Hi Richard,
>>>
>>> On Mon, 13 Nov 2023 at 15:28, Richard Earnshaw <rearnsha@arm.com> wrote:
>>>>
>>>>
>>>> A number of tests in the gcc testsuite, especially for arm-specific
>>>> targets, add various flags to control the architecture.  These run
>>>> into problems when the compiler is configured with -mfpu=auto if the
>>>> new architecture lacks an architectural feature that implies we have
>>>> floating-point instructions.
>>>>
>>>> The testsuite makes this worse as it falls foul of this requirement in
>>>> the base architecture strings provided by target-supports.exp.
>>>>
>>>> To fix this we add "+fp", or something equivalent to this, to all the
>>>> base architecture specifications.  The feature will be ignored if the
>>>> float ABI is set to soft.
>>>>
>>>> gcc/testsuite:
>>>>
>>>>          * lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok):
>>>>          Add base FPU specifications to all architectures that can support
>>>>          one.
>>>> ---
>>>>   gcc/testsuite/lib/target-supports.exp | 50 +++++++++++++--------------
>>>>   1 file changed, 25 insertions(+), 25 deletions(-)
>>>>
>>>
>>> Our CI has detected some regressions with this patch, in particular
>>> when testing for cortex-m55:
>>>
>>> with
>>> -mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto
>>> and GCC configured with --disable-multilib --with-mode=thumb
>>> --with-arch=armv8.1-m.main+mve.fp+fp.dp --with-float=hard
>>>
>>> you can see our logs here:
>>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/ <https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/>
>>>
>>> Thanks,
>>>
>>> Christophe
>>
>> What exactly am I supposed to be looking at here?  I see no description
>> of what those logs represent.  If they are supposed to be before and
>> after, then why does the after only run a tiny fraction of the testsuite
>> (Running gcc.git~master/gcc/testsuite/gcc.target/arm/arm.exp ...
>> Running gcc.git~master/gcc/testsuite/gcc.target/arm/cmse/cmse.exp ...
>> Running gcc.git~master/gcc/testsuite/gcc.target/arm/lto/lto.exp ...)
>>
>> The logs give no clue as to why the reminder of the testsuite wasn't run.
>>
>> Please don't make me guess.
>>
> 
> Here is a summary with the list of regressions:
> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/notify/regressions.sum/*view*/

OK, that's much more useful.  But how was I supposed to know that link 
existed?

> 
> I thought you'd be able to find your way in the logs above, the .0
> files contain the logs of the initial full testsuite run, and .1 ones
> contain the logs of the second run of the testsuite, restricted to the
> .exp files where we detected regressions. So looking at gcc.log.1.xz
> will give you details of the regressions shown in the link above.

There's nothing in the page you sent me to that gives any clue as to how 
to read the logs there.  So my assumption was that the .0 was a before 
run and .1 an after.  Please, if you're going to direct people to the 
log files, provide some way for them to understand what the log files show.

Now, to the specific issues:

Running gcc:gcc.target/arm/arm.exp ...
FAIL: gcc.target/arm/attr_thumb-static2.c (test for excess errors)
UNRESOLVED: gcc.target/arm/attr_thumb-static2.c scan-assembler-times blx 2

This was fixed with "arm: testsuite: avoid problems with -mfpu=auto in 
attr_thumb-static2.c", which is a later patch in the series (patch 6).

I don't think it's useful to try to regression test each individual 
patch, it wasn't practical to try to get every patch into order in the 
series (it would have made for a lot of churn on some files, especially 
target-supports.exp), so only a fully before and a fully after run is 
useful.  If there are issues once the whole series has been applied, 
then that is much more interesting.

R.

Re: [committed 03/22] arm: testsuite: avoid hard-float ABI incompatibility with -march

[Christophe Lyon]

On Mon, 20 Nov 2023 at 14:58, Richard Earnshaw
<Richard.Earnshaw@foss.arm.com> wrote:
>
>
>
> On 20/11/2023 13:36, Christophe Lyon wrote:
> > On Mon, 20 Nov 2023 at 13:44, Richard Earnshaw
> > <Richard.Earnshaw@foss.arm.com> wrote:
> >>
> >>
> >>
> >> On 20/11/2023 10:23, Christophe Lyon wrote:
> >>> Hi Richard,
> >>>
> >>> On Mon, 13 Nov 2023 at 15:28, Richard Earnshaw <rearnsha@arm.com> wrote:
> >>>>
> >>>>
> >>>> A number of tests in the gcc testsuite, especially for arm-specific
> >>>> targets, add various flags to control the architecture.  These run
> >>>> into problems when the compiler is configured with -mfpu=auto if the
> >>>> new architecture lacks an architectural feature that implies we have
> >>>> floating-point instructions.
> >>>>
> >>>> The testsuite makes this worse as it falls foul of this requirement in
> >>>> the base architecture strings provided by target-supports.exp.
> >>>>
> >>>> To fix this we add "+fp", or something equivalent to this, to all the
> >>>> base architecture specifications.  The feature will be ignored if the
> >>>> float ABI is set to soft.
> >>>>
> >>>> gcc/testsuite:
> >>>>
> >>>>          * lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok):
> >>>>          Add base FPU specifications to all architectures that can support
> >>>>          one.
> >>>> ---
> >>>>   gcc/testsuite/lib/target-supports.exp | 50 +++++++++++++--------------
> >>>>   1 file changed, 25 insertions(+), 25 deletions(-)
> >>>>
> >>>
> >>> Our CI has detected some regressions with this patch, in particular
> >>> when testing for cortex-m55:
> >>>
> >>> with
> >>> -mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto
> >>> and GCC configured with --disable-multilib --with-mode=thumb
> >>> --with-arch=armv8.1-m.main+mve.fp+fp.dp --with-float=hard
> >>>
> >>> you can see our logs here:
> >>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/ <https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/>
> >>>
> >>> Thanks,
> >>>
> >>> Christophe
> >>
> >> What exactly am I supposed to be looking at here?  I see no description
> >> of what those logs represent.  If they are supposed to be before and
> >> after, then why does the after only run a tiny fraction of the testsuite
> >> (Running gcc.git~master/gcc/testsuite/gcc.target/arm/arm.exp ...
> >> Running gcc.git~master/gcc/testsuite/gcc.target/arm/cmse/cmse.exp ...
> >> Running gcc.git~master/gcc/testsuite/gcc.target/arm/lto/lto.exp ...)
> >>
> >> The logs give no clue as to why the reminder of the testsuite wasn't run.
> >>
> >> Please don't make me guess.
> >>
> >
> > Here is a summary with the list of regressions:
> > https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/notify/regressions.sum/*view*/
>
> OK, that's much more useful.  But how was I supposed to know that link
> existed?
>
The full notification email contains a lot of information, with
several pointers to our Jenkins artifacts.
The notification email is not yet automatically sent to contributors
because we are still polishing, and I thought I'd save you some time
by just sending the useful links.

Looks like it's time to send those automatically too.

> >
> > I thought you'd be able to find your way in the logs above, the .0
> > files contain the logs of the initial full testsuite run, and .1 ones
> > contain the logs of the second run of the testsuite, restricted to the
> > .exp files where we detected regressions. So looking at gcc.log.1.xz
> > will give you details of the regressions shown in the link above.
>
> There's nothing in the page you sent me to that gives any clue as to how
> to read the logs there.  So my assumption was that the .0 was a before
> run and .1 an after.  Please, if you're going to direct people to the
> log files, provide some way for them to understand what the log files show.
>
> Now, to the specific issues:
>
> Running gcc:gcc.target/arm/arm.exp ...
> FAIL: gcc.target/arm/attr_thumb-static2.c (test for excess errors)
> UNRESOLVED: gcc.target/arm/attr_thumb-static2.c scan-assembler-times blx 2
>
> This was fixed with "arm: testsuite: avoid problems with -mfpu=auto in
> attr_thumb-static2.c", which is a later patch in the series (patch 6).
>
> I don't think it's useful to try to regression test each individual
> patch, it wasn't practical to try to get every patch into order in the
> series (it would have made for a lot of churn on some files, especially
> target-supports.exp), so only a fully before and a fully after run is
> useful.  If there are issues once the whole series has been applied,
> then that is much more interesting.
>

I looked at this in more detail.
That specific bisection build was triggered because we detected
regressions, after the full series was committed.
What happens is that at the first bad commit (this one) there were
more regressions than after the full series was committed.

So, the extract of
https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/notify/regressions.sum/*view*/
which remains valid on current trunk is:
Running gcc:gcc.target/arm/cmse/cmse.exp ...
FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
-march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
lr
FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
-march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
lr
FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
-march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
lr
FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
-march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
msr\tAPSR_nzcvqg, lr
FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
-march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
lr
FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
-march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
lr
FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
-march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
lr
FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
-march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
lr
FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
-march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
msr\tAPSR_nzcvqg, lr
FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
-march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
lr
FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
-march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O0   scan-assembler
msr\tAPSR_nzcvqg, lr
FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
-march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O1   scan-assembler
msr\tAPSR_nzcvqg, lr
FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
-march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O2   scan-assembler
msr\tAPSR_nzcvqg, lr
FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
-march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O3 -g
scan-assembler msr\tAPSR_nzcvqg, lr
FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
-march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -Os   scan-assembler
msr\tAPSR_nzcvqg, lr
FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
-march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
lr
FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
-march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
lr
FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
-march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
lr
FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
-march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
msr\tAPSR_nzcvqg, lr
FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
-march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
lr
FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
-march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
lr
FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
-march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
lr
FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
-march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
lr
FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
-march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
msr\tAPSR_nzcvqg, lr
FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
-march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
lr

> R.

Re: [committed 03/22] arm: testsuite: avoid hard-float ABI incompatibility with -march

[Richard Earnshaw]

On 20/11/2023 14:24, Christophe Lyon wrote:
> On Mon, 20 Nov 2023 at 14:58, Richard Earnshaw
> <Richard.Earnshaw@foss.arm.com> wrote:
>>
>>
>>
>> On 20/11/2023 13:36, Christophe Lyon wrote:
>>> On Mon, 20 Nov 2023 at 13:44, Richard Earnshaw
>>> <Richard.Earnshaw@foss.arm.com> wrote:
>>>>
>>>>
>>>>
>>>> On 20/11/2023 10:23, Christophe Lyon wrote:
>>>>> Hi Richard,
>>>>>
>>>>> On Mon, 13 Nov 2023 at 15:28, Richard Earnshaw <rearnsha@arm.com> wrote:
>>>>>>
>>>>>>
>>>>>> A number of tests in the gcc testsuite, especially for arm-specific
>>>>>> targets, add various flags to control the architecture.  These run
>>>>>> into problems when the compiler is configured with -mfpu=auto if the
>>>>>> new architecture lacks an architectural feature that implies we have
>>>>>> floating-point instructions.
>>>>>>
>>>>>> The testsuite makes this worse as it falls foul of this requirement in
>>>>>> the base architecture strings provided by target-supports.exp.
>>>>>>
>>>>>> To fix this we add "+fp", or something equivalent to this, to all the
>>>>>> base architecture specifications.  The feature will be ignored if the
>>>>>> float ABI is set to soft.
>>>>>>
>>>>>> gcc/testsuite:
>>>>>>
>>>>>>           * lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok):
>>>>>>           Add base FPU specifications to all architectures that can support
>>>>>>           one.
>>>>>> ---
>>>>>>    gcc/testsuite/lib/target-supports.exp | 50 +++++++++++++--------------
>>>>>>    1 file changed, 25 insertions(+), 25 deletions(-)
>>>>>>
>>>>>
>>>>> Our CI has detected some regressions with this patch, in particular
>>>>> when testing for cortex-m55:
>>>>>
>>>>> with
>>>>> -mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto
>>>>> and GCC configured with --disable-multilib --with-mode=thumb
>>>>> --with-arch=armv8.1-m.main+mve.fp+fp.dp --with-float=hard
>>>>>
>>>>> you can see our logs here:
>>>>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/ <https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Christophe
>>>>
>>>> What exactly am I supposed to be looking at here?  I see no description
>>>> of what those logs represent.  If they are supposed to be before and
>>>> after, then why does the after only run a tiny fraction of the testsuite
>>>> (Running gcc.git~master/gcc/testsuite/gcc.target/arm/arm.exp ...
>>>> Running gcc.git~master/gcc/testsuite/gcc.target/arm/cmse/cmse.exp ...
>>>> Running gcc.git~master/gcc/testsuite/gcc.target/arm/lto/lto.exp ...)
>>>>
>>>> The logs give no clue as to why the reminder of the testsuite wasn't run.
>>>>
>>>> Please don't make me guess.
>>>>
>>>
>>> Here is a summary with the list of regressions:
>>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/notify/regressions.sum/*view*/
>>
>> OK, that's much more useful.  But how was I supposed to know that link
>> existed?
>>
> The full notification email contains a lot of information, with
> several pointers to our Jenkins artifacts.
> The notification email is not yet automatically sent to contributors
> because we are still polishing, and I thought I'd save you some time
> by just sending the useful links.
> 
> Looks like it's time to send those automatically too.
> 
>>>
>>> I thought you'd be able to find your way in the logs above, the .0
>>> files contain the logs of the initial full testsuite run, and .1 ones
>>> contain the logs of the second run of the testsuite, restricted to the
>>> .exp files where we detected regressions. So looking at gcc.log.1.xz
>>> will give you details of the regressions shown in the link above.
>>
>> There's nothing in the page you sent me to that gives any clue as to how
>> to read the logs there.  So my assumption was that the .0 was a before
>> run and .1 an after.  Please, if you're going to direct people to the
>> log files, provide some way for them to understand what the log files show.
>>
>> Now, to the specific issues:
>>
>> Running gcc:gcc.target/arm/arm.exp ...
>> FAIL: gcc.target/arm/attr_thumb-static2.c (test for excess errors)
>> UNRESOLVED: gcc.target/arm/attr_thumb-static2.c scan-assembler-times blx 2
>>
>> This was fixed with "arm: testsuite: avoid problems with -mfpu=auto in
>> attr_thumb-static2.c", which is a later patch in the series (patch 6).
>>
>> I don't think it's useful to try to regression test each individual
>> patch, it wasn't practical to try to get every patch into order in the
>> series (it would have made for a lot of churn on some files, especially
>> target-supports.exp), so only a fully before and a fully after run is
>> useful.  If there are issues once the whole series has been applied,
>> then that is much more interesting.
>>
> 
> I looked at this in more detail.
> That specific bisection build was triggered because we detected
> regressions, after the full series was committed.
> What happens is that at the first bad commit (this one) there were
> more regressions than after the full series was committed.
> 
> So, the extract of
> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/notify/regressions.sum/*view*/
> which remains valid on current trunk is:
> Running gcc:gcc.target/arm/cmse/cmse.exp ...
> FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
> lr
> FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
> lr
> FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
> lr
> FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
> msr\tAPSR_nzcvqg, lr
> FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
> lr
> FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
> lr
> FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
> lr
> FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
> lr
> FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
> msr\tAPSR_nzcvqg, lr
> FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
> lr
> FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
> -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O0   scan-assembler
> msr\tAPSR_nzcvqg, lr
> FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
> -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O1   scan-assembler
> msr\tAPSR_nzcvqg, lr
> FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
> -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O2   scan-assembler
> msr\tAPSR_nzcvqg, lr
> FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
> -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O3 -g
> scan-assembler msr\tAPSR_nzcvqg, lr
> FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
> -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -Os   scan-assembler
> msr\tAPSR_nzcvqg, lr
> FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
> lr
> FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
> lr
> FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
> lr
> FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
> msr\tAPSR_nzcvqg, lr
> FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
> lr
> FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
> lr
> FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
> lr
> FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
> lr
> FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
> msr\tAPSR_nzcvqg, lr
> FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
> -march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
> lr
> 
>> R.

The compiled output contains (at least for the case I tried -mthumb 
-march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 -mfloat-abi=hard 
-mfpu=auto   -fdiagnostics-plain-output  -march=armv8-m.base -mthumb 
-mfloat-abi=soft -O1 -mcmse -ffat-lto-objects -fno-ident -S  -o cmse-2.s):

msr     APSR_nzcvq, r1

So this will never match the expected pattern, which is looking for 'lr' 
not 'r1'.  Are you sure these tests were running before?

R.

Re: [committed 03/22] arm: testsuite: avoid hard-float ABI incompatibility with -march

[Richard Earnshaw]

On 20/11/2023 14:39, Richard Earnshaw wrote:
> 
> 
> On 20/11/2023 14:24, Christophe Lyon wrote:
>> On Mon, 20 Nov 2023 at 14:58, Richard Earnshaw
>> <Richard.Earnshaw@foss.arm.com> wrote:
>>>
>>>
>>>
>>> On 20/11/2023 13:36, Christophe Lyon wrote:
>>>> On Mon, 20 Nov 2023 at 13:44, Richard Earnshaw
>>>> <Richard.Earnshaw@foss.arm.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 20/11/2023 10:23, Christophe Lyon wrote:
>>>>>> Hi Richard,
>>>>>>
>>>>>> On Mon, 13 Nov 2023 at 15:28, Richard Earnshaw <rearnsha@arm.com> 
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> A number of tests in the gcc testsuite, especially for arm-specific
>>>>>>> targets, add various flags to control the architecture.  These run
>>>>>>> into problems when the compiler is configured with -mfpu=auto if the
>>>>>>> new architecture lacks an architectural feature that implies we have
>>>>>>> floating-point instructions.
>>>>>>>
>>>>>>> The testsuite makes this worse as it falls foul of this 
>>>>>>> requirement in
>>>>>>> the base architecture strings provided by target-supports.exp.
>>>>>>>
>>>>>>> To fix this we add "+fp", or something equivalent to this, to all 
>>>>>>> the
>>>>>>> base architecture specifications.  The feature will be ignored if 
>>>>>>> the
>>>>>>> float ABI is set to soft.
>>>>>>>
>>>>>>> gcc/testsuite:
>>>>>>>
>>>>>>>           * lib/target-supports.exp 
>>>>>>> (check_effective_target_arm_arch_FUNC_ok):
>>>>>>>           Add base FPU specifications to all architectures that 
>>>>>>> can support
>>>>>>>           one.
>>>>>>> ---
>>>>>>>    gcc/testsuite/lib/target-supports.exp | 50 
>>>>>>> +++++++++++++--------------
>>>>>>>    1 file changed, 25 insertions(+), 25 deletions(-)
>>>>>>>
>>>>>>
>>>>>> Our CI has detected some regressions with this patch, in particular
>>>>>> when testing for cortex-m55:
>>>>>>
>>>>>> with
>>>>>> -mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto
>>>>>> and GCC configured with --disable-multilib --with-mode=thumb
>>>>>> --with-arch=armv8.1-m.main+mve.fp+fp.dp --with-float=hard
>>>>>>
>>>>>> you can see our logs here:
>>>>>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/ <https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Christophe
>>>>>
>>>>> What exactly am I supposed to be looking at here?  I see no 
>>>>> description
>>>>> of what those logs represent.  If they are supposed to be before and
>>>>> after, then why does the after only run a tiny fraction of the 
>>>>> testsuite
>>>>> (Running gcc.git~master/gcc/testsuite/gcc.target/arm/arm.exp ...
>>>>> Running gcc.git~master/gcc/testsuite/gcc.target/arm/cmse/cmse.exp ...
>>>>> Running gcc.git~master/gcc/testsuite/gcc.target/arm/lto/lto.exp ...)
>>>>>
>>>>> The logs give no clue as to why the reminder of the testsuite 
>>>>> wasn't run.
>>>>>
>>>>> Please don't make me guess.
>>>>>
>>>>
>>>> Here is a summary with the list of regressions:
>>>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/notify/regressions.sum/*view*/
>>>
>>> OK, that's much more useful.  But how was I supposed to know that link
>>> existed?
>>>
>> The full notification email contains a lot of information, with
>> several pointers to our Jenkins artifacts.
>> The notification email is not yet automatically sent to contributors
>> because we are still polishing, and I thought I'd save you some time
>> by just sending the useful links.
>>
>> Looks like it's time to send those automatically too.
>>
>>>>
>>>> I thought you'd be able to find your way in the logs above, the .0
>>>> files contain the logs of the initial full testsuite run, and .1 ones
>>>> contain the logs of the second run of the testsuite, restricted to the
>>>> .exp files where we detected regressions. So looking at gcc.log.1.xz
>>>> will give you details of the regressions shown in the link above.
>>>
>>> There's nothing in the page you sent me to that gives any clue as to how
>>> to read the logs there.  So my assumption was that the .0 was a before
>>> run and .1 an after.  Please, if you're going to direct people to the
>>> log files, provide some way for them to understand what the log files 
>>> show.
>>>
>>> Now, to the specific issues:
>>>
>>> Running gcc:gcc.target/arm/arm.exp ...
>>> FAIL: gcc.target/arm/attr_thumb-static2.c (test for excess errors)
>>> UNRESOLVED: gcc.target/arm/attr_thumb-static2.c scan-assembler-times 
>>> blx 2
>>>
>>> This was fixed with "arm: testsuite: avoid problems with -mfpu=auto in
>>> attr_thumb-static2.c", which is a later patch in the series (patch 6).
>>>
>>> I don't think it's useful to try to regression test each individual
>>> patch, it wasn't practical to try to get every patch into order in the
>>> series (it would have made for a lot of churn on some files, especially
>>> target-supports.exp), so only a fully before and a fully after run is
>>> useful.  If there are issues once the whole series has been applied,
>>> then that is much more interesting.
>>>
>>
>> I looked at this in more detail.
>> That specific bisection build was triggered because we detected
>> regressions, after the full series was committed.
>> What happens is that at the first bad commit (this one) there were
>> more regressions than after the full series was committed.
>>
>> So, the extract of
>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/notify/regressions.sum/*view*/
>> which remains valid on current trunk is:
>> Running gcc:gcc.target/arm/cmse/cmse.exp ...
>> FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
>> lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
>> lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
>> lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
>> msr\tAPSR_nzcvqg, lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
>> lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
>> lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
>> lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
>> lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
>> msr\tAPSR_nzcvqg, lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
>> lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
>> -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O0   scan-assembler
>> msr\tAPSR_nzcvqg, lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
>> -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O1   scan-assembler
>> msr\tAPSR_nzcvqg, lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
>> -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O2   scan-assembler
>> msr\tAPSR_nzcvqg, lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
>> -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O3 -g
>> scan-assembler msr\tAPSR_nzcvqg, lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
>> -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -Os   scan-assembler
>> msr\tAPSR_nzcvqg, lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
>> lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
>> lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
>> lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
>> msr\tAPSR_nzcvqg, lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
>> lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
>> lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
>> lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
>> lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
>> msr\tAPSR_nzcvqg, lr
>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
>> -march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
>> lr
>>
>>> R.
> 
> The compiled output contains (at least for the case I tried -mthumb 
> -march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 -mfloat-abi=hard 
> -mfpu=auto   -fdiagnostics-plain-output  -march=armv8-m.base -mthumb 
> -mfloat-abi=soft -O1 -mcmse -ffat-lto-objects -fno-ident -S  -o cmse-2.s):
> 
> msr     APSR_nzcvq, r1
> 
> So this will never match the expected pattern, which is looking for 'lr' 
> not 'r1'.  Are you sure these tests were running before?
> 
> R.

Sorry, ignore that, I was looking at the wrong test.

R.

Re: [committed 03/22] arm: testsuite: avoid hard-float ABI incompatibility with -march

[Christophe Lyon]

On Mon, 20 Nov 2023 at 15:39, Richard Earnshaw
<Richard.Earnshaw@foss.arm.com> wrote:
>
>
>
> On 20/11/2023 14:24, Christophe Lyon wrote:
> > On Mon, 20 Nov 2023 at 14:58, Richard Earnshaw
> > <Richard.Earnshaw@foss.arm.com> wrote:
> >>
> >>
> >>
> >> On 20/11/2023 13:36, Christophe Lyon wrote:
> >>> On Mon, 20 Nov 2023 at 13:44, Richard Earnshaw
> >>> <Richard.Earnshaw@foss.arm.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 20/11/2023 10:23, Christophe Lyon wrote:
> >>>>> Hi Richard,
> >>>>>
> >>>>> On Mon, 13 Nov 2023 at 15:28, Richard Earnshaw <rearnsha@arm.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>> A number of tests in the gcc testsuite, especially for arm-specific
> >>>>>> targets, add various flags to control the architecture.  These run
> >>>>>> into problems when the compiler is configured with -mfpu=auto if the
> >>>>>> new architecture lacks an architectural feature that implies we have
> >>>>>> floating-point instructions.
> >>>>>>
> >>>>>> The testsuite makes this worse as it falls foul of this requirement in
> >>>>>> the base architecture strings provided by target-supports.exp.
> >>>>>>
> >>>>>> To fix this we add "+fp", or something equivalent to this, to all the
> >>>>>> base architecture specifications.  The feature will be ignored if the
> >>>>>> float ABI is set to soft.
> >>>>>>
> >>>>>> gcc/testsuite:
> >>>>>>
> >>>>>>           * lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok):
> >>>>>>           Add base FPU specifications to all architectures that can support
> >>>>>>           one.
> >>>>>> ---
> >>>>>>    gcc/testsuite/lib/target-supports.exp | 50 +++++++++++++--------------
> >>>>>>    1 file changed, 25 insertions(+), 25 deletions(-)
> >>>>>>
> >>>>>
> >>>>> Our CI has detected some regressions with this patch, in particular
> >>>>> when testing for cortex-m55:
> >>>>>
> >>>>> with
> >>>>> -mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto
> >>>>> and GCC configured with --disable-multilib --with-mode=thumb
> >>>>> --with-arch=armv8.1-m.main+mve.fp+fp.dp --with-float=hard
> >>>>>
> >>>>> you can see our logs here:
> >>>>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/ <https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/>
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Christophe
> >>>>
> >>>> What exactly am I supposed to be looking at here?  I see no description
> >>>> of what those logs represent.  If they are supposed to be before and
> >>>> after, then why does the after only run a tiny fraction of the testsuite
> >>>> (Running gcc.git~master/gcc/testsuite/gcc.target/arm/arm.exp ...
> >>>> Running gcc.git~master/gcc/testsuite/gcc.target/arm/cmse/cmse.exp ...
> >>>> Running gcc.git~master/gcc/testsuite/gcc.target/arm/lto/lto.exp ...)
> >>>>
> >>>> The logs give no clue as to why the reminder of the testsuite wasn't run.
> >>>>
> >>>> Please don't make me guess.
> >>>>
> >>>
> >>> Here is a summary with the list of regressions:
> >>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/notify/regressions.sum/*view*/
> >>
> >> OK, that's much more useful.  But how was I supposed to know that link
> >> existed?
> >>
> > The full notification email contains a lot of information, with
> > several pointers to our Jenkins artifacts.
> > The notification email is not yet automatically sent to contributors
> > because we are still polishing, and I thought I'd save you some time
> > by just sending the useful links.
> >
> > Looks like it's time to send those automatically too.
> >
> >>>
> >>> I thought you'd be able to find your way in the logs above, the .0
> >>> files contain the logs of the initial full testsuite run, and .1 ones
> >>> contain the logs of the second run of the testsuite, restricted to the
> >>> .exp files where we detected regressions. So looking at gcc.log.1.xz
> >>> will give you details of the regressions shown in the link above.
> >>
> >> There's nothing in the page you sent me to that gives any clue as to how
> >> to read the logs there.  So my assumption was that the .0 was a before
> >> run and .1 an after.  Please, if you're going to direct people to the
> >> log files, provide some way for them to understand what the log files show.
> >>
> >> Now, to the specific issues:
> >>
> >> Running gcc:gcc.target/arm/arm.exp ...
> >> FAIL: gcc.target/arm/attr_thumb-static2.c (test for excess errors)
> >> UNRESOLVED: gcc.target/arm/attr_thumb-static2.c scan-assembler-times blx 2
> >>
> >> This was fixed with "arm: testsuite: avoid problems with -mfpu=auto in
> >> attr_thumb-static2.c", which is a later patch in the series (patch 6).
> >>
> >> I don't think it's useful to try to regression test each individual
> >> patch, it wasn't practical to try to get every patch into order in the
> >> series (it would have made for a lot of churn on some files, especially
> >> target-supports.exp), so only a fully before and a fully after run is
> >> useful.  If there are issues once the whole series has been applied,
> >> then that is much more interesting.
> >>
> >
> > I looked at this in more detail.
> > That specific bisection build was triggered because we detected
> > regressions, after the full series was committed.
> > What happens is that at the first bad commit (this one) there were
> > more regressions than after the full series was committed.
> >
> > So, the extract of
> > https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/notify/regressions.sum/*view*/
> > which remains valid on current trunk is:
> > Running gcc:gcc.target/arm/cmse/cmse.exp ...
> > FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
> > lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
> > lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
> > lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
> > msr\tAPSR_nzcvqg, lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
> > lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
> > lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
> > lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
> > lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
> > msr\tAPSR_nzcvqg, lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
> > lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
> > -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O0   scan-assembler
> > msr\tAPSR_nzcvqg, lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
> > -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O1   scan-assembler
> > msr\tAPSR_nzcvqg, lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
> > -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O2   scan-assembler
> > msr\tAPSR_nzcvqg, lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
> > -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O3 -g
> > scan-assembler msr\tAPSR_nzcvqg, lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
> > -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -Os   scan-assembler
> > msr\tAPSR_nzcvqg, lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
> > lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
> > lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
> > lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
> > msr\tAPSR_nzcvqg, lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
> > lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
> > lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
> > lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
> > lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
> > msr\tAPSR_nzcvqg, lr
> > FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
> > -march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
> > lr
> >
> >> R.
>
> The compiled output contains (at least for the case I tried -mthumb
> -march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 -mfloat-abi=hard
> -mfpu=auto   -fdiagnostics-plain-output  -march=armv8-m.base -mthumb
> -mfloat-abi=soft -O1 -mcmse -ffat-lto-objects -fno-ident -S  -o cmse-2.s):
>
> msr     APSR_nzcvq, r1
>
> So this will never match the expected pattern, which is looking for 'lr'
> not 'r1'.  Are you sure these tests were running before?
>

No, your patch enabled them.

I already noticed/reported a long time ago that cmse.exp was not
executed by all the configurations we currently run and I was
surprised to see errors in my manual runs with more specific
configurations.

Good to see it enabled now.


> R.

Re: [committed 03/22] arm: testsuite: avoid hard-float ABI incompatibility with -march

[Richard Earnshaw]

On 20/11/2023 14:50, Christophe Lyon wrote:
> On Mon, 20 Nov 2023 at 15:39, Richard Earnshaw
> <Richard.Earnshaw@foss.arm.com> wrote:
>>
>>
>>
>> On 20/11/2023 14:24, Christophe Lyon wrote:
>>> On Mon, 20 Nov 2023 at 14:58, Richard Earnshaw
>>> <Richard.Earnshaw@foss.arm.com> wrote:
>>>>
>>>>
>>>>
>>>> On 20/11/2023 13:36, Christophe Lyon wrote:
>>>>> On Mon, 20 Nov 2023 at 13:44, Richard Earnshaw
>>>>> <Richard.Earnshaw@foss.arm.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 20/11/2023 10:23, Christophe Lyon wrote:
>>>>>>> Hi Richard,
>>>>>>>
>>>>>>> On Mon, 13 Nov 2023 at 15:28, Richard Earnshaw <rearnsha@arm.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> A number of tests in the gcc testsuite, especially for arm-specific
>>>>>>>> targets, add various flags to control the architecture.  These run
>>>>>>>> into problems when the compiler is configured with -mfpu=auto if the
>>>>>>>> new architecture lacks an architectural feature that implies we have
>>>>>>>> floating-point instructions.
>>>>>>>>
>>>>>>>> The testsuite makes this worse as it falls foul of this requirement in
>>>>>>>> the base architecture strings provided by target-supports.exp.
>>>>>>>>
>>>>>>>> To fix this we add "+fp", or something equivalent to this, to all the
>>>>>>>> base architecture specifications.  The feature will be ignored if the
>>>>>>>> float ABI is set to soft.
>>>>>>>>
>>>>>>>> gcc/testsuite:
>>>>>>>>
>>>>>>>>            * lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok):
>>>>>>>>            Add base FPU specifications to all architectures that can support
>>>>>>>>            one.
>>>>>>>> ---
>>>>>>>>     gcc/testsuite/lib/target-supports.exp | 50 +++++++++++++--------------
>>>>>>>>     1 file changed, 25 insertions(+), 25 deletions(-)
>>>>>>>>
>>>>>>>
>>>>>>> Our CI has detected some regressions with this patch, in particular
>>>>>>> when testing for cortex-m55:
>>>>>>>
>>>>>>> with
>>>>>>> -mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto
>>>>>>> and GCC configured with --disable-multilib --with-mode=thumb
>>>>>>> --with-arch=armv8.1-m.main+mve.fp+fp.dp --with-float=hard
>>>>>>>
>>>>>>> you can see our logs here:
>>>>>>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/ <https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Christophe
>>>>>>
>>>>>> What exactly am I supposed to be looking at here?  I see no description
>>>>>> of what those logs represent.  If they are supposed to be before and
>>>>>> after, then why does the after only run a tiny fraction of the testsuite
>>>>>> (Running gcc.git~master/gcc/testsuite/gcc.target/arm/arm.exp ...
>>>>>> Running gcc.git~master/gcc/testsuite/gcc.target/arm/cmse/cmse.exp ...
>>>>>> Running gcc.git~master/gcc/testsuite/gcc.target/arm/lto/lto.exp ...)
>>>>>>
>>>>>> The logs give no clue as to why the reminder of the testsuite wasn't run.
>>>>>>
>>>>>> Please don't make me guess.
>>>>>>
>>>>>
>>>>> Here is a summary with the list of regressions:
>>>>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/notify/regressions.sum/*view*/
>>>>
>>>> OK, that's much more useful.  But how was I supposed to know that link
>>>> existed?
>>>>
>>> The full notification email contains a lot of information, with
>>> several pointers to our Jenkins artifacts.
>>> The notification email is not yet automatically sent to contributors
>>> because we are still polishing, and I thought I'd save you some time
>>> by just sending the useful links.
>>>
>>> Looks like it's time to send those automatically too.
>>>
>>>>>
>>>>> I thought you'd be able to find your way in the logs above, the .0
>>>>> files contain the logs of the initial full testsuite run, and .1 ones
>>>>> contain the logs of the second run of the testsuite, restricted to the
>>>>> .exp files where we detected regressions. So looking at gcc.log.1.xz
>>>>> will give you details of the regressions shown in the link above.
>>>>
>>>> There's nothing in the page you sent me to that gives any clue as to how
>>>> to read the logs there.  So my assumption was that the .0 was a before
>>>> run and .1 an after.  Please, if you're going to direct people to the
>>>> log files, provide some way for them to understand what the log files show.
>>>>
>>>> Now, to the specific issues:
>>>>
>>>> Running gcc:gcc.target/arm/arm.exp ...
>>>> FAIL: gcc.target/arm/attr_thumb-static2.c (test for excess errors)
>>>> UNRESOLVED: gcc.target/arm/attr_thumb-static2.c scan-assembler-times blx 2
>>>>
>>>> This was fixed with "arm: testsuite: avoid problems with -mfpu=auto in
>>>> attr_thumb-static2.c", which is a later patch in the series (patch 6).
>>>>
>>>> I don't think it's useful to try to regression test each individual
>>>> patch, it wasn't practical to try to get every patch into order in the
>>>> series (it would have made for a lot of churn on some files, especially
>>>> target-supports.exp), so only a fully before and a fully after run is
>>>> useful.  If there are issues once the whole series has been applied,
>>>> then that is much more interesting.
>>>>
>>>
>>> I looked at this in more detail.
>>> That specific bisection build was triggered because we detected
>>> regressions, after the full series was committed.
>>> What happens is that at the first bad commit (this one) there were
>>> more regressions than after the full series was committed.
>>>
>>> So, the extract of
>>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/notify/regressions.sum/*view*/
>>> which remains valid on current trunk is:
>>> Running gcc:gcc.target/arm/cmse/cmse.exp ...
>>> FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
>>> lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
>>> lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
>>> lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
>>> msr\tAPSR_nzcvqg, lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/hard-sp/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
>>> lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
>>> lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
>>> lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
>>> lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
>>> msr\tAPSR_nzcvqg, lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/hard/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
>>> lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O0   scan-assembler
>>> msr\tAPSR_nzcvqg, lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O1   scan-assembler
>>> msr\tAPSR_nzcvqg, lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O2   scan-assembler
>>> msr\tAPSR_nzcvqg, lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -O3 -g
>>> scan-assembler msr\tAPSR_nzcvqg, lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/soft/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb -mfloat-abi=soft  -Os   scan-assembler
>>> msr\tAPSR_nzcvqg, lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
>>> lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
>>> lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
>>> lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
>>> msr\tAPSR_nzcvqg, lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp-sp/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
>>> lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -O0   scan-assembler msr\tAPSR_nzcvqg,
>>> lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -O1   scan-assembler msr\tAPSR_nzcvqg,
>>> lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -O2   scan-assembler msr\tAPSR_nzcvqg,
>>> lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -O3 -g   scan-assembler
>>> msr\tAPSR_nzcvqg, lr
>>> FAIL: gcc.target/arm/cmse/mainline/8m/softfp/cmse-5.c
>>> -march=armv8-m.main+fp -mthumb  -Os   scan-assembler msr\tAPSR_nzcvqg,
>>> lr
>>>
>>>> R.
>>
>> The compiled output contains (at least for the case I tried -mthumb
>> -march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 -mfloat-abi=hard
>> -mfpu=auto   -fdiagnostics-plain-output  -march=armv8-m.base -mthumb
>> -mfloat-abi=soft -O1 -mcmse -ffat-lto-objects -fno-ident -S  -o cmse-2.s):
>>
>> msr     APSR_nzcvq, r1
>>
>> So this will never match the expected pattern, which is looking for 'lr'
>> not 'r1'.  Are you sure these tests were running before?
>>
> 
> No, your patch enabled them.
> 
> I already noticed/reported a long time ago that cmse.exp was not
> executed by all the configurations we currently run and I was
> surprised to see errors in my manual runs with more specific
> configurations.
> 
> Good to see it enabled now.

[TLDR]

I was initially confused about why this test had suddenly started to 
run, but it turns out it's because cmse.exp has the gating operation, 
not the test itself.

The problem in this case is because the specific subtest is checking for 
the DSP extension.  But we have a command line of

  -mthumb -march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 \
  -mfloat-abi=hard -mfpu=auto -fdiagnostics-plain-output \
  -march=armv8-m.main+fp -mthumb -mfloat-abi=soft -O1 -mcmse \
  -mfloat-abi=soft

When compiling the test, but a command line of

  -mthumb -march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 \
  -mfloat-abi=hard -mfpu=auto

when checking for the DSP extension.

The former is built up from

  -mthumb -march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 \
  -mfloat-abi=hard -mfpu=auto

for the testsuite run

  -fdiagnostics-plain-output

from the general framework

  -march=armv8-m.main+fp -mthumb

from the cmse.exp script [add_options_for...]

  -mfloat-abi=soft

from the framework - variant check

and finally

  -O1 -mcmse -mfloat-abi=soft

from the dg-options in the test.

So we're going to get a mismatch in features here which is not trivial 
to work around.  The problem in this particular case stems from the fact 
that the DSP extension is mandatory if MVE is present, but optional 
otherwise and the option combinations imply it via +mve.fp.  We then 
override the architecture with a non-MVE variant and end up not having 
DSP.  Ultimately, therefore, we compile the test without DSP, but then 
check for DSP with a set of architecture flags that has DSP.

Given the way this is all put together, I think you'd see the same 
problem if you ran the test with

  -mthumb -march=armv8.1-m.main+fp+dsp -mfloat-abi=softfp

I don't think there's a trivial way to work around the inconsistent 
options problem without weakening the test overall (by just testing for 
"APSR_nzcvqg?").  So perhaps the best solution is to do that, but then 
add some additional tests that are outside this base CMSE behaviour that 
test the APSR register more explicitly.

I'll give this some thought.

R.