[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 #16 from rguenther at suse dot de <rguenther at suse dot de> 2013-02-14 08:56:12 UTC ---
On Wed, 13 Feb 2013, ebotcazou at gcc dot gnu.org wrote:

> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
> 
> --- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-02-13 22:13:42 UTC ---
> > In LTO:
> > 
> >   /* 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 (DECL_INITIAL (decl), 1));
> >       return;
> > 
> > but obviously output_constant_def when just getting DECL_INITIAL cannot
> > honor any special alignment requirements of decl.  It will simply get
> > a new decl with standard alignment.
> > 
> > We know decl is already the decl associated with the constant, so we
> > should just re-use it.
> 
> Why does the alignment of a DECL_IN_CONSTANT_POOL matter here exactly?

Because as it is seen as a regular VAR_DECL by optimizers the
vectorizer (well, IPA increase-alignment in this case) chooses to
bump its alignment to be able to use aligned vector moves.

Thus we need to honor the increased DECL_ALIGN when outputting the
constant pool, otherwise we generate wrong-code.