[Bug tree-optimization/110755] [13/14 Regression] Wrong optimization of fabs on ppc64el at -O1

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:21da32d995c8b574c929ec420cd3b0fcfe6fa4fe

commit r14-2782-g21da32d995c8b574c929ec420cd3b0fcfe6fa4fe
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Jul 26 10:50:50 2023 +0200

    range-op-float: Fix up -frounding-math frange_arithmetic +- handling
[PR110755]

    IEEE754 says that x + (-x) and x - x result in +0 in all rounding modes
    but rounding towards negative infinity, in which case the result is -0
    for all finite x.  x + x and x - (-x) if it is zero retain sign of x.
    Now, range_arithmetic implements the normal rounds to even rounding,
    and as the addition or subtraction in those cases is exact, we don't do any
    further rounding etc. and e.g. on the testcase below distilled from glibc
    compute a range [+0, +INF], which is fine for -fno-rounding-math or
    if we'd have a guarantee that those statements aren't executed with
rounding
    towards negative infinity.

    I believe it is only +- which has this problematic behavior and I think
    it is best to deal with it in frange_arithmetic; if we know -frounding-math
    is on, it is x + (-x) or x - x and we are asked to round to negative
    infinity (i.e. want low bound rather than high bound), change +0 result to
    -0.

    2023-07-26  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/110755
            * range-op-float.cc (frange_arithmetic): Change +0 result to -0
            for PLUS_EXPR or MINUS_EXPR if -frounding-math, inf is negative and
            it is exact op1 + (-op1) or op1 - op1.

            * gcc.dg/pr110755.c: New test.