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 <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.
> 
> 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.

Reply via email to