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.

0 files changed, 0 insertions, 0 deletions