@c
@c anything else? --mew 10feb93
-
+@macro gcctabopt{body}
+@code{\body\}
+@end macro
+@macro gccoptlist{body}
+@smallexample
+\body\
+@end smallexample
+@end macro
+@c Makeinfo handles the above macro OK, TeX needs manual line breaks;
+@c they get lost at some point in handling the macro. But if @macro is
+@c used here rather than @alias, it produces double line breaks.
+@iftex
+@alias gol = *
+@end iftex
+@ifnottex
+@macro gol
+@end macro
+@end ifnottex
@ifset INTERNALS
@ifset USING
-@settitle Using and Porting GNU CC
+@settitle Using and Porting the GNU Compiler Collection (GCC)
@end ifset
@end ifset
@c seems reasonable to assume at least one of INTERNALS or USING is set...
@ifclear INTERNALS
-@settitle Using GNU CC
+@settitle Using the GNU Compiler Collection
@end ifclear
@ifclear USING
-@settitle Porting GNU CC
+@settitle Porting the GNU Compiler Collection
@end ifclear
@syncodeindex fn cp
@c \global\normaloffset =0.75in
@c @end tex
-@ifinfo
+@ifnottex
@dircategory Programming
@direntry
-* gcc: (gcc). The GNU C compiler.
+* gcc: (gcc). The GNU Compiler Collection.
@end direntry
@ifset INTERNALS
@ifset USING
@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 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
@titlepage
@ifset INTERNALS
@ifset USING
-@center @titlefont{Using and Porting GNU CC}
+@center @titlefont{Using and Porting the GNU Compiler Collection}
@end ifset
@end ifset
@ifclear INTERNALS
-@title Using GNU CC
+@title Using the GNU Compiler Collection
@end ifclear
@ifclear USING
-@title Porting GNU CC
+@title Porting the GNU Compiler Collection
@end ifclear
@sp 2
@center Richard M. Stallman
@sp 3
-@center Last updated 16 March 1998
+@center Last updated 22 March 2001
@sp 1
@c The version number appears five times more in this file.
-@center for egcs-1.1
+@center for gcc-3.1
@page
@vskip 0pt plus 1filll
-Copyright @copyright{} 1988, 89, 92, 93, 94, 95, 96, 98 Free Software Foundation, Inc.
+Copyright @copyright{} 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1998,
+1999, 2000, 2001 Free Software Foundation, Inc.
@sp 2
-For EGCS Version 1.0@*
+For GCC Version 3.1@*
@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 EGCS version 1.0.
+report bugs. It corresponds to GCC version 3.1.
@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 EGCS version 1.0.
+bugs. It corresponds to GCC version 3.1.
@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 EGCS version 1.0.
+bugs. It corresponds to GCC version 3.1.
@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 GNU CC.
+* 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.
-* Gcov:: gcov: a GNU CC test coverage program.
-* Trouble:: If you have trouble installing GNU CC.
+* Gcov:: gcov: a GCC test coverage program.
+* Trouble:: If you have trouble installing GCC.
* Bugs:: How, why and where to report bugs.
-* Service:: How to find suppliers of support for GNU CC.
-* Contributing:: How to contribute to testing and developing GNU CC.
-* VMS:: Using GNU CC on VMS.
+* Service:: How to find suppliers of support for GCC.
+* Contributing:: How to contribute to testing and developing GCC.
+* VMS:: Using GCC on VMS.
+* Makefile:: List of Makefile targets.
@end ifset
@ifset INTERNALS
-* Portability:: Goals of GNU CC's portability features.
-* Interface:: Function-call interface of GNU CC output.
+* 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.
* RTL:: The intermediate representation that most passes work on.
* Machine Desc:: How to write machine description instruction patterns.
* GNU/Linux:: Linux and the GNU Project
* Copying:: GNU General Public License says
- how you can copy and share GNU CC.
-* Contributors:: People who have contributed to GNU CC.
+ how you can copy and share GCC.
+* Contributors:: People who have contributed to GCC.
* Index:: Index of concepts and symbol names.
@end menu
@ifset USING
@node G++ and GCC
-@chapter Compile C, C++, or Objective C
+@chapter Compile C, C++, Objective C, Fortran, Java or CHILL
@cindex Objective C
-The C, C++, and Objective C versions of the compiler are integrated; the
-GNU C compiler can compile programs written in C, C++, or Objective C.
+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
+separate manuals.
@cindex GCC
-``GCC'' is a common shorthand term for the GNU C compiler. This is both
+``GCC'' is a common shorthand term for the GNU Compiler Collection. This is both
the most general name for the compiler, and the name used when the
-emphasis is on compiling C programs.
+emphasis is on compiling C programs (as the abbreviation formerly
+stood for ``GNU C Compiler'').
@cindex C++
@cindex G++
it ``GCC'' no matter what the language context; however, the term
``G++'' is more useful when the emphasis is on compiling C++ programs.
-We use the name ``GNU CC'' to refer to the compilation system as a
+We use the name ``GCC'' to refer to the compilation system as a
whole, and more specifically to the language-independent part of the
compiler. For example, we refer to the optimization options as
-affecting the behavior of ``GNU CC'' or sometimes just ``the compiler''.
+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 GNU CC 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.
In this manual, we only discuss the options for the C, Objective-C, and
-C++ compilers and those of the GNU CC core. Consult the documentation
+C++ compilers and those of the GCC core. Consult the documentation
of the other front ends for the options to use when compiling programs
written in other languages.
@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{Compatibility,,Compatibility with the Java Platform, gcj, GNU gcj},
+for details of compatibility between @code{gcj} and the Java Platform.
+
+@xref{References,,Language Definition References, chill, GNU Chill},
+for details of the CHILL standard.
+
@include invoke.texi
@include install.texi
@include gcov.texi
@node Trouble
-@chapter Known Causes of Trouble with GNU CC
+@chapter Known Causes of Trouble with GCC
@cindex bugs, known
@cindex installation trouble
@cindex known causes of trouble
-This section describes known problems that affect users of GNU CC. Most
-of these are not GNU CC bugs per se---if they were, we would fix them.
+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.
Some of these problems are due to bugs in other software, some are
@menu
* Actual Bugs:: Bugs we will fix later.
-* Installation Problems:: Problems that manifest when you install GNU CC.
-* Cross-Compiler Problems:: Common problems of cross compiling with GNU CC.
-* Interoperation:: Problems using GNU CC with other compilers,
+* Installation Problems:: Problems that manifest when you install GCC.
+* Cross-Compiler Problems:: Common problems of cross compiling with GCC.
+* Interoperation:: Problems using GCC with other compilers,
and with certain linkers, assemblers and debuggers.
* External Bugs:: Problems compiling certain programs.
-* Incompatibilities:: GNU CC is incompatible with traditional C.
+* Incompatibilities:: GCC is incompatible with traditional C.
* 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}.
prototypes.
@item
-There are several obscure case of mis-using struct, union, and
-enum tags that are not detected as errors by the compiler.
-
-@item
-When @samp{-pedantic-errors} is specified, GNU C will incorrectly give
+When @samp{-pedantic-errors} is specified, GCC will incorrectly give
an error message when a function name is specified in an expression
involving the comma operator.
-
-@item
-Loop unrolling doesn't work properly for certain C++ programs. This is
-a bug in the C++ front end. It sometimes emits incorrect debug info, and
-the loop unrolling code is unable to recover from this error.
@end itemize
@node Installation Problems
@xref{Other Dir}.
@item
-If you build GNU CC on a BSD system using a directory stored in a System
+If you build GCC on a BSD system using a directory stored in a System
V file system, problems may occur in running @code{fixincludes} if the
System V file system doesn't support symbolic links. These problems
result in a failure to fix the declaration of @code{size_t} in
@file{sys/types.h}. If you find that @code{size_t} is a signed type and
that type mismatches occur, this could be the cause.
-The solution is not to use such a directory for building GNU CC.
-
-@item
-In previous versions of GNU CC, the @code{gcc} driver program looked for
-@code{as} and @code{ld} in various places; for example, in files
-beginning with @file{/usr/local/lib/gcc-}. GNU CC version 2 looks for
-them in the directory
-@file{/usr/local/lib/gcc-lib/@var{target}/@var{version}}.
-
-Thus, to use a version of @code{as} or @code{ld} that is not the system
-default, for example @code{gas} or GNU @code{ld}, you must put them in
-that directory (or make links to them from that directory).
+The solution is not to use such a directory for building GCC.
@item
Some commands executed when making the compiler may fail (return a
@code{make}. Either ignore the problem or switch to GNU Make.
@item
-If you have installed a program known as purify, you may find that it
-causes errors while linking @code{enquire}, which is part of building
-GNU CC. The fix is to get rid of the file @code{real-ld} which purify
-installs---so that GNU CC won't try to use it.
-
-@item
On GNU/Linux SLS 1.01, there is a problem with @file{libc.a}: it does not
-contain the obstack functions. However, GNU CC assumes that the obstack
+contain the obstack functions. However, GCC assumes that the obstack
functions are in @file{libc.a} when it is the GNU C library. To work
around this problem, change the @code{__GNU_LIBRARY__} conditional
around line 31 to @samp{#if 1}.
@item
-On some 386 systems, building the compiler never finishes because
-@code{enquire} hangs due to a hardware problem in the motherboard---it
-reports floating point exceptions to the kernel incorrectly. You can
-install GNU CC except for @file{float.h} by patching out the command to
-run @code{enquire}. You may also be able to fix the problem for real by
-getting a replacement motherboard. This problem was observed in
-Revision E of the Micronics motherboard, and is fixed in Revision F.
-It has also been observed in the MYLEX MXA-33 motherboard.
-
-If you encounter this problem, you may also want to consider removing
-the FPU from the socket during the compilation. Alternatively, if you
-are running SCO Unix, you can reboot and force the FPU to be ignored.
-To do this, type @samp{hd(40)unix auto ignorefpu}.
-
-@item
-On some 386 systems, GNU CC crashes trying to compile @file{enquire.c}.
-This happens on machines that don't have a 387 FPU chip. On 386
-machines, the system kernel is supposed to emulate the 387 when you
-don't have one. The crash is due to a bug in the emulator.
-
-One of these systems is the Unix from Interactive Systems: 386/ix.
-On this system, an alternate emulator is provided, and it does work.
-To use it, execute this command as super-user:
-
-@example
-ln /etc/emulator.rel1 /etc/emulator
-@end example
-
-@noindent
-and then reboot the system. (The default emulator file remains present
-under the name @file{emulator.dflt}.)
-
-Try using @file{/etc/emulator.att}, if you have such a problem on the
-SCO system.
-
-Another system which has this problem is Esix. We don't know whether it
-has an alternate emulator that works.
-
-On NetBSD 0.8, a similar problem manifests itself as these error messages:
-
-@example
-enquire.c: In function `fprop':
-enquire.c:2328: floating overflow
-@end example
-
-@item
-On SCO systems, when compiling GNU CC with the system's compiler,
+On SCO systems, when compiling GCC with the system's compiler,
do not use @samp{-O}. Some versions of the system's compiler miscompile
-GNU CC with @samp{-O}.
+GCC with @samp{-O}.
@cindex @code{genflags}, crash on Sun 4
@item
Sometimes on a Sun 4 you may observe a crash in the program
-@code{genflags} or @code{genoutput} while building GNU CC. This is said to
+@code{genflags} or @code{genoutput} while building GCC. This is said to
be due to a bug in @code{sh}. You can probably get around it by running
@code{genflags} or @code{genoutput} manually and then retrying the
@code{make}.
@item
-On Solaris 2, executables of GNU CC version 2.0.2 are commonly
+On Solaris 2, executables of GCC version 2.0.2 are commonly
available, but they have a bug that shows up when compiling current
-versions of GNU CC: undefined symbol errors occur during assembly if you
+versions of GCC: undefined symbol errors occur during assembly if you
use @samp{-g}.
-The solution is to compile the current version of GNU CC without
+The solution is to compile the current version of GCC without
@samp{-g}. That makes a working compiler which you can use to recompile
with @samp{-g}.
@item
Solaris 2 comes with a number of optional OS packages. Some of these
-packages are needed to use GNU CC fully. If you did not install all
+packages are needed to use GCC fully. If you did not install all
optional packages when installing Solaris, you will need to verify that
-the packages that GNU CC needs are installed.
+the packages that GCC needs are installed.
To check whether an optional package is installed, use
the @code{pkginfo} command. To add an optional package, use the
@code{pkgadd} command. For further details, see the Solaris
documentation.
-For Solaris 2.0 and 2.1, GNU CC needs six packages: @samp{SUNWarc},
+For Solaris 2.0 and 2.1, GCC needs six packages: @samp{SUNWarc},
@samp{SUNWbtool}, @samp{SUNWesu}, @samp{SUNWhea}, @samp{SUNWlibm}, and
@samp{SUNWtoo}.
-For Solaris 2.2, GNU CC needs an additional seventh package: @samp{SUNWsprot}.
+For Solaris 2.2, GCC needs an additional seventh package: @samp{SUNWsprot}.
@item
On Solaris 2, trying to use the linker and other tools in
-@file{/usr/ucb} to install GNU CC has been observed to cause trouble.
+@file{/usr/ucb} to install GCC has been observed to cause trouble.
For example, the linker may hang indefinitely. The fix is to remove
@file{/usr/ucb} from your @code{PATH}.
optional, and there should not be a warning about their absence.
@item
-In Ultrix 4.0 on the MIPS machine, @file{stdio.h} does not work with GNU
-CC at all unless it has been fixed with @code{fixincludes}. This causes
-problems in building GNU CC. Once GNU CC is installed, the problems go
-away.
-
-To work around this problem, when making the stage 1 compiler, specify
-this option to Make:
-
-@example
-GCC_FOR_TARGET="./xgcc -B./ -I./include"
-@end example
-
-When making stage 2 and stage 3, specify this option:
-
-@example
-CFLAGS="-g -I./include"
-@end example
-
-@item
Users have reported some problems with version 2.0 of the MIPS
compiler tools that were shipped with Ultrix 4.1. Version 2.10
which came with Ultrix 4.2 seems to work fine.
when linking code that uses @code{alloca} against shared
libraries on RISC-OS 5.0, and DEC's OSF/1 systems. This is a bug
in the linker, that is supposed to be fixed in future revisions.
-To protect against this, GNU CC passes @samp{-non_shared} to the
+To protect against this, GCC passes @samp{-non_shared} to the
linker unless you pass an explicit @samp{-shared} or
@samp{-call_shared} switch.
that too indicates a problem with disk space, ULIMIT, or @code{MAXUMEM}.
@item
-Current GNU CC versions probably do not work on version 2 of the NeXT
+Current GCC versions probably do not work on version 2 of the NeXT
operating system.
@item
@item
On the Tower models 4@var{n}0 and 6@var{n}0, by default a process is not
-allowed to have more than one megabyte of memory. GNU CC cannot compile
+allowed to have more than one megabyte of memory. GCC cannot compile
itself (or many other programs) with @samp{-O} in that much memory.
To solve this problem, reconfigure the kernel adding the following line
@item
On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a bug
-in the assembler that must be fixed before GNU CC can be built. This
+in the assembler that must be fixed before GCC can be built. This
bug manifests itself during the first stage of compilation, while
building @file{libgcc2.a}:
./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
use BASH (the GNU shell) to run @code{fixproto}.
@item
-Some versions of the Pyramid C compiler are reported to be unable to
-compile GNU CC. You must use an older version of GNU CC for
-bootstrapping. One indication of this problem is if you get a crash
-when GNU CC compiles the function @code{muldi3} in file @file{libgcc2.c}.
-
-You may be able to succeed by getting GNU CC version 1, installing it,
-and using it to compile GNU CC version 2. The bug in the Pyramid C
-compiler does not seem to affect GNU CC version 1.
-
-@item
There may be similar problems on System V Release 3.1 on 386 systems.
@item
On the Intel Paragon (an i860 machine), if you are using operating
system version 1.0, you will get warnings or errors about redefinition
-of @code{va_arg} when you build GNU CC.
+of @code{va_arg} when you build GCC.
If this happens, then you need to link most programs with the library
@file{iclib.a}. You must also modify @file{stdio.h} as follows: before
These problems don't exist in operating system version 1.1.
@item
-On the Altos 3068, programs compiled with GNU CC won't work unless you
+On the Altos 3068, programs compiled with GCC won't work unless you
fix a kernel bug. This happens using system versions V.2.2 1.0gT1 and
V.2.2 1.0e and perhaps later versions as well. See the file
@file{README.ALTOS}.
at run time.
@item
-Older GDB versions sometimes fail to read the output of GNU CC version
+Older GDB versions sometimes fail to read the output of GCC version
2. If you have trouble, get GDB version 4.4 or later.
@item
@cindex DBX
-DBX rejects some files produced by GNU CC, though it accepts similar
+DBX rejects some files produced by GCC, though it accepts similar
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
Use of @samp{-I/usr/include} may cause trouble.
-Many systems come with header files that won't work with GNU CC unless
+Many systems come with header files that won't work with GCC unless
corrected by @code{fixincludes}. The corrected header files go in a new
-directory; GNU CC searches this directory before @file{/usr/include}.
-If you use @samp{-I/usr/include}, this tells GNU CC to search
+directory; GCC searches this directory before @file{/usr/include}.
+If you use @samp{-I/usr/include}, this tells GCC to search
@file{/usr/include} earlier on, before the corrected headers. The
result is that you get the uncorrected header files.
-I/usr/local/lib/gcc-lib/@var{target}/@var{version}/include -I/usr/include
@end smallexample
-For C++ programs, GNU CC also uses a special directory that defines C++
+For C++ programs, GCC also uses a special directory that defines C++
interfaces to standard C subroutines. This directory is meant to be
searched @emph{before} other standard include directories, so that it
takes precedence. If you are compiling C++ programs and specifying
There is a bug in @code{vfork} on the Sun-4 which causes the registers
of the child process to clobber those of the parent. Because of this,
programs that call @code{vfork} are likely to lose when compiled
-optimized with GNU CC when the child code alters registers which contain
+optimized with GCC when the child code alters registers which contain
C variables in the parent. This affects variables which are live in the
parent across the call to @code{vfork}.
@item
On some SGI systems, when you use @samp{-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 GNU CC.
+Naturally, this does not happen when you use GCC.
You must specify all three options explicitly.
@item
-On a Sparc, GNU CC aligns all values of type @code{double} on an 8-byte
+On a Sparc, GCC aligns all values of type @code{double} on an 8-byte
boundary, and it expects every @code{double} to be so aligned. The Sun
compiler usually gives @code{double} values 8-byte alignment, with one
exception: function arguments of type @code{double} may not be aligned.
As a result, if a function compiled with Sun CC takes the address of an
argument of type @code{double} and passes this pointer of type
-@code{double *} to a function compiled with GNU CC, dereferencing the
+@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
@item
On Solaris, the @code{malloc} function in the @file{libmalloc.a} library
-may allocate memory that is only 4 byte aligned. Since GNU CC on the
+may allocate memory that is only 4 byte aligned. Since GCC on the
Sparc assumes that doubles are 8 byte aligned, this may result in a
fatal signal if doubles are stored in memory allocated by the
@file{libmalloc.a} library.
doubles do not work in Sun OS versions 4.0.3 and earlier, because the
kernel emulator uses an obsolete and incompatible format. Long doubles
do not work in Sun OS version 4.1.1 due to a problem in a Sun library.
-Long doubles do work on Sun OS versions 4.1.2 and higher, but GNU CC
+Long doubles do work on Sun OS versions 4.1.2 and higher, but GCC
does not enable them by default. Long doubles appear to work in Sun OS
5.x (Solaris 2.x).
@item
On HP-UX version 9.01 on the HP PA, the HP compiler @code{cc} does not
-compile GNU CC correctly. We do not yet know why. However, GNU CC
+compile GCC correctly. We do not yet know why. However, GCC
compiled on earlier HP-UX versions works properly on HP-UX 9.01 and can
compile itself properly on 9.01.
@item
On the HP PA machine, ADB sometimes fails to work on functions compiled
-with GNU CC. Specifically, it fails to work on functions that use
-@code{alloca} or variable-size arrays. This is because GNU CC doesn't
+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.
In extremely rare cases involving some very large functions you may
receive errors from the HP linker complaining about an out of bounds
unconditional branch offset. This used to occur more often in previous
-versions of GNU CC, but is now exceptionally rare. If you should run
+versions of GCC, but is now exceptionally rare. If you should run
into it, you can work around by making your function smaller.
@item
-GNU CC compiled code sometimes emits warnings from the HP-UX assembler of
+GCC compiled code sometimes emits warnings from the HP-UX assembler of
the form:
@smallexample
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
@item
There is an assembler bug in versions of DG/UX prior to 5.4.2.01 that
-occurs when the @samp{fldcr} instruction is used. GNU CC uses
+occurs when the @samp{fldcr} instruction is used. GCC uses
@samp{fldcr} on the 88100 to serialize volatile memory references. Use
the option @samp{-mno-serialize-volatile} if your version of the
assembler has this bug.
@cindex Alliant
@item
On the Alliant, the system's own convention for returning structures
-and unions is unusual, and is not compatible with GNU CC no matter
+and unions is unusual, and is not compatible with GCC no matter
what options are used.
@cindex RT PC
@item
On the IBM RT PC, the MetaWare HighC compiler (hc) uses a different
convention for structure and union returning. Use the option
-@samp{-mhc-struct-return} to tell GNU CC to use a convention compatible
+@samp{-mhc-struct-return} to tell GCC to use a convention compatible
with it.
@cindex Vax calling convention
by function calls. However, the C compiler uses conventions compatible
with BSD Unix: registers 2 through 5 may be clobbered by function calls.
-GNU CC uses the same convention as the Ultrix C compiler. You can use
+GCC uses the same convention as the Ultrix C compiler. You can use
these options to produce code compatible with the Fortran compiler:
@smallexample
@end smallexample
@item
-On the WE32k, you may find that programs compiled with GNU CC do not
+On the WE32k, you may find that programs compiled with GCC do not
work with the standard shared C library. You may need to link with
the ordinary C compiler. If you do so, you must specify the following
options:
The first specifies where to find the library @file{libgcc.a}
specified with the @samp{-lgcc} option.
-GNU CC does linking by invoking @code{ld}, just as @code{cc} does, and
+GCC does linking by invoking @code{ld}, just as @code{cc} does, and
there is no reason why it @emph{should} matter which compilation program
you use to invoke @code{ld}. If someone tracks this problem down,
it can probably be fixed easily.
on. If you think this may be happening to you, try using the GNU
assembler; GAS version 2.1 supports ECOFF on Irix.
-Or use the @samp{-noasmopt} option when you compile GNU CC with itself,
+Or use the @samp{-noasmopt} option when you compile GCC with itself,
and then again when you compile your program. (This is a temporary
kludge to turn off assembler optimization on Irix.) If this proves to
be what you need, edit the assembler spec in the file @file{specs} so
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.
-You can prevent this problem by linking GNU CC with the GNU malloc
+You can prevent this problem by linking GCC with the GNU malloc
(which thus replaces the malloc that comes with the system). GNU malloc
is available as a separate package, and also in the file
@file{src/gmalloc.c} in the GNU Emacs 19 distribution.
If you have installed GNU malloc as a separate library package, use this
-option when you relink GNU CC:
+option when you relink GCC:
@example
MALLOC=/usr/local/lib/libgmalloc.a
Alternatively, if you have compiled @file{gmalloc.c} from Emacs 19, copy
the object file to @file{gmalloc.o} and use this option when you relink
-GNU CC:
+GCC:
@example
MALLOC=gmalloc.o
@end itemize
@node Incompatibilities
-@section Incompatibilities of GNU CC
-@cindex incompatibilities of GNU CC
+@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
@cindex read-only strings
@cindex shared strings
@item
-GNU CC normally makes string constants read-only. If several
-identical-looking string constants are used, GNU CC stores only one
+GCC normally makes string constants read-only. If several
+identical-looking string constants are used, GCC stores only one
copy of the string.
@cindex @code{mktemp}, and constant strings
The best solution to these problems is to change the program to use
@code{char}-array variables with initialization strings for these
purposes instead of string constants. But if this is not possible,
-you can use the @samp{-fwritable-strings} flag, which directs GNU CC
+you can use the @samp{-fwritable-strings} flag, which directs GCC
to handle string constants the same way most C compilers do.
@samp{-traditional} also has this effect, among others.
@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
-GNU CC does not substitute macro arguments when they appear inside of
-string constants. For example, the following macro in GNU CC
+GCC does not substitute macro arguments when they appear inside of
+string constants. For example, the following macro in GCC
@example
#define foo(a) "a"
@noindent
will produce output @code{"a"} regardless of what the argument @var{a} is.
-The @samp{-traditional} option directs GNU CC to handle such cases
-(among others) in the old-fashioned (non-ANSI) fashion.
+The @samp{-traditional} option directs GCC to handle such cases
+(among others) in the old-fashioned (non-ISO) fashion.
@cindex @code{setjmp} incompatibilities
@cindex @code{longjmp} incompatibilities
in it.
If you use the @samp{-W} option with the @samp{-O} option, you will
-get a warning when GNU CC thinks such a problem might be possible.
+get a warning when GCC thinks such a problem might be possible.
The @samp{-traditional} option directs GNU C to put variables in
the stack by default, rather than in registers, in functions that
@item
Programs that use preprocessing directives in the middle of macro
-arguments do not work with GNU CC. For example, a program like this
+arguments do not work with GCC. For example, a program like this
will not work:
@example
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{+=}. GNU CC, 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.
@cindex apostrophes
@cindex '
@item
-GNU CC complains about unterminated character constants inside of
+GCC complains about unterminated character constants inside of
preprocessing conditionals that fail. Some programs have English
comments enclosed in conditionals that are guaranteed to fail; if these
-comments contain apostrophes, GNU CC will probably report an error. For
+comments contain apostrophes, GCC will probably report an error. For
example, this code would produce an error:
@example
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
When compiling functions that return @code{float}, PCC converts it to
-a double. GNU CC actually returns a @code{float}. If you are concerned
+a double. GCC actually returns a @code{float}. If you are concerned
with PCC compatibility, you should declare your functions to return
@code{double}; you might as well say what you mean.
@cindex structures
@cindex unions
@item
-When compiling functions that return structures or unions, GNU CC
+When compiling functions that return structures or unions, GCC
output code normally uses a method different from that used on most
-versions of Unix. As a result, code compiled with GNU CC cannot call
+versions of Unix. As a result, code compiled with GCC cannot call
a structure-returning function compiled with PCC, and vice versa.
-The method used by GNU CC is as follows: a structure or union which is
+The method used by GCC is as follows: a structure or union which is
1, 2, 4 or 8 bytes long is returned like a scalar. A structure or union
with any other size is stored into an address supplied by the caller
(usually in a special, fixed register, but on some machines it is passed
on the stack). The machine-description macros @code{STRUCT_VALUE} and
-@code{STRUCT_INCOMING_VALUE} tell GNU CC where to pass this address.
+@code{STRUCT_INCOMING_VALUE} tell GCC where to pass this address.
By contrast, PCC on most target machines returns structures and unions
of any size by copying the data into an area of static storage, and then
returning the address of that storage as if it were a pointer value.
The caller must copy the data from that memory area to the place where
-the value is wanted. GNU CC does not use this method because it is
+the value is wanted. GCC does not use this method because it is
slower and nonreentrant.
On some newer machines, PCC uses a reentrant convention for all
-structure and union returning. GNU CC on most of these machines uses a
+structure and union returning. GCC on most of these machines uses a
compatible convention when returning structures and unions in memory,
but still returns small structures and unions in registers.
-You can tell GNU CC to use a compatible convention for all structure and
+You can tell GCC to use a compatible convention for all structure and
union returning with the option @samp{-fpcc-struct-return}.
@cindex preprocessing tokens
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
begins with a digit and is followed by letters, underscores, digits,
-periods and @samp{e+}, @samp{e-}, @samp{E+}, or @samp{E-} character
-sequences.
+periods and @samp{e+}, @samp{e-}, @samp{E+}, @samp{E-}, @samp{p+},
+@samp{p-}, @samp{P+}, or @samp{P-} character sequences. (In strict C89
+mode, the sequences @samp{p+}, @samp{p-}, @samp{P+} and @samp{P-} cannot
+appear in preprocessing numbers.)
To make the above program fragment valid, place whitespace in front of
the minus sign. This whitespace will end the preprocessing number.
@node Fixed Headers
@section Fixed Header Files
-GNU CC needs to install corrected versions of some system header files.
+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 GNU CC unless they are changed. Some have bugs, some are
-incompatible with ANSI C, and some depend on special features of other
+work with GCC unless they are changed. Some have bugs, some are
+incompatible with ISO C, and some depend on special features of other
compilers.
-Installing GNU CC automatically creates and installs the fixed header
+Installing GCC automatically creates and installs the fixed header
files, by running a program called @code{fixincludes} (or for certain
targets an alternative such as @code{fixinc.svr4}). Normally, you
don't need to pay attention to this. But there are cases where it
@itemize @bullet
@item
If you update the system's header files, such as by installing a new
-system version, the fixed header files of GNU CC are not automatically
-updated. The easiest way to update them is to reinstall GNU CC. (If
+system version, the fixed header files of GCC are not automatically
+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.)
as to use the proper set, but you'll have to do this by hand.
@item
-On Lynxos, GNU CC by default does not fix the header files. This is
+On Lynxos, GCC by default does not fix the header files. This is
because bugs in the shell cause the @code{fixincludes} script to fail.
This means you will encounter problems due to bugs in the system header
-files. It may be no comfort that they aren't GNU CC's fault, but it
+files. It may be no comfort that they aren't GCC's fault, but it
does mean that there's nothing for us to do about them.
@end itemize
@node Standard Libraries
@section Standard Libraries
-GNU CC 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
function will still return @code{char *}.
If you need a Standard compliant library, then you need to find one, as
-GNU CC 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.
+GCC does not provide one. The GNU C library (called @code{glibc})
+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
Certain local variables aren't recognized by debuggers when you compile
with optimization.
-This occurs because sometimes GNU CC optimizes the variable out of
+This occurs because sometimes GCC optimizes the variable out of
existence. There is no way to tell the debugger how to compute the
value such a variable ``would have had'', and it is not clear that would
-be desirable anyway. So GNU CC simply does not mention the eliminated
+be desirable anyway. So GCC simply does not mention the eliminated
variable when it writes debugging information.
You have to expect a certain amount of disagreement between the
@cindex conflicting types
@cindex scope of declaration
@item
-Users often think it is a bug when GNU CC reports an error for code
+Users often think it is a bug when GCC reports an error for code
like this:
@example
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
volatile but do not use bitfields.
@item
-GNU CC comes with shell scripts to fix certain known problems in system
+GCC comes with shell scripts to fix certain known problems in system
header files. They install corrected copies of various header files in
-a special directory where only GNU CC will normally look for them. The
+a special directory where only GCC will normally look for them. The
scripts adapt to various systems by searching all the system header
files for the problem cases that we know about.
If new system header files are installed, nothing automatically arranges
-to update the corrected header files. You will have to reinstall GNU CC
+to update the corrected header files. You will have to reinstall GCC
to fix the new header files. More specifically, go to the build
directory and delete the files @file{stmp-fixinc} and
@file{stmp-headers}, and the subdirectory @code{include}; then do
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.
@cindex misunderstandings in C++
@cindex surprises in C++
@cindex C++ misunderstandings
-C++ is a complex language and an evolving one, and its standard definition
-(the ANSI C++ draft standard) is also evolving. As a result,
-your C++ compiler may occasionally surprise you, even when its behavior is
-correct. This section discusses some areas that frequently give rise to
-questions of this sort.
+C++ is a complex language and an evolving one, and its standard
+definition (the ISO C++ standard) was only recently completed. As a
+result, your C++ compiler may occasionally surprise you, even when its
+behavior is correct. This section discusses some areas that frequently
+give rise to questions of this sort.
@menu
* Static Definitions:: Static member declarations are not definitions
* Temporaries:: Temporaries may vanish before you expect
+* Copy Assignment:: Copy Assignment operators copy virtual bases twice
@end menu
@node Static Definitions
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:
It is dangerous to use pointers or references to @emph{portions} of a
temporary object. The compiler may very well delete the object before
you expect it to, leaving a pointer to garbage. The most common place
-where this problem crops up is in classes like the libg++
-@code{String} class, that define a conversion function to type
-@code{char *} or @code{const char *}. However, any class that returns
-a pointer to some internal structure is potentially subject to this
-problem.
+where this problem crops up is in classes like string classes,
+especially ones that define a conversion function to type @code{char *}
+or @code{const char *} -- which is one reason why the standard
+@code{string} class requires you to call the @code{c_str} member
+function. However, any class that returns a pointer to some internal
+structure is potentially subject to this problem.
For example, a program may use a function @code{strfunc} that returns
-@code{String} objects, and another function @code{charfunc} that
+@code{string} objects, and another function @code{charfunc} that
operates on pointers to @code{char}:
@example
-String strfunc ();
+string strfunc ();
void charfunc (const char *);
+
+void
+f ()
+@{
+ const char *p = strfunc().c_str();
+ ...
+ charfunc (p);
+ ...
+ charfunc (p);
+@}
@end example
@noindent
-In this situation, it may seem natural to write @w{@samp{charfunc
-(strfunc ());}} based on the knowledge that class @code{String} has an
-explicit conversion to @code{char} pointers. However, what really
-happens is akin to @samp{charfunc (@w{strfunc ()}.@w{convert ()});},
-where the @code{convert} method is a function to do the same data
-conversion normally performed by a cast. Since the last use of the
-temporary @code{String} object is the call to the conversion function,
-the compiler may delete that object before actually calling
-@code{charfunc}. The compiler has no way of knowing that deleting the
-@code{String} object will invalidate the pointer. The pointer then
-points to garbage, so that by the time @code{charfunc} is called, it
-gets an invalid argument.
+In this situation, it may seem reasonable to save a pointer to the C
+string returned by the @code{c_str} member function and use that rather
+than call @code{c_str} repeatedly. However, the temporary string
+created by the call to @code{strfunc} is destroyed after @code{p} is
+initialized, at which point @code{p} is left pointing to freed memory.
Code like this may run successfully under some other compilers,
-especially those that delete temporaries relatively late. However, the
-GNU C++ behavior is also standard-conforming, so if your program depends
-on late destruction of temporaries it is not portable.
+particularly obsolete cfront-based compilers that delete temporaries
+along with normal local variables. However, the GNU C++ behavior is
+standard-conforming, so if your program depends on late destruction of
+temporaries it is not portable.
+
+The safe way to write such code is to give the temporary a name, which
+forces it to remain until the end of the scope of the name. For
+example:
+
+@example
+string& tmp = strfunc ();
+charfunc (tmp.c_str ());
+@end example
-If you think this is surprising, you should be aware that the ANSI C++
-committee continues to debate the lifetime-of-temporaries problem.
+@node Copy Assignment
+@subsection Implicit Copy-Assignment for Virtual Bases
-For now, at least, the safe way to write such code is to give the
-temporary a name, which forces it to remain until the end of the scope of
-the name. For example:
+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:
@example
-String& tmp = strfunc ();
-charfunc (tmp);
+struct Base@{
+ char *name;
+ Base(char *n) : name(strdup(n))@{@}
+ Base& operator= (const Base& other)@{
+ free (name);
+ name = strdup (other.name);
+ @}
+@};
+
+struct A:virtual Base@{
+ int val;
+ A():Base("A")@{@}
+@};
+
+struct B:virtual Base@{
+ int bval;
+ B():Base("B")@{@}
+@};
+
+struct Derived:public A, public B@{
+ Derived():Base("Derived")@{@}
+@};
+
+void func(Derived &d1, Derived &d2)
+@{
+ d1 = d2;
+@}
@end example
+The C++ standard specifies that @samp{Base::Base} is only called once
+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
+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
+operator, the application can define whether and how the virtual base
+subobject is assigned.
+
@node Protoize Caveats
@section Caveats of using @code{protoize}
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
@section Certain Changes We Don't Want to Make
This section lists changes that people frequently request, but which
-we do not make because we think GNU CC is better without them.
+we do not make because we think GCC is better without them.
@itemize @bullet
@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.
program to run on more than one type of machine cannot possibly benefit
from this kind of compatibility.
-This is why GNU CC does and will treat plain bitfields in the same
+This is why GCC does and will treat plain bitfields in the same
fashion on all types of machines (by default).
There are some arguments for making bitfields unsigned by default on all
machines. If, for example, this becomes a universal de facto standard,
-it would make sense for GNU CC to go along with it. This is something
+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
@item
Undefining @code{__STDC__} when @samp{-ansi} is not used.
-Currently, GNU CC defines @code{__STDC__} as long as you don't use
+Currently, GCC defines @code{__STDC__} as long as you don't use
@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.
-GNU CC normally defines @code{__STDC__} to be 1, and in addition
-defines @code{__STRICT_ANSI__} if you specify the @samp{-ansi} option.
+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.
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. GNU CC follows the host convention when
+conformance to the C Standard. GCC follows the host convention when
processing system include files, but when processing user files it follows
the usual GNU C convention.
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
Deleting ``empty'' loops.
-GNU CC does not delete ``empty'' loops because the most likely reason
-you would put one in a program is to have a delay. Deleting them will
-not make real programs run any faster, so it would be pointless.
+Historically, GCC has not deleted ``empty'' loops under the
+assumption that the most likely reason you would put one in a program is
+to have a delay, so deleting them will not make real programs run any
+faster.
-It would be different if optimization of a nonempty loop could produce
-an empty one. But this generally can't happen.
+However, the rationale here is that optimization of a nonempty loop
+cannot produce an empty one, which holds for C but is not always the
+case for C++.
+
+Moreover, with @samp{-funroll-loops} small ``empty'' loops are already
+removed, so the current behavior is both sub-optimal and inconsistent
+and will change in the future.
@item
Making side effects happen in the same order as in some other compiler.
@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
@itemize @w{}
@item
@emph{Errors} report problems that make it impossible to compile your
-program. GNU CC reports errors with the source file name and line
+program. GCC reports errors with the source file name and line
number where the problem is apparent.
@item
options (for instance, @samp{-Wall} requests a variety of useful
warnings).
-GNU CC always tries to compile your program if possible; it never
+GCC always tries to compile your program if possible; it never
gratuitously rejects a program whose meaning is clear merely because
(for instance) it fails to conform to a standard. In some cases,
however, the C and C++ standards specify that certain extensions are
forbidden, and a diagnostic @emph{must} be issued by a conforming
-compiler. The @samp{-pedantic} option tells GNU CC to issue warnings in
+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
@cindex bugs
@cindex reporting bugs
-Your bug reports play an essential role in making GNU CC reliable.
+Your bug reports play an essential role in making GCC reliable.
When you encounter a problem, the first thing to do is to see if it is
already known. @xref{Trouble}. If it isn't known, then you should
Reporting a bug may help you by bringing a solution to your problem, or
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 GNU CC work
-better. Bug reports are your contribution to the maintenance of GNU CC.
+to help the entire community by making the next version of GCC work
+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
* 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.
-* Patches: Sending Patches. How to send a patch for GNU CC.
+* 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 example, in many nonoptimizing compilers, you can write @samp{x;}
at the end of a function instead of @samp{return x;}, with the same
results. But the value of the function is undefined if @code{return}
-is omitted; it is not a bug when GNU CC produces different results.
+is omitted; it is not a bug when GCC produces different results.
Problems often result from expressions with two increment operators,
as in @code{f (*p++, *p++)}. Your previous compiler might have
-interpreted that expression the way you intended; GNU CC might
+interpreted that expression the way you intended; GCC might
interpret it another way. Neither compiler is wrong. The bug is
in your code.
for traditional practice''.
@item
-If you are an experienced user of C or C++ compilers, your suggestions
-for improvement of GNU CC or GNU C++ 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 egcs-bugs@@cygnus.com
-Send bug reports for GNU C to @samp{egcs-bugs@@cygnus.com}.
-
-@kindex egcs-bugs@@cygnus.com
-@kindex egcs-bugs@@cygnus.com
-Send bug reports for GNU C++ and the C++ runtime libraries to
-@samp{egcs-bugs@@cygnus.com}.
+@kindex gcc-bugs@@gcc.gnu.org or bug-gcc@@gnu.org
+Send bug reports for the GNU Compiler Collection to
+@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.
-Often people think of posting bug reports to the newsgroup instead of
-mailing them. This appears to work, but it has one problem which can be
-crucial: a newsgroup posting does not contain a mail path back to the
-sender. Thus, if maintainers need more information, they may be unable
-to reach you. For this reason, you should always send bug reports by
-mail to the proper mailing list.
+Please read @uref{http://gcc.gnu.org/bugs.html} for additional and/or
+more up-to-date bug reporting instructions before you post a bug report.
-As a last resort, send bug reports on paper to:
-
-@example
-GNU Compiler Bugs
-Free Software Foundation
-59 Temple Place - Suite 330
-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
us to track which bugs have been fixed and to forward your bugs reports
to the appropriate maintainer.
-If you include source code in your message, you can send it as clear
-text if it is small. If the message is larger, you may compress it using
-@file{gzip}, @file{bzip2}, or @file{pkzip}. Please be aware that sending
-compressed files needs an additional binary-safe mechanism such as
-@code{MIME} or @code{uuencode}. There is a 40k message limit on the
-@samp{egcs-bugs@@cygnus.com} mailing list at the time of this writing
-(August 1998).
-
To enable someone to investigate the bug, you should include all these
things:
@itemize @bullet
@item
-The version of GNU CC. You can get this by running it with the
+The version of GCC. You can get this by running it with the
@samp{-v} option.
Without this, we won't know whether there is any point in looking for
-the bug in the current version of GNU CC.
+the bug in the current version of GCC.
@item
A complete input file that will reproduce the bug. If the bug is in the
frequently depend on every little detail of the function they happen in.
Even if the input file that fails comes from a GNU program, you should
-still send the complete test case. Don't ask the GNU CC maintainers to
+still send the complete test case. Don't ask the GCC maintainers to
do the extra work of obtaining the program in question---they are all
overworked as it is. Also, the problem may depend on what is in the
-header files on your system; it is unreliable for the GNU CC maintainers
+header files on your system; it is unreliable for the GCC maintainers
to try the problem with the header files available to them. By sending
CPP output, you can eliminate this source of uncertainty and save us
a certain percentage of wild goose chases.
@item
-The command arguments you gave GNU CC or GNU C++ to compile that example
+The command arguments you gave GCC to compile that example
and observe the bug. For example, did you use @samp{-O}? To guarantee
you won't omit something important, list all the options.
@item
Details of any other deviations from the standard procedure for installing
-GNU CC.
+GCC.
@item
A description of what behavior you observe that you believe is
not know whether the bug was happening. We would not be able to draw
any conclusion from our observations.
-If the problem is a diagnostic when compiling GNU CC with some other
+If the problem is a diagnostic when compiling GCC with some other
compiler, say whether it is a warning or an error.
Often the observed symptom is incorrect output when your program is run.
bug in the program itself.
@item
-If you send examples of assembler code output from GNU CC or GNU C++,
+If you send examples of assembler code output from GCC,
please use @samp{-g} when you make them. The debugging information
includes source line numbers which are essential for correlating the
output with the input.
@item
-If you wish to mention something in the GNU CC source, refer to it by
+If you wish to mention something in the GCC source, refer to it by
context, not by line number.
The line numbers in the development sources don't match those in your
@cindex backtrace for bug reports
For example, many people send just a backtrace, but that is never
useful by itself. A simple backtrace with arguments conveys little
-about GNU CC because the compiler is largely data-driven; the same
+about GCC because the compiler is largely data-driven; the same
functions are called over and over for different RTL insns, doing
different things depending on the details of the insn.
Of course, if you can find a simpler example to report @emph{instead} of
the original one, that is a convenience. Errors in the output will be
easier to spot, running under the debugger will take less time, etc.
-Most GNU CC bugs involve just one function, so the most straightforward
+Most GCC bugs involve just one function, so the most straightforward
way to simplify an example is to delete all the function definitions
except the one where the bug occurs. Those earlier in the file may be
replaced by external declarations if the crucial function depends on
patch is all we need. We might see problems with your patch and decide
to fix the problem another way, or we might not understand it at all.
-Sometimes with a program as complicated as GNU CC it is very hard to
+Sometimes with a program as complicated as GCC it is very hard to
construct an example that will make the program follow a certain path
through the code. If you don't send the example, we won't be able to
construct one, so we won't be able to verify that the bug is fixed.
we should be able to reproduce the crash ourselves.
@end itemize
-@node Sending Patches,, Bug Reporting, Bugs
-@section Sending Patches for GNU CC
+@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 bug report
-mailing list, @code{egcs-bugs@@cygnus.com}.
+compiler, that is very helpful. Send suggested fixes to the patches
+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
People often suggest fixing a problem by changing machine-independent
files such as @file{toplev.c} to do something special that a particular
system needs. Sometimes it is totally obvious that such changes would
-break GNU CC for almost all users. We can't possibly make a change like
+break GCC for almost all users. We can't possibly make a change like
that. At best it might tell us how to write another patch that would
solve the problem acceptably.
@end itemize
@node Service
-@chapter How To Get Help with GNU CC
+@chapter How To Get Help with GCC
-If you need help installing, using or changing GNU CC, there are two
+If you need help installing, using or changing GCC, there are two
ways to find it:
@itemize @bullet
@item
Send a message to a suitable network mailing list. First try
-@code{egcs-bugs@@cygnus.com}, and if that brings no response, try
-@code{egcs@@cygnus.com}.
+@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
+@pxref{Bug Reporting}.
@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
-GNU CC 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 GNU CC Development
+@chapter Contributing to GCC Development
-If you would like to help pretest GNU CC releases to assure they work
-well, or if you would like to work on improving GNU CC, please contact
-the maintainers at @code{egcs@@cygnus.com}. A pretester should
-be willing to try to investigate bugs as well as report them.
+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}.
-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@@cygnus.com} before you start; the
-maintainers may be able to suggest ways to make your extension fit in
-better with the rest of GNU CC and with other development plans.
+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 GNU CC on VMS
+@chapter Using GCC on VMS
@c prevent bad page break with this line
-Here is how to use GNU CC on VMS.
+Here is how to use GCC on VMS.
@menu
* Include Files and VMS:: Where the preprocessor looks for the include files.
* Global Declarations:: How to do globaldef, globalref and globalvalue with
- GNU CC.
+ GCC.
* VMS Misc:: Misc information.
@end menu
@cindex include files and VMS
@cindex VMS and include files
@cindex header files and VMS
-Due to the differences between the filesystems of Unix and VMS, GNU CC
+Due to the differences between the filesystems of Unix and VMS, GCC
attempts to translate file names in @samp{#include} into names that VMS
will understand. The basic strategy is to prepend a prefix to the
specification of the include file, convert the whole filename to a VMS
-filename, and then try to open the file. GNU CC tries various prefixes
+filename, and then try to open the file. GCC tries various prefixes
one by one until one of them succeeds:
@enumerate
@end example
@noindent
-are a common source of incompatibility between VAX-C and GNU CC. 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 ANSI C behavior implemented by GNU CC: 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}:
@end example
@noindent
-is actually asking for the file @file{foobar.h}. GNU CC does not
+is actually asking for the file @file{foobar.h}. GCC does not
make this assumption, and instead takes what you ask for literally;
it tries to read the file @file{foobar}. The best way to avoid this
problem is to always specify the desired file extension in your include
directives.
-GNU CC for VMS is distributed with a set of include files that is
+GCC for VMS is distributed with a set of include files that is
sufficient to compile most general purpose programs. Even though the
-GNU CC distribution does not contain header files to define constants
+GCC distribution does not contain header files to define constants
and structures for some VMS system-specific functions, there is no
-reason why you cannot use GNU CC with any of these functions. You first
+reason why you cannot use GCC with any of these functions. You first
may have to generate or create header files, either by using the public
domain utility @code{UNSDL} (which can be found on a DECUS tape), or by
extracting the relevant modules from one of the system macro libraries,
@findex GLOBALDEF
@findex GLOBALVALUEDEF
@findex GLOBALVALUEREF
-GNU CC does not provide the @code{globalref}, @code{globaldef} and
+GCC does not provide the @code{globalref}, @code{globaldef} and
@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
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
@cindex exit status and VMS
@cindex return value of @code{main}
@cindex @code{main} and the exit status
-GNU CC automatically arranges for @code{main} to return 1 by default if
+GCC automatically arranges for @code{main} to return 1 by default if
you fail to specify an explicit return value. This will be interpreted
by VMS as a status code indicating a normal successful completion.
-Version 1 of GNU CC did not provide this default.
+Version 1 of GCC did not provide this default.
-GNU CC 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.
@cindex shared VMS run time system
@cindex @file{VAXCRTL}
-Under previous versions of GNU CC, the generated code would occasionally
+Under previous versions of GCC, the generated code would occasionally
give strange results when linked to the sharable @file{VAXCRTL} library.
Now this should work.
Although the VMS linker does distinguish between upper and lower case
letters in global symbols, most VMS compilers convert all such symbols
into upper case and most run-time library routines also have upper case
-names. To be able to reliably call such routines, GNU CC (by means of
+names. To be able to reliably call such routines, GCC (by means of
the assembler GAS) converts global symbols into upper case like other
VMS compilers. However, since the usual practice in C is to distinguish
-case, GNU CC (via GAS) tries to preserve usual C behavior by augmenting
+case, GCC (via GAS) tries to preserve usual C behavior by augmenting
each name that is not all lower case. This means truncating the name
to at most 23 characters and then adding more characters at the end
which encode the case pattern of those 23. Names which contain at
These macro definitions can be placed in a header file to minimize the
number of changes to your source code.
+
+@node Makefile
+@chapter Makefile Targets
+@cindex makefile targets
+@cindex targets, makefile
+
+@table @code
+@item all
+This is the default target. Depending on what your build/host/target
+configuration is, it coordinates all the things that need to be built.
+
+@item doc
+Produce info-formatted documentation. Also, @code{make dvi} is
+available for DVI-formatted documentation, and @code{make
+generated-manpages} to generate man pages.
+
+@item mostlyclean
+Delete the files made while building the compiler.
+
+@item clean
+That, and all the other files built by @code{make all}.
+
+@item distclean
+That, and all the files created by @code{configure}.
+
+@item extraclean
+That, and any temporary or intermediate files, like emacs backup files.
+
+@item maintainer-clean
+Distclean plus any file that can be generated from other files. Note
+that additional tools may be required beyond what is normally needed to
+build gcc.
+
+@item install
+Installs gcc.
+
+@item uninstall
+Deletes installed files.
+
+@item check
+Run the testsuite. This creates a @file{testsuite} subdirectory that
+has various @file{.sum} and @file{.log} files containing the results of
+the testing. You can run subsets with, for example, @code{make check-gcc}.
+You can specify specific tests by setting RUNTESTFLAGS to be the name
+of the @file{.exp} file, optionally followed by (for some tests) an equals
+and a file wildcard, like:
+
+@example
+make check-gcc RUNTESTFLAGS="execute.exp=19980413-*"
+@end example
+
+Note that running the testsuite may require additional tools be
+installed, such as TCL or dejagnu.
+
+@item bootstrap
+Builds gcc three times - once with the native compiler, once with the
+native-built compiler it just built, and once with the compiler it built
+the second time. In theory, the last two should produce the same
+results, which @code{make compare} can check. Each step of this process
+is called a "stage", and the results of each stage N (N=1..3) are copied
+to a subdirectory @file{stageN/}.
+
+@item bootstrap-lean
+Like @code{bootstrap}, except that the various stages are removed once
+they're no longer needed. This saves disk space.
+
+@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. This will allow you to, for example, quickly rebuild a
+bootstrapped compiler after changing the sources, without having to do a
+full bootstrap.
+
+@item quickstrap
+Rebuilds the most recently built stage. Since each stage requires
+special invocation, using this target means you don't have to keep track
+of which stage you're on or what invocation that stage needs.
+
+@item cleanstrap
+Removed everything (@code{make clean}) and rebuilds (@code{make bootstrap}).
+
+@item stageN (N=1..4)
+For each stage, moves the appropriate files to the stageN subdirectory.
+
+@item unstageN (N=1..4)
+Undoes the corresponding @code{stageN}.
+
+@item restageN (N=1..4)
+Undoes the corresponding @code{stageN} and rebuilds it with the
+appropriate flags.
+
+@item compare
+Compares the results of stages 2 and 3. This ensures that the compiler
+is running properly, since it should produce the same object files
+regardless of how it itself was compiled.
+
+@end table
+
@end ifset
@ifset INTERNALS
@node Portability
-@chapter GNU CC and Portability
+@chapter GCC and Portability
@cindex portability
-@cindex GNU CC and portability
+@cindex GCC and portability
-The main goal of GNU CC was to make a good, fast compiler for machines in
+The main goal of GCC was to make a good, fast compiler for machines in
the class that the GNU system aims to run on: 32-bit machines that address
8-bit bytes and have several general registers. Elegance, theoretical
power and simplicity are only secondary.
-GNU CC gets most of the information about the target machine from a machine
+GCC gets most of the information about the target machine from a machine
description which gives an algebraic formula for each of the machine's
instructions. This is a very clean way to describe the target. But when
the compiler needs information that is difficult to express in this
@cindex endianness
@cindex autoincrement addressing, availability
@findex abort
-GNU CC does not contain machine dependent code, but it does contain code
+GCC does not contain machine dependent code, but it does contain code
that depends on machine parameters such as endianness (whether the most
significant byte has the highest or lowest address of the bytes in a word)
and the availability of autoincrement addressing. In the RTL-generation
@ifset INTERNALS
@node Interface
-@chapter Interfacing to GNU CC Output
-@cindex interfacing to GNU CC output
+@chapter Interfacing to GCC Output
+@cindex interfacing to GCC output
@cindex run-time conventions
@cindex function call conventions
@cindex conventions, run-time
-GNU CC is normally configured to use the same function calling convention
+GCC is normally configured to use the same function calling convention
normally in use on the target system. This is done with the
machine-description macros described (@pxref{Target Macros}).
@cindex returning structures and unions
However, returning of structure and union values is done differently on
some target machines. As a result, functions compiled with PCC
-returning such types cannot be called from code compiled with GNU CC,
+returning such types cannot be called from code compiled with GCC,
and vice versa. This does not cause trouble often because few Unix
library routines return structures or unions.
-GNU CC code returns structures and unions that are 1, 2, 4 or 8 bytes
+GCC code returns structures and unions that are 1, 2, 4 or 8 bytes
long in the same registers used for @code{int} or @code{double} return
-values. (GNU CC typically allocates variables of such types in
+values. (GCC typically allocates variables of such types in
registers also.) Structures and unions of other sizes are returned by
storing them into an address passed by the caller (usually in a
register). The machine-description macros @code{STRUCT_VALUE} and
-@code{STRUCT_INCOMING_VALUE} tell GNU CC where to pass this address.
+@code{STRUCT_INCOMING_VALUE} tell GCC where to pass this address.
By contrast, PCC on most target machines returns structures and unions
of any size by copying the data into an area of static storage, and then
returning the address of that storage as if it were a pointer value.
The caller must copy the data from that memory area to the place where
-the value is wanted. This is slower than the method used by GNU CC, and
+the value is wanted. This is slower than the method used by GCC, and
fails to be reentrant.
On some target machines, such as RISC machines and the 80386, the
standard system convention is to pass to the subroutine the address of
-where to return the value. On these machines, GNU CC has been
+where to return the value. On these machines, GCC has been
configured to be compatible with the standard compiler, when this method
is used. It may not be compatible for structures of 1, 2, 4 or 8 bytes.
@cindex argument passing
@cindex passing arguments
-GNU CC uses the system's standard convention for passing arguments. On
+GCC uses the system's standard convention for passing arguments. On
some machines, the first few arguments are passed in registers; in
others, all are passed on the stack. It would be possible to use
registers for argument passing on any machine, and this would probably
result in a significant speedup. But the result would be complete
incompatibility with code that follows the standard convention. So this
-change is practical only if you are switching to GNU CC as the sole C
+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 GNU CC.
+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
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 GNU CC promises to do,
+values after a @code{longjmp}. And this is all GCC promises to do,
because it is very difficult to restore register variables correctly, and
-one of GNU CC's features is that it can put variables in registers without
+one of GCC's features is that it can put variables in registers without
your asking it to.
If you want a variable to be unaltered by @code{longjmp}, and you don't
@cindex arithmetic libraries
@cindex math libraries
-Code compiled with GNU CC may call certain library routines. Most of
+Code compiled with GCC may call certain library routines. Most of
them handle arithmetic for which there are no instructions. This
includes multiply and divide on some machines, and floating point
operations on any machine for which floating point support is disabled
function call interface is used for calling the library routines.
These library routines should be defined in the library @file{libgcc.a},
-which GNU CC automatically searches whenever it links a program. On
+which GCC automatically searches whenever it links a program. On
machines that have multiply and divide instructions, if hardware
floating point is in use, normally @file{libgcc.a} is not needed, but it
is searched just in case.
corresponding C arithmetic operator. As long as the file is compiled
with another C compiler, which supports all the C arithmetic operators,
this file will work portably. However, @file{libgcc1.c} does not work if
-compiled with GNU CC, because each arithmetic function would compile
+compiled with GCC, because each arithmetic function would compile
into a call to itself!
@end ifset
@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.
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 GNU CC. 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{.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
this pass. This dump file's name is made by appending @samp{.combine}
to the input file name.
+@cindex register movement
+@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 then attempts
+to change the registers used by the instruction to avoid the move
+instruction.
+
+The option @samp{-dN} causes a debugging dump of the RTL code after
+this pass. This dump file's name is made by appending @samp{.regmove}
+to the input file name.
+
@cindex instruction scheduling
@cindex scheduling, instruction
@item
this pass. This dump file's name is made by appending @samp{.dbr}
to the input file name.
+@cindex branch shortening
+@item
+Branch shortening. On many RISC machines, branch instructions have a
+limited range. Thus, longer sequences of instructions must be used for
+long branches. In this pass, the compiler figures out what how far each
+instruction will be from each other instruction, and therefore whether
+the usual instructions, or the longer sequences, must be used for each
+branch.
+
@cindex register-to-stack conversion
@item
Conversion from usage of some hard registers to usage of a register
is running, unlike the definitions in @file{@var{machine}.h}, which
describe the machine for which the compiler is producing output. Most
of the values in @file{xm-@var{machine}.h} are actually the same on all
-machines that GNU CC runs on, so large parts of all configuration files
+machines that GCC runs on, so large parts of all configuration files
are identical. But there are some macros that vary:
@table @code
@findex FATAL_EXIT_CODE
@item FATAL_EXIT_CODE
A C expression for the status code to be returned when the compiler
-exits after serious errors.
+exits after serious errors. The default is the system-provided macro
+@samp{EXIT_FAILURE}, or @samp{1} if the system doesn't define that
+macro. Define this macro only if these defaults are incorrect.
@findex SUCCESS_EXIT_CODE
@item SUCCESS_EXIT_CODE
A C expression for the status code to be returned when the compiler
-exits without serious errors.
+exits without serious errors. (Warnings are not serious errors.) The
+default is the system-provided macro @samp{EXIT_SUCCESS}, or @samp{0} if
+the system doesn't define that macro. Define this macro only if these
+defaults are incorrect.
@findex HOST_WORDS_BIG_ENDIAN
@item HOST_WORDS_BIG_ENDIAN
Defined if the host machine stores words of multi-word values in
-big-endian order. (GNU CC does not depend on the host byte ordering
+big-endian order. (GCC does not depend on the host byte ordering
within a word.)
@findex HOST_FLOAT_WORDS_BIG_ENDIAN
@end example
@noindent
-so that when the compiler is compiled with GNU CC it uses the more
+so that when the compiler is compiled with GCC it uses the more
efficient built-in @code{alloca} function.
@item FUNCTION_CONVERSION_BUG
@findex MULTIBYTE_CHARS
@item MULTIBYTE_CHARS
Define this macro to enable support for multibyte characters in the
-input to GNU CC. 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
-prototypes, even if it doesn't define __STDC__, or define
-it to be 0 if you do not want any prototypes used in compiling
-GNU CC. If @samp{USE_PROTOTYPES} is not defined, it will be
-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
-GNU CC. 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
@item DIR_SEPARATOR
If your system uses some character other than slash to separate
directory names within a file specification, define this macro to be a C
-character constant specifying that character. When GNU CC displays file
-names, the character you specify will be used. GNU CC will test for
+character constant specifying that character. When GCC displays file
+names, the character you specify will be used. GCC will test for
both slash and the character you specify when parsing filenames.
@findex OBJECT_SUFFIX
@item OBJECT_SUFFIX
Define this macro to be a C string representing the suffix for object
-files on your machine. If you do not define this macro, GNU CC will use
+files on your machine. If you do not define this macro, GCC will use
@samp{.o} as the suffix for object files.
@findex EXECUTABLE_SUFFIX
@item EXECUTABLE_SUFFIX
Define this macro to be a C string representing the suffix for executable
-files on your machine. If you do not define this macro, GNU CC will use
+files on your machine. If you do not define this macro, GCC will use
the null string as the suffix for object files.
+@findex NO_AUTO_EXE_SUFFIX
+@item NO_AUTO_EXE_SUFFIX
+Define this macro if executable files on your machine have a suffix, but
+the compiler driver should not automatically append it to the output file
+name, if user hasn't specified one.
+
+@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
@findex bcmp
In addition, configuration files for system V define @code{bcopy},
@code{bzero} and @code{bcmp} as aliases. Some files define @code{alloca}
-as a macro when compiled with GNU CC, in order to take advantage of the
-benefit of GNU CC's built-in @code{alloca}.
+as a macro when compiled with GCC, in order to take advantage of the
+benefit of GCC's built-in @code{alloca}.
@node Fragments
@chapter Makefile Fragments
@cindex makefile fragment
-When you configure GNU CC using the @file{configure} script
+When you configure GCC using the @file{configure} script
(@pxref{Installation}), it will construct the file @file{Makefile} from
the template file @file{Makefile.in}. When it does this, it will
incorporate makefile fragment files from the @file{config} directory,
A list of source file names to be compiled or assembled and inserted
into @file{libgcc.a}.
+@findex Floating Point Emulation
+@item Floating Point Emulation
+To have GCC include software floating point libraries in @file{libgcc.a}
+define @code{FPBIT} and @code{DPBIT} along with a few rules as follows:
+@smallexample
+# We want fine grained libraries, so use the new code to build the
+# floating point emulation libraries.
+FPBIT = fp-bit.c
+DPBIT = dp-bit.c
+
+
+fp-bit.c: $(srcdir)/config/fp-bit.c
+ echo '#define FLOAT' > fp-bit.c
+ cat $(srcdir)/config/fp-bit.c >> fp-bit.c
+
+dp-bit.c: $(srcdir)/config/fp-bit.c
+ cat $(srcdir)/config/fp-bit.c > dp-bit.c
+@end smallexample
+
+You may need to provide additional #defines at the beginning of @file{fp-bit.c}
+and @file{dp-bit.c} to control target endianness and other options.
+
+
@findex CRTSTUFF_T_CFLAGS
@item CRTSTUFF_T_CFLAGS
Special flags used when compiling @file{crtstuff.c}.
@findex MULTILIB_OPTIONS
@item MULTILIB_OPTIONS
-For some targets, invoking GNU CC in different ways produces objects
-that can not be linked together. For example, for some targets GNU CC
+For some targets, invoking GCC in different ways produces objects
+that can not be linked together. For example, for some targets GCC
produces both big and little endian code. For these targets, you must
arrange for multiple versions of @file{libgcc.a} to be compiled, one for
-each set of incompatible options. When GNU CC invokes the linker, it
+each set of incompatible options. When GCC invokes the linker, it
arranges to link in the right version of @file{libgcc.a}, based on
the command line options used.
@findex MULTILIB_MATCHES
@item MULTILIB_MATCHES
Sometimes the same option may be written in two different ways. If an
-option is listed in @code{MULTILIB_OPTIONS}, GNU CC needs to know about
+option is listed in @code{MULTILIB_OPTIONS}, GCC needs to know about
any synonyms. In that case, set @code{MULTILIB_MATCHES} to a list of
items of the form @samp{option=option} to describe all relevant
synonyms. For example, @samp{m68000=mc68000 m68020=mc68020}.
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
a program contributes very little; maintaining the standard version of a
program for the whole community contributes much. Easy new ports
contribute little, since someone else would surely do them; difficult
-ports such as adding a new CPU to the GNU C compiler contribute more;
+ports such as adding a new CPU to the GNU Compiler Collection contribute more;
major new features or packages contribute the most.
By establishing the idea that supporting further development is ``the
@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
@smallexample
@var{one line to give the program's name and a brief idea of what it does.}
-Copyright (C) 19@var{yy} @var{name of author}
+Copyright (C) @var{yyyy} @var{name of author}
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
when it starts in an interactive mode:
@smallexample
-Gnomovision version 69, Copyright (C) 19@var{yy} @var{name of author}
+Gnomovision version 69, Copyright (C) @var{yyyy} @var{name of author}
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
type `show w'.
This is free software, and you are welcome to redistribute it
Public License instead of this License.
@node Contributors
-@unnumbered Contributors to GNU CC
+@unnumbered Contributors to GCC
@cindex contributors
-
-In addition to Richard Stallman, several people have written parts
-of GNU CC.
-
-@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 GNU CC to VMS.
-
-@item
-Alex Crain provided changes for the 3b1.
-
-@item
-Greg Satz and Chris Hanson assisted in making GNU CC 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 GNU CC to the Mips cpu.
-
-@item
-Devon Bowen, Dale Wiles and Kevin Zachmann ported GNU CC to the Tahoe.
-
-@item
-Jonathan Stone wrote the machine description for the Pyramid computer.
-
-@item
-Gary Miller ported GNU CC 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
