On 12/13/2017 09:24 AM, Richard Biener wrote:
>>
>> Alternately we could to the dom_walker ctor that an initial state of
>> EDGE_EXECUTABLE is already set.
>
> I'm quite sure that wouldn't help for VRP.
Not sure why. But it's not worth digging deep into.
I do think the current structure could s
On 12/13/2017 09:55 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 12 Dec 2017, David Malcolm wrote:
>
>> There didn't seem to be a pre-existing way to determine the unique
>> out-edge after a GIMPLE_COND (if it has a constant cond), so I added
>> a new gimple_cond_get_unique_successor_edge function.
Hi,
On Tue, 12 Dec 2017, David Malcolm wrote:
> There didn't seem to be a pre-existing way to determine the unique
> out-edge after a GIMPLE_COND (if it has a constant cond), so I added
> a new gimple_cond_get_unique_successor_edge function. Similarly,
> something similar may apply for switches,
On December 13, 2017 5:18:16 PM GMT+01:00, Jeff Law wrote:
>On 12/13/2017 09:02 AM, David Malcolm wrote:
>> On Wed, 2017-12-13 at 08:46 -0700, Jeff Law wrote:
>>> On 12/13/2017 03:06 AM, Richard Biener wrote:
On December 12, 2017 9:50:38 PM GMT+01:00, David Malcolm >>> redhat.com> wrote:
On 12/13/2017 09:02 AM, David Malcolm wrote:
> On Wed, 2017-12-13 at 08:46 -0700, Jeff Law wrote:
>> On 12/13/2017 03:06 AM, Richard Biener wrote:
>>> On December 12, 2017 9:50:38 PM GMT+01:00, David Malcolm >> redhat.com> wrote:
PR tree-optimization/83312 reports a false positive from
-W
On Wed, 2017-12-13 at 08:46 -0700, Jeff Law wrote:
> On 12/13/2017 03:06 AM, Richard Biener wrote:
> > On December 12, 2017 9:50:38 PM GMT+01:00, David Malcolm > redhat.com> wrote:
> > > PR tree-optimization/83312 reports a false positive from
> > > -Warray-bounds.
> > > The root cause is that VRP
On 12/13/2017 03:06 AM, Richard Biener wrote:
> On December 12, 2017 9:50:38 PM GMT+01:00, David Malcolm
> wrote:
>> PR tree-optimization/83312 reports a false positive from
>> -Warray-bounds.
>> The root cause is that VRP both:
>>
>> (a) updates a GIMPLE_COND to be always false, and
>>
>> (b) up
On December 12, 2017 9:50:38 PM GMT+01:00, David Malcolm
wrote:
>PR tree-optimization/83312 reports a false positive from
>-Warray-bounds.
>The root cause is that VRP both:
>
>(a) updates a GIMPLE_COND to be always false, and
>
>(b) updates an ARRAY_REF in the now-unreachable other path to use an
PR tree-optimization/83312 reports a false positive from -Warray-bounds.
The root cause is that VRP both:
(a) updates a GIMPLE_COND to be always false, and
(b) updates an ARRAY_REF in the now-unreachable other path to use an
ASSERT_EXPR with a negative index:
def_stmt j_6 = ASSERT_EXPR