This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug debug/48886] New: VTA issues with > word size integers
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 5 May 2011 13:08:51 +0000
- Subject: [Bug debug/48886] New: VTA issues with > word size integers
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48886
Summary: VTA issues with > word size integers
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: jakub@gcc.gnu.org
CC: aoliva@gcc.gnu.org, tromey@gcc.gnu.org
The http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00403.html
typeddwarf.c testcase is going to fail on i?86 with gdb supporting typed DWARF
stack. The above mentioned patch should fix the 3 vars in f4, but n and o vars
in f2 still have no location info. More detailed testcase:
/* { dg-options "-g" } */
volatile int vv;
volatile long long vv2;
__attribute__((noinline, noclone)) void
foo (long long x)
{
float f = x;
vv = x;/* { dg-final { gdb-test 10 "f" "7" } } */
}
__attribute__((noinline, noclone)) void
bar (long long x)
{
float f = x;
vv = x;/* { dg-final { gdb-test 17 "f" "7" } } */
vv2 = x * 2;
vv = x;/* { dg-final { gdb-test 19 "f" "7" } } */
}
__attribute__((noinline, noclone)) void
baz (long long x)
{
float f = x;
vv = x;/* { dg-final { gdb-test 26 "f" "7" } } */
vv2 = x * 2;
vv++;/* { dg-final { gdb-test 27 "f" "7" } } */
}
int
main ()
{
foo (7LL);
bar (7LL);
baz (7LL);
return 0;
}
Here the parameter isn't completely unused (happens much more often in
real-world). So, the references to the long long parameter where sizeof (long
long) > sizeof (word) are initially DImode pseudos which is loaded from DImode
MEM (DECL_INCOMING_RTL). During jump and its delete_trivially_dead_in nothing
relevant is deleted, then comes subreg1 pass and splits the DImode load into
two SImode loads and leaves (concatn:DI [(reg:SI x) (reg:SI y)]) in the
debug_insn.
During CSE1 or so fast DCE is performed and just removes the second load to
(reg:SI y), as that register is unused. Later on DF resets the debug insn
because (reg:SI y) is mentioned just in debug insns and nowhere else.
To fix foo, we could either call delete_trivially_dead_insns at the end of
subreg1 pass if it did any work (tried that and works), or perhaps teach fast
DCE to also create debug temporaries like delete_trivially_dead_insns (not sure
how hard that would be). That still isn't enough to fix foo (and n/o vars in
f2 from typeddwarf.c), we'd also need to handle CONCATN in mem_loc_descriptor,
at least the easy case where it has MODE_INT mode twice as big as MODE_INT
modes of the parts and the parts are at least word sized, then we could expand
it either to a left shift and plus/or, or in some special cases like in the
testcase two consecutive MEMs to just a single MEM or two consecutive regs to
just a single reg. Consecutive would need to respect WORDS_BIG_ENDIAN I guess.
In baz it is even more problematic, the debug_insn references DImode %eax:%edx,
but as *.split2 pass splits the DImode %eax:%edx = mem:DI load into separate
loads into SImode %eax and %edx, var-tracking doesn't figure out that %eax:%edx
is the same value at that point as the mem:DI content which isn't modified.
So, when %eax:%edx DImode register is clobbered (during x * 2 computation), f
is said to be optimized out afterwards, while it is also live in the MEM.
Wonder if var-tracking shouldn't try to split 2 * word MODE_INT regs into
CONCATN (if dwarf2out handles it) or into shift + plus/ior.