Re: [PATCH] testsuite: arm: Use effective-target for attr-neon* tests
On 04/11/2024 20:14, Torbjorn SVENSSON wrote:
>
>
> 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.
Yuk! We really shouldn't be spewing out this level of verbiage. My initial
feeling is that there's a bug somewhere in the implementation that we ought to
fix. Maybe in the compiler itself, or in arm_neon.h.
In the mean time, I think the best thing to do is to skip this test on
m-profile cores, rather than try to force a bunch of meaningless option
combinations to work. Perhaps add:
/* { dg-skip-if "This tests needs an A- or R-profile target" { arm_cortex_m } }
*/
That might mean that in a few cases we will no-longer run this test, but it
shouldn't be for targets that really matter.
R.
>
> Kind regards,
> Torbjörn
Re: [PATCH] testsuite: arm: Use effective-target for attr-neon* tests
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
Re: [PATCH] testsuite: arm: Use effective-target for attr-neon* tests
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?
R.
