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

[rguenther at suse dot de]

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

--- Comment #29 from rguenther at suse dot de <rguenther at suse dot de> 2013-03-05 14:26:00 UTC ---
On Tue, 5 Mar 2013, rguenther at suse dot de wrote:

> 
> 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?

So in fact the issue must be that we _do_ share the constant pool
entry but not the decl we use to refer to it.  Which isn't very
easily fixable (well, it _is_ fixable, but ... )

OTOH in assemble_variable we properly use

  /* If this symbol belongs to the tree constant pool, output the constant
     if it hasn't already been written.  */
  if (TREE_CONSTANT_POOL_ADDRESS_P (symbol))
    {
      tree decl = SYMBOL_REF_DECL (symbol);
      if (!TREE_ASM_WRITTEN (DECL_INITIAL (decl)))
        output_constant_def_contents (symbol);
      return;
    }

so any constant pool entry shouldn't be emitted multiple times ...

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

So we can revert the part of the patch that ends up not creating
a new decl but only transfer DECL_ALIGN.  But then we still don't
"merge" the decls we use to refer to the constants, so I wonder
how creating less decls can fix this issue at all ...

Note that merging constants but not decls also can end up
creating bogusly aligned constants.  In fact it seems to me
that we need to arrange for the LTO path

  /* 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;
    }

to never share a constant pool entry ... :/

Bah.  A reduced testcase would be nice to have ...