public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/43077]  New: VTA issues caused by SSA expand
@ 2010-02-15 13:23 jakub at gcc dot gnu dot org
  2010-02-18 15:13 ` [Bug debug/43077] " matz at gcc dot gnu dot org
                   ` (15 more replies)
  0 siblings, 16 replies; 17+ messages in thread
From: jakub at gcc dot gnu dot org @ 2010-02-15 13:23 UTC (permalink / raw)
  To: gcc-bugs

In the following testcase in both foo and baz functions var[abc] debuginfo
is lost during SSA expansion (unlike e.g. with redhat/gcc-4_4-branch VTA which
doesn't do SSA expansion):

int varb;

int __attribute__((noinline))
foo (void)
{
  int vara = (varb == 3);
  asm volatile ("" : : "g" (vara));
  return 0;
}

int __attribute__((noinline))
bar (unsigned long *p, unsigned long *q)
{
  int ret;
  asm volatile ("" : "=r" (ret), "=r" (*p), "=r" (*q) : "0" (1), "1" (2), "2"
(3));
  return ret;
}

int __attribute__((noinline))
baz (void)
{
  unsigned long a = 0, b = 0, c = 0;
  a = bar (&b, &c);
  unsigned long vara = a;
  unsigned long varb = b;
  unsigned long varc = c;
  __asm__ volatile ("" : : "g" (vara), "g" (varb), "g" (varc));
  return a;
}

int
main (void)
{
  foo ();
  baz ();
  return 0;
}
In *.optimized we have on redhat/gcc-4_4-branch:
foo
  # DEBUG vara => varb == 3
  __asm__ __volatile__("" :  : "g" varb == 3);
baz:
  D.1615D.1615 = bar (&b, &c);
  # DEBUG D#1 => (long unsigned int) D.1615D.1615
  # DEBUG a => D#1
  # DEBUG vara => D#1
  # DEBUG D#2 => b
  # DEBUG varb => D#2
  # DEBUG D#3 => c
  # DEBUG varc => D#3
  __asm__ __volatile__("" :  : "g" (long unsigned int) D.1615D.1615, "g" b, "g"
c);
and on the trunk:
foo:
  varb.0_1 = varb;
  vara_2 = varb.0_1 == 3;
  # DEBUG vara => vara_2
  __asm__ __volatile__("" :  : "g" vara_2);
baz:
  D.2742_2 = bar (&b, &c);
  a_3 = (long unsigned int) D.2742_2;
  # DEBUG a => a_3
  # DEBUG vara => a_3
  varb_5 = b;
  # DEBUG varb => varb_5
  varc_6 = c;
  # DEBUG varc => varc_6
  __asm__ __volatile__("" :  : "g" a_3, "g" varb_5, "g" varc_6);
On redhat/gcc-4_4-branch then expansion has debug insns which still track where
the variables really live:
foo:
(debug_insn 5 4 6 3 P.c:6 (var_location:SI vara (eq:SI (mem/c/i:SI
(symbol_ref:DI ("varb")  <var_decl 0x7f668363e820 varb>) [2 varb+0 S4 A32])
(const_int 3 [0x3]))) -1 (nil))
baz:
(debug_insn 14 13 15 3 P.c:23 (var_location:DI D.4294967295 (zero_extend:DI
(reg:SI 58 [ D.1615 ]))) -1 (nil))
(debug_insn 15 14 16 3 P.c:23 (var_location:DI a (debug_expr:DI D#1)) -1 (nil))
(debug_insn 16 15 17 3 P.c:24 (var_location:DI vara (debug_expr:DI D#1)) -1
(nil))
(debug_insn 17 16 18 3 P.c:25 (var_location:DI D.4294967294 (mem/c/i:DI
(plus:DI (reg/f:DI 54 virtual-stack-vars) (const_int -8 [0xfffffffffffffff8]))
[3 b+0 S8 A64])) -1 (nil))
(debug_insn 18 17 19 3 P.c:25 (var_location:DI varb (debug_expr:DI D#2)) -1
(nil))
(debug_insn 19 18 20 3 P.c:26 (var_location:DI D.4294967293 (mem/c/i:DI
(plus:DI (reg/f:DI 54 virtual-stack-vars) (const_int -16 [0xfffffffffffffff0]))
[3 c+0 S8 A64])) -1 (nil))
(debug_insn 20 19 21 3 P.c:26 (var_location:DI varc (debug_expr:DI D#3)) -1
(nil))
but on the trunk in *.expand we have:
foo:
(debug_insn 5 4 6 3 P.c:6 (var_location:SI vara (reg/v:SI 59 [ vara ])) -1
(nil))
(insn 6 5 7 3 P.c:7 (set (reg:CCZ 17 flags) (compare:CCZ (mem/c/i:SI
(symbol_ref:DI ("varb")  <var_decl 0x7f158a318000 varb>) [2 varb+0 S4 A32])
(const_int 3 [0x3]))) -1 (nil))
(insn 7 6 8 3 P.c:7 (set (reg:QI 62) (eq:QI (reg:CCZ 17 flags) (const_int 0
[0x0]))) -1 (nil))
(insn 8 7 9 3 P.c:7 (parallel [(set (reg:SI 61) (zero_extend:SI (reg:QI 62)))
(clobber (reg:CC 17 flags))]) -1 (nil))
(insn 9 8 10 3 P.c:7 (parallel [(asm_operands/v ("") ("") 0 [(reg:SI 61)]...
baz:
(debug_insn 14 13 15 3 P.c:23 (var_location:DI a (reg/v:DI 59 [ a ])) -1 (nil))
(debug_insn 15 14 16 3 P.c:24 (var_location:DI vara (reg/v:DI 59 [ a ])) -1
(nil))
(debug_insn 16 15 17 3 P.c:25 (var_location:DI varb (reg/v:DI 60 [ varb ])) -1
(nil))
(debug_insn 17 16 18 3 P.c:26 (var_location:DI varc (reg/v:DI 61 [ varc ])) -1
(nil))
(insn 18 17 19 3 P.c:27 (set (reg:DI 65) (sign_extend:DI (reg:SI 58 [ D.2742
]))) -1 (nil))
(insn 19 18 20 3 P.c:27 (parallel [(asm_operands/v ("") ("") 0 [(reg:DI 65)
(mem/c/i:DI (plus:DI (reg/f:DI 54 virtual-stack-vars) (const_int -8
[0xfffffffffffffff8])) [3 b+0 S8 A64]) (mem/c/i:DI (plus:DI (reg/f:DI 54
virtual-stack-vars) (const_int -16 [0xfffffffffffffff0])) [3 c+0 S8 A128])]...

The problem is that pseudo 59 in foo resp. pseudos in 59/60/61 in baz are only
referenced in the debug_insns, never initialized or used in actual code and
therefore are pretty soon just changed into (clobber (const_int 0)).  I believe
this is because SSA expansion in some cases (e.g. for the asm operand "g") does
a TER, so DECL_RTL of the SSA_NAME isn't actually used.  I guess we'd need to
TER in this case also into the DEBUG_INSN locations, but not sure when exactly
to do that.

This is quite important e.g. for SystemTap, as asm "g" input operands with some
short lived vars in a macro is something that is used in user probes, and
SystemTap then expects to find the values of those vars in the debuginfo.


-- 
           Summary: VTA issues caused by SSA expand
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: wrong-debug
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jakub at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077


^ permalink raw reply	[flat|nested] 17+ messages in thread
end of thread, other threads:[~2010-02-23 22:32 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-02-15 13:23 [Bug debug/43077] New: VTA issues caused by SSA expand jakub at gcc dot gnu dot org
2010-02-18 15:13 ` [Bug debug/43077] " matz at gcc dot gnu dot org
2010-02-18 15:46 ` jakub at gcc dot gnu dot org
2010-02-18 16:12 ` matz at gcc dot gnu dot org
2010-02-18 16:40 ` matz at gcc dot gnu dot org
2010-02-18 16:50 ` matz at gcc dot gnu dot org
2010-02-18 19:49 ` jakub at gcc dot gnu dot org
2010-02-19  9:49 ` jakub at gcc dot gnu dot org
2010-02-19 11:23 ` jakub at gcc dot gnu dot org
2010-02-19 12:32 ` jakub at gcc dot gnu dot org
2010-02-19 12:33 ` matz at gcc dot gnu dot org
2010-02-23 14:25 ` jakub at gcc dot gnu dot org
2010-02-23 14:32 ` matz at gcc dot gnu dot org
2010-02-23 16:42 ` matz at gcc dot gnu dot org
2010-02-23 16:47 ` matz at gcc dot gnu dot org
2010-02-23 22:05 ` hjl dot tools at gmail dot com
2010-02-23 22:32 ` jakub at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).