Re: [PATCH] Fold x/x to 1, 0/x to 0 and 0%x to 0 consistently

[Marc Glisse <marc dot glisse at inria dot fr>]

On Wed, 8 Jun 2016, Jakub Jelinek wrote:

> On Wed, Jun 08, 2016 at 01:43:56PM -0400, Jason Merrill wrote:
> > > A few random ideas I was considering:
> > > * restrict it to GIMPLE, so we can't have a regression in the front-ends.
> > > * fold x/0 to 0 with TREE_OVERFLOW set, to tell the front-end that something
> > > is going on.
> > > * fold to (x/y,0) or (x/y,1) so the division by 0 is still there, but C++11
> > > constexpr might give a strange message about it, and folding might not be
> > > idempotent.
> >
> > Any of these would avoid the constexpr regression, though the second
> > would make the diagnostic worse.  Or the front end could copy
> > constexpr function bodies before folding.
>
> Or, both cxx_eval_binary_expression and cp_fold would need to
> not fold if the divisor is integer_zerop.

Ah, right, I think I understand the current condition for folding 0%X now. 
It is meant for warnings, not validity, and with delayed folding, we can 
only have issues with 0%0, we cannot miss warnings or constexpr-UB by 
folding 0%X, since if we were going to discover that X is 0 early enough 
to warn (or in constexpr evaluation) we would have discovered it before 
the call to fold.

If I got it right, that means the condition could actually be, instead of 
!integer_zerop (@1):

flag_non_call_exceptions ? tree_expr_nonzero_p (@1) :
 (GIMPLE || !integer_zerop (@1))

(or something similar at a different level in the call chain of course)

(not that this helps in any way for the PR...)

--
Marc Glisse