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.
