From 0d600fce5ba0aae8073f84b9c5f9296233f6f269 Mon Sep 17 00:00:00 2001 From: Jie Zhang Date: Tue, 26 Oct 2010 16:13:04 +0000 Subject: [PATCH] invoke.texi: Improve documentation of -fstrict-volatile-bitfields. * doc/invoke.texi: Improve documentation of -fstrict-volatile-bitfields. From-SVN: r165971 --- gcc/ChangeLog | 5 +++++ gcc/doc/invoke.texi | 14 ++++++++------ 2 files changed, 13 insertions(+), 6 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 1906f53720e..661e0c15fa8 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,8 @@ +2010-10-26 Jie Zhang + + * doc/invoke.texi: Improve documentation of + -fstrict-volatile-bitfields. + 2010-10-26 Ira Rosen PR tree-optimization/46167 diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index ee68454fc16..7ea042f6775 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -18120,8 +18120,8 @@ is at @uref{http://gcc.gnu.org/@/wiki/@/Visibility}. @opindex 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 +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 bitfields as ``unsigned short'' (assuming short @@ -18134,11 +18134,13 @@ 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 +If the target requires strict alignment, and honoring the field 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. +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. -- 2.30.2