https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125039
--- Comment #11 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-15 branch has been updated by Jakub Jelinek <[email protected]>: https://gcc.gnu.org/g:d4b40362327691b903fee90c01fe9586d2b60ecf commit r15-11225-gd4b40362327691b903fee90c01fe9586d2b60ecf Author: Jakub Jelinek <[email protected]> Date: Tue Apr 28 09:28:44 2026 +0200 range-op-float: Fix ICE on undefined_p ranges [PR125039] The following testcase ICEs at -O1 since r14-4153. lower_bound/upper_bound methods on frange (and others) assert they aren't called on undefined_p () ranges, because such ranges don't really have any lower or upper bound. Most fold_range virtual methods call empty_range_varying early which checks if the operand ranges aren't undefined and in that case return true and set r to varying, and then can safely use lower_bound/upper_bound etc. Now, operator_not_equal::fold_range did that until r14-4152 indirectly, by calling it in frelop_early_resolve which it called unconditionally. r14-4153 changed it not to call frelop_early_resolve in some cases because it could misbehave as mentioned in the comment. frelop_early_resolve has 3 conditionals it handles. if (!maybe_isnan (op1, op2) && relation_union (rel, my_rel) == my_rel) doesn't apply for this case, because the if (rel == VREL_EQ && maybe_isnan (op1, op2)) condition means maybe_isnan (op1, op2) will be true. if (relation_intersect (rel, my_rel) == VREL_UNDEFINED) is the condition which r14-4153 wanted to avoid. And finally if (empty_range_varying (r, type, op1, op2)) is the condition the following patch readds, so that we don't ICE on those. 2026-04-27 Jakub Jelinek <[email protected]> PR tree-optimization/125039 * range-op-float.cc (operator_not_equal::fold_range): Call empty_range_varying when not calling frelop_early_resolve. * gcc.c-torture/compile/pr125039.c: New test. Reviewed-by: Richard Biener <[email protected]> (cherry picked from commit 62d5880b9599c3bdbc22b80d522b0bea14f4beaf)
