c-tree.texi, [...]: Correct end-of-sentence markup and markup of "etc.", "e.g." and "i.e.".
* doc/c-tree.texi, doc/cfg.texi, doc/contrib.texi, doc/cpp.texi, doc/cppopts.texi, doc/extend.texi, doc/fragments.texi, doc/frontends.texi, doc/gcov.texi, doc/hostconfig.texi, doc/implement-c.texi, doc/install.texi, doc/invoke.texi, doc/libgcc.texi, doc/md.texi, doc/passes.texi, doc/portability.texi, doc/rtl.texi, doc/sourcebuild.texi, doc/standards.texi, doc/tm.texi, doc/tree-ssa.texi, doc/trouble.texi: Correct end-of-sentence markup and markup of "etc.", "e.g." and "i.e.". Use @code in various places where appropriate. From-SVN: r90101
This commit is contained in:
parent
f0eb93a806
commit
8a36672b01
|
@ -1,3 +1,16 @@
|
|||
2004-11-05 Joseph S. Myers <joseph@codesourcery.com>
|
||||
|
||||
* doc/c-tree.texi, doc/cfg.texi, doc/contrib.texi, doc/cpp.texi,
|
||||
doc/cppopts.texi, doc/extend.texi, doc/fragments.texi,
|
||||
doc/frontends.texi, doc/gcov.texi, doc/hostconfig.texi,
|
||||
doc/implement-c.texi, doc/install.texi, doc/invoke.texi,
|
||||
doc/libgcc.texi, doc/md.texi, doc/passes.texi,
|
||||
doc/portability.texi, doc/rtl.texi, doc/sourcebuild.texi,
|
||||
doc/standards.texi, doc/tm.texi, doc/tree-ssa.texi,
|
||||
doc/trouble.texi: Correct end-of-sentence markup and markup of
|
||||
"etc.", "e.g." and "i.e.". Use @code in various places where
|
||||
appropriate.
|
||||
|
||||
2004-11-05 Joseph S. Myers <joseph@codesourcery.com>
|
||||
|
||||
* doc/c-tree.texi, doc/cfg.texi, doc/extend.texi, doc/gty.texi,
|
||||
|
|
|
@ -776,7 +776,7 @@ The following macros can be used on a tree node representing a class-type.
|
|||
|
||||
@ftable @code
|
||||
@item LOCAL_CLASS_P
|
||||
This predicate holds if the class is local class @emph{i.e.} declared
|
||||
This predicate holds if the class is local class @emph{i.e.}@: declared
|
||||
inside a function body.
|
||||
|
||||
@item TYPE_POLYMORPHIC_P
|
||||
|
@ -2062,7 +2062,7 @@ These nodes represent integer division operations that return an integer
|
|||
result. @code{TRUNC_DIV_EXPR} rounds towards zero, @code{FLOOR_DIV_EXPR}
|
||||
rounds towards negative infinity, @code{CEIL_DIV_EXPR} rounds towards
|
||||
positive infinity and @code{ROUND_DIV_EXPR} rounds to the closest integer.
|
||||
Integer division in C and C++ is truncating, i.e@. @code{TRUNC_DIV_EXPR}.
|
||||
Integer division in C and C++ is truncating, i.e.@: @code{TRUNC_DIV_EXPR}.
|
||||
|
||||
The behavior of these operations on signed arithmetic overflow, when
|
||||
dividing the minimum signed integer by minus one, is controlled by the
|
||||
|
@ -2076,9 +2076,9 @@ These nodes represent the integer remainder or modulus operation.
|
|||
The integer modulus of two operands @code{a} and @code{b} is
|
||||
defined as @code{a - (a/b)*b} where the division calculated using
|
||||
the corresponding division operator. Hence for @code{TRUNC_MOD_EXPR}
|
||||
this definition assumes division using truncation towards zero, i.e@.
|
||||
this definition assumes division using truncation towards zero, i.e.@:
|
||||
@code{TRUNC_DIV_EXPR}. Integer remainder in C and C++ uses truncating
|
||||
division, i.e@. @code{TRUNC_MOD_EXPR}.
|
||||
division, i.e.@: @code{TRUNC_MOD_EXPR}.
|
||||
|
||||
@item EXACT_DIV_EXPR
|
||||
The @code{EXACT_DIV_EXPR} code is used to represent integer divisions where
|
||||
|
|
|
@ -44,11 +44,11 @@ Two pointer members of the @code{basic_block} structure are the
|
|||
pointers @code{next_bb} and @code{prev_bb}. These are used to keep
|
||||
doubly linked chain of basic blocks in the same order as the
|
||||
underlying instruction stream. The chain of basic blocks is updated
|
||||
transparently by the provided API for manipulating the CFG. The macro
|
||||
transparently by the provided API for manipulating the CFG@. The macro
|
||||
@code{FOR_EACH_BB} can be used to visit all the basic blocks in
|
||||
lexicographical order. Dominator traversals are also possible using
|
||||
@code{walk_dominator_tree}. Given two basic blocks A and B, block A
|
||||
dominates block B if A is @emph{always} executed before B.
|
||||
dominates block B if A is @emph{always} executed before B@.
|
||||
|
||||
@findex BASIC_BLOCK
|
||||
The @code{BASIC_BLOCK} array contains all basic blocks in an
|
||||
|
@ -140,8 +140,8 @@ FOR_EACH_BB (bb)
|
|||
@cindex edge in the flow graph
|
||||
@findex edge
|
||||
Edges represent possible control flow transfers from the end of some
|
||||
basic block A to the head of another basic block B. We say that A is
|
||||
a predecessor of B, and B is a successor of A. Edges are represented
|
||||
basic block A to the head of another basic block B@. We say that A is
|
||||
a predecessor of B, and B is a successor of A@. Edges are represented
|
||||
in GCC with the @code{edge} data type. Each @code{edge} acts as a
|
||||
link between two basic blocks: the @code{src} member of an edge
|
||||
points to the predecessor basic block of the @code{dest} basic block.
|
||||
|
@ -173,7 +173,7 @@ may be freely redirected when the flow graph is not in SSA form.
|
|||
@findex EDGE_FALLTHRU, force_nonfallthru
|
||||
Fall-thru edges are present in case where the basic block may continue
|
||||
execution to the following one without branching. These edges have
|
||||
the @code{EDGE_FALLTHRU} flag set. Unlike other types of edges, these
|
||||
the @code{EDGE_FALLTHRU} flag set. Unlike other types of edges, these
|
||||
edges must come into the basic block immediately following in the
|
||||
instruction stream. The function @code{force_nonfallthru} is
|
||||
available to insert an unconditional jump in the case that redirection
|
||||
|
@ -193,7 +193,7 @@ edges have the @code{EDGE_ABNORMAL} and @code{EDGE_EH} flags set.
|
|||
@findex purge_dead_edges
|
||||
When updating the instruction stream it is easy to change possibly
|
||||
trapping instruction to non-trapping, by simply removing the exception
|
||||
edge. The opposite conversion is difficult, but should not happen
|
||||
edge. The opposite conversion is difficult, but should not happen
|
||||
anyway. The edges can be eliminated via @code{purge_dead_edges} call.
|
||||
|
||||
@findex REG_EH_REGION, EDGE_ABNORMAL_CALL
|
||||
|
@ -366,7 +366,7 @@ range from 0 to @code{REG_BR_PROB_BASE}. It represents probability of
|
|||
passing control from the end of the @code{src} basic block to the
|
||||
@code{dest} basic block, i.e.@: the probability that control will flow
|
||||
along this edge. The @code{EDGE_FREQUENCY} macro is available to
|
||||
compute how frequently a given edge is taken. There is a @code{count}
|
||||
compute how frequently a given edge is taken. There is a @code{count}
|
||||
field for each edge as well, representing same information as for a
|
||||
basic block.
|
||||
|
||||
|
@ -384,7 +384,7 @@ of basic blocks.
|
|||
|
||||
@findex redirect_edge_and_branch
|
||||
Updating profile information is a delicate task that can unfortunately
|
||||
not be easily integrated with the CFG manipulation API. Many of the
|
||||
not be easily integrated with the CFG manipulation API@. Many of the
|
||||
functions and hooks to modify the CFG, such as
|
||||
@code{redirect_edge_and_branch}, do not have enough information to
|
||||
easily update the profile, so updating it is in the majority of cases
|
||||
|
@ -392,7 +392,7 @@ left up to the caller. It is difficult to uncover bugs in the profile
|
|||
updating code, because they manifest themselves only by producing
|
||||
worse code, and checking profile consistency is not possible because
|
||||
of numeric error accumulation. Hence special attention needs to be
|
||||
given to this issue in each pass that modifies the CFG.
|
||||
given to this issue in each pass that modifies the CFG@.
|
||||
|
||||
@findex REG_BR_PROB_BASE, BB_FREQ_BASE, count
|
||||
It is important to point out that @code{REG_BR_PROB_BASE} and
|
||||
|
@ -527,7 +527,7 @@ this is best modeled as redirection of edges in the control flow graph
|
|||
and thus use of @code{redirect_edge_and_branch} is preferred over more
|
||||
low level functions, such as @code{redirect_jump} that operate on RTL
|
||||
chain only. The CFG hooks defined in @file{cfghooks.h} should provide
|
||||
the complete API required for manipulating and maintaining the CFG.
|
||||
the complete API required for manipulating and maintaining the CFG@.
|
||||
|
||||
@findex find_sub_basic_blocks, split_block
|
||||
It is also possible that a pass has to insert control flow instruction
|
||||
|
@ -561,7 +561,7 @@ function may be useful to find bugs in the control flow graph updating
|
|||
code.
|
||||
|
||||
Note that at present, the representation of control flow in the
|
||||
@code{tree} representation is discarded before expanding to RTL.
|
||||
@code{tree} representation is discarded before expanding to RTL@.
|
||||
Long term the CFG should be maintained and ``expanded'' to the
|
||||
RTL representation along with the function @code{tree} itself.
|
||||
|
||||
|
|
|
@ -94,7 +94,7 @@ Per Bothner for his direction via the steering committee and various
|
|||
improvements to the infrastructure for supporting new languages. Chill
|
||||
front end implementation. Initial implementations of
|
||||
cpplib, fix-header, config.guess, libio, and past C++ library (libg++)
|
||||
maintainer. Dreaming up, designing and implementing much of GCJ.
|
||||
maintainer. Dreaming up, designing and implementing much of GCJ@.
|
||||
|
||||
@item
|
||||
Devon Bowen helped port GCC to the Tahoe.
|
||||
|
@ -118,7 +118,7 @@ Christian Bruel for improvements to local store elimination.
|
|||
Herman A.J. ten Brugge for various fixes.
|
||||
|
||||
@item
|
||||
Joerg Brunsmann for Java compiler hacking and help with the GCJ FAQ.
|
||||
Joerg Brunsmann for Java compiler hacking and help with the GCJ FAQ@.
|
||||
|
||||
@item
|
||||
Joe Buck for his direction via the steering committee.
|
||||
|
@ -146,7 +146,7 @@ Steve Chamberlain for support for the Renesas SH and H8 processors
|
|||
and the PicoJava processor, and for GCJ config fixes.
|
||||
|
||||
@item
|
||||
Glenn Chambers for help with the GCJ FAQ.
|
||||
Glenn Chambers for help with the GCJ FAQ@.
|
||||
|
||||
@item
|
||||
John-Marc Chandonia for various libgcj patches.
|
||||
|
@ -236,7 +236,7 @@ Richard Earnshaw for his ongoing work with the ARM@.
|
|||
David Edelsohn for his direction via the steering committee, ongoing work
|
||||
with the RS6000/PowerPC port, help cleaning up Haifa loop changes,
|
||||
doing the entire AIX port of libstdc++ with his bare hands, and for
|
||||
ensuring GCC properly keeps working on AIX.
|
||||
ensuring GCC properly keeps working on AIX@.
|
||||
|
||||
@item
|
||||
Kevin Ediger for the floating point formatting of num_put::do_put in
|
||||
|
@ -279,7 +279,7 @@ feeding the gcc.gnu.org box and saving its users tons of spam.
|
|||
Fred Fish for BeOS support and Ada fixes.
|
||||
|
||||
@item
|
||||
Ivan Fontes Garcia for the Portugese translation of the GCJ FAQ.
|
||||
Ivan Fontes Garcia for the Portugese translation of the GCJ FAQ@.
|
||||
|
||||
@item
|
||||
Peter Gerwinski for various bug fixes and the Pascal front end.
|
||||
|
@ -490,7 +490,7 @@ Warren Levy for tremendous work on libgcj (Java Runtime Library) and
|
|||
random work on the Java front end.
|
||||
|
||||
@item
|
||||
Alain Lichnewsky ported GCC to the MIPS CPU.
|
||||
Alain Lichnewsky ported GCC to the MIPS CPU@.
|
||||
|
||||
@item
|
||||
Oskar Liljeblad for hacking on AWT and his many Java bug reports and
|
||||
|
@ -544,7 +544,7 @@ for Java test code.
|
|||
Bryce McKinlay for numerous GCJ and libgcj fixes and improvements.
|
||||
|
||||
@item
|
||||
Adam Megacz for his work on the Microsoft Windows port of GCJ.
|
||||
Adam Megacz for his work on the Microsoft Windows port of GCJ@.
|
||||
|
||||
@item
|
||||
Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS,
|
||||
|
@ -685,14 +685,14 @@ Ovidiu Predescu for his work on the Objective-C front end and runtime
|
|||
libraries.
|
||||
|
||||
@item
|
||||
Jerry Quinn for major performance improvements in C++ formatted I/O.
|
||||
Jerry Quinn for major performance improvements in C++ formatted I/O@.
|
||||
|
||||
@item
|
||||
Ken Raeburn for various improvements to checker, MIPS ports and various
|
||||
cleanups in the compiler.
|
||||
|
||||
@item
|
||||
Rolf W. Rasmussen for hacking on AWT.
|
||||
Rolf W. Rasmussen for hacking on AWT@.
|
||||
|
||||
@item
|
||||
David Reese of Sun Microsystems contributed to the Solaris on PowerPC
|
||||
|
@ -750,7 +750,7 @@ Roger Sayle for improvements to constant folding and GCC's RTL optimizers
|
|||
as well as for fixing numerous bugs.
|
||||
|
||||
@item
|
||||
Bradley Schatz for his work on the GCJ FAQ.
|
||||
Bradley Schatz for his work on the GCJ FAQ@.
|
||||
|
||||
@item
|
||||
Peter Schauer wrote the code to allow debugging to work on the Alpha.
|
||||
|
@ -794,7 +794,7 @@ folding and help with the original VAX & m68k ports.
|
|||
|
||||
@item
|
||||
Kenny Simpson for prompting libstdc++ fixes due to defect reports from
|
||||
the LWG (thereby keeping GCC in line with updates from the ISO).
|
||||
the LWG (thereby keeping GCC in line with updates from the ISO)@.
|
||||
|
||||
@item
|
||||
Franz Sirl for his ongoing work with making the PPC port stable
|
||||
|
@ -855,7 +855,7 @@ Ian Lance Taylor for his mips16 work, general configury hacking,
|
|||
fixincludes, etc.
|
||||
|
||||
@item
|
||||
Holger Teutsch provided the support for the Clipper CPU.
|
||||
Holger Teutsch provided the support for the Clipper CPU@.
|
||||
|
||||
@item
|
||||
Gary Thomas for his ongoing work to make the PPC work for GNU/Linux.
|
||||
|
@ -864,7 +864,7 @@ Gary Thomas for his ongoing work to make the PPC work for GNU/Linux.
|
|||
Philipp Thomas for random bug fixes throughout the compiler
|
||||
|
||||
@item
|
||||
Jason Thorpe for thread support in libstdc++ on NetBSD.
|
||||
Jason Thorpe for thread support in libstdc++ on NetBSD@.
|
||||
|
||||
@item
|
||||
Kresten Krab Thorup wrote the run time support for the Objective-C
|
||||
|
@ -938,7 +938,7 @@ Ulrich Weigand for work on the s390 port.
|
|||
Zack Weinberg for major work on cpplib and various other bug fixes.
|
||||
|
||||
@item
|
||||
Matt Welsh for help with Linux Threads support in GCJ.
|
||||
Matt Welsh for help with Linux Threads support in GCJ@.
|
||||
|
||||
@item
|
||||
Urban Widmark for help fixing java.io.
|
||||
|
|
|
@ -230,7 +230,7 @@ differences that do exist are detailed in the section @ref{Traditional
|
|||
Mode}.
|
||||
|
||||
For clarity, unless noted otherwise, references to @samp{CPP} in this
|
||||
manual refer to GNU CPP.
|
||||
manual refer to GNU CPP@.
|
||||
@c man end
|
||||
|
||||
@menu
|
||||
|
@ -596,7 +596,7 @@ Punctuator: @{ @} [ ] # ##
|
|||
@end smallexample
|
||||
|
||||
@cindex other tokens
|
||||
Any other single character is considered ``other''. It is passed on to
|
||||
Any other single character is considered ``other''. It is passed on to
|
||||
the preprocessor's output unmolested. The C compiler will almost
|
||||
certainly reject source code containing ``other'' tokens. In ASCII, the
|
||||
only other characters are @samp{@@}, @samp{$}, @samp{`}, and control
|
||||
|
@ -2091,7 +2091,7 @@ handling.
|
|||
|
||||
@item __NEXT_RUNTIME__
|
||||
This macro is defined, with value 1, if (and only if) the NeXT runtime
|
||||
(as in @option{-fnext-runtime}) is in use for Objective-C. If the GNU
|
||||
(as in @option{-fnext-runtime}) is in use for Objective-C@. If the GNU
|
||||
runtime is used, this macro is not defined, so that you can use this
|
||||
macro to determine which runtime (NeXT or GNU) is being used.
|
||||
|
||||
|
@ -3559,7 +3559,7 @@ replacement text before storing it, but preserves the form of internal
|
|||
whitespace.
|
||||
|
||||
One consequence is that it is legitimate for the replacement text to
|
||||
contain an unmatched quote (@pxref{Traditional lexical analysis}). An
|
||||
contain an unmatched quote (@pxref{Traditional lexical analysis}). An
|
||||
unclosed string or character constant continues into the text
|
||||
following the macro call. Similarly, the text at the end of a macro's
|
||||
expansion can run together with the text after the macro invocation to
|
||||
|
@ -3802,7 +3802,7 @@ target character, and then or-ing in the bit-pattern of the new
|
|||
character truncated to the width of a target character. The final
|
||||
bit-pattern is given type @code{int}, and is therefore signed,
|
||||
regardless of whether single characters are signed or not (a slight
|
||||
change from versions 3.1 and earlier of GCC). If there are more
|
||||
change from versions 3.1 and earlier of GCC)@. If there are more
|
||||
characters in the constant than would fit in the target @code{int} the
|
||||
compiler issues a warning, and the excess leading characters are
|
||||
ignored.
|
||||
|
|
|
@ -333,10 +333,10 @@ Headers}) together with @option{-E}. It inserts a special @code{#pragma},
|
|||
@code{#pragma GCC pch_preprocess "<filename>"} in the output to mark
|
||||
the place where the precompiled header was found, and its filename. When
|
||||
@option{-fpreprocessed} is in use, GCC recognizes this @code{#pragma} and
|
||||
loads the PCH.
|
||||
loads the PCH@.
|
||||
|
||||
This option is off by default, because the resulting preprocessed output
|
||||
is only really suitable as input to GCC. It is switched on by
|
||||
is only really suitable as input to GCC@. It is switched on by
|
||||
@option{-save-temps}.
|
||||
|
||||
You should not write this @code{#pragma} in your own code, but it is
|
||||
|
@ -546,11 +546,11 @@ problems with encodings that do not fit exactly in @code{wchar_t}.
|
|||
@item -finput-charset=@var{charset}
|
||||
@opindex finput-charset
|
||||
Set the input character set, used for translation from the character
|
||||
set of the input file to the source character set used by GCC. If the
|
||||
set of the input file to the source character set used by GCC@. If the
|
||||
locale does not specify, or GCC cannot get this information from the
|
||||
locale, the default is UTF-8. This can be overridden by either the locale
|
||||
or this command line option. Currently the command line option takes
|
||||
precedence if there's a conflict. @var{charset} can be any encoding
|
||||
locale, the default is UTF-8. This can be overridden by either the locale
|
||||
or this command line option. Currently the command line option takes
|
||||
precedence if there's a conflict. @var{charset} can be any encoding
|
||||
supported by the system's @code{iconv} library routine.
|
||||
|
||||
@item -fworking-directory
|
||||
|
|
|
@ -142,7 +142,7 @@ must use @code{typeof} (@pxref{Typeof}).
|
|||
|
||||
In G++, the result value of a statement expression undergoes array and
|
||||
function pointer decay, and is returned by value to the enclosing
|
||||
expression. For instance, if @code{A} is a class, then
|
||||
expression. For instance, if @code{A} is a class, then
|
||||
|
||||
@smallexample
|
||||
A a;
|
||||
|
@ -193,7 +193,7 @@ bug.)
|
|||
@cindex macros, local labels
|
||||
|
||||
GCC allows you to declare @dfn{local labels} in any nested block
|
||||
scope. A local label is just like an ordinary label, but you can
|
||||
scope. A local label is just like an ordinary label, but you can
|
||||
only reference it (with a @code{goto} statement, or by taking its
|
||||
address) within the block in which it was declared.
|
||||
|
||||
|
@ -1514,7 +1514,7 @@ you may use @code{__noreturn__} instead of @code{noreturn}.
|
|||
attributes.
|
||||
|
||||
@table @code
|
||||
@c Keep this table alphabetized by attribute name. Treat _ as space.
|
||||
@c Keep this table alphabetized by attribute name. Treat _ as space.
|
||||
|
||||
@item alias ("@var{target}")
|
||||
@cindex @code{alias} attribute
|
||||
|
@ -1631,8 +1631,8 @@ Currently, the @code{dllexport} attribute is ignored for inlined
|
|||
functions, unless the @option{-fkeep-inline-functions} flag has been
|
||||
used. The attribute is also ignored for undefined symbols.
|
||||
|
||||
When applied to C++ classes. the attribute marks defined non-inlined
|
||||
member functions and static data members as exports. Static consts
|
||||
When applied to C++ classes, the attribute marks defined non-inlined
|
||||
member functions and static data members as exports. Static consts
|
||||
initialized in-class are not marked unless they are also defined
|
||||
out-of-class.
|
||||
|
||||
|
@ -1646,7 +1646,7 @@ the @option{--export-all} linker flag.
|
|||
On Microsoft Windows and Symbian OS targets, the @code{dllimport}
|
||||
attribute causes the compiler to reference a function or variable via
|
||||
a global pointer to a pointer that is set up by the DLL exporting the
|
||||
symbol. The attribute implies @code{extern} storage. On Microsoft
|
||||
symbol. The attribute implies @code{extern} storage. On Microsoft
|
||||
Windows targets, the pointer name is formed by combining @code{_imp__}
|
||||
and the function or variable name.
|
||||
|
||||
|
@ -1654,7 +1654,7 @@ You can use @code{__declspec(dllimport)} as a synonym for
|
|||
@code{__attribute__ ((dllimport))} for compatibility with other
|
||||
compilers.
|
||||
|
||||
Currently, the attribute is ignored for inlined functions. If the
|
||||
Currently, the attribute is ignored for inlined functions. If the
|
||||
attribute is applied to a symbol @emph{definition}, an error is reported.
|
||||
If a symbol previously declared @code{dllimport} is later defined, the
|
||||
attribute is ignored in subsequent references, and a warning is emitted.
|
||||
|
@ -1676,12 +1676,12 @@ the current translation unit.
|
|||
|
||||
For Microsoft Windows based targets the use of the @code{dllimport}
|
||||
attribute on functions is not necessary, but provides a small
|
||||
performance benefit by eliminating a thunk in the DLL. The use of the
|
||||
performance benefit by eliminating a thunk in the DLL@. The use of the
|
||||
@code{dllimport} attribute on imported variables was required on older
|
||||
versions of the GNU linker, but can now be avoided by passing the
|
||||
@option{--enable-auto-import} switch to the GNU linker. As with
|
||||
@option{--enable-auto-import} switch to the GNU linker. As with
|
||||
functions, using the attribute for a variable eliminates a thunk in
|
||||
the DLL.
|
||||
the DLL@.
|
||||
|
||||
One drawback to using this attribute is that a pointer to a function
|
||||
or variable marked as @code{dllimport} cannot be used as a constant
|
||||
|
@ -1711,17 +1711,17 @@ to call and return from a function.
|
|||
|
||||
On 68HC11 the compiler will generate a sequence of instructions
|
||||
to invoke a board-specific routine to switch the memory bank and call the
|
||||
real function. The board-specific routine simulates a @code{call}.
|
||||
real function. The board-specific routine simulates a @code{call}.
|
||||
At the end of a function, it will jump to a board-specific routine
|
||||
instead of using @code{rts}. The board-specific return routine simulates
|
||||
instead of using @code{rts}. The board-specific return routine simulates
|
||||
the @code{rtc}.
|
||||
|
||||
@item fastcall
|
||||
@cindex functions that pop the argument stack on the 386
|
||||
On the Intel 386, the @code{fastcall} attribute causes the compiler to
|
||||
pass the first two arguments in the registers ECX and EDX. Subsequent
|
||||
arguments are passed on the stack. The called function will pop the
|
||||
arguments off the stack. If the number of arguments is variable all
|
||||
pass the first two arguments in the registers ECX and EDX@. Subsequent
|
||||
arguments are passed on the stack. The called function will pop the
|
||||
arguments off the stack. If the number of arguments is variable all
|
||||
arguments are pushed on the stack.
|
||||
|
||||
@item format (@var{archetype}, @var{string-index}, @var{first-to-check})
|
||||
|
@ -2214,7 +2214,7 @@ See the ELF gABI for complete details, but the short story is:
|
|||
@c keep this list of visibilities in alphabetical order.
|
||||
|
||||
@item default
|
||||
Default visibility is the normal case for ELF. This value is
|
||||
Default visibility is the normal case for ELF@. This value is
|
||||
available for the visibility attribute to override other options
|
||||
that may change the assumed visibility of symbols.
|
||||
|
||||
|
@ -2374,10 +2374,10 @@ feature is intended for code generated by programs which contains labels
|
|||
that may be unused but which is compiled with @option{-Wall}. It would
|
||||
not normally be appropriate to use in it human-written code, though it
|
||||
could be useful in cases where the code that jumps to the label is
|
||||
contained within an @code{#ifdef} conditional. GNU C++ does not permit
|
||||
contained within an @code{#ifdef} conditional. GNU C++ does not permit
|
||||
such placement of attribute lists, as it is permissible for a
|
||||
declaration, which could begin with an attribute list, to be labelled in
|
||||
C++. Declarations cannot be labelled in C90 or C99, so the ambiguity
|
||||
C++. Declarations cannot be labelled in C90 or C99, so the ambiguity
|
||||
does not arise there.
|
||||
|
||||
An attribute specifier list may appear as part of a @code{struct},
|
||||
|
@ -2976,7 +2976,7 @@ The @code{dllexport} attribute is described in @xref{Function Attributes}.
|
|||
|
||||
@subsection M32R/D Variable Attributes
|
||||
|
||||
One attribute is currently defined for the M32R/D.
|
||||
One attribute is currently defined for the M32R/D@.
|
||||
|
||||
@table @code
|
||||
@item model (@var{model-name})
|
||||
|
@ -3147,7 +3147,7 @@ alignment. See your linker documentation for further information.
|
|||
@item packed
|
||||
This attribute, attached to @code{struct} or @code{union} type
|
||||
definition, specifies that each member of the structure or union is
|
||||
placed to minimize the memory required. When attached to an @code{enum}
|
||||
placed to minimize the memory required. When attached to an @code{enum}
|
||||
definition, it indicates that the smallest integral type should be used.
|
||||
|
||||
@opindex fshort-enums
|
||||
|
@ -3312,7 +3312,7 @@ above in recent GCC versions.
|
|||
On those ARM targets that support @code{dllimport} (such as Symbian
|
||||
OS), you can use the @code{notshared} attribute to indicate that the
|
||||
virtual table and other similar data for a class should not be
|
||||
exported from a DLL. For example:
|
||||
exported from a DLL@. For example:
|
||||
|
||||
@smallexample
|
||||
class __declspec(notshared) C @{
|
||||
|
@ -3502,7 +3502,7 @@ template from the first output operand and another separates the last
|
|||
output operand from the first input, if any. Commas separate the
|
||||
operands within each group. The total number of operands is currently
|
||||
limited to 30; this limitation may be lifted in some future version of
|
||||
GCC.
|
||||
GCC@.
|
||||
|
||||
If there are no output operands but there are input operands, you must
|
||||
place two consecutive colons surrounding the place where the output
|
||||
|
@ -4344,7 +4344,7 @@ This function returns the return address of the current function, or of
|
|||
one of its callers. The @var{level} argument is number of frames to
|
||||
scan up the call stack. A value of @code{0} yields the return address
|
||||
of the current function, a value of @code{1} yields the return address
|
||||
of the caller of the current function, and so forth. When inlining
|
||||
of the caller of the current function, and so forth. When inlining
|
||||
the expected behavior is that the function will return the address of
|
||||
the function that will be returned to. To work around this behavior use
|
||||
the @code{noinline} function attribute.
|
||||
|
@ -4354,7 +4354,7 @@ The @var{level} argument must be a constant integer.
|
|||
On some machines it may be impossible to determine the return address of
|
||||
any function other than the current one; in such cases, or when the top
|
||||
of the stack has been reached, this function will return @code{0} or a
|
||||
random value. In addition, @code{__builtin_frame_address} may be used
|
||||
random value. In addition, @code{__builtin_frame_address} may be used
|
||||
to determine if the top of the stack has been reached.
|
||||
|
||||
This function should only be used with a nonzero argument for debugging
|
||||
|
@ -4882,7 +4882,7 @@ The remaining functions are provided for optimization purposes.
|
|||
GCC includes built-in versions of many of the functions in the standard
|
||||
C library. The versions prefixed with @code{__builtin_} will always be
|
||||
treated as having the same meaning as the C library function even if you
|
||||
specify the @option{-fno-builtin} option. (@pxref{C Dialect Options})
|
||||
specify the @option{-fno-builtin} option. (@pxref{C Dialect Options})
|
||||
Many of these functions are only optimized in certain cases; if they are
|
||||
not optimized in a particular case, a call to the library function will
|
||||
be emitted.
|
||||
|
@ -5053,7 +5053,7 @@ depending on the arguments' types. For example:
|
|||
@})
|
||||
@end smallexample
|
||||
|
||||
@emph{Note:} This construct is only available for C.
|
||||
@emph{Note:} This construct is only available for C@.
|
||||
|
||||
@end deftypefn
|
||||
|
||||
|
@ -5093,7 +5093,7 @@ Example:
|
|||
(void)0))
|
||||
@end smallexample
|
||||
|
||||
@emph{Note:} This construct is only available for C. Furthermore, the
|
||||
@emph{Note:} This construct is only available for C@. Furthermore, the
|
||||
unused expression (@var{exp1} or @var{exp2} depending on the value of
|
||||
@var{const_exp}) may still generate syntax errors. This may change in
|
||||
future revisions.
|
||||
|
@ -5266,7 +5266,7 @@ leading @samp{0} or @samp{0x} prefixes. The number parsed is placed
|
|||
in the significand such that the least significant bit of the number
|
||||
is at the least significant bit of the significand. The number is
|
||||
truncated to fit the significand field provided. The significand is
|
||||
forced to be a quiet NaN.
|
||||
forced to be a quiet NaN@.
|
||||
|
||||
This function, if given a string literal, is evaluated early enough
|
||||
that it is considered a compile-time constant.
|
||||
|
@ -5282,7 +5282,7 @@ Similar to @code{__builtin_nan}, except the return type is @code{long double}.
|
|||
|
||||
@deftypefn {Built-in Function} double __builtin_nans (const char *str)
|
||||
Similar to @code{__builtin_nan}, except the significand is forced
|
||||
to be a signaling NaN. The @code{nans} function is proposed by
|
||||
to be a signaling NaN@. The @code{nans} function is proposed by
|
||||
@uref{http://www.open-std.org/jtc1/sc22/wg14/www/docs/n965.htm,,WG14 N965}.
|
||||
@end deftypefn
|
||||
|
||||
|
@ -5314,7 +5314,7 @@ Returns the number of 1-bits in @var{x}.
|
|||
@end deftypefn
|
||||
|
||||
@deftypefn {Built-in Function} int __builtin_parity (unsigned int x)
|
||||
Returns the parity of @var{x}, i.@:e. the number of 1-bits in @var{x}
|
||||
Returns the parity of @var{x}, i.e.@: the number of 1-bits in @var{x}
|
||||
modulo 2.
|
||||
@end deftypefn
|
||||
|
||||
|
@ -8648,7 +8648,7 @@ declarations to have @var{string} prepended to their assembly symbols.
|
|||
This effect may be terminated with another @code{extern_prefix} pragma
|
||||
whose argument is an empty string. The preprocessor macro
|
||||
@code{__PRAGMA_EXTERN_PREFIX} will be defined if this pragma is
|
||||
available (currently only on Tru64 UNIX).
|
||||
available (currently only on Tru64 UNIX)@.
|
||||
@end table
|
||||
|
||||
These pragmas and the asm labels extension interact in a complicated
|
||||
|
|
|
@ -186,7 +186,7 @@ Variables provided for host fragments to set include:
|
|||
@itemx X_CPPFLAGS
|
||||
These are extra flags to pass to the C compiler and preprocessor,
|
||||
respectively. They are used both when building GCC, and when compiling
|
||||
things with the just-built GCC.
|
||||
things with the just-built GCC@.
|
||||
|
||||
@item XCFLAGS
|
||||
These are extra flags to use when building the compiler. They are not
|
||||
|
|
|
@ -39,7 +39,7 @@ The part of a compiler that is specific to a particular language is
|
|||
called the ``front end''. In addition to the front ends that are
|
||||
integrated components of GCC, there are several other front ends that
|
||||
are maintained separately. These support languages such as Pascal,
|
||||
Mercury, and COBOL. To use these, they must be built together with
|
||||
Mercury, and COBOL@. To use these, they must be built together with
|
||||
GCC proper.
|
||||
|
||||
@cindex C++
|
||||
|
|
|
@ -149,8 +149,8 @@ and exit without doing any further processing.
|
|||
|
||||
@item -a
|
||||
@itemx --all-blocks
|
||||
Write individual execution counts for every basic block. Normally gcov
|
||||
outputs execution counts only for the main blocks of a line. With this
|
||||
Write individual execution counts for every basic block. Normally gcov
|
||||
outputs execution counts only for the main blocks of a line. With this
|
||||
option you can determine if blocks within a single line are not being
|
||||
executed.
|
||||
|
||||
|
@ -158,7 +158,7 @@ executed.
|
|||
@itemx --branch-probabilities
|
||||
Write branch frequencies to the output file, and write branch summary
|
||||
info to the standard output. This option allows you to see how often
|
||||
each branch in your program was taken. Unconditional branches will not
|
||||
each branch in your program was taken. Unconditional branches will not
|
||||
be shown, unless the @option{-u} option is given.
|
||||
|
||||
@item -c
|
||||
|
@ -177,18 +177,18 @@ header file @file{x.h} contains code, and was included in the file
|
|||
@file{a.c}, then running @command{gcov} on the file @file{a.c} will produce
|
||||
an output file called @file{a.c##x.h.gcov} instead of @file{x.h.gcov}.
|
||||
This can be useful if @file{x.h} is included in multiple source
|
||||
files. If you uses the @samp{-p} option, both the including and
|
||||
files. If you uses the @samp{-p} option, both the including and
|
||||
included file names will be complete path names.
|
||||
|
||||
@item -p
|
||||
@itemx --preserve-paths
|
||||
Preserve complete path information in the names of generated
|
||||
@file{.gcov} files. Without this option, just the filename component is
|
||||
used. With this option, all directories are used, with @samp{/} characters
|
||||
@file{.gcov} files. Without this option, just the filename component is
|
||||
used. With this option, all directories are used, with @samp{/} characters
|
||||
translated to @samp{#} characters, @file{.} directory components
|
||||
removed and @file{..}
|
||||
components renamed to @samp{^}. This is useful if sourcefiles are in several
|
||||
different directories. It also affects the @samp{-l} option.
|
||||
components renamed to @samp{^}. This is useful if sourcefiles are in several
|
||||
different directories. It also affects the @samp{-l} option.
|
||||
|
||||
@item -f
|
||||
@itemx --function-summaries
|
||||
|
@ -198,11 +198,11 @@ Output summaries for each function in addition to the file level summary.
|
|||
@itemx --object-directory @var{directory}
|
||||
@itemx --object-file @var{file}
|
||||
Specify either the directory containing the gcov data files, or the
|
||||
object path name. The @file{.gcno}, and
|
||||
@file{.gcda} data files are searched for using this option. If a directory
|
||||
object path name. The @file{.gcno}, and
|
||||
@file{.gcda} data files are searched for using this option. If a directory
|
||||
is specified, the data files are in that directory and named after the
|
||||
source file name, without its extension. If a file is specified here,
|
||||
the data files are named after that file, without its extension. If this
|
||||
source file name, without its extension. If a file is specified here,
|
||||
the data files are named after that file, without its extension. If this
|
||||
option is not supplied, it defaults to the current directory.
|
||||
|
||||
@item -u
|
||||
|
@ -213,31 +213,31 @@ Unconditional branches are normally not interesting.
|
|||
@end table
|
||||
|
||||
@command{gcov} should be run with the current directory the same as that
|
||||
when you invoked the compiler. Otherwise it will not be able to locate
|
||||
the source files. @command{gcov} produces files called
|
||||
@file{@var{mangledname}.gcov} in the current directory. These contain
|
||||
when you invoked the compiler. Otherwise it will not be able to locate
|
||||
the source files. @command{gcov} produces files called
|
||||
@file{@var{mangledname}.gcov} in the current directory. These contain
|
||||
the coverage information of the source file they correspond to.
|
||||
One @file{.gcov} file is produced for each source file containing code,
|
||||
which was compiled to produce the data files. The @var{mangledname} part
|
||||
which was compiled to produce the data files. The @var{mangledname} part
|
||||
of the output file name is usually simply the source file name, but can
|
||||
be something more complicated if the @samp{-l} or @samp{-p} options are
|
||||
given. Refer to those options for details.
|
||||
given. Refer to those options for details.
|
||||
|
||||
The @file{.gcov} files contain the @samp{:} separated fields along with
|
||||
program source code. The format is
|
||||
program source code. The format is
|
||||
|
||||
@smallexample
|
||||
@var{execution_count}:@var{line_number}:@var{source line text}
|
||||
@end smallexample
|
||||
|
||||
Additional block information may succeed each line, when requested by
|
||||
command line option. The @var{execution_count} is @samp{-} for lines
|
||||
command line option. The @var{execution_count} is @samp{-} for lines
|
||||
containing no code and @samp{#####} for lines which were never
|
||||
executed. Some lines of information at the start have @var{line_number}
|
||||
executed. Some lines of information at the start have @var{line_number}
|
||||
of zero.
|
||||
|
||||
When printing percentages, 0% and 100% are only printed when the values
|
||||
are @emph{exactly} 0% and 100% respectively. Other values which would
|
||||
are @emph{exactly} 0% and 100% respectively. Other values which would
|
||||
conventionally be rounded to 0% or 100% are instead printed as the
|
||||
nearest non-boundary value.
|
||||
|
||||
|
@ -332,11 +332,11 @@ function main called 1 returned 1 blocks executed 75%
|
|||
@end smallexample
|
||||
|
||||
In this mode, each basic block is only shown on one line -- the last
|
||||
line of the block. A multi-line block will only contribute to the
|
||||
line of the block. A multi-line block will only contribute to the
|
||||
execution count of that last line, and other lines will not be shown
|
||||
to contain code, unless previous blocks end on those lines.
|
||||
The total execution count of a line is shown and subsequent lines show
|
||||
the execution counts for individual blocks that end on that line. After each
|
||||
the execution counts for individual blocks that end on that line. After each
|
||||
block, the branch and call counts of the block will be shown, if the
|
||||
@option{-b} option is given.
|
||||
|
||||
|
@ -505,7 +505,7 @@ blocks.
|
|||
The @file{.gcda} file is generated when a program containing object files
|
||||
built with the GCC @option{-fprofile-arcs} option is executed. A
|
||||
separate @file{.gcda} file is created for each object file compiled with
|
||||
this option. It contains arc transition counts, and some summary
|
||||
this option. It contains arc transition counts, and some summary
|
||||
information.
|
||||
|
||||
The full details of the file format is specified in @file{gcov-io.h},
|
||||
|
|
|
@ -73,7 +73,7 @@ and such a PCH file won't work.
|
|||
|
||||
@deftypefn {Host Hook} size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void);
|
||||
This host hook returns the alignment required for allocating virtual
|
||||
memory. Usually this is the same as getpagesize, but on some hosts the
|
||||
memory. Usually this is the same as getpagesize, but on some hosts the
|
||||
alignment for reserving memory differs from the pagesize for committing
|
||||
memory.
|
||||
@end deftypefn
|
||||
|
@ -159,7 +159,7 @@ define this macro if using the default will create an invalid file name.
|
|||
Define this macro to be a C statement (sans semicolon) that performs
|
||||
host-dependent removal of ordinary temp files in the compilation driver.
|
||||
|
||||
If you do not define this macro, GCC will use the default version. You
|
||||
If you do not define this macro, GCC will use the default version. You
|
||||
should define this macro if the default version does not reliably remove
|
||||
the temp file as, for example, on VMS which allows multiple versions
|
||||
of a file.
|
||||
|
|
|
@ -49,7 +49,7 @@ a freestanding environment); refer to their documentation for details.
|
|||
@item
|
||||
@cite{How a diagnostic is identified (C90 3.7, C99 3.10, C90 and C99 5.1.1.3).}
|
||||
|
||||
Diagnostics consist of all the output sent to stderr by GCC.
|
||||
Diagnostics consist of all the output sent to stderr by GCC@.
|
||||
|
||||
@item
|
||||
@cite{Whether each nonempty sequence of white-space characters other than
|
||||
|
|
|
@ -261,7 +261,7 @@ environment to your ``good'' shell prior to running
|
|||
@command{configure}/@command{make}.
|
||||
|
||||
@command{zsh} is not a fully compliant POSIX shell and will not
|
||||
work when configuring GCC.
|
||||
work when configuring GCC@.
|
||||
|
||||
@item GNU binutils
|
||||
|
||||
|
@ -277,7 +277,7 @@ obtained via FTP mirror sites.
|
|||
|
||||
@item GNU make version 3.79.1 (or later)
|
||||
|
||||
You must have GNU make installed to build GCC.
|
||||
You must have GNU make installed to build GCC@.
|
||||
|
||||
@item GNU tar version 1.12 (or later)
|
||||
|
||||
|
@ -287,7 +287,7 @@ systems' @command{tar} programs will also work, only try GNU
|
|||
|
||||
@item GNU Multiple Precision Library (GMP) version 4.0 (or later)
|
||||
|
||||
Necessary to build the Fortran frontend. If you don't have it
|
||||
Necessary to build the Fortran frontend. If you don't have it
|
||||
installed in your library search path, you will have to configure with
|
||||
the @option{--with-gmp} or @option{--with-gmp-dir} configure option.
|
||||
|
||||
|
@ -391,7 +391,7 @@ Necessary for running @command{texi2dvi}, used when running
|
|||
@itemx ssh (any version)
|
||||
|
||||
Necessary to access the CVS repository. Public releases and weekly
|
||||
snapshots of the development sources are also available via FTP.
|
||||
snapshots of the development sources are also available via FTP@.
|
||||
|
||||
@item perl version 5.6.1 (or later)
|
||||
|
||||
|
@ -635,22 +635,22 @@ the installation directory for G++ header files. The default is
|
|||
|
||||
@item --program-prefix=@var{prefix}
|
||||
GCC supports some transformations of the names of its programs when
|
||||
installing them. This option prepends @var{prefix} to the names of
|
||||
programs to install in @var{bindir} (see above). For example, specifying
|
||||
installing them. This option prepends @var{prefix} to the names of
|
||||
programs to install in @var{bindir} (see above). For example, specifying
|
||||
@option{--program-prefix=foo-} would result in @samp{gcc}
|
||||
being installed as @file{/usr/local/bin/foo-gcc}.
|
||||
|
||||
@item --program-suffix=@var{suffix}
|
||||
Appends @var{suffix} to the names of programs to install in @var{bindir}
|
||||
(see above). For example, specifying @option{--program-suffix=-3.1}
|
||||
(see above). For example, specifying @option{--program-suffix=-3.1}
|
||||
would result in @samp{gcc} being installed as
|
||||
@file{/usr/local/bin/gcc-3.1}.
|
||||
|
||||
@item --program-transform-name=@var{pattern}
|
||||
Applies the @samp{sed} script @var{pattern} to be applied to the names
|
||||
of programs to install in @var{bindir} (see above). @var{pattern} has to
|
||||
of programs to install in @var{bindir} (see above). @var{pattern} has to
|
||||
consist of one or more basic @samp{sed} editing commands, separated by
|
||||
semicolons. For example, if you want the @samp{gcc} program name to be
|
||||
semicolons. For example, if you want the @samp{gcc} program name to be
|
||||
transformed to the installed program @file{/usr/local/bin/myowngcc} and
|
||||
the @samp{g++} program name to be transformed to
|
||||
@file{/usr/local/bin/gspecial++} without changing other program names,
|
||||
|
@ -659,7 +659,7 @@ you could use the pattern
|
|||
to achieve this effect.
|
||||
|
||||
All three options can be combined and used together, resulting in more
|
||||
complex conversion patterns. As a basic rule, @var{prefix} (and
|
||||
complex conversion patterns. As a basic rule, @var{prefix} (and
|
||||
@var{suffix}) are prepended (appended) before further transformations
|
||||
can happen with a special transformation script @var{pattern}.
|
||||
|
||||
|
@ -669,7 +669,7 @@ transformation is explicitly asked for by one of these options.
|
|||
|
||||
For native builds, some of the installed programs are also installed
|
||||
with the target alias in front of their name, as in
|
||||
@samp{i686-pc-linux-gnu-gcc}. All of the above transformations happen
|
||||
@samp{i686-pc-linux-gnu-gcc}. All of the above transformations happen
|
||||
before the target alias is prepended to the name---so, specifying
|
||||
@option{--program-prefix=foo-} and @option{program-suffix=-3.1}, the
|
||||
resulting binary would be installed as
|
||||
|
@ -809,7 +809,7 @@ directory, where @var{libexec} defaults to
|
|||
@file{@var{exec-prefix}/libexec} and @var{exec-prefix} defaults to
|
||||
@var{prefix} which defaults to @file{/usr/local} unless overridden by
|
||||
the @option{--prefix=@var{pathname}} switch described
|
||||
above. @var{target} is the target system triple, such as
|
||||
above. @var{target} is the target system triple, such as
|
||||
@samp{sparc-sun-solaris2.7}, and @var{version} denotes the GCC
|
||||
version, such as 3.0.
|
||||
@item
|
||||
|
@ -915,7 +915,7 @@ AIX thread support.
|
|||
DCE thread support.
|
||||
@item gnat
|
||||
Ada tasking support. For non-Ada programs, this setting is equivalent
|
||||
to @samp{single}. When used in conjunction with the Ada run time, it
|
||||
to @samp{single}. When used in conjunction with the Ada run time, it
|
||||
causes GCC to use the same thread primitives as Ada uses. This option
|
||||
is necessary when using both Ada and the back end exception handling,
|
||||
which is the default for most Ada targets.
|
||||
|
@ -981,8 +981,8 @@ PowerPC systems.
|
|||
Define if you want to use __cxa_atexit, rather than atexit, to
|
||||
register C++ destructors for local statics and global objects.
|
||||
This is essential for fully standards-compliant handling of
|
||||
destructors, but requires __cxa_atexit in libc. This option is currently
|
||||
only available on systems with GNU libc. When enabled, this will cause
|
||||
destructors, but requires __cxa_atexit in libc. This option is currently
|
||||
only available on systems with GNU libc. When enabled, this will cause
|
||||
@option{-fuse-cxa-exit} to be passed by default.
|
||||
|
||||
@item --enable-target-optspace
|
||||
|
@ -1036,7 +1036,7 @@ addition, @samp{libstdc++}'s include files will be installed into
|
|||
@file{@var{libdir}} unless you overruled it by using
|
||||
@option{--with-gxx-include-dir=@var{dirname}}. Using this option is
|
||||
particularly useful if you intend to use several versions of GCC in
|
||||
parallel. This is currently supported by @samp{libgfortran},
|
||||
parallel. This is currently supported by @samp{libgfortran},
|
||||
@samp{libjava}, @samp{libmudflap}, @samp{libstdc++}, and @samp{libobjc}.
|
||||
|
||||
|
||||
|
@ -1078,7 +1078,7 @@ to look up installations paths in the registry using the following key:
|
|||
@end smallexample
|
||||
|
||||
@var{key} defaults to GCC version number, and can be overridden by the
|
||||
@option{--enable-win32-registry=@var{key}} option. Vendors and distributors
|
||||
@option{--enable-win32-registry=@var{key}} option. Vendors and distributors
|
||||
who use custom installers are encouraged to provide a different key,
|
||||
perhaps one comprised of vendor name and GCC version number, to
|
||||
avoid conflict with existing installations. This feature is enabled
|
||||
|
@ -1130,12 +1130,12 @@ errors causing wrong code to be generated.
|
|||
@item --enable-coverage
|
||||
@itemx --enable-coverage=@var{level}
|
||||
With this option, the compiler is built to collect self coverage
|
||||
information, every time it is run. This is for internal development
|
||||
purposes, and only works when the compiler is being built with gcc. The
|
||||
information, every time it is run. This is for internal development
|
||||
purposes, and only works when the compiler is being built with gcc. The
|
||||
@var{level} argument controls whether the compiler is built optimized or
|
||||
not, values are @samp{opt} and @samp{noopt}. For coverage analysis you
|
||||
not, values are @samp{opt} and @samp{noopt}. For coverage analysis you
|
||||
want to disable optimization, for performance analysis you want to
|
||||
enable optimization. When coverage is enabled, the default level is
|
||||
enable optimization. When coverage is enabled, the default level is
|
||||
without optimization.
|
||||
|
||||
@item --enable-gather-detailed-mem-stats
|
||||
|
@ -1202,7 +1202,7 @@ directory. @emph{This option with the @var{dir} argument is required} when
|
|||
building a cross compiler, if @file{@var{prefix}/@var{target}/sys-include}
|
||||
doesn't pre-exist. If @file{@var{prefix}/@var{target}/sys-include} does
|
||||
pre-exist, the @var{dir} argument may be omitted. @command{fixincludes}
|
||||
will be run on these files to make them compatible with GCC.
|
||||
will be run on these files to make them compatible with GCC@.
|
||||
|
||||
@item --without-headers
|
||||
Tells GCC not use any target headers from a libc when building a cross
|
||||
|
@ -1272,19 +1272,19 @@ The following options apply to building @samp{libgcj}.
|
|||
Don't set system properties from @env{GCJ_PROPERTIES}.
|
||||
|
||||
@item --enable-hash-synchronization
|
||||
Use a global hash table for monitor locks. Ordinarily,
|
||||
Use a global hash table for monitor locks. Ordinarily,
|
||||
@samp{libgcj}'s @samp{configure} script automatically makes
|
||||
the correct choice for this option for your platform. Only use
|
||||
the correct choice for this option for your platform. Only use
|
||||
this if you know you need the library to be configured differently.
|
||||
|
||||
@item --enable-interpreter
|
||||
Enable the Java interpreter. The interpreter is automatically
|
||||
enabled by default on all platforms that support it. This option
|
||||
Enable the Java interpreter. The interpreter is automatically
|
||||
enabled by default on all platforms that support it. This option
|
||||
is really only useful if you want to disable the interpreter
|
||||
(using @option{--disable-interpreter}).
|
||||
|
||||
@item --disable-java-net
|
||||
Disable java.net. This disables the native part of java.net only,
|
||||
Disable java.net. This disables the native part of java.net only,
|
||||
using non-functional stubs for native method implementations.
|
||||
|
||||
@item --disable-jvmpi
|
||||
|
@ -1294,7 +1294,7 @@ Disable JVMPI support.
|
|||
Enable runtime eCos target support.
|
||||
|
||||
@item --without-libffi
|
||||
Don't use @samp{libffi}. This will disable the interpreter and JNI
|
||||
Don't use @samp{libffi}. This will disable the interpreter and JNI
|
||||
support as well, as these require @samp{libffi} to work.
|
||||
|
||||
@item --enable-libgcj-debug
|
||||
|
@ -1303,8 +1303,8 @@ Enable runtime debugging code.
|
|||
@item --enable-libgcj-multifile
|
||||
If specified, causes all @file{.java} source files to be
|
||||
compiled into @file{.class} files in one invocation of
|
||||
@samp{gcj}. This can speed up build time, but is more
|
||||
resource-intensive. If this option is unspecified or
|
||||
@samp{gcj}. This can speed up build time, but is more
|
||||
resource-intensive. If this option is unspecified or
|
||||
disabled, @samp{gcj} is invoked once for each @file{.java}
|
||||
file to compile into a @file{.class} file.
|
||||
|
||||
|
@ -1312,8 +1312,8 @@ file to compile into a @file{.class} file.
|
|||
Search for libiconv in @file{DIR/include} and @file{DIR/lib}.
|
||||
|
||||
@item --enable-sjlj-exceptions
|
||||
Force use of @code{builtin_setjmp} for exceptions. @samp{configure}
|
||||
ordinarily picks the correct value based on the platform. Only use
|
||||
Force use of @code{builtin_setjmp} for exceptions. @samp{configure}
|
||||
ordinarily picks the correct value based on the platform. Only use
|
||||
this option if you are sure you need a different setting.
|
||||
|
||||
@item --with-system-zlib
|
||||
|
@ -1321,25 +1321,25 @@ Use installed @samp{zlib} rather than that included with GCC@.
|
|||
|
||||
@item --with-win32-nlsapi=ansi, unicows or unicode
|
||||
Indicates how MinGW @samp{libgcj} translates between UNICODE
|
||||
characters and the Win32 API.
|
||||
characters and the Win32 API@.
|
||||
@table @code
|
||||
@item ansi
|
||||
Use the single-byte @code{char} and the Win32 A functions natively,
|
||||
translating to and from UNICODE when using these functions. If
|
||||
translating to and from UNICODE when using these functions. If
|
||||
unspecified, this is the default.
|
||||
|
||||
@item unicows
|
||||
Use the @code{WCHAR} and Win32 W functions natively. Adds
|
||||
Use the @code{WCHAR} and Win32 W functions natively. Adds
|
||||
@code{-lunicows} to @file{libgcj.spec} to link with @samp{libunicows}.
|
||||
@file{unicows.dll} needs to be deployed on Microsoft Windows 9X machines
|
||||
running built executables. @file{libunicows.a}, an open-source
|
||||
running built executables. @file{libunicows.a}, an open-source
|
||||
import library around Microsoft's @code{unicows.dll}, is obtained from
|
||||
@uref{http://libunicows.sourceforge.net/}, which also gives details
|
||||
on getting @file{unicows.dll} from Microsoft.
|
||||
|
||||
@item unicode
|
||||
Use the @code{WCHAR} and Win32 W functions natively. Does @emph{not}
|
||||
add @code{-lunicows} to @file{libgcj.spec}. The built executables will
|
||||
Use the @code{WCHAR} and Win32 W functions natively. Does @emph{not}
|
||||
add @code{-lunicows} to @file{libgcj.spec}. The built executables will
|
||||
only run on Microsoft Windows NT and above.
|
||||
@end table
|
||||
@end table
|
||||
|
@ -1352,16 +1352,16 @@ Use the X Window System.
|
|||
|
||||
@item --enable-java-awt=PEER(S)
|
||||
Specifies the AWT peer library or libraries to build alongside
|
||||
@samp{libgcj}. If this option is unspecified or disabled, AWT
|
||||
will be non-functional. Current valid values are @option{gtk} and
|
||||
@option{xlib}. Multiple libraries should be separated by a
|
||||
@samp{libgcj}. If this option is unspecified or disabled, AWT
|
||||
will be non-functional. Current valid values are @option{gtk} and
|
||||
@option{xlib}. Multiple libraries should be separated by a
|
||||
comma (i.e.@: @option{--enable-java-awt=gtk,xlib}).
|
||||
|
||||
@item --enable-gtk-cairo
|
||||
Build the cairo Graphics2D implementation on GTK.
|
||||
Build the cairo Graphics2D implementation on GTK@.
|
||||
|
||||
@item --enable-java-gc=TYPE
|
||||
Choose garbage collector. Defaults to @option{boehm} if unspecified.
|
||||
Choose garbage collector. Defaults to @option{boehm} if unspecified.
|
||||
|
||||
@item --disable-gtktest
|
||||
Do not try to compile and run a test GTK+ program.
|
||||
|
@ -1672,7 +1672,7 @@ at @uref{http://gcc.gnu.org/buildstat.html}, although not everyone who
|
|||
reports a successful build runs the testsuites and submits the results.
|
||||
This step is optional and may require you to download additional software,
|
||||
but it can give you confidence in your new GCC installation or point out
|
||||
problems before you install and start using your new GCC.
|
||||
problems before you install and start using your new GCC@.
|
||||
|
||||
First, you must have @uref{download.html,,downloaded the testsuites}.
|
||||
These are part of the full distribution, but if you downloaded the
|
||||
|
@ -1948,7 +1948,7 @@ quickly review the build status page for your release, available from
|
|||
If your system is not listed for the version of GCC that you built,
|
||||
send a note to
|
||||
@email{gcc@@gcc.gnu.org} indicating
|
||||
that you successfully built and installed GCC.
|
||||
that you successfully built and installed GCC@.
|
||||
Include the following information:
|
||||
|
||||
@itemize @bullet
|
||||
|
@ -2567,7 +2567,7 @@ and includes all the necessary compilation tools and libraries.
|
|||
@heading @anchor{*-*-freebsd*}*-*-freebsd*
|
||||
|
||||
The version of binutils installed in @file{/usr/bin} probably works with
|
||||
this release of GCC. However, on FreeBSD 4, bootstrapping against the
|
||||
this release of GCC@. However, on FreeBSD 4, bootstrapping against the
|
||||
latest FSF binutils is known to improve overall testsuite results; and,
|
||||
on FreeBSD/alpha, using binutils 2.14 or later is required to build libjava.
|
||||
|
||||
|
@ -2587,7 +2587,7 @@ FreeBSD/alpha since its inception. You may use @option{-gstabs} instead
|
|||
of @option{-g}, if you really want the old debugging format. There are
|
||||
no known issues with mixing object files and libraries with different
|
||||
debugging formats. Otherwise, this release of GCC should now match more
|
||||
of the configuration used in the stock FreeBSD configuration of GCC. In
|
||||
of the configuration used in the stock FreeBSD configuration of GCC@. In
|
||||
particular, @option{--enable-threads} is now configured by default.
|
||||
However, as a general user, do not attempt to replace the system
|
||||
compiler with this release. Known to bootstrap and check with good
|
||||
|
@ -2633,9 +2633,9 @@ you may encounter a variety of problems when using the HP assembler.
|
|||
|
||||
Specifically, @option{-g} does not work on HP-UX (since that system
|
||||
uses a peculiar debugging format which GCC does not know about), unless
|
||||
you use GAS and GDB. It may be helpful to configure GCC with the
|
||||
you use GAS and GDB@. It may be helpful to configure GCC with the
|
||||
@uref{./configure.html#with-gnu-as,,@option{--with-gnu-as}} and
|
||||
@option{--with-as=@dots{}} options to ensure that GCC can find GAS.
|
||||
@option{--with-as=@dots{}} options to ensure that GCC can find GAS@.
|
||||
|
||||
If you wish to use the pa-risc 2.0 architecture support with a 32-bit
|
||||
runtime, you must use either the HP assembler, or gas/binutils 2.11
|
||||
|
@ -2711,8 +2711,8 @@ GCC 3.0 and up support HP-UX 11. GCC 2.95.x is not supported and cannot
|
|||
be used to compile GCC 3.0 and up.
|
||||
|
||||
Refer to @uref{binaries.html,,binaries} for information about obtaining
|
||||
precompiled GCC binaries for HP-UX. Precompiled binaries must be obtained
|
||||
to build the Ada language as it can't be bootstrapped using C. Ada is
|
||||
precompiled GCC binaries for HP-UX@. Precompiled binaries must be obtained
|
||||
to build the Ada language as it can't be bootstrapped using C@. Ada is
|
||||
only available for the 32-bit PA-RISC runtime. The libffi and libjava
|
||||
haven't been ported to HP-UX and don't build.
|
||||
|
||||
|
@ -2731,7 +2731,7 @@ unbundled compiler, or a binary distribution of GCC@.
|
|||
There are several possible approaches to building the distribution.
|
||||
Binutils can be built first using the HP tools. Then, the GCC
|
||||
distribution can be built. The second approach is to build GCC
|
||||
first using the HP tools, then build binutils, then rebuild GCC.
|
||||
first using the HP tools, then build binutils, then rebuild GCC@.
|
||||
There have been problems with various binary distributions, so it
|
||||
is best not to start from a binary distribution.
|
||||
|
||||
|
@ -2767,7 +2767,7 @@ search for ld. The two linkers supported on this target require different
|
|||
commands. The default linker is determined during configuration. As a
|
||||
result, it's not possible to switch linkers in the middle of a GCC build.
|
||||
This has been been reported to sometimes occur in unified builds of
|
||||
binutils and GCC.
|
||||
binutils and GCC@.
|
||||
|
||||
GCC 3.0 through 3.2 require binutils 2.11 or above. GCC 3.3 through
|
||||
GCC 3.5 require binutils 2.14 or later.
|
||||
|
@ -2966,13 +2966,13 @@ more major ABI changes are expected.
|
|||
<hr />
|
||||
@end html
|
||||
@heading @anchor{ia64-*-hpux*}ia64-*-hpux*
|
||||
Building GCC on this target requires the GNU Assembler. The bundled HP
|
||||
assembler will not work. To prevent GCC from using the wrong assembler,
|
||||
Building GCC on this target requires the GNU Assembler. The bundled HP
|
||||
assembler will not work. To prevent GCC from using the wrong assembler,
|
||||
the option @option{--with-gnu-as} may be necessary.
|
||||
|
||||
The GCC libunwind library has not been ported to HPUX. This means that for
|
||||
The GCC libunwind library has not been ported to HPUX@. This means that for
|
||||
GCC versions 3.2.3 and earlier, @option{--enable-libunwind-exceptions}
|
||||
is required to build GCC. For GCC 3.3 and later, this is the default.
|
||||
is required to build GCC@. For GCC 3.3 and later, this is the default.
|
||||
For gcc 3.4.3 and later, @option{--enable-libunwind-exceptions} is
|
||||
removed and the system libunwind library will always be used.
|
||||
|
||||
|
@ -3010,10 +3010,10 @@ If this error occurs during stage2 or later, then the problem most likely
|
|||
is the version of Make (see above).
|
||||
|
||||
The native @command{as} and @command{ld} are recommended for bootstrapping
|
||||
on AIX 4 and required for bootstrapping on AIX 5L. The GNU Assembler
|
||||
on AIX 4 and required for bootstrapping on AIX 5L@. The GNU Assembler
|
||||
reports that it supports WEAK symbols on AIX 4, which causes GCC to try to
|
||||
utilize weak symbol functionality although it is not supported. The GNU
|
||||
Assembler and Linker do not support AIX 5L sufficiently to bootstrap GCC.
|
||||
Assembler and Linker do not support AIX 5L sufficiently to bootstrap GCC@.
|
||||
The native AIX tools do interoperate with GCC@.
|
||||
|
||||
Building @file{libstdc++.a} requires a fix for an AIX Assembler bug
|
||||
|
@ -3218,9 +3218,9 @@ MIPS systems check for division by zero (unless
|
|||
generating either a conditional trap or a break instruction. Using
|
||||
trap results in smaller code, but is only supported on MIPS II and
|
||||
later. Also, some versions of the Linux kernel have a bug that
|
||||
prevents trap from generating the proper signal (SIGFPE). To enable
|
||||
prevents trap from generating the proper signal (@code{SIGFPE}). To enable
|
||||
the use of break, use the @option{--with-divide=breaks}
|
||||
@command{configure} option when configuring GCC. The default is to
|
||||
@command{configure} option when configuring GCC@. The default is to
|
||||
use traps on systems that support them.
|
||||
|
||||
Cross-compilers for the Mips as target using the Mips assembler
|
||||
|
@ -3436,7 +3436,7 @@ zSeries system (64-bit) running GNU/Linux for zSeries@.
|
|||
<hr />
|
||||
@end html
|
||||
@heading @anchor{s390x-ibm-tpf*}s390x-ibm-tpf*
|
||||
zSeries system (64-bit) running TPF. This platform is
|
||||
zSeries system (64-bit) running TPF@. This platform is
|
||||
supported as cross-compilation target only.
|
||||
|
||||
@html
|
||||
|
@ -3632,7 +3632,7 @@ the Solaris 7 Recommended Patch Cluster.
|
|||
|
||||
GCC 3.3 triggers a bug in version 5.0 Alpha 03/27/98 of the Sun assembler,
|
||||
which causes a bootstrap failure when linking the 64-bit shared version of
|
||||
libgcc. A typical error message is:
|
||||
libgcc. A typical error message is:
|
||||
|
||||
@smallexample
|
||||
ld: fatal: relocation error: R_SPARC_32: file libgcc/sparcv9/_muldi3.o:
|
||||
|
@ -3719,7 +3719,7 @@ in some cases (for example, when @code{alloca} is used).
|
|||
@end html
|
||||
@heading @anchor{*-*-vxworks*}*-*-vxworks*
|
||||
Support for VxWorks is in flux. At present GCC supports @emph{only} the
|
||||
very recent VxWorks 5.5 (aka Tornado 2.2) release, and only on PowerPC.
|
||||
very recent VxWorks 5.5 (aka Tornado 2.2) release, and only on PowerPC@.
|
||||
We welcome patches for other architectures supported by VxWorks 5.5.
|
||||
Support for VxWorks AE would also be welcome; we believe this is merely
|
||||
a matter of writing an appropriate ``configlette'' (see below). We are
|
||||
|
@ -3731,7 +3731,7 @@ VxWorks comes with an older version of GCC installed in
|
|||
Choose an installation @var{prefix} entirely outside @var{$WIND_BASE}.
|
||||
Before running @command{configure}, create the directories @file{@var{prefix}}
|
||||
and @file{@var{prefix}/bin}. Link or copy the appropriate assembler,
|
||||
linker, etc. into @file{@var{prefix}/bin}, and set your @var{PATH} to
|
||||
linker, etc.@: into @file{@var{prefix}/bin}, and set your @var{PATH} to
|
||||
include that directory while running both @command{configure} and
|
||||
@command{make}.
|
||||
|
||||
|
@ -3755,7 +3755,7 @@ VxWorks will incorporate this module.)
|
|||
@heading @anchor{x86_64-*-*}x86_64-*-*, amd64-*-*
|
||||
|
||||
GCC supports the x86-64 architecture implemented by the AMD64 processor
|
||||
(amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD.
|
||||
(amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD@.
|
||||
On GNU/Linux the default is a bi-arch compiler which is able to generate
|
||||
both 64-bit x86-64 and 32-bit x86 code (via the @option{-m32} switch).
|
||||
|
||||
|
|
|
@ -989,7 +989,7 @@ line options for each tool.
|
|||
|
||||
@item --version
|
||||
@opindex version
|
||||
Display the version number and copyrights of the invoked GCC.
|
||||
Display the version number and copyrights of the invoked GCC@.
|
||||
@end table
|
||||
|
||||
@node Invoking G++
|
||||
|
@ -1239,9 +1239,9 @@ options for strict ISO C conformance) implies @option{-trigraphs}.
|
|||
@opindex no-integrated-cpp
|
||||
Performs a compilation in two passes: preprocessing and compiling. This
|
||||
option allows a user supplied "cc1", "cc1plus", or "cc1obj" via the
|
||||
@option{-B} option. The user supplied compilation step can then add in
|
||||
@option{-B} option. The user supplied compilation step can then add in
|
||||
an additional preprocessing step after normal preprocessing but before
|
||||
compiling. The default is to use the integrated cpp (internal cpp)
|
||||
compiling. The default is to use the integrated cpp (internal cpp)
|
||||
|
||||
The semantics of this option will change if "cc1", "cc1plus", and
|
||||
"cc1obj" are merged.
|
||||
|
@ -1330,7 +1330,7 @@ Here is a list of options that are @emph{only} for compiling C++ programs:
|
|||
|
||||
@item -fabi-version=@var{n}
|
||||
@opindex fabi-version
|
||||
Use version @var{n} of the C++ ABI. Version 2 is the version of the
|
||||
Use version @var{n} of the C++ ABI@. Version 2 is the version of the
|
||||
C++ ABI that first appeared in G++ 3.4. Version 1 is the version of
|
||||
the C++ ABI that first appeared in G++ 3.2. Version 0 will always be
|
||||
the version that conforms most closely to the C++ ABI specification.
|
||||
|
@ -1509,13 +1509,13 @@ destructors, but will only work if your C library supports
|
|||
Causes all inlined methods to be marked with
|
||||
@code{__attribute__ ((visibility ("hidden")))} so that they do not
|
||||
appear in the export table of a DSO and do not require a PLT indirection
|
||||
when used within the DSO. Enabling this option can have a dramatic effect
|
||||
when used within the DSO@. Enabling this option can have a dramatic effect
|
||||
on load and link times of a DSO as it massively reduces the size of the
|
||||
dynamic export table when the library makes heavy use of templates. While
|
||||
dynamic export table when the library makes heavy use of templates. While
|
||||
it can cause bloating through duplication of code within each DSO where
|
||||
it is used, often the wastage is less than the considerable space occupied
|
||||
by a long symbol name in the export table which is typical when using
|
||||
templates and namespaces. For even more savings, combine with the
|
||||
templates and namespaces. For even more savings, combine with the
|
||||
@option{-fvisibility=hidden} switch.
|
||||
|
||||
@item -fno-weak
|
||||
|
@ -1547,7 +1547,7 @@ inlined by default.
|
|||
@item -Wabi @r{(C++ only)}
|
||||
@opindex Wabi
|
||||
Warn when G++ generates code that is probably not compatible with the
|
||||
vendor-neutral C++ ABI. Although an effort has been made to warn about
|
||||
vendor-neutral C++ ABI@. Although an effort has been made to warn about
|
||||
all such cases, there are probably some cases that are not warned about,
|
||||
even though G++ is generating incompatible code. There may also be
|
||||
cases where warnings are emitted even though the code that is generated
|
||||
|
@ -2592,8 +2592,8 @@ the warnings were only enabled by the @option{-Wall} command line option.
|
|||
@opindex Wstrict-aliasing
|
||||
This option is only active when @option{-fstrict-aliasing} is active.
|
||||
It warns about code which might break the strict aliasing rules that the
|
||||
compiler is using for optimization. The warning does not catch all
|
||||
cases, but does attempt to catch the more common pitfalls. It is
|
||||
compiler is using for optimization. The warning does not catch all
|
||||
cases, but does attempt to catch the more common pitfalls. It is
|
||||
included in @option{-Wall}.
|
||||
|
||||
@item -Wstrict-aliasing=2
|
||||
|
@ -3301,12 +3301,12 @@ Add code so that program flow @dfn{arcs} are instrumented. During
|
|||
execution the program records how many times each branch and call is
|
||||
executed and how many times it is taken or returns. When the compiled
|
||||
program exits it saves this data to a file called
|
||||
@file{@var{auxname}.gcda} for each source file. The data may be used for
|
||||
@file{@var{auxname}.gcda} for each source file. The data may be used for
|
||||
profile-directed optimizations (@option{-fbranch-probabilities}), or for
|
||||
test coverage analysis (@option{-ftest-coverage}). Each object file's
|
||||
test coverage analysis (@option{-ftest-coverage}). Each object file's
|
||||
@var{auxname} is generated from the name of the output file, if
|
||||
explicitly specified and it is not the final executable, otherwise it is
|
||||
the basename of the source file. In both cases any suffix is removed
|
||||
the basename of the source file. In both cases any suffix is removed
|
||||
(e.g.@: @file{foo.gcda} for input file @file{dir/foo.c}, or
|
||||
@file{dir/foo.gcda} for output file specified as @option{-o dir/foo.o}).
|
||||
|
||||
|
@ -3314,8 +3314,8 @@ the basename of the source file. In both cases any suffix is removed
|
|||
|
||||
@item
|
||||
Compile the source files with @option{-fprofile-arcs} plus optimization
|
||||
and code generation options. For test coverage analysis, use the
|
||||
additional @option{-ftest-coverage} option. You do not need to profile
|
||||
and code generation options. For test coverage analysis, use the
|
||||
additional @option{-ftest-coverage} option. You do not need to profile
|
||||
every source file in a program.
|
||||
|
||||
@item
|
||||
|
@ -3324,9 +3324,9 @@ Link your object files with @option{-lgcov} or @option{-fprofile-arcs}
|
|||
|
||||
@item
|
||||
Run the program on a representative workload to generate the arc profile
|
||||
information. This may be repeated any number of times. You can run
|
||||
information. This may be repeated any number of times. You can run
|
||||
concurrent instances of your program, and provided that the file system
|
||||
supports locking, the data files will be correctly updated. Also
|
||||
supports locking, the data files will be correctly updated. Also
|
||||
@code{fork} calls are detected and correctly handled (double counting
|
||||
will not happen).
|
||||
|
||||
|
@ -3338,7 +3338,7 @@ Control Optimization}).
|
|||
|
||||
@item
|
||||
For test coverage analysis, use @command{gcov} to produce human readable
|
||||
information from the @file{.gcno} and @file{.gcda} files. Refer to the
|
||||
information from the @file{.gcno} and @file{.gcda} files. Refer to the
|
||||
@command{gcov} documentation for further information.
|
||||
|
||||
@end itemize
|
||||
|
@ -3367,10 +3367,10 @@ working on improving it.
|
|||
@opindex ftest-coverage
|
||||
Produce a notes file that the @command{gcov} code-coverage utility
|
||||
(@pxref{Gcov,, @command{gcov}---a Test Coverage Program}) can use to
|
||||
show program coverage. Each source file's note file is called
|
||||
@file{@var{auxname}.gcno}. Refer to the @option{-fprofile-arcs} option
|
||||
show program coverage. Each source file's note file is called
|
||||
@file{@var{auxname}.gcno}. Refer to the @option{-fprofile-arcs} option
|
||||
above for a description of @var{auxname} and instructions on how to
|
||||
generate test coverage data. Coverage data will match the source files
|
||||
generate test coverage data. Coverage data will match the source files
|
||||
more closely, if you do not optimize.
|
||||
|
||||
@item -d@var{letters}
|
||||
|
@ -3681,7 +3681,7 @@ to the source file name. If the @samp{-@var{options}} form is used,
|
|||
@opindex fdump-ipa
|
||||
Control the dumping at various stages of inter-procedural analysis
|
||||
language tree to a file. The file name is generated by appending a switch
|
||||
specific suffix to the source file name. The following dumps are possible:
|
||||
specific suffix to the source file name. The following dumps are possible:
|
||||
|
||||
@table @samp
|
||||
@item all
|
||||
|
@ -3700,14 +3700,14 @@ Control the dumping at various stages of processing the intermediate
|
|||
language tree to a file. The file name is generated by appending a switch
|
||||
specific suffix to the source file name. If the @samp{-@var{options}}
|
||||
form is used, @var{options} is a list of @samp{-} separated options that
|
||||
control the details of the dump. Not all options are applicable to all
|
||||
dumps, those which are not meaningful will be ignored. The following
|
||||
control the details of the dump. Not all options are applicable to all
|
||||
dumps, those which are not meaningful will be ignored. The following
|
||||
options are available
|
||||
|
||||
@table @samp
|
||||
@item address
|
||||
Print the address of each node. Usually this is not meaningful as it
|
||||
changes according to the environment and source file. Its primary use
|
||||
changes according to the environment and source file. Its primary use
|
||||
is for tying up a dump file with a debug environment.
|
||||
@item slim
|
||||
Inhibit dumping of members of a scope or body of a function merely
|
||||
|
@ -3761,7 +3761,7 @@ made by appending @file{.cfg} to the source file name.
|
|||
Dump the control flow graph of each function to a file in VCG format. The
|
||||
file name is made by appending @file{.vcg} to the source file name. Note
|
||||
that if the file contains more than one function, the generated file cannot
|
||||
be used directly by VCG. You will need to cut and paste each function's
|
||||
be used directly by VCG@. You will need to cut and paste each function's
|
||||
graph into its own separate file first.
|
||||
|
||||
@item ch
|
||||
|
@ -3781,7 +3781,7 @@ appending @file{.alias} to the source file name.
|
|||
|
||||
@item ccp
|
||||
@opindex fdump-tree-ccp
|
||||
Dump each function after CCP. The file name is made by appending
|
||||
Dump each function after CCP@. The file name is made by appending
|
||||
@file{.ccp} to the source file name.
|
||||
|
||||
@item pre
|
||||
|
@ -3854,9 +3854,9 @@ Enable all the available tree dumps with the flags provided in this option.
|
|||
@opindex frandom-string
|
||||
This option provides a seed that GCC uses when it would otherwise use
|
||||
random numbers. It is used to generate certain symbol names
|
||||
that have to be different in every compiled file. It is also used to
|
||||
that have to be different in every compiled file. It is also used to
|
||||
place unique stamps in coverage data files and the object files that
|
||||
produce them. You can use the @option{-frandom-seed} option to produce
|
||||
produce them. You can use the @option{-frandom-seed} option to produce
|
||||
reproducibly identical object files.
|
||||
|
||||
The @var{string} should be different for every file you compile.
|
||||
|
@ -3905,8 +3905,8 @@ Both numbers are in seconds.
|
|||
|
||||
@item -fvar-tracking
|
||||
@opindex fvar-tracking
|
||||
Run variable tracking pass. It computes where variables are stored at each
|
||||
position in code. Better debugging information is then generated
|
||||
Run variable tracking pass. It computes where variables are stored at each
|
||||
position in code. Better debugging information is then generated
|
||||
(if the debugging information format supports this information).
|
||||
|
||||
It is enabled by default when compiling with optimization (@option{-Os},
|
||||
|
@ -4234,7 +4234,7 @@ release to an another.
|
|||
In C, emit @code{static} functions that are declared @code{inline}
|
||||
into the object file, even if the function has been inlined into all
|
||||
of its callers. This switch does not affect functions using the
|
||||
@code{extern inline} extension in GNU C. In C++, emit any and all
|
||||
@code{extern inline} extension in GNU C@. In C++, emit any and all
|
||||
inline functions into the object file.
|
||||
|
||||
@item -fkeep-static-consts
|
||||
|
@ -4438,7 +4438,7 @@ Enabled by default when gcse is enabled.
|
|||
@item -fgcse-after-reload
|
||||
@opindex fgcse-after-reload
|
||||
When @option{-fgcse-after-reload} is enabled, a redundant load elimination
|
||||
pass is performed after reload. The purpose of this pass is to cleanup
|
||||
pass is performed after reload. The purpose of this pass is to cleanup
|
||||
redundant spilling.
|
||||
|
||||
@item -floop-optimize
|
||||
|
@ -4456,7 +4456,7 @@ by separate flags.
|
|||
|
||||
@item -fcrossjumping
|
||||
@opindex crossjumping
|
||||
Perform cross-jumping transformation. This transformation unifies equivalent code and save code size. The
|
||||
Perform cross-jumping transformation. This transformation unifies equivalent code and save code size. The
|
||||
resulting code may or may not perform better than without cross-jumping.
|
||||
|
||||
Enabled at levels @option{-O2}, @option{-O3}, @option{-Os}.
|
||||
|
@ -4650,7 +4650,7 @@ Perform loop optimizations on trees. This flag is enabled by default
|
|||
at @option{-O} and higher.
|
||||
|
||||
@item -ftree-loop-linear
|
||||
Perform linear loop transformations on tree. This flag can improve cache
|
||||
Perform linear loop transformations on tree. This flag can improve cache
|
||||
performance and allow further loop optimizations to take place.
|
||||
|
||||
@item -ftree-lim
|
||||
|
@ -4699,7 +4699,7 @@ Perform loop vectorization on trees.
|
|||
|
||||
@item -ftracer
|
||||
@opindex ftracer
|
||||
Perform tail duplication to enlarge superblock size. This transformation
|
||||
Perform tail duplication to enlarge superblock size. This transformation
|
||||
simplifies the control flow of the function allowing other optimizations to do
|
||||
better job.
|
||||
|
||||
|
@ -4725,7 +4725,7 @@ long dependency chains, thus improving efficiency of the scheduling passes
|
|||
(for best results, @option{-fweb} should be used as well).
|
||||
|
||||
Combination of @option{-fweb} and CSE is often sufficient to obtain the
|
||||
same effect. However in cases the loop body is more complicated than
|
||||
same effect. However in cases the loop body is more complicated than
|
||||
a single basic block, this is not reliable. It also does not work at all
|
||||
on some of the architectures due to restrictions in the CSE pass.
|
||||
|
||||
|
@ -4797,7 +4797,7 @@ sections.
|
|||
@item -freorder-functions
|
||||
@opindex freorder-functions
|
||||
Reorder basic blocks in the compiled function in order to reduce number of
|
||||
taken branches and improve code locality. This is implemented by using special
|
||||
taken branches and improve code locality. This is implemented by using special
|
||||
subsections @code{.text.hot} for most frequently executed functions and
|
||||
@code{.text.unlikely} for unlikely executed functions. Reordering is done by
|
||||
the linker so object file format must support named sections and linker must
|
||||
|
@ -4948,12 +4948,12 @@ shall be used on the declaration.
|
|||
|
||||
@item
|
||||
Static functions now can use non-standard passing conventions that
|
||||
may break @code{asm} statements calling functions directly. Again,
|
||||
may break @code{asm} statements calling functions directly. Again,
|
||||
attribute @code{used} will prevent this behavior.
|
||||
@end itemize
|
||||
|
||||
As a temporary workaround, @option{-fno-unit-at-a-time} can be used,
|
||||
but this scheme may not be supported by future releases of GCC.
|
||||
but this scheme may not be supported by future releases of GCC@.
|
||||
|
||||
Enabled at levels @option{-O2}, @option{-O3}.
|
||||
|
||||
|
@ -5211,7 +5211,7 @@ for testing, so we are interested to hear about miscompilations with
|
|||
|
||||
@item -ftracer
|
||||
@opindex ftracer
|
||||
Perform tail duplication to enlarge superblock size. This transformation
|
||||
Perform tail duplication to enlarge superblock size. This transformation
|
||||
simplifies the control flow of the function allowing other optimizations to do
|
||||
better job.
|
||||
|
||||
|
@ -5531,12 +5531,12 @@ Maximum number of basic blocks on path that cse considers. The default is 10.
|
|||
|
||||
@item global-var-threshold
|
||||
|
||||
Counts the number of function calls (N) and the number of
|
||||
call-clobbered variables (V). If NxV is larger than this limit, a
|
||||
Counts the number of function calls (@var{n}) and the number of
|
||||
call-clobbered variables (@var{v}). If @var{n}x@var{v} is larger than this limit, a
|
||||
single artificial variable will be created to represent all the
|
||||
call-clobbered variables at function call sites. This artificial
|
||||
variable will then be made to alias every call-clobbered variable.
|
||||
(done as int * size_t on the host machine; beware overflow).
|
||||
(done as @code{int * size_t} on the host machine; beware overflow).
|
||||
|
||||
@item max-aliased-vops
|
||||
|
||||
|
@ -5554,8 +5554,8 @@ Tuning this may improve compilation speed; it has no effect on code
|
|||
generation.
|
||||
|
||||
The default is 30% + 70% * (RAM/1GB) with an upper bound of 100% when
|
||||
RAM >= 1GB. If @code{getrlimit} is available, the notion of "RAM" is
|
||||
the smallest of actual RAM and RLIMIT_DATA or RLIMIT_AS. If
|
||||
RAM >= 1GB@. If @code{getrlimit} is available, the notion of "RAM" is
|
||||
the smallest of actual RAM and @code{RLIMIT_DATA} or @code{RLIMIT_AS}. If
|
||||
GCC is not able to calculate RAM on a particular platform, the lower
|
||||
bound of 30% is used. Setting this parameter and
|
||||
@option{ggc-min-heapsize} to zero causes a full collection to occur at
|
||||
|
@ -6671,7 +6671,7 @@ architectures:
|
|||
@table @gcctabopt
|
||||
@item -mabi=@var{name}
|
||||
@opindex mabi
|
||||
Generate code for the specified ABI. Permissible values are: @samp{apcs-gnu},
|
||||
Generate code for the specified ABI@. Permissible values are: @samp{apcs-gnu},
|
||||
@samp{atpcs}, @samp{aapcs} and @samp{iwmmxt}.
|
||||
|
||||
@item -mapcs-frame
|
||||
|
@ -7029,9 +7029,9 @@ Change only the low 8 bits of the stack pointer.
|
|||
|
||||
@item -mint8
|
||||
@opindex mint8
|
||||
Assume int to be 8 bit integer. This affects the sizes of all types: A
|
||||
Assume int to be 8 bit integer. This affects the sizes of all types: A
|
||||
char will be 1 byte, an int will be 1 byte, an long will be 2 bytes
|
||||
and long long will be 4 bytes. Please note that this option does not
|
||||
and long long will be 4 bytes. Please note that this option does not
|
||||
comply to the C standards, but it will provide you with smaller code
|
||||
size.
|
||||
@end table
|
||||
|
@ -7049,7 +7049,7 @@ These options are defined specifically for the CRIS ports.
|
|||
@opindex mcpu
|
||||
Generate code for the specified architecture. The choices for
|
||||
@var{architecture-type} are @samp{v3}, @samp{v8} and @samp{v10} for
|
||||
respectively ETRAX@w{ }4, ETRAX@w{ }100, and ETRAX@w{ }100@w{ }LX.
|
||||
respectively ETRAX@w{ }4, ETRAX@w{ }100, and ETRAX@w{ }100@w{ }LX@.
|
||||
Default is @samp{v0} except for cris-axis-linux-gnu, where the default is
|
||||
@samp{v10}.
|
||||
|
||||
|
@ -7147,7 +7147,7 @@ or storage for local variable needs to be allocated.
|
|||
With @option{-fpic} and @option{-fPIC}, don't generate (do generate)
|
||||
instruction sequences that load addresses for functions from the PLT part
|
||||
of the GOT rather than (traditional on other architectures) calls to the
|
||||
PLT. The default is @option{-mgotplt}.
|
||||
PLT@. The default is @option{-mgotplt}.
|
||||
|
||||
@item -maout
|
||||
@opindex maout
|
||||
|
@ -7241,9 +7241,9 @@ the name of the framework and header.h is found in the
|
|||
|
||||
@item -gused
|
||||
@opindex -gused
|
||||
Emit debugging information for symbols that are used. For STABS
|
||||
Emit debugging information for symbols that are used. For STABS
|
||||
debugging format, this enables @option{-feliminate-unused-debug-symbols}.
|
||||
This is by default ON.
|
||||
This is by default ON@.
|
||||
|
||||
@item -gfull
|
||||
@opindex -gfull
|
||||
|
@ -7296,7 +7296,7 @@ See man ld(1) for more information.
|
|||
@item -bundle_loader @var{executable}
|
||||
@opindex bundle_loader
|
||||
This option specifies the @var{executable} that will be loading the build
|
||||
output file being linked. See man ld(1) for more information.
|
||||
output file being linked. See man ld(1) for more information.
|
||||
|
||||
@item -dynamiclib
|
||||
@opindex -dynamiclib
|
||||
|
@ -7654,7 +7654,7 @@ size of the small data area to 64KB, but allows the variables to be
|
|||
directly accessed via a single instruction.
|
||||
|
||||
The default is @option{-mlarge-data}. With this option the data area
|
||||
is limited to just below 2GB. Programs that require more than 2GB of
|
||||
is limited to just below 2GB@. Programs that require more than 2GB of
|
||||
data must use @code{malloc} or @code{mmap} to allocate the data in the
|
||||
heap instead of in the program's data segment.
|
||||
|
||||
|
@ -8206,10 +8206,10 @@ this to work.
|
|||
|
||||
@item -msio
|
||||
@opindex msio
|
||||
Generate the predefine, @code{_SIO}, for server IO. The default is
|
||||
Generate the predefine, @code{_SIO}, for server IO@. The default is
|
||||
@option{-mwsio}. This generates the predefines, @code{__hp9000s700},
|
||||
@code{__hp9000s700__} and @code{_WSIO}, for workstation IO. These
|
||||
options are available under HP-UX and HI-UX.
|
||||
@code{__hp9000s700__} and @code{_WSIO}, for workstation IO@. These
|
||||
options are available under HP-UX and HI-UX@.
|
||||
|
||||
@item -mgnu-ld
|
||||
@opindex gnu-ld
|
||||
|
@ -8309,7 +8309,7 @@ adding these link options.
|
|||
@item -threads
|
||||
@opindex threads
|
||||
Add support for multithreading with the @dfn{dce thread} library
|
||||
under HP-UX. This option sets flags for both the preprocessor and
|
||||
under HP-UX@. This option sets flags for both the preprocessor and
|
||||
linker.
|
||||
@end table
|
||||
|
||||
|
@ -8331,15 +8331,15 @@ for the ABI and the set of available instructions. The choices for
|
|||
@var{cpu-type} are:
|
||||
@table @emph
|
||||
@item i386
|
||||
Original Intel's i386 CPU.
|
||||
Original Intel's i386 CPU@.
|
||||
@item i486
|
||||
Intel's i486 CPU. (No scheduling is implemented for this chip.)
|
||||
Intel's i486 CPU@. (No scheduling is implemented for this chip.)
|
||||
@item i586, pentium
|
||||
Intel Pentium CPU with no MMX support.
|
||||
@item pentium-mmx
|
||||
Intel PentiumMMX CPU based on Pentium core with MMX instruction set support.
|
||||
@item i686, pentiumpro
|
||||
Intel PentiumPro CPU.
|
||||
Intel PentiumPro CPU@.
|
||||
@item pentium2
|
||||
Intel Pentium2 CPU based on PentiumPro core with MMX instruction set support.
|
||||
@item pentium3, pentium3m
|
||||
|
@ -8376,7 +8376,7 @@ set support.
|
|||
IDT Winchip2 CPU, dealt in same way as i486 with additional MMX and 3dNOW!
|
||||
instruction set support.
|
||||
@item c3
|
||||
Via C3 CPU with MMX and 3dNOW! instruction set support. (No scheduling is
|
||||
Via C3 CPU with MMX and 3dNOW! instruction set support. (No scheduling is
|
||||
implemented for this chip.)
|
||||
@item c3-2
|
||||
Via C3-2 CPU with MMX and SSE instruction set support. (No scheduling is
|
||||
|
@ -8421,7 +8421,7 @@ Use the standard 387 floating point coprocessor present majority of chips and
|
|||
emulated otherwise. Code compiled with this option will run almost everywhere.
|
||||
The temporary results are computed in 80bit precision instead of precision
|
||||
specified by the type resulting in slightly different results compared to most
|
||||
of other chips. See @option{-ffloat-store} for more detailed description.
|
||||
of other chips. See @option{-ffloat-store} for more detailed description.
|
||||
|
||||
This is the default choice for i386 compiler.
|
||||
|
||||
|
@ -8454,7 +8454,7 @@ functional units well resulting in instable performance.
|
|||
|
||||
@item -masm=@var{dialect}
|
||||
@opindex masm=@var{dialect}
|
||||
Output asm instructions using selected @var{dialect}. Supported choices are
|
||||
Output asm instructions using selected @var{dialect}. Supported choices are
|
||||
@samp{intel} or @samp{att} (the default one).
|
||||
|
||||
@item -mieee-fp
|
||||
|
@ -8521,7 +8521,7 @@ without that switch.
|
|||
@itemx -m128bit-long-double
|
||||
@opindex m96bit-long-double
|
||||
@opindex m128bit-long-double
|
||||
These switches control the size of @code{long double} type. The i386
|
||||
These switches control the size of @code{long double} type. The i386
|
||||
application binary interface specifies the size to be 96 bits,
|
||||
so @option{-m96bit-long-double} is the default in 32 bit mode.
|
||||
|
||||
|
@ -9416,7 +9416,7 @@ Equivalent to @samp{-march=mips64}.
|
|||
@itemx -mno-mips16
|
||||
@opindex mips16
|
||||
@opindex mno-mips16
|
||||
Use (do not use) the MIPS16 ISA.
|
||||
Use (do not use) the MIPS16 ISA@.
|
||||
|
||||
@item -mabi=32
|
||||
@itemx -mabi=o64
|
||||
|
@ -9451,7 +9451,7 @@ Generate (do not generate) SVR4-style position-independent code.
|
|||
Lift (do not lift) the usual restrictions on the size of the global
|
||||
offset table.
|
||||
|
||||
GCC normally uses a single instruction to load values from the GOT.
|
||||
GCC normally uses a single instruction to load values from the GOT@.
|
||||
While this is relatively efficient, it will only work if the GOT
|
||||
is smaller than about 64k. Anything larger will cause the linker
|
||||
to report an error such as:
|
||||
|
@ -9521,7 +9521,7 @@ support to be enabled.
|
|||
@itemx -mno-mips3d
|
||||
@opindex mips3d
|
||||
@opindex mno-mips3d
|
||||
Use (do not use) the MIPS-3D ASE. @xref{MIPS-3D Built-in Functions}.
|
||||
Use (do not use) the MIPS-3D ASE@. @xref{MIPS-3D Built-in Functions}.
|
||||
The option @option{-mips3d} implies @option{-mpaired-single}.
|
||||
|
||||
@item -mint64
|
||||
|
@ -9607,7 +9607,7 @@ MIPS systems check for division by zero by generating either a
|
|||
conditional trap or a break instruction. Using traps results in
|
||||
smaller code, but is only supported on MIPS II and later. Also, some
|
||||
versions of the Linux kernel have a bug that prevents trap from
|
||||
generating the proper signal (SIGFPE). Use @option{-mdivide-traps} to
|
||||
generating the proper signal (@code{SIGFPE}). Use @option{-mdivide-traps} to
|
||||
allow conditional traps on architectures that support them and
|
||||
@option{-mdivide-breaks} to force the use of breaks.
|
||||
|
||||
|
@ -9640,7 +9640,7 @@ This option has no effect on abicalls code. The default is
|
|||
@opindex mmad
|
||||
@opindex mno-mad
|
||||
Enable (disable) use of the @code{mad}, @code{madu} and @code{mul}
|
||||
instructions, as provided by the R4650 ISA.
|
||||
instructions, as provided by the R4650 ISA@.
|
||||
|
||||
@item -mfused-madd
|
||||
@itemx -mno-fused-madd
|
||||
|
@ -10115,11 +10115,11 @@ Do not pretend that branches are expensive. This is the default.
|
|||
|
||||
@item -msplit
|
||||
@opindex msplit
|
||||
Generate code for a system with split I&D.
|
||||
Generate code for a system with split I&D@.
|
||||
|
||||
@item -mno-split
|
||||
@opindex mno-split
|
||||
Generate code for a system without split I&D. This is the default.
|
||||
Generate code for a system without split I&D@. This is the default.
|
||||
|
||||
@item -munix-asm
|
||||
@opindex munix-asm
|
||||
|
@ -10307,7 +10307,7 @@ ABI@.
|
|||
|
||||
@item -mabi=no-spe
|
||||
@opindex mabi=no-spe
|
||||
Disable Booke SPE ABI extensions for the current ABI.
|
||||
Disable Booke SPE ABI extensions for the current ABI@.
|
||||
|
||||
@item -misel=@var{yes/no}
|
||||
@itemx -misel
|
||||
|
@ -10426,7 +10426,7 @@ On AIX, Darwin, and 64-bit PowerPC GNU/Linux, the option
|
|||
@option{-malign-natural} overrides the ABI-defined alignment of larger
|
||||
types, such as floating-point doubles, on their natural size-based boundary.
|
||||
The option @option{-malign-power} instructs GCC to follow the ABI-specified
|
||||
alignment rules. GCC defaults to the standard alignment defined in the ABI.
|
||||
alignment rules. GCC defaults to the standard alignment defined in the ABI@.
|
||||
|
||||
@item -msoft-float
|
||||
@itemx -mhard-float
|
||||
|
@ -10574,7 +10574,7 @@ by the target during instruction scheduling. The argument
|
|||
@item -minsert-sched-nops=@var{scheme}
|
||||
@opindex minsert-sched-nops
|
||||
This option controls which nop insertion scheme will be used during
|
||||
the second scheduling pass. The argument @var{scheme} takes one of the
|
||||
the second scheduling pass. The argument @var{scheme} takes one of the
|
||||
following values:
|
||||
@var{no}: Don't insert nops.
|
||||
@var{pad}: Pad with nops any dispatch group which has vacant issue slots,
|
||||
|
@ -10637,7 +10637,7 @@ the current ABI@.
|
|||
|
||||
@item -mabi=no-altivec
|
||||
@opindex mabi=no-altivec
|
||||
Disable AltiVec ABI extensions for the current ABI.
|
||||
Disable AltiVec ABI extensions for the current ABI@.
|
||||
|
||||
@item -mprototype
|
||||
@itemx -mno-prototype
|
||||
|
@ -10843,11 +10843,11 @@ If one of the other options is present the backchain pointer is placed either
|
|||
on top of the stack frame (@option{-mkernel-backchain}) or on
|
||||
the bottom (@option{-mbackchain}).
|
||||
Beside the different backchain location @option{-mkernel-backchain}
|
||||
also changes stack frame layout breaking the ABI. This option
|
||||
also changes stack frame layout breaking the ABI@. This option
|
||||
is intended to be used for code which internally needs a backchain but has
|
||||
to get by with a limited stack size e.g.@: the linux kernel.
|
||||
Internal unwinding code not using DWARF-2 info has to be able to locate the
|
||||
return address of a function. That will be eased be the fact that
|
||||
return address of a function. That will be eased be the fact that
|
||||
the return address of a function is placed two words below the backchain
|
||||
pointer.
|
||||
|
||||
|
@ -10879,7 +10879,7 @@ targets default to @option{-m64}.
|
|||
When @option{-mzarch} is specified, generate code using the
|
||||
instructions available on z/Architecture.
|
||||
When @option{-mesa} is specified, generate code using the
|
||||
instructions available on ESA/390. Note that @option{-mesa} is
|
||||
instructions available on ESA/390. Note that @option{-mesa} is
|
||||
not possible with @option{-m64}.
|
||||
When generating code compliant to the GNU/Linux for S/390 ABI,
|
||||
the default is @option{-mesa}. When generating code compliant
|
||||
|
@ -10903,7 +10903,7 @@ The default is to not print debug information.
|
|||
@item -march=@var{cpu-type}
|
||||
@opindex march
|
||||
Generate code that will run on @var{cpu-type}, which is the name of a system
|
||||
representing a certain processor type. Possible values for
|
||||
representing a certain processor type. Possible values for
|
||||
@var{cpu-type} are @samp{g5}, @samp{g6}, @samp{z900}, and @samp{z990}.
|
||||
When generating code using the instructions available on z/Architecture,
|
||||
the default is @option{-march=z900}. Otherwise, the default is
|
||||
|
@ -10922,7 +10922,7 @@ The default is the value used for @option{-march}.
|
|||
@opindex mno-tpf-trace
|
||||
Generate code that adds (does not add) in TPF OS specific branches to trace
|
||||
routines in the operating system. This option is off by default, even
|
||||
when compiling for the TPF OS.
|
||||
when compiling for the TPF OS@.
|
||||
|
||||
@item -mfused-madd
|
||||
@itemx -mno-fused-madd
|
||||
|
@ -11251,9 +11251,9 @@ With @option{-mcpu=sparclite}, GCC generates code for the SPARClite variant of
|
|||
the SPARC architecture. This adds the integer multiply, integer divide step
|
||||
and scan (@code{ffs}) instructions which exist in SPARClite but not in SPARC-V7.
|
||||
With @option{-mcpu=f930}, the compiler additionally optimizes it for the
|
||||
Fujitsu MB86930 chip, which is the original SPARClite, with no FPU. With
|
||||
Fujitsu MB86930 chip, which is the original SPARClite, with no FPU@. With
|
||||
@option{-mcpu=f934}, the compiler additionally optimizes it for the Fujitsu
|
||||
MB86934 chip, which is the more recent SPARClite with FPU.
|
||||
MB86934 chip, which is the more recent SPARClite with FPU@.
|
||||
|
||||
With @option{-mcpu=sparclet}, GCC generates code for the SPARClet variant of
|
||||
the SPARC architecture. This adds the integer multiply, multiply/accumulate,
|
||||
|
@ -11286,7 +11286,7 @@ that select a particular cpu implementation. Those are @samp{cypress},
|
|||
@itemx -mno-v8plus
|
||||
@opindex mv8plus
|
||||
@opindex mno-v8plus
|
||||
With @option{-mv8plus}, GCC generates code for the SPARC-V8+ ABI. The
|
||||
With @option{-mv8plus}, GCC generates code for the SPARC-V8+ ABI@. The
|
||||
difference from the V8 ABI is that the global and out registers are
|
||||
considered 64-bit wide. This is enabled by default on Solaris in 32-bit
|
||||
mode for all SPARC-V9 processors.
|
||||
|
@ -11305,7 +11305,7 @@ on SPARC-V9 processors in 64-bit environments:
|
|||
@table @gcctabopt
|
||||
@item -mlittle-endian
|
||||
@opindex mlittle-endian
|
||||
Generate code for a processor running in little-endian mode. It is only
|
||||
Generate code for a processor running in little-endian mode. It is only
|
||||
available for a few configurations and most notably not on Solaris.
|
||||
|
||||
@item -m32
|
||||
|
@ -11643,7 +11643,7 @@ this option is used.
|
|||
|
||||
@item -mv850e
|
||||
@opindex mv850e
|
||||
Specify that the target processor is the V850E. The preprocessor
|
||||
Specify that the target processor is the V850E@. The preprocessor
|
||||
constant @samp{__v850e__} will be defined if this option is used.
|
||||
|
||||
If neither @option{-mv850} nor @option{-mv850e} nor @option{-mv850e1}
|
||||
|
@ -11993,7 +11993,7 @@ position-independent.
|
|||
If supported for the target machine, emit position-independent code,
|
||||
suitable for dynamic linking and avoiding any limit on the size of the
|
||||
global offset table. This option makes a difference on the m68k
|
||||
and the SPARC.
|
||||
and the SPARC@.
|
||||
|
||||
Position-independent code requires special support, and therefore works
|
||||
only on certain machines.
|
||||
|
@ -12054,7 +12054,7 @@ three-way choice.
|
|||
@item -fpack-struct[=@var{n}]
|
||||
@opindex fpack-struct
|
||||
Without a value specified, pack all structure members together without
|
||||
holes. When a value is specified (which must be a small power of two), pack
|
||||
holes. When a value is specified (which must be a small power of two), pack
|
||||
structure members according to this value, representing the maximum
|
||||
alignment (that is, objects with default alignment requirements larger than
|
||||
this will be output potentially unaligned at the next fitting location.
|
||||
|
@ -12189,7 +12189,7 @@ usage so the only other commonly used option will be @code{hidden}.
|
|||
The default if @option{-fvisibility} isn't specified is
|
||||
@code{default}, i.e., make every
|
||||
symbol public---this causes the same behavior as previous versions of
|
||||
GCC.
|
||||
GCC@.
|
||||
|
||||
A good explanation of the benefits offered by ensuring ELF
|
||||
symbols have the correct visibility is given by ``How To Write
|
||||
|
@ -12197,18 +12197,18 @@ Shared Libraries'' by Ulrich Drepper (which can be found at
|
|||
@w{@uref{http://people.redhat.com/~drepper/}})---however a superior
|
||||
solution made possible by this option to marking things hidden when
|
||||
the default is public is to make the default hidden and mark things
|
||||
public. This is the norm with DLL's on Windows and with @option{-fvisibility=hidden}
|
||||
public. This is the norm with DLL's on Windows and with @option{-fvisibility=hidden}
|
||||
and @code{__attribute__ ((visibility("default")))} instead of
|
||||
@code{__declspec(dllexport)} you get almost identical semantics with
|
||||
identical syntax. This is a great boon to those working with
|
||||
identical syntax. This is a great boon to those working with
|
||||
cross-platform projects.
|
||||
|
||||
For those adding visibility support to existing code, you may find
|
||||
@samp{#pragma GCC visibility} of use. This works by you enclosing
|
||||
@samp{#pragma GCC visibility} of use. This works by you enclosing
|
||||
the declarations you wish to set visibility for with (for example)
|
||||
@samp{#pragma GCC visibility push(hidden)} and
|
||||
@samp{#pragma GCC visibility pop}. These can be nested up to sixteen
|
||||
times. Bear in mind that symbol visibility should be viewed @strong{as
|
||||
@samp{#pragma GCC visibility pop}. These can be nested up to sixteen
|
||||
times. Bear in mind that symbol visibility should be viewed @strong{as
|
||||
part of the API interface contract} and thus all new code should
|
||||
always specify visibility when it is not the default ie; declarations
|
||||
only for use within the local DSO should @strong{always} be marked explicitly
|
||||
|
|
|
@ -17,7 +17,7 @@ integer multiply and divide on some machines, and all floating-point
|
|||
operations on other machines. @code{libgcc} also includes routines
|
||||
for exception handling, and a handful of miscellaneous operations.
|
||||
|
||||
Some of these routines can be defined in mostly machine-independent C.
|
||||
Some of these routines can be defined in mostly machine-independent C@.
|
||||
Others must be hand-written in assembly language for each processor
|
||||
that needs them.
|
||||
|
||||
|
@ -267,7 +267,7 @@ These functions return the quotient of @var{a} and @var{b}; that is,
|
|||
@deftypefnx {Runtime Function} {long double} __negtf2 (long double @var{a})
|
||||
@deftypefnx {Runtime Function} {long double} __negxf2 (long double @var{a})
|
||||
These functions return the negation of @var{a}. They simply flip the
|
||||
sign bit, so they can produce negative zero and negative NaN.
|
||||
sign bit, so they can produce negative zero and negative NaN@.
|
||||
@end deftypefn
|
||||
|
||||
@subsection Conversion functions
|
||||
|
@ -391,7 +391,7 @@ Under the hood, all of these routines are implemented as
|
|||
|
||||
@noindent
|
||||
where @var{E} is a constant chosen to give the proper behavior for
|
||||
NaN. Thus, the meaning of the return value is different for each set.
|
||||
NaN@. Thus, the meaning of the return value is different for each set.
|
||||
Do not rely on this implementation; only the semantics documented
|
||||
below are guaranteed.
|
||||
|
||||
|
|
|
@ -786,7 +786,7 @@ means exactly what
|
|||
would mean, if the machine-description reader accepted @samp{:P}
|
||||
mode suffixes. Unfortunately, it cannot, because @code{Pmode} is an
|
||||
alias for some other mode, and might vary with machine-specific
|
||||
options. @xref{Misc}.
|
||||
options. @xref{Misc}.
|
||||
@end defun
|
||||
|
||||
@defun scratch_operand
|
||||
|
@ -1826,12 +1826,12 @@ System V Release 4 small data area reference
|
|||
@table @code
|
||||
@item q
|
||||
@samp{a}, @code{b}, @code{c}, or @code{d} register for the i386.
|
||||
For x86-64 it is equivalent to @samp{r} class. (for 8-bit instructions that
|
||||
do not use upper halves)
|
||||
For x86-64 it is equivalent to @samp{r} class (for 8-bit instructions that
|
||||
do not use upper halves).
|
||||
|
||||
@item Q
|
||||
@samp{a}, @code{b}, @code{c}, or @code{d} register. (for 8-bit instructions,
|
||||
that do use upper halves)
|
||||
@samp{a}, @code{b}, @code{c}, or @code{d} register (for 8-bit instructions,
|
||||
that do use upper halves).
|
||||
|
||||
@item R
|
||||
Legacy register---equivalent to @code{r} class in i386 mode.
|
||||
|
@ -2297,7 +2297,7 @@ Floating-point register on the SPARC-V8 architecture and
|
|||
lower floating-point register on the SPARC-V9 architecture.
|
||||
|
||||
@item e
|
||||
Floating-point register. It is equivalent to @samp{f} on the
|
||||
Floating-point register. It is equivalent to @samp{f} on the
|
||||
SPARC-V8 architecture and contains both lower and upper
|
||||
floating-point registers on the SPARC-V9 architecture.
|
||||
|
||||
|
@ -2305,11 +2305,11 @@ floating-point registers on the SPARC-V9 architecture.
|
|||
Floating-point condition code register.
|
||||
|
||||
@item d
|
||||
Lower floating-point register. It is only valid on the SPARC-V9
|
||||
Lower floating-point register. It is only valid on the SPARC-V9
|
||||
architecture when the Visual Instruction Set is available.
|
||||
|
||||
@item b
|
||||
Floating-point register. It is only valid on the SPARC-V9 architecture
|
||||
Floating-point register. It is only valid on the SPARC-V9 architecture
|
||||
when the Visual Instruction Set is available.
|
||||
|
||||
@item h
|
||||
|
@ -3061,7 +3061,7 @@ generating the instruction.
|
|||
|
||||
@cindex @code{parity@var{m}2} instruction pattern
|
||||
@item @samp{parity@var{m}2}
|
||||
Store into operand 0 the parity of @var{x}, i.@:e. the number of 1-bits
|
||||
Store into operand 0 the parity of @var{x}, i.e.@: the number of 1-bits
|
||||
in @var{x} modulo 2. @var{m} is the mode of operand 0; operand 1's mode
|
||||
is specified by the instruction pattern, and the compiler will convert
|
||||
the operand to that mode before generating the instruction.
|
||||
|
@ -4764,7 +4764,7 @@ having to ensure the two patterns' templates match.
|
|||
@findex include
|
||||
The @code{include} pattern tells the compiler tools where to
|
||||
look for patterns that are in files other than in the file
|
||||
@file{.md}. This is used only at build time and there is no preprocessing allowed.
|
||||
@file{.md}. This is used only at build time and there is no preprocessing allowed.
|
||||
|
||||
It looks like:
|
||||
|
||||
|
@ -4783,7 +4783,7 @@ For example:
|
|||
@end smallexample
|
||||
|
||||
Where @var{pathname} is a string that specifies the location of the file,
|
||||
specifies the include file to be in @file{gcc/config/target/filestuff}. The
|
||||
specifies the include file to be in @file{gcc/config/target/filestuff}. The
|
||||
directory @file{gcc/config/target} is regarded as the default directory.
|
||||
|
||||
|
||||
|
|
|
@ -68,7 +68,7 @@ invoked when (1) it is certain that the function is used, (2)
|
|||
warning flags specified by the user require some amount of
|
||||
compilation in order to honor, (3) the language indicates that
|
||||
semantic analysis is not complete until gimplification occurs.
|
||||
Hum... this sounds overly complicated. Perhaps we should just
|
||||
Hum@dots{} this sounds overly complicated. Perhaps we should just
|
||||
have the front end gimplify always; in most cases it's only one
|
||||
function call.
|
||||
|
||||
|
@ -135,7 +135,7 @@ The callback should examine the expression in question and return
|
|||
@code{GS_UNHANDLED} if the expression is not a language specific
|
||||
construct that requires attention. Otherwise it should alter the
|
||||
expression in some way to such that forward progress is made toward
|
||||
producing valid GIMPLE. If the callback is certain that the
|
||||
producing valid GIMPLE@. If the callback is certain that the
|
||||
transformation is complete and the expression is valid GIMPLE, it
|
||||
should return @code{GS_ALL_DONE}. Otherwise it should return
|
||||
@code{GS_OK}, which will cause the expression to be processed again.
|
||||
|
@ -293,7 +293,7 @@ seeing if the result can be simplified. It is located in
|
|||
@item Copy Renaming
|
||||
|
||||
This pass attempts to change the name of compiler temporaries involved in
|
||||
copy operations such that SSA->normal can coalesce the copy away. When compiler
|
||||
copy operations such that SSA->normal can coalesce the copy away. When compiler
|
||||
temporaries are copies of user variables, it also renames the compiler
|
||||
temporary to the user variable resulting in better use of user symbols. It is
|
||||
located in @file{tree-ssa-copyrename.c} and is described by
|
||||
|
@ -396,10 +396,10 @@ The optimizations also use various utility functions contained in
|
|||
|
||||
This pass applies if-conversion to simple loops to help vectorizer.
|
||||
We identify if convertable loops, if-convert statements and merge
|
||||
basic blocks in one big block. The idea is to present loop in such
|
||||
basic blocks in one big block. The idea is to present loop in such
|
||||
form so that vectorizer can have one to one mapping between statements
|
||||
and available vector operations. This patch re-introduces COND_EXPR
|
||||
at GIMPLE level. This pass is located in @file{tree-if-conv.c}.
|
||||
and available vector operations. This patch re-introduces COND_EXPR
|
||||
at GIMPLE level. This pass is located in @file{tree-if-conv.c}.
|
||||
|
||||
@item Conditional constant propagation
|
||||
|
||||
|
@ -437,7 +437,7 @@ in @file{tree-ssa-dce.c} and is described by @code{pass_cd_dce}.
|
|||
This pass identifies function calls that may be rewritten into
|
||||
jumps. No code transformation is actually applied here, but the
|
||||
data and control flow problem is solved. The code transformation
|
||||
requires target support, and so is delayed until RTL. In the
|
||||
requires target support, and so is delayed until RTL@. In the
|
||||
meantime @code{CALL_EXPR_TAILCALL} is set indicating the possibility.
|
||||
The pass is located in @file{tree-tailcall.c} and is described by
|
||||
@code{pass_tail_calls}. The RTL transformation is handled by
|
||||
|
@ -468,7 +468,7 @@ is described by @code{pass_mudflap_2}.
|
|||
|
||||
This pass rewrites the function such that it is in normal form. At
|
||||
the same time, we eliminate as many single-use temporaries as possible,
|
||||
so the intermediate language is no longer GIMPLE, but GENERIC. The
|
||||
so the intermediate language is no longer GIMPLE, but GENERIC@. The
|
||||
pass is located in @file{tree-ssa.c} and is described by @code{pass_del_ssa}.
|
||||
@end itemize
|
||||
|
||||
|
@ -555,7 +555,7 @@ This pass is seriously out-of-date and is supposed to be replaced by
|
|||
a new one described below in near future.
|
||||
|
||||
A second loop optimization pass takes care of basic block level
|
||||
optimizations---unrolling, peeling and unswitching loops. The source
|
||||
optimizations---unrolling, peeling and unswitching loops. The source
|
||||
files are @file{cfgloopanal.c} and @file{cfgloopmanip.c} containing
|
||||
generic loop analysis and manipulation code, @file{loop-init.c} with
|
||||
initialization and finalization code, @file{loop-unswitch.c} for loop
|
||||
|
|
|
@ -11,7 +11,7 @@
|
|||
GCC itself aims to be portable to any machine where @code{int} is at least
|
||||
a 32-bit type. It aims to target machines with a flat (non-segmented) byte
|
||||
addressed data address space (the code address space can be separate).
|
||||
Target ABIs may have 8, 16, 32 or 64-bit @code{int} type. @code{char}
|
||||
Target ABIs may have 8, 16, 32 or 64-bit @code{int} type. @code{char}
|
||||
can be wider than 8 bits.
|
||||
|
||||
GCC gets most of the information about the target machine from a machine
|
||||
|
|
|
@ -72,9 +72,9 @@ commonly found inside @code{symbol_ref} expressions, but they appear in
|
|||
other contexts in the RTL expressions that make up machine descriptions.
|
||||
|
||||
In a machine description, strings are normally written with double
|
||||
quotes, as you would in C. However, strings in machine descriptions may
|
||||
quotes, as you would in C@. However, strings in machine descriptions may
|
||||
extend over many lines, which is invalid C, and adjacent string
|
||||
constants are not concatenated as they are in C. Any string constant
|
||||
constants are not concatenated as they are in C@. Any string constant
|
||||
may be surrounded with a single set of parentheses. Sometimes this
|
||||
makes the machine description easier to read.
|
||||
|
||||
|
@ -534,7 +534,7 @@ Stored in the @code{unchanging} field and printed as @samp{/u}.
|
|||
@item INSN_ANNULLED_BRANCH_P (@var{x})
|
||||
In a @code{jump_insn}, @code{call_insn}, or @code{insn} indicates
|
||||
that the branch is an annulling one. See the discussion under
|
||||
@code{sequence} below. Stored in the @code{unchanging} field and
|
||||
@code{sequence} below. Stored in the @code{unchanging} field and
|
||||
printed as @samp{/u}.
|
||||
|
||||
@findex INSN_DEAD_CODE_P
|
||||
|
@ -808,7 +808,7 @@ the value. Use @code{SUBREG_PROMOTED_UNSIGNED_SET} to change the value.
|
|||
Set the @code{unchanging} and @code{volatil} fields in a @code{subreg}
|
||||
to reflect zero, sign, or other extension. If @code{volatil} is
|
||||
zero, then @code{unchanging} as nonzero means zero extension and as
|
||||
zero means sign extension. If @code{volatil} is nonzero then some
|
||||
zero means sign extension. If @code{volatil} is nonzero then some
|
||||
other type of extension was done via the @code{ptr_extend} instruction.
|
||||
|
||||
@findex SUBREG_PROMOTED_VAR_P
|
||||
|
|
|
@ -128,7 +128,7 @@ Subdirectories for various languages. Directories containing a file
|
|||
the subdirectories @file{cp} (for C++), @file{objc} (for Objective-C)
|
||||
and @file{objcp} (for Objective-C++) are documented in this manual
|
||||
(@pxref{Passes, , Passes and Files of the Compiler}); those for other
|
||||
languages are not. @xref{Front End, , Anatomy of a Language Front End},
|
||||
languages are not. @xref{Front End, , Anatomy of a Language Front End},
|
||||
for details of the files in these directories.
|
||||
|
||||
@item config
|
||||
|
@ -631,7 +631,7 @@ anything.
|
|||
@itemx distclean
|
||||
@itemx maintainer-clean
|
||||
The language parts of the standard GNU
|
||||
@samp{*clean} targets. @xref{Standard Targets, , Standard Targets for
|
||||
@samp{*clean} targets. @xref{Standard Targets, , Standard Targets for
|
||||
Users, standards, GNU Coding Standards}, for details of the standard
|
||||
targets. For GCC, @code{maintainer-clean} should delete
|
||||
all generated files in the source directory that are not checked into
|
||||
|
@ -713,7 +713,7 @@ everything from the single @file{gcc/Makefile} is preferred.
|
|||
If defined, a space-separated list of files that should be scanned by
|
||||
gengtype.c to generate the garbage collection tables and routines for
|
||||
this language. This excludes the files that are common to all front
|
||||
ends. @xref{Type Information}.
|
||||
ends. @xref{Type Information}.
|
||||
@item need_gmp
|
||||
If defined to @samp{yes}, this frontend requires the GMP library.
|
||||
Enables configure tests for GMP, which set @code{GMPLIBS} and
|
||||
|
@ -911,18 +911,18 @@ testsuite, publicly available at
|
|||
These tests are integrated in the GCC testsuite in the
|
||||
@file{gcc/testsuite/ada/acats} directory, and
|
||||
enabled automatically when running @code{make check}, assuming
|
||||
the Ada language has been enabled when configuring GCC.
|
||||
the Ada language has been enabled when configuring GCC@.
|
||||
|
||||
You can also run the Ada testsuite independently, using
|
||||
@code{make check-ada}, or run a subset of the tests by specifying which
|
||||
chapter to run, e.g:
|
||||
chapter to run, e.g.:
|
||||
|
||||
@smallexample
|
||||
$ make check-ada CHAPTERS="c3 c9"
|
||||
@end smallexample
|
||||
|
||||
The tests are organized by directory, each directory corresponding to
|
||||
a chapter of the Ada Reference Manual. So for example, c9 corresponds
|
||||
a chapter of the Ada Reference Manual. So for example, c9 corresponds
|
||||
to chapter 9, which deals with tasking features of the language.
|
||||
|
||||
There is also an extra chapter called @file{gcc} containing a template for
|
||||
|
|
|
@ -179,8 +179,8 @@ have additional useful information.
|
|||
|
||||
@cindex treelang
|
||||
There is no standard for treelang, which is a sample language front end
|
||||
for GCC. Its only purpose is as a sample for people wishing to write a
|
||||
new language for GCC. The language is documented in
|
||||
for GCC@. Its only purpose is as a sample for people wishing to write a
|
||||
new language for GCC@. The language is documented in
|
||||
@file{gcc/treelang/treelang.texi} which can be turned into info or
|
||||
HTML format.
|
||||
|
||||
|
|
|
@ -781,7 +781,7 @@ for that option, but it will not count as an undocumented option. The
|
|||
actual option name is made by appending @samp{-m} to the specified name.
|
||||
Non-empty description strings should be marked with @code{N_(@dots{})} for
|
||||
@command{xgettext}. Please do not mark empty strings because the empty
|
||||
string is reserved by GNU gettext. @code{gettext("")} returns the header entry
|
||||
string is reserved by GNU gettext. @code{gettext("")} returns the header entry
|
||||
of the message catalog with meta information, not the empty string.
|
||||
|
||||
In addition to the description for @option{--help},
|
||||
|
@ -814,7 +814,7 @@ Each subgrouping contains a string constant, that defines the option
|
|||
name, the address of a variable, a description string, and a value.
|
||||
Non-empty description strings should be marked with @code{N_(@dots{})}
|
||||
for @command{xgettext}. Please do not mark empty strings because the
|
||||
empty string is reserved by GNU gettext. @code{gettext("")} returns the
|
||||
empty string is reserved by GNU gettext. @code{gettext("")} returns the
|
||||
header entry of the message catalog with meta information, not the empty
|
||||
string.
|
||||
|
||||
|
@ -980,7 +980,7 @@ target to perform any target specific initialization of the
|
|||
@code{struct function} structure. It is intended that this would be
|
||||
used to initialize the @code{machine} of that structure.
|
||||
|
||||
@code{struct machine_function} structures are expected to be freed by GC.
|
||||
@code{struct machine_function} structures are expected to be freed by GC@.
|
||||
Generally, any memory that they reference must be allocated by using
|
||||
@code{ggc_alloc}, including the structure itself.
|
||||
@end deftypevar
|
||||
|
@ -1538,12 +1538,12 @@ When a bit-field is inserted into a packed record, the whole size
|
|||
of the underlying type is used by one or more same-size adjacent
|
||||
bit-fields (that is, if its long:3, 32 bits is used in the record,
|
||||
and any additional adjacent long bit-fields are packed into the same
|
||||
chunk of 32 bits. However, if the size changes, a new field of that
|
||||
size is allocated). In an unpacked record, this is the same as using
|
||||
chunk of 32 bits. However, if the size changes, a new field of that
|
||||
size is allocated). In an unpacked record, this is the same as using
|
||||
alignment, but not equivalent when packing.
|
||||
|
||||
If both MS bit-fields and @samp{__attribute__((packed))} are used,
|
||||
the latter will take precedence. If @samp{__attribute__((packed))} is
|
||||
the latter will take precedence. If @samp{__attribute__((packed))} is
|
||||
used on a single field when MS bit-fields are in use, it will take
|
||||
precedence for that field, but the alignment of the rest of the structure
|
||||
may affect its placement.
|
||||
|
@ -1604,7 +1604,7 @@ target machine. If you don't define this, the default is one word.
|
|||
|
||||
@defmac ADA_LONG_TYPE_SIZE
|
||||
On some machines, the size used for the Ada equivalent of the type
|
||||
@code{long} by a native Ada compiler differs from that used by C. In
|
||||
@code{long} by a native Ada compiler differs from that used by C@. In
|
||||
that situation, define this macro to be a C expression to be used for
|
||||
the size of that type. If you don't define this, the default is the
|
||||
value of @code{LONG_TYPE_SIZE}.
|
||||
|
@ -5560,7 +5560,7 @@ necessary. Traditionally, the default costs are @code{COSTS_N_INSNS (5)}
|
|||
for multiplications, @code{COSTS_N_INSNS (7)} for division and modulus
|
||||
operations, and @code{COSTS_N_INSNS (1)} for all other operations.
|
||||
|
||||
When optimizing for code size, i.e@. when @code{optimize_size} is
|
||||
When optimizing for code size, i.e.@: when @code{optimize_size} is
|
||||
nonzero, this target hook should be used to estimate the relative
|
||||
size cost of an expression, again relative to @code{COSTS_N_INSNS}.
|
||||
|
||||
|
@ -5728,7 +5728,7 @@ This hook is executed by the scheduler after function level initializations.
|
|||
@end deftypefn
|
||||
|
||||
@deftypefn {Target Hook} void TARGET_SCHED_FINISH_GLOBAL (FILE *@var{file}, int @var{verbose})
|
||||
This is the cleanup hook corresponding to TARGET_SCHED_INIT_GLOBAL.
|
||||
This is the cleanup hook corresponding to @code{TARGET_SCHED_INIT_GLOBAL}.
|
||||
@var{file} is either a null pointer, or a stdio stream to write any debug output to.
|
||||
@var{verbose} is the verbose level provided by @option{-fsched-verbose-@var{n}}.
|
||||
@end deftypefn
|
||||
|
@ -6911,7 +6911,7 @@ should be excluded; on many systems, the letter @samp{L} at the
|
|||
beginning of a label has this effect. You should find out what
|
||||
convention your system uses, and follow it.
|
||||
|
||||
The default version of this function utilizes ASM_GENERATE_INTERNAL_LABEL.
|
||||
The default version of this function utilizes @code{ASM_GENERATE_INTERNAL_LABEL}.
|
||||
@end deftypefn
|
||||
|
||||
@defmac ASM_OUTPUT_DEBUG_LABEL (@var{stream}, @var{prefix}, @var{num})
|
||||
|
@ -7571,13 +7571,13 @@ the jump-table.
|
|||
@end defmac
|
||||
|
||||
@deftypefn {Target Hook} void TARGET_ASM_EMIT_UNWIND_LABEL (@var{stream}, @var{decl}, @var{for_eh}, @var{empty})
|
||||
This target hook emits a label at the beginning of each FDE. It
|
||||
This target hook emits a label at the beginning of each FDE@. It
|
||||
should be defined on targets where FDEs need special labels, and it
|
||||
should write the appropriate label, for the FDE associated with the
|
||||
function declaration @var{decl}, to the stdio stream @var{stream}.
|
||||
The third argument, @var{for_eh}, is a boolean: true if this is for an
|
||||
exception table. The fourth argument, @var{empty}, is a boolean:
|
||||
true if this is a placeholder label for an omitted FDE.
|
||||
true if this is a placeholder label for an omitted FDE@.
|
||||
|
||||
The default is that FDEs are not given nonlocal labels.
|
||||
@end deftypefn
|
||||
|
@ -8031,7 +8031,7 @@ output an @code{N_FUN} entry for the function @var{decl}.
|
|||
@defmac DBX_OUTPUT_SOURCE_LINE (@var{stream}, @var{line}, @var{counter})
|
||||
A C statement to output DBX debugging information before code for line
|
||||
number @var{line} of the current source file to the stdio stream
|
||||
@var{stream}. @var{counter} is the number of time the macro was
|
||||
@var{stream}. @var{counter} is the number of time the macro was
|
||||
invoked, including the current invocation; it is intended to generate
|
||||
unique labels in the assembly output.
|
||||
|
||||
|
@ -8372,21 +8372,21 @@ be switched into prior to the execution of @var{insn}.
|
|||
|
||||
@defmac MODE_AFTER (@var{mode}, @var{insn})
|
||||
If this macro is defined, it is evaluated for every @var{insn} during
|
||||
mode switching. It determines the mode that an insn results in (if
|
||||
mode switching. It determines the mode that an insn results in (if
|
||||
different from the incoming mode).
|
||||
@end defmac
|
||||
|
||||
@defmac MODE_ENTRY (@var{entity})
|
||||
If this macro is defined, it is evaluated for every @var{entity} that needs
|
||||
mode switching. It should evaluate to an integer, which is a mode that
|
||||
@var{entity} is assumed to be switched to at function entry. If @code{MODE_ENTRY}
|
||||
mode switching. It should evaluate to an integer, which is a mode that
|
||||
@var{entity} is assumed to be switched to at function entry. If @code{MODE_ENTRY}
|
||||
is defined then @code{MODE_EXIT} must be defined.
|
||||
@end defmac
|
||||
|
||||
@defmac MODE_EXIT (@var{entity})
|
||||
If this macro is defined, it is evaluated for every @var{entity} that needs
|
||||
mode switching. It should evaluate to an integer, which is a mode that
|
||||
@var{entity} is assumed to be switched to at function exit. If @code{MODE_EXIT}
|
||||
mode switching. It should evaluate to an integer, which is a mode that
|
||||
@var{entity} is assumed to be switched to at function exit. If @code{MODE_EXIT}
|
||||
is defined then @code{MODE_ENTRY} must be defined.
|
||||
@end defmac
|
||||
|
||||
|
@ -8522,7 +8522,7 @@ be preserved even if it does not appear that the register is used again
|
|||
later in the function.
|
||||
|
||||
Another note: according to the MIPS spec, coprocessor 1 (if present) is
|
||||
the FPU. One accesses COP1 registers through standard mips
|
||||
the FPU@. One accesses COP1 registers through standard mips
|
||||
floating-point support; they are not included in this mechanism.
|
||||
|
||||
There is one macro used in defining the MIPS coprocessor interface which
|
||||
|
@ -8582,7 +8582,7 @@ This hook returns the size of the cookie to use when allocating an array
|
|||
whose elements have the indicated @var{type}. Assumes that it is already
|
||||
known that a cookie is needed. The default is
|
||||
@code{max(sizeof (size_t), alignof(type))}, as defined in section 2.7 of the
|
||||
IA64/Generic C++ ABI.
|
||||
IA64/Generic C++ ABI@.
|
||||
@end deftypefn
|
||||
|
||||
@deftypefn {Target Hook} bool TARGET_CXX_COOKIE_HAS_SIZE (void)
|
||||
|
@ -9000,7 +9000,7 @@ Note that regardless of this macro the ``definedness'' of @code{clz}
|
|||
and @code{ctz} at zero do @emph{not} extend to the builtin functions
|
||||
visible to the user. Thus one may be free to adjust the value at will
|
||||
to match the target expansion of these operations without fear of
|
||||
breaking the API.
|
||||
breaking the API@.
|
||||
@end defmac
|
||||
|
||||
@defmac Pmode
|
||||
|
@ -9113,11 +9113,11 @@ When a bit-field is inserted into a packed record, the whole size
|
|||
of the underlying type is used by one or more same-size adjacent
|
||||
bit-fields (that is, if its long:3, 32 bits is used in the record,
|
||||
and any additional adjacent long bit-fields are packed into the same
|
||||
chunk of 32 bits. However, if the size changes, a new field of that
|
||||
chunk of 32 bits. However, if the size changes, a new field of that
|
||||
size is allocated).
|
||||
|
||||
If both MS bit-fields and @samp{__attribute__((packed))} are used,
|
||||
the latter will take precedence. If @samp{__attribute__((packed))} is
|
||||
the latter will take precedence. If @samp{__attribute__((packed))} is
|
||||
used on a single field when MS bit-fields are in use, it will take
|
||||
precedence for that field, but the alignment of the rest of the structure
|
||||
may affect its placement.
|
||||
|
@ -9477,7 +9477,7 @@ that are different from @option{-I}.
|
|||
@deftypefn {Target Hook} bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree @var{fndecl})
|
||||
This target hook returns @code{true} if it is safe to use a local alias
|
||||
for a virtual function @var{fndecl} when constructing thunks,
|
||||
@code{false} otherwise. By default, the hook returns @code{true} for all
|
||||
@code{false} otherwise. By default, the hook returns @code{true} for all
|
||||
functions, if a target supports aliases (i.e.@: defines
|
||||
@code{ASM_OUTPUT_DEF}), @code{false} otherwise,
|
||||
@end deftypefn
|
||||
|
|
|
@ -23,7 +23,7 @@ GIMPLE and RTL are used to optimize the program. GIMPLE is used for
|
|||
target and language independent optimizations (e.g., inlining,
|
||||
constant propagation, tail call elimination, redundancy elimination,
|
||||
etc). Much like GENERIC, GIMPLE is a language independent, tree based
|
||||
representation. However, it differs from GENERIC in that the GIMPLE
|
||||
representation. However, it differs from GENERIC in that the GIMPLE
|
||||
grammar is more restrictive: expressions contain no more than 3
|
||||
operands (except function calls), it has no control flow structures
|
||||
and expressions with side-effects are only allowed on the right hand
|
||||
|
@ -53,10 +53,10 @@ The purpose of GENERIC is simply to provide a language-independent way of
|
|||
representing an entire function in trees. To this end, it was necessary to
|
||||
add a few new tree codes to the back end, but most everything was already
|
||||
there. If you can express it with the codes in @code{gcc/tree.def}, it's
|
||||
GENERIC.
|
||||
GENERIC@.
|
||||
|
||||
Early on, there was a great deal of debate about how to think about
|
||||
statements in a tree IL. In GENERIC, a statement is defined as any
|
||||
statements in a tree IL@. In GENERIC, a statement is defined as any
|
||||
expression whose value, if any, is ignored. A statement will always
|
||||
have @code{TREE_SIDE_EFFECTS} set (or it will be discarded), but a
|
||||
non-statement expression may also have side effects. A
|
||||
|
@ -72,10 +72,10 @@ off to @code{tree_rest_of_compilation}, but this seems inelegant.
|
|||
If necessary, a front end can use some language-dependent tree codes
|
||||
in its GENERIC representation, so long as it provides a hook for
|
||||
converting them to GIMPLE and doesn't expect them to work with any
|
||||
(hypothetical) optimizers that run before the conversion to GIMPLE.
|
||||
(hypothetical) optimizers that run before the conversion to GIMPLE@.
|
||||
The intermediate representation used while parsing C and C++ looks
|
||||
very little like GENERIC, but the C and C++ gimplifier hooks are
|
||||
perfectly happy to take it as input and spit out GIMPLE.
|
||||
perfectly happy to take it as input and spit out GIMPLE@.
|
||||
|
||||
@node GIMPLE
|
||||
@section GIMPLE
|
||||
|
@ -129,14 +129,14 @@ The tree representation of a function is stored in
|
|||
If a front end wants to include language-specific tree codes in the tree
|
||||
representation which it provides to the back end, it must provide a
|
||||
definition of @code{LANG_HOOKS_GIMPLIFY_EXPR} which knows how to
|
||||
convert the front end trees to GIMPLE. Usually such a hook will involve
|
||||
much of the same code for expanding front end trees to RTL. This function
|
||||
convert the front end trees to GIMPLE@. Usually such a hook will involve
|
||||
much of the same code for expanding front end trees to RTL@. This function
|
||||
can return fully lowered GIMPLE, or it can return GENERIC trees and let the
|
||||
main gimplifier lower them the rest of the way; this is often simpler.
|
||||
|
||||
The C and C++ front ends currently convert directly from front end
|
||||
trees to GIMPLE, and hand that off to the back end rather than first
|
||||
converting to GENERIC. Their gimplifier hooks know about all the
|
||||
converting to GENERIC@. Their gimplifier hooks know about all the
|
||||
@code{_STMT} nodes and how to convert them to GENERIC forms. There
|
||||
was some work done on a genericization pass which would run first, but
|
||||
the existence of @code{STMT_EXPR} meant that in order to convert all
|
||||
|
@ -144,7 +144,7 @@ of the C statements into GENERIC equivalents would involve walking the
|
|||
entire tree anyway, so it was simpler to lower all the way. This
|
||||
might change in the future if someone writes an optimization pass
|
||||
which would work better with higher-level trees, but currently the
|
||||
optimizers all expect GIMPLE.
|
||||
optimizers all expect GIMPLE@.
|
||||
|
||||
A front end which wants to use the tree optimizers (and already has
|
||||
some sort of whole-function tree representation) only needs to provide
|
||||
|
@ -293,8 +293,8 @@ Most statements will be assignment statements, represented by
|
|||
@code{MODIFY_EXPR}. A @code{CALL_EXPR} whose value is ignored can
|
||||
also be a statement. No other C expressions can appear at statement level;
|
||||
a reference to a volatile object is converted into a @code{MODIFY_EXPR}.
|
||||
In GIMPLE form, type of @code{MODIFY_EXPR} is not meaningful. Instead, use type
|
||||
of LHS or RHS.
|
||||
In GIMPLE form, type of @code{MODIFY_EXPR} is not meaningful. Instead, use type
|
||||
of LHS or RHS@.
|
||||
|
||||
There are also several varieties of complex statements.
|
||||
|
||||
|
@ -337,7 +337,7 @@ syntactic blocks in the source code, since several C++ constructs have
|
|||
implicit scopes associated with them. On the other hand, although the C++
|
||||
front end uses pseudo-scopes to handle cleanups for objects with
|
||||
destructors, these don't translate into the GIMPLE form; multiple
|
||||
declarations at the same level use the same BIND_EXPR.
|
||||
declarations at the same level use the same @code{BIND_EXPR}.
|
||||
|
||||
@node Statement Sequences
|
||||
@subsubsection Statement Sequences
|
||||
|
@ -752,12 +752,12 @@ variable @code{a}. Real definition are also known as @dfn{killing
|
|||
definitions}. Similarly, the use of @code{a} reads all its bits.
|
||||
|
||||
In contrast, virtual operands are used with variables that can have
|
||||
a partial or ambiguous reference. This includes structures, arrays,
|
||||
globals, and aliased variables. In these cases, we have two types of
|
||||
definitions. For globals, structures, and arrays, we can determine from
|
||||
a partial or ambiguous reference. This includes structures, arrays,
|
||||
globals, and aliased variables. In these cases, we have two types of
|
||||
definitions. For globals, structures, and arrays, we can determine from
|
||||
a statement whether a variable of these types has a killing definition.
|
||||
If the variable does, then the statement is marked as having a
|
||||
@dfn{must definition} of that variable. However, if a statement is only
|
||||
@dfn{must definition} of that variable. However, if a statement is only
|
||||
defining a part of the variable (i.e.@: a field in a structure), or if we
|
||||
know that a statement might define the variable but we cannot say for sure,
|
||||
then we mark that statement as having a @dfn{may definition}. For
|
||||
|
@ -815,7 +815,7 @@ incorrect assumptions about them.
|
|||
Operands are collected by @file{tree-ssa-operands.c}. They are stored
|
||||
inside each statement's annotation and can be accessed with
|
||||
@code{DEF_OPS}, @code{USE_OPS}, @code{V_MAY_DEF_OPS},
|
||||
@code{V_MUST_DEF_OPS} and @code{VUSE_OPS}. The following are all the
|
||||
@code{V_MUST_DEF_OPS} and @code{VUSE_OPS}. The following are all the
|
||||
accessor macros available to access USE operands. To access all the
|
||||
other operand arrays, just change the name accordingly:
|
||||
|
||||
|
@ -964,7 +964,7 @@ So if you want to look at the use pointers for all the @code{USE} and
|
|||
|
||||
The @code{_TREE_} macro is basically the same as the @code{USE} and
|
||||
@code{DEF} macros, only with the use or def dereferenced via
|
||||
@code{USE_FROM_PTR (use_p)} and @code{DEF_FROM_PTR (def_p)}. Since we
|
||||
@code{USE_FROM_PTR (use_p)} and @code{DEF_FROM_PTR (def_p)}. Since we
|
||||
aren't using operand pointers, use and defs flags can be mixed.
|
||||
|
||||
@smallexample
|
||||
|
@ -979,10 +979,10 @@ aren't using operand pointers, use and defs flags can be mixed.
|
|||
|
||||
Note that @code{V_MAY_DEFS} are broken into 2 flags, one for the
|
||||
@code{DEF} portion (@code{SSA_OP_VMAYDEF}) and one for the USE portion
|
||||
(@code{SSA_OP_VMAYUSE}). If all you want to look at are the
|
||||
(@code{SSA_OP_VMAYUSE}). If all you want to look at are the
|
||||
@code{V_MAY_DEFS} together, there is a fourth iterator macro for this,
|
||||
which returns both a def_operand_p and a use_operand_p for each
|
||||
@code{V_MAY_DEF} in the statement. Note that you don't need any flags for
|
||||
@code{V_MAY_DEF} in the statement. Note that you don't need any flags for
|
||||
this one.
|
||||
|
||||
@smallexample
|
||||
|
@ -1009,8 +1009,8 @@ documentation in @file{tree-ssa-operands.h}.
|
|||
Most of the tree optimizers rely on the data flow information provided
|
||||
by the Static Single Assignment (SSA) form. We implement the SSA form
|
||||
as described in @cite{R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and
|
||||
K. Zadeck. Efficiently Computing Static Single Assignment Form and the
|
||||
Control Dependence Graph. ACM Transactions on Programming Languages
|
||||
K. Zadeck. Efficiently Computing Static Single Assignment Form and the
|
||||
Control Dependence Graph. ACM Transactions on Programming Languages
|
||||
and Systems, 13(4):451-490, October 1991}.
|
||||
|
||||
The SSA form is based on the premise that program variables are
|
||||
|
@ -1063,7 +1063,7 @@ The following macros can be used to examine PHI nodes
|
|||
|
||||
@defmac PHI_RESULT (@var{phi})
|
||||
Returns the @code{SSA_NAME} created by PHI node @var{phi} (i.e.,
|
||||
@var{phi}'s LHS).
|
||||
@var{phi}'s LHS)@.
|
||||
@end defmac
|
||||
|
||||
@defmac PHI_NUM_ARGS (@var{phi})
|
||||
|
@ -1218,8 +1218,8 @@ the variables pointed-to by P_i (and its memory tag) also escape.
|
|||
|
||||
We have two classes of memory tags. Memory tags associated with
|
||||
the pointed-to data type of the pointers in the program. These
|
||||
tags are called ``type memory tag'' (TMT). The other class are
|
||||
those associated with SSA_NAMEs, called ``name memory tag'' (NMT).
|
||||
tags are called ``type memory tag'' (TMT)@. The other class are
|
||||
those associated with SSA_NAMEs, called ``name memory tag'' (NMT)@.
|
||||
The basic idea is that when adding operands for an INDIRECT_REF
|
||||
*P_i, we will first check whether P_i has a name tag, if it does
|
||||
we use it, because that will have more precise aliasing
|
||||
|
|
|
@ -205,7 +205,7 @@ the application linked with @file{libstdc++.a} must include the
|
|||
@option{-Wl,-brtl} flag on the link line. G++ cannot impose this
|
||||
because this option may interfere with the semantics of the user
|
||||
program and users may not always use @samp{g++} to link his or her
|
||||
application. Applications are not required to use the
|
||||
application. Applications are not required to use the
|
||||
@option{-Wl,-brtl} flag on the link line---the rest of the
|
||||
@file{libstdc++.a} library which is not dependent on the symbol
|
||||
merging semantics will continue to function correctly.
|
||||
|
@ -213,7 +213,7 @@ merging semantics will continue to function correctly.
|
|||
@item
|
||||
An application can interpose its own definition of functions for
|
||||
functions invoked by @file{libstdc++.a} with ``runtime-linking''
|
||||
enabled on AIX. To accomplish this the application must be linked
|
||||
enabled on AIX@. To accomplish this the application must be linked
|
||||
with ``runtime-linking'' option and the functions explicitly must be
|
||||
exported by the application (@option{-Wl,-brtl,-bE:exportfile}).
|
||||
|
||||
|
@ -222,9 +222,9 @@ AIX on the RS/6000 provides support (NLS) for environments outside of
|
|||
the United States. Compilers and assemblers use NLS to support
|
||||
locale-specific representations of various objects including
|
||||
floating-point numbers (@samp{.} vs @samp{,} for separating decimal
|
||||
fractions). There have been problems reported where the library linked
|
||||
fractions). There have been problems reported where the library linked
|
||||
with GCC does not produce the same floating-point formats that the
|
||||
assembler accepts. If you have this problem, set the @env{LANG}
|
||||
assembler accepts. If you have this problem, set the @env{LANG}
|
||||
environment variable to @samp{C} or @samp{En_US}.
|
||||
|
||||
@item
|
||||
|
@ -770,7 +770,7 @@ called two-stage (or dependent) name lookup. G++ implements it
|
|||
since version 3.4.
|
||||
|
||||
Two-stage name lookup sometimes leads to situations with behavior
|
||||
different from non-template codes. The most common is probably this:
|
||||
different from non-template codes. The most common is probably this:
|
||||
|
||||
@smallexample
|
||||
template <typename T> struct Base @{
|
||||
|
@ -795,7 +795,7 @@ you need to defer lookup until instantiation time, at which the base
|
|||
class is known. For this, you need to access @code{i} in a dependent
|
||||
context, by either using @code{this->i} (remember that @code{this} is of
|
||||
type @code{Derived<T>*}, so is obviously dependent), or using
|
||||
@code{Base<T>::i}. Alternatively, @code{Base<T>::i} might be brought
|
||||
@code{Base<T>::i}. Alternatively, @code{Base<T>::i} might be brought
|
||||
into scope by a @code{using}-declaration.
|
||||
|
||||
Another, similar example involves calling member functions of a base
|
||||
|
|
Loading…
Reference in New Issue