Dear Richard,
It can trap with sNaN ± 0.0. ±Inf ± 0.0 = ±Inf, so it does not raise an
FE_OVERFLOW (because there’s no overflow of a finite quantity), and qNaN does
not raise an FE_INVALID because it’s quiet.
There’s already a check for sNaN in fold-const.cc
/* Don't allow the fold with -fsignaling-nans. */
if (arg ? tree_expr_maybe_signaling_nan_p (arg) : HONOR_SNANS (type))
return false;
As far as I know, the purpose of this bug fix was to suppress this specific
optimization when the program is compiled with -ftrapping-math flag.
Best regards,
Matteo
> On Aug 28, 2025, at 10:43 AM, Richard Biener <richard.guent...@gmail.com>
> wrote:
>
> On Sat, Aug 23, 2025 at 11:56 PM Matteo Nicoli
> <matteo.nicoli...@gmail.com> wrote:
>>
>> Dear reviewers,
>>
>> I attached a patch for bug 121595
>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121595). I signed it, and
>> added `Reviewed-by: Andrew Pinski <andrew.pin...@oss.qualcomm.com>` (here
>> in CC).
>
> +/* fabs(x + 0.0) -> fabs(x), safe even with signed zeros when
> -fno-trapping-math. */
> +(for op (plus minus)
> + (simplify
> + (abs (op @0 real_zerop@1))
> + (if (!flag_trapping_math)
> + (abs @0))))
>
> so forgive my ignorance, possibly IEEE abs() never raises FP exceptions
> (unless operating on sNaN?)? But does Inf + 0.0 raise FE_OVERFLOW?
> Does NaN + 0.0 raise FE_INVALID?
>
> So what I wonder is whether !HONOR_SNANS (@0) would be enough to check?
>
> I refrained from trusting AI on those questions ...
>
> Richard.
>
>> Best regards,
>> Matteo
>>
>>
