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.
