http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45722
--- Comment #33 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-12
17:34:26 UTC ---
> 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).
Yes, accesses to unaligned stuff is an old problem, see for example PR c/18287,
and INDIRECT_REFs indeed never tried to handle this. However, this shouldn't
be the problem here since there are no indirect accesses involved, it's just:
struct E sE;
struct E x;
x = sE;
Why on earth does SRA now introduce indirect accesses to scalarize a direct
assignment between 2 structures with the same type?
