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.
