invoke.texi (Link Options): Many editorial changes around -flinker-output.
authorGerald Pfeifer <gerald@pfeifer.com>
Sun, 26 May 2019 17:33:52 +0000 (17:33 +0000)
committerGerald Pfeifer <gerald@gcc.gnu.org>
Sun, 26 May 2019 17:33:52 +0000 (17:33 +0000)
* doc/invoke.texi (Link Options): Many editorial changes around
-flinker-output.

From-SVN: r271633

gcc/ChangeLog
gcc/doc/invoke.texi

index bccecbb5e47b639a82ecfbd421c313b3f484f7f2..2ffb48cef0f0327f5e95e55ac56303d482fdb847 100644 (file)
@@ -1,3 +1,8 @@
+2019-05-26  Gerald Pfeifer  <gerald@pfeifer.com>
+
+       * doc/invoke.texi (Link Options): Many editorial changes around
+       -flinker-output.
+
 2019-05-26  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
 
        * doc/invoke.texi (x86 Options, -mvect8-ret-in-mem): Remove
index 9ca90aad30eda497fd4c52c41b8fdcf87e568507..1719037a8e08d157f5f0fb138ca941c4f698f123 100644 (file)
@@ -13141,44 +13141,48 @@ Options}.
 
 @item -flinker-output=@var{type}
 @opindex flinker-output
-This option controls the code generation of the link time optimizer.  By
-default the linker output is determined by the linker plugin automatically. For
-debugging the compiler and in the case of incremental linking to non-lto object
-file is desired, it may be useful to control the type manually.
-
-If @var{type} is @samp{exec} the code generation is configured to produce static
-binary. In this case @option{-fpic} and @option{-fpie} are both disabled.
-
-If @var{type} is @samp{dyn} the code generation is configured to produce shared
-library. In this case @option{-fpic} or @option{-fPIC} is preserved, but not
-enabled automatically.  This makes it possible to build shared libraries without
-position independent code on architectures this is possible, i.e.@: on x86.
-
-If @var{type} is @samp{pie} the code generation is configured to produce
-@option{-fpie} executable. This result in similar optimizations as @samp{exec}
-except that @option{-fpie} is not disabled if specified at compilation time.
+This option controls code generation of the link time optimizer.  By
+default the linker output is automatically determined by the linker
+plugin.  For debugging the compiler and if incremental linking with a 
+non-LTO object file is desired, it may be useful to control the type
+manually.
+
+If @var{type} is @samp{exec} code generation produces a static
+binary. In this case @option{-fpic} and @option{-fpie} are both
+disabled.
+
+If @var{type} is @samp{dyn} code generation produces a shared
+library.  In this case @option{-fpic} or @option{-fPIC} is preserved,
+but not enabled automatically.  This allows to build shared libraries
+without position independent code on architectures where this is
+possible, i.e.@: on x86.
+
+If @var{type} is @samp{pie} code generation produces an @option{-fpie}
+executable. This results in similar optimizations as @samp{exec}
+except that @option{-fpie} is not disabled if specified at compilation
+time.
 
 If @var{type} is @samp{rel} the compiler assumes that incremental linking is
 done.  The sections containing intermediate code for link-time optimization are
 merged, pre-optimized, and output to the resulting object file. In addition, if
 @option{-ffat-lto-objects} is specified the binary code is produced for future
-non-lto linking. The object file produced by incremental linking will be smaller
-than a static library produced from the same object files.  At link-time the
+non-LTO linking. The object file produced by incremental linking will be smaller
+than a static library produced from the same object files.  At link time the
 result of incremental linking will also load faster to compiler than a static
-library assuming that majority of objects in the library are used.
+library assuming that the majority of objects in the library are used.
 
-Finally @samp{nolto-rel} configure compiler to for incremental linking where
-code generation is forced, final binary is produced and the intermediate code
-for later link-time optimization is stripped. When multiple object files are
-linked together the resulting code will be optimized better than with link time
-optimizations disabled (for example, the cross-module inlining will happen),
-most of benefits of whole program optimizations are however lost. 
+Finally @samp{nolto-rel} configures the compiler for incremental linking where
+code generation is forced, a final binary is produced and the intermediate
+code for later link-time optimization is stripped. When multiple object files
+are linked together the resulting code will be optimized better than with
+link-time optimizations disabled (for example, cross-module inlining will
+happen), most of benefits of whole program optimizations are however lost. 
 
 During the incremental link (by @option{-r}) the linker plugin will default to
 @option{rel}. With current interfaces to GNU Binutils it is however not
-possible to link incrementally LTO objects and non-LTO objects into a single
+possible to incrementally link LTO objects and non-LTO objects into a single
 mixed object file.  In the case any of object files in incremental link cannot
-be used for link-time optimization the linker plugin will output warning and
+be used for link-time optimization the linker plugin will issue a warning and
 use @samp{nolto-rel}. To maintain the whole program optimization it is
 recommended to link such objects into static library instead. Alternatively it
 is possible to use H.J. Lu's binutils with support for mixed objects.