------- 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
