Be even more conservative in intersection of NANs.

Intersecting two ranges where one is a NAN is keeping the sign bit of
the NAN range.  This is not correct as the sign bits may not match.

I think the only time we're absolutely sure about the intersection of
a NAN and something else, is when both are a NAN with exactly the same
properties (sign bit).  If we're intersecting two NANs of differing
sign, we can decide later whether that's undefined or just a NAN with
no known sign.  For now I've done the latter.

I'm still mentally working on intersections involving NANs, especially
if we want to keep track of signbits.  For now, let's be extra careful
and only do things we're absolutely sure about.

Later we may want to fold the intersect of [NAN,NAN] and say [3,5]
with the posibility of NAN, to a NAN, but I'm not 100% sure.  As I've
said before, setting varying is always a safe choice, because it means
we know nothing and ranger won't attempt to optimize anything.

gcc/ChangeLog:

	* value-range.cc (early_nan_resolve): Remove.
	(frange::intersect): Handle NANs.

0 files changed, 0 insertions, 0 deletions