http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-05
10:18:01 UTC ---
(In reply to comment #23)
> > How can the patch cause a name collision when all the patch does is
> > avoid creating a new decl...? They are static and thus should be
> > mangled.
>
> They clearly aren't.
>
> > Well, and if we want a new decl just to re-assign a unique name here
> > then we want to copy over alignment information. That is, LTO should
> > handle constant-pool entries by _not_ streaming the decl then. Honza,
> > how are those supposed to make the symtab -> WPA -> LTRANS transition
> > anyway?
>
> The irony being that the initial implementation didn't stream the DECL but was
> changed because the varpool was just starting to being streamed as well. :-)
Yes, we do refer to the in the IL so we need to stream them (in some way).
The question is why we don't hit lto-lang.c:lto_set_decl_assembler_name
mangling of !TREE_PUBLIC decls when streaming in the decl for the constant
pool entries (or when computing the assembler name at some point).
I suppose we never compute decl-assembler-name for the constant pool entries
but emit them in a special way? At least build_constant_desc seems to
create a raw SYMBOL_RER using the raw created label? But then, as we
don't stream the constant-descs, the RTL should refer to unique labels
(but DECL_NAME and the SYMBOL_REF symbol do not agree).
Which means that eventually the following would fix it:
Index: gcc/varasm.c
===================================================================
--- gcc/varasm.c (revision 196451)
+++ gcc/varasm.c (working copy)
@@ -3124,6 +3124,11 @@ build_constant_desc (tree exp, tree decl
else
align_variable (decl, 0);
}
+ /* If we already had a decl for this constant pool entry adjust its
+ label to be unique within this translation unit and to make it
+ consistent with the symbol-ref symbol we use below. */
+ else
+ DECL_NAME (decl) = get_identifier (label);
/* Now construct the SYMBOL_REF and the MEM. */
if (use_object_blocks_p ())
can you check that?
Thanks.
