https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #27 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #26)
> (In reply to Aldy Hernandez from comment #24)
> > If you single step from there on, we run into:
> >
> > if (gimple_stmt_nonnegative_warnv_p (call, &strict_overflow_p))
> > r.set_nonnegative (type);
> > else if (gimple_call_nonnull_result_p (call)
> > || gimple_call_nonnull_arg (call))
> > r.set_nonzero (type);
> > else
> > r.set_varying (type);
> >
> > IIRC, we had some discussion upstream about the meaning of set_nonnegative,
> > and we all agreed that nuking -NAN was the right thing. Neat, huh? :)
>
> Is this done only for statements for which there isn't a ranges handler?
> If so, given the IEEE 754 non-guarantee of NAN signs except for copy, abs,
> copysign and negate I'd say that we should have a ranges handler for all
> those ops and for anything else assume NAN sign is VARYING, including the
> above spot.
We're doing this for all GIMPLE_CALL's, so copy, abs, copysign are handled
separately, either as builtins or in the IL directly (i.e. not calls). Hmmm,
maybe it's time to revisit what frange::set_nnonnegative() means (again).
Lemme think about this...there are very few set_nonnegative() calls in ranger.
It should be easy to contain.
> As for signed zeros in -fsigned-zeros (default) mode, wonder if we e.g. don't
> say sqrt is nonnegative (even when sqrt (-0.0) is -0.0).
It seems tree_call_nonnegative_warnv_p is already doing the right thing for
sqrt?
CASE_CFN_SQRT:
CASE_CFN_SQRT_FN:
/* sqrt(-0.0) is -0.0. */
if (!HONOR_SIGNED_ZEROS (type))
return true;
return RECURSE (arg0);
