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)
FAIL: gcc.dg/wcaselabel-1.c (test for errors, line 10)
And then there is a -fnon-call-exceptions testcase
FAIL: gcc.c-torture/execute/20101011-1.c -O1 execution test
FAIL: gcc.c-torture/execute/20101011-1.c -O2 execution test
FAIL: gcc.c-torture/execute/20101011-1.c -O2 -flto
-fno-use-linker-plugin -flt
o-partition=none execution test
FAIL: gcc.c-torture/execute/20101011-1.c -O2 -flto -fuse-linker-plugin
-fno-fa
t-lto-objects execution test
FAIL: gcc.c-torture/execute/20101011-1.c -O3 -g execution test
FAIL: gcc.c-torture/execute/20101011-1.c -Os execution test
which tests that 0/0 traps (on targets where it does). This shows
we might want to guard the simplifications against -fnon-call-exceptions.
The other way to fix the inconsistency is of course to not rely
on undefinedness in 0 % x simplification and disable that if x
is not known to be nonzero. We can introduce the other transforms
with properly guarding against a zero 2nd operand as well.
So - any opinions here?
Note that currently, VRP optimizes 0/0 to 0 (but not 0%0) when we don't
pass -fnon-call-exceptions.
If we guard with !flag_non_call_exceptions || tree_expr_nonzero_p(...),
the transformation seems safe for the middle-end, so the main issue is
front-ends.
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.
But as long as we don't always perform the simplification, we need some
other way to break the cycle for PR70992.
--
Marc Glisse
