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.
