This is the mail archive of the 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: patch: honor volatile bitfield types

> From: DJ Delorie <>
> Date: Wed, 16 Jun 2010 18:53:54 -0400

A bit of thread hijacking (moving it to gcc@) I'm afraid, but
it's too related to pass up on the opportunity...

> Index: gcc/doc/invoke.texi
> ===================================================================
> --- gcc/doc/invoke.texi	(revision 160864)
> +++ gcc/doc/invoke.texi	(working copy)
> @@ -17722,12 +17722,38 @@ be thrown between DSOs must be explicitl
>  visibility so that the @samp{type_info} nodes will be unified between
>  the DSOs.
>  An overview of these techniques, their benefits and how to use them
>  is at @w{@uref{}}.
> +@item -fstrict-volatile-bitfields
> +This option should be used if accesses to volatile bitfields (or other
> +structure fields, although the compiler usually honors those types
> +anyway) should use a single access in a mode of the same size as the
> +container's type, aligned to a natural alignment if possible.  For
> +example, targets with memory-mapped peripheral registers might require
> +all such accesses to be 16 bits wide; with this flag the user could
> +declare all peripheral bitfields as ``unsigned short'' (assuming short
> +is 16 bits on these targets) to force GCC to use 16 bit accesses
> +instead of, perhaps, a more efficient 32 bit access.
> +
> +If this option is disabled, the compiler will use the most efficient
> +instruction.  In the previous example, that might be a 32-bit load
> +instruction, even though that will access bytes that do not contain
> +any portion of the bitfield, or memory-mapped registers unrelated to
> +the one being updated.
> +
> +If the target requires strict alignment, and honoring the container
> +type would require violating this alignment, a warning is issued.
> +However, the access happens as the user requested, under the
> +assumption that the user knows something about the target hardware
> +that GCC is unaware of.
> +
> +The default value of this option is determined by the application binary
> +interface for the target processor.
> +
>  @end table

Can we similarly promise or say something for accesses of the
containing struct as a whole?

I.e. "struct io { unsigned int data : 8;
unsigned int data_av : 1; unsigned int this : 7;
unsigned int that : 8; unsigned int other : 8;};"
and whole-struct assignments through "volatile struct io *iop"?

For one, should this option matter there?

For another, can we promise to not split up such an access for
machines where a full-32-bit-word access makes sense?

I'm asking because a bug in SRA once split up a read followed by
a write of a similar struct (too many single-bit fields to serve
as an example) into *four* variously-sized reads and writes, and
intermixed at that, and I got pushback when arguing the
obviousness of the full access being TRT.

brgds, H-P
PS: Right, for a Linux driver, always access through readl/writel.

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