On 07/14/11 18:03, Richard Henderson wrote:
> On 07/14/2011 03:03 AM, Bernd Schmidt wrote:
>> +++ gcc/config/ia64/ia64.c (working copy)
>> @@ -1047,7 +1047,7 @@
>> tmp = gen_rtx_PLUS (Pmode, tmp, pic_offset_table_rtx);
>> emit_insn (gen_rtx_SET (VOIDmode, dest, tmp));
>>
>> - tmp = gen_rtx_LO_SUM (Pmode, dest, src);
>> + tmp = gen_rtx_LO_SUM (Pmode, gen_rtx_MEM (Pmode, dest), src);
>
> And the bug stems from ... what?
>
> Is this bug still fixed if you change this to gen_const_mem?
It should be. Testing this isn't straightforward bit tricky since the
original bug is in gcc-3.3 which doesn't have gen_const_mem, and current
mainline with just the scheduler patch removed doesn't reproduce it with
the testcase.
In mainline, gen_const_mem sets MEM_NOTRAP_P, but it looks like we
handle that correctly in may_trap_p:
if (/* MEM_NOTRAP_P only relates to the actual position of the memory
reference; moving it out of context such as when moving code
when optimizing, might cause its address to become invalid. */
code_changed
|| !MEM_NOTRAP_P (x))
and sched_deps uses rtx_addr_can_trap anyway.
> This is a load from the .got.
Yes, but not using the fixed got pointer in r1, but a random other
register which can have different values in the function.
> It's difficult to tell if your raw gen_rtx_MEM with no aliasing
> info doesn't just paper over a problem by preventing it from
> being moved.
The problem isn't about memory aliasing, it's about the pointer register
being clobbered.
Bernd
