I'm starting from an MCU that doesn't work right if GCC doesn't do what the user tells GCC to do. I added -fstrict-volatile-bitfields to tell gcc that it needs to be more strict than the standard allows for bitfield access, because without that flag, there's no way to force gcc to use a specific access width on bitfields. When I added that flag, some ARM folks chose to enable it in their target, because they felt they needed it. If different ARM folks feel otherwise, that's a target problem.
If the user tells gcc that a particular 32-bit memory location should be treated as both a char and a long, then gcc has been given inconsistent information. The spec says it can do what it wants to access that memory, and it does. If the user tells gcc that a particular 16-bit memory location consists of 16-bits worth of "unsigned short", and the user has told gcc that it needs to be strict about accessing that field in the type specified, and gcc uses a 32-bit access anyway, gcc is wrong. I will agree with you 100% that gcc can do whatever the spec allows if the user does NOT specify -fstrict-volatile-bitfields, but the flag is there to tell gcc that the user needs stricter control than the spec demands. If the user uses that flag, *and* gives gcc information that is inconsistent with the use of that flag, then the user is wrong. I note that you assume GNU/Linux is involved, perhaps that's part of the problem. Maybe the Linux kernel needs gcc to ignore its bitfield types, but other ARM firmware may have other requirements. If you and the other ARM maintainers want to argue over whether -fstrict-volatile-bitfields is enabled by default for the ARM target, go for it. Just leave my targets alone. > where those semantics contradict the semantics of ISO C. Where in the spec does it say that a compiler MUST access an "unsigned short" bitfield with a 32-bit access? I've seen places where it says the compiler MAY or MIGHT do it, but not MUST.
