[Bug middle-end/23623] volatile keyword changes bitfield access size from 32bit to 8bit

["m dot reszat at kostal dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From m dot reszat at kostal dot com  2005-08-30 07:43 -------
(In reply to comment #1)
> (In reply to comment #0)
> 
> > Access to bf1.b is correctly done as 32-bits (lwz/stw opcodes), bf2.b is
> > accessed as 8-bits (lbz/stb opcodes). GCC3.4.3 shows the same behaviour, can't
> > go back any further. The same happens when the bitfield itself is made volatile,
> > not the whole struct.
> 
> This is intentional. The idea is not to touch any more of that volatile stuff
> than absolutely needed. Why do you think it is a bug?

When dealing with peripherals in embedded systems, the use of bitfields makes
the code much more readable. 

Ex.: 3 bits of a peripheral register define a timer prescaler
It can be s.th. like 
#define PS_VAL_05 0x00140000
#define PS_MASK   0x001c0000
...
per_reg = (per_reg & ~PS_MASK) | PS_VAL_05;

But could be as simple as 
per_reg.ps = 5;, or even per_reg.ps = func(...); 
Try to set up the latter w/o bitfields and you end up
per_reg = (per_reg & ~PS_MASK) | (func(...) << PS_SHIFT);

Most (admittedly not all) modern peripherals allow the bitfield approach, but
correct access size is a must (misalignment traps, access triggered buffering
etc.). 
IMHO the compiler/code generator should always use the basic type when a
variable is declared as volatile, i.e. volatile unsigned int ps:3; should
enforce 32-bit-access, probably even for non-bitfields. All compilers for
embedded systems I know of act this way, so I assumed this was a bug.
In other cases, e.g. communicating between threads through memory, access size
is not an issue and even if so, could be enforced by appropriate declaration or,
god help me, typecasting as a last resort.
Unfortunately, C does not provide a qualifier for access size enforcement,
"volatile" seems to be the closest friend. The current implementation puts me
between a rock and a hard place, as the "core volatile functionality" is needed
as well.
What do you think?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623