------- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-16 10:17 -------
DECL_ALIGN of d is set to 128 (but appearantly it isn't ensured it'll end up
that way). DECL_ALIGN is adjusted here:
Old value = 32
New value = 128
expand_one_stack_var_at (decl=0x7ffff5ae90a0, offset=-16)
at /space/rguenther/src/svn/trunk/gcc/cfgexpand.c:739
739 DECL_USER_ALIGN (decl) = 0;
so on trunk get_object_alignment of the MEM_REF will return 128 and thus
we do not run into unaligned move expansion here:
if (mode != BLKmode
&& (unsigned) align < GET_MODE_ALIGNMENT (mode)
/* If the target does not have special handling for unaligned
loads of mode then it can use regular moves for them. */
&& ((icode = optab_handler (movmisalign_optab, mode))
!= CODE_FOR_nothing))
manually setting alignment back to 32 in gdb results in ok asm.
movlps (%esp), %xmm0
movhps 8(%esp), %xmm0
mulps .LC4, %xmm0
instead of
mulps (%esp), %xmm0
Appearantly stack alignment code doesn't work.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hjl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
