This is the mail archive of the gcc@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]

Re: bitfields: types vs modes?


On Tue, 10 Mar 2009, DJ Delorie wrote:
> 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.

Thank you for those words.  ;)

(There was a "minor argument" on IRC some time ago on a related
subject.)

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

And not even *then* are you guaranteed the intended semantics as
per the documentation (though at least each target should be
able to promise that, IMNSHO).  IMHO GCC should have the means
to do what you suggest for *all* targets; memory-mapped I/O that
needs to be accessed in a specific mode is a general-enough
situation.

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

Can you provide example code?  I'm confused enough to believe
that you *should* get this effect with PCC_BITFIELD_TYPE_MATTERS
(modulo current bugs).

> Comments?

The concept is certainly agreeable.  I'd recommend -fno-tree-sra
when you inspect current behavior; there be bugs there.  Sorry,
no PR yet.

brgds, H-P


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