Open jstengleingithub opened 8 months ago
CC @AaronBallman @erichkeane
Note this option is required to get the correct ABI behavior for arm-eabi and aarch64 ABIs. GCC implements/handles it in the middle-end instead of in the arm/aarch64 backends so it could be used by other targets if needed.
h8300, m32c, rx and sh targets in GCC all enable it by default too.
@llvm/issue-subscribers-clang-codegen
Author: Jeremy Stenglein (jstengleingithub)
Does the lowering of bitfields in clang to loads/stores and bit manipulation already guarantee that bit field accesses are strict?
Hmm... i see value in having the flag, but I am unsure of how we manage these accesses today. I could swear we do strict access of bitfields in nearly any case already, right? Any such patch here is going to need to do some sort of analysis to ensure figure out what would actually CHANGE with this feature.
-fstrict-volatile-bitfields is accepted by gcc:
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
-fstrict-volatile-bitfields This option should be used if accesses to volatile bit-fields (or other structure fields, although the compiler usually honors those types anyway) should use a single access of the width of the field’s type, aligned to a natural alignment if possible. For example, targets with memory-mapped peripheral registers might require all such accesses to be 16 bits wide; with this flag you can declare all peripheral bit-fields as unsigned short (assuming short is 16 bits on these targets) to force GCC to use 16-bit accesses instead of, perhaps, a more efficient 32-bit access.
Clang does not accept it however: