https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Comment #10 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
This is interesting.
We are trying to thread 5->7->8->9->3->??.
The path 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. However, op1 ==
op2 and op2 being a NAN is an impossible scenario.
We are ICEing because frange::set_nan() sees the NAN and the desire to set the
NAN flag to NO. I thought this would never happen, but alas it happens in
threading. I think 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.
