[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue Mar 5 10:18:00 GMT 2013


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.



More information about the Gcc-bugs mailing list