On Tue, Mar 6, 2012 at 11:08 PM, Eric Botcazou <ebotca...@adacore.com> wrote: > If you try to bootstrap the GNAT 4.7.0 compiler on IA-64/Linux with > non-default > options (-gnatpg replaced with -gnatpgn), you get another comparison failure > caused by debug insns, stemming from the machine-specific reorg pass (aka insn > bundling on IA-64). With -g , when cselib is called on: > > (insn 17 41 18 2 (set (reg/f:DI 14 r14 [357]) > (plus:DI (reg:DI 16 r16 [356]) > (const_int 28 > [0x1c]))) /home/eric/gnat.b/gnat7_47/src/gcc/ada/atree.adb:2244 205 {adddi3} > (expr_list:REG_DEAD (reg:DI 16 r16 [356]) > (nil))) > > it finds a previous equivalent value: > > (plus:DI (plus:DI (ashift:DI (value:DI 5:111 @0x29abbe0/0x29f5f20) > (const_int 5 [0x5])) > (value:DI 9:9 @0x29abc40/0x29f5fe0)) > (const_int 28 [0x1c])) > > computed for a debug insn: > > (debug_insn 12 10 65 2 (var_location:SI n (mem/j:SI (plus:DI (plus:DI > (ashift:DI (reg:DI 14 r14 [orig:344 D.2979 ] [344]) > (const_int 5 [0x5])) > (reg/f:DI 15 r15 [orig:342 > atree__atree_private_part__nodes__table.32 ] [342])) > (const_int 28 [0x1c])) [0 > *atree__atree_private_part__nodes__table.32_17 > [D.2979_19].is_extension___XVN.S0.field5+0 S4 A8])) sem_ch2.adb:49 -1 > (nil)) > > When output_dependence is called on a couple of MEMs, it uses the above value > to get the equivalent addresses: > > (plus:DI (value:DI 9:9 @0x29abc40/0x29f5fe0) > (value:DI 12:4189 @0x29abc88/0x29c8a20)) > > and > > (plus:DI (plus:DI (ashift:DI (value:DI 5:111 @0x29abbe0/0x29f5f20) > (const_int 5 [0x5])) > (value:DI 9:9 @0x29abc40/0x29f5fe0)) > (const_int 28 [0x1c])) > > and rtx_refs_may_alias_p returns true on them because ao_ref_from_mem returns > false for one of the MEMs. > > > Without -g, when cselib is called on: > > (insn 14 30 15 2 (set (reg/f:DI 14 r14 [357]) > (plus:DI (reg:DI 16 r16 [356]) > (const_int 28 > [0x1c]))) /home/eric/gnat.b/gnat7_47/src/gcc/ada/atree.adb:2244 205 {adddi3} > (expr_list:REG_DEAD (reg:DI 16 r16 [356]) > (nil))) > > output_dependence only gets the equivalent addresses: > > (plus:DI (value:DI 8:8 @0x299f2e8/0x299f1a0) > (value:DI 10:4188 @0x299f318/0x299f200)) > > and > > (plus:DI (value:DI 12:4254 @0x299f348/0x29a0490) > (const_int 28 [0x1c])) > > and memrefs_conflict_p is able to prove that they don't conflict. > > > The problem is that the more complex expression in the first case fools > memrefs_conflict_p because the predicate makes a wrong assumption about the > canonicalization of address expressions. Hence the attached patch. > > Bootstrapped/regtested on IA-64/Linux, OK for the mainline? Do we also want > it > for 4.7.1 or is it too specific?
Hmm, but isn't the bug that we feed debug-insn mems to memrefs_conflict_p? Or that we have non-legitimate address expressions in them? Richard. > > 2012-03-06 Eric Botcazou <ebotca...@adacore.com> > > * alias.c (memrefs_conflict_p) <PLUS>: Correct wrong assumption about > canonicalization of address expressions. > > > -- > Eric Botcazou