On 13/04/2026 07:54, Torbjorn SVENSSON wrote: > > > On 2026-04-10 13:11, Richard Earnshaw (foss) wrote: >> On 10/04/2026 10:47, Torbjorn SVENSSON wrote: >>> >>> >>> On 2026-04-10 11:30, Christophe Lyon wrote: >>>> Sorry for the late reply, I have 2 questions: >>>> >>>> On 4/9/26 16:52, Torbjorn SVENSSON wrote: >>>>> >>>>> >>>>> On 2026-04-08 11:57, Richard Earnshaw (foss) wrote: >>>>>> On 07/04/2026 10:23, Torbjörn SVENSSON wrote: >>>>>>> Changes since v1: >>>>>>> >>>>>>> - Limited xfail check to arm* after Linaro CI notification of >>>>>>> regression for aarch64-linux-gnu. >>>>>>> >>>>>>> Ok for trunk and releases/gcc-15? >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> gcc/testsuite/ChangeLog: >>>>>>> >>>>>>> PR testsuite/113276 >>>>>>> * gcc.dg/torture/fp-double-convert-float-1.c: Xfail test for arm* >>>>>>> unless soft float or double-precision FP. >>>>>>> * lib/target-supports.exp >>>>>>> (check_effective_target_arm_softfp_or_dp): New function. >>>>>>> >>>>>>> Signed-off-by: Torbjörn SVENSSON <[email protected]> >>>>>>> --- >>>>>>> .../gcc.dg/torture/fp-double-convert-float-1.c | 2 +- >>>>>>> gcc/testsuite/lib/target-supports.exp | 16 >>>>>>> ++++++++++++++++ >>>>>>> 2 files changed, 17 insertions(+), 1 deletion(-) >>>>>>> >>>>>>> diff --git a/gcc/testsuite/gcc.dg/torture/fp-double-convert-float-1.c >>>>>>> b/gcc/testsuite/gcc.dg/torture/fp-double-convert-float-1.c >>>>>>> index 1c28a9e101e..7326ae10a9f 100644 >>>>>>> --- a/gcc/testsuite/gcc.dg/torture/fp-double-convert-float-1.c >>>>>>> +++ b/gcc/testsuite/gcc.dg/torture/fp-double-convert-float-1.c >>>>>>> @@ -1,5 +1,5 @@ >>>>>>> /* PR57245 */ >>>>>>> -/* { dg-do run } */ >>>>>>> +/* { dg-do run { xfail { arm*-*-* && { ! arm_softfp_or_dp } } } } */ >>>>>>> /* { dg-require-effective-target fenv } */ >>>>>>> /* { dg-require-effective-target hard_float } */ >>>>>>> /* { dg-additional-options "-frounding-math" } */ >>>>>>> diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/ >>>>>>> lib/target-supports.exp >>>>>>> index 3f428ad5817..b61f77233f2 100644 >>>>>>> --- a/gcc/testsuite/lib/target-supports.exp >>>>>>> +++ b/gcc/testsuite/lib/target-supports.exp >>>>>>> @@ -6352,6 +6352,22 @@ foreach { armfunc armflag armdefs } { >>>>>>> }] >>>>>>> } >>>>>>> +# Return 1 if current target uses soft-float or supports double- >>>>>>> precision FP >>>>>>> +proc check_effective_target_arm_softfp_or_dp { } { >>>>>>> + if { ![istarget arm*-*-*] } { >>>>>>> + return 0 >>>>>>> + } >>>>>>> + >>>>>>> + return [check_no_compiler_messages arm_softfp_or_dp assembly { >>>>>>> + #ifdef __ARM_FP // Not defined => soft float >>>>>>> + # if ((__ARM_FP & 8) == 0) >>>>>>> + # error __ARM_FP indicates that double-precision is not supported >>>>>>> + # endif >>>>>>> + #endif >>>>>>> + int main (void) { return 0; } >>>>>>> + } "" ] >>>>>>> +} >>>>>>> + >>>>>>> # Return 1 if GCC was configured with --with-mode= >>>>>>> proc check_effective_target_default_mode { } { >>>>>> >>>>>> I think I'd rather the test be called arm_mixed_fp (ie a mix of hard and >>>>>> softfp). The logic for that is inverted from your current test, but >>>>>> then you don't need the inversion when you use the test for the xfail. >>>>>> >>>>>> OK with that change. >>>>> >>>> >>>> Looks like we all forgot to request an entry in sourcebuild.texi for the >>>> new effective-target :-( >>> >>> Ouch, missed that one :(. I'll send a followup patch for that shortly. >>> >>>> >>>> My other question is more for Richard: I'm confused after reading the PR, >>>> arm_softfp_or_dp is the name you suggested there, so you changed your mind >>>> to arm_mixed_fp? >>>> >>>> But don't we want to make sure HW DP is supported? >>>> Why do we want this to be OK in the soft-FP case? >>>> The testcase has: >>>> /* { dg-require-effective-target hard_float } */ >>> >>> When I inverted the logic, the function looks like this: >>> >>> # Return 1 if current target supports both single- and double-precision FP >>> proc check_effective_target_arm_mixed_fp { } { >>> if { ![istarget arm*-*-*] } { >>> return 0 >>> } >>> >>> return [check_no_compiler_messages arm_mixed_fp assembly { >>> #ifndef __ARM_FP >>> # error __ARM_FP not defined >>> #elif ((__ARM_FP & 0xc) == 0xc) >>> # error __ARM_FP indicates that both single- and double-precision >>> FP are supported >>> #endif >>> int main (void) { return 0; } >>> } "" ] >>> } >>> >> >> I would have thought this could be simplified to >> >> // Mixed FP means we have hw FP, but only for SFmode (ignores HFmode) >> #if !defined(__ARM_FP) || (__ARM_FP & 0xc) != 0x4) >> #error Not mixed FP >> #endif > > Well, that's a different way to describe the same state. > My way detects that DP is set but SP is not. Maybe that's not a case we need > to worry about? >
I don't think so. In the unlikely scenario that we had a CPU with double-precision floats but no single-precision, I think it would be highly unlikely that we'd handle that with software emulation of the single-precision values: we'd simply promote to double and convert back afterwards - much like we do for half-precision. R. > Kind regards, > Torbjörn > >> >> >> R. >> >>> >>> This means, that only the case where FPU is selected and it supports both >>> SP and DP, then the check will succeed. >>> >>> Did I misunderstand the intention of the request to invert here? >>> >>> Kind regards, >>> Torbjörn >>> >>>> >>>> >>>> Thanks, >>>> >>>> Christophe >>>> >>>>> Pushed as r16-8549-g3d30fc2f73ccc1. >>>>> >>>>> I'll pick this for releases/gcc-15 mid next week unless I see a >>>>> regression report. >>>>> >>>>> Kind regards, >>>>> Torbjörn >>>>> >>>>>> >>>>>> R. >>>>> >>>> >>> >> >
