This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]