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?
