Re: VRP: x+1 and -x cannot be INT_MIN

2017-11-20 Thread Richard Biener
On Mon, Nov 20, 2017 at 3:10 PM, Marc Glisse wrote: > On Mon, 20 Nov 2017, Richard Biener wrote: > >>> I had to adapt one testcase where for VR_VARYING | [1, 1] we used to >>> produce >>> ~[0, 0] and now produce [-INT_MAX, INT_MAX]. I am surprised at how late >>> the >>> transformation now happens

Re: VRP: x+1 and -x cannot be INT_MIN

2017-11-20 Thread Marc Glisse
On Mon, 20 Nov 2017, Richard Biener wrote: I had to adapt one testcase where for VR_VARYING | [1, 1] we used to produce ~[0, 0] and now produce [-INT_MAX, INT_MAX]. I am surprised at how late the transformation now happens (only after removing __builtin_unreachable, in forwprop3, while trunk cur

Re: VRP: x+1 and -x cannot be INT_MIN

2017-11-20 Thread Richard Biener
On Sun, Nov 19, 2017 at 11:41 AM, Marc Glisse wrote: > On Mon, 13 Nov 2017, Richard Biener wrote: > >> On Sat, Nov 11, 2017 at 11: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

Re: VRP: x+1 and -x cannot be INT_MIN

2017-11-19 Thread Jeff Law
On 11/19/2017 03:41 AM, Marc Glisse wrote: > On Mon, 13 Nov 2017, Richard Biener wrote: > >> On Sat, Nov 11, 2017 at 11: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 som

Re: VRP: x+1 and -x cannot be INT_MIN

2017-11-19 Thread Marc Glisse
On Mon, 13 Nov 2017, Richard Biener wrote: On Sat, Nov 11, 2017 at 11: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

Re: VRP: x+1 and -x cannot be INT_MIN

2017-11-13 Thread Richard Biener
On Sat, Nov 11, 2017 at 11: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

Re: VRP: x+1 and -x cannot be INT_MIN

2017-11-12 Thread Marc Glisse
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

Re: VRP: x+1 and -x cannot be INT_MIN

2017-11-12 Thread Martin Sebor
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

Re: VRP: x+1 and -x cannot be INT_MIN

2017-11-11 Thread Marc Glisse
On Sat, 11 Nov 2017, Jakub Jelinek wrote: On Sat, Nov 11, 2017 at 11:03:06PM +0100, Marc Glisse wrote: --- gcc/tree-vrp.c (revision 254629) +++ gcc/tree-vrp.c (working copy) @@ -2086,20 +2086,38 @@ extract_range_from_binary_expr_1 (value_ else set_value_range_to_varying

Re: VRP: x+1 and -x cannot be INT_MIN

2017-11-11 Thread Jakub Jelinek
On Sat, Nov 11, 2017 at 11:03:06PM +0100, Marc Glisse wrote: > --- gcc/tree-vrp.c(revision 254629) > +++ gcc/tree-vrp.c(working copy) > @@ -2086,20 +2086,38 @@ extract_range_from_binary_expr_1 (value_ >else > set_value_range_to_varying (vr); > >return; > } > >

VRP: x+1 and -x cannot be INT_MIN

2017-11-11 Thread Marc Glisse
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