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