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