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


Reply via email to