https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79209
Bug ID: 79209 Summary: AArch64: Inconsistent packed volatile bitfield accesses Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Created attachment 40571 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40571&action=edit Packed volatile bitfield testcase for both C and C++. Hi. It seems that volatile bitfield structures with the packed attribute set (that are not accompanied with an aligned attribute) are accessed quite inconsistently. The instruction used to access the volatile bitfield depends on the optimization level, the bitfield width and the the value itself. Moreover, -fstrict-volatile-bitfields seems to have no particular effect on this matter (e.g. only a temporary register used to access field was changed). Yes, noticed that there was a note regarding packed fields in the manual, but perhaps I expected it to only cover some rare special cases. Consider the following structure and function: struct __attribute__((packed)) S0 { unsigned volatile int y : 1; unsigned volatile int x : 2; unsigned volatile int z : 29; } volatile struct S0 * fn(); When updating the structure GCC generally prefers ldr w/str w (word) pair, which is to be expected. However, based on the value being written GCC may access the structure using ldrb w/strb w (byte) pair; usually if structure access is not inlined and and/orr instruction is chosen based on the value being written. Of course, should the underlying hardware only support word access byte access will of couse fail -- hence the volatile bitfield in the first place. With both packed and aligned attributes set everything works as expected. I guess the packed bitfields have been somewhat difficult thing to define and agreed on, so a warning message (and a documentation entry explaining it) would be just fine. Certainly could be just that I'm wrong, but as this was a tad difficult to spot I'd still prefer it any day of the week. Tested using GCC 6.2, 6.3 and 7.0.1 (trunk) and they all produce pratically identical results. Both C and C++ frontends share this same mishap or feature. aarch64-none-elf-gcc -Wall -Wextra -mabi=lp64 -fstrict-volatile-bitfields -fno-exceptions -xc++ {-O0,-Og,-O1,-O2,-O3} -S packed-volatile-bitfield.in -o -