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

["amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Andrew Macleod from comment #9)
> > (In reply to Jakub Jelinek from comment #8)
> > > Unfortunately that would mean for the non-equality cases that if
> > > lhs.undefined_p () we don't return undefined but false (aka VARYING).
> > > Another option is to add those if (op?.undefined_p ()) return false; to both
> > > case BRS_TRUE: and case BRS_FALSE:.
> > 
> > Well, if the LHS is undefined, (or even one of the operands) we are
> > typically in dead code or edge anyway.. I'm not sure it really matters?
> 
> Ok, I'll test the patch then.
> 
> > An alternate question as well is why is the threader even looking at this
> > impossible path. It should know that the branch can never be true
> 
> I think range-op shouldn't assume nothing will call it with UNDEFINED ranges.

Oh I wasn't suggesting otherwise,we should be bulletproof.  Just wondering why
the threader is spending any time evaluating ranges on a path it should know is
impossible.