On 08/01/2025 13:56, Tamar Christina wrote:
>> -----Original Message-----
>> From: Richard Earnshaw (lists) <richard.earns...@arm.com>
>> Sent: Wednesday, January 8, 2025 1:18 PM
>> To: Christophe Lyon <christophe.l...@linaro.org>; gcc-patches@gcc.gnu.org;
>> Richard Sandiford <richard.sandif...@arm.com>; Tamar Christina
>> <tamar.christ...@arm.com>; Andre Simoes Dias Vieira
>> <andre.simoesdiasvie...@arm.com>; ktkac...@nvidia.com;
>> raman...@nvidia.com
>> Subject: Re: [PATCH 3/4] arm, testsuite: fix arm_v8_3a_fp16_complex_neon_ok
>>
>> On 19/12/2024 12:17, Christophe Lyon wrote:
>>> Without this patch, testcases using arm_v8_3a_fp16_complex_neon fail
>>> to compile on arm-linux-gnueabihf with
>>> fatal error: gnu/stubs-soft.h: No such file or directory
>>> because they are actually compiled with
>>> -mfloat-abi=softfp -mfpu=auto -mcpu=unset -march=armv8.3-a+fp16
>>>
>>> Fix this by including stdint.h in the sample code for the effective-target.
>>>
>>> This makes these tests PASS instead of being UNRESOLVED:
>>> fast-math-bb-slp-complex-add-half-float.c
>>> fast-math-bb-slp-complex-mla-half-float.c
>>> fast-math-bb-slp-complex-mls-half-float.c
>>> fast-math-bb-slp-complex-mul-half-float.c
>>> fast-math-complex-add-half-float.c
>>> fast-math-complex-mla-half-float.c
>>> fast-math-complex-mls-half-float.c
>>> fast-math-complex-mul-half-float.c
>>>
>>> except for two new
>>> FAIL: gcc.dg/vect/complex/fast-math-complex-mls-half-float.c scan-tree-dump
>> vect "Found COMPLEX_ADD_ROT270"
>>> (and the same with -flto -ffat-lto-objects)
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * lib/target-supports.exp
>>> (check_effective_target_arm_v8_3a_fp16_complex_neon_ok_nocache):
>>> Include stdint.h.
>>> ---
>>> gcc/testsuite/lib/target-supports.exp | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/gcc/testsuite/lib/target-supports.exp
>>> b/gcc/testsuite/lib/target-
>> supports.exp
>>> index a16e9534ccd..9f4e2700dd2 100644
>>> --- a/gcc/testsuite/lib/target-supports.exp
>>> +++ b/gcc/testsuite/lib/target-supports.exp
>>> @@ -13298,6 +13298,7 @@ proc
>> check_effective_target_arm_v8_3a_fp16_complex_neon_ok_nocache { } {
>>> #if !defined (__ARM_FEATURE_COMPLEX)
>>> #error "__ARM_FEATURE_COMPLEX not defined"
>>> #endif
>>> + #include <stdint.h>
>>> } "$flags -mcpu=unset -march=armv8.3-a+fp16"] } {
>>> set et_arm_v8_3a_fp16_complex_neon_flags \
>>> "$flags -mcpu=unset -march=armv8.3-a+fp16"
>>
>> I'm somewhat surprised that a test in gcc.dg/vect/complex is using an
>> unguarded
>> arm_... set of options. Tamar, I think this test is one of yours: how is
>> this supposed
>> to work on non-arm platforms?
>
> On non-arm platforms et_arm_v8_3a_complex_neon_flags will be "" and so the
> options adding expands to adding no options.
>
> That's the reason the directive contains a check if it's arm or aarch64
> before processing
> further. It avoids having to repeated guard the dg-add-options by a target
> check.
>
That's not at all obvious from the name, especially when there are other
similarly named checks.
R.
> Tamar.
>
>>
>> R.
