[Bug tree-optimization/109008] [13 Regression] Wrong code in scipy package since r13-3926-gd4c2f1d376da6f

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

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

--- Comment #44 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #43)
> Created attachment 54622 [details]
> gcc13-pr109008-2.patch
> 
> Above mentioned incremental patch.  It does actually 2 things.  One is not
> widening to -inf or +inf, but to nextafter value in a hypothetical wider
> floating point type with equal mantissa precision but wider exponent range.
> And the other is, as the new test in that patch shows, that regardless
> whether
> we do the above optimization or not, with -ffinite-math-only it would still
> be miscompiled, as we limit the range to the maximum representable value and
> so
> on the resulting range in this case we get with vanilla trunk
> [frange] double
> [-1.9958403095347198116563727130368385660674512604354575415e+292
> (-0x0.8p+972), 0.0 (0x0.0p+0)] range.  That is incorrect, __DBL_MAX__ +
> 0x0.fffffffffffff8p+970 when rounding to nearest is still finite
> (__DBL_MAX__),
> and so valid for -ffinite-math-only.

Note the widening is supposed to undo a round-to-nearest operation so
if the rounded value is finite then the original unrounded value is
necessarily so as well, no?  But sure, it can be bigger than __DBL_MAX__,
but not by much.

> There is another issue.  For !MODE_HAS_INFINITIES (TYPE_MODE (type)) types
> I'm afraid this is still broken and significantly more so.  Because the
> minimum or maximum representable values in those cases (probably, haven't
> played with such machines) act as saturation boundaries (like infinities
> normally), WHATEVER_MAX + anything_positive is still WHATEVER_MAX etc.
> So, wonder if we e.g. shouldn't just punt in float_binary_op_range_finish
> for such modes if lhs range has at least one of the boundaries the maximum
> representable one.  Though, maybe it isn't limited to the reverse ops, who
> knows...

But if we avoid "rounding" our widened range to the target format then
within real.cc it should be all fine to go beyond __DBL_MAX__ (whether
the mode has infinities or not), no?

As said elsewhere it would be nice to re-compute the forward range op
and see whether the re-computed LHS range covers the original LHS fully
(so we're at least conservative here).