On 05/11/2024 07:55, Torbjorn SVENSSON wrote:
>
>
> On 2024-11-04 15:41, Richard Earnshaw wrote:
>> 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 <[email protected]>
>>>
>>> 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.
>
> Do you want me to move the assembler checks to a new file, like suffixing
> with "-asm" (memset-inline-5-asm.c) and then include the base file in it or
> do you have something else in mind?
Sorry for the slow reply, I'd incorrectly marked this thread as resolved in my
mailbox.
I would keep the existing files as they are for the compile tests, but remove
the dg-do run statement. Then, when we want to run the test as well, we can
simply create the new test (with, perhaps -exe appended and just #include the
main test. Something like
memset-inline-5-exe.c:
-----
/* { dg-do run } */
/* ... other dg-directives copied from main test ... */
#include "memset-inline-5.c"
-----
I believe the framework does not follow the include path to find additional
directives, so this will do what we need with the minimum of changes to the
original test.
R.
