+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,
@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
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
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
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
@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.
@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
@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
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.
@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
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
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
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.
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.
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.
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.
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
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.
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
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,
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
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.
@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
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.
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
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.
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
@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
@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.
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
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.
@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
@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
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;
@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.
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
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.
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.
@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.
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
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})
@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.
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},
@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})
@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
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 @{
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
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.
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
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.
@})
@end smallexample
-@emph{Note:} This construct is only available for C.
+@emph{Note:} This construct is only available for C@.
@end deftypefn
(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.
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.
@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
@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
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
@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
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++
@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.
@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
@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
@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
@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.
@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.
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},
@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
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.
@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
@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
@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)
@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.
@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)
@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,
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}.
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
@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
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.
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
@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}.
@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
@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
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
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
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
@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.
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
@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
@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.
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
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
@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.
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
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
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.
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.
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.
<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.
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
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
<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
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:
@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
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}.
@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).
@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++
@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.
@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.
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
@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
@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
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}).
@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
@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).
@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
@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}
@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
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
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
@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
@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.
@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},
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
@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
@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}.
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
@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.
(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.
@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
@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}.
@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.
@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
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
@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
@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
@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}.
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
@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
@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
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.
@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
@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
@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
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
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.
@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
@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.
@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
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:
@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
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.
@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
@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
@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
@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
@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,
@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
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.
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
@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
@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
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,
@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.
@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
@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}
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.
@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.
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
@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
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.
@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
@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.
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
@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.
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.
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
@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.
@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:
@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.
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.
@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.
@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
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
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
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
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
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
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.
@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
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
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
@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
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
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
@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.
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},
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.
@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
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.
@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}.
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}.
@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
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})
@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
@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.
@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
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
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)
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
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.
@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
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
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
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
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
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
@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.
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
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
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:
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
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
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
@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})
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
@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.
@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}).
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
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 @{
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
projects / thirdparty / gcc.git / commitdiff
