------- Comment #8 from jakub at gcc dot gnu dot org 2010-02-19 11:23 -------
Details for Alex:
/* { dg-options "-m32 -O2 -g -march=i386 -mtune=generic -dA" } */
int foo (unsigned long *);
int
fn3 (void)
{
unsigned long a = 0, b = 0;
a = foo (&b);
unsigned long varb = b;
asm volatile ("" : : "g" (varb));
return a;
}
This has just one bb (plus the special 2), so this is not a bug in
vt_find_locations stuff and is not related to the sp issues either.
At the end of the bb we have:
name: varb D.1234
offset 0
(value/s/u:SI 7:7 @0x1eeca58/0x1eec760)
(value/s/u:SI 7:7 @0x1eeca58/0x1eec760)
offset 0
(mem/c/i:SI (value/s/u:SI 5:3926 @0x1eeca28/0x1eec7f0) [2 bD.1233+0 S4
A32])
but value 5:3926 is not in the hash table (and that's the reason why
var_location for varb is
(note 38 37 13 (var_location varb (nil)) NOTE_INSN_VAR_LOCATION)
) - it is not in the hash table even at the spot where the DEBUG_INSN for varb
has its uops. varb is present at bp - 12. Before the call there is
(insn:TI 25 29 6 pr43077.c:7 (set (reg/f:SI 0 ax [61])
(plus:SI (reg/f:SI 6 bp)
(const_int -12 [0xfffffffffffffff4]))) 247 {*lea_1} (nil))
...
(insn:TI 8 36 9 pr43077.c:7 (set (mem/f/i:SI (reg/f:SI 7 sp) [0 S4 A32])
(reg/f:SI 0 ax [61])) 47 {*movsi_1} (expr_list:REG_DEAD (reg/f:SI 0 ax
[61])
(expr_list:REG_EQUAL (plus:SI (reg/f:SI 20 frame)
(const_int -4 [0xfffffffffffffffc]))
(nil))))
value 5:3926 is apparently created while processing insn 25, and during
processing uops for insn 25 value 5:3926 is added to the hash table, with %eax
as the (only) location. But of course when processing the call
dataflow_set_clear_at_call nukes it, as %eax is cloberred, thus value 5:3926
has no locations and is nuked from the hash table. When emitting varb location
note, it doesn't find that VALUE in the hash table, so doesn't know that value
5:3926 is actually ebp - 12. Not sure what is so different for 64-bit
compilation that it figures it out.
For Michael: if you have bootstrapped/regtested your patch, please submit it to
gcc-patches anyway, this will be hopefully resolved afterwards.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077
