[Bug tree-optimization/126464] [13/14/15 Regression] wrong code with FP ranges since r13-3926

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:46b25706b7af8f8843c3dd88bbf59c5b44de0ac1

commit r15-11443-g46b25706b7af8f8843c3dd88bbf59c5b44de0ac1
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Jul 31 08:56:03 2026 +0200

    range-op-float: Fix up inf handling in other reverse ops [PR126464]

    On Thu, Jul 30, 2026 at 09:31:17AM +0200, Richard Biener wrote:
    > > The following testcase is miscompiled since my r16-1108 change.
    > > The problem is if we handle a reverse of a narrowing float to float
cast
    > > (in the example there are double -> float and long double -> double
    > > cast) and the lhs range is [-inf, -inf] or [+inf, +inf] (note,
regardless
    > > of whether some NaNs are allowed or not, so not necessarily
    > > lhs.known_isinf ()), then handling that range in the wider type also
    > > as [-inf, -inf] or [+inf, +inf] is wrong, e.g. for the double -> float
    > > conversion, [-inf, -0x0.ffffff8p+128] double range could map to just
    > > that [-inf, -inf].  We have already float_widen_lhs_range function
    > > but that just extends the range by +/-1ulp or 0.5ulp if the bounds
    > > are finite.  If the range isn't singleton (except for optional NaN),
    > > then the minimum (or maximum) finite is already in the range, so this
just
    > > extends the case where they are singleton.
    > > I don't know how to portably figure out that 0x0.ffffff8p+128 for
    > > double -> float (especially when in float_widen_lhs_range we don't know
    > > yet the wider type), so the patch just uses the +/-1ulp extension (i.e.
    > > [-inf, min_finite] or [+inf, max_finite] case.

    On a second thought, this actually isn't specific to just reverse of
    narrowing float to float casts, it is a problem for any other reverse
binary
    ops too.

    E.g. the following testcase is miscompiled at -O2 since
r13-3926-gd4c2f1d376da
    (but works with -O0).  The lhs of the addition is [-inf, -inf], one of its
    operand is [-1e304, -1e300] and we think the other operand has to be
    [-inf, -inf].  That is obviously wrong, even much larger operands can
result
    in -inf, anything below -DBL_MAX + -1e300 where x + -1e300 doesn't round to
    -DBL_MAX or higher but to -inf.

    So, the following patch just widens lb of +inf and ub of -inf by 1ulp for
    all callers (and thus doesn't need the also_inf argument.

    2026-07-31  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/126464
            * range-op-float.cc (float_widen_lhs_range): Remove also_inf
            argument, replace its uses as if it was always true.

            * gcc.dg/torture/pr126464.c: New test.

    Reviewed-by: Richard Biener <rguenth@suse.de>
    (cherry picked from commit 6f32166346de2d1c0f6253e4fe37e8a6edac655d)