On Sun, 12 Nov 2017, Martin Sebor wrote:
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.
I picked 4 (I was too lazy to type '2' and make it the usual 42) so there
would be some margin, and people reading the testcase (i.e. me) wouldn't
need to think too hard to know that -INT_MAX (shorter to type than
-INT_MAX-1) falls in the forbidden region. Otherwise I would need to think
if the inequality is strict, if I may have an off-by-1 error, etc. The
goal is to check if a range computation is happening at all, not to check
the exact bounds computed. If we want to make it tight, I guess we could
test y<=0 and x==-INT_MAX-1 for instance.
My first idea was a test that -z can never be INT_MIN, but we have
transformations that move negate_expr to the other side of comparisons, so
that was more complicated to test than the addition.
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" } } */
--
Marc Glisse
