git
/
gcc
mirror of git://gcc.gnu.org/git/gcc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

extend.texi: Follow spelling conventions. 

* doc/extend.texi: Follow spelling conventions.
	* doc/invoke.texi: Fix a typo.

From-SVN: r169420
This commit is contained in:
Kazu Hirata 2011-01-30 22:25:31 +00:00 committed by Kazu Hirata
parent e543b94c18
commit c4c8962b49
3 changed files with 9 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
gcc/ChangeLog
View File

@ -1,3 +1,8 @@
2011-01-30 Kazu Hirata <kazu@codesourcery.com>
* doc/extend.texi: Follow spelling conventions.
* doc/invoke.texi: Fix a typo.
2011-01-30 Joseph Myers <joseph@codesourcery.com>
* config/hpux11.opt: New.

6
gcc/doc/extend.texi
View File

@ -13649,9 +13649,9 @@ The C++ standard differs from the C standard in its treatment of
volatile objects. It fails to specify what constitutes a volatile
access, except to say that C++ should behave in a similar manner to C
with respect to volatiles, where possible. However, the different
lvalueness of expressions between C and C++ complicate the behaviour.
lvalueness of expressions between C and C++ complicate the behavior.
G++ behaves the same as GCC for volatile access, @xref{C
Extensions,,Volatiles}, for a description of GCC's behaviour.
Extensions,,Volatiles}, for a description of GCC's behavior.
The C and C++ language specifications differ when an object is
accessed in a void context:
@ -13681,7 +13681,7 @@ possible to ignore the return value from functions returning volatile
references. Again, if you wish to force a read, cast the reference to
an rvalue.
G++ implements the same behaviour as GCC does when assigning to a
G++ implements the same behavior as GCC does when assigning to a
volatile object -- there is no reread of the assigned-to object, the
assigned rvalue is reused. Note that in C++ assignment expressions
are lvalues, and if used as an lvalue, the volatile object will be

2
gcc/doc/invoke.texi
View File

@ -7690,7 +7690,7 @@ This option enables the extraction of object files with GIMPLE bytecode out of
library archives. This improves the quality of optimization by exposing more
code the the link time optimizer. This information specify what symbols
can be accessed externally (by non-LTO object or during dynamic linking).
Resulting code quality improvements on binaries (and shared libaries that do
Resulting code quality improvements on binaries (and shared libraries that do
use hidden visibility) is similar to @code{-fwhole-program}. See
@option{-flto} for a description on the effect of this flag and how to use it.