On 08/23/2012 03:08 AM, Richard Guenther wrote:
In fact, you should probably implement code-generation constraints from
within the frontends by, for strict volatile bitfields, emitting loads/stores
using DECL_BIT_FIELD_REPRESENTATIVE (doing read-modify-write
explicitely). Or maybe you can elaborate on the code-generation effects
of strict-volatile bitfields?
This was documented in the GCC manual at the same time the original
patch for extracting bit-field values was added:
@item -fstrict-volatile-bitfields
@opindex fstrict-volatile-bitfields
This option should be used if accesses to volatile bit-fields (or other
structure fields, although the compiler usually honors those types
anyway) should use a single access of the width of the
field'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 bit-fields as @code{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 uses the most efficient
instruction. In the previous example, that might be a 32-bit load
instruction, even though that accesses bytes that do not contain
any portion of the bit-field, or memory-mapped registers unrelated to
the one being updated.
If the target requires strict alignment, and honoring the field
type would require violating this alignment, a warning is issued.
If the field has @code{packed} attribute, the access is done without
honoring the field type. If the field doesn't have @code{packed}
attribute, the access is done honoring the field type. In both cases,
GCC assumes that the user knows something about the target hardware
that it is unaware of.
The default value of this option is determined by the application binary
interface for the target processor.
-Sandra
