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.