On 05/11/2024 15:21, Richard Earnshaw (lists) wrote:
> On 04/11/2024 20:34, Torbjorn SVENSSON wrote:
>>
>>
>> On 2024-11-04 17:03, Richard Earnshaw (lists) wrote:
>>> On 31/10/2024 18:26, Torbjörn SVENSSON wrote:
>>>> Ok for trunk and releases/gcc-14?
>>>>
>>>> -- 
>>>>
>>>> Tests uses neon, so add effective-target arm_neon.
>>>>
>>>> gcc/testsuite/ChangeLog:
>>>>
>>>>     * gcc.target/arm/pr68620.c: Use effective-target arm_neon.
>>>>     * gcc.target/arm/pr78041.c: Likewise.
>>>>
>>>> Signed-off-by: Torbjörn SVENSSON <torbjorn.svens...@foss.st.com>
>>>> ---
>>>>   gcc/testsuite/gcc.target/arm/pr68620.c | 4 ++--
>>>>   gcc/testsuite/gcc.target/arm/pr78041.c | 3 ++-
>>>>   2 files changed, 4 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/gcc/testsuite/gcc.target/arm/pr68620.c 
>>>> b/gcc/testsuite/gcc.target/arm/pr68620.c
>>>> index 91878432b00..b4a44dab6ba 100644
>>>> --- a/gcc/testsuite/gcc.target/arm/pr68620.c
>>>> +++ b/gcc/testsuite/gcc.target/arm/pr68620.c
>>>> @@ -1,8 +1,8 @@
>>>>   /* { dg-do compile } */
>>>>   /* { dg-skip-if "-mpure-code supports M-profile without Neon only" { 
>>>> *-*-* } { "-mpure-code" } } */
>>>> -/* { dg-require-effective-target arm_fp_ok } */
>>>> +/* { dg-require-effective-target arm_neon_ok } */
>>>
>>> This seems reasonable, but ...
>>>
>>>>   /* { dg-options "-mfp16-format=ieee" } */
>>>> -/* { dg-add-options arm_fp } */
>>>> +/* { dg-add-options arm_neon } */
>>>>     #include "arm_neon.h"
>>>>   
>>>
>>> ... I don't think this is right.  It looks like the point of this test is 
>>> to check that adding the #pragma to select a neon-based FPU enables a 
>>> specific intrinsic.  That ought to work with the existing checks (at least, 
>>> modulo changing the effective-target at the start).  But adding neon 
>>> options on the command line shouldn't be needed.  What's the option 
>>> combination that leads to a failure?
>>
>> The arm_fp is not enough to ensure a valid architecture is in use.
>>
>> If I do not switch from arm_fp to arm_neon, I get the test executed like 
>> this for m85hard:
>>
>> .../bin/arm-none-eabi-gcc  .../gcc/testsuite/gcc.target/arm/pr68620.c 
>> -mthumb -march=armv8.1-m.main+mve -mcpu=cortex-m55 -mfloat-abi=hard 
>> -mfpu=fpv5-d16   -fdiagnostics-plain-output   -mfp16-format=ieee  -S -o 
>> pr68620.s
>>
>> Obvious, -mfp16-format=ieee is valid for Cortex-M85, but it's not the same 
>> thing as that it supports neon/nenon-fp16. The check for arm_neon passes as 
>> there are flags that could be added that override and makes the check pass, 
>> i.e.:
>>
>> .../bin/arm-none-eabi-gcc   -mthumb -march=armv8.1-m.main+mve 
>> -mcpu=cortex-m55 -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_ok16723.o arm_neon_ok16723.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, in order for the test to pass, a compatible architecture must be 
>> selected and if we are not going to use the arm_neon check, then what should 
>> we us to get as wide coverage as possible?
> 
> This is similar to the other neon tests I've just replied about: I'd just 
> skip this (pr68620) test on m-profile for now.
> 
> R.
> 
>>
>> Kind regards,
>> Torbjörn
> 


I've just realised there's another way we could change this test which stays 
within the spirit of compiling a function with additional capabilities.

 /* { dg-do compile } */
 /* { dg-skip-if "-mpure-code supports M-profile without Neon only" { *-*-* } { 
"-mpure-code" } } */
 /* { dg-require-effective-target arm_arch_v7a_ok } */
 /* { dg-options "-mfp16-format=ieee -mfpu=auto -mfloat-abi=softfp" } */
 /* { dg-add-options arm_arch_v7a } */

This will have the effect of forcing the architecture to a known baseline and 
from there we can then override the FPU with a neon extension.

R.

Reply via email to