On 11/11/2017 03:03 PM, Marc Glisse wrote:
Hello,
with undefined overflow, just because we know nothing about one of the
arguments of an addition doesn't mean we can't say something about the
result. We could constrain more the cases where we replace VR_VARYING
with a full VR_RANGE, but I didn't want to duplicate too much logic.
The 20040409 testcases were introduced to test an RTL transformation, so
I don't feel too bad adding -fwrapv to work around the undefined
overflows they exhibit.
Bootstrap+regtest on powerpc64le-unknown-linux-gnu.
2017-11-13 Marc Glisse <marc.gli...@inria.fr>
gcc/
* tree-vrp.c (extract_range_from_binary_expr_1) [PLUS_EXPR,
MINUS_EXPR]: Use a full range for VR_VARYING.
gcc/testsuite/
PR testsuite/82951
* gcc.c-torture/execute/20040409-1.c: Use -fwrapv.
* gcc.c-torture/execute/20040409-2.c: Likewise.
* gcc.c-torture/execute/20040409-3.c: Likewise.
* gcc.dg/tree-ssa/vrp118.c: New file.
I'm curious about the 4 in the added test case (copied below).
Is there some significance to it or is actually meant to be
(or could it be) a 2?
FWIW, if there's some significance to the 4 then it would be
nice to have a comment there explaining it. If there isn't
any then may I suggest to either change it to 2 or, perhaps
even better, change the second if condition to
(x < -__INT_MAX__ + 3) to make the effect on the range of
x clear and (presumably) also obviate questions like this
one.
Martin
+++ gcc/testsuite/gcc.dg/tree-ssa/vrp118.c (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+void eliminate_me();
+void f(int x,int y){
+ if (y < 4)
+ __builtin_unreachable();
+ x += y;
+ if (x == -__INT_MAX__)
+ eliminate_me ();
+}
+
+/* { dg-final { scan-tree-dump-not "eliminate_me" "optimized" } } */
