On 10/10/14 04:06, Uros Bizjak wrote:
On Wed, Oct 8, 2014 at 1:56 PM, Uros Bizjak <ubiz...@gmail.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 <ubiz...@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.
The escaping VALUE stuff is still in my queue.
jeff
