aboutsummaryrefslogtreecommitdiff
path: root/gcc/doc
diff options
context:
space:
mode:
authorJie Zhang <jie@codesourcery.com>2010-10-26 16:13:04 +0000
committerJie Zhang <jiez@gcc.gnu.org>2010-10-26 16:13:04 +0000
commit0d600fce5ba0aae8073f84b9c5f9296233f6f269 (patch)
tree1def84239e3f47c486cb01d95ea163c2e57e1573 /gcc/doc
parent75264e61bdb256689fb9fc1492bf6586ae2449fe (diff)
downloadgcc-0d600fce5ba0aae8073f84b9c5f9296233f6f269.zip
gcc-0d600fce5ba0aae8073f84b9c5f9296233f6f269.tar.gz
gcc-0d600fce5ba0aae8073f84b9c5f9296233f6f269.tar.bz2
invoke.texi: Improve documentation of -fstrict-volatile-bitfields.
* doc/invoke.texi: Improve documentation of -fstrict-volatile-bitfields. From-SVN: r165971
Diffstat (limited to 'gcc/doc')
-rw-r--r--gcc/doc/invoke.texi14
1 files changed, 8 insertions, 6 deletions
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ee68454..7ea042f 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.