https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126464
--- Comment #14 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-13 branch has been updated by Jakub Jelinek <[email protected]>: https://gcc.gnu.org/g:de161ea6d7522cc945cb2fe30f90304bbc6affbf commit r13-10447-gde161ea6d7522cc945cb2fe30f90304bbc6affbf Author: Jakub Jelinek <[email protected]> Date: Thu Jul 30 09:56:41 2026 +0200 range-op-float: Fix up inf handling in reverse narrowing float to float cast [PR126464] 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. 2026-07-30 Jakub Jelinek <[email protected]> PR tree-optimization/126464 * range-op-float.cc (float_widen_lhs_range): Add also_inf argument defaulted to false, if true, extend even lb of +inf and ub of -inf. * gcc.dg/pr126464.c: New test. Reviewed-by: Richard Biener <[email protected]> (cherry picked from commit 3754582630fa1eeff44a39f656ba0c7db6e58d0d)
