On 2024-11-05 16:37, Richard Earnshaw wrote:
On 05/11/2024 15:21, Richard Earnshaw (lists) wrote:
On 04/11/2024 20:34, Torbjorn SVENSSON wrote:
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?
This is similar to the other neon tests I've just replied about: I'd just skip
this (pr68620) test on m-profile for now.
R.
Kind regards,
Torbjörn
I've just realised there's another way we could change this test which stays
within the spirit of compiling a function with additional capabilities.
/* { dg-do compile } */
/* { dg-skip-if "-mpure-code supports M-profile without Neon only" { *-*-* } {
"-mpure-code" } } */
/* { dg-require-effective-target arm_arch_v7a_ok } */
/* { dg-options "-mfp16-format=ieee -mfpu=auto -mfloat-abi=softfp" } */
/* { dg-add-options arm_arch_v7a } */
This will have the effect of forcing the architecture to a known baseline and
from there we can then override the FPU with a neon extension.
The reason why I did not go this way from the start (yes I was
considering it) was that I'm not sure if it was enough to check this for
the v7a architecture or if neon should be tested in some other
permutation in addition to v7a.
Anyway, I think it's better to do a v7a variant than not testing it at
all, so I'll prepare an updated patch with this (I'll do the same for
the other patch that you reviewed earlier today too).
Kind regards,
Torbjörn
