procyberian/gcc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

invoke.texi (Link Options): Many editorial changes around -flinker-output.

Browse source 
* doc/invoke.texi (Link Options): Many editorial changes around
	-flinker-output.

From-SVN: r271633
This commit is contained in:
Gerald Pfeifer 2019-05-26 17:33:52 +00:00 • committed by Gerald Pfeifer
parent abbb83070a
commit e1fb36b8e4
2 changed files with 33 additions and 24 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
gcc/ChangeLog
View 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

52
gcc/doc/invoke.texi
View 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.
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} 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{exec} code generation produces a 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{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} 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.
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.