On 2024-11-04 17:03, Richard Earnshaw (lists) wrote:
On 31/10/2024 18:26, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Tests uses neon, so add effective-target arm_neon.
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr68620.c: Use effective-target arm_neon.
* gcc.target/arm/pr78041.c: Likewise.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svens...@foss.st.com>
---
gcc/testsuite/gcc.target/arm/pr68620.c | 4 ++--
gcc/testsuite/gcc.target/arm/pr78041.c | 3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.target/arm/pr68620.c
b/gcc/testsuite/gcc.target/arm/pr68620.c
index 91878432b00..b4a44dab6ba 100644
--- a/gcc/testsuite/gcc.target/arm/pr68620.c
+++ b/gcc/testsuite/gcc.target/arm/pr68620.c
@@ -1,8 +1,8 @@
/* { dg-do compile } */
/* { dg-skip-if "-mpure-code supports M-profile without Neon only" { *-*-* } {
"-mpure-code" } } */
-/* { dg-require-effective-target arm_fp_ok } */
+/* { dg-require-effective-target arm_neon_ok } */
This seems reasonable, but ...
/* { dg-options "-mfp16-format=ieee" } */
-/* { dg-add-options arm_fp } */
+/* { dg-add-options arm_neon } */
#include "arm_neon.h"
... I don't think this is right. It looks like the point of this test is to
check that adding the #pragma to select a neon-based FPU enables a specific
intrinsic. That ought to work with the existing checks (at least, modulo
changing the effective-target at the start). But adding neon options on the
command line shouldn't be needed. What's the option combination that leads to
a failure?
The arm_fp is not enough to ensure a valid architecture is in use.
If I do not switch from arm_fp to arm_neon, I get the test executed like
this for m85hard:
.../bin/arm-none-eabi-gcc .../gcc/testsuite/gcc.target/arm/pr68620.c
-mthumb -march=armv8.1-m.main+mve -mcpu=cortex-m55 -mfloat-abi=hard
-mfpu=fpv5-d16 -fdiagnostics-plain-output -mfp16-format=ieee -S
-o pr68620.s
Obvious, -mfp16-format=ieee is valid for Cortex-M85, but it's not the
same thing as that it supports neon/nenon-fp16. The check for arm_neon
passes as there are flags that could be added that override and makes
the check pass, i.e.:
.../bin/arm-none-eabi-gcc -mthumb -march=armv8.1-m.main+mve
-mcpu=cortex-m55 -mfloat-abi=hard -mfpu=fpv5-d16
-fdiagnostics-plain-output -mfpu=neon -mfloat-abi=softfp -mcpu=unset
-march=armv7-a -Wno-complain-wrong-lang -c -o arm_neon_ok16723.o
arm_neon_ok16723.c
Note: I get this when I am adding -mcpu=unset to the arm_neon_ok check.
If I do not add the -mcpu=unset, the test is marked as unsupported due
to a conflicting -march/-mcpu combination (this is what I'm trying to
fix in the patchset that I will share in a few days, but without a
dedicated fix, these tests will be listed as regressions).
So, in order for the test to pass, a compatible architecture must be
selected and if we are not going to use the arm_neon check, then what
should we us to get as wide coverage as possible?
Kind regards,
Torbjörn
