[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

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

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

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #16)
> Created attachment 54224 [details]
> untested patch
> 
> Perhaps this would work.  It solves the testcase, though I think we should
> probably audit the operators that don't use the generic
> range_operator_float::fold_range to make sure they're not doing anything
> silly.
> 
> Note that we could add similar code whenever we drop to a NAN like
> const_binop does:
> 
>       /* Don't constant fold this floating point operation if
> 	 both operands are not NaN but the result is NaN, and
> 	 flag_trapping_math.  Such operations should raise an
> 	 invalid operation exception.  */
>       if (flag_trapping_math
> 	  && MODE_HAS_NANS (mode)
> 	  && REAL_VALUE_ISNAN (result)
> 	  && !REAL_VALUE_ISNAN (d1)
> 	  && !REAL_VALUE_ISNAN (d2))
> 	return NULL_TREE;
> 
> I avoided doing so because an frange of NAN does not count as a singleton so
> it should never be propagated.  If this is a problem, I could add a similar
> tweak.
> 
> What do y'all think?

I suppose it's a good workaround for now and consistent with what CCP
would end up doing.  Ideally we wouldn't restrict lattice propagation
so we can perform simplification of uses (esp. in conditionals) but
just prevent folding the actual computation that causes the overflow
(thus catch it at propagation stage).  As you say how ranger works doesn't
easily allow that, unfortunately.