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