[Bug target/45233] FAIL: gcc.c-torture/compile/pr44707.c
iains at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Sun Nov 6 12:37:00 GMT 2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> 2011-11-06 12:36:23 UTC ---
Trying to simplify this, the following is enough to trigger the behavior:
extern int w;
void
foo (void)
{
int e2 = w;
__asm__ volatile ("/* %0 */" : : "ro" (e2));
}
==
(1) the code DTRT when the constraint is "r" or "o" ... but not when it is
"ro".
(2) essentially, up to combine, we have:
(insn 5 2 6 2 (set:SI (reg:SI 122)
(plus:SI (reg:SI 31 r31)
(high:SI (const:SI (unspec:SI [
(symbol_ref:SI ("&L_w$non_lazy_ptr") [flags 0x400]
<var_decl 0x420a3a20 w>)
] UNSPEC_MACHOPIC_OFFSET))))) ../tests/pr44707-x.c:7 96
{addsi3_high}
(nil))
(insn 6 5 7 2 (set (reg/f:SI 121)
(mem/u/c:SI (lo_sum:SI (reg:SI 122)
(const:SI (unspec:SI [
(symbol_ref:SI ("&L_w$non_lazy_ptr") [flags 0x400]
<var_decl 0x420a3a20 w>)
] UNSPEC_MACHOPIC_OFFSET))) [0 S4 A8]))
../tests/pr44707-x.c:7 348 {movsi_low}
(expr_list:REG_DEAD (reg:SI 122)
(expr_list:REG_EQUAL (symbol_ref:SI ("w") [flags 0x240] <var_decl
0x420a3a20 w>)
(nil))))
(3) when "ro" is given, combine decides to delete insn 5 & 6 ...
(4) ira decides to re-insert the load of a pointer to w .. but it doesn't
(re-)insert the machopic indirect stuff...
(note 5 2 6 2 NOTE_INSN_DELETED)
(note 6 5 12 2 NOTE_INSN_DELETED)
(insn 12 6 13 2 (set (reg:SI 2 r2)
(plus:SI (reg:SI 31 r31)
(high:SI (const:SI (unspec:SI [
(symbol_ref:SI ("w") [flags 0x240] <var_decl
0x420a3a20 w>)
] UNSPEC_MACHOPIC_OFFSET))))) ../tests/pr44707-x.c:7 96
{addsi3_high}
(nil))
(insn 13 12 7 2 (set (reg:SI 2 r2)
(lo_sum:SI (reg:SI 2 r2)
(const:SI (unspec:SI [
(symbol_ref:SI ("w") [flags 0x240] <var_decl
0x420a3a20 w>)
] UNSPEC_MACHOPIC_OFFSET)))) ../tests/pr44707-x.c:7 14
{macho_low_si}
(nil))
which leads to the assembler fail...
====
So ... I don't know whether the problem lies in combine (incorrectly
eliminating the address load) -- or in ira (not re-introducing the indirect
reference).
Would welcome input from one of you gurus ...
this is an irritating long-term fail (and, I guess, it might even have
implications for other targets...)
More information about the Gcc-bugs
mailing list