Patchwork Fix PR53471, remove DECL_ASSEMBLER_NAME deferred compute

login
register
mail settings
Submitter Richard Guenther
Date June 4, 2012, 8:55 a.m.
Message ID <Pine.LNX.4.64.1206041048150.5860@jbgna.fhfr.qr>
Download mbox | patch
Permalink /patch/162682/
State New
Headers show

Comments

Richard Guenther - June 4, 2012, 8:55 a.m.
On Fri, 1 Jun 2012, Jason Merrill wrote:

> On 06/01/2012 05:22 AM, Richard Guenther wrote:
> > On Thu, 31 May 2012, Jason Merrill wrote:
> >
> > > The comment mentions PCH in connection with deferred seting of
> > > DECL_ASSEMBLER_NAME; off the top of my head it occurs to me that that
> > > might be
> > > connected with anonymous unions, which need to have different linkage
> > > names in
> > > different translation units.
> >
> > Not sure when PCH generation happens (or when we call
> > rest_of_type_compilation), but shouldn't that be way earlier than
> > the debug output?
> 
> PCH generation happens at the beginning of cp_write_global_declarations;
> rest_of_type_compilation, which triggers the debug output, is called after
> each class definition.
> 
> > Anyway, any suggestion on how to tackle the issue
> > that we cannot compute new DECL_ASSEMBLER_NAMEs after the frontend
> > is finished?
> 
> Fix up the deferred_asm_name list somewhere between the call to
> c_common_write_pch and the call to free_lang_data.  I guess this would mean
> another debug hook for processing that needs to happen before free_lang_data.

That's certainly possible - add a finish_compilation_unit debug hook.
I'll think about that for 4.8.

> Or fix free_lang_data to deal with these types, too.

Unfortunately they are not "reachable" from anything but the
deferred_asm_name list.  So it would mean another debug hook.

> Or use your first patch, and decide that we don't care about the linkage name
> of unreachable types.  What types are affected by this, anyway?

Types affected by this are types not referenced from any object/function
that is being output as LTO bytecode (and the type will not be output
as LTO bytecode either, so at LTO time we'd not generate debuginfo for
it either).  It's basically completely "unused" types that are affected.

I suppose that's indeed the easiest fix - all "important" types should
have been assigned an assembler name by free-lang-data.  One issue
is that free-lang-data (and its assembler name assigning code) is not
run if -flto is not enabled ...

So I suppose for the 4.7 branch we'd go with


and for trunk change two things - make sure the assembler-name assigning
piece of free-lang-data runs unconditionally and a debug hook is added
so we can output debuginfo dependent on langhooks.

I am going to test the above and install it on trunk and the branch
for now to get into 4.7.1.

Thanks,
Richard.

Patch

Index: dwarf2out.c
===================================================================
--- dwarf2out.c (revision 188106)
+++ dwarf2out.c (working copy)
@@ -22158,7 +22158,8 @@  dwarf2out_finish (const char *filename)
   for (node = deferred_asm_name; node; node = node->next)
     {
       tree decl = node->created_for;
-      if (DECL_ASSEMBLER_NAME (decl) != DECL_NAME (decl))
+      if ((!flag_generate_lto || DECL_ASSEMBLER_NAME_SET_P (decl))
+         && DECL_ASSEMBLER_NAME (decl) != DECL_NAME (decl))
        {
          add_linkage_attr (node->die, decl);
          move_linkage_attr (node->die);