[PATCH] fold-const: Don't consider NaN non-negative [PR97965]

[Jakub Jelinek]

On Thu, Nov 26, 2020 at 01:56:03PM -0000, Roger Sayle wrote:
> My completely untested solution is the attached patch.  My apologies, I'm
> not
> even set up to compile things on the laptop that I'm composing this e-mail
> on,
> but my notes/proposals on tackling PR97965 are easier expressed as the
> actual
> suggested changes/edits.  [Forgive me if I've made a typo].

Ah, thanks, I wasn't aware of that function.
Looking at the tree_expr_maybe_nan_p implementation, I wonder if:
    case PLUS_EXPR:
    case MINUS_EXPR:
    case MULT_EXPR:
      return !tree_expr_finite_p (TREE_OPERAND (x, 0))
             || !tree_expr_finite_p (TREE_OPERAND (x, 1));
shouldn't try harder, for + and minus, isn't
      return (tree_expr_maybe_nan_p (TREE_OPERAND (x, 0))
	      || tree_expr_maybe_nan_p (TREE_OPERAND (x, 1))
	      || (!tree_expr_finite_p (TREE_OPERAND (x, 0))
		  && !tree_expr_finite_p (TREE_OPERAND (x, 1))));
what we want to test?  I mean, if neither operand is a NaN and
one of the operands is finite, then the result will be either finite
or inf or -inf, but not NaN.  MULT_EXPR would presumably also need to
rule out zeros (i.e. use the *nonzero* APIs too, on the other side
+-inf * +-inf is not NaN).

Another thing, tree_expr_nonzero_warnv_p handles not just trees, but also
GIMPLE, shouldn't these tree_expr_finite_p and tree_expr_maybe_nan_p APIs
be also rewritten so that they can also handle SSA_NAMEs by walking the def
chains?

	Jakub