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.
