[Bug debug/41353] New: VTA missed-debug issues

[Bug debug/41353] New: VTA missed-debug issues

[jakub at gcc dot gnu dot org]

PR41343 testcase lead me to look at 3 small testcases showing VTA throwing
debug info on the floor (-gdwarf-4 -O2 in all cases):
int
foo (int i, int j)
{
  int i1 = 2 * i;
  int i2 = 3 * i;
  return j;
}
Above is a problem already during RTL expansion, SSA_NAME i_1 (of PARM_DECL i,
with GIMPLE_NOP in SSA_NAME_DEF_STMT) is expanded to NULL by expand_debug_expr,
because var_to_partition returns NO_PARTITION for it.  I think we could special
case the initial SSA_NAMEs of parameters and expand them as the parameters.

int i = 1, j;

int
foo (void)
{
  int i1 = 2 * i;
  int i2 = 3 * i;
  return j;
}

In this case we emit i2 debug info correctly:
        .byte   0x3     # DW_OP_addr
        .quad   i
        .byte   0x6     # DW_OP_deref
        .byte   0x33    # DW_OP_lit3
        .byte   0x1e    # DW_OP_mul
        .byte   0x9f    # DW_OP_stack_value
        .byte   0x93    # DW_OP_piece
        .uleb128 0x4
but i1 is lost (has empty location list).  In *.compgotos things look still
good to me:
(debug_insn 5 2 6 2 d.c:6 (var_location:SI i1 (mult:SI (mem/c/i:SI
(symbol_ref:DI ("i") [flags 0x2] <var_decl 0x7f36e4772820 i>) [2 i+0 S4 A32])
        (const_int 2 [0x2]))) -1 (nil))

(debug_insn 6 5 12 2 d.c:7 (var_location:SI i2 (mult:SI (mem/c/i:SI
(symbol_ref:DI ("i") [flags 0x2] <var_decl 0x7f36e4772820 i>) [2 i+0 S4 A32])
        (const_int 3 [0x3]))) -1 (nil))
