Re: [PATCH v2, RTL]: Fix PR 63483, Scheduler performs Invalid move of aliased memory reference

[Uros Bizjak <ubizjak at gmail dot com>]

On Fri, Oct 10, 2014 at 7:25 PM, Jeff Law <law@redhat.com> wrote:

>>>>> This message revives an old thread [1], where the miscompilation of
>>>>> gfortran
>>>>> on alpha was found that that resulted in:
>>>
>>>
>>> [...]
>>>
>>>> As said in the audit trail of the bugreport I think that the caller
>>>> of alpha_set_memflags is wrong in applying MEM flags from the _source_
>>>> operand to MEMs generated for the RMW sequence for the destination.
>>>>
>>>> It would be better to fix that instead.
>>>
>>>
>>> Please see comment #6 of the referred PR [1] for further analysis and
>>> ammended testcase. The testcase and analysis will show a "native" read
>>> passing possibly aliasing store.
>>
>>
>> Attached v2 patch implements the same approach in all alias.c places
>> that declare MEM_READONLY_P operands as never aliasing.
>>
>> 2014-10-10  Uros Bizjak  <ubizjak@gmail.com>
>>
>>      * alias.c (true_dependence_1): Do not exit early for MEM_READONLY_P
>>      references when alignment ANDs are involved.
>>      (write_dependence_p): Ditto.
>>      (may_alias_p): Ditto.
>>
>> Patch was boostrapped and regression tested on x86_64-linux-gnu and
>> alpha-linux-gnu. Unfortunately, there are still failures remaining in
>> gfortran testsuite due to independent RTL infrastructure problem with
>> VALUEs leaking into aliasing detecting functions [2], [3].
>>
>> The patch was discussed and OK'd by Richi in the PR audit trail. If
>> there are no objections from RTL maintainers, I plan to commit it to
>> the mainline early next week.
>>
>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
>> [2] https://gcc.gnu.org/ml/gcc/2014-10/msg00060.html
>> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63475
>
> No objection.  In fact, after reading everything it's pretty obvious to me
> that a /u MEM must be considered as potentially conflicting with writes that
> are implemented as RMW sequences to deal with the lack of byte access
> support.

Thanks, I went ahead and commit the patch to SVN mainline. I wonder,
if they should be also committed to release branches?

> The escaping VALUE stuff is still in my queue.

Great, I can test them on alpha native, there are many gfortran
testsuite failures due to this problem.

Thanks,
Uros.