On 2024-11-04 16:47, Richard Earnshaw (lists) wrote:
On 20/10/2024 16:51, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
The tests assume that a neon fpu is avialable and fails it not, so
explicitly require it.
diff --git a/gcc/testsuite/gcc.target/arm/attr-neon2.c
b/gcc/testsuite/gcc.target/arm/attr-neon2.c
index a7a72dac379..0811d72af9b 100644
--- a/gcc/testsuite/gcc.target/arm/attr-neon2.c
+++ b/gcc/testsuite/gcc.target/arm/attr-neon2.c
@@ -2,6 +2,7 @@
/* { dg-require-effective-target arm_neon_ok } */
/* { dg-require-effective-target arm_fp_ok } */
/* { dg-options "-Ofast" } */
+/* { dg-add-options arm_neon } */
/* { dg-add-options arm_fp } */
/* Reset fpu to a value compatible with the next pragmas. */
Focussing just on this test for the moment (I suspect the others may be
similar). But this doesn't look right. The point of the test is a file
compiled without neon (and where neon is compatible with the target
architecture) can compile functions with neon options where those aren't
enabled by default.
Can you give some more detail, please, about the failures you're seeing and the
options that lead to that?
Without the patch, I get the following when testing for m85hard:
Testing arm/attr-neon2.c
...
spawn -ignore SIGHUP .../bin/arm-none-eabi-gcc
.../gcc/testsuite/gcc.target/arm/attr-neon2.c -mthumb
-march=armv8.1-m.main+mve+pacbti -mcpu=cortex-m85 -mfloat-abi=hard
-mfpu=fpv5-d16 -fdiagnostics-plain-output -Ofast -ffat-lto-objects
-fno-ident -S -o attr-neon2.s
pid is 5387 -5387
In file included from
.../lib/gcc/arm-none-eabi/15.0.0/include/arm_neon.h:42,
from .../gcc/testsuite/gcc.target/arm/attr-neon2.c:12:
.../lib/gcc/arm-none-eabi/15.0.0/include/arm_bf16.h: In function
'vcvtah_f32_bf16':
.../lib/gcc/arm-none-eabi/15.0.0/include/arm_bf16.h:41:10: error:
implicit declaration of function '__builtin_neon_vbfcvtbf'; did you mean
'__builtin_neon_vcvthshf'? [-Wimplicit-function-declaration]
.../lib/gcc/arm-none-eabi/15.0.0/include/arm_bf16.h:41:3: error: invalid
conversion from type 'bfloat16_t'
.../lib/gcc/arm-none-eabi/15.0.0/include/arm_bf16.h: In function
'vcvth_bf16_f32':
(and approximately 4000 more lines of warnings and errors in arm_neon.h)
...
gcc.target/arm/attr-neon2.c: output file does not exist
UNRESOLVED: gcc.target/arm/attr-neon2.c scan-assembler .fpu\\s+vfp\n
gcc.target/arm/attr-neon2.c: output file does not exist
UNRESOLVED: gcc.target/arm/attr-neon2.c scan-assembler .fpu\\s+neon\n
gcc.target/arm/attr-neon2.c: output file does not exist
UNRESOLVED: gcc.target/arm/attr-neon2.c check-function-bodies my
UNRESOLVED: gcc.target/arm/attr-neon2.c check-function-bodies my1
I get the same result for m55hard and m85hard, but not for any other of
my tested targets, so I suspect that this has something to do with that
there is nothing setting the proper architecture.
The arm_neon_ok check is successful with this command line:
.../bin/arm-none-eabi-gcc -mthumb -march=armv8.1-m.main+mve+pacbti
-mcpu=cortex-m85 -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_ok2995.o
arm_neon_ok2995.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 all in all. Maybe arm_neon is not the right one, but we need to
ensure a compatible architecture is active in order for the test to
pass. It's the same kind of issue in the other tests in this patch.
Let me know if you have any other ideas on how to fix this issue.
Kind regards,
Torbjörn
