[Bug target/56997] Incorrect write to packed field when strict-volatile-bitfields enabled on aarch32

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

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.