are the only places where i1 and i2 are mentioned.  But var-tracking messes it
up:
(note 24 2 23 2 (var_location i1 (expr_list:REG_DEP_TRUE (ashift:SI (mem/c/i:SI
(symbol_ref:DI ("i") [flags 0x2] <var_decl 0x7f36e4772820 i>) [2 i+0 S4 A32])
        (const_int 1 [0x1]))
    (const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)

(note 23 24 25 2 (var_location i1 (nil)) NOTE_INSN_VAR_LOCATION)

(note 25 23 12 2 (var_location i2 (expr_list:REG_DEP_TRUE (mult:SI (mem/c/i:SI
(symbol_ref:DI ("i") [flags 0x2] <var_decl 0x7f36e4772820 i>) [2 i+0 S4 A32])
        (const_int 3 [0x3]))
    (const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
(note the second i1 note).

And my last testcase is:
int i, j;

int
foo (void)
{
  int i1 = 2 * i;
  int i2 = 3 * i;
  return j;
}

Here info is dropped at RTL expansion time, as the VAR_DECL doesn't have RTL
set yet during the expansion.  It is common though, so it will be emitted in
the current TU anyway.  Another case would be extern int i, j; where it is
questionable if the debug info should reference an external variable which
wouldn't be mentioned anywhere in the TU.


-- 
           Summary: VTA missed-debug issues
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          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=41353

[Bug debug/41353] VTA missed-debug issues

[jakub at gcc dot gnu dot org]

------- Comment #1 from jakub at gcc dot gnu dot org  2009-09-14 08:18 -------
Created an attachment (id=18580)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18580&action=view)
gcc45-pr41353.patch

Here is a small patch that allows us to get at least a little bit toward fixing
the first testcase.  At *.expand time it fills the location with the pseudos of
the PARM_DECL, but as it isn't used, that pseudo is optimized away very soon.
Either at the point where the pseudo is killed we should handle it (know that
PARM_DECLs initially live in the incoming reg/mem), or perhaps already this
spot should know about it and handle PARM_DECLs when there is no partition
immediately using DECL_INCOMING_RTL.


-- 


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

[Bug debug/41353] VTA missed-debug issues

[jakub at gcc dot gnu dot org]

------- Comment #2 from jakub at gcc dot gnu dot org  2009-09-14 09:15 -------
Regarding the second testcase, the second i1 note (no real location) comes from
emit_notes_for_changes (insn, EMIT_NOTE_AFTER_INSN, set->vars); in MO_VAL_LOC
handling, the first one (with the correct location) is emitted later on from
MO_VAL_USE's emit_notes_for_changes (insn, EMIT_NOTE_BEFORE_INSN, set->vars);
(in both cases with the same VALUE, but in the first case
val_expand_loc_callback returns the VALUE unexpanded, in the second case
expanded).


-- 


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

[Bug debug/41353] VTA missed-debug issues

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement


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

[Bug debug/41353] VTA missed-debug issues

[jakub at gcc dot gnu dot org]

------- Comment #3 from jakub at gcc dot gnu dot org  2009-09-14 17:36 -------
Another testcase for the vartrack bug:
int
foo (int i)
{
  asm volatile ("" : "+r" (i));
  int i1 = 2 * i;
  int i2 = 2 * i;
  int i3 = 2 * i;
  return i;
}

(debug_insn 8 6 9 2 d6.c:4 (var_location:SI i (reg:SI 0 ax [60])) -1 (nil))
(debug_insn 9 8 10 2 d6.c:5 (var_location:SI i1 (mult:SI (reg:SI 0 ax [60])
        (const_int 2 [0x2]))) -1 (nil))
(debug_insn 10 9 11 2 d6.c:6 (var_location:SI i2 (mult:SI (reg:SI 0 ax [60])
        (const_int 2 [0x2]))) -1 (nil))
(debug_insn 11 10 19 2 d6.c:7 (var_location:SI i3 (mult:SI (reg:SI 0 ax [60])
        (const_int 2 [0x2]))) -1 (nil))
(insn 19 11 24 2 d6.c:9 (use (reg/i:SI 0 ax)) -1 (nil))
looks sane to me, but:
(note 30 6 29 2 (var_location i (expr_list:REG_DEP_TRUE (reg:SI 0 ax [60])
    (const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
(note 29 30 33 2 (var_location i (nil)) NOTE_INSN_VAR_LOCATION)
(note 33 29 32 2 (var_location i1 (nil)) NOTE_INSN_VAR_LOCATION)
(note 32 33 31 2 (var_location i (nil)) NOTE_INSN_VAR_LOCATION)
(note 31 32 34 2 (var_location i1 (expr_list:REG_DEP_TRUE (ashift:SI (reg:SI 0
ax [60])
        (const_int 1 [0x1]))
    (const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
(note 34 31 35 2 (var_location i2 (nil)) NOTE_INSN_VAR_LOCATION)
(note 35 34 19 2 (var_location i3 (nil)) NOTE_INSN_VAR_LOCATION)
(insn 19 35 24 2 d6.c:9 (use (reg/i:SI 0 ax)) -1 (nil))
not.


-- 


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

[Bug debug/41353] VTA missed-debug issues

[jakub at gcc dot gnu dot org]

------- Comment #4 from jakub at gcc dot gnu dot org  2009-09-15 13:45 -------
Created an attachment (id=18585)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18585&action=view)
gcc45-pr41353.patch

I've looked briefly at the problem with correct var location notes followed by
(nil) ones and I believe the problem is that we don't order MO_VAL_USE notes
before MO_VAL_LOC ones, which I believe we have to.  This patch fixes this
testcase, will do a full bootstrap/regtest of it now.

Another thing, unrelated to this, are TREE_STATIC var definitions, without
DECL_RTL_SET_P.  Consider say (again, -gdwarf-4 -O2):
int i = 1, j, k = 1;

int
foo (void)
{
  int i1 = 2 * i;
  int i2 = 2 * i;
  int k1 = 2 * k;
  int k2 = 2 * k;
  return j;
}

Here i2 has correct debug info (and with this patch also i1), but k1 and k2
don't have any location.  The difference is that i is the first global object,
where notice_global_symbol calls DECL_RTL for it, while k already isn't the
first one and DECL_RTL is done only when varpool is finalized.  The important
question now is, is it safe to do DECL_RTL if not already set from
expand_debug_expr, at least for some TREE_STATIC VAR_DECLs?  Is the DECL_RTL
avoidance just to avoid the expensive computing of the name mangling?  If it
won't make a -fcompare-debug difference, I think we should make_decl_rtl,
otherwise perhaps have some way to defer this for later (create a MEM with
something inside it that would later during debug info emission (when all the
varpool stuff is finalized) we'd need to double check that the decl has been
actually emitted so that vars aren't referenced just in .debug_info/.debug_loc
and nowhere else.


-- 


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

[Bug debug/41353] VTA missed-debug issues

[jakub at gcc dot gnu dot org]

------- Comment #5 from jakub at gcc dot gnu dot org  2009-09-16 11:48 -------
Looking at the
int
foo (int i)
{
  asm volatile ("" : "+r" (i));
  int i1 = 2 * i;
  int i2 = 2 * i;
  int i3 = 2 * i;
  return i;
}
testcase now, here the problem is that cse1 pass sees:
(insn 7 6 8 2 d6.c:4 (set (reg/v:SI 59 [ i ])
        (reg:SI 60)) 47 {*movsi_1} (nil))
(pseudo 60 is the dest of the asm, pseudo 59 is the real variable) and replaces
all occurrences of pseudo 59 with pseudo 60 in the following insns, including
DEBUG_INSNs.  But, pseudo 60 doesn't have REG_EXPR set obviously.
In *.compgotos we have:
(debug_insn 8 6 9 2 d6.c:4 (var_location:SI i (reg:SI 0 ax [60])) -1 (nil))
(debug_insn 9 8 10 2 d6.c:5 (var_location:SI i1 (mult:SI (reg:SI 0 ax [60])
        (const_int 2 [0x2]))) -1 (nil))
(debug_insn 10 9 11 2 d6.c:6 (var_location:SI i2 (mult:SI (reg:SI 0 ax [60])
        (const_int 2 [0x2]))) -1 (nil))
(debug_insn 11 10 19 2 d6.c:7 (var_location:SI i3 (mult:SI (reg:SI 0 ax [60])
        (const_int 2 [0x2]))) -1 (nil))
(insn 19 11 24 2 d6.c:9 (use (reg/i:SI 0 ax)) -1 (nil))
So, we first have a MO_USE_NO_VAR, then MO_VAL_LOC saying i lives in %eax, then
MO_USE_NO_VAR for the occurrence of %eax in debug_insn 9, then MO_VAL_LOC
saying it lives in %eax * 2, etc.  But, each such MO_USE_NO_VAR will clobber
anything that lives in that register or depends on it.
I wonder if we shouldn't special case regs without REG_EXPR referenced from
DEBUG_INSN expressions.  Perhaps they could be ignored altogether or something.


-- 


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

[Bug debug/41353] VTA missed-debug issues

[jakub at gcc dot gnu dot org]

------- Comment #6 from jakub at gcc dot gnu dot org  2009-09-16 11:53 -------
With:
--- var-tracking.c.xx 2009-09-16 09:17:52.000000000 +0200
+++ var-tracking.c 2009-09-16 13:48:08.000000000 +0200
@@ -4416,14 +4416,14 @@ use_type (rtx *loc, struct count_use_inf
       expr = REG_EXPR (*loc);

       if (!expr)
-        return MO_USE_NO_VAR;
+        return cui && DEBUG_INSN_P (cui->insn) ? MO_CLOBBER : MO_USE_NO_VAR;
       else if (target_for_debug_bind (var_debug_decl (expr)))
         return MO_CLOBBER;
       else if (track_loc_p (*loc, expr, REG_OFFSET (*loc),
                             false, modep, NULL))
         return MO_USE;
       else
-        return MO_USE_NO_VAR;
+        return cui && DEBUG_INSN_P (cui->insn) ? MO_CLOBBER : MO_USE_NO_VAR;
     }
   else if (MEM_P (*loc))
     {
hack the vars var-tracking doesn't cancel everything immediately, but only
after the
(insn 19 32 36 2 d6.c:9 (use (reg/i:SI 0 ax)) -1 (nil))
insn - which isn't a debug insn and therefore it is still treated as
MO_USE_NO_VAR.


-- 


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

[Bug debug/41353] VTA missed-debug issues

[jakub at gcc dot gnu dot org]

------- Comment #7 from jakub at gcc dot gnu dot org  2009-09-16 16:42 -------
Created an attachment (id=18598)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18598&action=view)
expand-asm-stmt.patch

Alternatively to cure this expand_asm_operands could ensure the temporaries
have correct REG_ATTRS.  This cures the testcase as well.


-- 


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

[Bug debug/41353] VTA missed-debug issues

[jakub at gcc dot gnu dot org]

------- Comment #8 from jakub at gcc dot gnu dot org  2009-09-16 16:43 -------
The http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41353#c4 patch has been
obsoleted by http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01017.html


-- 


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

[Bug debug/41353] VTA missed-debug issues

[jakub at gcc dot gnu dot org]

------- Comment #9 from jakub at gcc dot gnu dot org  2009-09-16 17:17 -------
Another interesting testcase:
int
foo (int i)
{
  asm volatile ("" : "+r" (i));
  int i1 = 2 * i;
  int i2 = 2 * i;
  int i3 = 3 * i;
  asm volatile ("" : "+r" (i) : : "memory");
  return i;
}
Here things go wrong during regmove I'd say.  Before regmove, the first asm
sets (reg:SI 60 [i]), which is also used in several DEBUG_INSNS (for i, i1, i2,
i3) in between the 2 asms, then the second asm uses pseudo 60 and sets 61.
regmove changes it to use pseudo 61 in all places (starting even before the
first asm), but none of the debug_insn arguments are changed, so they all refer
to a dead pseudo 60 and during RA they become clobber 0.


-- 


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

[Bug debug/41353] VTA missed-debug issues

[jakub at gcc dot gnu dot org]

------- Comment #10 from jakub at gcc dot gnu dot org  2009-09-16 17:19 -------
And yet another testcase:
int
foo (int i, int j)
{
  j += i;
  int i1 = 2 * i;
  int i2 = 3 * i;
  asm volatile ("" : "+r" (j) : : "memory");
  return j;
}

Here the debug_insn arguments are lost during cprop1 pass, no idea why yet.


-- 


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

[Bug debug/41353] VTA missed-debug issues

[jakub at gcc dot gnu dot org]

------- Comment #11 from jakub at gcc dot gnu dot org  2009-09-21 18:32 -------
The #c10 problem is that df marks pseudo 60 used last in j += i; (and then just
in 2 DEBUG_INSNs following it) as REG_DEAD in that instruction and drops the
DEBUG_INSN uses below it on the floor.


-- 


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

[Bug debug/41353] VTA missed-debug issues

[aoliva at gcc dot gnu dot org]

------- Comment #12 from aoliva at gcc dot gnu dot org  2009-09-23 16:31 -------
Subject: Bug 41353

Author: aoliva
Date: Wed Sep 23 16:30:39 2009
New Revision: 152088

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152088
Log:
PR debug/41353
* var-tracking.c (add_with_sets): Sort MO_VAL_LOC last among uses.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/var-tracking.c


-- 


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

[Bug debug/41353] VTA missed-debug issues

[jakub at gcc dot gnu dot org]

------- Comment #13 from jakub at gcc dot gnu dot org  2009-10-02 15:01 -------
Subject: Bug 41353

Author: jakub
Date: Fri Oct  2 15:01:22 2009
New Revision: 152403

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152403
Log:
        PR debug/41404
        PR debug/41353
        * cfgexpand.c (expand_debug_expr) <case STRING_CST>: Don't create
        CONST_STRING if STRING_CST contains embedded '\0's or doesn't end with
        '\0'.
        (expand_debug_expr) <case VAR_DECL>: For TREE_STATIC !DECL_EXTERNAL
        vars use DECL_RTL with resetting it back to NULL afterwards.
        * dwarf2out.c (same_dw_val_p): For dw_val_class_addr compare with
        rtx_equal_p instead of asserting it is a SYMBOL_REF.
        (value_format): For dw_val_class_addr only use DW_FORM_addr if
        the attribute type allows it, otherwise use DW_FORM_dataN.
        (mem_loc_descriptor): Handle CONST_STRING.
        (add_const_value_attribute): Handle CONST_STRING using add_AT_addr.
        Handle MEM with CONST_STRING address using add_AT_string.
        (rtl_for_decl_init): Return MEM with CONST_STRING address instead of
        CONST_STRING for const arrays initialized with a string literal.
        (resolve_one_addr, resolve_addr_in_expr, resolve_addr): New functions.
        (dwarf2out_finish): Call resolve_addr.

        * gcc.dg/guality/pr41404-1.c: New test.
        * gcc.dg/guality/pr41353-2.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/guality/pr41353-2.c
    trunk/gcc/testsuite/gcc.dg/guality/pr41404-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfgexpand.c
    trunk/gcc/dwarf2out.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/41353] VTA missed-debug issues

[aoliva at gcc dot gnu dot org]

------- Comment #14 from aoliva at gcc dot gnu dot org  2009-10-06 06:05 -------
The patch that introduces debug temps fixes the problem in #c9.
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00112.html

As for the testcase in #c10, the behavior is correct.  If the pseudo holding a
value becomes dead at a certain point, we shouldn't reference the dead value in
subsequent debug insns because, well, it is dead.  Trying to keep it alive
would do us no good: it would likely cause codegen differences.

Now...  Maybe we could make room for finding the value in alternate locations,
adding a debug temp insn right before the death of the pseudo, and referencing
the debug temp instead of the pseudo itself.  This wouldn't help if it's the
only location known to hold the value, and that location gets actually
clobbered afterwards, say if a register gets reused.  We might end up with lots
of useless debug stmts.  However, if the value survives, or is found at an
equivalent location, we might still represent it, but should we?  If we found
the value to be dead, wouldn't it be more accurate to say so?


-- 


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

[Bug debug/41353] VTA missed-debug issues

[aoliva at gcc dot gnu dot org]

------- Comment #15 from aoliva at gcc dot gnu dot org  2009-10-06 06:09 -------
Err, I messed up my testing.  #c9 is not fixed, I was looking at cprop dumps
(as in #c10), not regmove.  Sorry.  Looking into it now.


-- 

aoliva at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |aoliva at gcc dot gnu dot
                   |dot org                     |org


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

[Bug debug/41353] VTA missed-debug issues

[aoliva at gcc dot gnu dot org]

------- Comment #16 from aoliva at gcc dot gnu dot org  2009-10-06 07:53 -------
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00359.html fixes #c9


-- 


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

[Bug debug/41353] VTA missed-debug issues

[aoliva at gcc dot gnu dot org]

------- Comment #17 from aoliva at gcc dot gnu dot org  2009-10-08 19:20 -------
Subject: Bug 41353

Author: aoliva
Date: Thu Oct  8 19:20:22 2009
New Revision: 152573

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152573
Log:
PR debug/41353
* regmove.c (regmove_backward_pass): Replace src with dst in the
debug insn, and check for dst before rather than after.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/regmove.c


-- 


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

[Bug debug/41353] VTA missed-debug issues

[aoliva at gcc dot gnu dot org]

------- Comment #18 from aoliva at gcc dot gnu dot org  2009-10-08 19:22 -------
All fixed.


-- 

aoliva at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


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