[Bug debug/48866] New: gcc hangs when -g is set

[Bug debug/48866] New: gcc hangs when -g is set

[siebert at aicas dot com]

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

           Summary: gcc hangs when -g is set
           Product: gcc
           Version: 4.4.4
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: debug
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: siebert@aicas.com


Created attachment 24178
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24178
Minimum C example I could produce.  The original code was generated C code.

gcc hangs when compiling the attached C source code (on Linux/x86) as follows

> gcc -O2 -c test.c -o test.o -g
[hangs forever...]
^C
> 

The problem disappears without -g or when using -O0. 

> gcc -O2 -c test.c -o test.o
> gcc -O0 -c test.c -o test.o -g
>

[Bug debug/48866] gcc hangs when -g is set

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.05.04 10:22:37
     Ever Confirmed|0                           |1
      Known to fail|                            |4.6.1, 4.7.0

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-04 10:22:37 UTC ---
Confirmed mainline and 4_6-branch.

[Bug debug/48866] gcc hangs when -g is set

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-05-04 11:32:01 UTC ---
it's var-tracking

[Bug debug/48866] gcc hangs when -g is set

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-04 12:07:42 UTC ---
cselib actually.  Shorter testcase:

struct S { struct S *d[2]; };

struct S *
foo (struct S *x)
{
  struct S *y, *z;
  y =
x->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1];
  z =
y->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1];
  return z;
}

[Bug debug/48866] gcc hangs when -g is set

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-04 14:21:28 UTC ---
The problem is the MEMs nested in other MEM addresses, cselib isn't prepared to
handle it efficiently.

So, either we should break very deep MEM nests using extra DEBUG_INSNs and
debug temporaries (not sure how easy it would be to break them during
expand_debug_expr, so perhaps either when expand_debug_expr finishes, or
perhaps during vt_initialize before an insn is passed to cselib_process_insn),
or cselib would need to have some cache on MEMs it already looked up during
current toplevel cselib_lookup or cselib_subst_to_values calls - for small
number of MEMs perhaps a linear cache that cselib_lookup_mem could iterate
over, holding
MEM rtx / corresponding cselib_val * pairs, for bigger amounts perhaps
pointer_map.  Without such a cache, 14 nested MEMs result in certainly more
than
4 billion cselib_lookup searches within one cselib_process_insn.

[Bug debug/48866] gcc hangs when -g is set

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-05-05 11:54:12 UTC ---
I think the problem is that the debug stmts are being expanded into debug insns
*before* the code that should precede them.  If we expanded the stmts in the
natural, expended order, we'd get the variables bound to simpler expressions. 
That said, I'm not sure this will avoid the cselib slowdown, for we will likely
end up having to use the mems as a location.  Investigating...

[Bug debug/48866] gcc hangs when -g is set

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |aoliva at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #6 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-05-05 12:59:35 UTC ---
Created attachment 24189
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24189
Patch that works around the problem

It is TER that considers the loads as replaceable and ends up moving the entire
computation past the debug stmts.  Considering that MEMs are the reason for the
inefficiency in cselib, and I don't think replacing loads into addresses of
other loads brings us much (any?) benefit, I came up with this hack that fixes
the problem.

We can't really use the incoming argument for debug info very long: it dies at
the first use.  So, even though this patch keeps the debug insns at the
expected place, and we bind the user variables properly, the binding of y
doesn't survive: the value stored in it dies at the first use, on the next
insn, and we can't construct an expression based on a chain of MEMs because (as
mentioned above) the incoming argument, which held the address of the first
MEM, is already dead.

With this patch, the expression stored in z is still regarded as replaceable,
so the debug insn is bound to a MEM before the load, but after var-tracking,
another location expression is emitted with the REG into which the MEM is
loaded.

[Bug debug/48866] gcc hangs when -g is set

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-05 13:54:18 UTC ---
Why are you changing TER for that though?  Won't that affect also real code
generation rather than just debug insns?  I mean there are targets e.g. with
MEM MEM addressing.  With SSA expansion I think you can decide whether you want
to use TER's advice or not during expansion, where you know if it is from debug
stmt or not.

[Bug debug/48866] gcc hangs when -g is set

[aoliva at gcc dot gnu.org]

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

--- Comment #8 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-05-06 14:43:45 UTC ---
I don't see how it would.  Except for some very particular cases (that do not
include the expansion of addresses AFAICT) we just expand each of the
replaceable stmts at the time their SSA names are first referenced.  It's
combine that takes care of creating double-indirect address modes.

Anyway, the current situation is highly sub-optimal: we'd be better off, at
least in terms of debug info generation, if we emitted the code corresponding
to a replaceable def at the point of the def, if it's not effectively
replaced/combined.  Here's how I'm thinking of implementing this:

- in expand_gimple_basic_block, upon encountering a replaceable gimple stmt,
instead of skipping it altogether:

-- if it is mapped to an expansion in a pointer map, emit the expansion, unmark
it as replaceable, and remove the mapping

