On Wed, Oct 9, 2013 at 3:09 AM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > 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.
Note that the C++ memory model restricts the _maximum_ memory region we may touch - it does not constrain the minimum as AAPCS does. What I would suggest is to have a -fgnu-strict-volatile-bit-fields (or two levels of it) enabled by default on AAPCS targets which will follow the AAPCS if it doesn't violate the maximum memory region constraints of the C++ memory model. I never claimed that the C++ memory model is good enough for AAPCS but there was consensus that the default on AAPCS should not violate the C++ memory model by default. -fgnu-strict-volatile-bit-fields should be fully implementable in get_best_mode if you pass down the desired AAPCS mode. Richard. > 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.