[Bug tree-optimization/106967] [13 Regression] ICE in upper_bound, at value-range.h:348 since r13-2713-g917461478d3bb733

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 21 Sep 2022, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967
> 
> --- Comment #12 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #11)
> > Btw,
> > 
> > static inline bool
> > finite_operands_p (const frange &op1, const frange &op2)
> > {
> >   return flag_finite_math_only || (!op1.maybe_isnan () && !op2.maybe_isnan
> > ());
> > }
> > 
> > is wrong, you should either test HONOR_NANS on the range type or even
> > better, do this check in maybe_isnan ().
> 
> 
> Yeah, I need to revisit this.  My patch still stands though, as we need to
> correctly handle definite NANs everywhere.  I'll come back to finite_operands_p
> though.
> 
> > 
> > Btw, since you are "sanitizing" ranges at _set () time for other flag_*,
> > it might be good to simply do that for HONOR_NANS as well so we have a
> > single flag here and always ranges that do not need extra treatment?
> 
> The problem here is that the NAN was explicitly set by a pass (i.e. it's in the
> IL).  Although perhaps frange::set_nan() should just set UNDEFINED?  Is that
> what you had in mind?

Yes.