This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/23623] volatile keyword changes bitfield access size from 32bit to 8bit
- From: "falk at debian dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 30 Aug 2005 12:26:34 -0000
- Subject: [Bug middle-end/23623] volatile keyword changes bitfield access size from 32bit to 8bit
- References: <20050829140226.23623.m.reszat@kostal.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From falk at debian dot org 2005-08-30 12:26 -------
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> When dealing with peripherals in embedded systems, the use of bitfields makes
> the code much more readable.
I can see that.
> Most (admittedly not all) modern peripherals allow the bitfield approach, but
> correct access size is a must (misalignment traps, access triggered buffering
> etc.).
I can see that too, but I don't see what it has to do with this PR.
> 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.
OK, but why? You still haven't explained. What exactly is the problem with
your code the way gcc does things currently?
> All compilers for
> embedded systems I know of act this way, so I assumed this was a bug.
The only other compiler I have around (DEC C) behaves the same way as gcc
(which is, to take the narrowest possible access that can be still done
in one instruction).
In any case, even if the current behavior isn't perfect, we would need an
extremely and utterly good reason to change it, lest we screw over lots
of users relying on the current behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623