@c -item/itemx, text after all (sub/sub)section titles, etc..
@c -consider putting the lists of options on pp 17--> etc in columns or
@c some such.
-@c -spellcheck
-@c -continuity of phrasing; ie, bit-field vs bitfield in rtl.texi
@c -overfulls. do a search for "mew" in the files, and you will see
@c overfulls that i noted but could not deal with.
@c -have to add text: beginning of chapter 8
@c
@c anything else? --mew 10feb93
+@c For consistency, use the following:
+@c - "back end" as a noun, "back-end" as an adjective.
+@c - "bit-field" not "bitfield" or "bit field" (following the C and C++
+@c standards).
+@c - "built-in" as an adjective ("built-in function"), or sometimes
+@c "built in", not "builtin" (which isn't a word).
+@c - "front end" as a noun, "front-end" as an adjective.
+@c - "GCC" for the GNU Compiler Collection, both generally
+@c and as the GNU C Compiler in the context of compiling C;
+@c "G++" for the C++ compiler; "gcc" and "g++" (lowercase),
+@c marked up with @command, for the commands for compilation when the
+@c emphasis is on those; "GNU C" and "GNU C++" for language dialects;
+@c and try to avoid the older term "GNU CC".
+
@macro gcctabopt{body}
@code{\body\}
@end macro
@c \global\normaloffset =0.75in
@c @end tex
+@c Change the font used for @def... commands, since the default
+@c proportional one used is bad for names starting __.
+@tex
+\global\setfont\defbf\ttbshape{10}{\magstep1}
+@end tex
+
@ifnottex
@dircategory Programming
@direntry
@sp 2
@center Richard M. Stallman
@sp 3
-@center Last updated 9 May 2001
+@center Last updated 22 June 2001
@sp 1
@c The version number appears five times more in this file.
* Installation:: How to configure, compile and install GCC.
* C Extensions:: GNU extensions to the C language family.
* C++ Extensions:: GNU extensions to the C++ language.
-* Objective C:: GNU Objective-C runtime features.
+* Objective-C:: GNU Objective-C runtime features.
* Gcov:: gcov: a GCC test coverage program.
* Trouble:: If you have trouble installing GCC.
* Bugs:: How, why and where to report bugs.
* Portability:: Goals of GCC's portability features.
* Interface:: Function-call interface of GCC output.
* Passes:: Order of passes, what they do, and what each file is for.
-* Trees:: The source representation used by the C and C++ front-ends.
+* Trees:: The source representation used by the C and C++ front ends.
* RTL:: The intermediate representation that most passes work on.
* Machine Desc:: How to write machine description instruction patterns.
-* Target Macros:: How to write the machine description C macros.
+* Target Macros:: How to write the machine description C macros and functions.
* Config:: Writing the @file{xm-@var{machine}.h} file.
* Fragments:: Writing the @file{t-@var{target}} and @file{x-@var{host}} files.
@end ifset
@ifset USING
@node G++ and GCC
-@chapter Compile C, C++, Objective C, Fortran, Java or CHILL
+@chapter Compile C, C++, Objective-C, Fortran, Java or CHILL
-@cindex Objective C
+@cindex Objective-C
@cindex Fortran
@cindex Java
@cindex CHILL
-Several versions of the compiler (C, C++, Objective C, Fortran, Java
+Several versions of the compiler (C, C++, Objective-C, Fortran, Java
and CHILL) are integrated; this is why we use the name
-``GNU Compiler Collection''. GCC can compile programs written in any of these
-languages. The Fortran, CHILL, and Java compilers are described in
+``GNU Compiler Collection''. GCC can compile programs written in any of these
+languages. The Fortran, CHILL, and Java compilers are described in
separate manuals.
@cindex GCC
affecting the behavior of ``GCC'' or sometimes just ``the compiler''.
Front ends for other languages, such as Ada 95 and Pascal exist but
-have not yet been integrated into GCC. These front-ends, like that for C++,
+have not yet been integrated into GCC@. These front ends, like that for C++,
are built in subdirectories of GCC and link to it. The result is an
integrated compiler that can compile programs written in C, C++,
-Objective C, or any of the languages for which you have installed front
+Objective-C, or any of the languages for which you have installed front
ends.
In this manual, we only discuss the options for the C, Objective-C, and
give you comprehensive C++ source-level editing capabilities
(@pxref{C,,C and C++,gdb.info, Debugging with GDB}).
-@c FIXME! Someone who knows something about Objective C ought to put in
+@c FIXME! Someone who knows something about Objective-C ought to put in
@c a paragraph or two about it here, and move the index entry down when
@c there is more to point to than the general mention in the 1st par.
in a hosted implementation.
@opindex ffreestanding
-GNU CC aims towards being usable as a conforming freestanding
+GCC aims towards being usable as a conforming freestanding
implementation, or as the compiler for a conforming hosted
implementation. By default, it will act as the compiler for a hosted
implementation, defining @code{__STDC_HOSTED__} as @code{1} and
linking and startup. @xref{C Dialect Options,,Options Controlling C
Dialect}.
-GNU CC does not provide the library facilities required only of hosted
+GCC does not provide the library facilities required only of hosted
implementations, nor yet all the facilities required by C99 of
freestanding implementations; to use the facilities of a hosted
environment, you will need to find them elsewhere (for example, in the
@c FIXME: details of C++ standard.
-There is no formal written standard for Objective-C. The most
+There is no formal written standard for Objective-C@. The most
authoritative manual is ``Object-Oriented Programming and the
Objective-C Language'', available at a number of web sites;
@uref{http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/} has a
information as well.
@xref{Language,,The GNU Fortran Language, g77, Using and Porting GNU
-Fortran}, for details of the Fortran language supported by GCC.
+Fortran}, for details of the Fortran language supported by GCC@.
@xref{Compatibility,,Compatibility with the Java Platform, gcj, GNU gcj},
for details of compatibility between @code{gcj} and the Java Platform.
@cindex installation trouble
@cindex known causes of trouble
-This section describes known problems that affect users of GCC. Most
+This section describes known problems that affect users of GCC@. Most
of these are not GCC bugs per se---if they were, we would fix them.
But the result for a user may be like the result of a bug.
and with certain linkers, assemblers and debuggers.
* External Bugs:: Problems compiling certain programs.
* Incompatibilities:: GCC is incompatible with traditional C.
-* Fixed Headers:: GNU C uses corrected versions of system header files.
+* Fixed Headers:: GCC uses corrected versions of system header files.
This is necessary, but doesn't always work smoothly.
-* Standard Libraries:: GNU C uses the system C library, which might not be
+* Standard Libraries:: GCC uses the system C library, which might not be
compliant with the ISO C standard.
* Disappointments:: Regrettable things we can't change, but not quite bugs.
* C++ Misunderstandings:: Common misunderstandings with GNU C++.
@node Interoperation
@section Interoperation
-This section lists various difficulties encountered in using GNU C or
-GNU C++ together with other compilers or with the assemblers, linkers,
+This section lists various difficulties encountered in using GCC
+together with other compilers or with the assemblers, linkers,
libraries and debuggers on certain systems.
@itemize @bullet
@item
-Objective C does not work on the RS/6000.
+Objective-C does not work on the RS/6000.
@item
-GNU C++ does not do name mangling in the same way as other C++
+G++ does not do name mangling in the same way as other C++
compilers. This means that object files compiled with one compiler
cannot be used with another.
@item
@cindex DBX
DBX rejects some files produced by GCC, though it accepts similar
-constructs in output from PCC. Until someone can supply a coherent
+constructs in output from PCC@. Until someone can supply a coherent
description of what is valid DBX input and what is not, there is
nothing I can do about these problems. You are on your own.
@item
-The GNU assembler (GAS) does not support PIC. To generate PIC code, you
+The GNU assembler (GAS) does not support PIC@. To generate PIC code, you
must use some other assembler, such as @file{/bin/as}.
@item
@item
On some SGI systems, when you use @option{-lgl_s} as an option,
it gets translated magically to @samp{-lgl_s -lX11_s -lc_s}.
-Naturally, this does not happen when you use GCC.
+Naturally, this does not happen when you use GCC@.
You must specify all three options explicitly.
@item
@code{double *} to a function compiled with GCC, dereferencing the
pointer may cause a fatal signal.
-One way to solve this problem is to compile your entire program with GNU
-CC. Another solution is to modify the function that is compiled with
+One way to solve this problem is to compile your entire program with GCC@.
+Another solution is to modify the function that is compiled with
Sun CC to copy the argument into a local variable; local variables
are always properly aligned. A third solution is to modify the function
that uses the pointer to dereference it via the following function
@item
On the HP PA machine, ADB sometimes fails to work on functions compiled
-with GCC. Specifically, it fails to work on functions that use
+with GCC@. Specifically, it fails to work on functions that use
@code{alloca} or variable-size arrays. This is because GCC doesn't
generate HP-UX unwind descriptors for such functions. It may even be
impossible to generate them.
will cause the linker to report an undefined symbol @code{foo}.
Although this behavior differs from most other systems, it is not a
bug because redefining an @code{extern} variable as @code{static}
-is undefined in ISO C.
+is undefined in ISO C@.
@item
AIX on the RS/6000 provides support (NLS) for environments outside of
@item
On the RS/6000, XLC version 1.3.0.0 will miscompile @file{jump.c}. XLC
version 1.3.0.1 or later fixes this problem. You can obtain XLC-1.3.0.2
-by requesting PTF 421749 from IBM.
+by requesting PTF 421749 from IBM@.
@item
@opindex mno-serialize-volatile
@smallexample
#ifndef _SIZE_T
#define _SIZE_T
-@var{actual typedef here}
+@var{actual-typedef-here}
#endif
@end smallexample
@opindex traditional
There are several noteworthy incompatibilities between GNU C and K&R
-(non-ISO) versions of C. The @option{-traditional} option
+(non-ISO) versions of C@. The @option{-traditional} option
eliminates many of these incompatibilities, @emph{but not all}, by
-telling GNU C to behave like a K&R C compiler.
+telling GCC to behave like a K&R C compiler.
@itemize @bullet
@cindex string constants
If you use the @option{-W} option with the @option{-O} option, you will
get a warning when GCC thinks such a problem might be possible.
-The @option{-traditional} option directs GNU C to put variables in
+The @option{-traditional} option directs GCC to put variables in
the stack by default, rather than in registers, in functions that
call @code{setjmp}. This results in the behavior found in
traditional C compilers.
@item
Programs that use preprocessing directives in the middle of macro
-arguments do not work with GCC. For example, a program like this
+arguments do not work with GCC@. For example, a program like this
will not work:
@example
implement.
@item
-K&R compilers allow comments to cross over an inclusion boundary (i.e.
-started in an include file and ended in the including file). I think
+K&R compilers allow comments to cross over an inclusion boundary
+(i.e.@: started in an include file and ended in the including file). I think
this would be quite ugly and can't imagine it could be needed.
@cindex external declaration scope
In some other C compilers, a @code{extern} declaration affects all the
rest of the file even if it happens within a block.
-The @option{-traditional} option directs GNU C to treat all @code{extern}
+The @option{-traditional} option directs GCC to treat all @code{extern}
declarations as global, like traditional compilers.
@item
@cindex preprocessing tokens
@cindex preprocessing numbers
@item
-GNU C complains about program fragments such as @samp{0x74ae-0x4000}
+GCC complains about program fragments such as @samp{0x74ae-0x4000}
which appear to be two hexadecimal constants separated by the minus
operator. Actually, this string is a single @dfn{preprocessing token}.
-Each such token must correspond to one token in C. Since this does not,
-GNU C prints an error message. Although it may appear obvious that what
+Each such token must correspond to one token in C@. Since this does not,
+GCC prints an error message. Although it may appear obvious that what
is meant is an operator and two values, the ISO C standard specifically
requires that this be treated as erroneous.
@item
If you update the system's header files, such as by installing a new
system version, the fixed header files of GCC are not automatically
-updated. The easiest way to update them is to reinstall GCC. (If
+updated. The easiest way to update them is to reinstall GCC@. (If
you want to be clever, look in the makefile and you can find a
shortcut.)
shown above.
@item
-Accesses to bitfields even in volatile objects works by accessing larger
+Accesses to bit-fields even in volatile objects works by accessing larger
objects, such as a byte or a word. You cannot rely on what size of
-object is accessed in order to read or write the bitfield; it may even
-vary for a given bitfield according to the precise usage.
+object is accessed in order to read or write the bit-field; it may even
+vary for a given bit-field according to the precise usage.
If you care about controlling the amount of memory that is accessed, use
-volatile but do not use bitfields.
+volatile but do not use bit-fields.
@item
GCC comes with shell scripts to fix certain known problems in system
f ()
@{
const char *p = strfunc().c_str();
- ...
+ @dots{}
charfunc (p);
- ...
+ @dots{}
charfunc (p);
@}
@end example
@subsection Implicit Copy-Assignment for Virtual Bases
When a base class is virtual, only one subobject of the base class
-belongs to each full object. Also, the constructors and destructors are
-invoked only once, and called from the most-derived class. However, such
-objects behave unspecified when being assigned. For example:
+belongs to each full object. Also, the constructors and destructors are
+invoked only once, and called from the most-derived class. However, such
+objects behave unspecified when being assigned. For example:
@example
struct Base@{
@end example
The C++ standard specifies that @samp{Base::Base} is only called once
-when constructing or copy-constructing a Derived object. It is
+when constructing or copy-constructing a Derived object. It is
unspecified whether @samp{Base::operator=} is called more than once when
the implicit copy-assignment for Derived objects is invoked (as it is
inside @samp{func} in the example).
g++ implements the ``intuitive'' algorithm for copy-assignment: assign all
-direct bases, then assign all members. In that algorithm, the virtual
-base subobject can be encountered many times. In the example, copying
+direct bases, then assign all members. In that algorithm, the virtual
+base subobject can be encountered many times. In the example, copying
proceeds in the following order: @samp{val}, @samp{name} (via
@code{strdup}), @samp{bval}, and @samp{name} again.
If application code relies on copy-assignment, a user-defined
-copy-assignment operator removes any uncertainties. With such an
+copy-assignment operator removes any uncertainties. With such an
operator, the application can define whether and how the virtual base
subobject is assigned.
you can specify a field width explicitly.
@item
-Making bitfields unsigned by default on particular machines where ``the
+Making bit-fields unsigned by default on particular machines where ``the
ABI standard'' says to do so.
-The ISO C standard leaves it up to the implementation whether a bitfield
+The ISO C standard leaves it up to the implementation whether a bit-field
declared plain @code{int} is signed or not. This in effect creates two
-alternative dialects of C.
+alternative dialects of C@.
@opindex fsigned-bitfields
@opindex funsigned-bitfields
@option{-funsigned-bitfields}. However, this leaves open the question of
which dialect to use by default.
-Currently, the preferred dialect makes plain bitfields signed, because
+Currently, the preferred dialect makes plain bit-fields signed, because
this is simplest. Since @code{int} is the same as @code{signed int} in
-every other context, it is cleanest for them to be the same in bitfields
+every other context, it is cleanest for them to be the same in bit-fields
as well.
Some computer manufacturers have published Application Binary Interface
-standards which specify that plain bitfields should be unsigned. It is
-a mistake, however, to say anything about this issue in an ABI. This is
-because the handling of plain bitfields distinguishes two dialects of C.
+standards which specify that plain bit-fields should be unsigned. It is
+a mistake, however, to say anything about this issue in an ABI@. This is
+because the handling of plain bit-fields distinguishes two dialects of C@.
Both dialects are meaningful on every type of machine. Whether a
-particular object file was compiled using signed bitfields or unsigned
+particular object file was compiled using signed bit-fields or unsigned
is of no concern to other object files, even if they access the same
-bitfields in the same data structures.
+bit-fields in the same data structures.
A given program is written in one or the other of these two dialects.
The program stands a chance to work on most any machine if it is
Many users appreciate the GNU C compiler because it provides an
environment that is uniform across machines. These users would be
-inconvenienced if the compiler treated plain bitfields differently on
+inconvenienced if the compiler treated plain bit-fields differently on
certain machines.
Occasionally users write programs intended only for a particular machine
program to run on more than one type of machine cannot possibly benefit
from this kind of compatibility.
-This is why GCC does and will treat plain bitfields in the same
+This is why GCC does and will treat plain bit-fields in the same
fashion on all types of machines (by default).
-There are some arguments for making bitfields unsigned by default on all
+There are some arguments for making bit-fields unsigned by default on all
machines. If, for example, this becomes a universal de facto standard,
it would make sense for GCC to go along with it. This is something
to be considered in the future.
(Of course, users strongly concerned about portability should indicate
-explicitly in each bitfield whether it is signed or not. In this way,
+explicitly in each bit-field whether it is signed or not. In this way,
they write programs which have the same meaning in both C dialects.)
@item
GCC normally defines @code{__STDC__} to be 1, and in addition
defines @code{__STRICT_ANSI__} if you specify the @option{-ansi} option,
-or a @option{-std} option for strict conformance to some version of ISO C.
+or a @option{-std} option for strict conformance to some version of ISO C@.
On some hosts, system include files use a different convention, where
@code{__STDC__} is normally 0, but is 1 if the user specifies strict
conformance to the C Standard. GCC follows the host convention when
They would not work otherwise.
In addition, many header files are written to provide prototypes in ISO
-C but not in traditional C. Many of these header files can work without
+C but not in traditional C@. Many of these header files can work without
change in C++ provided @code{__STDC__} is defined. If @code{__STDC__}
is not defined, they will all fail, and will all need to be changed to
test explicitly for C++ as well.
it may not. (If it does not, look in the service directory; see
@ref{Service}.) In any case, the principal function of a bug report is
to help the entire community by making the next version of GCC work
-better. Bug reports are your contribution to the maintenance of GCC.
+better. Bug reports are your contribution to the maintenance of GCC@.
Since the maintainers are very overloaded, we cannot respond to every
bug report. However, if the bug has not been fixed, we are likely to
@itemize @bullet
@item
-The version of GCC. You can get this by running it with the
+The version of GCC@. You can get this by running it with the
@option{-v} option.
Without this, we won't know whether there is any point in looking for
-the bug in the current version of GCC.
+the bug in the current version of GCC@.
@item
A complete input file that will reproduce the bug. If the bug is in the
preprocessor output generated by adding @option{-save-temps} to the
compilation command (@pxref{Debugging Options}). When you do this, use
the same @option{-I}, @option{-D} or @option{-U} options that you used in
-actual compilation. Then send the @var{input}.i or @var{input}.ii files
+actual compilation. Then send the @var{input}.i or @var{input}.ii files
generated.
A single statement is not enough of an example. In order to compile it,
@item
Details of any other deviations from the standard procedure for installing
-GCC.
+GCC@.
@item
A description of what behavior you observe that you believe is
@cindex gccbug script
To simplify creation of bug reports, and to allow better tracking of
-reports, we use the GNATS bug tracking system. Part of that system is
-the @code{gccbug} script. This is a Unix shell script, so you need a
-shell to run it. It is normally installed in the same directory where
+reports, we use the GNATS bug tracking system. Part of that system is
+the @code{gccbug} script. This is a Unix shell script, so you need a
+shell to run it. It is normally installed in the same directory where
@code{gcc} is installed.
The gccbug script is derived from send-pr, @pxref{using
-send-pr,,Creating new Problem Reports,send-pr,Reporting Problems}. When
+send-pr,,Creating new Problem Reports,send-pr,Reporting Problems}. When
invoked, it starts a text editor so you can fill out the various fields
-of the report. When the you quit the editor, the report is automatically
+of the report. When the you quit the editor, the report is automatically
send to the bug reporting address.
A number of fields in this bug report form are specific to GCC, and are
Please follow these guidelines so we can study your patches efficiently.
If you don't follow these guidelines, your information might still be
-useful, but using it will take extra work. Maintaining GNU C is a lot
+useful, but using it will take extra work. Maintaining GCC is a lot
of work in the best of circumstances, and we can't keep up unless you do
your best to help.
@chapter Using GCC on VMS
@c prevent bad page break with this line
-Here is how to use GCC on VMS.
+Here is how to use GCC on VMS@.
@menu
* Include Files and VMS:: Where the preprocessor looks for the include files.
the include file.
@item
-If the file specification is not a valid VMS filename (i.e. does not
+If the file specification is not a valid VMS filename (i.e.@: does not
contain a device or a directory specifier, and contains a @samp{/}
character), the preprocessor tries to convert it from Unix syntax to
VMS syntax.
@end example
@noindent
-are a common source of incompatibility between VAX-C and GCC. VAX-C
+are a common source of incompatibility between VAX-C and GCC@. VAX-C
treats this much like a standard @code{#include <foobar.h>} directive.
That is incompatible with the ISO C behavior implemented by GCC: to
expand the name @code{foobar} as a macro. Macro expansion should
@findex GLOBALVALUEDEF
@findex GLOBALVALUEREF
GCC does not provide the @code{globalref}, @code{globaldef} and
-@code{globalvalue} keywords of VAX-C. You can get the same effect with
+@code{globalvalue} keywords of VAX-C@. You can get the same effect with
an obscure feature of GAS, the GNU assembler. (This requires GAS
version 1.39 or later.) The following macros allow you to use this
feature in a fairly natural way:
by VMS as a status code indicating a normal successful completion.
Version 1 of GCC did not provide this default.
-GCC on VMS works only with the GNU assembler, GAS. You need version
+GCC on VMS works only with the GNU assembler, GAS@. You need version
1.37 or later of GAS in order to produce value debugging information for
the VMS debugger. Use the ordinary VMS linker with the object files
-produced by GAS.
+produced by GAS@.
@cindex shared VMS run time system
@cindex @file{VAXCRTL}
libraries (such as Xlib) which were generated by another compiler. You
can use the compiler option @samp{/NOCASE_HACK} to inhibit augmentation;
it makes external C functions and variables case-independent as is usual
-on VMS. Alternatively, you could write all references to the functions
+on VMS@. Alternatively, you could write all references to the functions
and variables in such libraries using lower case; this will work on VMS,
but is not portable to other systems. The compiler option @samp{/NAMES}
also provides control over global name handling.
-Function and variable names are handled somewhat differently with GNU
-C++. The GNU C++ compiler performs @dfn{name mangling} on function
+Function and variable names are handled somewhat differently with G++.
+The GNU C++ compiler performs @dfn{name mangling} on function
names, which means that it adds information to the function name to
describe the data types of the arguments that the function takes. One
result of this is that the name of a function can become very long.
@item bubblestrap
Once bootstrapped, this incrementally rebuilds each of the three stages,
one at a time. It does this by ``bubbling'' the stages up from their
-stubdirectories, rebuilding them, and copying them back to their
+subdirectories, rebuilding them, and copying them back to their
subdirectories. This will allow you to, for example, quickly rebuild a
bootstrapped compiler after changing the sources, without having to do a
full bootstrap.
change is practical only if you are switching to GCC as the sole C
compiler for the system. We may implement register argument passing on
certain machines once we have a complete GNU system so that we can
-compile the libraries with GCC.
+compile the libraries with GCC@.
On some machines (particularly the Sparc), certain types of arguments
are passed ``by invisible reference''. This means that the value is
they appear in @file{libgcc2.c}. Others must be hand-written in
assembly language for each processor. Wherever they are defined, they
are compiled into the support library, @file{libgcc.a}, which is
-automatically searched when you link programs with GCC.
+automatically searched when you link programs with GCC@.
@end ifset
@ifset INTERNALS
closing files, and sequencing the passes.
@cindex parsing pass
-The parsing pass is invoked only once, to parse the entire input. The RTL
-intermediate code for a function is generated as the function is parsed, a
-statement at a time. Each statement is read in as a syntax tree and then
-converted to RTL; then the storage for the tree for the statement is
-reclaimed. Storage for types (and the expressions for their sizes),
-declarations, and a representation of the binding contours and how they nest,
-remain until the function is finished being compiled; these are all needed
-to output the debugging information.
+The parsing pass is invoked only once, to parse the entire input. A
+high level tree representation is then generated from the input,
+one function at a time. This tree code is then transformed into RTL
+intermediate code, and processed. The files involved in transforming
+the trees into RTL are @file{expr.c}, @file{expmed.c}, and
+@file{stmt.c}.
+@c Note, the above files aren't strictly the only files involved. It's
+@c all over the place (function.c, final.c,etc). However, those are
+@c the files that are supposed to be directly involved, and have
+@c their purpose listed as such, so i've only listed them.
+The order of trees that are processed, is not
+necessarily the same order they are generated from
+the input, due to deferred inlining, and other considerations.
@findex rest_of_compilation
@findex rest_of_decl_compilation
within @code{rest_of_compilation}. When that function returns from
compiling a function definition, the storage used for that function
definition's compilation is entirely freed, unless it is an inline
-function
+function, or was deferred for some reason (this can occur in
+templates, for example).
@ifset USING
(@pxref{Inline,,An Inline Function is As Fast As a Macro}).
@end ifset
@itemize @bullet
@item
Parsing. This pass reads the entire text of a function definition,
-constructing partial syntax trees. This and RTL generation are no longer
-truly separate passes (formerly they were), but it is easier to think
-of them as separate.
+constructing a high level tree representation. (Because of the semantic
+analysis that takes place during this pass, it does more than is
+formally considered to be parsing.)
The tree representation does not entirely follow C syntax, because it is
intended to support other languages as well.
tree node that represents an expression has a data type attached.
Variables are represented as declaration nodes.
-@cindex constant folding
-@cindex arithmetic simplifications
-@cindex simplifications, arithmetic
-Constant folding and some arithmetic simplifications are also done
-during this pass.
-
The language-independent source files for parsing are
@file{stor-layout.c}, @file{fold-const.c}, and @file{tree.c}.
There are also header files @file{tree.h} and @file{tree.def}
-which define the format of the tree representation.@refill
+which define the format of the tree representation.
+
+C Preprocessing, for language front ends, that want or require it, is
+performed by cpplib, which is covered in seperate documentation. In
+particular, the internals are covered in @xref{Top, ,Cpplib internals, cppinternals, Cpplib Internals}.
+
@c Avoiding overfull is tricky here.
The source files to parse C are
-@file{c-parse.in},
-@file{c-decl.c},
-@file{c-typeck.c},
@file{c-aux-info.c},
@file{c-convert.c},
-and @file{c-lang.c}
-along with header files
-@file{c-lex.h}, and
-@file{c-tree.h}.
+@file{c-decl.c},
+@file{c-errors.c},
+@file{c-lang.c},
+@file{c-parse.in},
+and
+@file{c-typeck.c},
+along with a header file
+@file{c-tree.h}
+and some files shared with Objective-C and C++.
The source files for parsing C++ are in @file{cp/}.
They are @file{parse.y},
@file{except.c},@*
@file{expr.c}, @file{init.c}, @file{lex.c},
@file{method.c}, @file{ptree.c},@*
-@file{search.c}, @file{tree.c},
+@file{search.c}, @file{spew.c}, @*
+@file{semantics.c}, @file{tree.c},
@file{typeck2.c}, and
@file{typeck.c}, along with header files @file{cp-tree.def},
@file{cp-tree.h}, and @file{decl.h}.
-The special source files for parsing Objective C are in @file{objc/}.
+The special source files for parsing Objective-C are in @file{objc/}.
They are @file{objc-parse.y}, @file{objc-act.c}, @file{objc-tree.def}, and
@file{objc-act.h}. Certain C-specific files are used for this as
well.
-The file @file{c-common.c} is also used for all of the above languages.
+The files
+@file{c-common.c},
+@file{c-common.def},
+@file{c-dump.c},
+@file{c-format.c},
+@file{c-lex.c},
+@file{c-pragma.c},
+and
+@file{c-semantics.c},
+along with header files
+@file{c-common.h},
+@file{c-dump.h},
+@file{c-lex.h},
+and
+@file{c-pragma.h},
+are also used for all of the above languages.
+
+
+@cindex Tree optimization
+@item
+Tree optimization. This is the optimization of the tree
+representation, before converting into RTL code.
+
+@cindex inline on trees, automatic
+Currently, the main optimization performed here is tree-based
+inlining.
+This is implemented for C++ in @file{cp/optimize.c}. Note that
+tree based inlining turns off rtx based inlining (since it's more
+powerful, it would be a waste of time to do rtx based inlining in
+addition).
+The C front end currently does not perform tree based inlining.
+
+@cindex constant folding
+@cindex arithmetic simplifications
+@cindex simplifications, arithmetic
+Constant folding and some arithmetic simplifications are also done
+during this pass, on the tree representation.
+The routines that perform these tasks are located in @file{fold-const.c}.
@cindex RTL generation
@item
RTL generation. This is the conversion of syntax tree into RTL code.
-It is actually done statement-by-statement during parsing, but for
-most purposes it can be thought of as a separate pass.
@cindex target-parameter-dependent code
This is where the bulk of target-parameter-dependent code is found,
Also, the file
@file{insn-emit.c}, generated from the machine description by the
program @code{genemit}, is used in this pass. The header file
-@file{expr.h} is used for communication within this pass.@refill
+@file{expr.h} is used for communication within this pass.
@findex genflags
@findex gencodes
The header files @file{insn-flags.h} and @file{insn-codes.h},
generated from the machine description by the programs @code{genflags}
and @code{gencodes}, tell this pass which standard names are available
-for use and which patterns correspond to them.@refill
+for use and which patterns correspond to them.
Aside from debugging information output, none of the following passes
refers to the tree structure representation of the function (only
part of which is saved).
-@cindex inline, automatic
+@cindex inline on rtx, automatic
The decision of whether the function can and should be expanded inline
in its subsequent callers is made at the end of rtl generation. The
function must meet certain criteria, currently related to the size of
the function and the types and number of parameters it has. Note that
this function may contain loops, recursive calls to itself
(tail-recursive functions can be inlined!), gotos, in short, all
-constructs supported by GCC. The file @file{integrate.c} contains
+constructs supported by GCC@. The file @file{integrate.c} contains
the code to save a function's rtl for later inlining and to inline that
rtl when the function is called. The header file @file{integrate.h}
is also used for this purpose.
this pass. This dump file's name is made by appending @samp{.rtl} to
the input file name.
+@c Should the exception handling pass be talked about here?
+
+@cindex sibling call optimization
+@item
+Sibiling call optimization. This pass performs tail recursion
+elimination, and tail and sibling call optimizations. The purpose of
+these optimizations is to reduce the overhead of function calls,
+whenever possible.
+
+The source file of this pass is @file{sibcall.c}
+
+@opindex di
+The option @option{-di} causes a debugging dump of the RTL code after
+this pass is run. This dump file's name is made by appending
+@samp{.sibling} to the input file name.
+
@cindex jump optimization
@cindex unreachable code
@cindex dead code
@cindex constant propagation
@item
Common subexpression elimination. This pass also does constant
-propagation. Its source file is @file{cse.c}. If constant
-propagation causes conditional jumps to become unconditional or to
-become no-ops, jump optimization is run again when CSE is finished.
+propagation. Its source files are @file{cse.c}, and @file{cselib.c}.
+If constant propagation causes conditional jumps to become
+unconditional or to become no-ops, jump optimization is run again when
+CSE is finished.
@opindex ds
The option @option{-ds} causes a debugging dump of the RTL code after
this pass. This dump file's name is made by appending @samp{.cse} to
the input file name.
+@cindex SSA optimizations
+@cindex Single Static Assignment optimizations
+@opindex fssa
+@item
+Static Single Assignment (SSA) based optimization passes. The
+SSA conversion passes (to/from) are turned on by the @option{-fssa}
+option (it is also done automatically if you enable an SSA optimization pass).
+These passes utilize a form called Static Single Assignment. In SSA form,
+each variable (pseudo register) is only set once, giving you def-use
+and use-def chains for free, and enabling a lot more optimization
+passes to be run in linear time.
+Conversion to and from SSA form is handled by functions in
+@file{ssa.c}.
+
+@opindex de
+The option @option{-de} causes a debugging dump of the RTL code after
+this pass. This dump file's name is made by appending @samp{.ssa} to
+the input file name.
+@itemize @bullet
+@cindex SSA DCE
+@cindex DCE, SSA based
+@cindex dead code elimination
+@opindex fdce
+@item
+Dead Code Elimination. Turned on by the @option{-fdce} option.
+This pass performs elimination of code considered unnecessary because it
+is never executed. It operates in linear time.
+
+@opindex dX
+The option @option{-dX} causes a debugging dump of the RTL code after
+this pass. This dump file's name is made by appending @samp{.dce} to
+the input file name.
+@end itemize
@cindex global common subexpression elimination
@cindex constant propagation
@cindex copy propagation
@item
-Global common subexpression elimination. This pass performs GCSE
-using Morel-Renvoise Partial Redundancy Elimination, with the exception
-that it does not try to move invariants out of loops---that is left to
-the loop optimization pass. This pass also performs global constant
-and copy propagation.
-
-The source file for this pass is gcse.c.
+Global common subexpression elimination. This pass performs two
+different types of GCSE depending on whether you are optimizing for
+size or not (LCM based GCSE tends to increase code size for a gain in
+speed, while Morel-Renvoise based GCSE does not).
+When optimizing for size, GCSE is done using Morel-Renvoise Partial
+Redundancy Elimination, with the exception that it does not try to move
+invariants out of loops---that is left to the loop optimization pass.
+If MR PRE GCSE is done, code hoisting (aka unification) is also done, as
+well as load motion.
+If you are optimizing for speed, LCM (lazy code motion) based GCSE is
+done. LCM is based on the work of Knoop, Ruthing, and Steffen. LCM
+based GCSE also does loop invariant code motion. We also perform load
+and store motion when optimizing for speed.
+Regardless of which type of GCSE is used, the GCSE pass also performs
+global constant and copy propagation.
+
+The source file for this pass is @file{gcse.c}, and the LCM routines
+are in @file{lcm.c}.
@opindex dG
The option @option{-dG} causes a debugging dump of the RTL code after
Its source files are @file{loop.c} and @file{unroll.c}, plus the header
@file{loop.h} used for communication between them. Loop unrolling uses
some functions in @file{integrate.c} and the header @file{integrate.h}.
+Loop dependency analysis routines are contained in @file{dependence.c}.
@opindex dL
The option @option{-dL} causes a debugging dump of the RTL code after
this pass. This dump file's name is made by appending @samp{.combine}
to the input file name.
+@cindex if conversion
+@item
+If-conversion is a transformation that transforms control dependencies
+into data dependencies (IE it transforms conditional code into a
+single control stream).
+It is implemented in the file @file{ifcvt.c}.
+
+@opindex dE
+The option @option{-dE} causes a debugging dump of the RTL code after
+this pass. This dump file's name is made by appending @samp{.ce} to
+the input file name.
+
@cindex register movement
@item
-Register movement (@file{regmove.c}). This pass looks for cases where
+Register movement (@file{regmove.c}). This pass looks for cases where
matching constraints would force an instruction to need a reload, and
this reload would be a register to register move. It then attempts
to change the registers used by the instruction to avoid the move
this pass. This dump file's name is made by appending @samp{.sched2}
to the input file name.
+@cindex basic block reordering
+@cindex reordering, block
+@item
+Basic block reordering. This pass implements profile guided code
+positioning. If profile information is not available, various types of
+static analysis are performed to make the predictions normally coming
+from the profile feedback (IE execution frequency, branch probability,
+etc). It is implemented in the file @file{bb-reorder.c}, and the
+various prediction routines are in @file{predict.c}.
+
+@opindex dB
+The option @option{-dB} causes a debugging dump of the RTL code after
+this pass. This dump file's name is made by appending @samp{.bbro} to
+the input file name.
+
@cindex cross-jumping
@cindex no-op move instructions
@item
also responsible for identifying spurious test and compare
instructions. Machine-specific peephole optimizations are performed
at the same time. The function entry and exit sequences are generated
-directly as assembler code in this pass; they never exist as RTL.
+directly as assembler code in this pass; they never exist as RTL@.
The source files are @file{final.c} plus @file{insn-output.c}; the
latter is generated automatically from the machine description by the
Debugging information output. This is run after final because it must
output the stack slot offsets for pseudo registers that did not get
hard registers. Source files are @file{dbxout.c} for DBX symbol table
-format, @file{sdbout.c} for SDB symbol table format, and
-@file{dwarfout.c} for DWARF symbol table format.
+format, @file{sdbout.c} for SDB symbol table format, @file{dwarfout.c}
+for DWARF symbol table format, and the files @file{dwarf2out.c} and
+@file{dwarf2asm.c} for DWARF2 symbol table format.
@end itemize
Some additional files are used by all or many passes:
All the passes that work with RTL use the header files @file{rtl.h}
and @file{rtl.def}, and subroutines in file @file{rtl.c}. The tools
@code{gen*} also use these files to read and work with the machine
-description RTL.
+description RTL@.
@findex genconfig
@item
@file{recog.c} and @file{recog.h}, plus the files @file{insn-recog.c}
and @file{insn-extract.c} that are generated automatically from the
machine description by the tools @file{genrecog} and
-@file{genextract}.@refill
+@file{genextract}.
@item
Several passes use the header files @file{regs.h} which defines the
@file{insn-attr.h}, which is generated from the machine description by
the program @file{genattr}. The file @file{insn-attrtab.c} contains
subroutines to obtain the attribute values for insns. It is generated
-from the machine description by the program @file{genattrtab}.@refill
+from the machine description by the program @file{genattrtab}.
@end itemize
@end ifset
@table @code
@findex USG
@item USG
-Define this macro if the host system is System V.
+Define this macro if the host system is System V@.
@findex VMS
@item VMS
-Define this macro if the host system is VMS.
+Define this macro if the host system is VMS@.
@findex FATAL_EXIT_CODE
@item FATAL_EXIT_CODE
A C expression for the number of bits in @code{long} on the host
machine.
+@findex HOST_BITS_PER_LONGLONG
+@item HOST_BITS_PER_LONGLONG
+A C expression for the number of bits in @code{long long} on the host
+machine.
+
@findex ONLY_INT_FIELDS
@item ONLY_INT_FIELDS
Define this macro to indicate that the host compiler only supports
-@code{int} bit fields, rather than other integral types, including
+@code{int} bit-fields, rather than other integral types, including
@code{enum}, as do most C compilers.
@findex OBSTACK_CHUNK_SIZE
@findex USE_C_ALLOCA
@item USE_C_ALLOCA
Define this macro to indicate that the compiler is running with the
-@code{alloca} implemented in C. This version of @code{alloca} can be
+@code{alloca} implemented in C@. This version of @code{alloca} can be
found in the file @file{alloca.c}; to use it, you must also alter the
@file{Makefile} variable @code{ALLOCA}. (This is done automatically
for the systems on which we know it is needed.)
@findex MULTIBYTE_CHARS
@item MULTIBYTE_CHARS
Define this macro to enable support for multibyte characters in the
-input to GCC. This requires that the host system support the ISO C
+input to GCC@. This requires that the host system support the ISO C
library functions for converting multibyte characters to wide
characters.
names, the character you specify will be used. GCC will test for
both slash and the character you specify when parsing filenames.
+@findex DIR_SEPARATOR_2
+@item DIR_SEPARATOR_2
+If your system uses an alternative character other than
+@samp{DIR_SEPARATOR} to separate directory names within a file
+specification, define this macro to be a C character constant specifying
+that character. If you define this macro, GCC will test for slash,
+@samp{DIR_SEPARATOR}, and @samp{DIR_SEPARATOR_2} when parsing filenames.
+
@findex TARGET_OBJECT_SUFFIX
@item TARGET_OBJECT_SUFFIX
Define this macro to be a C string representing the suffix for object
@item UPDATE_PATH_HOST_CANONICALIZE (@var{path}, @var{key})
If defined, a C statement (sans semicolon) that performs host-dependent
canonicalization when a path used in a compilation driver or preprocessor is
-canonicalized. @var{path} is the path to be canonicalized, and @var{key} is
-a translation prefix when its value isn't @code{NULL}. If the C statement
+canonicalized. @var{path} is the path to be canonicalized, and @var{key} is
+a translation prefix when its value isn't @code{NULL}. If the C statement
does canonicalize @var{path}, the new path should be returned.
@end table
free software added up to a complete system because the GNU Project
had been working since 1984 to make one. The GNU Manifesto
had set forth the goal of developing a free Unix-like system, called
-GNU. By the time Linux was written, the system was almost finished.
+GNU@. By the time Linux was written, the system was almost finished.
Most free software projects have the goal of developing a particular
program for a particular job. For example, Linus Torvalds set out to
major components without which there could be no system. Linux itself
was about 3%. So if you were going to pick a name for the system
based on who wrote the programs in the system, the most appropriate
-single choice would be ``GNU''.
+single choice would be ``GNU''@.
But we don't think that is the right way to consider the question.
The GNU Project was not, is not, a project to develop specific
OSDN Git Service
