[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647

--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> Perhaps just adding if (op2.undefined_p ()) return false; above most of the
> switch (get_bool_state (r, lhs, type)) lines (in methods that refer to op2;
> and similarly for op1) for the comparison operators.

This feels like the right approach.  We also do something similar in some of
the binary operators.  For example, plus/minus_expr do:

  if (lhs.undefined_p ())
    return false;

For this testcase we have:

[0,0] = UNDEFINED < op2

I don't think we can determine anything for op2 in this situation, so the right
thing would be to return false, which amounts to returning VARYING.

The binary operators would also have to handle operators of undefined, but
those seem to all have gates on singleton_p() or go through the fold_range()
routine for the inverse operation, so they'd be handled correctly.

So yeah, it looks like just handling the op[12]_range operators above the
get_bool_state would do the trick.

Hmmm, it seems like there are 2 operators that have possible problematic
handling of op2.undefined_p():

1. operator_cast::op1_range (irange &r, tree type,

   The assert looks at the op2 type.  That will ICE with an UNDEFINED.

   The truncating_cast_p path will also look at op2's type blindly.

2. operator_bitwise_xor::op1_range

  Imagine: [0,0] = x ^ UNDEFINED

  op1_range won't ICE, but it will do:

        case BRS_FALSE:
          r = op2;

  I don't think we know anything about x in this case.  Though if, op2 is
UNDEFINED, I guess it
  wouldn't hurt to assume op1 is also UNDEFINED.

   Also earlier in the function, for:

     UNDEFINED = x ^ op2

   will return x = UNDEFINED for any op2.  

So at least #1 would also have to be handled because it could ICE.

Also, range-op-float.cc needs the same treatment prior all the get_bool_state
calls.

As you mention, another alternative would be to always call
empty_range_varying, as we're doing for abs::op[12]_range:

  if (empty_range_varying (r, type, lhs, op2))
    return true;

Thoughts?  Andrew?

Hmmm, I wonder why we haven't tripped over this scenario in past releases (LHS
being defined, but op2 being UNDEFINED).