[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596

aldyh at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Thu Nov 10 12:47:25 GMT 2022


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);


More information about the Gcc-bugs mailing list