http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
Bernd Edlinger <bernd.edlinger at hotmail dot de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bernd.edlinger at hotmail dot
de
--- Comment #6 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Sandra Loosemore from comment #5)
> Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00750.html
Hi Sandra,
I tried your patch, but I dont like the code that it generates:
printf("%x\n", (unsigned int)g.b);
g.b = 0xAAAAAAA;
is compiled to invalid code (in ARMv5)
ldr r4, .L2
ldr r1, [r4]
ldr r3, [r4, #4]
and r3, r3, #7
mov r3, r3, asl #25
orr r1, r3, r1, lsr #7
ldr r0, .L2+4
bl printf
ldr r2, [r4]
ldr r3, .L2+8
and r2, r2, #127
orr r3, r2, r3
str r3, [r4]
ldr r3, [r4, #4]
bic r3, r3, #7
orr r3, r3, #5
str r3, [r4, #4]
code is invalid because: the object "g" is only 5 bytes large,
but the first statement reads 2x4 bytes, and ignores the 3 extra bytes.
this can fault if g is close to a segment boundary.
The second statement reads the 3 bytes beyond g and writes them
unmodified back. That is problematic if a task switch occurs between the
read and store sequence, and the other task modifies something in the 3 bytes.
Previous versions of gcc produced single 5x1 byte read/write sequences for
that structure, as does apparently the x86 version.
Regards
Bernd.
