On Wed, Jun 8, 2016 at 11:16 AM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Wed, 8 Jun 2016, Richard Biener wrote: > >> The following works around PR70992 but the issue came up repeatedly >> that we are not very consistent in preserving the undefined behavior >> of division or modulo by zero. Ok - the only inconsistency is >> that we fold 0 % x to 0 but not 0 % 0 (with literal zero). >> >> After folding is now no longer done early in the C family FEs the >> number of diagnostic regressions with the patch below is two. >> >> FAIL: g++.dg/cpp1y/constexpr-sfinae.C -std=c++14 (test for excess errors)
Yep. We don't want to fold away undefined behavior in a constexpr function, since constexpr evaluation wants to detect undefined behavior and treat the expression as non-constant in that case. > 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. Jason
