https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126467

--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <[email protected]>:

https://gcc.gnu.org/g:2fb55e1d061ab091beafa04b2050c88f8d8d64bf

commit r17-3158-g2fb55e1d061ab091beafa04b2050c88f8d8d64bf
Author: Roger Sayle <[email protected]>
Date:   Sun Aug 9 08:00:06 2026 +0200

    PR tree-optimization/126467: 0.0-x -> -x vs. signed zeros in match.pd.

    This is my proposed solution to PR tree-optimization/126467, where we're
    inappropriately converting 0.0 - x to -x when we honor IEEE signed zeros.
    This transformation is valid with -Ofast, but by default +0.0 - +0.0
    should return +0.0, but -(+0.0) is -0.0.  Likewise when x is NaN, 0.0 - x
    may change the payload, but -x is guaranteed not to.  My fix is to
    separate the logic for this transformation from that for FP addition.

    Technically, we could do slightly better by introducing a
    tree_expr_negative_p (complementing and mutually recursive with the
    existing tree_expr_nonnegative_p), but that's a bigger change and
    less suitable for backporting to release branches, i.e. a follow-up.

    I agree with Alexander Monakov that an alternate fix might be to
    correctly reuse the existing fold_real_zero_addition_p functionality
    by constructing and garbage collecting a NEGATE_EXPR tree on each call,
    but this seems a little less efficient.

    2026-08-09  Roger Sayle  <[email protected]>
                Andrea Pinski  <[email protected]>

    gcc/ChangeLog
            PR tree-optimization/126467
            * match.pd (0.0 - x -> -x): Update the conditions under which
            the transformation is performed, disallowing x = +0.0 when we
            honor signed zeros.  This is still disallowed if x is a NaN.

    gcc/testsuite/ChangeLog
            PR tree-optimization/126467
            * gcc.dg/pr126467-1.c: New test case.
            * gcc.dg/pr126467-2.c: Likewise.
            * gcc.dg/pr96392.c: Fix incorrect test case.

Reply via email to