Markup and minor fixes in LTO documentation.

gcc/:
	* doc/lto.texi (LTO): Ensure two spaces after period.  Fix
	spacing after 'e.g.', typos, comma, hyphenation.

From-SVN: r168931

gcc/ChangeLog

+2011-01-17  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>
+
+	* doc/lto.texi (LTO): Ensure two spaces after period.  Fix
+	spacing after 'e.g.', typos, comma, hyphenation.
+
 2011-01-17  Richard Henderson  <rth@redhat.com>
 
 	* config/rx/predicates.md (rx_constshift_operand): Use match_test.

gcc/doc/lto.texi

@@ -27,7 +27,7 @@ the files.  Additionally, one might be able to ship one set of fat
 objects which could be used both for development and the production of
 optimized builds.  A, perhaps surprising, side effect of this feature
 is that any mistake in the toolchain that leads to LTO information not
-being used (e.g. an older @code{libtool} calling @code{ld} directly).
+being used (e.g.@: an older @code{libtool} calling @code{ld} directly).
 This is both an advantage, as the system is more robust, and a
 disadvantage, as the user is not informed that the optimization has
 been disabled.
@@ -120,11 +120,11 @@ call-graph partitions.
 @end enumerate
 
 WHOPR can be seen as an extension of the usual LTO mode of
-compilation.  In LTO, WPA and LTRANS and are executed within a single
+compilation.  In LTO, WPA and LTRANS are executed within a single
 execution of the compiler, after the whole program has been read into
 memory.
 
-When compiling in WHOPR mode the callgraph is partitioned during
+When compiling in WHOPR mode, the callgraph is partitioned during
 the WPA stage.  The whole program is split into a given number of
 partitions of roughly the same size.  The compiler tries to
 minimize the number of references which cross partition boundaries.
@@ -149,13 +149,13 @@ are described below.
 @item Command line options (@code{.gnu.lto_.opts})
 
 This section contains the command line options used to generate the
-object files.  This is used at link-time to determine the optimization
+object files.  This is used at link time to determine the optimization
 level and other settings when they are not explicitly specified at the
 linker command line.
 
 Currently, GCC does not support combining LTO object files compiled
 with different set of the command line options into a single binary.
-At link-time, the options given on the command line and the options
+At link time, the options given on the command line and the options
 saved on all the files in a link-time set are applied globally.  No
 attempt is made at validating the combination of flags (other than the
 usual validation done by option processing).  This is implemented in
@@ -367,7 +367,7 @@ Most optimization passes split naturally into analysis,
 propagation and transformation stages.  But some do not.  The
 main problem arises when one pass performs changes and the
 following pass gets confused by seeing different callgraphs
-betwee the @emph{Transform} stage and the @emph{Generate summary}
+between the @emph{Transform} stage and the @emph{Generate summary}
 or @emph{Execute} stage.  This means that the passes are required
 to communicate their decisions with each other.
 
@@ -476,7 +476,7 @@ provided with the link-time information.  In GCC, the whole
 program option (@option{-fwhole-program}) asserts that every
 function and variable defined in the current compilation
 unit is static, except for function @code{main} (note: at
-link-time, the current unit is the union of all objects compiled
+link time, the current unit is the union of all objects compiled
 with LTO).  Since some functions and variables need to
 be referenced externally, for example by another DSO or from an
 assembler file, GCC also provides the function and variable