diff options
| author | jiez <jiez@138bc75d-0d04-0410-961f-82ee72b054a4> | 2010-10-26 16:13:04 +0000 |
|---|---|---|
| committer | jiez <jiez@138bc75d-0d04-0410-961f-82ee72b054a4> | 2010-10-26 16:13:04 +0000 |
| commit | c0fc75c3a05ed0c07fb0675c18813227c916a52a (patch) | |
| tree | 1def84239e3f47c486cb01d95ea163c2e57e1573 | |
| parent | 4ba746627517cb5154a1762a6745c30a93291a50 (diff) | |
| download | gcc-c0fc75c3a05ed0c07fb0675c18813227c916a52a.tar.gz | |
* doc/invoke.texi: Improve documentation of
-fstrict-volatile-bitfields.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@165971 138bc75d-0d04-0410-961f-82ee72b054a4
| -rw-r--r-- | gcc/ChangeLog | 5 | ||||
| -rw-r--r-- | 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 <jie@codesourcery.com> + + * doc/invoke.texi: Improve documentation of + -fstrict-volatile-bitfields. + 2010-10-26 Ira Rosen <irar@il.ibm.com> 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. |