Here’s the patch with the modified comment before the rule in match.pd
tree-optimization-121595.patch
Description: Binary data
> On Aug 29, 2025, at 12:53 PM, Richard Biener <richard.guent...@gmail.com> > wrote: > > On Fri, Aug 29, 2025 at 10:56 AM Matteo Nicoli > <matteo.nicoli...@gmail.com> wrote: >> >> 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. > > So we've discussed on IRC and the conclusion was that with default > exception handling !HONOR_SNANS would be sufficient > but alternate exception handling might trap on x + 0.0 when x is > denormal. Ideally we'd have a separate flag for > non-default exception handling, but as-is we don't. > > Please add a comment like > > /* With non-default exception handling denormal + 0.0 might trap. > Otherwise !HONOR_SNANS would be sufficient here. */ > > The patch is OK with that change. > > Richard. > > > >> >> 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 >> >> >>
