http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> 2011-12-20 11:56:22 UTC --- On Tue, 20 Dec 2011, ebotcazou at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 > > --- Comment #9 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-12-20 > 11:34:00 UTC --- > > You mean that handling the TYPE_ALIGN != MODE_ALIGN case when > > expanding a MEM_REF (thus, INDIRECT_REF on old branches) won't work? > > But you cannot have TYPE_ALIGN < MODE_ALIGN (TYPE_MODE). You can. Just check what you get with that aligned(1) int typedef. For vector types you can anyways (by design) to allow unaligned vector moves. Is it documented anywhere that you can't take the address of an unaligned structure member (given the struct is packed) on STRICT_ALIGNMENT targets (or, when it's a vector component even on non-STRICT_ALIGNMENT targets)? Why does the C frontend not warn for these cases (unconditionally?)? I don't see at all that we can't support expanding such moves properly. After all we can extract an INT mode value from unaligned memory (we are never generating a mem:BLK with INT mode size in that case anyway, or a MEM:SI with MEM_ALIGN less than SImode align anyway)
