@c
@c anything else? --mew 10feb93
-
+@macro gcctabopt{body}
+@code{\body\}
+@end macro
@ifset INTERNALS
@ifset USING
@c \global\normaloffset =0.75in
@c @end tex
-@ifinfo
+@ifnottex
@dircategory Programming
@direntry
* gcc: (gcc). The GNU Compiler Collection.
@ifclear INTERNALS
This file documents the use of the GNU compiler.
@end ifclear
-
-Published by the Free Software Foundation
-59 Temple Place - Suite 330
+@sp 1
+Published by the Free Software Foundation@*
+59 Temple Place - Suite 330@*
Boston, MA 02111-1307 USA
-
-Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999 Free Software Foundation, Inc.
-
+@sp 1
+@c When you update the list of years below, search for copyright{} and
+@c update the other copy too.
+Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
+1999, 2000, 2001 Free Software Foundation, Inc.
+@sp 1
Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.
-
+@sp 1
@ignore
Permission is granted to process this file through Tex and print the
results, provided the printed document carries copying permission
Software'' are included exactly as in the original, and provided that
the entire resulting derived work is distributed under the terms of a
permission notice identical to this one.
-
+@sp 1
Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that the sections entitled ``GNU General Public License'' and
``Funding for Free Software'', and this permission notice, may be
included in translations approved by the Free Software Foundation
instead of in the original English.
-@end ifinfo
+@end ifnottex
@setchapternewpage odd
@c @finalout
@sp 2
@center Richard M. Stallman
@sp 3
-@center Last updated 28 July 1999
+@center Last updated 20 December 2000
@sp 1
@c The version number appears five times more in this file.
-@center for gcc-2.96
+@center for gcc-2.97
@page
@vskip 0pt plus 1filll
-Copyright @copyright{} 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1998, 1999 Free Software Foundation, Inc.
+Copyright @copyright{} 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1998,
+1999, 2000, 2001 Free Software Foundation, Inc.
@sp 2
-For GCC Version 2.96@*
+For GCC Version 2.97@*
@sp 1
Published by the Free Software Foundation @*
59 Temple Place - Suite 330@*
@end titlepage
@page
-@ifinfo
-
@node Top, G++ and GCC,, (DIR)
@top Introduction
@cindex introduction
@ifset USING
This manual documents how to run, install and port the GNU
compiler, as well as its new features and incompatibilities, and how to
-report bugs. It corresponds to GCC version 2.96.
+report bugs. It corresponds to GCC version 2.97.
@end ifset
@end ifset
@ifclear INTERNALS
This manual documents how to run and install the GNU compiler,
as well as its new features and incompatibilities, and how to report
-bugs. It corresponds to GCC version 2.96.
+bugs. It corresponds to GCC version 2.97.
@end ifclear
@ifclear USING
This manual documents how to port the GNU compiler,
as well as its new features and incompatibilities, and how to report
-bugs. It corresponds to GCC version 2.96.
+bugs. It corresponds to GCC version 2.97.
@end ifclear
-@end ifinfo
@menu
@ifset USING
* G++ and GCC:: You can compile C or C++ programs.
+* Standards:: Language standards supported by GCC.
* Invoking GCC:: Command options supported by @samp{gcc}.
* Installation:: How to configure, compile and install GCC.
* C Extensions:: GNU extensions to the C language family.
@ifset USING
@node G++ and GCC
-@chapter Compile C, C++, Objective C, or Fortran
+@chapter Compile C, C++, Objective C, Fortran, Java or CHILL
@cindex Objective C
-The C, C++, and Objective C, and Fortran versions of the compiler are
-integrated; this is why we use the name ``GNU Compiler Collection''.
-GCC can compile programs written in C, C++, Objective C, or Fortran.
-The Fortran compiler is described in a separate manual.
+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 and CHILL compilers are described in
+separate manuals. The Java compiler currently has no manual documenting it.
@cindex GCC
``GCC'' is a common shorthand term for the GNU Compiler Collection. This is both
compiler. For example, we refer to the optimization options as
affecting the behavior of ``GCC'' or sometimes just ``the compiler''.
-Front ends for other languages, such as Ada 9X, Fortran, Modula-3, and
-Pascal, are under development. These front-ends, like that for C++, are
-built in subdirectories of GCC and link to it. The result is an
+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++,
+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
ends.
@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.
+@node Standards
+@chapter Language Standards Supported by GCC
+@cindex C standard
+@cindex C standards
+@cindex ANSI C standard
+@cindex ANSI C
+@cindex ANSI C89
+@cindex C89
+@cindex ANSI X3.159-1989
+@cindex X3.159-1989
+@cindex ISO C standard
+@cindex ISO C
+@cindex ISO C89
+@cindex ISO C90
+@cindex ISO/IEC 9899
+@cindex ISO 9899
+@cindex C90
+@cindex ISO C94
+@cindex C94
+@cindex ISO C95
+@cindex C95
+@cindex ISO C99
+@cindex C99
+@cindex ISO C9X
+@cindex C9X
+@cindex Technical Corrigenda
+@cindex TC1
+@cindex Technical Corrigendum 1
+@cindex TC2
+@cindex Technical Corrigendum 2
+@cindex AMD1
+@cindex freestanding implementation
+@cindex freestanding environment
+@cindex hosted implementation
+@cindex hosted environment
+@findex __STDC_HOSTED__
+
+For each language compiled by GCC for which there is a standard, GCC
+attempts to follow one or more versions of that standard, possibly
+with some exceptions, and possibly with some extensions.
+
+GCC supports three versions of the C standard, although support for
+the most recent version is not yet complete.
+
+The original ANSI C standard (X3.159-1989) was ratified in 1989 and
+published in 1990. This standard was ratified as an ISO standard
+(ISO/IEC 9899:1990) later in 1990. There were no technical
+differences between these publications, although the sections of the
+ANSI standard were renumbered and became clauses in the ISO standard.
+This standard, in both its forms, is commonly known as @dfn{C89}, or
+occasionally as @dfn{C90}, from the dates of ratification. The ANSI
+standard, but not the ISO standard, also came with a Rationale
+document. To select this standard in GCC, use one of the options
+@samp{-ansi}, @samp{-std=c89} or @samp{-std=iso9899:1990}; to obtain
+all the diagnostics required by the standard, you should also specify
+@samp{-pedantic} (or @samp{-pedantic-errors} if you want them to be
+errors rather than warnings). @xref{C Dialect Options,,Options
+Controlling C Dialect}.
+
+Errors in the 1990 ISO C standard were corrected in two Technical
+Corrigenda published in 1994 and 1996. GCC does not support the
+uncorrected version.
+
+An amendment to the 1990 standard was published in 1995. This
+amendment added digraphs and @code{__STDC_VERSION__} to the language,
+but otherwise concerned the library. This amendment is commonly known
+as @dfn{AMD1}; the amended standard is sometimes known as @dfn{C94} or
+@dfn{C95}. To select this standard in GCC, use the option
+@samp{-std=iso9899:199409} (with, as for other standard versions,
+@samp{-pedantic} to receive all required diagnostics).
+
+A new edition of the ISO C standard was published in 1999 as ISO/IEC
+9899:1999, and is commonly known as @dfn{C99}. GCC has incomplete
+support for this standard version; see
+@uref{http://gcc.gnu.org/c99status.html} for details. To select this
+standard, use @samp{-std=c99} or @samp{-std=iso9899:1999}. (While in
+development, drafts of this standard version were referred to as
+@dfn{C9X}.)
+
+GCC also has some limited support for traditional (pre-ISO) C with the
+@samp{-traditional} option. This support may be of use for compiling
+some very old programs that have not been updated to ISO C, but should
+not be used for new programs. It will not work with some modern C
+libraries such as the GNU C library.
+
+By default, GCC provides some extensions to the C language that on
+rare occasions conflict with the C standard. @xref{C
+Extensions,,Extensions to the C Language Family}. Use of the
+@samp{-std} options listed above will disable these extensions where
+they conflict with the C standard version selected. You may also
+select an extended version of the C language explicitly with
+@samp{-std=gnu89} (for C89 with GNU extensions) or @samp{-std=gnu99}
+(for C99 with GNU extensions). The default, if no C language dialect
+options are given, is @samp{-std=gnu89}; this will change to
+@samp{-std=gnu99} in some future release when the C99 support is
+complete. Some features that are part of the C99 standard are
+accepted as extensions in C89 mode.
+
+The ISO C standard defines (in clause 4) two classes of conforming
+implementation. A @dfn{conforming hosted implementation} supports the
+whole standard including all the library facilities; a @dfn{conforming
+freestanding implementation} is only required to provide certain
+library facilities: those in @code{<float.h>}, @code{<limits.h>},
+@code{<stdarg.h>}, and @code{<stddef.h>}; since AMD1, also those in
+@code{<iso646.h>}; and in C99, also those in @code{<stdbool.h>} and
+@code{<stdint.h>}. In addition, complex types, added in C99, are not
+required for freestanding implementations. The standard also defines
+two environments for programs, a @dfn{freestanding environment},
+required of all implementations and which may not have library
+facilities beyond those required of freestanding implementations,
+where the handling of program startup and termination are
+implementation-defined, and a @dfn{hosted environment}, which is not
+required, in which all the library facilities are provided and startup
+is through a function @code{int main (void)} or @code{int main (int,
+char *[])}. An OS kernel would be a freestanding environment; a
+program using the facilities of an operating system would normally be
+in a hosted implementation.
+
+GNU CC 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
+presuming that when the names of ISO C functions are used, they have
+the semantics defined in the standard. To make it act as a conforming
+freestanding implementation for a freestanding environment, use the
+option @samp{-ffreestanding}; it will then define
+@code{__STDC_HOSTED__} to @code{0} and not make assumptions about the
+meanings of function names from the standard library. To build an OS
+kernel, you may well still need to make your own arrangements for
+linking and startup. @xref{C Dialect Options,,Options Controlling C
+Dialect}.
+
+GNU CC 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
+GNU C library). @xref{Standard Libraries,,Standard Libraries}.
+
+For references to Technical Corrigenda, Rationale documents and
+information concerning the history of C that is available online, see
+@uref{http://gcc.gnu.org/readings.html}
+
+@c FIXME: details of C++ standard.
+@c FIXME: definitions of Java and Objective C.
+
+@xref{Language,,The GNU Fortran Language, g77, Using and Porting GNU
+Fortran}, for details of the Fortran language supported by GCC.
+
+@xref{References,,Language Definition References, chill, GNU Chill},
+for details of the CHILL standard.
+
@include invoke.texi
@include install.texi
* Fixed Headers:: GNU C 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
- compliant with the ISO/ANSI C standard.
+ compliant with the ISO C standard.
* Disappointments:: Regrettable things we can't change, but not quite bugs.
* C++ Misunderstandings:: Common misunderstandings with GNU C++.
* Protoize Caveats:: Things to watch out for when using @code{protoize}.
./xgcc: Internal compiler error: program as got fatal signal 11
@end smallexample
-A patched version of the assembler is available by anonymous ftp from
-@code{altdorf.ai.mit.edu} as the file
-@file{archive/cph/hpux-8.0-assembler}. If you have HP software support,
-the patch can also be obtained directly from HP, as described in the
-following note:
+A patched version of the assembler is available as the file
+@uref{ftp://altdorf.ai.mit.edu/archive/cph/hpux-8.0-assembler}. If you
+have HP software support, the patch can also be obtained directly from
+HP, as described in the following note:
@quotation
This is the patched assembler, to patch SR#1653-010439, where the
PTF U403044 from IBM and users of AIX 3.2 should request PTF U416277.
See the file @file{README.RS6000} for more details on these updates.
-You can test for the presense of a fixed assembler by using the
+You can test for the presence of a fixed assembler by using the
command
@smallexample
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 ANSI C.
+is undefined in ISO C.
@item
AIX on the RS/6000 provides support (NLS) for environments outside of
because of problems in DEC's versions of the X11 header files
@file{X11/Xlib.h} and @file{X11/Xutil.h}. People recommend adding
@samp{-I/usr/include/mit} to use the MIT versions of the header files,
-using the @samp{-traditional} switch to turn off ANSI C, or fixing the
+using the @samp{-traditional} switch to turn off ISO C, or fixing the
header files by adding this:
@example
@end example
@item
-If you have trouble compiling Perl on a SunOS 4 system, it may be
-because Perl specifies @samp{-I/usr/ucbinclude}. This accesses the
-unfixed header files. Perl specifies the options
-
-@example
--traditional -Dvolatile=__volatile__
--I/usr/include/sun -I/usr/ucbinclude
--fpcc-struct-return
-@end example
-
-@noindent
-most of which are unnecessary with GCC 2.4.5 and newer versions. You
-can make a properly working Perl by setting @code{ccflags} to
-@samp{-fwritable-strings} (implied by the @samp{-traditional} in the
-original options) and @code{cppflags} to empty in @file{config.sh}, then
-typing @samp{./doSH; make depend; make}.
-
-@item
On various 386 Unix systems derived from System V, including SCO, ISC,
and ESIX, you may get error messages about running out of virtual memory
while compiling certain programs.
@section Incompatibilities of GCC
@cindex incompatibilities of GCC
-There are several noteworthy incompatibilities between GNU C and most
-existing (non-ANSI) versions of C. The @samp{-traditional} option
+There are several noteworthy incompatibilities between GNU C and K&R
+(non-ISO) versions of C. The @samp{-traditional} option
eliminates many of these incompatibilities, @emph{but not all}, by
-telling GNU C to behave like the other C compilers.
+telling GNU C to behave like a K&R C compiler.
@itemize @bullet
@cindex string constants
@code{-2147483648} is positive.
This is because 2147483648 cannot fit in the type @code{int}, so
-(following the ANSI C rules) its data type is @code{unsigned long int}.
+(following the ISO C rules) its data type is @code{unsigned long int}.
Negating this value yields 2147483648 again.
@item
will produce output @code{"a"} regardless of what the argument @var{a} is.
The @samp{-traditional} option directs GCC to handle such cases
-(among others) in the old-fashioned (non-ANSI) fashion.
+(among others) in the old-fashioned (non-ISO) fashion.
@cindex @code{setjmp} incompatibilities
@cindex @code{longjmp} incompatibilities
hack)
@end example
-ANSI C does not permit such a construct. It would make sense to support
+ISO C does not permit such a construct. It would make sense to support
it when @samp{-traditional} is used, but it is too much work to
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
+this would be quite ugly and can't imagine it could be needed.
+
@cindex external declaration scope
@cindex scope of external declarations
@cindex declaration scope
typedef long foo bar;
@end example
-In ANSI C, this is not allowed: @code{long} and other type modifiers
+In ISO C, this is not allowed: @code{long} and other type modifiers
require an explicit @code{int}. Because this criterion is expressed
by Bison grammar rules rather than C code, the @samp{-traditional}
flag cannot alter it.
PCC allows typedef names to be used as function parameters. The
difficulty described immediately above applies here too.
+@item
+When in @samp{-traditional} mode, GCC allows the following erroneous
+pair of declarations to appear together in a given scope:
+
+@example
+typedef int foo;
+typedef foo foo;
+@end example
+
+@item
+GCC treats all characters of identifiers as significant, even when in
+@samp{-traditional} mode. According to K&R-1 (2.2), ``No more than the
+first eight characters are significant, although more may be used.''.
+Also according to K&R-1 (2.2), ``An identifier is a sequence of letters
+and digits; the first character must be a letter. The underscore _
+counts as a letter.'', but GCC also allows dollar signs in identifiers.
+
@cindex whitespace
@item
PCC allows whitespace in the middle of compound assignment operators
-such as @samp{+=}. GCC, following the ANSI standard, does not
+such as @samp{+=}. GCC, following the ISO standard, does not
allow this. The difficulty described immediately above applies here
too.
Many user programs contain the declaration @samp{long time ();}. In the
past, the system header files on many systems did not actually declare
@code{time}, so it did not matter what type your program declared it to
-return. But in systems with ANSI C headers, @code{time} is declared to
+return. But in systems with ISO C headers, @code{time} is declared to
return @code{time_t}, and if that is not the same as @code{long}, then
@samp{long time ();} is erroneous.
-The solution is to change your program to use @code{time_t} as the return
-type of @code{time}.
+The solution is to change your program to use appropriate system headers
+(@code{<time.h>} on systems with ISO C headers) and not to declare
+@code{time} if the system header files declare it, or failing that to
+use @code{time_t} as the return type of @code{time}.
@cindex @code{float} as function value type
@item
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
-is meant is an operator and two values, the ANSI C standard specifically
+is meant is an operator and two values, the ISO C standard specifically
requires that this be treated as erroneous.
A @dfn{preprocessing token} is a @dfn{preprocessing number} if it
GCC needs to install corrected versions of some system header files.
This is because most target systems have some header files that won't
work with GCC unless they are changed. Some have bugs, some are
-incompatible with ANSI C, and some depend on special features of other
+incompatible with ISO C, and some depend on special features of other
compilers.
Installing GCC automatically creates and installs the fixed header
@node Standard Libraries
@section Standard Libraries
-GCC by itself attempts to be what the ISO/ANSI C standard calls a
-@dfn{conforming freestanding implementation}. This means all ANSI
-C language features are available, as well as the contents of
-@file{float.h}, @file{limits.h}, @file{stdarg.h}, and
-@file{stddef.h}. The rest of the C library is supplied by the
-vendor of the operating system. If that C library doesn't conform to
-the C standards, then your programs might get warnings (especially when
-using @samp{-Wall}) that you don't expect.
+GCC by itself attempts to be a conforming freestanding implementation.
+@xref{Standards,,Language Standards Supported by GCC}, for details of
+what this means. Beyond the library facilities required of such an
+implementation, the rest of the C library is supplied by the vendor of
+the operating system. If that C library doesn't conform to the C
+standards, then your programs might get warnings (especially when using
+@samp{-Wall}) that you don't expect.
For example, the @code{sprintf} function on SunOS 4.1.3 returns
@code{char *} while the C standard says that @code{sprintf} returns an
If you need a Standard compliant library, then you need to find one, as
GCC does not provide one. The GNU C library (called @code{glibc})
-has been ported to a number of operating systems, and provides ANSI/ISO,
-POSIX, BSD and SystemV compatibility. You could also ask your operating
-system vendor if newer libraries are available.
+provides ISO C, POSIX, BSD, SystemV and X/Open compatibility for
+GNU/Linux and HURD-based GNU systems; no recent version of it supports
+other systems, though some very old versions did. Version 2.2 of the
+GNU C library includes nearly complete C99 support. You could also ask
+your operating system vendor if newer libraries are available.
@node Disappointments
@section Disappointments and Misunderstandings
because that is available to be inherited. Thus, the definition and
the prototype do not match, and you get an error.
-This behavior may seem silly, but it's what the ANSI standard specifies.
+This behavior may seem silly, but it's what the ISO standard specifies.
It is easy enough for you to make your code work by moving the
definition of @code{struct mumble} above the prototype. It's not worth
-being incompatible with ANSI C just to avoid an error for the example
+being incompatible with ISO C just to avoid an error for the example
shown above.
@item
if the first argument is a floating point, it is passed in a
floating point register, rather than an integer register.
-If the code is rewritten to use the ANSI standard @file{stdarg.h}
+If the code is rewritten to use the ISO standard @file{stdarg.h}
method of variable arguments, and the prototype is in scope at
the time of the call, everything will work fine.
@item
On the H8/300 and H8/300H, variable argument functions must be
-implemented using the ANSI standard @file{stdarg.h} method of
+implemented using the ISO standard @file{stdarg.h} method of
variable arguments. Furthermore, calls to functions using @file{stdarg.h}
variable arguments must have a prototype for the called function
in scope at the time of the call.
This declaration only establishes that the class @code{Foo} has an
@code{int} named @code{Foo::bar}, and a member function named
@code{Foo::method}. But you still need to define @emph{both}
-@code{method} and @code{bar} elsewhere. According to the draft ANSI
+@code{method} and @code{bar} elsewhere. According to the ISO
standard, you must supply an initializer in one (and only one) source
file, such as:
pointer-to-function variable; this you must do by hand. @code{protoize}
inserts a comment containing @samp{???} each time it finds such a
variable; so you can find all such variables by searching for this
-string. ANSI C does not require declaring the argument types of
+string. ISO C does not require declaring the argument types of
pointer-to-function types.
@item
@code{unprotoize} can become confused when trying to convert a function
definition or declaration which contains a declaration for a
pointer-to-function formal argument which has the same name as the
-function being defined or declared. We recommand you avoid such choices
+function being defined or declared. We recommend you avoid such choices
of formal parameter names.
@item
more annoyance than good.
@item
-Warning about unreachable code.
-
-It's very common to have unreachable code in machine-generated
-programs. For example, this happens normally in some files of GNU C
-itself.
-
-@item
Warning when a non-void function value is ignored.
Coming as I do from a Lisp background, I balk at the idea that there is
Making bitfields unsigned by default on particular machines where ``the
ABI standard'' says to do so.
-The ANSI C standard leaves it up to the implementation whether a bitfield
+The ISO C standard leaves it up to the implementation whether a bitfield
declared plain @code{int} is signed or not. This in effect creates two
alternative dialects of C.
@samp{-traditional}. This provides good results in practice.
Programmers normally use conditionals on @code{__STDC__} to ask whether
-it is safe to use certain features of ANSI C, such as function
-prototypes or ANSI token concatenation. Since plain @samp{gcc} supports
-all the features of ANSI C, the correct answer to these questions is
+it is safe to use certain features of ISO C, such as function
+prototypes or ISO token concatenation. Since plain @samp{gcc} supports
+all the features of ISO C, the correct answer to these questions is
``yes''.
Some users try to use @code{__STDC__} to check for the availability of
-certain library facilities. This is actually incorrect usage in an ANSI
-C program, because the ANSI C standard says that a conforming
+certain library facilities. This is actually incorrect usage in an ISO
+C program, because the ISO C standard says that a conforming
freestanding implementation should define @code{__STDC__} even though it
does not have the library facilities. @samp{gcc -ansi -pedantic} is a
conforming freestanding implementation, and it is therefore required to
-define @code{__STDC__}, even though it does not come with an ANSI C
+define @code{__STDC__}, even though it does not come with an ISO C
library.
Sometimes people say that defining @code{__STDC__} in a compiler that
-does not completely conform to the ANSI C standard somehow violates the
+does not completely conform to the ISO C standard somehow violates the
standard. This is illogical. The standard is a standard for compilers
-that claim to support ANSI C, such as @samp{gcc -ansi}---not for other
-compilers such as plain @samp{gcc}. Whatever the ANSI C standard says
+that claim to support ISO C, such as @samp{gcc -ansi}---not for other
+compilers such as plain @samp{gcc}. Whatever the ISO C standard says
is relevant to the design of plain @samp{gcc} without @samp{-ansi} only
for pragmatic reasons, not as a requirement.
value of @code{__STDC__} that goes with the C compiler that is
subsequently used. These programs must test @code{__STDC__}
to determine what kind of C preprocessor that compiler uses:
-whether they should concatenate tokens in the ANSI C fashion
+whether they should concatenate tokens in the ISO C fashion
or in the traditional fashion.
These programs work properly with GNU C++ if @code{__STDC__} is defined.
They would not work otherwise.
-In addition, many header files are written to provide prototypes in ANSI
+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
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
@item
Not allowing structures with volatile fields in registers.
-Strictly speaking, there is no prohibition in the ANSI C standard
+Strictly speaking, there is no prohibition in the ISO C standard
against allowing structures with volatile fields in registers, but
it does not seem to make any sense and is probably not what you wanted
to do. So the compiler will give an error message in this case.
+
+@item
+Making certain warnings into errors by default.
+
+Some ISO C testsuites report failure when the compiler does not produce
+an error message for a certain program.
+
+ISO C requires a ``diagnostic'' message for certain kinds of invalid
+programs, but a warning is defined by GCC to count as a diagnostic. If
+GCC produces a warning but not an error, that is correct ISO C support.
+If test suites call this ``failure'', they should be run with the GCC
+option @samp{-pedantic-errors}, which will turn these warnings into
+errors.
+
@end itemize
@node Warnings and Errors
forbidden, and a diagnostic @emph{must} be issued by a conforming
compiler. The @samp{-pedantic} option tells GCC to issue warnings in
such cases; @samp{-pedantic-errors} says to make them errors instead.
-This does not mean that @emph{all} non-ANSI constructs get warnings
+This does not mean that @emph{all} non-ISO constructs get warnings
or errors.
@xref{Warning Options,,Options to Request or Suppress Warnings}, for
* Criteria: Bug Criteria. Have you really found a bug?
* Where: Bug Lists. Where to send your bug report.
* Reporting: Bug Reporting. How to report a bug effectively.
+* GNATS: gccbug. You can use a bug reporting tool.
* Patches: Sending Patches. How to send a patch for GCC.
* Known: Trouble. Known problems.
* Help: Service. Where to ask for help.
@end menu
-@node Bug Criteria
+@node Bug Criteria,Bug Lists,,Bugs
@section Have You Found a Bug?
@cindex bug criteria
for traditional practice''.
@item
-If you are an experienced user of C or C++ (or Fortran or Objective-C)
-compilers, your suggestions
-for improvement of GCC are welcome in any case.
+If you are an experienced user of one of the languages GCC supports, your
+suggestions for improvement of GCC are welcome in any case.
@end itemize
-@node Bug Lists
+@node Bug Lists,Bug Reporting,Bug Criteria,Bugs
@section Where to Report Bugs
@cindex bug report mailing lists
@kindex gcc-bugs@@gcc.gnu.org or bug-gcc@@gnu.org
Send bug reports for the GNU Compiler Collection to
-@samp{gcc-bugs@@gcc.gnu.org} or @samp{bug-gcc@@gnu.org}.
+@email{gcc-bugs@@gcc.gnu.org}. In accordance with the GNU-wide
+convention, in which bug reports for tool ``foo'' are sent
+to @samp{bug-foo@@gnu.org}, the address @email{bug-gcc@@gnu.org}
+may also be used; it will forward to the address given above.
-Please read @samp{<URL:http://www.gnu.org/software/gcc/faq.html#bugreport>} for
+Please read @uref{http://www.gnu.org/software/gcc/bugs.html} for
bug reporting instructions before you post a bug report.
Often people think of posting bug reports to the newsgroup instead of
Boston, MA 02111-1307, USA
@end example
-@node Bug Reporting
+@node Bug Reporting,gccbug,Bug Lists,Bugs
@section How to Report Bugs
@cindex compiler bugs, reporting
You may find additional and/or more up-to-date instructions at
-@samp{<URL:http://www.gnu.org/software/gcc/faq.html#bugreport>}.
+@uref{http://www.gnu.org/software/gcc/bugs.html}.
The fundamental principle of reporting bugs usefully is this:
@strong{report all the facts}. If you are not sure whether to state a
we should be able to reproduce the crash ourselves.
@end itemize
-@node Sending Patches,, Bug Reporting, Bugs
+@node gccbug,Sending Patches, Bug Reporting, Bugs
+@section The gccbug script
+@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
+@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
+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
+send to the bug reporting address.
+
+A number of fields in this bug report form are specific to GCC, and are
+explained here.
+
+@table @code
+
+@cindex @code{Category} field
+@cindex @code{>Category:}
+@item >Category:
+The category of a GCC problem can be one of the following:
+
+@table @code
+@item c
+A problem with the C compiler proper.
+driver.
+
+@item c++
+A problem with the C++ compiler.
+driver.
+
+@item fortran
+A problem with the Fortran 77.
+
+@item java
+A problem with the Java compiler.
+
+@item objc
+A problem with the Objective C compiler.
+
+@item libstdc++
+A problem with the C++ standard library.
+
+@item libf2c
+A problem with the Fortran 77 library.
+
+@item libobjc
+A problem with the Objective C library.
+
+@item optimization
+The problem occurs only when generating optimized code.
+
+@item debug
+The problem occurs only when generating code for debugging.
+
+@item target
+The problem is specific to the target architecture.
+
+@item middle-end
+The problem is independent from target architecture and programming
+language.
+
+@item other
+It is a problem in some other part of the GCC software.
+
+@item web
+There is a problem with the GCC home page.
+
+@end table
+
+@cindex @code{Class} field
+@cindex @code{>Class:}
+@item >Class:
+The class of a problem can be one of the following:
+
+@table @code
+@cindex @emph{doc-bug} class
+@item doc-bug
+A problem with the documentation.
+
+@cindex @emph{accepts-illegal} class
+@item accepts-illegal
+GCC fails to reject erroneous code.
+
+@cindex @emph{rejects-legal} class
+@item rejects-legal
+GCC gives an error message for correct code.
+
+@cindex @emph{wrong-code} class
+@item wrong-code
+The machine code generated by gcc is incorrect.
+
+@cindex @emph{ice-on-legal-code} class
+@item ice-on-legal-code
+GCC gives an Internal Compiler Error (ICE) for correct code.
+
+@cindex @emph{ice-on-illegal-code} class
+@item ice-on-illegal-code
+GCC gives an ICE instead of reporting an error
+
+@cindex @emph{pessimizes-code} class
+@item pessimizes-code
+GCC misses an important optimization opportunity.
+
+@cindex @emph{sw-bug} class
+@item sw-bug
+A general product problem. (@samp{sw} stands for ``software''.)
+
+@cindex @emph{change-request} class
+@item change-request
+A request for a change in behavior, etc.
+
+@cindex @emph{support} class
+@item support
+A support problem or question.
+
+@cindex @emph{duplicate} class
+@item duplicate (@var{pr-number})
+Duplicate PR. @var{pr-number} should be the number of the original PR.
+
+@noindent
+The default is @samp{sw-bug}.
+@sp 1
+@end table
+
+@end table
+
+@node Sending Patches,, gccbug, Bugs
@section Sending Patches for GCC
If you would like to write bug fixes or improvements for the GNU C
compiler, that is very helpful. Send suggested fixes to the patches
-mailing list, @code{gcc-patches@@gcc.gnu.org}.
+mailing list, @email{gcc-patches@@gcc.gnu.org}.
Please follow these guidelines so we can study your patches efficiently.
If you don't follow these guidelines, your information might still be
@itemize @bullet
@item
Send a message to a suitable network mailing list. First try
-@code{gcc-bugs@@gcc.gnu.org} or @code{bug-gcc@@gnu.org}, and if that
-brings no response, try @code{gcc@@gcc.gnu.org}.
+@email{gcc-help@@gcc.gnu.org} (for help installing or using GCC), and if
+that brings no response, try @email{gcc@@gcc.gnu.org}. For help
+changing GCC, ask @email{gcc@@gcc.gnu.org}. If you think you have found
+a bug in GCC, please report it following the instructions at
+@uref{http://gcc.gnu.org/bugs.html}.
@item
Look in the service directory for someone who might help you for a fee.
-The service directory is found in the file named @file{SERVICE} in the
-GCC distribution.
+The service directory is found at
+@uref{http://www.gnu.org/prep/service.html}.
@end itemize
+@c For further information, see
+@c @uref{http://gcc.gnu.org/cgi-bin/fom.cgi?file=12}.
+@c FIXME: this URL may be too volatile, this FAQ entry needs to move to
+@c the regular web pages before we can uncomment the reference.
+
@node Contributing
@chapter Contributing to GCC Development
-If you would like to help pretest GCC releases to assure they work
-well, or if you would like to work on improving GCC, please contact
-the maintainers at @code{egcs@@egcs.cygnus.com}. A pretester should
-be willing to try to investigate bugs as well as report them.
-
-If you'd like to work on improvements, please ask for suggested projects
-or suggest your own ideas. If you have already written an improvement,
-please tell us about it. If you have not yet started work, it is useful
-to contact @code{egcs@@egcs.cygnus.com} before you start; the
-maintainers may be able to suggest ways to make your extension fit in
-better with the rest of GCC and with other development plans.
+If you would like to help pretest GCC releases to assure they work well,
+our current development sources are available by CVS (see
+@uref{http://gcc.gnu.org/cvs.html}). Source and binary snapshots are
+also available for FTP; see @uref{http://gcc.gnu.org/snapshots.html}.
+Remember that snapshots of the current development sources may not be of
+production quality; if you find problems (whether compiler crashes,
+miscompiled code, poor optimization or any other problem), please report
+them following our bug reporting instructions at
+@uref{http://gcc.gnu.org/bugs.html}.
+
+If you would like to work on improvements to GCC, please read
+@uref{http://gcc.gnu.org/contribute.html} and
+@uref{http://gcc.gnu.org/contributewhy.html} for information on how to
+make useful contributions and avoid duplication of effort. Suggested
+projects are listed at @uref{http://gcc.gnu.org/projects/}.
@node VMS
@chapter Using GCC on VMS
@noindent
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 ANSI C behavior implemented by GCC: to
+That is incompatible with the ISO C behavior implemented by GCC: to
expand the name @code{foobar} as a macro. Macro expansion should
eventually yield one of the two standard formats for @code{#include}:
The fact that the symbol is an array may lead to warnings where the
variable is used. Insert type casts to avoid the warnings. Here is an
-example; it takes advantage of the ANSI C feature allowing macros that
+example; it takes advantage of the ISO C feature allowing macros that
expand to use the same name as the macro itself.
@example
the subroutine.
@cindex @code{longjmp} and automatic variables
-If you use @code{longjmp}, beware of automatic variables. ANSI C says that
+If you use @code{longjmp}, beware of automatic variables. ISO C says that
automatic variables that are not declared @code{volatile} have undefined
values after a @code{longjmp}. And this is all GCC promises to do,
because it is very difficult to restore register variables correctly, and
@file{c-lex.h}, and
@file{c-tree.h}.
-The source files for parsing C++ are @file{cp-parse.y},
-@file{cp-class.c},@*
-@file{cp-cvt.c}, @file{cp-decl.c}, @file{cp-decl2.c},
-@file{cp-dem.c}, @file{cp-except.c},@*
-@file{cp-expr.c}, @file{cp-init.c}, @file{cp-lex.c},
-@file{cp-method.c}, @file{cp-ptree.c},@*
-@file{cp-search.c}, @file{cp-tree.c}, @file{cp-type2.c}, and
-@file{cp-typeck.c}, along with header files @file{cp-tree.def},
-@file{cp-tree.h}, and @file{cp-decl.h}.
-
-The special source files for parsing Objective C are
-@file{objc-parse.y}, @file{objc-actions.c}, @file{objc-tree.def}, and
-@file{objc-actions.h}. Certain C-specific files are used for this as
+The source files for parsing C++ are in @file{cp/}.
+They are @file{parse.y},
+@file{class.c},@*
+@file{cvt.c}, @file{decl.c}, @file{decl2.c},
+@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{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/}.
+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.
this pass. This dump file's name is made by appending @samp{.cse2} to
the input file name.
-@cindex register allocation, stupid
-@cindex stupid register allocation
-@item
-Stupid register allocation is performed at this point in a
-nonoptimizing compilation. It does a little data flow analysis as
-well. When stupid register allocation is in use, the next pass
-executed is the reloading pass; the others in between are skipped.
-The source file is @file{stupid.c}.
-
@cindex data flow analysis
@cindex analysis, data flow
@cindex basic blocks
@item
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 them attempts
+this reload would be a register to register move. It then attempts
to change the registers used by the instruction to avoid the move
instruction.
@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 ANSI C
+input to GCC. This requires that the host system support the ISO C
library functions for converting multibyte characters to wide
characters.
@item POSIX
Define this if your system is POSIX.1 compliant.
-@findex NO_SYS_SIGLIST
-@item NO_SYS_SIGLIST
-Define this if your system @emph{does not} provide the variable
-@code{sys_siglist}.
-
-@vindex sys_siglist
-Some systems do provide this variable, but with a different name such
-as @code{_sys_siglist}. On these systems, you can define
-@code{sys_siglist} as a macro which expands into the name actually
-provided.
-
-Autoconf normally defines @code{SYS_SIGLIST_DECLARED} when it finds a
-declaration of @code{sys_siglist} in the system header files.
-However, when you define @code{sys_siglist} to a different name
-autoconf will not automatically define @code{SYS_SIGLIST_DECLARED}.
-Therefore, if you define @code{sys_siglist}, you should also define
-@code{SYS_SIGLIST_DECLARED}.
-
@findex USE_PROTOTYPES
@item USE_PROTOTYPES
Define this to be 1 if you know that the host compiler supports
determined automatically whether your compiler supports
prototypes by checking if @samp{__STDC__} is defined.
-@findex NO_MD_PROTOTYPES
-@item NO_MD_PROTOTYPES
-Define this if you wish suppression of prototypes generated from
-the machine description file, but to use other prototypes within
-GCC. If @samp{USE_PROTOTYPES} is defined to be 0, or the
-host compiler does not support prototypes, this macro has no
-effect.
-
-@findex MD_CALL_PROTOTYPES
-@item MD_CALL_PROTOTYPES
-Define this if you wish to generate prototypes for the
-@code{gen_call} or @code{gen_call_value} functions generated from
-the machine description file. If @samp{USE_PROTOTYPES} is
-defined to be 0, or the host compiler does not support
-prototypes, or @samp{NO_MD_PROTOTYPES} is defined, this macro has
-no effect. As soon as all of the machine descriptions are
-modified to have the appropriate number of arguments, this macro
-will be removed.
-
@findex PATH_SEPARATOR
@item PATH_SEPARATOR
Define this macro to be a C character constant representing the
files on your machine. If you do not define this macro, GCC will use
the null string as the suffix for object files.
+@findex HOST_BIT_BUCKET
+@item HOST_BIT_BUCKET
+The name of a file or file-like object on the host system which acts as
+a ``bit bucket''. If you do not define this macro, GCC will use
+@samp{/dev/null} as the bit bucket. If the target does not support a
+bit bucket, this should be defined to the null string, or some other
+illegal filename. If the bit bucket is not writable, GCC will use a
+temporary file instead.
+
@findex COLLECT_EXPORT_LIST
@item COLLECT_EXPORT_LIST
If defined, @code{collect2} will scan the individual object files
Define this macro for systems like AIX, where the linker discards
object files that are not referenced from @code{main} and uses export
lists.
+
+@findex COLLECT2_HOST_INITIALIZATION
+@item COLLECT2_HOST_INITIALIZATION
+If defined, a C statement (sans semicolon) that performs host-dependent
+initialization when @code{collect2} is being initialized.
+
+@findex GCC_DRIVER_HOST_INITIALIZATION
+@item GCC_DRIVER_HOST_INITIALIZATION
+If defined, a C statement (sans semicolon) that performs host-dependent
+initialization when a compilation driver is being initialized.
+
+@findex UPDATE_PATH_HOST_CANONICALIZE
+@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
+does canonicalize @var{path}, the new path should be returned.
@end table
@findex bzero
case, set @code{MULTILIB_EXCEPTIONS} to be all of the switch exceptions
in shell case syntax that should not be built.
-For example, in the PowerPC embedded ABI support, it was not desirable
-to build libraries that compiled with the @samp{-mcall-aixdesc} option
-and either of the @samp{-mcall-aixdesc} or @samp{-mlittle} options at
-the same time, and therefore @code{MULTILIB_EXCEPTIONS} is set to
-@code{*mrelocatable/*mcall-aixdesc* *mlittle/*mcall-aixdesc*}.
+For example, in the PowerPC embedded ABI support, it is not desirable
+to build libraries compiled with the @samp{-mcall-aix} option
+and either of the @samp{-fleading-underscore} or @samp{-mlittle} options
+at the same time. Therefore @code{MULTILIB_EXCEPTIONS} is set to
+@code{*mcall-aix/*fleading-underscore* *mlittle/*mcall-aix*}.
@findex MULTILIB_EXTRA_OPTS
@item MULTILIB_EXTRA_OPTS
@item INSTALL
The install program to use.
@end table
+@end ifset
@node Funding
@unnumbered Funding Free Software
@iftex
@unnumberedsec TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
@end iftex
-@ifinfo
+@ifnottex
@center TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
-@end ifinfo
+@end ifnottex
@enumerate 0
@item
@iftex
@heading NO WARRANTY
@end iftex
-@ifinfo
+@ifnottex
@center NO WARRANTY
-@end ifinfo
+@end ifnottex
@item
BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
@iftex
@heading END OF TERMS AND CONDITIONS
@end iftex
-@ifinfo
+@ifnottex
@center END OF TERMS AND CONDITIONS
-@end ifinfo
+@end ifnottex
@page
@unnumberedsec How to Apply These Terms to Your New Programs
@node Contributors
@unnumbered Contributors to GCC
@cindex contributors
-
-In addition to Richard Stallman, several people have written parts
-of GCC.
-
-@itemize @bullet
-@item
-The idea of using RTL and some of the optimization ideas came from the
-program PO written at the University of Arizona by Jack Davidson and
-Christopher Fraser. See ``Register Allocation and Exhaustive Peephole
-Optimization'', Software Practice and Experience 14 (9), Sept. 1984,
-857-866.
-
-@item
-Paul Rubin wrote most of the preprocessor.
-
-@item
-Leonard Tower wrote parts of the parser, RTL generator, and RTL
-definitions, and of the Vax machine description.
-
-@item
-Ted Lemon wrote parts of the RTL reader and printer.
-
-@item
-Jim Wilson implemented loop strength reduction and some other
-loop optimizations.
-
-@item
-Nobuyuki Hikichi of Software Research Associates, Tokyo, contributed
-the support for the Sony NEWS machine.
-
-@item
-Charles LaBrec contributed the support for the Integrated Solutions
-68020 system.
-
-@item
-Michael Tiemann of Cygnus Support wrote the front end for C++, as well
-as the support for inline functions and instruction scheduling. Also
-the descriptions of the National Semiconductor 32000 series cpu, the
-SPARC cpu and part of the Motorola 88000 cpu.
-
-@item
-Gerald Baumgartner added the signature extension to the C++ front-end.
-
-@item
-Jan Stein of the Chalmers Computer Society provided support for
-Genix, as well as part of the 32000 machine description.
-
-@item
-Randy Smith finished the Sun FPA support.
-
-@item
-Robert Brown implemented the support for Encore 32000 systems.
-
-@item
-David Kashtan of SRI adapted GCC to VMS.
-
-@item
-Alex Crain provided changes for the 3b1.
-
-@item
-Greg Satz and Chris Hanson assisted in making GCC work on HP-UX for
-the 9000 series 300.
-
-@item
-William Schelter did most of the work on the Intel 80386 support.
-
-@item
-Christopher Smith did the port for Convex machines.
-
-@item
-Paul Petersen wrote the machine description for the Alliant FX/8.
-
-@item
-Dario Dariol contributed the four varieties of sample programs
-that print a copy of their source.
-
-@item
-Alain Lichnewsky ported GCC to the Mips cpu.
-
-@item
-Devon Bowen, Dale Wiles and Kevin Zachmann ported GCC to the Tahoe.
-
-@item
-Jonathan Stone wrote the machine description for the Pyramid computer.
-
-@item
-Gary Miller ported GCC to Charles River Data Systems machines.
-
-@item
-Richard Kenner of the New York University Ultracomputer Research
-Laboratory wrote the machine descriptions for the AMD 29000, the DEC
-Alpha, the IBM RT PC, and the IBM RS/6000 as well as the support for
-instruction attributes. He also made changes to better support RISC
-processors including changes to common subexpression elimination,
-strength reduction, function calling sequence handling, and condition
-code support, in addition to generalizing the code for frame pointer
-elimination.
-
-@item
-Richard Kenner and Michael Tiemann jointly developed reorg.c, the delay
-slot scheduler.
-
-@item
-Mike Meissner and Tom Wood of Data General finished the port to the
-Motorola 88000.
-
-@item
-Masanobu Yuhara of Fujitsu Laboratories implemented the machine
-description for the Tron architecture (specifically, the Gmicro).
-
-@item
-NeXT, Inc.@: donated the front end that supports the Objective C
-language.
-@c We need to be careful to make it clear that "Objective C"
-@c is the name of a language, not that of a program or product.
-
-@item
-James van Artsdalen wrote the code that makes efficient use of
-the Intel 80387 register stack.
-
-@item
-Mike Meissner at the Open Software Foundation finished the port to the
-MIPS cpu, including adding ECOFF debug support, and worked on the
-Intel port for the Intel 80386 cpu. Later at Cygnus Support, he worked
-on the rs6000 and PowerPC ports.
-
-@item
-Ron Guilmette implemented the @code{protoize} and @code{unprotoize}
-tools, the support for Dwarf symbolic debugging information, and much of
-the support for System V Release 4. He has also worked heavily on the
-Intel 386 and 860 support.
-
-@item
-Torbjorn Granlund implemented multiply- and divide-by-constant
-optimization, improved long long support, and improved leaf function
-register allocation.
-
-@item
-Mike Stump implemented the support for Elxsi 64 bit CPU.
-
-@item
-John Wehle added the machine description for the Western Electric 32000
-processor used in several 3b series machines (no relation to the
-National Semiconductor 32000 processor).
-
-@ignore @c These features aren't advertised yet, since they don't fully work.
-@item
-Analog Devices helped implement the support for complex data types
-and iterators.
-@end ignore
-
-@item
-Holger Teutsch provided the support for the Clipper cpu.
-
-@item
-Kresten Krab Thorup wrote the run time support for the Objective C
-language.
-
-@item
-Stephen Moshier contributed the floating point emulator that assists in
-cross-compilation and permits support for floating point numbers wider
-than 64 bits.
-
-@item
-David Edelsohn contributed the changes to RS/6000 port to make it
-support the PowerPC and POWER2 architectures.
-
-@item
-Steve Chamberlain wrote the support for the Hitachi SH processor.
-
-@item
-Peter Schauer wrote the code to allow debugging to work on the Alpha.
-
-@item
-Oliver M. Kellogg of Deutsche Aerospace contributed the port to the
-MIL-STD-1750A.
-
-@item
-Michael K. Gschwind contributed the port to the PDP-11.
-
-@item
-David Reese of Sun Microsystems contributed to the Solaris on PowerPC
-port.
-@end itemize
+@include contrib.texi
@node Index
@unnumbered Index
-@end ifset
-
-@ifclear INTERNALS
-@node Index
-@unnumbered Index
-@end ifclear
@printindex cp
OSDN Git Service
