RE: [PATCH] reimplement -fstrict-volatile-bitfields v4, part 2/2

[Bernd Edlinger <bernd dot edlinger at hotmail dot de>]

Hi,

On Mon, 30 Sep 2013 16:18:30, DJ Delorie wrote:
>
> As per my previous comments on this patch, I will not approve the
> changes to the m32c backend, as they will cause real bugs in real
> hardware, and violate the hardware's ABI. The user may use
> -fno-strict-volatile-bitfields if they do not desire this behavior and
> understand the consequences.
>
> I am not a maintainer for the rx and h8300 ports, but they are in the
> same situation.
>
> To reiterate my core position: if the user defines a proper "volatile
> int" bitfield, and the compiler does anything other than an int-sized
> access, the compiler is WRONG. Any optimization that changes volatile
> accesses to something other than what the user specified is a bug that
> needs to be fixed before this option can be non-default.

hmm, I just tried to use the latest 4.9 trunk to compile the example from
the AAPCS document:

struct s
{
  volatile int a:8;
  volatile char b:2;
};

struct s ss;

int
main ()
{
  ss.a=1;
  ss.b=1;
  return 0;
}

and the resulting code is completely against the written AAPCS specification:

main:
        @ Function supports interworking.
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        ldr     r3, .L2
        ldrh    r2, [r3]
        bic     r2, r2, #254
        orr     r2, r2, #1
        strh    r2, [r3]        @ movhi
        ldrh    r2, [r3]
        bic     r2, r2, #512
        orr     r2, r2, #256
        strh    r2, [r3]        @ movhi
        mov     r0, #0
        bx      lr

two half-word accesses, to my total surprise!

As it looks like, the -fstrict-volatile-bitfields are already totally broken,
apparently in favour of the C++ memory model, at least at the write-side.

These are aligned accesses, not the packed structures, that was the
only case where it used to work once.

This must be fixed. I do not understand why we cannot agree, that
at least the bug-fix part of Sandra's patch needs to be applied.

Regards
Bernd.