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.
