http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45722
--- Comment #30 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-12
13:01:56 UTC ---
(insn 88 87 89 5 (set (reg:DI 134 [ x$l ])
(mem/c:DI (reg/f:SI 185) [0 MEM[(struct E *)&sE]+0 S8 A8]))
pr45722.c:50 -1
(nil))
The memory has MEM_ALIGN 8, but we of course just ignore that for
STRICT_ALIGNMENT targets. So the situation is similar to the old
mishandling of
typedef int myint __attribute__((aligned(1)));
int foo (myint *p)
{
return *p;
}
int main()
{
char c[5];
return foo (&c[1]);
}
where on old GCC releases we don't run into unaligned memory load
handling for STRICT_ALINGMENT targets either (INDIRECT_REF never
tried to handle that case, I tried to cover up for that with
usign movmisalign where available for MEM_REF). Now as the alignment
info on the type of the mem-ref is bogus the
align = MAX (TYPE_ALIGN (TREE_TYPE (exp)),
get_object_alignment (exp, BIGGEST_ALIGNMENT));
hunk will make that handling not trigger anyway.
So, it's a) SRAs fault to not preserve alignment b) a general and
very very old problem of GCC (the C FE also doesn't have proper
types when taking the address of a field of a packed struct).