-- otherwise, emit a placeholder note and insert (stmt,placeholder) in the
pointer map

- in expand_expr_real_1 case SSA_NAME, instead of expanding the replaceable
stmt onto the current insn seq, expand it into a separate seq and:

-- if the stmt is already in the pointer map, emit the seq before the
placeholder, remove the placeholder, and unmark the stmt as replaceable

-- if it isn't, insert the pair (stmt, expansion) in the pointer map

- at the end of expansion, remove all placeholders before adjusting deferred
debug insns

Makes sense?  Any pitfalls I should watch out for?

[Bug debug/48866] gcc hangs when -g is set

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #24189|0                           |1
        is obsolete|                            |

--- Comment #9 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-05-06 22:18:16 UTC ---
Created attachment 24202
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24202
Avoid too-complex value exprs by keeping unreplaced replaceable expansions in
natural order

This alternate patch implements (with minor changes) the plan described in
comment 8, that should improve debuggability and limit the complexity of debug
values generated by the expander to about the maximum complexity of an insn. 
It successfully undoes the code movement of TER for code generated that is not
combined into other stmts.  force_reg for a subsequent insn is still regarded
as combination, although I have plans to move that up as well.  Using the
suggested target for an assignment is regarded as combination, and it must
remain that way to avoid moving the assignment before the initialization of the
target.

This has so far passed compare after bootstrap-debug on x86_64-linux-gnu;
testing it more thoroughly now.  Will add comments before posting it to the
list.

[Bug debug/48866] gcc hangs when -g is set

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-07 06:13:35 UTC ---
Please test it with
http://git.fedorahosted.org/git/?p=elfutils.git;a=shortlog;h=refs/heads/dwarf
on something large (say cc1plus) too, build stage3 cc1plus from either the
vanilla or modified tree with stage2 cc1 from unpatched as well as patched
tree, compare the numbers.

[Bug debug/48866] gcc hangs when -g is set

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-07 06:15:23 UTC ---
locstats program, the above URL just gives the repo.  Not sure if it has been
adjusted already for typed DWARF stack though, if not, perhaps for the testing
you could temporarily disable generation of DW_OP_GNU_*_type and
DW_OP_GNU_convert/DW_OP_GNU_reinterpret in mem_loc_descriptor, just return
NULL.

[Bug debug/48866] gcc hangs when -g is set

[aoliva at gcc dot gnu.org]

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

--- Comment #12 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-04-13 15:56:29 UTC ---
Author: aoliva
Date: Fri Apr 13 15:56:21 2012
New Revision: 186422

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186422
Log:
PR debug/48866
* df.h (enum debug_temp_where): New.
(dead_debug_init, dead_debug_finish) Declare.
(dead_debug_add, dead_debug_insert_temp): Declare.
(struct dead_debug_use, struct dead_debug): Moved from...
* df-problems.c: ... here.
(df_set_unused_notes_for_mw): Bind debug uses of unused regno
to a debug temp.
(df_create_unused_note): Likewise.
(df_set_dead_notes_for_mw): Move comment where it belongs.
(dead_debug_init): Export.
(dead_debug_reset_uses): New, factored out of...
(dead_debug_finish): ...this.  Export.
(dead_debug_reset): Remove.
(dead_debug_add): Export.
(dead_debug_insert_before): Rename to...
(dead_debug_insert_temp): ... this.  Add where argument.  Export.
Locate stored value for BEFORE_WITH_VALUE.  Avoid repeat inserts.
Return insertion count.
(df_note_bb_compute): Adjust.
* dce.c (word_dce_process_block): Adjust dead debug uses.
(dce_process_block): Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dce.c
    trunk/gcc/df-problems.c
    trunk/gcc/df.h

[Bug debug/48866] gcc hangs when -g is set

[aoliva at gcc dot gnu.org]

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

--- Comment #13 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-06-13 20:42:00 UTC ---
Author: aoliva
Date: Wed Jun 13 20:41:55 2012
New Revision: 188527

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188527
Log:
PR debug/52983
PR debug/48866
* dce.c (word_dce_process_block): Insert debug temps only if the
insn is not marked.
(dce_process_block): Likewise, and if debug.used is not empty,
and only after iterating over all DEFs that might mark the insn.

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

[Bug debug/48866] gcc hangs when -g is set

[aoliva at gcc dot gnu.org]

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

--- Comment #14 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-06-28 07:39:34 UTC ---
Author: aoliva
Date: Thu Jun 28 07:39:25 2012
New Revision: 189036

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189036
Log:
PR debug/53740
PR debug/52983
PR debug/48866
* dce.c (word_dce_process_block): Check whether inserting debug
temps are needed even for needed insns.
(dce_process_block): Likewise.
* df-problems.c (dead_debug_add): Add comment about multi-regs.
(dead_debug_insert_temp): Likewise.  Don't subreg when we're
setting fewer regs than a multi-reg requires.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dce.c
    trunk/gcc/df-problems.c