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

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

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

--- Comment #22 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #20)
> (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.
> 
> Even as a workaround this seems to be quite a big hammer.
> If we want to preserve overflow traps, all we need to arrange is that if
> non-inf operands result in singleton inf we don't treat that result as
> singleton.
> Now, what result one gets in different rounding modes depends on the
> rounding mode,
> in round to nearest it should be +-inf, in round to zero +-max, in round to
> +inf +inf or -max and in round to -inf -inf or +max.  But right now GCC
> doesn't handle the separate rounding modes, it just differentiates between
> -fno-rounding-math where we assume round to nearest and -frounding-math
> where we should consider any rounding mode.

Note that we currently can't represent +-inf or +-max, as we only have two
endpoints.  So that would just be represented as VARYING.

> I think for -frounding-math we already don't treat such results as
> singletons, as we
> end up with ranges like [+max, +inf] or [-inf, -max].
> So, one possible way for -fno-rounding-math -ftrapping-math could be instead
> of making
> the result VARYING just extend the range by one ulp towards 0, i.e. instead
> of singleton
> [+inf, +inf] use [+max, +inf] etc.

This seems reasonable.  So instead of set_varying(), we could do [+max, +inf],
etc.

> Another would be to add some bool flag to frange which would say this is
> never a singleton and just take that flag into account, though perhaps it is
> too risky right now.

That seems easy to get wrong, especially this late in the cycle.

> 
> As for invalid exceptions, that implies result maybe or known NAN, but we
> don't treat
> maybe or known NAN as singletons, do we?  After all, there isn't just a
> single NAN and we don't know which one the result is.  That doesn't mean we
> handle all cases right, say
> if a result of something is only used in __builtin_isnan or similar, we can
> still happily optimized it away.

NANs are never singletons, and maybe_nans either.  See frange::singleton_p:

  if (m_kind == VR_RANGE && real_identical (&m_min, &m_max))
    {
      // Return false for any singleton that may be a NAN.
      if (HONOR_NANS (m_type) && maybe_isnan ())
        return false;
...
    }

Also, all the conditional operators in frange fail to fold if maybe_isnan.  The
only things we fold for sure are:

a) One operand is a known NAN.

b) None of the operands can ever be a NAN *and* we know the answer to the
conditional.

For example, foperator_gt::fold_range:

...
...
  if (op1.known_isnan () || op2.known_isnan ())
    r = range_false (type);
  else if (!maybe_isnan (op1, op2))
    {
      if (real_compare (LE_EXPR, &op1.upper_bound (), &op2.lower_bound ()))
        r = range_true (type);
      else if (!real_compare (LE_EXPR, &op1.lower_bound (), &op2.upper_bound
()))
        r = range_false (type);
      else
        r = range_true_and_false (type);
    }

so... we're pretty careful about NOT folding relationals that have the
possibility of a NAN, and a singleton is only for a known range without a NAN.