[Bug middle-end/57748] [4.8/4.9 Regression] ICE on ARM with -mfloat-abi=softfp -mfpu=neon

["bernd.edlinger at hotmail dot de" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #8 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Martin Jambor from comment #7)
> In any event, it is clear that
> the code in expand_assignment cannot cope with unaligned tem and non-NULL
> offset.  So currently I'm considering the following patch, although I am not
> really sure it is enough (it does fix the ICE, though).  If you can run the
> testcase on the platform, would you run it with this patch applied, please?

No, unfortunately I can only look at the assembler listing.

But wait a moment...

If the object is assumed to be unaligned here this patch will
likely just compute the unaligned address, add the offset,
and store the result there without any special precautions.
While the code in the if statement seems to store the expression
on a register and move that register to the final destination.

Well, I believe this unaligned arrays are generally broken.

consider this example:

struct test
{
  char x;
  long long y[10];
} __attribute__((packed));

long long foo(struct test *x, long long y, long long z)
{
   long long a = x->y[y];
   x->y[y] = z;
   return a;
}

gets compiled to:

foo:
        @ Function supports interworking.
        @ args = 8, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        stmfd   sp!, {r4, r5}
        add     r5, sp, #8
        ldmia   r5, {r4-r5}
        add     r2, r0, r2, asl #3
        add     r1, r2, #1
        ldmia   r1, {r0-r1}
        str     r4, [r2, #1]
        str     r5, [r2, #5]
        ldmfd   sp!, {r4, r5}
        bx      lr

Won't these ldmia statements statements fault on unaligned
addresses, even on a cortex-a9 ?

Furthermore str on odd addresses are always there, regardless of the
-mno-unaligned-access setting.