This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug debug/48886] New: VTA issues with > word size integers


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]