This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #27 from rguenther at suse dot de <rguenther at suse dot de> 2013-03-05 13:58:15 UTC ---
On Tue, 5 Mar 2013, ebotcazou at gcc dot gnu.org wrote:

> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
> 
> --- Comment #26 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-03-05 13:51:28 UTC ---
> > 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?
> 
> Right, see make_decl_rtl:
> 
>   /* If this variable belongs to the global constant pool, retrieve the
>      pre-computed RTL or recompute it in LTO mode.  */
>   if (TREE_CODE (decl) == VAR_DECL && DECL_IN_CONSTANT_POOL (decl))
>     {
>       SET_DECL_RTL (decl, output_constant_def_1 (DECL_INITIAL (decl),
>                          decl, 1));
>       return;
>     }
> 
> > 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).
> 
> I think the problem is that, with your patch, the DECLs are not unified when
> they have the same DECL_INITIAL (decl), even if they have the same RTL in the
> end.

Hmm, but when I use the same contents for the two arrays in my simple
testcase I do get only a single .LC0 output referenced from two places.
We will end up sharing the same RTL for both (unmerged) DECLs - but
I don't see how this can be a problem?  Maybe we fail to set
TREE_ASM_WRITTEN on the duplicate and output it anyway via other 
mechanisms?

But I can reproduce the Ada LTO bootstrap failure ...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]