https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126464
--- Comment #13 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-14 branch has been updated by Jakub Jelinek <[email protected]>: https://gcc.gnu.org/g:db8b415de6b3eb6ebcad50c8f8d4e386ccc09ef7 commit r14-12790-gdb8b415de6b3eb6ebcad50c8f8d4e386ccc09ef7 Author: Jakub Jelinek <[email protected]> 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 <[email protected]> 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 <[email protected]> (cherry picked from commit 6f32166346de2d1c0f6253e4fe37e8a6edac655d)
