On Fri, Nov 30, 2012 at 1:29 PM, Uros Bizjak wrote:
> On Fri, Nov 30, 2012 at 11:42 AM, Steven Bosscher wrote:
>> On Fri, Nov 30, 2012 at 11:39 AM, Paolo Bonzini wrote:
>>> Il 29/11/2012 23:47, Uros Bizjak ha scritto:
>>>> This one-liner causes following runtime test failure [1] for
>>>> alphaev68-linux-gnu:
>>>>
>>>> FAIL: gfortran.fortran-torture/execute/save_1.f90 execution, -O2
>>>> FAIL: gfortran.fortran-torture/execute/save_1.f90 execution, -O2
>>>> -fomit-frame-pointer -finline-functions
>>>> FAIL: gfortran.fortran-torture/execute/save_1.f90 execution, -O2
>>>> -fomit-frame-pointer -finline-functions -funroll-loops
>>>> FAIL: gfortran.fortran-torture/execute/save_1.f90 execution, -O2
>>>> -fbounds-check
>>>>
>>>> The patch miscompiles libgfortran library.
>>>>
>>>> I will provide more info tomorrow, any hint what/where should I look
>>>> for differences?
>>>
>>> Anywhere. The bug disabled a large part of alias analysis.
>>>
>>> Perhaps you can bisect it and backport the fix along the steps.
>>
>> Or open a PR and assign it to me, ultimately I'm responsible for this
>> breakage.
>
> I have found the problem. Luckily, it is the testcase that is
> miscompiled. The problem is in sched1 pass that moves write to an
> address "addrX" that happens to be aliased with AND mutilated address
> "addrY & -7". The improved alias analysis does not notice that the
> write is inside (addr & -7) region, allowing write to be moved after
> read.
Based on this description of the problem, I remembered these patches
from Alexandre:
2012-07-06 Alexandre Oilva <>
PR rtl-optimization/53827
PR debug/53671
PR debug/49888
* alias.c (memrefs_conflict_p): Adjust offset and size by the
same amount for alignment ANDs.
2012-06-21 Alexandre Oliva <>
PR debug/53671
PR debug/49888
* alias.c (memrefs_conflict_p): Improve handling of AND for alignment.
They are r188868 and r189325. Can you try revert these and see if that
fixes your problem (probably at the expense of some other problem
returning, but at least it'd be a good place to start looking
further...).
Ciao!
Steven
