On Fri, Aug 29, 2025 at 2:20 PM Matteo Nicoli
<matteo.nicoli...@gmail.com> wrote:
>
> Here’s the patch with the modified comment before the rule in match.pd
OK. Do you have git access? Btw, the ChangeLog is currently wrong:
Subject: [PATCH] tree-optimization/121595 - the optimization fabs(a+0.0) ->
fabs(a) should apply only for non trapping case
* added a match expression
- gcc/match.pd
* added tests
- gcc/testsuite/gcc.dg/fabs-plus-zero-1.c
- gcc/testsuite/gcc.dg/fabs-plus-zero-2.c
there's a missing patch description and the changlog part should look like this:
PR tree-optimization/121595
* match.pd (fabs(a + 0.0) -> fabs (a)): New pattern.
* gcc.dg/fabs-plus-zero-1.c: New testcase.
* gcc.dg/fabs-plus-zero-2.c: Likewise.
>
>
> > 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
> >>
> >>
> >>
>
