> On Oct 17, 2016, at 3:27 AM, Richard Biener
> wrote:
>
> On Fri, Oct 14, 2016 at 3:51 PM, Bill Schmidt
> wrote:
>> Hi Richard,
>>
>>> On Oct 14, 2016, at 4:19 AM, Richard Biener
>>> wrote:
>>>
>>> On
On Fri, Oct 14, 2016 at 3:51 PM, Bill Schmidt
wrote:
> Hi Richard,
>
>> On Oct 14, 2016, at 4:19 AM, Richard Biener
>> wrote:
>>
>> On Thu, Oct 13, 2016 at 5:38 PM, Bill Schmidt
>> wrote:
>>> The previous
Hi Richard,
> On Oct 14, 2016, at 4:19 AM, Richard Biener
> wrote:
>
> On Thu, Oct 13, 2016 at 5:38 PM, Bill Schmidt
> wrote:
>> The previous patch for
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937 is necessary, but not
>>
On Thu, Oct 13, 2016 at 5:38 PM, Bill Schmidt
wrote:
> The previous patch for
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937 is necessary, but not
> sufficient in all cases. It allows -1 to be used with a pointer
> increment, which we really do not want given
The previous patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937 is necessary, but not
sufficient in all cases. It allows -1 to be used with a pointer
increment, which we really do not want given that this is generally not
profitable. Disable this case for now. We can add logic later
On 2016.10.12 at 20:14 -0500, Bill Schmidt wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937 reports an ICE in SLSR
> where a POINTER_PLUS_EXPR occurs with a candidate increment of -1. This
> is supposed to be prevented by code in analyze_increments, since replacement
> of such a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937 reports an ICE in SLSR
where a POINTER_PLUS_EXPR occurs with a candidate increment of -1. This
is supposed to be prevented by code in analyze_increments, since replacement
of such a candidate is not guaranteed to be profitable. The test for this