This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 05 Mar 2013 13:58:15 +0000
- Subject: [Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
- Auto-submitted: auto-generated
- References: <bug-50494-4@http.gcc.gnu.org/bugzilla/>
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 ...