[Bug middle-end/45722] [4.6 Regression] FAIL: gcc.c-torture/execute/20040709-2.c execution at -O1 and -Os

[ebotcazou at gcc dot gnu.org]

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?