https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r6-3811-g68e57f040c6330eb853551622d458a67d6f9e572 on this
testcase,
but as pointed out tree_binary_nonnegative_warnv_p needs to be more careful.
Given that tree_single_nonnegative_warnv_p may return true on REAL_CST NaN
literal with sign bit unset, one question is if e.g. such NaN +
nonnegative_value or nonnegative_value + such NaN could result in NaN result
with negative sign, in that case even PLUS_EXPR
if (FLOAT_TYPE_P (type))
return RECURSE (op0) && RECURSE (op1);
would be incorrect and we'd need to guard it with && !tree_expr_maybe_nan_p
(op0) && !tree_expr_maybe_nan_p (op1).
Then there is the MULT_EXPR x * x case, that might suffer from similar problem
to PLUS_EXPR if NaN with positive sign * NaN with positive sign can result in
NaN with negative sign. Then there is the MULT_EXPR RECURSE (op0) && RECURSE
(op1) case, that
one can certainly result in possibly NaN if one operand is 0 and another +inf,
so
we'd need to guard it for FLOAT_TYPE_P with
(tree_expr_nonzero_warnv_p (op0, strict_overflow_p) ||
!tree_expr_maybe_infinite_p (op1))
&& (tree_expr_nonzero_warnv_p (op1, strict_overflow_p) ||
!tree_expr_maybe_infinite_p (op0))
And then RDIV_EXPR, again corresponding checks.
