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

[Richard Biener <rguenther@suse.de>]

On Thu, 9 Jun 2016, Marc Glisse wrote:

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

I think I can live with testing 
tree_expr_nonzero_p for flag_non_call_exceptions (or just disabling
the pattern for flag_non_call_exceptions).  But the literal zero
or the GIMPLE check isn't what I'd like to see.  I want to understand
the FE requirements some more and esp. understand why delayed folding
makes this still an issue.  [as much as the C FE now figures out
what is an lvalue or rvalue before folding the FEs should figure out
whether sth is a constexpr or not before folding - that should be
doable without doing any folding, see my examples in the other mail
about undefined behavior]

> (or something similar at a different level in the call chain of course)
> 
> (not that this helps in any way for the PR...)

Not with -fnon-call-exceptions at least.  I just mentioned the PR to
get some attention ;)

Richard.