[PATCH] Don't ICE on symbolic ranges in VRP (PR tree-optimization/68455)

[PATCH] Don't ICE on symbolic ranges in VRP (PR tree-optimization/68455)

[Marek Polacek]

We blow up on the following testcase because we find ourselves passing
[_13 + 1, INT_MAX] as a vr1 to extract_range_from_multiplicative_op_1;
that's bad because this function immediately calls vrp_int_const_binop
which just doesn't work for symbolic ranges, it only wants int_csts.

This started with Richards S.'s changes in r228614 -- we're now since
able to recurse into SSA names, thus get better info about ranges.
That means that range_includes_zero_p in extract_range_from_binary_expr_1
for the *_DIV_EXPR cases was able to determine that the range doesn't
include zero, so we went through a different code path and ended up
calling extract_range_from_multiplicative_op_1 even with symbolic ranges.

I couldn't come up with anything better than checking that we're dealing
with nonsymbolic ranges for such a case.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2015-11-23  Marek Polacek  <polacek@redhat.com>

	PR tree-optimization/68455
	* tree-vrp.c (extract_range_from_binary_expr_1): Don't call
	extract_range_from_multiplicative_op_1 on symbolic ranges.

	* gcc.dg/tree-ssa/pr68455.c: New test.

diff --git gcc/testsuite/gcc.dg/tree-ssa/pr68455.c gcc/testsuite/gcc.dg/tree-ssa/pr68455.c
index e69de29..6b46b30 100644
--- gcc/testsuite/gcc.dg/tree-ssa/pr68455.c
+++ gcc/testsuite/gcc.dg/tree-ssa/pr68455.c
@@ -0,0 +1,19 @@
+/* PR tree-optimization/68455 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int r;
+int n;
+
+void
+fn1 (void)
+{
+  int i;
+
+  for (i = 0; i < 1; ++i)
+    {
+      unsigned short int u;
+      if (u < n)
+	r = 1 / n;
+    }
+}
diff --git gcc/tree-vrp.c gcc/tree-vrp.c
index 7001190..acbb70b 100644
--- gcc/tree-vrp.c
+++ gcc/tree-vrp.c
@@ -3015,7 +3015,7 @@ extract_range_from_binary_expr_1 (value_range *vr,
 	      return;
 	    }
 	}
-      else
+      else if (!symbolic_range_p (&vr0) && !symbolic_range_p (&vr1))
 	{
 	  extract_range_from_multiplicative_op_1 (vr, code, &vr0, &vr1);
 	  return;

	Marek

Re: [PATCH] Don't ICE on symbolic ranges in VRP (PR tree-optimization/68455)

[Richard Biener]

On November 23, 2015 5:31:11 PM GMT+01:00, Marek Polacek <polacek@redhat.com> wrote:
>We blow up on the following testcase because we find ourselves passing
>[_13 + 1, INT_MAX] as a vr1 to extract_range_from_multiplicative_op_1;
>that's bad because this function immediately calls vrp_int_const_binop
>which just doesn't work for symbolic ranges, it only wants int_csts.
>
>This started with Richards S.'s changes in r228614 -- we're now since
>able to recurse into SSA names, thus get better info about ranges.
>That means that range_includes_zero_p in
>extract_range_from_binary_expr_1
>for the *_DIV_EXPR cases was able to determine that the range doesn't
>include zero, so we went through a different code path and ended up
>calling extract_range_from_multiplicative_op_1 even with symbolic
>ranges.
>
>I couldn't come up with anything better than checking that we're
>dealing
>with nonsymbolic ranges for such a case.
>
>Bootstrapped/regtested on x86_64-linux, ok for trunk?

Hmm.  I think we can do better if vr0 is symbolical - use min, max for it.

I suppose it would be best to implement a get_integer_range () function doing that or also looking at equivalences if we are getting a symbolic range.

Anyway, those are future enhancements that shouldn't block this patch.

Thus OK.

Richard.

>2015-11-23  Marek Polacek  <polacek@redhat.com>
>
>	PR tree-optimization/68455
>	* tree-vrp.c (extract_range_from_binary_expr_1): Don't call
>	extract_range_from_multiplicative_op_1 on symbolic ranges.
>
>	* gcc.dg/tree-ssa/pr68455.c: New test.
>
>diff --git gcc/testsuite/gcc.dg/tree-ssa/pr68455.c
>gcc/testsuite/gcc.dg/tree-ssa/pr68455.c
>index e69de29..6b46b30 100644
>--- gcc/testsuite/gcc.dg/tree-ssa/pr68455.c
>+++ gcc/testsuite/gcc.dg/tree-ssa/pr68455.c
>@@ -0,0 +1,19 @@
>+/* PR tree-optimization/68455 */
>+/* { dg-do compile } */
>+/* { dg-options "-O2" } */
>+
>+int r;
>+int n;
>+
>+void
>+fn1 (void)
>+{
>+  int i;
>+
>+  for (i = 0; i < 1; ++i)
>+    {
>+      unsigned short int u;
>+      if (u < n)
>+	r = 1 / n;
>+    }
>+}
>diff --git gcc/tree-vrp.c gcc/tree-vrp.c
>index 7001190..acbb70b 100644
>--- gcc/tree-vrp.c
>+++ gcc/tree-vrp.c
>@@ -3015,7 +3015,7 @@ extract_range_from_binary_expr_1 (value_range
>*vr,
> 	      return;
> 	    }
> 	}
>-      else
>+      else if (!symbolic_range_p (&vr0) && !symbolic_range_p (&vr1))
> 	{
> 	  extract_range_from_multiplicative_op_1 (vr, code, &vr0, &vr1);
> 	  return;
>
>	Marek

Re: [PATCH] Don't ICE on symbolic ranges in VRP (PR tree-optimization/68455)

[Marek Polacek]

On Mon, Nov 23, 2015 at 05:40:14PM +0100, Richard Biener wrote:
> On November 23, 2015 5:31:11 PM GMT+01:00, Marek Polacek <polacek@redhat.com> wrote:
> >We blow up on the following testcase because we find ourselves passing
> >[_13 + 1, INT_MAX] as a vr1 to extract_range_from_multiplicative_op_1;
> >that's bad because this function immediately calls vrp_int_const_binop
> >which just doesn't work for symbolic ranges, it only wants int_csts.
> >
> >This started with Richards S.'s changes in r228614 -- we're now since
> >able to recurse into SSA names, thus get better info about ranges.
> >That means that range_includes_zero_p in
> >extract_range_from_binary_expr_1
> >for the *_DIV_EXPR cases was able to determine that the range doesn't
> >include zero, so we went through a different code path and ended up
> >calling extract_range_from_multiplicative_op_1 even with symbolic
> >ranges.
> >
> >I couldn't come up with anything better than checking that we're
> >dealing
> >with nonsymbolic ranges for such a case.
> >
> >Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> Hmm.  I think we can do better if vr0 is symbolical - use min, max for it.
> 
> I suppose it would be best to implement a get_integer_range () function doing that or also looking at equivalences if we are getting a symbolic range.
> 
> Anyway, those are future enhancements that shouldn't block this patch.
 
Is this something for this stage3?  Or should I open a PR and fix it in the
next stage1?

> Thus OK.

Thanks.

	Marek

Re: [PATCH] Don't ICE on symbolic ranges in VRP (PR tree-optimization/68455)

[Richard Biener]

On November 23, 2015 6:09:33 PM GMT+01:00, Marek Polacek <polacek@redhat.com> wrote:
>On Mon, Nov 23, 2015 at 05:40:14PM +0100, Richard Biener wrote:
>> On November 23, 2015 5:31:11 PM GMT+01:00, Marek Polacek
><polacek@redhat.com> wrote:
>> >We blow up on the following testcase because we find ourselves
>passing
>> >[_13 + 1, INT_MAX] as a vr1 to
>extract_range_from_multiplicative_op_1;
>> >that's bad because this function immediately calls
>vrp_int_const_binop
>> >which just doesn't work for symbolic ranges, it only wants int_csts.
>> >
>> >This started with Richards S.'s changes in r228614 -- we're now
>since
>> >able to recurse into SSA names, thus get better info about ranges.
>> >That means that range_includes_zero_p in
>> >extract_range_from_binary_expr_1
>> >for the *_DIV_EXPR cases was able to determine that the range
>doesn't
>> >include zero, so we went through a different code path and ended up
>> >calling extract_range_from_multiplicative_op_1 even with symbolic
>> >ranges.
>> >
>> >I couldn't come up with anything better than checking that we're
>> >dealing
>> >with nonsymbolic ranges for such a case.
>> >
>> >Bootstrapped/regtested on x86_64-linux, ok for trunk?
>> 
>> Hmm.  I think we can do better if vr0 is symbolical - use min, max
>for it.
>> 
>> I suppose it would be best to implement a get_integer_range ()
>function doing that or also looking at equivalences if we are getting a
>symbolic range.
>> 
>> Anyway, those are future enhancements that shouldn't block this
>patch.
> 
>Is this something for this stage3?  Or should I open a PR and fix it in
>the
>next stage1?

Open a PR for next stage1.  Unless you are able to create a testcase that regressed of course.

Richard.

>> Thus OK.
>
>Thanks.
>
>	Marek