So... can I/we move forward on this? Or will such a change be rejected? BTW, Since sending this I discovered that gcc treats these differently wrt TARGET_NARROW_VOLATILE_BITFIELD:
volatile struct { unsigned int a:8; unsigned int b:24; } t1; volatile struct { unsigned int a:7; unsigned int b:25; } t2; t1.a will be accessed as a byte regardless of the target's preferences, whereas t2.c follows the target preferences. > One of our customers has a chip with memory-mapped peripheral > registers that need to be accessed in a specific mode. The registers > represent bitfields within the hardware, so a volatile struct is an > obvious choice to represent them in C. > > However, gcc has a very simplistic heuristic for deciding what mode to > use to access bitfields in structures - it uses either the biggest or > smallest mode practical. This offers the programmer no way to tell > gcc what mode the accesses need to be in, aside from manually > reading/writing memory with integer types and casting. > > Options? My thought, after some internal discussion, is that (if the > target chooses) we allow gcc to honor the type of a volatile bitfield > as the mode as long as it can do so without otherwise violating the > structure's layout. Some new hook will be needed for the backend, and > perhaps a -W option for when the type cannot be honored. > > I.e. if the programmer is careful enough to properly lay out the > struct, the programmer should get what the programmer asks for. > > Comments? Alternatives?