On 01/11/2024 18:40, Richard Earnshaw (lists) wrote:
> On 24/10/2024 09:50, Torbjörn SVENSSON wrote:
>> Ok for trunk and releases/gcc-14?
>>
>> --
>>
>> As these tests are set to execute and require neon hardware to do so,
>> add the missing dg-require-effective-target arm_neon_hw.
>>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/arm/memset-inline-4.c: Use effective-target
>> arm_neon_hw.
>> * gcc.target/arm/memset-inline-5.c: Likewise.
>> * gcc.target/arm/memset-inline-6.c: Likewise.
>>
>> Signed-off-by: Torbjörn SVENSSON <torbjorn.svens...@foss.st.com>
>
> These tests combine both a scan-assembler and a run. Unconditionally
> requiring neon hardware before running the test means we lose the
> scan-assembler when the hardware is not available. But I think you can write
>
> /* { dg-do run { arm_neon_hw } } */
>
> instead and now the framework will only try to run the test if hardware is
> available, but will fall back to a compile test otherwise.
I've been doing some more digging into this and it looks as though I was
mistaken about this fall-back behaviour. Firstly, I'd missed out the 'target'
keyword, the code would need to be
/* { dg-do run { target arm_neon_hw } } */
but this still doesn't work as I expected. Instead the test is skipped
entirely if the selector fails to match. So we shouldn't combine assembly scan
tests and execution tests in a single file, but need to have separate tests:
one for execution and one for assembly output.
Sorry for the confusion,
R.
