[Bug debug/53470] [4.8 Regression] ICE when linking with -g in splice_child_die, at dwarf2out.c:4264

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> 2012-06-06 11:55:32 UTC ---
On Tue, 5 Jun 2012, jason at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53470
> 
> Jason Merrill <jason at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |jason at gcc dot gnu.org
> 
> --- Comment #7 from Jason Merrill <jason at gcc dot gnu.org> 2012-06-05 18:07:14 UTC ---
> OK, here's the problem:
> 
> free_lang_data_in_type clears TYPE_CONTEXT of Holder.
> gen_tagged_type_die tries to emit an enclosing class first, but since
> TYPE_CONTEXT is null, it thinks Holder isn't a nested class.
> gen_struct_or_union_type_die calls scope_die_for, which forces out
> ExtensionCord, which also generates a DIE for Holder.
> gen_struct_or_union_type_die contiues to generate what is now a duplicate DIE
> for Holder.
> 
> What is the rationale for clearing TYPE_CONTEXT of Holder?  It seems quite
> deliberate, but there's no comment explaining why it would be a good idea.

All of the clearing is done to push down memory usage and/or cause
types to be referenced that are otherwise unused.  A way to retain the
latter would be to not recurse into TYPE_CONTEXT during find_decls_types_r
and in free_lang_data_in_type only reset TYPE_CONTEXT when
that is not in fld.pset (thus we didn't visit it, aka, it is unused).

Not sure if this will reliably fix this kind of ICEs.

Note that the fundamental issue with running free-lang-data with -g0
and lto1 with -g is that free-lang-data with -g0 assumes we won't
generate debug information.  I think the case in question is the
only remaining case we do different things -g0 vs. -g in
free-lang-data - and we should definitely remove that inconsistency.

Thus, I suppose even the simple

Index: tree.c
===================================================================
--- tree.c      (revision 188260)
+++ tree.c      (working copy)
@@ -4575,10 +4575,9 @@ free_lang_data_in_type (tree type)
   free_lang_data_in_one_sizepos (&TYPE_SIZE (type));
   free_lang_data_in_one_sizepos (&TYPE_SIZE_UNIT (type));

-  if (debug_info_level < DINFO_LEVEL_TERSE
-      || (TYPE_CONTEXT (type)
-         && TREE_CODE (TYPE_CONTEXT (type)) != FUNCTION_DECL
-         && TREE_CODE (TYPE_CONTEXT (type)) != NAMESPACE_DECL))
+  if (TYPE_CONTEXT (type)
+      && TREE_CODE (TYPE_CONTEXT (type)) != FUNCTION_DECL
+      && TREE_CODE (TYPE_CONTEXT (type)) != NAMESPACE_DECL)
     TYPE_CONTEXT (type) = NULL_TREE;
 }

should be ok at the expense of extra memory/disk space usage at -g0
(note we walk TYPE_CONTEXT for all types in find_decls_types_r, so
even the restriction above looks odd - either we should restrict
recursion as well or never clear TYPE_CONTEXT).

Richard.