https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67052
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot
com> ---
The uses of the *nonnegative* functions should be removed to determine
what semantics are expected for for floating-point arguments.
If the semantics are "sign bit is 0", NaNs should return according to
their sign bit (and -0 should return false). If the semantics are "value
>= 0", NaNs should always return false, but -0 should return true. If
the semantics are "!(value < 0)", NaNs should return true, as should -0.
It's possible different places expect different semantics.
> /* Convert ABS_EXPR<x> < 0 to false. */
> strict_overflow_p = false;
> if (code == LT_EXPR
> && (integer_zerop (arg1) || real_zerop (arg1))
> && tree_expr_nonnegative_warnv_p (arg0, &strict_overflow_p))
> {
> if (strict_overflow_p)
> fold_overflow_warning (("assuming signed overflow does not occur "
> "when simplifying comparison of "
> "absolute value and zero"),
> WARN_STRICT_OVERFLOW_CONDITIONAL);
> return omit_one_operand_loc (loc, type,
> constant_boolean_node (false, type),
> arg0);
Omitting an ordered NaN comparison with 0 also loses an exception (if
flag_trapping_math && HONOR_NANS) (as does an equality comparison in the
case of signaling NaNs). (Modulo the unresolved discussion in the thread
starting at
<https://gcc.gnu.org/ml/gcc-patches/2015-02/threads.html#00555> of which
sort of comparison LTGT should be, and so which existing code handling it
the other way is buggy.)
