Re: Fix g++.dg/torture/stackalign/eh-alloca-1.C with LTO plugin

[Jan Hubicka <hubicka at ucw dot cz>]

> On Wed, 1 Dec 2010, Jan Hubicka wrote:
> 
> > Hi,
> > this patch fixes the stackalign issues.  What happens here is that
> > dw2_force_const_mem produce an label that is supposed to point to given
> > constant in memory.  This is realized by dw2_output_indirect_constant_1 that
> > produce variable with the name smatching the label's name and appropriate
> > constructor.
> > 
> > This is used to encode personality routines for EH.
> > 
> > The catch is that the label name is "*.Lblah", while the static variable in LTO
> > mode ends up being "*.Lblah.1234" because we do the mangling of static vars.
> > This patch simply avoids all the mangling by enforcing the assembler name to be
> > same as label's assembler name.  It is what we want anyway.
> > 
> > I am not quite sure why this happens only with linker plugin. I assume that we
> > optimize the functions differently resulting in different EH info.
> > 
> > Regtested/bootstrapped x86_64-linux, OK?
> > 
> > Honza
> > 
> > 	* dwarf2asm.c (dw2_output_indirect_constant_1): Set assembler name
> > 	of the new decl.
> > Index: dwarf2asm.c
> > ===================================================================
> > --- dwarf2asm.c	(revision 167242)
> > +++ dwarf2asm.c	(working copy)
> > @@ -920,6 +920,7 @@ dw2_output_indirect_constant_1 (splay_tr
> >  
> >    sym_ref = gen_rtx_SYMBOL_REF (Pmode, sym);
> >    sym = targetm.strip_name_encoding (sym);
> > +  SET_DECL_ASSEMBLER_NAME (decl, id);
> 
> Shouldn't this be done before the DECL_ASSEMBLER_NAME use above?

Ah yes, though it is executed only at TREE_PUBLIC path that won't mangle.

> 
> Why doesn't it just work in mangled form?  We generate that decl
> at this very place, so I don't see how we get the chance to mangle it
> anyway.

I think it eventually gets into lto_set_decl_assembler_name that
uncionditionally mangles all statics.

Honza
> 
> Richard.