https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824
--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Aldy Hernandez <al...@gcc.gnu.org>: https://gcc.gnu.org/g:ba0db24386107ffa237a2af0d1fdef9030460157 commit r13-2444-gba0db24386107ffa237a2af0d1fdef9030460157 Author: Aldy Hernandez <al...@redhat.com> Date: Mon Sep 5 15:28:55 2022 +0200 Do not ICE when updating a NAN to a non-NAN. Updating a definite NAN to a definitely not NAN was an assertion failure, but it turns out we can have such a scenario while attempting to thread an impossible path. This patch updates the range to undefined. What happens in the testcase is that we are trying to thread path that starts like this: <bb 5> [local count: 81335936906]: SR.30_3 = Nan; goto <bb 7>; [100.00%] <bb 7> [local count: 108447915740]: # SR.30_25 = PHI <SR.30_3(5), SR.30_12(6)> plus_33 = SR.30_25; w1$value__13 = f_distance$D2421$value__1; w2$value__14 = plus_33; if (w1$value__13 == w2$value__14) goto <bb 8>; [50.00%] else goto <bb 9>; [50.00%] On the path, SR.30_25 is NAN, which ultimately makes w2$value__14 a NAN. This means that the 7->8 is impossible on the path. On the true arm (foperator_equal::op1_range) we are asserting that op1 (w1$value__13) is a !NAN because for the == conditional to succeed, neither operand can be a NAN. But...we know that operand 2 is a NAN. This is an impossible scenario. We are ICEing because frange::set_nan() sees the NAN and the desire to set the NAN flag to NO. The correct thing to do is to set the range to undefined, which is basically unreachable, and will cause all the right things to happen. For that matter, the threader will see that an UNDEFINED range was calculated in the path and abort trying to investigate paths in that direction. PR middle-end/106824 gcc/ChangeLog: * value-range.cc (frange::set_nan): Set undefined when updating a NAN to a non-NAN. gcc/testsuite/ChangeLog: * g++.dg/pr106824.C: New test.
