1996-09-18 05:35:50 +00:00
|
|
|
\input texinfo @c -*-texinfo-*-
|
1999-08-26 09:30:50 +00:00
|
|
|
@c %**start of header
|
1996-09-18 05:35:50 +00:00
|
|
|
@setfilename gcc.info
|
|
|
|
@c @setfilename usegcc.info
|
|
|
|
@c @setfilename portgcc.info
|
|
|
|
@c To produce the full manual, use the "gcc.info" setfilename, and
|
|
|
|
@c make sure the following do NOT begin with '@c' (and the @clear lines DO)
|
|
|
|
@set INTERNALS
|
|
|
|
@set USING
|
|
|
|
@c To produce a user-only manual, use the "usegcc.info" setfilename, and
|
|
|
|
@c make sure the following does NOT begin with '@c':
|
|
|
|
@c @clear INTERNALS
|
|
|
|
@c To produce a porter-only manual, use the "portgcc.info" setfilename,
|
|
|
|
@c and make sure the following does NOT begin with '@c':
|
|
|
|
@c @clear USING
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@c (For FSF printing, turn on smallbook, comment out finalout below;
|
1996-09-18 05:35:50 +00:00
|
|
|
@c that is all that is needed.)
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@c 6/27/96 FSF DO wants smallbook fmt for 1st bound edition.
|
|
|
|
@c @smallbook
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@c i also commented out the finalout command, so if there *are* any
|
|
|
|
@c overfulls, you'll (hopefully) see the rectangle in the right hand
|
|
|
|
@c margin. -mew 15june93
|
1999-08-26 09:30:50 +00:00
|
|
|
@c @finalout
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@c NOTE: checks/things to do:
|
1999-08-26 09:30:50 +00:00
|
|
|
@c
|
1996-09-18 05:35:50 +00:00
|
|
|
@c -have bob do a search in all seven files for "mew" (ideally --mew,
|
1999-08-26 09:30:50 +00:00
|
|
|
@c but i may have forgotten the occasional "--"..).
|
|
|
|
@c Just checked... all have `--'! Bob 22Jul96
|
|
|
|
@c Use this to search: grep -n '\-\-mew' *.texi
|
1996-09-18 05:35:50 +00:00
|
|
|
@c -item/itemx, text after all (sub/sub)section titles, etc..
|
|
|
|
@c -consider putting the lists of options on pp 17--> etc in columns or
|
|
|
|
@c some such.
|
|
|
|
@c -spellcheck
|
|
|
|
@c -continuity of phrasing; ie, bit-field vs bitfield in rtl.texi
|
|
|
|
@c -overfulls. do a search for "mew" in the files, and you will see
|
|
|
|
@c overfulls that i noted but could not deal with.
|
|
|
|
@c -have to add text: beginning of chapter 8
|
|
|
|
|
|
|
|
@c
|
|
|
|
@c anything else? --mew 10feb93
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@ifset INTERNALS
|
|
|
|
@ifset USING
|
1999-10-16 06:09:09 +00:00
|
|
|
@settitle Using and Porting the GNU Compiler Collection (GCC)
|
1996-09-18 05:35:50 +00:00
|
|
|
@end ifset
|
|
|
|
@end ifset
|
|
|
|
@c seems reasonable to assume at least one of INTERNALS or USING is set...
|
|
|
|
@ifclear INTERNALS
|
1999-10-16 06:09:09 +00:00
|
|
|
@settitle Using the GNU Compiler Collection
|
1996-09-18 05:35:50 +00:00
|
|
|
@end ifclear
|
|
|
|
@ifclear USING
|
1999-10-16 06:09:09 +00:00
|
|
|
@settitle Porting the GNU Compiler Collection
|
1999-08-26 09:30:50 +00:00
|
|
|
@end ifclear
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@syncodeindex fn cp
|
|
|
|
@syncodeindex vr cp
|
|
|
|
@c %**end of header
|
|
|
|
|
|
|
|
@c Use with @@smallbook.
|
|
|
|
|
|
|
|
@c Cause even numbered pages to be printed on the left hand side of
|
|
|
|
@c the page and odd numbered pages to be printed on the right hand
|
|
|
|
@c side of the page. Using this, you can print on both sides of a
|
|
|
|
@c sheet of paper and have the text on the same part of the sheet.
|
|
|
|
|
|
|
|
@c The text on right hand pages is pushed towards the right hand
|
|
|
|
@c margin and the text on left hand pages is pushed toward the left
|
1999-08-26 09:30:50 +00:00
|
|
|
@c hand margin.
|
1996-09-18 05:35:50 +00:00
|
|
|
@c (To provide the reverse effect, set bindingoffset to -0.75in.)
|
|
|
|
|
|
|
|
@c @tex
|
|
|
|
@c \global\bindingoffset=0.75in
|
|
|
|
@c \global\normaloffset =0.75in
|
|
|
|
@c @end tex
|
|
|
|
|
|
|
|
@ifinfo
|
1999-08-26 09:30:50 +00:00
|
|
|
@dircategory Programming
|
|
|
|
@direntry
|
1999-10-16 06:09:09 +00:00
|
|
|
* gcc: (gcc). The GNU Compiler Collection.
|
1999-08-26 09:30:50 +00:00
|
|
|
@end direntry
|
1996-09-18 05:35:50 +00:00
|
|
|
@ifset INTERNALS
|
|
|
|
@ifset USING
|
|
|
|
This file documents the use and the internals of the GNU compiler.
|
|
|
|
@end ifset
|
|
|
|
@end ifset
|
|
|
|
@ifclear USING
|
|
|
|
This file documents the internals of the GNU compiler.
|
|
|
|
@end ifclear
|
|
|
|
@ifclear INTERNALS
|
|
|
|
This file documents the use of the GNU compiler.
|
|
|
|
@end ifclear
|
|
|
|
|
|
|
|
Published by the Free Software Foundation
|
|
|
|
59 Temple Place - Suite 330
|
|
|
|
Boston, MA 02111-1307 USA
|
|
|
|
|
2001-02-17 08:34:50 +00:00
|
|
|
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000 Free Software Foundation, Inc.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
@ignore
|
|
|
|
Permission is granted to process this file through Tex and print the
|
|
|
|
results, provided the printed document carries copying permission
|
|
|
|
notice identical to this one except for the removal of this paragraph
|
|
|
|
(this paragraph not being relevant to the printed manual).
|
|
|
|
|
|
|
|
@end ignore
|
|
|
|
Permission is granted to copy and distribute modified versions of this
|
|
|
|
manual under the conditions for verbatim copying, provided also that the
|
1999-08-26 09:30:50 +00:00
|
|
|
sections entitled ``GNU General Public License'' and ``Funding for Free
|
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
Permission is granted to copy and distribute translations of this manual
|
|
|
|
into another language, under the above conditions for modified versions,
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
@end ifinfo
|
|
|
|
|
|
|
|
@setchapternewpage odd
|
1999-08-26 09:30:50 +00:00
|
|
|
@c @finalout
|
1996-09-18 05:35:50 +00:00
|
|
|
@titlepage
|
|
|
|
@ifset INTERNALS
|
|
|
|
@ifset USING
|
1999-10-16 06:09:09 +00:00
|
|
|
@center @titlefont{Using and Porting the GNU Compiler Collection}
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@end ifset
|
|
|
|
@end ifset
|
|
|
|
@ifclear INTERNALS
|
1999-10-16 06:09:09 +00:00
|
|
|
@title Using the GNU Compiler Collection
|
1996-09-18 05:35:50 +00:00
|
|
|
@end ifclear
|
|
|
|
@ifclear USING
|
1999-10-16 06:09:09 +00:00
|
|
|
@title Porting the GNU Compiler Collection
|
1996-09-18 05:35:50 +00:00
|
|
|
@end ifclear
|
|
|
|
@sp 2
|
|
|
|
@center Richard M. Stallman
|
|
|
|
@sp 3
|
1999-10-16 06:09:09 +00:00
|
|
|
@center Last updated 28 July 1999
|
1996-09-18 05:35:50 +00:00
|
|
|
@sp 1
|
1999-08-26 09:30:50 +00:00
|
|
|
@c The version number appears five times more in this file.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
@center for gcc-2.95
|
1996-09-18 05:35:50 +00:00
|
|
|
@page
|
|
|
|
@vskip 0pt plus 1filll
|
1999-10-16 06:09:09 +00:00
|
|
|
Copyright @copyright{} 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1998, 1999 Free Software Foundation, Inc.
|
1996-09-18 05:35:50 +00:00
|
|
|
@sp 2
|
1999-10-16 06:09:09 +00:00
|
|
|
For GCC Version 2.95@*
|
1996-09-18 05:35:50 +00:00
|
|
|
@sp 1
|
|
|
|
Published by the Free Software Foundation @*
|
|
|
|
59 Temple Place - Suite 330@*
|
|
|
|
Boston, MA 02111-1307, USA@*
|
1999-08-26 09:30:50 +00:00
|
|
|
Last printed April, 1998.@*
|
1996-09-18 05:35:50 +00:00
|
|
|
Printed copies are available for $50 each.@*
|
1999-08-26 09:30:50 +00:00
|
|
|
ISBN 1-882114-37-X
|
1996-09-18 05:35:50 +00:00
|
|
|
@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.
|
|
|
|
|
|
|
|
Permission is granted to copy and distribute modified versions of this
|
|
|
|
manual under the conditions for verbatim copying, provided also that the
|
1999-08-26 09:30:50 +00:00
|
|
|
sections entitled ``GNU General Public License'' and ``Funding for Free
|
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
Permission is granted to copy and distribute translations of this manual
|
|
|
|
into another language, under the above conditions for modified versions,
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
@end titlepage
|
|
|
|
@page
|
|
|
|
|
|
|
|
@ifinfo
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Top, G++ and GCC,, (DIR)
|
1996-09-18 05:35:50 +00:00
|
|
|
@top Introduction
|
|
|
|
@cindex introduction
|
|
|
|
|
|
|
|
@ifset INTERNALS
|
|
|
|
@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
|
1999-10-16 06:09:09 +00:00
|
|
|
report bugs. It corresponds to GCC version 2.95.
|
1996-09-18 05:35:50 +00:00
|
|
|
@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
|
1999-10-16 06:09:09 +00:00
|
|
|
bugs. It corresponds to GCC version 2.95.
|
1996-09-18 05:35:50 +00:00
|
|
|
@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
|
1999-10-16 06:09:09 +00:00
|
|
|
bugs. It corresponds to GCC version 2.95.
|
1996-09-18 05:35:50 +00:00
|
|
|
@end ifclear
|
|
|
|
|
|
|
|
@end ifinfo
|
|
|
|
@menu
|
|
|
|
@ifset USING
|
|
|
|
* G++ and GCC:: You can compile C or C++ programs.
|
|
|
|
* Invoking GCC:: Command options supported by @samp{gcc}.
|
1999-10-16 06:09:09 +00:00
|
|
|
* Installation:: How to configure, compile and install GCC.
|
1996-09-18 05:35:50 +00:00
|
|
|
* C Extensions:: GNU extensions to the C language family.
|
|
|
|
* C++ Extensions:: GNU extensions to the C++ language.
|
1999-10-16 06:09:09 +00:00
|
|
|
* Gcov:: gcov: a GCC test coverage program.
|
|
|
|
* Trouble:: If you have trouble installing GCC.
|
1996-09-18 05:35:50 +00:00
|
|
|
* Bugs:: How, why and where to report bugs.
|
1999-10-16 06:09:09 +00:00
|
|
|
* Service:: How to find suppliers of support for GCC.
|
|
|
|
* Contributing:: How to contribute to testing and developing GCC.
|
|
|
|
* VMS:: Using GCC on VMS.
|
1996-09-18 05:35:50 +00:00
|
|
|
@end ifset
|
|
|
|
@ifset INTERNALS
|
1999-10-16 06:09:09 +00:00
|
|
|
* Portability:: Goals of GCC's portability features.
|
|
|
|
* Interface:: Function-call interface of GCC output.
|
1996-09-18 05:35:50 +00:00
|
|
|
* 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.
|
|
|
|
* Target Macros:: How to write the machine description C macros.
|
|
|
|
* Config:: Writing the @file{xm-@var{machine}.h} file.
|
|
|
|
* Fragments:: Writing the @file{t-@var{target}} and @file{x-@var{host}} files.
|
|
|
|
@end ifset
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
* Funding:: How to help assure funding for free software.
|
|
|
|
* GNU/Linux:: Linux and the GNU Project
|
|
|
|
|
|
|
|
* Copying:: GNU General Public License says
|
1999-10-16 06:09:09 +00:00
|
|
|
how you can copy and share GCC.
|
|
|
|
* Contributors:: People who have contributed to GCC.
|
1999-08-26 09:30:50 +00:00
|
|
|
|
1996-09-18 05:35:50 +00:00
|
|
|
* Index:: Index of concepts and symbol names.
|
|
|
|
@end menu
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@ifset USING
|
|
|
|
@node G++ and GCC
|
1999-10-16 06:09:09 +00:00
|
|
|
@chapter Compile C, C++, Objective C, or Fortran
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex Objective C
|
1999-10-16 06:09:09 +00:00
|
|
|
The C, C++, and Objective C, and Fortran versions of the compiler are
|
|
|
|
integrated; this is why we use the name ``GNU Compiler Collection''.
|
|
|
|
GCC can compile programs written in C, C++, Objective C, or Fortran.
|
|
|
|
The Fortran compiler is described in a separate manual.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex GCC
|
1999-10-16 06:09:09 +00:00
|
|
|
``GCC'' is a common shorthand term for the GNU Compiler Collection. This is both
|
1999-08-26 09:30:50 +00:00
|
|
|
the most general name for the compiler, and the name used when the
|
1999-10-16 06:09:09 +00:00
|
|
|
emphasis is on compiling C programs (as the abbreviation formerly
|
|
|
|
stood for ``GNU C Compiler'').
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex C++
|
|
|
|
@cindex G++
|
|
|
|
When referring to C++ compilation, it is usual to call the compiler
|
|
|
|
``G++''. Since there is only one compiler, it is also accurate to call
|
|
|
|
it ``GCC'' no matter what the language context; however, the term
|
|
|
|
``G++'' is more useful when the emphasis is on compiling C++ programs.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
We use the name ``GCC'' to refer to the compilation system as a
|
1999-08-26 09:30:50 +00:00
|
|
|
whole, and more specifically to the language-independent part of the
|
|
|
|
compiler. For example, we refer to the optimization options as
|
1999-10-16 06:09:09 +00:00
|
|
|
affecting the behavior of ``GCC'' or sometimes just ``the compiler''.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
built in subdirectories of GCC and link to it. The result is an
|
1999-08-26 09:30:50 +00:00
|
|
|
integrated compiler that can compile programs written in C, C++,
|
|
|
|
Objective C, or any of the languages for which you have installed front
|
|
|
|
ends.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
In this manual, we only discuss the options for the C, Objective-C, and
|
1999-10-16 06:09:09 +00:00
|
|
|
C++ compilers and those of the GCC core. Consult the documentation
|
1999-08-26 09:30:50 +00:00
|
|
|
of the other front ends for the options to use when compiling programs
|
|
|
|
written in other languages.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex compiler compared to C++ preprocessor
|
|
|
|
@cindex intermediate C version, nonexistent
|
|
|
|
@cindex C intermediate output, nonexistent
|
|
|
|
G++ is a @emph{compiler}, not merely a preprocessor. G++ builds object
|
|
|
|
code directly from your C++ program source. There is no intermediate C
|
|
|
|
version of the program. (By contrast, for example, some other
|
|
|
|
implementations use a program that generates a C program from your C++
|
|
|
|
source.) Avoiding an intermediate C representation of the program means
|
|
|
|
that you get better object code, and better debugging information. The
|
|
|
|
GNU debugger, GDB, works with this information in the object code to
|
|
|
|
give you comprehensive C++ source-level editing capabilities
|
|
|
|
(@pxref{C,,C and C++,gdb.info, Debugging with GDB}).
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@c FIXME! Someone who knows something about Objective C ought to put in
|
|
|
|
@c a paragraph or two about it here, and move the index entry down when
|
|
|
|
@c there is more to point to than the general mention in the 1st par.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@include invoke.texi
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@include install.texi
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@include extend.texi
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@include gcov.texi
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Trouble
|
1999-10-16 06:09:09 +00:00
|
|
|
@chapter Known Causes of Trouble with GCC
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex bugs, known
|
|
|
|
@cindex installation trouble
|
|
|
|
@cindex known causes of trouble
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
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.
|
1999-08-26 09:30:50 +00:00
|
|
|
But the result for a user may be like the result of a bug.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Some of these problems are due to bugs in other software, some are
|
|
|
|
missing features that are too much work to add, and some are places
|
|
|
|
where people's opinions differ as to what is best.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@menu
|
|
|
|
* Actual Bugs:: Bugs we will fix later.
|
1999-10-16 06:09:09 +00:00
|
|
|
* 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,
|
1999-08-26 09:30:50 +00:00
|
|
|
and with certain linkers, assemblers and debuggers.
|
|
|
|
* External Bugs:: Problems compiling certain programs.
|
1999-10-16 06:09:09 +00:00
|
|
|
* Incompatibilities:: GCC is incompatible with traditional C.
|
1999-08-26 09:30:50 +00:00
|
|
|
* 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.
|
|
|
|
* 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}.
|
|
|
|
* Non-bugs:: Things we think are right, but some others disagree.
|
|
|
|
* Warnings and Errors:: Which problems in your code get warnings,
|
|
|
|
and which get errors.
|
|
|
|
@end menu
|
|
|
|
|
|
|
|
@node Actual Bugs
|
|
|
|
@section Actual Bugs We Haven't Fixed Yet
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@itemize @bullet
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
The @code{fixincludes} script interacts badly with automounters; if the
|
|
|
|
directory of system header files is automounted, it tends to be
|
|
|
|
unmounted while @code{fixincludes} is running. This would seem to be a
|
|
|
|
bug in the automounter. We don't know any good way to work around it.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
The @code{fixproto} script will sometimes add prototypes for the
|
|
|
|
@code{sigsetjmp} and @code{siglongjmp} functions that reference the
|
|
|
|
@code{jmp_buf} type before that type is defined. To work around this,
|
|
|
|
edit the offending file and place the typedef in front of the
|
|
|
|
prototypes.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
There are several obscure case of mis-using struct, union, and
|
|
|
|
enum tags that are not detected as errors by the compiler.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
When @samp{-pedantic-errors} is specified, GCC will incorrectly give
|
1999-08-26 09:30:50 +00:00
|
|
|
an error message when a function name is specified in an expression
|
|
|
|
involving the comma operator.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Installation Problems
|
|
|
|
@section Installation Problems
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
This is a list of problems (and some apparent problems which don't
|
|
|
|
really mean anything is wrong) that show up during installation of GNU
|
|
|
|
CC.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@itemize @bullet
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On certain systems, defining certain environment variables such as
|
|
|
|
@code{CC} can interfere with the functioning of @code{make}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
If you encounter seemingly strange errors when trying to build the
|
|
|
|
compiler in a directory other than the source directory, it could be
|
|
|
|
because you have previously configured the compiler in the source
|
|
|
|
directory. Make sure you have done all the necessary preparations.
|
|
|
|
@xref{Other Dir}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
If you build GCC on a BSD system using a directory stored in a System
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
The solution is not to use such a directory for building GCC.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
In previous versions of GCC, the @code{gcc} driver program looked for
|
1999-08-26 09:30:50 +00:00
|
|
|
@code{as} and @code{ld} in various places; for example, in files
|
1999-10-16 06:09:09 +00:00
|
|
|
beginning with @file{/usr/local/lib/gcc-}. GCC version 2 looks for
|
1999-08-26 09:30:50 +00:00
|
|
|
them in the directory
|
|
|
|
@file{/usr/local/lib/gcc-lib/@var{target}/@var{version}}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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).
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Some commands executed when making the compiler may fail (return a
|
|
|
|
non-zero status) and be ignored by @code{make}. These failures, which
|
|
|
|
are often due to files that were not found, are expected, and can safely
|
|
|
|
be ignored.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
It is normal to have warnings in compiling certain files about
|
|
|
|
unreachable code and about enumeration type clashes. These files' names
|
|
|
|
begin with @samp{insn-}. Also, @file{real.c} may get some warnings that
|
|
|
|
you can ignore.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Sometimes @code{make} recompiles parts of the compiler when installing
|
|
|
|
the compiler. In one case, this was traced down to a bug in
|
|
|
|
@code{make}. Either ignore the problem or switch to GNU Make.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC. The fix is to get rid of the file @code{real-ld} which purify
|
|
|
|
installs---so that GCC won't try to use it.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On GNU/Linux SLS 1.01, there is a problem with @file{libc.a}: it does not
|
1999-10-16 06:09:09 +00:00
|
|
|
contain the obstack functions. However, GCC assumes that the obstack
|
1999-08-26 09:30:50 +00:00
|
|
|
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}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
install GCC except for @file{float.h} by patching out the command to
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
On some 386 systems, GCC crashes trying to compile @file{enquire.c}.
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
ln /etc/emulator.rel1 /etc/emulator
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@noindent
|
|
|
|
and then reboot the system. (The default emulator file remains present
|
|
|
|
under the name @file{emulator.dflt}.)
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Try using @file{/etc/emulator.att}, if you have such a problem on the
|
|
|
|
SCO system.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Another system which has this problem is Esix. We don't know whether it
|
|
|
|
has an alternate emulator that works.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
On NetBSD 0.8, a similar problem manifests itself as these error messages:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
enquire.c: In function `fprop':
|
|
|
|
enquire.c:2328: floating overflow
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
On SCO systems, when compiling GCC with the system's compiler,
|
1999-08-26 09:30:50 +00:00
|
|
|
do not use @samp{-O}. Some versions of the system's compiler miscompile
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC with @samp{-O}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex @code{genflags}, crash on Sun 4
|
|
|
|
@item
|
|
|
|
Sometimes on a Sun 4 you may observe a crash in the program
|
1999-10-16 06:09:09 +00:00
|
|
|
@code{genflags} or @code{genoutput} while building GCC. This is said to
|
1999-08-26 09:30:50 +00:00
|
|
|
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}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
On Solaris 2, executables of GCC version 2.0.2 are commonly
|
1999-08-26 09:30:50 +00:00
|
|
|
available, but they have a bug that shows up when compiling current
|
1999-10-16 06:09:09 +00:00
|
|
|
versions of GCC: undefined symbol errors occur during assembly if you
|
1999-08-26 09:30:50 +00:00
|
|
|
use @samp{-g}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
The solution is to compile the current version of GCC without
|
1999-08-26 09:30:50 +00:00
|
|
|
@samp{-g}. That makes a working compiler which you can use to recompile
|
|
|
|
with @samp{-g}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Solaris 2 comes with a number of optional OS packages. Some of these
|
1999-10-16 06:09:09 +00:00
|
|
|
packages are needed to use GCC fully. If you did not install all
|
1999-08-26 09:30:50 +00:00
|
|
|
optional packages when installing Solaris, you will need to verify that
|
1999-10-16 06:09:09 +00:00
|
|
|
the packages that GCC needs are installed.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
For Solaris 2.0 and 2.1, GCC needs six packages: @samp{SUNWarc},
|
1999-08-26 09:30:50 +00:00
|
|
|
@samp{SUNWbtool}, @samp{SUNWesu}, @samp{SUNWhea}, @samp{SUNWlibm}, and
|
|
|
|
@samp{SUNWtoo}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
For Solaris 2.2, GCC needs an additional seventh package: @samp{SUNWsprot}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On Solaris 2, trying to use the linker and other tools in
|
1999-10-16 06:09:09 +00:00
|
|
|
@file{/usr/ucb} to install GCC has been observed to cause trouble.
|
1999-08-26 09:30:50 +00:00
|
|
|
For example, the linker may hang indefinitely. The fix is to remove
|
|
|
|
@file{/usr/ucb} from your @code{PATH}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
If you use the 1.31 version of the MIPS assembler (such as was shipped
|
|
|
|
with Ultrix 3.1), you will need to use the -fno-delayed-branch switch
|
|
|
|
when optimizing floating point code. Otherwise, the assembler will
|
|
|
|
complain when the GCC compiler fills a branch delay slot with a
|
|
|
|
floating point instruction, such as @code{add.d}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
If on a MIPS system you get an error message saying ``does not have gp
|
|
|
|
sections for all it's [sic] sectons [sic]'', don't worry about it. This
|
|
|
|
happens whenever you use GAS with the MIPS linker, but there is not
|
|
|
|
really anything wrong, and it is okay to use the output file. You can
|
|
|
|
stop such warnings by installing the GNU linker.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
It would be nice to extend GAS to produce the gp tables, but they are
|
|
|
|
optional, and there should not be a warning about their absence.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
problems in building GCC. Once GCC is installed, the problems go
|
1999-08-26 09:30:50 +00:00
|
|
|
away.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
To work around this problem, when making the stage 1 compiler, specify
|
|
|
|
this option to Make:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
GCC_FOR_TARGET="./xgcc -B./ -I./include"
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
When making stage 2 and stage 3, specify this option:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
CFLAGS="-g -I./include"
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Users have also reported some problems with version 2.20 of the
|
|
|
|
MIPS compiler tools that were shipped with RISC/os 4.x. The earlier
|
|
|
|
version 2.11 seems to work fine.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Some versions of the MIPS linker will issue an assertion failure
|
|
|
|
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.
|
1999-10-16 06:09:09 +00:00
|
|
|
To protect against this, GCC passes @samp{-non_shared} to the
|
1999-08-26 09:30:50 +00:00
|
|
|
linker unless you pass an explicit @samp{-shared} or
|
|
|
|
@samp{-call_shared} switch.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On System V release 3, you may get this error message
|
|
|
|
while linking:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@smallexample
|
|
|
|
ld fatal: failed to write symbol name @var{something}
|
|
|
|
in strings table for file @var{whatever}
|
|
|
|
@end smallexample
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
This probably indicates that the disk is full or your ULIMIT won't allow
|
|
|
|
the file to be as large as it needs to be.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
This problem can also result because the kernel parameter @code{MAXUMEM}
|
|
|
|
is too small. If so, you must regenerate the kernel and make the value
|
|
|
|
much larger. The default value is reported to be 1024; a value of 32768
|
|
|
|
is said to work. Smaller values may also work.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On System V, if you get an error like this,
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
/usr/local/lib/bison.simple: In function `yyparse':
|
|
|
|
/usr/local/lib/bison.simple:625: virtual memory exhausted
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@noindent
|
|
|
|
that too indicates a problem with disk space, ULIMIT, or @code{MAXUMEM}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
Current GCC versions probably do not work on version 2 of the NeXT
|
1999-08-26 09:30:50 +00:00
|
|
|
operating system.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On NeXTStep 3.0, the Objective C compiler does not work, due,
|
|
|
|
apparently, to a kernel bug that it happens to trigger. This problem
|
|
|
|
does not happen on 3.1.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On the Tower models 4@var{n}0 and 6@var{n}0, by default a process is not
|
1999-10-16 06:09:09 +00:00
|
|
|
allowed to have more than one megabyte of memory. GCC cannot compile
|
1999-08-26 09:30:50 +00:00
|
|
|
itself (or many other programs) with @samp{-O} in that much memory.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
To solve this problem, reconfigure the kernel adding the following line
|
|
|
|
to the configuration file:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@smallexample
|
|
|
|
MAXUMEM = 4096
|
|
|
|
@end smallexample
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a bug
|
1999-10-16 06:09:09 +00:00
|
|
|
in the assembler that must be fixed before GCC can be built. This
|
1999-08-26 09:30:50 +00:00
|
|
|
bug manifests itself during the first stage of compilation, while
|
|
|
|
building @file{libgcc2.a}:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@smallexample
|
|
|
|
_floatdisf
|
|
|
|
cc1: warning: `-g' option not supported on this version of GCC
|
|
|
|
cc1: warning: `-g1' option not supported on this version of GCC
|
|
|
|
./xgcc: Internal compiler error: program as got fatal signal 11
|
|
|
|
@end smallexample
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@quotation
|
|
|
|
This is the patched assembler, to patch SR#1653-010439, where the
|
|
|
|
assembler aborts on floating point constants.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The bug is not really in the assembler, but in the shared library
|
|
|
|
version of the function ``cvtnum(3c)''. The bug on ``cvtnum(3c)'' is
|
|
|
|
SR#4701-078451. Anyway, the attached assembler uses the archive
|
|
|
|
library version of ``cvtnum(3c)'' and thus does not exhibit the bug.
|
|
|
|
@end quotation
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
This patch is also known as PHCO_4484.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On HP-UX version 8.05, but not on 8.07 or more recent versions,
|
|
|
|
the @code{fixproto} shell script triggers a bug in the system shell.
|
|
|
|
If you encounter this problem, upgrade your operating system or
|
|
|
|
use BASH (the GNU shell) to run @code{fixproto}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Some versions of the Pyramid C compiler are reported to be unable to
|
1999-10-16 06:09:09 +00:00
|
|
|
compile GCC. You must use an older version of GCC for
|
1999-08-26 09:30:50 +00:00
|
|
|
bootstrapping. One indication of this problem is if you get a crash
|
1999-10-16 06:09:09 +00:00
|
|
|
when GCC compiles the function @code{muldi3} in file @file{libgcc2.c}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
You may be able to succeed by getting GCC version 1, installing it,
|
|
|
|
and using it to compile GCC version 2. The bug in the Pyramid C
|
|
|
|
compiler does not seem to affect GCC version 1.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
There may be similar problems on System V Release 3.1 on 386 systems.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On the Intel Paragon (an i860 machine), if you are using operating
|
|
|
|
system version 1.0, you will get warnings or errors about redefinition
|
1999-10-16 06:09:09 +00:00
|
|
|
of @code{va_arg} when you build GCC.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
the lines
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
#if defined(__i860__) && !defined(_VA_LIST)
|
|
|
|
#include <va_list.h>
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@noindent
|
|
|
|
insert the line
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
#if __PGC__
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@noindent
|
|
|
|
and after the lines
|
|
|
|
|
|
|
|
@example
|
|
|
|
extern int vprintf(const char *, va_list );
|
|
|
|
extern int vsprintf(char *, const char *, va_list );
|
|
|
|
#endif
|
|
|
|
@end example
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
insert the line
|
|
|
|
|
|
|
|
@example
|
|
|
|
#endif /* __PGC__ */
|
|
|
|
@end example
|
|
|
|
|
|
|
|
These problems don't exist in operating system version 1.1.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
On the Altos 3068, programs compiled with GCC won't work unless you
|
1999-08-26 09:30:50 +00:00
|
|
|
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}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
You will get several sorts of compilation and linking errors on the
|
|
|
|
we32k if you don't follow the special instructions. @xref{Configurations}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
A bug in the HP-UX 8.05 (and earlier) shell will cause the fixproto
|
|
|
|
program to report an error of the form:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
./fixproto: sh internal 1K buffer overflow
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
To fix this, change the first line of the fixproto script to look like:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
#!/bin/ksh
|
|
|
|
@end example
|
|
|
|
@end itemize
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Cross-Compiler Problems
|
|
|
|
@section Cross-Compiler Problems
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
You may run into problems with cross compilation on certain machines,
|
|
|
|
for several reasons.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@itemize @bullet
|
|
|
|
@item
|
|
|
|
Cross compilation can run into trouble for certain machines because
|
|
|
|
some target machines' assemblers require floating point numbers to be
|
|
|
|
written as @emph{integer} constants in certain contexts.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The compiler writes these integer constants by examining the floating
|
|
|
|
point value as an integer and printing that integer, because this is
|
|
|
|
simple to write and independent of the details of the floating point
|
|
|
|
representation. But this does not work if the compiler is running on
|
|
|
|
a different machine with an incompatible floating point format, or
|
|
|
|
even a different byte-ordering.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
In addition, correct constant folding of floating point values
|
|
|
|
requires representing them in the target machine's format.
|
|
|
|
(The C standard does not quite require this, but in practice
|
|
|
|
it is the only way to win.)
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
It is now possible to overcome these problems by defining macros such
|
|
|
|
as @code{REAL_VALUE_TYPE}. But doing so is a substantial amount of
|
|
|
|
work for each target machine.
|
|
|
|
@ifset INTERNALS
|
|
|
|
@xref{Cross-compilation}.
|
|
|
|
@end ifset
|
|
|
|
@ifclear INTERNALS
|
|
|
|
@xref{Cross-compilation,,Cross Compilation and Floating Point Format,
|
|
|
|
gcc.info, Using and Porting GCC}.
|
|
|
|
@end ifclear
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
At present, the program @file{mips-tfile} which adds debug
|
|
|
|
support to object files on MIPS systems does not work in a cross
|
|
|
|
compile environment.
|
|
|
|
@end itemize
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Interoperation
|
|
|
|
@section Interoperation
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
This section lists various difficulties encountered in using GNU C or
|
|
|
|
GNU C++ together with other compilers or with the assemblers, linkers,
|
|
|
|
libraries and debuggers on certain systems.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@itemize @bullet
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Objective C does not work on the RS/6000.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
GNU C++ does not do name mangling in the same way as other C++
|
|
|
|
compilers. This means that object files compiled with one compiler
|
|
|
|
cannot be used with another.
|
|
|
|
|
|
|
|
This effect is intentional, to protect you from more subtle problems.
|
|
|
|
Compilers differ as to many internal details of C++ implementation,
|
|
|
|
including: how class instances are laid out, how multiple inheritance is
|
|
|
|
implemented, and how virtual function calls are handled. If the name
|
|
|
|
encoding were made the same, your programs would link against libraries
|
|
|
|
provided from other compilers---but the programs would then crash when
|
|
|
|
run. Incompatible libraries are then detected at link time, rather than
|
|
|
|
at run time.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
Older GDB versions sometimes fail to read the output of GCC version
|
1999-08-26 09:30:50 +00:00
|
|
|
2. If you have trouble, get GDB version 4.4 or later.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex DBX
|
1999-10-16 06:09:09 +00:00
|
|
|
DBX rejects some files produced by GCC, though it accepts similar
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
The GNU assembler (GAS) does not support PIC. To generate PIC code, you
|
|
|
|
must use some other assembler, such as @file{/bin/as}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On some BSD systems, including some versions of Ultrix, use of profiling
|
|
|
|
causes static variable destructors (currently used only in C++) not to
|
|
|
|
be run.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Use of @samp{-I/usr/include} may cause trouble.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
Many systems come with header files that won't work with GCC unless
|
1999-08-26 09:30:50 +00:00
|
|
|
corrected by @code{fixincludes}. The corrected header files go in a new
|
1999-10-16 06:09:09 +00:00
|
|
|
directory; GCC searches this directory before @file{/usr/include}.
|
|
|
|
If you use @samp{-I/usr/include}, this tells GCC to search
|
1999-08-26 09:30:50 +00:00
|
|
|
@file{/usr/include} earlier on, before the corrected headers. The
|
|
|
|
result is that you get the uncorrected header files.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Instead, you should use these options (when compiling C programs):
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@smallexample
|
|
|
|
-I/usr/local/lib/gcc-lib/@var{target}/@var{version}/include -I/usr/include
|
|
|
|
@end smallexample
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
For C++ programs, GCC also uses a special directory that defines C++
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
include directories explicitly, use this option first, then the two
|
|
|
|
options above:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
-I/usr/local/lib/g++-include
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@ignore
|
|
|
|
@cindex @code{vfork}, for the Sun-4
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
optimized with GCC when the child code alters registers which contain
|
1999-08-26 09:30:50 +00:00
|
|
|
C variables in the parent. This affects variables which are live in the
|
|
|
|
parent across the call to @code{vfork}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If you encounter this, you can work around the problem by declaring
|
|
|
|
variables @code{volatile} in the function that calls @code{vfork}, until
|
|
|
|
the problem goes away, or by not declaring them @code{register} and not
|
|
|
|
using @samp{-O} for those source files.
|
|
|
|
@end ignore
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
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}.
|
1999-10-16 06:09:09 +00:00
|
|
|
Naturally, this does not happen when you use GCC.
|
1999-08-26 09:30:50 +00:00
|
|
|
You must specify all three options explicitly.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
On a Sparc, GCC aligns all values of type @code{double} on an 8-byte
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
@code{double *} to a function compiled with GCC, dereferencing the
|
1999-08-26 09:30:50 +00:00
|
|
|
pointer may cause a fatal signal.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
One way to solve this problem is to compile your entire program with GNU
|
|
|
|
CC. Another solution is to modify the function that is compiled with
|
|
|
|
Sun CC to copy the argument into a local variable; local variables
|
|
|
|
are always properly aligned. A third solution is to modify the function
|
|
|
|
that uses the pointer to dereference it via the following function
|
|
|
|
@code{access_double} instead of directly with @samp{*}:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@smallexample
|
|
|
|
inline double
|
|
|
|
access_double (double *unaligned_ptr)
|
|
|
|
@{
|
|
|
|
union d2i @{ double d; int i[2]; @};
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
union d2i *p = (union d2i *) unaligned_ptr;
|
|
|
|
union d2i u;
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
u.i[0] = p->i[0];
|
|
|
|
u.i[1] = p->i[1];
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
return u.d;
|
|
|
|
@}
|
|
|
|
@end smallexample
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@noindent
|
|
|
|
Storing into the pointer can be done likewise with the same union.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
On Solaris, the @code{malloc} function in the @file{libmalloc.a} library
|
1999-10-16 06:09:09 +00:00
|
|
|
may allocate memory that is only 4 byte aligned. Since GCC on the
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The solution is to not use the @file{libmalloc.a} library. Use instead
|
|
|
|
@code{malloc} and related functions from @file{libc.a}; they do not have
|
|
|
|
this problem.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Sun forgot to include a static version of @file{libdl.a} with some
|
|
|
|
versions of SunOS (mainly 4.1). This results in undefined symbols when
|
|
|
|
linking static binaries (that is, if you use @samp{-static}). If you
|
|
|
|
see undefined symbols @code{_dlclose}, @code{_dlsym} or @code{_dlopen}
|
|
|
|
when linking, compile and link against the file
|
|
|
|
@file{mit/util/misc/dlsym.c} from the MIT version of X windows.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
The 128-bit long double format that the Sparc port supports currently
|
|
|
|
works by using the architecturally defined quad-word floating point
|
|
|
|
instructions. Since there is no hardware that supports these
|
|
|
|
instructions they must be emulated by the operating system. Long
|
|
|
|
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.
|
1999-10-16 06:09:09 +00:00
|
|
|
Long doubles do work on Sun OS versions 4.1.2 and higher, but GCC
|
1999-08-26 09:30:50 +00:00
|
|
|
does not enable them by default. Long doubles appear to work in Sun OS
|
|
|
|
5.x (Solaris 2.x).
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
On HP-UX version 9.01 on the HP PA, the HP compiler @code{cc} does not
|
1999-10-16 06:09:09 +00:00
|
|
|
compile GCC correctly. We do not yet know why. However, GCC
|
1999-08-26 09:30:50 +00:00
|
|
|
compiled on earlier HP-UX versions works properly on HP-UX 9.01 and can
|
|
|
|
compile itself properly on 9.01.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
On the HP PA machine, ADB sometimes fails to work on functions compiled
|
1999-10-16 06:09:09 +00:00
|
|
|
with GCC. Specifically, it fails to work on functions that use
|
|
|
|
@code{alloca} or variable-size arrays. This is because GCC doesn't
|
1999-08-26 09:30:50 +00:00
|
|
|
generate HP-UX unwind descriptors for such functions. It may even be
|
|
|
|
impossible to generate them.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Debugging (@samp{-g}) is not supported on the HP PA machine, unless you use
|
|
|
|
the preliminary GNU tools (@pxref{Installation}).
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Taking the address of a label may generate errors from the HP-UX
|
|
|
|
PA assembler. GAS for the PA does not have this problem.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Using floating point parameters for indirect calls to static functions
|
|
|
|
will not work when using the HP assembler. There simply is no way for GCC
|
|
|
|
to specify what registers hold arguments for static functions when using
|
|
|
|
the HP assembler. GAS for the PA does not have this problem.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
versions of GCC, but is now exceptionally rare. If you should run
|
1999-08-26 09:30:50 +00:00
|
|
|
into it, you can work around by making your function smaller.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC compiled code sometimes emits warnings from the HP-UX assembler of
|
1999-08-26 09:30:50 +00:00
|
|
|
the form:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@smallexample
|
|
|
|
(warning) Use of GR3 when
|
|
|
|
frame >= 8192 may cause conflict.
|
|
|
|
@end smallexample
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
These warnings are harmless and can be safely ignored.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
The current version of the assembler (@file{/bin/as}) for the RS/6000
|
|
|
|
has certain problems that prevent the @samp{-g} option in GCC from
|
|
|
|
working. Note that @file{Makefile.in} uses @samp{-g} by default when
|
|
|
|
compiling @file{libgcc2.c}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
IBM has produced a fixed version of the assembler. The upgraded
|
|
|
|
assembler unfortunately was not included in any of the AIX 3.2 update
|
|
|
|
PTF releases (3.2.2, 3.2.3, or 3.2.3e). Users of AIX 3.1 should request
|
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
You can test for the presense of a fixed assembler by using the
|
|
|
|
command
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@smallexample
|
|
|
|
as -u < /dev/null
|
|
|
|
@end smallexample
|
|
|
|
|
|
|
|
@noindent
|
|
|
|
If the command exits normally, the assembler fix already is installed.
|
|
|
|
If the assembler complains that "-u" is an unknown flag, you need to
|
|
|
|
order the fix.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On the IBM RS/6000, compiling code of the form
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@smallexample
|
|
|
|
extern int foo;
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@dots{} foo @dots{}
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
static int foo;
|
|
|
|
@end smallexample
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@noindent
|
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
AIX on the RS/6000 provides support (NLS) for environments outside of
|
|
|
|
the United States. Compilers and assemblers use NLS to support
|
|
|
|
locale-specific representations of various objects including
|
|
|
|
floating-point numbers ("." vs "," for separating decimal fractions).
|
|
|
|
There have been problems reported where the library linked with GCC does
|
|
|
|
not produce the same floating-point formats that the assembler accepts.
|
|
|
|
If you have this problem, set the LANG environment variable to "C" or
|
|
|
|
"En_US".
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Even if you specify @samp{-fdollars-in-identifiers},
|
|
|
|
you cannot successfully use @samp{$} in identifiers on the RS/6000 due
|
|
|
|
to a restriction in the IBM assembler. GAS supports these
|
|
|
|
identifiers.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On the RS/6000, XLC version 1.3.0.0 will miscompile @file{jump.c}. XLC
|
|
|
|
version 1.3.0.1 or later fixes this problem. You can obtain XLC-1.3.0.2
|
|
|
|
by requesting PTF 421749 from IBM.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
There is an assembler bug in versions of DG/UX prior to 5.4.2.01 that
|
1999-10-16 06:09:09 +00:00
|
|
|
occurs when the @samp{fldcr} instruction is used. GCC uses
|
1999-08-26 09:30:50 +00:00
|
|
|
@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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On VMS, GAS versions 1.38.1 and earlier may cause spurious warning
|
|
|
|
messages from the linker. These warning messages complain of mismatched
|
|
|
|
psect attributes. You can ignore them. @xref{VMS Install}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On NewsOS version 3, if you include both of the files @file{stddef.h}
|
|
|
|
and @file{sys/types.h}, you get an error because there are two typedefs
|
|
|
|
of @code{size_t}. You should change @file{sys/types.h} by adding these
|
|
|
|
lines around the definition of @code{size_t}:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@smallexample
|
|
|
|
#ifndef _SIZE_T
|
|
|
|
#define _SIZE_T
|
|
|
|
@var{actual typedef here}
|
|
|
|
#endif
|
|
|
|
@end smallexample
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex Alliant
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On the Alliant, the system's own convention for returning structures
|
1999-10-16 06:09:09 +00:00
|
|
|
and unions is unusual, and is not compatible with GCC no matter
|
1999-08-26 09:30:50 +00:00
|
|
|
what options are used.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex RT PC
|
|
|
|
@cindex IBM RT PC
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On the IBM RT PC, the MetaWare HighC compiler (hc) uses a different
|
|
|
|
convention for structure and union returning. Use the option
|
1999-10-16 06:09:09 +00:00
|
|
|
@samp{-mhc-struct-return} to tell GCC to use a convention compatible
|
1999-08-26 09:30:50 +00:00
|
|
|
with it.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex Vax calling convention
|
|
|
|
@cindex Ultrix calling convention
|
|
|
|
@item
|
|
|
|
On Ultrix, the Fortran compiler expects registers 2 through 5 to be saved
|
|
|
|
by function calls. However, the C compiler uses conventions compatible
|
|
|
|
with BSD Unix: registers 2 through 5 may be clobbered by function calls.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC uses the same convention as the Ultrix C compiler. You can use
|
1999-08-26 09:30:50 +00:00
|
|
|
these options to produce code compatible with the Fortran compiler:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@smallexample
|
|
|
|
-fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5
|
|
|
|
@end smallexample
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
On the WE32k, you may find that programs compiled with GCC do not
|
1999-08-26 09:30:50 +00:00
|
|
|
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:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@smallexample
|
|
|
|
-L/usr/local/lib/gcc-lib/we32k-att-sysv/2.8.1 -lgcc -lc_s
|
|
|
|
@end smallexample
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The first specifies where to find the library @file{libgcc.a}
|
|
|
|
specified with the @samp{-lgcc} option.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC does linking by invoking @code{ld}, just as @code{cc} does, and
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On the Alpha, you may get assembler errors about invalid syntax as a
|
|
|
|
result of floating point constants. This is due to a bug in the C
|
|
|
|
library functions @code{ecvt}, @code{fcvt} and @code{gcvt}. Given valid
|
|
|
|
floating point numbers, they sometimes print @samp{NaN}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On Irix 4.0.5F (and perhaps in some other versions), an assembler bug
|
|
|
|
sometimes reorders instructions incorrectly when optimization is turned
|
|
|
|
on. If you think this may be happening to you, try using the GNU
|
|
|
|
assembler; GAS version 2.1 supports ECOFF on Irix.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
Or use the @samp{-noasmopt} option when you compile GCC with itself,
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
that it unconditionally passes @samp{-O0} to the assembler, and never
|
|
|
|
passes @samp{-O2} or @samp{-O3}.
|
|
|
|
@end itemize
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node External Bugs
|
|
|
|
@section Problems Compiling Certain Programs
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@c prevent bad page break with this line
|
|
|
|
Certain programs have problems compiling.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@itemize @bullet
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Parse errors may occur compiling X11 on a Decstation running Ultrix 4.2
|
|
|
|
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
|
|
|
|
header files by adding this:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
#ifdef __STDC__
|
|
|
|
#define NeedFunctionPrototypes 0
|
|
|
|
#endif
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
You can prevent this problem by linking GCC with the GNU malloc
|
1999-08-26 09:30:50 +00:00
|
|
|
(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
|
1999-10-16 06:09:09 +00:00
|
|
|
option when you relink GCC:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@example
|
1999-08-26 09:30:50 +00:00
|
|
|
MALLOC=/usr/local/lib/libgmalloc.a
|
1996-09-18 05:35:50 +00:00
|
|
|
@end example
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@example
|
1999-08-26 09:30:50 +00:00
|
|
|
MALLOC=gmalloc.o
|
1996-09-18 05:35:50 +00:00
|
|
|
@end example
|
1999-08-26 09:30:50 +00:00
|
|
|
@end itemize
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Incompatibilities
|
1999-10-16 06:09:09 +00:00
|
|
|
@section Incompatibilities of GCC
|
|
|
|
@cindex incompatibilities of GCC
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
There are several noteworthy incompatibilities between GNU C and most
|
|
|
|
existing (non-ANSI) 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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@itemize @bullet
|
|
|
|
@cindex string constants
|
|
|
|
@cindex read-only strings
|
|
|
|
@cindex shared strings
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC normally makes string constants read-only. If several
|
|
|
|
identical-looking string constants are used, GCC stores only one
|
1999-08-26 09:30:50 +00:00
|
|
|
copy of the string.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex @code{mktemp}, and constant strings
|
|
|
|
One consequence is that you cannot call @code{mktemp} with a string
|
|
|
|
constant argument. The function @code{mktemp} always alters the
|
|
|
|
string its argument points to.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex @code{sscanf}, and constant strings
|
|
|
|
@cindex @code{fscanf}, and constant strings
|
|
|
|
@cindex @code{scanf}, and constant strings
|
|
|
|
Another consequence is that @code{sscanf} does not work on some systems
|
|
|
|
when passed a string constant as its format control string or input.
|
|
|
|
This is because @code{sscanf} incorrectly tries to write into the string
|
|
|
|
constant. Likewise @code{fscanf} and @code{scanf}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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,
|
1999-10-16 06:09:09 +00:00
|
|
|
you can use the @samp{-fwritable-strings} flag, which directs GCC
|
1999-08-26 09:30:50 +00:00
|
|
|
to handle string constants the same way most C compilers do.
|
|
|
|
@samp{-traditional} also has this effect, among others.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
@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}.
|
|
|
|
Negating this value yields 2147483648 again.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC does not substitute macro arguments when they appear inside of
|
|
|
|
string constants. For example, the following macro in GCC
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@example
|
1999-08-26 09:30:50 +00:00
|
|
|
#define foo(a) "a"
|
1996-09-18 05:35:50 +00:00
|
|
|
@end example
|
|
|
|
|
|
|
|
@noindent
|
1999-08-26 09:30:50 +00:00
|
|
|
will produce output @code{"a"} regardless of what the argument @var{a} is.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
The @samp{-traditional} option directs GCC to handle such cases
|
1999-08-26 09:30:50 +00:00
|
|
|
(among others) in the old-fashioned (non-ANSI) fashion.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex @code{setjmp} incompatibilities
|
|
|
|
@cindex @code{longjmp} incompatibilities
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
When you use @code{setjmp} and @code{longjmp}, the only automatic
|
|
|
|
variables guaranteed to remain valid are those declared
|
|
|
|
@code{volatile}. This is a consequence of automatic register
|
|
|
|
allocation. Consider this function:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
jmp_buf j;
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
foo ()
|
|
|
|
@{
|
|
|
|
int a, b;
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
a = fun1 ();
|
|
|
|
if (setjmp (j))
|
|
|
|
return a;
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
a = fun2 ();
|
|
|
|
/* @r{@code{longjmp (j)} may occur in @code{fun3}.} */
|
|
|
|
return a + fun3 ();
|
|
|
|
@}
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Here @code{a} may or may not be restored to its first value when the
|
|
|
|
@code{longjmp} occurs. If @code{a} is allocated in a register, then
|
|
|
|
its first value is restored; otherwise, it keeps the last value stored
|
|
|
|
in it.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If you use the @samp{-W} option with the @samp{-O} option, you will
|
1999-10-16 06:09:09 +00:00
|
|
|
get a warning when GCC thinks such a problem might be possible.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The @samp{-traditional} option directs GNU C to put variables in
|
|
|
|
the stack by default, rather than in registers, in functions that
|
|
|
|
call @code{setjmp}. This results in the behavior found in
|
|
|
|
traditional C compilers.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Programs that use preprocessing directives in the middle of macro
|
1999-10-16 06:09:09 +00:00
|
|
|
arguments do not work with GCC. For example, a program like this
|
1999-08-26 09:30:50 +00:00
|
|
|
will not work:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
foobar (
|
|
|
|
#define luser
|
|
|
|
hack)
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
ANSI 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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex external declaration scope
|
|
|
|
@cindex scope of external declarations
|
|
|
|
@cindex declaration scope
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Declarations of external variables and functions within a block apply
|
|
|
|
only to the block containing the declaration. In other words, they
|
|
|
|
have the same scope as any other declaration in the same place.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
In some other C compilers, a @code{extern} declaration affects all the
|
|
|
|
rest of the file even if it happens within a block.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The @samp{-traditional} option directs GNU C to treat all @code{extern}
|
|
|
|
declarations as global, like traditional compilers.
|
|
|
|
|
|
|
|
@item
|
|
|
|
In traditional C, you can combine @code{long}, etc., with a typedef name,
|
|
|
|
as shown here:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@example
|
1999-08-26 09:30:50 +00:00
|
|
|
typedef int foo;
|
|
|
|
typedef long foo bar;
|
1996-09-18 05:35:50 +00:00
|
|
|
@end example
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
In ANSI 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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex typedef names as function parameters
|
|
|
|
@item
|
|
|
|
PCC allows typedef names to be used as function parameters. The
|
|
|
|
difficulty described immediately above applies here too.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex whitespace
|
|
|
|
@item
|
|
|
|
PCC allows whitespace in the middle of compound assignment operators
|
1999-10-16 06:09:09 +00:00
|
|
|
such as @samp{+=}. GCC, following the ANSI standard, does not
|
1999-08-26 09:30:50 +00:00
|
|
|
allow this. The difficulty described immediately above applies here
|
|
|
|
too.
|
|
|
|
|
|
|
|
@cindex apostrophes
|
|
|
|
@cindex '
|
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC complains about unterminated character constants inside of
|
1999-08-26 09:30:50 +00:00
|
|
|
preprocessing conditionals that fail. Some programs have English
|
|
|
|
comments enclosed in conditionals that are guaranteed to fail; if these
|
1999-10-16 06:09:09 +00:00
|
|
|
comments contain apostrophes, GCC will probably report an error. For
|
1999-08-26 09:30:50 +00:00
|
|
|
example, this code would produce an error:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@example
|
1999-08-26 09:30:50 +00:00
|
|
|
#if 0
|
|
|
|
You can't expect this to work.
|
1996-09-18 05:35:50 +00:00
|
|
|
#endif
|
|
|
|
@end example
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The best solution to such a problem is to put the text into an actual
|
|
|
|
C comment delimited by @samp{/*@dots{}*/}. However,
|
|
|
|
@samp{-traditional} suppresses these error messages.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
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 @code{time_t}, and if that is not the same as @code{long}, then
|
|
|
|
@samp{long time ();} is erroneous.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The solution is to change your program to use @code{time_t} as the return
|
|
|
|
type of @code{time}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex @code{float} as function value type
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
When compiling functions that return @code{float}, PCC converts it to
|
1999-10-16 06:09:09 +00:00
|
|
|
a double. GCC actually returns a @code{float}. If you are concerned
|
1999-08-26 09:30:50 +00:00
|
|
|
with PCC compatibility, you should declare your functions to return
|
|
|
|
@code{double}; you might as well say what you mean.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex structures
|
|
|
|
@cindex unions
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
When compiling functions that return structures or unions, GCC
|
1999-08-26 09:30:50 +00:00
|
|
|
output code normally uses a method different from that used on most
|
1999-10-16 06:09:09 +00:00
|
|
|
versions of Unix. As a result, code compiled with GCC cannot call
|
1999-08-26 09:30:50 +00:00
|
|
|
a structure-returning function compiled with PCC, and vice versa.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
The method used by GCC is as follows: a structure or union which is
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
@code{STRUCT_INCOMING_VALUE} tell GCC where to pass this address.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
the value is wanted. GCC does not use this method because it is
|
1999-08-26 09:30:50 +00:00
|
|
|
slower and nonreentrant.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
On some newer machines, PCC uses a reentrant convention for all
|
1999-10-16 06:09:09 +00:00
|
|
|
structure and union returning. GCC on most of these machines uses a
|
1999-08-26 09:30:50 +00:00
|
|
|
compatible convention when returning structures and unions in memory,
|
|
|
|
but still returns small structures and unions in registers.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
You can tell GCC to use a compatible convention for all structure and
|
1999-08-26 09:30:50 +00:00
|
|
|
union returning with the option @samp{-fpcc-struct-return}.
|
|
|
|
|
|
|
|
@cindex preprocessing tokens
|
|
|
|
@cindex preprocessing numbers
|
|
|
|
@item
|
|
|
|
GNU C complains about program fragments such as @samp{0x74ae-0x4000}
|
|
|
|
which appear to be two hexadecimal constants separated by the minus
|
|
|
|
operator. Actually, this string is a single @dfn{preprocessing token}.
|
|
|
|
Each such token must correspond to one token in C. Since this does not,
|
|
|
|
GNU C prints an error message. Although it may appear obvious that what
|
|
|
|
is meant is an operator and two values, the ANSI 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.
|
|
|
|
|
|
|
|
To make the above program fragment valid, place whitespace in front of
|
|
|
|
the minus sign. This whitespace will end the preprocessing number.
|
1996-09-18 05:35:50 +00:00
|
|
|
@end itemize
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Fixed Headers
|
|
|
|
@section Fixed Header Files
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC needs to install corrected versions of some system header files.
|
1999-08-26 09:30:50 +00:00
|
|
|
This is because most target systems have some header files that won't
|
1999-10-16 06:09:09 +00:00
|
|
|
work with GCC unless they are changed. Some have bugs, some are
|
1999-08-26 09:30:50 +00:00
|
|
|
incompatible with ANSI C, and some depend on special features of other
|
|
|
|
compilers.
|
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
Installing GCC automatically creates and installs the fixed header
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
doesn't do the right thing automatically.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@itemize @bullet
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
If you update the system's header files, such as by installing a new
|
1999-10-16 06:09:09 +00:00
|
|
|
system version, the fixed header files of GCC are not automatically
|
|
|
|
updated. The easiest way to update them is to reinstall GCC. (If
|
1999-08-26 09:30:50 +00:00
|
|
|
you want to be clever, look in the makefile and you can find a
|
|
|
|
shortcut.)
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
On some systems, in particular SunOS 4, header file directories contain
|
|
|
|
machine-specific symbolic links in certain places. This makes it
|
|
|
|
possible to share most of the header files among hosts running the
|
|
|
|
same version of SunOS 4 on different machine models.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The programs that fix the header files do not understand this special
|
|
|
|
way of using symbolic links; therefore, the directory of fixed header
|
|
|
|
files is good only for the machine model used to build it.
|
|
|
|
|
|
|
|
In SunOS 4, only programs that look inside the kernel will notice the
|
|
|
|
difference between machine models. Therefore, for most purposes, you
|
|
|
|
need not be concerned about this.
|
|
|
|
|
|
|
|
It is possible to make separate sets of fixed header files for the
|
|
|
|
different machine models, and arrange a structure of symbolic links so
|
|
|
|
as to use the proper set, but you'll have to do this by hand.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
On Lynxos, GCC by default does not fix the header files. This is
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
files. It may be no comfort that they aren't GCC's fault, but it
|
1999-08-26 09:30:50 +00:00
|
|
|
does mean that there's nothing for us to do about them.
|
1996-09-18 05:35:50 +00:00
|
|
|
@end itemize
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Standard Libraries
|
|
|
|
@section Standard Libraries
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC by itself attempts to be what the ISO/ANSI C standard calls a
|
1999-08-26 09:30:50 +00:00
|
|
|
@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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
For example, the @code{sprintf} function on SunOS 4.1.3 returns
|
|
|
|
@code{char *} while the C standard says that @code{sprintf} returns an
|
|
|
|
@code{int}. The @code{fixincludes} program could make the prototype for
|
|
|
|
this function match the Standard, but that would be wrong, since the
|
|
|
|
function will still return @code{char *}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If you need a Standard compliant library, then you need to find one, as
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC does not provide one. The GNU C library (called @code{glibc})
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Disappointments
|
|
|
|
@section Disappointments and Misunderstandings
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
These problems are perhaps regrettable, but we don't know any practical
|
|
|
|
way around them.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@itemize @bullet
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Certain local variables aren't recognized by debuggers when you compile
|
|
|
|
with optimization.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
This occurs because sometimes GCC optimizes the variable out of
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
be desirable anyway. So GCC simply does not mention the eliminated
|
1999-08-26 09:30:50 +00:00
|
|
|
variable when it writes debugging information.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
You have to expect a certain amount of disagreement between the
|
|
|
|
executable and your source code, when you use optimization.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex conflicting types
|
|
|
|
@cindex scope of declaration
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
Users often think it is a bug when GCC reports an error for code
|
1999-08-26 09:30:50 +00:00
|
|
|
like this:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
int foo (struct mumble *);
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
struct mumble @{ @dots{} @};
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
int foo (struct mumble *x)
|
|
|
|
@{ @dots{} @}
|
1996-09-18 05:35:50 +00:00
|
|
|
@end example
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
This code really is erroneous, because the scope of @code{struct
|
|
|
|
mumble} in the prototype is limited to the argument list containing it.
|
|
|
|
It does not refer to the @code{struct mumble} defined with file scope
|
|
|
|
immediately below---they are two unrelated types with similar names in
|
|
|
|
different scopes.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
But in the definition of @code{foo}, the file-scope type is used
|
|
|
|
because that is available to be inherited. Thus, the definition and
|
|
|
|
the prototype do not match, and you get an error.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
This behavior may seem silly, but it's what the ANSI 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
|
|
|
|
shown above.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Accesses to bitfields even in volatile objects works by accessing larger
|
|
|
|
objects, such as a byte or a word. You cannot rely on what size of
|
|
|
|
object is accessed in order to read or write the bitfield; it may even
|
|
|
|
vary for a given bitfield according to the precise usage.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If you care about controlling the amount of memory that is accessed, use
|
|
|
|
volatile but do not use bitfields.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC comes with shell scripts to fix certain known problems in system
|
1999-08-26 09:30:50 +00:00
|
|
|
header files. They install corrected copies of various header files in
|
1999-10-16 06:09:09 +00:00
|
|
|
a special directory where only GCC will normally look for them. The
|
1999-08-26 09:30:50 +00:00
|
|
|
scripts adapt to various systems by searching all the system header
|
|
|
|
files for the problem cases that we know about.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If new system header files are installed, nothing automatically arranges
|
1999-10-16 06:09:09 +00:00
|
|
|
to update the corrected header files. You will have to reinstall GCC
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
@samp{make install} again.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
@cindex floating point precision
|
|
|
|
On 68000 and x86 systems, for instance, you can get paradoxical results
|
|
|
|
if you test the precise values of floating point numbers. For example,
|
|
|
|
you can find that a floating point value which is not a NaN is not equal
|
|
|
|
to itself. This results from the fact that the floating point registers
|
|
|
|
hold a few more bits of precision than fit in a @code{double} in memory.
|
|
|
|
Compiled code moves values between memory and floating point registers
|
|
|
|
at its convenience, and moving them into memory truncates them.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
You can partially avoid this problem by using the @samp{-ffloat-store}
|
|
|
|
option (@pxref{Optimize Options}).
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On the MIPS, variable argument functions using @file{varargs.h}
|
|
|
|
cannot have a floating point value for the first argument. The
|
|
|
|
reason for this is that in the absence of a prototype in scope,
|
|
|
|
if the first argument is a floating point, it is passed in a
|
|
|
|
floating point register, rather than an integer register.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If the code is rewritten to use the ANSI standard @file{stdarg.h}
|
|
|
|
method of variable arguments, and the prototype is in scope at
|
|
|
|
the time of the call, everything will work fine.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
On the H8/300 and H8/300H, variable argument functions must be
|
|
|
|
implemented using the ANSI 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.
|
|
|
|
@end itemize
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node C++ Misunderstandings
|
|
|
|
@section Common Misunderstandings with GNU C++
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex misunderstandings in C++
|
|
|
|
@cindex surprises in C++
|
|
|
|
@cindex C++ misunderstandings
|
1999-10-16 06:09:09 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@menu
|
|
|
|
* Static Definitions:: Static member declarations are not definitions
|
|
|
|
* Temporaries:: Temporaries may vanish before you expect
|
1999-10-16 06:09:09 +00:00
|
|
|
* Copy Assignment:: Copy Assignment operators copy virtual bases twice
|
1999-08-26 09:30:50 +00:00
|
|
|
@end menu
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Static Definitions
|
|
|
|
@subsection Declare @emph{and} Define Static Members
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex C++ static data, declaring and defining
|
|
|
|
@cindex static data in C++, declaring and defining
|
|
|
|
@cindex declaring static data in C++
|
|
|
|
@cindex defining static data in C++
|
|
|
|
When a class has static data members, it is not enough to @emph{declare}
|
|
|
|
the static member; you must also @emph{define} it. For example:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
class Foo
|
|
|
|
@{
|
|
|
|
@dots{}
|
|
|
|
void method();
|
|
|
|
static int bar;
|
|
|
|
@};
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
standard, you must supply an initializer in one (and only one) source
|
|
|
|
file, such as:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
int Foo::bar = 0;
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Other C++ compilers may not correctly implement the standard behavior.
|
|
|
|
As a result, when you switch to @code{g++} from one of these compilers,
|
|
|
|
you may discover that a program that appeared to work correctly in fact
|
|
|
|
does not conform to the standard: @code{g++} reports as undefined
|
|
|
|
symbols any static data members that lack definitions.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Temporaries
|
|
|
|
@subsection Temporaries May Vanish Before You Expect
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex temporaries, lifetime of
|
|
|
|
@cindex portions of temporary objects, pointers to
|
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
For example, a program may use a function @code{strfunc} that returns
|
1999-10-16 06:09:09 +00:00
|
|
|
@code{string} objects, and another function @code{charfunc} that
|
1999-08-26 09:30:50 +00:00
|
|
|
operates on pointers to @code{char}:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
1999-10-16 06:09:09 +00:00
|
|
|
string strfunc ();
|
1999-08-26 09:30:50 +00:00
|
|
|
void charfunc (const char *);
|
1999-10-16 06:09:09 +00:00
|
|
|
|
|
|
|
void
|
|
|
|
f ()
|
|
|
|
@{
|
|
|
|
const char *p = strfunc().c_str();
|
|
|
|
...
|
|
|
|
charfunc (p);
|
|
|
|
...
|
|
|
|
charfunc (p);
|
|
|
|
@}
|
1999-08-26 09:30:50 +00:00
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@noindent
|
1999-10-16 06:09:09 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Code like this may run successfully under some other compilers,
|
1999-10-16 06:09:09 +00:00
|
|
|
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
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
@node Copy Assignment
|
|
|
|
@subsection Implicit Copy-Assignment for Virtual Bases
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
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:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
1999-10-16 06:09:09 +00:00
|
|
|
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;
|
|
|
|
@}
|
1999-08-26 09:30:50 +00:00
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
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.
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Protoize Caveats
|
|
|
|
@section Caveats of using @code{protoize}
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The conversion programs @code{protoize} and @code{unprotoize} can
|
|
|
|
sometimes change a source file in a way that won't work unless you
|
|
|
|
rearrange it.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@itemize @bullet
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
@code{protoize} can insert references to a type name or type tag before
|
|
|
|
the definition, or in a file where they are not defined.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If this happens, compiler error messages should show you where the new
|
|
|
|
references are, so fixing the file by hand is straightforward.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
There are some C constructs which @code{protoize} cannot figure out.
|
|
|
|
For example, it can't determine argument types for declaring a
|
|
|
|
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
|
|
|
|
pointer-to-function types.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Using @code{unprotoize} can easily introduce bugs. If the program
|
|
|
|
relied on prototypes to bring about conversion of arguments, these
|
|
|
|
conversions will not take place in the program without prototypes.
|
|
|
|
One case in which you can be sure @code{unprotoize} is safe is when
|
|
|
|
you are removing prototypes that were made with @code{protoize}; if
|
|
|
|
the program worked before without any prototypes, it will work again
|
|
|
|
without them.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
You can find all the places where this problem might occur by compiling
|
|
|
|
the program with the @samp{-Wconversion} option. It prints a warning
|
|
|
|
whenever an argument is converted.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Both conversion programs can be confused if there are macro calls in and
|
|
|
|
around the text to be converted. In other words, the standard syntax
|
|
|
|
for a declaration or definition must not result from expanding a macro.
|
|
|
|
This problem is inherent in the design of C and cannot be fixed. If
|
|
|
|
only a few functions have confusing macro calls, you can easily convert
|
|
|
|
them manually.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
@code{protoize} cannot get the argument types for a function whose
|
|
|
|
definition was not actually compiled due to preprocessing conditionals.
|
|
|
|
When this happens, @code{protoize} changes nothing in regard to such
|
|
|
|
a function. @code{protoize} tries to detect such instances and warn
|
|
|
|
about them.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
You can generally work around this problem by using @code{protoize} step
|
|
|
|
by step, each time specifying a different set of @samp{-D} options for
|
|
|
|
compilation, until all of the functions have been converted. There is
|
|
|
|
no automatic way to verify that you have got them all, however.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Confusion may result if there is an occasion to convert a function
|
|
|
|
declaration or definition in a region of source code where there is more
|
|
|
|
than one formal parameter list present. Thus, attempts to convert code
|
|
|
|
containing multiple (conditionally compiled) versions of a single
|
|
|
|
function header (in the same vicinity) may not produce the desired (or
|
|
|
|
expected) results.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If you plan on converting source files which contain such code, it is
|
|
|
|
recommended that you first make sure that each conditionally compiled
|
|
|
|
region of source code which contains an alternative function header also
|
|
|
|
contains at least one additional follower token (past the final right
|
|
|
|
parenthesis of the function header). This should circumvent the
|
|
|
|
problem.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
@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
|
|
|
|
of formal parameter names.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
You might also want to correct some of the indentation by hand and break
|
|
|
|
long lines. (The conversion programs don't write lines longer than
|
|
|
|
eighty characters in any case.)
|
1996-09-18 05:35:50 +00:00
|
|
|
@end itemize
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Non-bugs
|
|
|
|
@section Certain Changes We Don't Want to Make
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
This section lists changes that people frequently request, but which
|
1999-10-16 06:09:09 +00:00
|
|
|
we do not make because we think GCC is better without them.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@itemize @bullet
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Checking the number and type of arguments to a function which has an
|
|
|
|
old-fashioned definition and no prototype.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Such a feature would work only occasionally---only for calls that appear
|
|
|
|
in the same file as the called function, following the definition. The
|
|
|
|
only way to check all calls reliably is to add a prototype for the
|
|
|
|
function. But adding a prototype eliminates the motivation for this
|
|
|
|
feature. So the feature is not worthwhile.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Warning about using an expression whose type is signed as a shift count.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Shift count operands are probably signed more often than unsigned.
|
|
|
|
Warning about this would cause far more annoyance than good.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Warning about assigning a signed value to an unsigned variable.
|
|
|
|
|
|
|
|
Such assignments must be very common; warning about them would cause
|
|
|
|
more annoyance than good.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Warning about unreachable code.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
It's very common to have unreachable code in machine-generated
|
|
|
|
programs. For example, this happens normally in some files of GNU C
|
|
|
|
itself.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Warning when a non-void function value is ignored.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Coming as I do from a Lisp background, I balk at the idea that there is
|
|
|
|
something dangerous about discarding a value. There are functions that
|
|
|
|
return values which some callers may find useful; it makes no sense to
|
|
|
|
clutter the program with a cast to @code{void} whenever the value isn't
|
|
|
|
useful.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Assuming (for optimization) that the address of an external symbol is
|
|
|
|
never zero.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
This assumption is false on certain systems when @samp{#pragma weak} is
|
|
|
|
used.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Making @samp{-fshort-enums} the default.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
This would cause storage layout to be incompatible with most other C
|
|
|
|
compilers. And it doesn't seem very important, given that you can get
|
|
|
|
the same result in other ways. The case where it matters most is when
|
|
|
|
the enumeration-valued object is inside a structure, and in that case
|
|
|
|
you can specify a field width explicitly.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Making bitfields unsigned by default on particular machines where ``the
|
|
|
|
ABI standard'' says to do so.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The ANSI 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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The GNU C compiler supports both dialects; you can specify the signed
|
|
|
|
dialect with @samp{-fsigned-bitfields} and the unsigned dialect with
|
|
|
|
@samp{-funsigned-bitfields}. However, this leaves open the question of
|
|
|
|
which dialect to use by default.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Currently, the preferred dialect makes plain bitfields signed, because
|
|
|
|
this is simplest. Since @code{int} is the same as @code{signed int} in
|
|
|
|
every other context, it is cleanest for them to be the same in bitfields
|
|
|
|
as well.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Some computer manufacturers have published Application Binary Interface
|
|
|
|
standards which specify that plain bitfields should be unsigned. It is
|
|
|
|
a mistake, however, to say anything about this issue in an ABI. This is
|
|
|
|
because the handling of plain bitfields distinguishes two dialects of C.
|
|
|
|
Both dialects are meaningful on every type of machine. Whether a
|
|
|
|
particular object file was compiled using signed bitfields or unsigned
|
|
|
|
is of no concern to other object files, even if they access the same
|
|
|
|
bitfields in the same data structures.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
A given program is written in one or the other of these two dialects.
|
|
|
|
The program stands a chance to work on most any machine if it is
|
|
|
|
compiled with the proper dialect. It is unlikely to work at all if
|
|
|
|
compiled with the wrong dialect.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Many users appreciate the GNU C compiler because it provides an
|
|
|
|
environment that is uniform across machines. These users would be
|
|
|
|
inconvenienced if the compiler treated plain bitfields differently on
|
|
|
|
certain machines.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Occasionally users write programs intended only for a particular machine
|
|
|
|
type. On these occasions, the users would benefit if the GNU C compiler
|
|
|
|
were to support by default the same dialect as the other compilers on
|
|
|
|
that machine. But such applications are rare. And users writing a
|
|
|
|
program to run on more than one type of machine cannot possibly benefit
|
|
|
|
from this kind of compatibility.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
This is why GCC does and will treat plain bitfields in the same
|
1999-08-26 09:30:50 +00:00
|
|
|
fashion on all types of machines (by default).
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
There are some arguments for making bitfields unsigned by default on all
|
|
|
|
machines. If, for example, this becomes a universal de facto standard,
|
1999-10-16 06:09:09 +00:00
|
|
|
it would make sense for GCC to go along with it. This is something
|
1999-08-26 09:30:50 +00:00
|
|
|
to be considered in the future.
|
|
|
|
|
|
|
|
(Of course, users strongly concerned about portability should indicate
|
|
|
|
explicitly in each bitfield whether it is signed or not. In this way,
|
|
|
|
they write programs which have the same meaning in both C dialects.)
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Undefining @code{__STDC__} when @samp{-ansi} is not used.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
Currently, GCC defines @code{__STDC__} as long as you don't use
|
1999-08-26 09:30:50 +00:00
|
|
|
@samp{-traditional}. This provides good results in practice.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
``yes''.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
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
|
|
|
|
library.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Sometimes people say that defining @code{__STDC__} in a compiler that
|
|
|
|
does not completely conform to the ANSI 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
|
|
|
|
is relevant to the design of plain @samp{gcc} without @samp{-ansi} only
|
|
|
|
for pragmatic reasons, not as a requirement.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC normally defines @code{__STDC__} to be 1, and in addition
|
1999-08-26 09:30:50 +00:00
|
|
|
defines @code{__STRICT_ANSI__} if you specify the @samp{-ansi} option.
|
|
|
|
On some hosts, system include files use a different convention, where
|
|
|
|
@code{__STDC__} is normally 0, but is 1 if the user specifies strict
|
1999-10-16 06:09:09 +00:00
|
|
|
conformance to the C Standard. GCC follows the host convention when
|
1999-08-26 09:30:50 +00:00
|
|
|
processing system include files, but when processing user files it follows
|
|
|
|
the usual GNU C convention.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Undefining @code{__STDC__} in C++.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Programs written to compile with C++-to-C translators get the
|
|
|
|
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
|
|
|
|
or in the traditional fashion.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
C but not in traditional C. Many of these header files can work without
|
|
|
|
change in C++ provided @code{__STDC__} is defined. If @code{__STDC__}
|
|
|
|
is not defined, they will all fail, and will all need to be changed to
|
|
|
|
test explicitly for C++ as well.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Deleting ``empty'' loops.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Making side effects happen in the same order as in some other compiler.
|
|
|
|
|
|
|
|
@cindex side effects, order of evaluation
|
|
|
|
@cindex order of evaluation, side effects
|
|
|
|
It is never safe to depend on the order of evaluation of side effects.
|
|
|
|
For example, a function call like this may very well behave differently
|
|
|
|
from one compiler to another:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@example
|
1999-08-26 09:30:50 +00:00
|
|
|
void func (int, int);
|
|
|
|
|
|
|
|
int i = 2;
|
|
|
|
func (i++, i++);
|
1996-09-18 05:35:50 +00:00
|
|
|
@end example
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
There is no guarantee (in either the C or the C++ standard language
|
|
|
|
definitions) that the increments will be evaluated in any particular
|
|
|
|
order. Either increment might happen first. @code{func} might get the
|
|
|
|
arguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Not allowing structures with volatile fields in registers.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Strictly speaking, there is no prohibition in the ANSI 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.
|
|
|
|
@end itemize
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Warnings and Errors
|
|
|
|
@section Warning Messages and Error Messages
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex error messages
|
|
|
|
@cindex warnings vs errors
|
|
|
|
@cindex messages, warning and error
|
|
|
|
The GNU compiler can produce two kinds of diagnostics: errors and
|
|
|
|
warnings. Each kind has a different purpose:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@itemize @w{}
|
|
|
|
@item
|
|
|
|
@emph{Errors} report problems that make it impossible to compile your
|
1999-10-16 06:09:09 +00:00
|
|
|
program. GCC reports errors with the source file name and line
|
1999-08-26 09:30:50 +00:00
|
|
|
number where the problem is apparent.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
@emph{Warnings} report other unusual conditions in your code that
|
|
|
|
@emph{may} indicate a problem, although compilation can (and does)
|
|
|
|
proceed. Warning messages also report the source file name and line
|
|
|
|
number, but include the text @samp{warning:} to distinguish them
|
|
|
|
from error messages.
|
|
|
|
@end itemize
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Warnings may indicate danger points where you should check to make sure
|
|
|
|
that your program really does what you intend; or the use of obsolete
|
|
|
|
features; or the use of nonstandard features of GNU C or C++. Many
|
|
|
|
warnings are issued only if you ask for them, with one of the @samp{-W}
|
|
|
|
options (for instance, @samp{-Wall} requests a variety of useful
|
|
|
|
warnings).
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC always tries to compile your program if possible; it never
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
compiler. The @samp{-pedantic} option tells GCC to issue warnings in
|
1999-08-26 09:30:50 +00:00
|
|
|
such cases; @samp{-pedantic-errors} says to make them errors instead.
|
|
|
|
This does not mean that @emph{all} non-ANSI constructs get warnings
|
|
|
|
or errors.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@xref{Warning Options,,Options to Request or Suppress Warnings}, for
|
|
|
|
more detail on these and related command-line options.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Bugs
|
|
|
|
@chapter Reporting Bugs
|
|
|
|
@cindex bugs
|
|
|
|
@cindex reporting bugs
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
Your bug reports play an essential role in making GCC reliable.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
report the problem.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
to help the entire community by making the next version of GCC work
|
|
|
|
better. Bug reports are your contribution to the maintenance of GCC.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
send you a patch and ask you to tell us whether it works.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
In order for a bug report to serve its purpose, you must include the
|
|
|
|
information that makes for fixing the bug.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@menu
|
|
|
|
* 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.
|
1999-10-16 06:09:09 +00:00
|
|
|
* Patches: Sending Patches. How to send a patch for GCC.
|
1999-08-26 09:30:50 +00:00
|
|
|
* Known: Trouble. Known problems.
|
|
|
|
* Help: Service. Where to ask for help.
|
|
|
|
@end menu
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Bug Criteria
|
|
|
|
@section Have You Found a Bug?
|
|
|
|
@cindex bug criteria
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If you are not sure whether you have found a bug, here are some guidelines:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@itemize @bullet
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex fatal signal
|
|
|
|
@cindex core dump
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
If the compiler gets a fatal signal, for any input whatever, that is a
|
|
|
|
compiler bug. Reliable compilers never crash.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex invalid assembly code
|
|
|
|
@cindex assembly code, invalid
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
If the compiler produces invalid assembly code, for any input whatever
|
|
|
|
(except an @code{asm} statement), that is a compiler bug, unless the
|
|
|
|
compiler reports errors (not just warnings) which would ordinarily
|
|
|
|
prevent the assembler from being run.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex undefined behavior
|
|
|
|
@cindex undefined function value
|
|
|
|
@cindex increment operators
|
|
|
|
@item
|
|
|
|
If the compiler produces valid assembly code that does not correctly
|
|
|
|
execute the input source code, that is a compiler bug.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
However, you must double-check to make sure, because you may have run
|
|
|
|
into an incompatibility between GNU C and traditional C
|
|
|
|
(@pxref{Incompatibilities}). These incompatibilities might be considered
|
|
|
|
bugs, but they are inescapable consequences of valuable features.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Or you may have a program whose behavior is undefined, which happened
|
|
|
|
by chance to give the desired results with another C or C++ compiler.
|
|
|
|
|
|
|
|
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}
|
1999-10-16 06:09:09 +00:00
|
|
|
is omitted; it is not a bug when GCC produces different results.
|
1999-08-26 09:30:50 +00:00
|
|
|
|
|
|
|
Problems often result from expressions with two increment operators,
|
|
|
|
as in @code{f (*p++, *p++)}. Your previous compiler might have
|
1999-10-16 06:09:09 +00:00
|
|
|
interpreted that expression the way you intended; GCC might
|
1999-08-26 09:30:50 +00:00
|
|
|
interpret it another way. Neither compiler is wrong. The bug is
|
|
|
|
in your code.
|
|
|
|
|
|
|
|
After you have localized the error to a single source line, it should
|
|
|
|
be easy to check for these things. If your program is correct and
|
|
|
|
well defined, you have found a compiler bug.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
If the compiler produces an error message for valid input, that is a
|
|
|
|
compiler bug.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex invalid input
|
|
|
|
@item
|
|
|
|
If the compiler does not produce an error message for invalid input,
|
|
|
|
that is a compiler bug. However, you should note that your idea of
|
|
|
|
``invalid input'' might be my idea of ``an extension'' or ``support
|
|
|
|
for traditional practice''.
|
|
|
|
|
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
If you are an experienced user of C or C++ (or Fortran or Objective-C)
|
|
|
|
compilers, your suggestions
|
|
|
|
for improvement of GCC are welcome in any case.
|
1996-09-18 05:35:50 +00:00
|
|
|
@end itemize
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Bug Lists
|
|
|
|
@section Where to Report Bugs
|
|
|
|
@cindex bug report mailing lists
|
1999-10-16 06:09:09 +00:00
|
|
|
@kindex gcc-bugs@@gcc.gnu.org or bug-gcc@@gnu.org
|
|
|
|
Send bug reports for the GNU Compiler Collection to
|
|
|
|
@samp{gcc-bugs@@gcc.gnu.org}. In accordance with the GNU-wide
|
|
|
|
convention, in which bug reports for tool ``foo'' are sent
|
|
|
|
to @samp{bug-foo@@gnu.org}, the address @samp{bug-gcc@@gnu.org}
|
|
|
|
may also be used; it will forward to the address given above.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
2000-03-09 09:21:46 +00:00
|
|
|
Please read @samp{<URL:http://www.gnu.org/software/gcc/bugs.html>} for
|
1999-10-16 06:09:09 +00:00
|
|
|
bug reporting instructions before you post a bug report.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
As a last resort, send bug reports on paper to:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
GNU Compiler Bugs
|
|
|
|
Free Software Foundation
|
|
|
|
59 Temple Place - Suite 330
|
|
|
|
Boston, MA 02111-1307, USA
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Bug Reporting
|
|
|
|
@section How to Report Bugs
|
|
|
|
@cindex compiler bugs, reporting
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
You may find additional and/or more up-to-date instructions at
|
2000-03-09 09:21:46 +00:00
|
|
|
@samp{<URL:http://www.gnu.org/software/gcc/bugs.html>}.
|
1999-10-16 06:09:09 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The fundamental principle of reporting bugs usefully is this:
|
|
|
|
@strong{report all the facts}. If you are not sure whether to state a
|
|
|
|
fact or leave it out, state it!
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Often people omit facts because they think they know what causes the
|
|
|
|
problem and they conclude that some details don't matter. Thus, you might
|
|
|
|
assume that the name of the variable you use in an example does not matter.
|
|
|
|
Well, probably it doesn't, but one cannot be sure. Perhaps the bug is a
|
|
|
|
stray memory reference which happens to fetch from the location where that
|
|
|
|
name is stored in memory; perhaps, if the name were different, the contents
|
|
|
|
of that location would fool the compiler into doing the right thing despite
|
|
|
|
the bug. Play it safe and give a specific, complete example. That is the
|
|
|
|
easiest thing for you to do, and the most helpful.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Keep in mind that the purpose of a bug report is to enable someone to
|
|
|
|
fix the bug if it is not known. It isn't very important what happens if
|
|
|
|
the bug is already known. Therefore, always write your bug reports on
|
|
|
|
the assumption that the bug is not known.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Sometimes people give a few sketchy facts and ask, ``Does this ring a
|
|
|
|
bell?'' This cannot help us fix a bug, so it is basically useless. We
|
|
|
|
respond by asking for enough details to enable us to investigate.
|
|
|
|
You might as well expedite matters by sending them to begin with.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Try to make your bug report self-contained. If we have to ask you for
|
|
|
|
more information, it is best if you include all the previous information
|
|
|
|
in your response, as well as the information that was missing.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Please report each bug in a separate message. This makes it easier for
|
|
|
|
us to track which bugs have been fixed and to forward your bugs reports
|
|
|
|
to the appropriate maintainer.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
To enable someone to investigate the bug, you should include all these
|
|
|
|
things:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@itemize @bullet
|
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
The version of GCC. You can get this by running it with the
|
1999-08-26 09:30:50 +00:00
|
|
|
@samp{-v} option.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Without this, we won't know whether there is any point in looking for
|
1999-10-16 06:09:09 +00:00
|
|
|
the bug in the current version of GCC.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
A complete input file that will reproduce the bug. If the bug is in the
|
|
|
|
C preprocessor, send a source file and any header files that it
|
1999-10-16 06:09:09 +00:00
|
|
|
requires. If the bug is in the compiler proper (@file{cc1}), send the
|
|
|
|
preprocessor output generated by adding @samp{-save-temps} to the
|
|
|
|
compilation command (@pxref{Debugging Options}). When you do this, use
|
|
|
|
the same @samp{-I}, @samp{-D} or @samp{-U} options that you used in
|
|
|
|
actual compilation. Then send the @var{input}.i or @var{input}.ii files
|
|
|
|
generated.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
A single statement is not enough of an example. In order to compile it,
|
|
|
|
it must be embedded in a complete file of compiler input; and the bug
|
|
|
|
might depend on the details of how this is done.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Without a real example one can compile, all anyone can do about your bug
|
|
|
|
report is wish you luck. It would be futile to try to guess how to
|
|
|
|
provoke the bug. For example, bugs in register allocation and reloading
|
|
|
|
frequently depend on every little detail of the function they happen in.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Even if the input file that fails comes from a GNU program, you should
|
1999-10-16 06:09:09 +00:00
|
|
|
still send the complete test case. Don't ask the GCC maintainers to
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
header files on your system; it is unreliable for the GCC maintainers
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
The command arguments you gave GCC to compile that example
|
1999-08-26 09:30:50 +00:00
|
|
|
and observe the bug. For example, did you use @samp{-O}? To guarantee
|
|
|
|
you won't omit something important, list all the options.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If we were to try to guess the arguments, we would probably guess wrong
|
|
|
|
and then we would not encounter the bug.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
The type of machine you are using, and the operating system name and
|
|
|
|
version number.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
The operands you gave to the @code{configure} command when you installed
|
|
|
|
the compiler.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
A complete list of any modifications you have made to the compiler
|
|
|
|
source. (We don't promise to investigate the bug unless it happens in
|
|
|
|
an unmodified compiler. But if you've made modifications and don't tell
|
|
|
|
us, then you are sending us on a wild goose chase.)
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Be precise about these changes. A description in English is not
|
|
|
|
enough---send a context diff for them.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Adding files of your own (such as a machine description for a machine we
|
|
|
|
don't support) is a modification of the compiler source.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Details of any other deviations from the standard procedure for installing
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
A description of what behavior you observe that you believe is
|
|
|
|
incorrect. For example, ``The compiler gets a fatal signal,'' or,
|
|
|
|
``The assembler instruction at line 208 in the output is incorrect.''
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Of course, if the bug is that the compiler gets a fatal signal, then one
|
|
|
|
can't miss it. But if the bug is incorrect output, the maintainer might
|
|
|
|
not notice unless it is glaringly wrong. None of us has time to study
|
|
|
|
all the assembler code from a 50-line C program just on the chance that
|
|
|
|
one instruction might be wrong. We need @emph{you} to do this part!
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Even if the problem you experience is a fatal signal, you should still
|
|
|
|
say so explicitly. Suppose something strange is going on, such as, your
|
|
|
|
copy of the compiler is out of synch, or you have encountered a bug in
|
|
|
|
the C library on your system. (This has happened!) Your copy might
|
|
|
|
crash and the copy here would not. If you @i{said} to expect a crash,
|
|
|
|
then when the compiler here fails to crash, we would know that the bug
|
|
|
|
was not happening. If you don't say to expect a crash, then we would
|
|
|
|
not know whether the bug was happening. We would not be able to draw
|
|
|
|
any conclusion from our observations.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
If the problem is a diagnostic when compiling GCC with some other
|
1999-08-26 09:30:50 +00:00
|
|
|
compiler, say whether it is a warning or an error.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Often the observed symptom is incorrect output when your program is run.
|
|
|
|
Sad to say, this is not enough information unless the program is short
|
|
|
|
and simple. None of us has time to study a large program to figure out
|
|
|
|
how it would work if compiled correctly, much less which line of it was
|
|
|
|
compiled wrong. So you will have to do that. Tell us which source line
|
|
|
|
it is, and what incorrect result happens when that line is executed. A
|
|
|
|
person who understands the program can find this as easily as finding a
|
|
|
|
bug in the program itself.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
If you send examples of assembler code output from GCC,
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
If you wish to mention something in the GCC source, refer to it by
|
1999-08-26 09:30:50 +00:00
|
|
|
context, not by line number.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The line numbers in the development sources don't match those in your
|
|
|
|
sources. Your line numbers would convey no useful information to the
|
|
|
|
maintainers.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Additional information from a debugger might enable someone to find a
|
|
|
|
problem on a machine which he does not have available. However, you
|
|
|
|
need to think when you collect this information if you want it to have
|
|
|
|
any chance of being useful.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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
|
1999-10-16 06:09:09 +00:00
|
|
|
about GCC because the compiler is largely data-driven; the same
|
1999-08-26 09:30:50 +00:00
|
|
|
functions are called over and over for different RTL insns, doing
|
|
|
|
different things depending on the details of the insn.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Most of the arguments listed in the backtrace are useless because they
|
|
|
|
are pointers to RTL list structure. The numeric values of the
|
|
|
|
pointers, which the debugger prints in the backtrace, have no
|
|
|
|
significance whatever; all that matters is the contents of the objects
|
|
|
|
they point to (and most of the contents are other such pointers).
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
In addition, most compiler passes consist of one or more loops that
|
|
|
|
scan the RTL insn sequence. The most vital piece of information about
|
|
|
|
such a loop---which insn it has reached---is usually in a local variable,
|
|
|
|
not in an argument.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex debug_rtx
|
|
|
|
What you need to provide in addition to a backtrace are the values of
|
|
|
|
the local variables for several stack frames up. When a local
|
|
|
|
variable or an argument is an RTX, first print its value and then use
|
|
|
|
the GDB command @code{pr} to print the RTL expression that it points
|
|
|
|
to. (If GDB doesn't run on your machine, use your debugger to call
|
|
|
|
the function @code{debug_rtx} with the RTX as an argument.) In
|
|
|
|
general, whenever a variable is a pointer, its value is no use
|
|
|
|
without the data it points to.
|
|
|
|
@end itemize
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Here are some things that are not necessary:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@itemize @bullet
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
A description of the envelope of the bug.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Often people who encounter a bug spend a lot of time investigating
|
|
|
|
which changes to the input file will make the bug go away and which
|
|
|
|
changes will not affect it.
|
|
|
|
|
|
|
|
This is often time consuming and not very useful, because the way we
|
|
|
|
will find the bug is by running a single example under the debugger with
|
|
|
|
breakpoints, not by pure deduction from a series of examples. You might
|
|
|
|
as well save your time for something else.
|
|
|
|
|
|
|
|
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.
|
1999-10-16 06:09:09 +00:00
|
|
|
Most GCC bugs involve just one function, so the most straightforward
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
them. (Exception: inline functions may affect compilation of functions
|
|
|
|
defined later in the file.)
|
|
|
|
|
|
|
|
However, simplification is not vital; if you don't want to do this,
|
|
|
|
report the bug anyway and send the entire test case you used.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
In particular, some people insert conditionals @samp{#ifdef BUG} around
|
|
|
|
a statement which, if removed, makes the bug not happen. These are just
|
|
|
|
clutter; we won't pay any attention to them anyway. Besides, you should
|
|
|
|
send us cpp output, and that can't have conditionals.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
A patch for the bug.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
A patch for the bug is useful if it is a good one. But don't omit the
|
|
|
|
necessary information, such as the test case, on the assumption that a
|
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
Sometimes with a program as complicated as GCC it is very hard to
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
|
|
|
|
|
|
|
And if we can't understand what bug you are trying to fix, or why your
|
|
|
|
patch should be an improvement, we won't install it. A test case will
|
|
|
|
help us to understand.
|
|
|
|
|
|
|
|
@xref{Sending Patches}, for guidelines on how to make it easy for us to
|
|
|
|
understand and install your patches.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
A guess about what the bug is or what it depends on.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Such guesses are usually wrong. Even I can't guess right about such
|
|
|
|
things without first using the debugger to find the facts.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
A core dump file.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
We have no way of examining a core dump for your type of machine
|
|
|
|
unless we have an identical system---and if we do have one,
|
|
|
|
we should be able to reproduce the crash ourselves.
|
1996-09-18 05:35:50 +00:00
|
|
|
@end itemize
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Sending Patches,, Bug Reporting, Bugs
|
1999-10-16 06:09:09 +00:00
|
|
|
@section Sending Patches for GCC
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If you would like to write bug fixes or improvements for the GNU C
|
1999-10-16 06:09:09 +00:00
|
|
|
compiler, that is very helpful. Send suggested fixes to the patches
|
|
|
|
mailing list, @code{gcc-patches@@gcc.gnu.org}.
|
1999-08-26 09:30:50 +00:00
|
|
|
|
|
|
|
Please follow these guidelines so we can study your patches efficiently.
|
|
|
|
If you don't follow these guidelines, your information might still be
|
|
|
|
useful, but using it will take extra work. Maintaining GNU C is a lot
|
|
|
|
of work in the best of circumstances, and we can't keep up unless you do
|
|
|
|
your best to help.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@itemize @bullet
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Send an explanation with your changes of what problem they fix or what
|
|
|
|
improvement they bring about. For a bug fix, just include a copy of the
|
|
|
|
bug report, and explain why the change fixes the bug.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
(Referring to a bug report is not as good as including it, because then
|
|
|
|
we will have to look it up, and we have probably already deleted it if
|
|
|
|
we've already fixed the bug.)
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Always include a proper bug report for the problem you think you have
|
|
|
|
fixed. We need to convince ourselves that the change is right before
|
|
|
|
installing it. Even if it is right, we might have trouble judging it if
|
|
|
|
we don't have a way to reproduce the problem.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Include all the comments that are appropriate to help people reading the
|
|
|
|
source in the future understand why this change was needed.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Don't mix together changes made for different reasons.
|
|
|
|
Send them @emph{individually}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If you make two changes for separate reasons, then we might not want to
|
|
|
|
install them both. We might want to install just one. If you send them
|
|
|
|
all jumbled together in a single set of diffs, we have to do extra work
|
|
|
|
to disentangle them---to figure out which parts of the change serve
|
|
|
|
which purpose. If we don't have time for this, we might have to ignore
|
|
|
|
your changes entirely.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If you send each change as soon as you have written it, with its own
|
|
|
|
explanation, then the two changes never get tangled up, and we can
|
|
|
|
consider each one properly without any extra work to disentangle them.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Ideally, each change you send should be impossible to subdivide into
|
|
|
|
parts that we might want to consider separately, because each of its
|
|
|
|
parts gets its motivation from the other parts.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Send each change as soon as that change is finished. Sometimes people
|
|
|
|
think they are helping us by accumulating many changes to send them all
|
|
|
|
together. As explained above, this is absolutely the worst thing you
|
|
|
|
could do.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Since you should send each change separately, you might as well send it
|
|
|
|
right away. That gives us the option of installing it immediately if it
|
|
|
|
is important.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Use @samp{diff -c} to make your diffs. Diffs without context are hard
|
|
|
|
for us to install reliably. More than that, they make it hard for us to
|
|
|
|
study the diffs to decide whether we want to install them. Unidiff
|
|
|
|
format is better than contextless diffs, but not as easy to read as
|
|
|
|
@samp{-c} format.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If you have GNU diff, use @samp{diff -cp}, which shows the name of the
|
|
|
|
function that each change occurs in.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Write the change log entries for your changes. We get lots of changes,
|
|
|
|
and we don't have time to do all the change log writing ourselves.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Read the @file{ChangeLog} file to see what sorts of information to put
|
|
|
|
in, and to learn the style that we use. The purpose of the change log
|
|
|
|
is to show people where to find what was changed. So you need to be
|
|
|
|
specific about what functions you changed; in large functions, it's
|
|
|
|
often helpful to indicate where within the function the change was.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
On the other hand, once you have shown people where to find the change,
|
|
|
|
you need not explain its purpose. Thus, if you add a new function, all
|
|
|
|
you need to say about it is that it is new. If you feel that the
|
|
|
|
purpose needs explaining, it probably does---but the explanation will be
|
|
|
|
much more useful if you put it in comments in the code.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If you would like your name to appear in the header line for who made
|
|
|
|
the change, send us the header line.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
When you write the fix, keep in mind that we can't install a change that
|
|
|
|
would break other systems.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
break GCC for almost all users. We can't possibly make a change like
|
1999-08-26 09:30:50 +00:00
|
|
|
that. At best it might tell us how to write another patch that would
|
|
|
|
solve the problem acceptably.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Sometimes people send fixes that @emph{might} be an improvement in
|
|
|
|
general---but it is hard to be sure of this. It's hard to install
|
|
|
|
such changes because we have to study them very carefully. Of course,
|
|
|
|
a good explanation of the reasoning by which you concluded the change
|
|
|
|
was correct can help convince us.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The safest changes are changes to the configuration files for a
|
|
|
|
particular machine. These are safe because they can't create new bugs
|
|
|
|
on other machines.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Please help us keep up with the workload by designing the patch in a
|
|
|
|
form that is good to install.
|
|
|
|
@end itemize
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Service
|
1999-10-16 06:09:09 +00:00
|
|
|
@chapter How To Get Help with GCC
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
If you need help installing, using or changing GCC, there are two
|
1999-08-26 09:30:50 +00:00
|
|
|
ways to find it:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@itemize @bullet
|
|
|
|
@item
|
|
|
|
Send a message to a suitable network mailing list. First try
|
1999-10-16 06:09:09 +00:00
|
|
|
@code{gcc-bugs@@gcc.gnu.org} or @code{bug-gcc@@gnu.org}, and if that
|
|
|
|
brings no response, try @code{gcc@@gcc.gnu.org}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC distribution.
|
1999-08-26 09:30:50 +00:00
|
|
|
@end itemize
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Contributing
|
1999-10-16 06:09:09 +00:00
|
|
|
@chapter Contributing to GCC Development
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
If you would like to help pretest GCC releases to assure they work
|
|
|
|
well, or if you would like to work on improving GCC, please contact
|
|
|
|
the maintainers at @code{gcc@@gcc.gnu.org}. A pretester should
|
1999-08-26 09:30:50 +00:00
|
|
|
be willing to try to investigate bugs as well as report them.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
to contact @code{gcc@@gcc.gnu.org} before you start; the
|
1999-08-26 09:30:50 +00:00
|
|
|
maintainers may be able to suggest ways to make your extension fit in
|
1999-10-16 06:09:09 +00:00
|
|
|
better with the rest of GCC and with other development plans.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node VMS
|
1999-10-16 06:09:09 +00:00
|
|
|
@chapter Using GCC on VMS
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@c prevent bad page break with this line
|
1999-10-16 06:09:09 +00:00
|
|
|
Here is how to use GCC on VMS.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@menu
|
|
|
|
* Include Files and VMS:: Where the preprocessor looks for the include files.
|
|
|
|
* Global Declarations:: How to do globaldef, globalref and globalvalue with
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC.
|
1999-08-26 09:30:50 +00:00
|
|
|
* VMS Misc:: Misc information.
|
|
|
|
@end menu
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Include Files and VMS
|
|
|
|
@section Include Files and VMS
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex include files and VMS
|
|
|
|
@cindex VMS and include files
|
|
|
|
@cindex header files and VMS
|
1999-10-16 06:09:09 +00:00
|
|
|
Due to the differences between the filesystems of Unix and VMS, GCC
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
filename, and then try to open the file. GCC tries various prefixes
|
1999-08-26 09:30:50 +00:00
|
|
|
one by one until one of them succeeds:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@enumerate
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
The first prefix is the @samp{GNU_CC_INCLUDE:} logical name: this is
|
|
|
|
where GNU C header files are traditionally stored. If you wish to store
|
|
|
|
header files in non-standard locations, then you can assign the logical
|
|
|
|
@samp{GNU_CC_INCLUDE} to be a search list, where each element of the
|
|
|
|
list is suitable for use with a rooted logical.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
The next prefix tried is @samp{SYS$SYSROOT:[SYSLIB.]}. This is where
|
|
|
|
VAX-C header files are traditionally stored.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
If the include file specification by itself is a valid VMS filename, the
|
|
|
|
preprocessor then uses this name with no prefix in an attempt to open
|
|
|
|
the include file.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
If the file specification is not a valid VMS filename (i.e. does not
|
|
|
|
contain a device or a directory specifier, and contains a @samp{/}
|
|
|
|
character), the preprocessor tries to convert it from Unix syntax to
|
|
|
|
VMS syntax.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Conversion works like this: the first directory name becomes a device,
|
|
|
|
and the rest of the directories are converted into VMS-format directory
|
|
|
|
names. For example, the name @file{X11/foobar.h} is
|
|
|
|
translated to @file{X11:[000000]foobar.h} or @file{X11:foobar.h},
|
|
|
|
whichever one can be opened. This strategy allows you to assign a
|
|
|
|
logical name to point to the actual location of the header files.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
If none of these strategies succeeds, the @samp{#include} fails.
|
|
|
|
@end enumerate
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Include directives of the form:
|
|
|
|
|
|
|
|
@example
|
|
|
|
#include foobar
|
1996-09-18 05:35:50 +00:00
|
|
|
@end example
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@noindent
|
1999-10-16 06:09:09 +00:00
|
|
|
are a common source of incompatibility between VAX-C and GCC. VAX-C
|
1999-08-26 09:30:50 +00:00
|
|
|
treats this much like a standard @code{#include <foobar.h>} directive.
|
1999-10-16 06:09:09 +00:00
|
|
|
That is incompatible with the ANSI C behavior implemented by GCC: to
|
1999-08-26 09:30:50 +00:00
|
|
|
expand the name @code{foobar} as a macro. Macro expansion should
|
|
|
|
eventually yield one of the two standard formats for @code{#include}:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
#include "@var{file}"
|
|
|
|
#include <@var{file}>
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If you have this problem, the best solution is to modify the source to
|
|
|
|
convert the @code{#include} directives to one of the two standard forms.
|
|
|
|
That will work with either compiler. If you want a quick and dirty fix,
|
|
|
|
define the file names as macros with the proper expansion, like this:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
#define stdio <stdio.h>
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@noindent
|
|
|
|
This will work, as long as the name doesn't conflict with anything else
|
|
|
|
in the program.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Another source of incompatibility is that VAX-C assumes that:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
#include "foobar"
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@noindent
|
1999-10-16 06:09:09 +00:00
|
|
|
is actually asking for the file @file{foobar.h}. GCC does not
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC for VMS is distributed with a set of include files that is
|
1999-08-26 09:30:50 +00:00
|
|
|
sufficient to compile most general purpose programs. Even though the
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC distribution does not contain header files to define constants
|
1999-08-26 09:30:50 +00:00
|
|
|
and structures for some VMS system-specific functions, there is no
|
1999-10-16 06:09:09 +00:00
|
|
|
reason why you cannot use GCC with any of these functions. You first
|
1999-08-26 09:30:50 +00:00
|
|
|
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,
|
|
|
|
and using an editor to construct a C header file.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
A @code{#include} file name cannot contain a DECNET node name. The
|
|
|
|
preprocessor reports an I/O error if you attempt to use a node name,
|
|
|
|
whether explicitly, or implicitly via a logical name.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Global Declarations
|
|
|
|
@section Global Declarations and VMS
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex GLOBALREF
|
|
|
|
@findex GLOBALDEF
|
|
|
|
@findex GLOBALVALUEDEF
|
|
|
|
@findex GLOBALVALUEREF
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC does not provide the @code{globalref}, @code{globaldef} and
|
1999-08-26 09:30:50 +00:00
|
|
|
@code{globalvalue} keywords of VAX-C. You can get the same effect with
|
|
|
|
an obscure feature of GAS, the GNU assembler. (This requires GAS
|
|
|
|
version 1.39 or later.) The following macros allow you to use this
|
|
|
|
feature in a fairly natural way:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@smallexample
|
|
|
|
#ifdef __GNUC__
|
|
|
|
#define GLOBALREF(TYPE,NAME) \
|
|
|
|
TYPE NAME \
|
|
|
|
asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME)
|
|
|
|
#define GLOBALDEF(TYPE,NAME,VALUE) \
|
|
|
|
TYPE NAME \
|
|
|
|
asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME) \
|
|
|
|
= VALUE
|
|
|
|
#define GLOBALVALUEREF(TYPE,NAME) \
|
|
|
|
const TYPE NAME[1] \
|
|
|
|
asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME)
|
|
|
|
#define GLOBALVALUEDEF(TYPE,NAME,VALUE) \
|
|
|
|
const TYPE NAME[1] \
|
|
|
|
asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME) \
|
|
|
|
= @{VALUE@}
|
|
|
|
#else
|
|
|
|
#define GLOBALREF(TYPE,NAME) \
|
|
|
|
globalref TYPE NAME
|
|
|
|
#define GLOBALDEF(TYPE,NAME,VALUE) \
|
|
|
|
globaldef TYPE NAME = VALUE
|
|
|
|
#define GLOBALVALUEDEF(TYPE,NAME,VALUE) \
|
|
|
|
globalvalue TYPE NAME = VALUE
|
|
|
|
#define GLOBALVALUEREF(TYPE,NAME) \
|
|
|
|
globalvalue TYPE NAME
|
|
|
|
#endif
|
|
|
|
@end smallexample
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@noindent
|
|
|
|
(The @code{_$$PsectAttributes_GLOBALSYMBOL} prefix at the start of the
|
|
|
|
name is removed by the assembler, after it has modified the attributes
|
|
|
|
of the symbol). These macros are provided in the VMS binaries
|
|
|
|
distribution in a header file @file{GNU_HACKS.H}. An example of the
|
|
|
|
usage is:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
GLOBALREF (int, ijk);
|
|
|
|
GLOBALDEF (int, jkl, 0);
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The macros @code{GLOBALREF} and @code{GLOBALDEF} cannot be used
|
|
|
|
straightforwardly for arrays, since there is no way to insert the array
|
|
|
|
dimension into the declaration at the right place. However, you can
|
|
|
|
declare an array with these macros if you first define a typedef for the
|
|
|
|
array type, like this:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
typedef int intvector[10];
|
|
|
|
GLOBALREF (intvector, foo);
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Array and structure initializers will also break the macros; you can
|
|
|
|
define the initializer to be a macro of its own, or you can expand the
|
|
|
|
@code{GLOBALDEF} macro by hand. You may find a case where you wish to
|
|
|
|
use the @code{GLOBALDEF} macro with a large array, but you are not
|
|
|
|
interested in explicitly initializing each element of the array. In
|
|
|
|
such cases you can use an initializer like: @code{@{0,@}}, which will
|
|
|
|
initialize the entire array to @code{0}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
A shortcoming of this implementation is that a variable declared with
|
|
|
|
@code{GLOBALVALUEREF} or @code{GLOBALVALUEDEF} is always an array. For
|
|
|
|
example, the declaration:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
GLOBALVALUEREF(int, ijk);
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@noindent
|
|
|
|
declares the variable @code{ijk} as an array of type @code{int [1]}.
|
|
|
|
This is done because a globalvalue is actually a constant; its ``value''
|
|
|
|
is what the linker would normally consider an address. That is not how
|
|
|
|
an integer value works in C, but it is how an array works. So treating
|
|
|
|
the symbol as an array name gives consistent results---with the
|
|
|
|
exception that the value seems to have the wrong type. @strong{Don't
|
|
|
|
try to access an element of the array.} It doesn't have any elements.
|
|
|
|
The array ``address'' may not be the address of actual storage.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
expand to use the same name as the macro itself.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
GLOBALVALUEREF (int, ss$_normal);
|
|
|
|
GLOBALVALUEDEF (int, xyzzy,123);
|
|
|
|
#ifdef __GNUC__
|
|
|
|
#define ss$_normal ((int) ss$_normal)
|
|
|
|
#define xyzzy ((int) xyzzy)
|
|
|
|
#endif
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Don't use @code{globaldef} or @code{globalref} with a variable whose
|
|
|
|
type is an enumeration type; this is not implemented. Instead, make the
|
|
|
|
variable an integer, and use a @code{globalvaluedef} for each of the
|
|
|
|
enumeration values. An example of this would be:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
#ifdef __GNUC__
|
|
|
|
GLOBALDEF (int, color, 0);
|
|
|
|
GLOBALVALUEDEF (int, RED, 0);
|
|
|
|
GLOBALVALUEDEF (int, BLUE, 1);
|
|
|
|
GLOBALVALUEDEF (int, GREEN, 3);
|
|
|
|
#else
|
|
|
|
enum globaldef color @{RED, BLUE, GREEN = 3@};
|
|
|
|
#endif
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node VMS Misc
|
|
|
|
@section Other VMS Issues
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex exit status and VMS
|
|
|
|
@cindex return value of @code{main}
|
|
|
|
@cindex @code{main} and the exit status
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC automatically arranges for @code{main} to return 1 by default if
|
1999-08-26 09:30:50 +00:00
|
|
|
you fail to specify an explicit return value. This will be interpreted
|
|
|
|
by VMS as a status code indicating a normal successful completion.
|
1999-10-16 06:09:09 +00:00
|
|
|
Version 1 of GCC did not provide this default.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC on VMS works only with the GNU assembler, GAS. You need version
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex shared VMS run time system
|
|
|
|
@cindex @file{VAXCRTL}
|
1999-10-16 06:09:09 +00:00
|
|
|
Under previous versions of GCC, the generated code would occasionally
|
1999-08-26 09:30:50 +00:00
|
|
|
give strange results when linked to the sharable @file{VAXCRTL} library.
|
|
|
|
Now this should work.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
A caveat for use of @code{const} global variables: the @code{const}
|
|
|
|
modifier must be specified in every external declaration of the variable
|
|
|
|
in all of the source files that use that variable. Otherwise the linker
|
|
|
|
will issue warnings about conflicting attributes for the variable. Your
|
|
|
|
program will still work despite the warnings, but the variable will be
|
|
|
|
placed in writable storage.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex name augmentation
|
|
|
|
@cindex case sensitivity and VMS
|
|
|
|
@cindex VMS and case sensitivity
|
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
names. To be able to reliably call such routines, GCC (by means of
|
1999-08-26 09:30:50 +00:00
|
|
|
the assembler GAS) converts global symbols into upper case like other
|
|
|
|
VMS compilers. However, since the usual practice in C is to distinguish
|
1999-10-16 06:09:09 +00:00
|
|
|
case, GCC (via GAS) tries to preserve usual C behavior by augmenting
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
least one dollar sign are an exception; they are converted directly into
|
|
|
|
upper case without augmentation.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Name augmentation yields bad results for programs that use precompiled
|
|
|
|
libraries (such as Xlib) which were generated by another compiler. You
|
|
|
|
can use the compiler option @samp{/NOCASE_HACK} to inhibit augmentation;
|
|
|
|
it makes external C functions and variables case-independent as is usual
|
|
|
|
on VMS. Alternatively, you could write all references to the functions
|
|
|
|
and variables in such libraries using lower case; this will work on VMS,
|
|
|
|
but is not portable to other systems. The compiler option @samp{/NAMES}
|
|
|
|
also provides control over global name handling.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Function and variable names are handled somewhat differently with GNU
|
|
|
|
C++. The GNU C++ compiler performs @dfn{name mangling} on function
|
|
|
|
names, which means that it adds information to the function name to
|
|
|
|
describe the data types of the arguments that the function takes. One
|
|
|
|
result of this is that the name of a function can become very long.
|
|
|
|
Since the VMS linker only recognizes the first 31 characters in a name,
|
|
|
|
special action is taken to ensure that each function and variable has a
|
|
|
|
unique name that can be represented in 31 characters.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If the name (plus a name augmentation, if required) is less than 32
|
|
|
|
characters in length, then no special action is performed. If the name
|
|
|
|
is longer than 31 characters, the assembler (GAS) will generate a
|
|
|
|
hash string based upon the function name, truncate the function name to
|
|
|
|
23 characters, and append the hash string to the truncated name. If the
|
|
|
|
@samp{/VERBOSE} compiler option is used, the assembler will print both
|
|
|
|
the full and truncated names of each symbol that is truncated.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The @samp{/NOCASE_HACK} compiler option should not be used when you are
|
|
|
|
compiling programs that use libg++. libg++ has several instances of
|
|
|
|
objects (i.e. @code{Filebuf} and @code{filebuf}) which become
|
|
|
|
indistinguishable in a case-insensitive environment. This leads to
|
|
|
|
cases where you need to inhibit augmentation selectively (if you were
|
|
|
|
using libg++ and Xlib in the same program, for example). There is no
|
|
|
|
special feature for doing this, but you can get the result by defining a
|
|
|
|
macro for each mixed case symbol for which you wish to inhibit
|
|
|
|
augmentation. The macro should expand into the lower case equivalent of
|
|
|
|
itself. For example:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@example
|
1999-08-26 09:30:50 +00:00
|
|
|
#define StuDlyCapS studlycaps
|
1996-09-18 05:35:50 +00:00
|
|
|
@end example
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
These macro definitions can be placed in a header file to minimize the
|
|
|
|
number of changes to your source code.
|
|
|
|
@end ifset
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@ifset INTERNALS
|
|
|
|
@node Portability
|
1999-10-16 06:09:09 +00:00
|
|
|
@chapter GCC and Portability
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex portability
|
1999-10-16 06:09:09 +00:00
|
|
|
@cindex GCC and portability
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
The main goal of GCC was to make a good, fast compiler for machines in
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC gets most of the information about the target machine from a machine
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
fashion, I have not hesitated to define an ad-hoc parameter to the machine
|
|
|
|
description. The purpose of portability is to reduce the total work needed
|
|
|
|
on the compiler; it was not of interest for its own sake.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex endianness
|
|
|
|
@cindex autoincrement addressing, availability
|
|
|
|
@findex abort
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC does not contain machine dependent code, but it does contain code
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
pass, it is often necessary to have multiple strategies for generating code
|
|
|
|
for a particular kind of syntax tree, strategies that are usable for different
|
|
|
|
combinations of parameters. Often I have not tried to address all possible
|
|
|
|
cases, but only the common ones or only the ones that I have encountered.
|
|
|
|
As a result, a new target may require additional strategies. You will know
|
|
|
|
if this happens because the compiler will call @code{abort}. Fortunately,
|
|
|
|
the new strategies can be added in a machine-independent fashion, and will
|
|
|
|
affect only the target machines that need them.
|
|
|
|
@end ifset
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@ifset INTERNALS
|
|
|
|
@node Interface
|
1999-10-16 06:09:09 +00:00
|
|
|
@chapter Interfacing to GCC Output
|
|
|
|
@cindex interfacing to GCC output
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex run-time conventions
|
|
|
|
@cindex function call conventions
|
|
|
|
@cindex conventions, run-time
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC is normally configured to use the same function calling convention
|
1999-08-26 09:30:50 +00:00
|
|
|
normally in use on the target system. This is done with the
|
|
|
|
machine-description macros described (@pxref{Target Macros}).
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex unions, returning
|
|
|
|
@cindex structures, returning
|
|
|
|
@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
|
1999-10-16 06:09:09 +00:00
|
|
|
returning such types cannot be called from code compiled with GCC,
|
1999-08-26 09:30:50 +00:00
|
|
|
and vice versa. This does not cause trouble often because few Unix
|
|
|
|
library routines return structures or unions.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC code returns structures and unions that are 1, 2, 4 or 8 bytes
|
1999-08-26 09:30:50 +00:00
|
|
|
long in the same registers used for @code{int} or @code{double} return
|
1999-10-16 06:09:09 +00:00
|
|
|
values. (GCC typically allocates variables of such types in
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
@code{STRUCT_INCOMING_VALUE} tell GCC where to pass this address.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
the value is wanted. This is slower than the method used by GCC, and
|
1999-08-26 09:30:50 +00:00
|
|
|
fails to be reentrant.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
On some target machines, such as RISC machines and the 80386, the
|
|
|
|
standard system convention is to pass to the subroutine the address of
|
1999-10-16 06:09:09 +00:00
|
|
|
where to return the value. On these machines, GCC has been
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex argument passing
|
|
|
|
@cindex passing arguments
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC uses the system's standard convention for passing arguments. On
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
change is practical only if you are switching to GCC as the sole C
|
1999-08-26 09:30:50 +00:00
|
|
|
compiler for the system. We may implement register argument passing on
|
|
|
|
certain machines once we have a complete GNU system so that we can
|
1999-10-16 06:09:09 +00:00
|
|
|
compile the libraries with GCC.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
On some machines (particularly the Sparc), certain types of arguments
|
|
|
|
are passed ``by invisible reference''. This means that the value is
|
|
|
|
stored in memory, and the address of the memory location is passed to
|
|
|
|
the subroutine.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex @code{longjmp} and automatic variables
|
|
|
|
If you use @code{longjmp}, beware of automatic variables. ANSI C says that
|
|
|
|
automatic variables that are not declared @code{volatile} have undefined
|
1999-10-16 06:09:09 +00:00
|
|
|
values after a @code{longjmp}. And this is all GCC promises to do,
|
1999-08-26 09:30:50 +00:00
|
|
|
because it is very difficult to restore register variables correctly, and
|
1999-10-16 06:09:09 +00:00
|
|
|
one of GCC's features is that it can put variables in registers without
|
1999-08-26 09:30:50 +00:00
|
|
|
your asking it to.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If you want a variable to be unaltered by @code{longjmp}, and you don't
|
|
|
|
want to write @code{volatile} because old C compilers don't accept it,
|
|
|
|
just take the address of the variable. If a variable's address is ever
|
|
|
|
taken, even if just to compute it and ignore it, then the variable cannot
|
|
|
|
go in a register:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@example
|
|
|
|
@{
|
|
|
|
int careful;
|
|
|
|
&careful;
|
|
|
|
@dots{}
|
|
|
|
@}
|
|
|
|
@end example
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex arithmetic libraries
|
|
|
|
@cindex math libraries
|
1999-10-16 06:09:09 +00:00
|
|
|
Code compiled with GCC may call certain library routines. Most of
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
with @samp{-msoft-float}. Some standard parts of the C library, such as
|
|
|
|
@code{bcopy} or @code{memcpy}, are also called automatically. The usual
|
|
|
|
function call interface is used for calling the library routines.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
These library routines should be defined in the library @file{libgcc.a},
|
1999-10-16 06:09:09 +00:00
|
|
|
which GCC automatically searches whenever it links a program. On
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Each arithmetic function is defined in @file{libgcc1.c} to use the
|
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
compiled with GCC, because each arithmetic function would compile
|
1999-08-26 09:30:50 +00:00
|
|
|
into a call to itself!
|
|
|
|
@end ifset
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@ifset INTERNALS
|
|
|
|
@node Passes
|
|
|
|
@chapter Passes and Files of the Compiler
|
|
|
|
@cindex passes and files of the compiler
|
|
|
|
@cindex files and passes of the compiler
|
|
|
|
@cindex compiler passes and files
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex top level of compiler
|
|
|
|
The overall control structure of the compiler is in @file{toplev.c}. This
|
|
|
|
file is responsible for initialization, decoding arguments, opening and
|
|
|
|
closing files, and sequencing the passes.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex parsing pass
|
|
|
|
The parsing pass is invoked only once, to parse the entire input. The RTL
|
|
|
|
intermediate code for a function is generated as the function is parsed, a
|
|
|
|
statement at a time. Each statement is read in as a syntax tree and then
|
|
|
|
converted to RTL; then the storage for the tree for the statement is
|
|
|
|
reclaimed. Storage for types (and the expressions for their sizes),
|
|
|
|
declarations, and a representation of the binding contours and how they nest,
|
|
|
|
remain until the function is finished being compiled; these are all needed
|
|
|
|
to output the debugging information.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex rest_of_compilation
|
|
|
|
@findex rest_of_decl_compilation
|
|
|
|
Each time the parsing pass reads a complete function definition or
|
|
|
|
top-level declaration, it calls either the function
|
|
|
|
@code{rest_of_compilation}, or the function
|
|
|
|
@code{rest_of_decl_compilation} in @file{toplev.c}, which are
|
|
|
|
responsible for all further processing necessary, ending with output of
|
|
|
|
the assembler language. All other compiler passes run, in sequence,
|
|
|
|
within @code{rest_of_compilation}. When that function returns from
|
|
|
|
compiling a function definition, the storage used for that function
|
|
|
|
definition's compilation is entirely freed, unless it is an inline
|
|
|
|
function
|
|
|
|
@ifset USING
|
|
|
|
(@pxref{Inline,,An Inline Function is As Fast As a Macro}).
|
|
|
|
@end ifset
|
|
|
|
@ifclear USING
|
|
|
|
(@pxref{Inline,,An Inline Function is As Fast As a Macro,gcc.texi,Using GCC}).
|
|
|
|
@end ifclear
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Here is a list of all the passes of the compiler and their source files.
|
|
|
|
Also included is a description of where debugging dumps can be requested
|
|
|
|
with @samp{-d} options.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@itemize @bullet
|
|
|
|
@item
|
|
|
|
Parsing. This pass reads the entire text of a function definition,
|
|
|
|
constructing partial syntax trees. This and RTL generation are no longer
|
|
|
|
truly separate passes (formerly they were), but it is easier to think
|
|
|
|
of them as separate.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The tree representation does not entirely follow C syntax, because it is
|
|
|
|
intended to support other languages as well.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Language-specific data type analysis is also done in this pass, and every
|
|
|
|
tree node that represents an expression has a data type attached.
|
|
|
|
Variables are represented as declaration nodes.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex constant folding
|
|
|
|
@cindex arithmetic simplifications
|
|
|
|
@cindex simplifications, arithmetic
|
|
|
|
Constant folding and some arithmetic simplifications are also done
|
|
|
|
during this pass.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The language-independent source files for parsing are
|
|
|
|
@file{stor-layout.c}, @file{fold-const.c}, and @file{tree.c}.
|
|
|
|
There are also header files @file{tree.h} and @file{tree.def}
|
|
|
|
which define the format of the tree representation.@refill
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@c Avoiding overfull is tricky here.
|
|
|
|
The source files to parse C are
|
|
|
|
@file{c-parse.in},
|
|
|
|
@file{c-decl.c},
|
|
|
|
@file{c-typeck.c},
|
|
|
|
@file{c-aux-info.c},
|
|
|
|
@file{c-convert.c},
|
|
|
|
and @file{c-lang.c}
|
|
|
|
along with header files
|
|
|
|
@file{c-lex.h}, and
|
|
|
|
@file{c-tree.h}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
well.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The file @file{c-common.c} is also used for all of the above languages.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex RTL generation
|
|
|
|
@item
|
|
|
|
RTL generation. This is the conversion of syntax tree into RTL code.
|
|
|
|
It is actually done statement-by-statement during parsing, but for
|
|
|
|
most purposes it can be thought of as a separate pass.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex target-parameter-dependent code
|
|
|
|
This is where the bulk of target-parameter-dependent code is found,
|
|
|
|
since often it is necessary for strategies to apply only when certain
|
|
|
|
standard kinds of instructions are available. The purpose of named
|
|
|
|
instruction patterns is to provide this information to the RTL
|
|
|
|
generation pass.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex tail recursion optimization
|
|
|
|
Optimization is done in this pass for @code{if}-conditions that are
|
|
|
|
comparisons, boolean operations or conditional expressions. Tail
|
|
|
|
recursion is detected at this time also. Decisions are made about how
|
|
|
|
best to arrange loops and how to output @code{switch} statements.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@c Avoiding overfull is tricky here.
|
|
|
|
The source files for RTL generation include
|
|
|
|
@file{stmt.c},
|
|
|
|
@file{calls.c},
|
|
|
|
@file{expr.c},
|
|
|
|
@file{explow.c},
|
|
|
|
@file{expmed.c},
|
|
|
|
@file{function.c},
|
|
|
|
@file{optabs.c}
|
|
|
|
and @file{emit-rtl.c}.
|
|
|
|
Also, the file
|
|
|
|
@file{insn-emit.c}, generated from the machine description by the
|
|
|
|
program @code{genemit}, is used in this pass. The header file
|
|
|
|
@file{expr.h} is used for communication within this pass.@refill
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex genflags
|
|
|
|
@findex gencodes
|
|
|
|
The header files @file{insn-flags.h} and @file{insn-codes.h},
|
|
|
|
generated from the machine description by the programs @code{genflags}
|
|
|
|
and @code{gencodes}, tell this pass which standard names are available
|
|
|
|
for use and which patterns correspond to them.@refill
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Aside from debugging information output, none of the following passes
|
|
|
|
refers to the tree structure representation of the function (only
|
|
|
|
part of which is saved).
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex inline, automatic
|
|
|
|
The decision of whether the function can and should be expanded inline
|
|
|
|
in its subsequent callers is made at the end of rtl generation. The
|
|
|
|
function must meet certain criteria, currently related to the size of
|
|
|
|
the function and the types and number of parameters it has. Note that
|
|
|
|
this function may contain loops, recursive calls to itself
|
|
|
|
(tail-recursive functions can be inlined!), gotos, in short, all
|
1999-10-16 06:09:09 +00:00
|
|
|
constructs supported by GCC. The file @file{integrate.c} contains
|
1999-08-26 09:30:50 +00:00
|
|
|
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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The option @samp{-dr} causes a debugging dump of the RTL code after
|
|
|
|
this pass. This dump file's name is made by appending @samp{.rtl} to
|
|
|
|
the input file name.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex jump optimization
|
|
|
|
@cindex unreachable code
|
|
|
|
@cindex dead code
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Jump optimization. This pass simplifies jumps to the following
|
|
|
|
instruction, jumps across jumps, and jumps to jumps. It deletes
|
|
|
|
unreferenced labels and unreachable code, except that unreachable code
|
|
|
|
that contains a loop is not recognized as unreachable in this pass.
|
|
|
|
(Such loops are deleted later in the basic block analysis.) It also
|
|
|
|
converts some code originally written with jumps into sequences of
|
|
|
|
instructions that directly set values from the results of comparisons,
|
|
|
|
if the machine has such instructions.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Jump optimization is performed two or three times. The first time is
|
|
|
|
immediately following RTL generation. The second time is after CSE,
|
|
|
|
but only if CSE says repeated jump optimization is needed. The
|
|
|
|
last time is right before the final pass. That time, cross-jumping
|
|
|
|
and deletion of no-op move instructions are done together with the
|
|
|
|
optimizations described above.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The source file of this pass is @file{jump.c}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The option @samp{-dj} causes a debugging dump of the RTL code after
|
|
|
|
this pass is run for the first time. This dump file's name is made by
|
|
|
|
appending @samp{.jump} to the input file name.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex register use analysis
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Register scan. This pass finds the first and last use of each
|
|
|
|
register, as a guide for common subexpression elimination. Its source
|
|
|
|
is in @file{regclass.c}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex jump threading
|
|
|
|
@item
|
|
|
|
Jump threading. This pass detects a condition jump that branches to an
|
|
|
|
identical or inverse test. Such jumps can be @samp{threaded} through
|
|
|
|
the second conditional test. The source code for this pass is in
|
|
|
|
@file{jump.c}. This optimization is only performed if
|
|
|
|
@samp{-fthread-jumps} is enabled.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex common subexpression elimination
|
|
|
|
@cindex constant propagation
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Common subexpression elimination. This pass also does constant
|
|
|
|
propagation. Its source file is @file{cse.c}. If constant
|
|
|
|
propagation causes conditional jumps to become unconditional or to
|
|
|
|
become no-ops, jump optimization is run again when CSE is finished.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The option @samp{-ds} causes a debugging dump of the RTL code after
|
|
|
|
this pass. This dump file's name is made by appending @samp{.cse} to
|
|
|
|
the input file name.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex global common subexpression elimination
|
|
|
|
@cindex constant propagation
|
|
|
|
@cindex copy propagation
|
|
|
|
@item
|
|
|
|
Global common subexpression elimination. This pass performs GCSE
|
|
|
|
using Morel-Renvoise Partial Redundancy Elimination, with the exception
|
|
|
|
that it does not try to move invariants out of loops - that is left to
|
|
|
|
the loop optimization pass. This pass also performs global constant
|
|
|
|
and copy propagation.
|
|
|
|
|
|
|
|
The source file for this pass is gcse.c.
|
|
|
|
|
|
|
|
The option @samp{-dG} causes a debugging dump of the RTL code after
|
|
|
|
this pass. This dump file's name is made by appending @samp{.gcse} to
|
|
|
|
the input file name.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex loop optimization
|
|
|
|
@cindex code motion
|
|
|
|
@cindex strength-reduction
|
|
|
|
@item
|
|
|
|
Loop optimization. This pass moves constant expressions out of loops,
|
|
|
|
and optionally does strength-reduction and loop unrolling as well.
|
|
|
|
Its source files are @file{loop.c} and @file{unroll.c}, plus the header
|
|
|
|
@file{loop.h} used for communication between them. Loop unrolling uses
|
|
|
|
some functions in @file{integrate.c} and the header @file{integrate.h}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The option @samp{-dL} causes a debugging dump of the RTL code after
|
|
|
|
this pass. This dump file's name is made by appending @samp{.loop} to
|
|
|
|
the input file name.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
If @samp{-frerun-cse-after-loop} was enabled, a second common
|
|
|
|
subexpression elimination pass is performed after the loop optimization
|
|
|
|
pass. Jump threading is also done again at this time if it was specified.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The option @samp{-dt} causes a debugging dump of the RTL code after
|
|
|
|
this pass. This dump file's name is made by appending @samp{.cse2} to
|
|
|
|
the input file name.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex register allocation, stupid
|
|
|
|
@cindex stupid register allocation
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
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}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex data flow analysis
|
|
|
|
@cindex analysis, data flow
|
|
|
|
@cindex basic blocks
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Data flow analysis (@file{flow.c}). This pass divides the program
|
|
|
|
into basic blocks (and in the process deletes unreachable loops); then
|
|
|
|
it computes which pseudo-registers are live at each point in the
|
|
|
|
program, and makes the first instruction that uses a value point at
|
|
|
|
the instruction that computed the value.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex autoincrement/decrement analysis
|
|
|
|
This pass also deletes computations whose results are never used, and
|
|
|
|
combines memory references with add or subtract instructions to make
|
|
|
|
autoincrement or autodecrement addressing.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The option @samp{-df} causes a debugging dump of the RTL code after
|
|
|
|
this pass. This dump file's name is made by appending @samp{.flow} to
|
|
|
|
the input file name. If stupid register allocation is in use, this
|
|
|
|
dump file reflects the full results of such allocation.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex instruction combination
|
|
|
|
@item
|
|
|
|
Instruction combination (@file{combine.c}). This pass attempts to
|
|
|
|
combine groups of two or three instructions that are related by data
|
|
|
|
flow into single instructions. It combines the RTL expressions for
|
|
|
|
the instructions by substitution, simplifies the result using algebra,
|
|
|
|
and then attempts to match the result against the machine description.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The option @samp{-dc} causes a debugging dump of the RTL code after
|
|
|
|
this pass. This dump file's name is made by appending @samp{.combine}
|
|
|
|
to the input file name.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
@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 them 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.
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex instruction scheduling
|
|
|
|
@cindex scheduling, instruction
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Instruction scheduling (@file{sched.c}). This pass looks for
|
|
|
|
instructions whose output will not be available by the time that it is
|
|
|
|
used in subsequent instructions. (Memory loads and floating point
|
|
|
|
instructions often have this behavior on RISC machines). It re-orders
|
|
|
|
instructions within a basic block to try to separate the definition and
|
|
|
|
use of items that otherwise would cause pipeline stalls.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Instruction scheduling is performed twice. The first time is immediately
|
|
|
|
after instruction combination and the second is immediately after reload.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The option @samp{-dS} causes a debugging dump of the RTL code after this
|
|
|
|
pass is run for the first time. The dump file's name is made by
|
|
|
|
appending @samp{.sched} to the input file name.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex register class preference pass
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Register class preferencing. The RTL code is scanned to find out
|
|
|
|
which register class is best for each pseudo register. The source
|
|
|
|
file is @file{regclass.c}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex register allocation
|
|
|
|
@cindex local register allocation
|
|
|
|
@item
|
|
|
|
Local register allocation (@file{local-alloc.c}). This pass allocates
|
|
|
|
hard registers to pseudo registers that are used only within one basic
|
|
|
|
block. Because the basic block is linear, it can use fast and
|
|
|
|
powerful techniques to do a very good job.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The option @samp{-dl} causes a debugging dump of the RTL code after
|
|
|
|
this pass. This dump file's name is made by appending @samp{.lreg} to
|
|
|
|
the input file name.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex global register allocation
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Global register allocation (@file{global.c}). This pass
|
|
|
|
allocates hard registers for the remaining pseudo registers (those
|
|
|
|
whose life spans are not contained in one basic block).
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex reloading
|
|
|
|
@item
|
|
|
|
Reloading. This pass renumbers pseudo registers with the hardware
|
|
|
|
registers numbers they were allocated. Pseudo registers that did not
|
|
|
|
get hard registers are replaced with stack slots. Then it finds
|
|
|
|
instructions that are invalid because a value has failed to end up in
|
|
|
|
a register, or has ended up in a register of the wrong kind. It fixes
|
|
|
|
up these instructions by reloading the problematical values
|
|
|
|
temporarily into registers. Additional instructions are generated to
|
|
|
|
do the copying.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The reload pass also optionally eliminates the frame pointer and inserts
|
|
|
|
instructions to save and restore call-clobbered registers around calls.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Source files are @file{reload.c} and @file{reload1.c}, plus the header
|
|
|
|
@file{reload.h} used for communication between them.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The option @samp{-dg} causes a debugging dump of the RTL code after
|
|
|
|
this pass. This dump file's name is made by appending @samp{.greg} to
|
|
|
|
the input file name.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex instruction scheduling
|
|
|
|
@cindex scheduling, instruction
|
|
|
|
@item
|
|
|
|
Instruction scheduling is repeated here to try to avoid pipeline stalls
|
|
|
|
due to memory loads generated for spilled pseudo registers.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The option @samp{-dR} causes a debugging dump of the RTL code after
|
|
|
|
this pass. This dump file's name is made by appending @samp{.sched2}
|
|
|
|
to the input file name.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex cross-jumping
|
|
|
|
@cindex no-op move instructions
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Jump optimization is repeated, this time including cross-jumping
|
|
|
|
and deletion of no-op move instructions.
|
|
|
|
|
|
|
|
The option @samp{-dJ} causes a debugging dump of the RTL code after
|
|
|
|
this pass. This dump file's name is made by appending @samp{.jump2}
|
|
|
|
to the input file name.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex delayed branch scheduling
|
|
|
|
@cindex scheduling, delayed branch
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Delayed branch scheduling. This optional pass attempts to find
|
|
|
|
instructions that can go into the delay slots of other instructions,
|
|
|
|
usually jumps and calls. The source file name is @file{reorg.c}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The option @samp{-dd} causes a debugging dump of the RTL code after
|
|
|
|
this pass. This dump file's name is made by appending @samp{.dbr}
|
|
|
|
to the input file name.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex register-to-stack conversion
|
|
|
|
@item
|
|
|
|
Conversion from usage of some hard registers to usage of a register
|
|
|
|
stack may be done at this point. Currently, this is supported only
|
|
|
|
for the floating-point registers of the Intel 80387 coprocessor. The
|
|
|
|
source file name is @file{reg-stack.c}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The options @samp{-dk} causes a debugging dump of the RTL code after
|
|
|
|
this pass. This dump file's name is made by appending @samp{.stack}
|
|
|
|
to the input file name.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex final pass
|
|
|
|
@cindex peephole optimization
|
|
|
|
@item
|
|
|
|
Final. This pass outputs the assembler code for the function. It is
|
|
|
|
also responsible for identifying spurious test and compare
|
|
|
|
instructions. Machine-specific peephole optimizations are performed
|
|
|
|
at the same time. The function entry and exit sequences are generated
|
|
|
|
directly as assembler code in this pass; they never exist as RTL.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The source files are @file{final.c} plus @file{insn-output.c}; the
|
|
|
|
latter is generated automatically from the machine description by the
|
|
|
|
tool @file{genoutput}. The header file @file{conditions.h} is used
|
|
|
|
for communication between these files.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex debugging information generation
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Debugging information output. This is run after final because it must
|
|
|
|
output the stack slot offsets for pseudo registers that did not get
|
|
|
|
hard registers. Source files are @file{dbxout.c} for DBX symbol table
|
|
|
|
format, @file{sdbout.c} for SDB symbol table format, and
|
|
|
|
@file{dwarfout.c} for DWARF symbol table format.
|
|
|
|
@end itemize
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Some additional files are used by all or many passes:
|
|
|
|
|
|
|
|
@itemize @bullet
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Every pass uses @file{machmode.def} and @file{machmode.h} which define
|
|
|
|
the machine modes.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Several passes use @file{real.h}, which defines the default
|
|
|
|
representation of floating point constants and how to operate on them.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
All the passes that work with RTL use the header files @file{rtl.h}
|
|
|
|
and @file{rtl.def}, and subroutines in file @file{rtl.c}. The tools
|
|
|
|
@code{gen*} also use these files to read and work with the machine
|
|
|
|
description RTL.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex genconfig
|
|
|
|
@item
|
|
|
|
Several passes refer to the header file @file{insn-config.h} which
|
|
|
|
contains a few parameters (C macro definitions) generated
|
|
|
|
automatically from the machine description RTL by the tool
|
|
|
|
@code{genconfig}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex instruction recognizer
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Several passes use the instruction recognizer, which consists of
|
|
|
|
@file{recog.c} and @file{recog.h}, plus the files @file{insn-recog.c}
|
|
|
|
and @file{insn-extract.c} that are generated automatically from the
|
|
|
|
machine description by the tools @file{genrecog} and
|
|
|
|
@file{genextract}.@refill
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Several passes use the header files @file{regs.h} which defines the
|
|
|
|
information recorded about pseudo register usage, and @file{basic-block.h}
|
|
|
|
which defines the information recorded about basic blocks.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
@file{hard-reg-set.h} defines the type @code{HARD_REG_SET}, a bit-vector
|
|
|
|
with a bit for each hard register, and some macros to manipulate it.
|
|
|
|
This type is just @code{int} if the machine has few enough hard registers;
|
|
|
|
otherwise it is an array of @code{int} and some of the macros expand
|
|
|
|
into loops.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Several passes use instruction attributes. A definition of the
|
|
|
|
attributes defined for a particular machine is in file
|
|
|
|
@file{insn-attr.h}, which is generated from the machine description by
|
|
|
|
the program @file{genattr}. The file @file{insn-attrtab.c} contains
|
|
|
|
subroutines to obtain the attribute values for insns. It is generated
|
|
|
|
from the machine description by the program @file{genattrtab}.@refill
|
|
|
|
@end itemize
|
|
|
|
@end ifset
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@ifset INTERNALS
|
|
|
|
@include rtl.texi
|
|
|
|
@include md.texi
|
|
|
|
@include tm.texi
|
|
|
|
@end ifset
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@ifset INTERNALS
|
|
|
|
@node Config
|
|
|
|
@chapter The Configuration File
|
|
|
|
@cindex configuration file
|
|
|
|
@cindex @file{xm-@var{machine}.h}
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The configuration file @file{xm-@var{machine}.h} contains macro
|
|
|
|
definitions that describe the machine and system on which the compiler
|
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
machines that GCC runs on, so large parts of all configuration files
|
1999-08-26 09:30:50 +00:00
|
|
|
are identical. But there are some macros that vary:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@table @code
|
|
|
|
@findex USG
|
|
|
|
@item USG
|
|
|
|
Define this macro if the host system is System V.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex VMS
|
|
|
|
@item VMS
|
|
|
|
Define this macro if the host system is VMS.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex HOST_WORDS_BIG_ENDIAN
|
|
|
|
@item HOST_WORDS_BIG_ENDIAN
|
|
|
|
Defined if the host machine stores words of multi-word values in
|
1999-10-16 06:09:09 +00:00
|
|
|
big-endian order. (GCC does not depend on the host byte ordering
|
1999-08-26 09:30:50 +00:00
|
|
|
within a word.)
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex HOST_FLOAT_WORDS_BIG_ENDIAN
|
|
|
|
@item HOST_FLOAT_WORDS_BIG_ENDIAN
|
|
|
|
Define this macro to be 1 if the host machine stores @code{DFmode},
|
|
|
|
@code{XFmode} or @code{TFmode} floating point numbers in memory with the
|
|
|
|
word containing the sign bit at the lowest address; otherwise, define it
|
|
|
|
to be zero.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
This macro need not be defined if the ordering is the same as for
|
|
|
|
multi-word integers.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex HOST_FLOAT_FORMAT
|
|
|
|
@item HOST_FLOAT_FORMAT
|
|
|
|
A numeric code distinguishing the floating point format for the host
|
|
|
|
machine. See @code{TARGET_FLOAT_FORMAT} in @ref{Storage Layout} for the
|
|
|
|
alternatives and default.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex HOST_BITS_PER_CHAR
|
|
|
|
@item HOST_BITS_PER_CHAR
|
|
|
|
A C expression for the number of bits in @code{char} on the host
|
|
|
|
machine.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex HOST_BITS_PER_SHORT
|
|
|
|
@item HOST_BITS_PER_SHORT
|
|
|
|
A C expression for the number of bits in @code{short} on the host
|
|
|
|
machine.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex HOST_BITS_PER_INT
|
|
|
|
@item HOST_BITS_PER_INT
|
|
|
|
A C expression for the number of bits in @code{int} on the host
|
|
|
|
machine.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex HOST_BITS_PER_LONG
|
|
|
|
@item HOST_BITS_PER_LONG
|
|
|
|
A C expression for the number of bits in @code{long} on the host
|
|
|
|
machine.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex ONLY_INT_FIELDS
|
|
|
|
@item ONLY_INT_FIELDS
|
|
|
|
Define this macro to indicate that the host compiler only supports
|
|
|
|
@code{int} bit fields, rather than other integral types, including
|
|
|
|
@code{enum}, as do most C compilers.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex OBSTACK_CHUNK_SIZE
|
|
|
|
@item OBSTACK_CHUNK_SIZE
|
|
|
|
A C expression for the size of ordinary obstack chunks.
|
|
|
|
If you don't define this, a usually-reasonable default is used.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex OBSTACK_CHUNK_ALLOC
|
|
|
|
@item OBSTACK_CHUNK_ALLOC
|
|
|
|
The function used to allocate obstack chunks.
|
|
|
|
If you don't define this, @code{xmalloc} is used.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex OBSTACK_CHUNK_FREE
|
|
|
|
@item OBSTACK_CHUNK_FREE
|
|
|
|
The function used to free obstack chunks.
|
|
|
|
If you don't define this, @code{free} is used.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex USE_C_ALLOCA
|
|
|
|
@item USE_C_ALLOCA
|
|
|
|
Define this macro to indicate that the compiler is running with the
|
|
|
|
@code{alloca} implemented in C. This version of @code{alloca} can be
|
|
|
|
found in the file @file{alloca.c}; to use it, you must also alter the
|
|
|
|
@file{Makefile} variable @code{ALLOCA}. (This is done automatically
|
|
|
|
for the systems on which we know it is needed.)
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If you do define this macro, you should probably do it as follows:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@example
|
1999-08-26 09:30:50 +00:00
|
|
|
#ifndef __GNUC__
|
|
|
|
#define USE_C_ALLOCA
|
1996-09-18 05:35:50 +00:00
|
|
|
#else
|
1999-08-26 09:30:50 +00:00
|
|
|
#define alloca __builtin_alloca
|
1996-09-18 05:35:50 +00:00
|
|
|
#endif
|
|
|
|
@end example
|
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@noindent
|
1999-10-16 06:09:09 +00:00
|
|
|
so that when the compiler is compiled with GCC it uses the more
|
1999-08-26 09:30:50 +00:00
|
|
|
efficient built-in @code{alloca} function.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item FUNCTION_CONVERSION_BUG
|
|
|
|
@findex FUNCTION_CONVERSION_BUG
|
|
|
|
Define this macro to indicate that the host compiler does not properly
|
|
|
|
handle converting a function value to a pointer-to-function when it is
|
|
|
|
used in an expression.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex MULTIBYTE_CHARS
|
|
|
|
@item MULTIBYTE_CHARS
|
|
|
|
Define this macro to enable support for multibyte characters in the
|
1999-10-16 06:09:09 +00:00
|
|
|
input to GCC. This requires that the host system support the ANSI C
|
1999-08-26 09:30:50 +00:00
|
|
|
library functions for converting multibyte characters to wide
|
|
|
|
characters.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex POSIX
|
|
|
|
@item POSIX
|
|
|
|
Define this if your system is POSIX.1 compliant.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex NO_SYS_SIGLIST
|
|
|
|
@item NO_SYS_SIGLIST
|
|
|
|
Define this if your system @emph{does not} provide the variable
|
|
|
|
@code{sys_siglist}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC. If @samp{USE_PROTOTYPES} is not defined, it will be
|
1999-08-26 09:30:50 +00:00
|
|
|
determined automatically whether your compiler supports
|
|
|
|
prototypes by checking if @samp{__STDC__} is defined.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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
|
1999-10-16 06:09:09 +00:00
|
|
|
GCC. If @samp{USE_PROTOTYPES} is defined to be 0, or the
|
1999-08-26 09:30:50 +00:00
|
|
|
host compiler does not support prototypes, this macro has no
|
|
|
|
effect.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex PATH_SEPARATOR
|
|
|
|
@item PATH_SEPARATOR
|
|
|
|
Define this macro to be a C character constant representing the
|
|
|
|
character used to separate components in paths. The default value is
|
|
|
|
the colon character
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex DIR_SEPARATOR
|
|
|
|
@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
|
1999-10-16 06:09:09 +00:00
|
|
|
character constant specifying that character. When GCC displays file
|
|
|
|
names, the character you specify will be used. GCC will test for
|
1999-08-26 09:30:50 +00:00
|
|
|
both slash and the character you specify when parsing filenames.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex OBJECT_SUFFIX
|
|
|
|
@item OBJECT_SUFFIX
|
|
|
|
Define this macro to be a C string representing the suffix for object
|
1999-10-16 06:09:09 +00:00
|
|
|
files on your machine. If you do not define this macro, GCC will use
|
1999-08-26 09:30:50 +00:00
|
|
|
@samp{.o} as the suffix for object files.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex EXECUTABLE_SUFFIX
|
|
|
|
@item EXECUTABLE_SUFFIX
|
|
|
|
Define this macro to be a C string representing the suffix for executable
|
1999-10-16 06:09:09 +00:00
|
|
|
files on your machine. If you do not define this macro, GCC will use
|
1999-08-26 09:30:50 +00:00
|
|
|
the null string as the suffix for object files.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex COLLECT_EXPORT_LIST
|
|
|
|
@item COLLECT_EXPORT_LIST
|
|
|
|
If defined, @code{collect2} will scan the individual object files
|
|
|
|
specified on its command line and create an export list for the linker.
|
|
|
|
Define this macro for systems like AIX, where the linker discards
|
|
|
|
object files that are not referenced from @code{main} and uses export
|
|
|
|
lists.
|
|
|
|
@end table
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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}
|
1999-10-16 06:09:09 +00:00
|
|
|
as a macro when compiled with GCC, in order to take advantage of the
|
|
|
|
benefit of GCC's built-in @code{alloca}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Fragments
|
|
|
|
@chapter Makefile Fragments
|
|
|
|
@cindex makefile fragment
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-10-16 06:09:09 +00:00
|
|
|
When you configure GCC using the @file{configure} script
|
1999-08-26 09:30:50 +00:00
|
|
|
(@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,
|
|
|
|
named @file{t-@var{target}} and @file{x-@var{host}}. If these files do
|
|
|
|
not exist, it means nothing needs to be added for a given target or
|
|
|
|
host.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@menu
|
|
|
|
* Target Fragment:: Writing the @file{t-@var{target}} file.
|
|
|
|
* Host Fragment:: Writing the @file{x-@var{host}} file.
|
|
|
|
@end menu
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Target Fragment
|
|
|
|
@section The Target Makefile Fragment
|
|
|
|
@cindex target makefile fragment
|
|
|
|
@cindex @file{t-@var{target}}
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The target makefile fragment, @file{t-@var{target}}, defines special
|
|
|
|
target dependent variables and targets used in the @file{Makefile}:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@table @code
|
|
|
|
@findex LIBGCC1
|
|
|
|
@item LIBGCC1
|
|
|
|
The rule to use to build @file{libgcc1.a}.
|
|
|
|
If your target does not need to use the functions in @file{libgcc1.a},
|
|
|
|
set this to empty.
|
|
|
|
@xref{Interface}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex CROSS_LIBGCC1
|
|
|
|
@item CROSS_LIBGCC1
|
|
|
|
The rule to use to build @file{libgcc1.a} when building a cross
|
|
|
|
compiler. If your target does not need to use the functions in
|
|
|
|
@file{libgcc1.a}, set this to empty. @xref{Cross Runtime}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex LIBGCC2_CFLAGS
|
|
|
|
@item LIBGCC2_CFLAGS
|
|
|
|
Compiler flags to use when compiling @file{libgcc2.c}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex LIB2FUNCS_EXTRA
|
|
|
|
@item LIB2FUNCS_EXTRA
|
|
|
|
A list of source file names to be compiled or assembled and inserted
|
|
|
|
into @file{libgcc.a}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex CRTSTUFF_T_CFLAGS
|
|
|
|
@item CRTSTUFF_T_CFLAGS
|
|
|
|
Special flags used when compiling @file{crtstuff.c}.
|
|
|
|
@xref{Initialization}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex CRTSTUFF_T_CFLAGS_S
|
|
|
|
@item CRTSTUFF_T_CFLAGS_S
|
|
|
|
Special flags used when compiling @file{crtstuff.c} for shared
|
|
|
|
linking. Used if you use @file{crtbeginS.o} and @file{crtendS.o}
|
|
|
|
in @code{EXTRA-PARTS}.
|
|
|
|
@xref{Initialization}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex MULTILIB_OPTIONS
|
|
|
|
@item MULTILIB_OPTIONS
|
1999-10-16 06:09:09 +00:00
|
|
|
For some targets, invoking GCC in different ways produces objects
|
|
|
|
that can not be linked together. For example, for some targets GCC
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
each set of incompatible options. When GCC invokes the linker, it
|
1999-08-26 09:30:50 +00:00
|
|
|
arranges to link in the right version of @file{libgcc.a}, based on
|
|
|
|
the command line options used.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The @code{MULTILIB_OPTIONS} macro lists the set of options for which
|
|
|
|
special versions of @file{libgcc.a} must be built. Write options that
|
|
|
|
are mutually incompatible side by side, separated by a slash. Write
|
|
|
|
options that may be used together separated by a space. The build
|
|
|
|
procedure will build all combinations of compatible options.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
For example, if you set @code{MULTILIB_OPTIONS} to @samp{m68000/m68020
|
|
|
|
msoft-float}, @file{Makefile} will build special versions of
|
|
|
|
@file{libgcc.a} using the following sets of options: @samp{-m68000},
|
|
|
|
@samp{-m68020}, @samp{-msoft-float}, @samp{-m68000 -msoft-float}, and
|
|
|
|
@samp{-m68020 -msoft-float}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex MULTILIB_DIRNAMES
|
|
|
|
@item MULTILIB_DIRNAMES
|
|
|
|
If @code{MULTILIB_OPTIONS} is used, this variable specifies the
|
|
|
|
directory names that should be used to hold the various libraries.
|
|
|
|
Write one element in @code{MULTILIB_DIRNAMES} for each element in
|
|
|
|
@code{MULTILIB_OPTIONS}. If @code{MULTILIB_DIRNAMES} is not used, the
|
|
|
|
default value will be @code{MULTILIB_OPTIONS}, with all slashes treated
|
|
|
|
as spaces.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
For example, if @code{MULTILIB_OPTIONS} is set to @samp{m68000/m68020
|
|
|
|
msoft-float}, then the default value of @code{MULTILIB_DIRNAMES} is
|
|
|
|
@samp{m68000 m68020 msoft-float}. You may specify a different value if
|
|
|
|
you desire a different set of directory names.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex MULTILIB_MATCHES
|
|
|
|
@item MULTILIB_MATCHES
|
|
|
|
Sometimes the same option may be written in two different ways. If an
|
1999-10-16 06:09:09 +00:00
|
|
|
option is listed in @code{MULTILIB_OPTIONS}, GCC needs to know about
|
1999-08-26 09:30:50 +00:00
|
|
|
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}.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex MULTILIB_EXCEPTIONS
|
|
|
|
@item MULTILIB_EXCEPTIONS
|
|
|
|
Sometimes when there are multiple sets of @code{MULTILIB_OPTIONS} being
|
|
|
|
specified, there are combinations that should not be built. In that
|
|
|
|
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*}.
|
|
|
|
|
|
|
|
@findex MULTILIB_EXTRA_OPTS
|
|
|
|
@item MULTILIB_EXTRA_OPTS
|
|
|
|
Sometimes it is desirable that when building multiple versions of
|
|
|
|
@file{libgcc.a} certain options should always be passed on to the
|
|
|
|
compiler. In that case, set @code{MULTILIB_EXTRA_OPTS} to be the list
|
|
|
|
of options to be used for all builds.
|
|
|
|
@end table
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Host Fragment
|
|
|
|
@section The Host Makefile Fragment
|
|
|
|
@cindex host makefile fragment
|
|
|
|
@cindex @file{x-@var{host}}
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The host makefile fragment, @file{x-@var{host}}, defines special host
|
|
|
|
dependent variables and targets used in the @file{Makefile}:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@table @code
|
|
|
|
@findex CC
|
|
|
|
@item CC
|
|
|
|
The compiler to use when building the first stage.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex CLIB
|
|
|
|
@item CLIB
|
|
|
|
Additional host libraries to link with.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex OLDCC
|
|
|
|
@item OLDCC
|
|
|
|
The compiler to use when building @file{libgcc1.a} for a native
|
|
|
|
compilation.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex OLDAR
|
|
|
|
@item OLDAR
|
|
|
|
The version of @code{ar} to use when building @file{libgcc1.a} for a native
|
|
|
|
compilation.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@findex INSTALL
|
|
|
|
@item INSTALL
|
|
|
|
The install program to use.
|
|
|
|
@end table
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Funding
|
|
|
|
@unnumbered Funding Free Software
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If you want to have more free software a few years from now, it makes
|
|
|
|
sense for you to help encourage people to contribute funds for its
|
|
|
|
development. The most effective approach known is to encourage
|
|
|
|
commercial redistributors to donate.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Users of free software systems can boost the pace of development by
|
|
|
|
encouraging for-a-fee distributors to donate part of their selling price
|
|
|
|
to free software developers---the Free Software Foundation, and others.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The way to convince distributors to do this is to demand it and expect
|
|
|
|
it from them. So when you compare distributors, judge them partly by
|
|
|
|
how much they give to free software development. Show distributors
|
|
|
|
they must compete to be the one who gives the most.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
To make this approach work, you must insist on numbers that you can
|
|
|
|
compare, such as, ``We will donate ten dollars to the Frobnitz project
|
|
|
|
for each disk sold.'' Don't be satisfied with a vague promise, such as
|
|
|
|
``A portion of the profits are donated,'' since it doesn't give a basis
|
|
|
|
for comparison.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Even a precise fraction ``of the profits from this disk'' is not very
|
|
|
|
meaningful, since creative accounting and unrelated business decisions
|
|
|
|
can greatly alter what fraction of the sales price counts as profit.
|
|
|
|
If the price you pay is $50, ten percent of the profit is probably
|
|
|
|
less than a dollar; it might be a few cents, or nothing at all.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Some redistributors do development work themselves. This is useful too;
|
|
|
|
but to keep everyone honest, you need to inquire how much they do, and
|
|
|
|
what kind. Some kinds of development make much more long-term
|
|
|
|
difference than others. For example, maintaining a separate version of
|
|
|
|
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
|
1999-10-16 06:09:09 +00:00
|
|
|
ports such as adding a new CPU to the GNU Compiler Collection contribute more;
|
1999-08-26 09:30:50 +00:00
|
|
|
major new features or packages contribute the most.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
By establishing the idea that supporting further development is ``the
|
|
|
|
proper thing to do'' when distributing free software for a fee, we can
|
|
|
|
assure a steady flow of resources into making more free software.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@display
|
|
|
|
Copyright (C) 1994 Free Software Foundation, Inc.
|
|
|
|
Verbatim copying and redistribution of this section is permitted
|
|
|
|
without royalty; alteration is not permitted.
|
|
|
|
@end display
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node GNU/Linux
|
|
|
|
@unnumbered Linux and the GNU Project
|
|
|
|
|
|
|
|
Many computer users run a modified version of the GNU system every
|
|
|
|
day, without realizing it. Through a peculiar turn of events, the
|
|
|
|
version of GNU which is widely used today is more often known as
|
|
|
|
``Linux'', and many users are not aware of the extent of its
|
|
|
|
connection with the GNU Project.
|
|
|
|
|
|
|
|
There really is a Linux; it is a kernel, and these people are using
|
|
|
|
it. But you can't use a kernel by itself; a kernel is useful only as
|
|
|
|
part of a whole system. The system in which Linux is typically used
|
|
|
|
is a modified variant of the GNU system---in other words, a Linux-based
|
|
|
|
GNU system.
|
|
|
|
|
|
|
|
Many users are not fully aware of the distinction between the kernel,
|
|
|
|
which is Linux, and the whole system, which they also call ``Linux''.
|
|
|
|
The ambiguous use of the name doesn't promote understanding.
|
|
|
|
|
|
|
|
Programmers generally know that Linux is a kernel. But since they
|
|
|
|
have generally heard the whole system called ``Linux'' as well, they
|
|
|
|
often envisage a history which fits that name. For example, many
|
|
|
|
believe that once Linus Torvalds finished writing the kernel, his
|
|
|
|
friends looked around for other free software, and for no particular
|
|
|
|
reason most everything necessary to make a Unix-like system was
|
|
|
|
already available.
|
|
|
|
|
|
|
|
What they found was no accident---it was the GNU system. The available
|
|
|
|
free software added up to a complete system because the GNU Project
|
|
|
|
had been working since 1984 to make one. The GNU Manifesto
|
|
|
|
had set forth the goal of developing a free Unix-like system, called
|
|
|
|
GNU. By the time Linux was written, the system was almost finished.
|
|
|
|
|
|
|
|
Most free software projects have the goal of developing a particular
|
|
|
|
program for a particular job. For example, Linus Torvalds set out to
|
|
|
|
write a Unix-like kernel (Linux); Donald Knuth set out to write a text
|
|
|
|
formatter (TeX); Bob Scheifler set out to develop a window system (X
|
|
|
|
Windows). It's natural to measure the contribution of this kind of
|
|
|
|
project by specific programs that came from the project.
|
|
|
|
|
|
|
|
If we tried to measure the GNU Project's contribution in this way,
|
|
|
|
what would we conclude? One CD-ROM vendor found that in their ``Linux
|
|
|
|
distribution'', GNU software was the largest single contingent, around
|
|
|
|
28% of the total source code, and this included some of the essential
|
|
|
|
major components without which there could be no system. Linux itself
|
|
|
|
was about 3%. So if you were going to pick a name for the system
|
|
|
|
based on who wrote the programs in the system, the most appropriate
|
|
|
|
single choice would be ``GNU''.
|
|
|
|
|
|
|
|
But we don't think that is the right way to consider the question.
|
|
|
|
The GNU Project was not, is not, a project to develop specific
|
|
|
|
software packages. It was not a project to develop a C compiler,
|
|
|
|
although we did. It was not a project to develop a text editor,
|
|
|
|
although we developed one. The GNU Project's aim was to develop
|
|
|
|
@emph{a complete free Unix-like system}.
|
|
|
|
|
|
|
|
Many people have made major contributions to the free software in the
|
|
|
|
system, and they all deserve credit. But the reason it is @emph{a
|
|
|
|
system}---and not just a collection of useful programs---is because the
|
|
|
|
GNU Project set out to make it one. We wrote the programs that were
|
|
|
|
needed to make a @emph{complete} free system. We wrote essential but
|
|
|
|
unexciting major components, such as the assembler and linker, because
|
|
|
|
you can't have a system without them. A complete system needs more
|
|
|
|
than just programming tools, so we wrote other components as well,
|
|
|
|
such as the Bourne Again SHell, the PostScript interpreter
|
|
|
|
Ghostscript, and the GNU C library.
|
|
|
|
|
|
|
|
By the early 90s we had put together the whole system aside from the
|
|
|
|
kernel (and we were also working on a kernel, the GNU Hurd, which runs
|
|
|
|
on top of Mach). Developing this kernel has been a lot harder than we
|
|
|
|
expected, and we are still working on finishing it.
|
|
|
|
|
|
|
|
Fortunately, you don't have to wait for it, because Linux is working
|
|
|
|
now. When Linus Torvalds wrote Linux, he filled the last major gap.
|
|
|
|
People could then put Linux together with the GNU system to make a
|
|
|
|
complete free system: a Linux-based GNU system (or GNU/Linux system,
|
|
|
|
for short).
|
|
|
|
|
|
|
|
Putting them together sounds simple, but it was not a trivial job.
|
|
|
|
The GNU C library (called glibc for short) needed substantial changes.
|
|
|
|
Integrating a complete system as a distribution that would work ``out
|
|
|
|
of the box'' was a big job, too. It required addressing the issue of
|
|
|
|
how to install and boot the system---a problem we had not tackled,
|
|
|
|
because we hadn't yet reached that point. The people who developed
|
|
|
|
the various system distributions made a substantial contribution.
|
|
|
|
|
|
|
|
The GNU Project supports GNU/Linux systems as well as @emph{the}
|
|
|
|
GNU system---even with funds. We funded the rewriting of the
|
|
|
|
Linux-related extensions to the GNU C library, so that now they are
|
|
|
|
well integrated, and the newest GNU/Linux systems use the current
|
|
|
|
library release with no changes. We also funded an early stage of the
|
|
|
|
development of Debian GNU/Linux.
|
|
|
|
|
|
|
|
We use Linux-based GNU systems today for most of our work, and we hope
|
|
|
|
you use them too. But please don't confuse the public by using the
|
|
|
|
name ``Linux'' ambiguously. Linux is the kernel, one of the essential
|
|
|
|
major components of the system. The system as a whole is more or less
|
|
|
|
the GNU system.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Copying
|
|
|
|
@unnumbered GNU GENERAL PUBLIC LICENSE
|
|
|
|
@center Version 2, June 1991
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@display
|
|
|
|
Copyright @copyright{} 1989, 1991 Free Software Foundation, Inc.
|
|
|
|
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Everyone is permitted to copy and distribute verbatim copies
|
|
|
|
of this license document, but changing it is not allowed.
|
|
|
|
@end display
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@unnumberedsec Preamble
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The licenses for most software are designed to take away your
|
|
|
|
freedom to share and change it. By contrast, the GNU General Public
|
|
|
|
License is intended to guarantee your freedom to share and change free
|
|
|
|
software---to make sure the software is free for all its users. This
|
|
|
|
General Public License applies to most of the Free Software
|
|
|
|
Foundation's software and to any other program whose authors commit to
|
|
|
|
using it. (Some other Free Software Foundation software is covered by
|
|
|
|
the GNU Library General Public License instead.) You can apply it to
|
|
|
|
your programs, too.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
When we speak of free software, we are referring to freedom, not
|
|
|
|
price. Our General Public Licenses are designed to make sure that you
|
|
|
|
have the freedom to distribute copies of free software (and charge for
|
|
|
|
this service if you wish), that you receive source code or can get it
|
|
|
|
if you want it, that you can change the software or use pieces of it
|
|
|
|
in new free programs; and that you know you can do these things.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
To protect your rights, we need to make restrictions that forbid
|
|
|
|
anyone to deny you these rights or to ask you to surrender the rights.
|
|
|
|
These restrictions translate to certain responsibilities for you if you
|
|
|
|
distribute copies of the software, or if you modify it.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
For example, if you distribute copies of such a program, whether
|
|
|
|
gratis or for a fee, you must give the recipients all the rights that
|
|
|
|
you have. You must make sure that they, too, receive or can get the
|
|
|
|
source code. And you must show them these terms so they know their
|
|
|
|
rights.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
We protect your rights with two steps: (1) copyright the software, and
|
|
|
|
(2) offer you this license which gives you legal permission to copy,
|
|
|
|
distribute and/or modify the software.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Also, for each author's protection and ours, we want to make certain
|
|
|
|
that everyone understands that there is no warranty for this free
|
|
|
|
software. If the software is modified by someone else and passed on, we
|
|
|
|
want its recipients to know that what they have is not the original, so
|
|
|
|
that any problems introduced by others will not reflect on the original
|
|
|
|
authors' reputations.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Finally, any free program is threatened constantly by software
|
|
|
|
patents. We wish to avoid the danger that redistributors of a free
|
|
|
|
program will individually obtain patent licenses, in effect making the
|
|
|
|
program proprietary. To prevent this, we have made it clear that any
|
|
|
|
patent must be licensed for everyone's free use or not licensed at all.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The precise terms and conditions for copying, distribution and
|
|
|
|
modification follow.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@iftex
|
|
|
|
@unnumberedsec TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
|
|
|
|
@end iftex
|
|
|
|
@ifinfo
|
|
|
|
@center TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
|
|
|
|
@end ifinfo
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@enumerate 0
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
This License applies to any program or other work which contains
|
|
|
|
a notice placed by the copyright holder saying it may be distributed
|
|
|
|
under the terms of this General Public License. The ``Program'', below,
|
|
|
|
refers to any such program or work, and a ``work based on the Program''
|
|
|
|
means either the Program or any derivative work under copyright law:
|
|
|
|
that is to say, a work containing the Program or a portion of it,
|
|
|
|
either verbatim or with modifications and/or translated into another
|
|
|
|
language. (Hereinafter, translation is included without limitation in
|
|
|
|
the term ``modification''.) Each licensee is addressed as ``you''.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Activities other than copying, distribution and modification are not
|
|
|
|
covered by this License; they are outside its scope. The act of
|
|
|
|
running the Program is not restricted, and the output from the Program
|
|
|
|
is covered only if its contents constitute a work based on the
|
|
|
|
Program (independent of having been made by running the Program).
|
|
|
|
Whether that is true depends on what the Program does.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
You may copy and distribute verbatim copies of the Program's
|
|
|
|
source code as you receive it, in any medium, provided that you
|
|
|
|
conspicuously and appropriately publish on each copy an appropriate
|
|
|
|
copyright notice and disclaimer of warranty; keep intact all the
|
|
|
|
notices that refer to this License and to the absence of any warranty;
|
|
|
|
and give any other recipients of the Program a copy of this License
|
|
|
|
along with the Program.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
You may charge a fee for the physical act of transferring a copy, and
|
|
|
|
you may at your option offer warranty protection in exchange for a fee.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
You may modify your copy or copies of the Program or any portion
|
|
|
|
of it, thus forming a work based on the Program, and copy and
|
|
|
|
distribute such modifications or work under the terms of Section 1
|
|
|
|
above, provided that you also meet all of these conditions:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@enumerate a
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
You must cause the modified files to carry prominent notices
|
|
|
|
stating that you changed the files and the date of any change.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
You must cause any work that you distribute or publish, that in
|
|
|
|
whole or in part contains or is derived from the Program or any
|
|
|
|
part thereof, to be licensed as a whole at no charge to all third
|
|
|
|
parties under the terms of this License.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
If the modified program normally reads commands interactively
|
|
|
|
when run, you must cause it, when started running for such
|
|
|
|
interactive use in the most ordinary way, to print or display an
|
|
|
|
announcement including an appropriate copyright notice and a
|
|
|
|
notice that there is no warranty (or else, saying that you provide
|
|
|
|
a warranty) and that users may redistribute the program under
|
|
|
|
these conditions, and telling the user how to view a copy of this
|
|
|
|
License. (Exception: if the Program itself is interactive but
|
|
|
|
does not normally print such an announcement, your work based on
|
|
|
|
the Program is not required to print an announcement.)
|
|
|
|
@end enumerate
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
These requirements apply to the modified work as a whole. If
|
|
|
|
identifiable sections of that work are not derived from the Program,
|
|
|
|
and can be reasonably considered independent and separate works in
|
|
|
|
themselves, then this License, and its terms, do not apply to those
|
|
|
|
sections when you distribute them as separate works. But when you
|
|
|
|
distribute the same sections as part of a whole which is a work based
|
|
|
|
on the Program, the distribution of the whole must be on the terms of
|
|
|
|
this License, whose permissions for other licensees extend to the
|
|
|
|
entire whole, and thus to each and every part regardless of who wrote it.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Thus, it is not the intent of this section to claim rights or contest
|
|
|
|
your rights to work written entirely by you; rather, the intent is to
|
|
|
|
exercise the right to control the distribution of derivative or
|
|
|
|
collective works based on the Program.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
In addition, mere aggregation of another work not based on the Program
|
|
|
|
with the Program (or with a work based on the Program) on a volume of
|
|
|
|
a storage or distribution medium does not bring the other work under
|
|
|
|
the scope of this License.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
You may copy and distribute the Program (or a work based on it,
|
|
|
|
under Section 2) in object code or executable form under the terms of
|
|
|
|
Sections 1 and 2 above provided that you also do one of the following:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@enumerate a
|
1996-09-18 05:35:50 +00:00
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Accompany it with the complete corresponding machine-readable
|
|
|
|
source code, which must be distributed under the terms of Sections
|
|
|
|
1 and 2 above on a medium customarily used for software interchange; or,
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Accompany it with a written offer, valid for at least three
|
|
|
|
years, to give any third party, for a charge no more than your
|
|
|
|
cost of physically performing source distribution, a complete
|
|
|
|
machine-readable copy of the corresponding source code, to be
|
|
|
|
distributed under the terms of Sections 1 and 2 above on a medium
|
|
|
|
customarily used for software interchange; or,
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Accompany it with the information you received as to the offer
|
|
|
|
to distribute corresponding source code. (This alternative is
|
|
|
|
allowed only for noncommercial distribution and only if you
|
|
|
|
received the program in object code or executable form with such
|
|
|
|
an offer, in accord with Subsection b above.)
|
|
|
|
@end enumerate
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The source code for a work means the preferred form of the work for
|
|
|
|
making modifications to it. For an executable work, complete source
|
|
|
|
code means all the source code for all modules it contains, plus any
|
|
|
|
associated interface definition files, plus the scripts used to
|
|
|
|
control compilation and installation of the executable. However, as a
|
|
|
|
special exception, the source code distributed need not include
|
|
|
|
anything that is normally distributed (in either source or binary
|
|
|
|
form) with the major components (compiler, kernel, and so on) of the
|
|
|
|
operating system on which the executable runs, unless that component
|
|
|
|
itself accompanies the executable.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If distribution of executable or object code is made by offering
|
|
|
|
access to copy from a designated place, then offering equivalent
|
|
|
|
access to copy the source code from the same place counts as
|
|
|
|
distribution of the source code, even though third parties are not
|
|
|
|
compelled to copy the source along with the object code.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
You may not copy, modify, sublicense, or distribute the Program
|
|
|
|
except as expressly provided under this License. Any attempt
|
|
|
|
otherwise to copy, modify, sublicense or distribute the Program is
|
|
|
|
void, and will automatically terminate your rights under this License.
|
|
|
|
However, parties who have received copies, or rights, from you under
|
|
|
|
this License will not have their licenses terminated so long as such
|
|
|
|
parties remain in full compliance.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
You are not required to accept this License, since you have not
|
|
|
|
signed it. However, nothing else grants you permission to modify or
|
|
|
|
distribute the Program or its derivative works. These actions are
|
|
|
|
prohibited by law if you do not accept this License. Therefore, by
|
|
|
|
modifying or distributing the Program (or any work based on the
|
|
|
|
Program), you indicate your acceptance of this License to do so, and
|
|
|
|
all its terms and conditions for copying, distributing or modifying
|
|
|
|
the Program or works based on it.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
Each time you redistribute the Program (or any work based on the
|
|
|
|
Program), the recipient automatically receives a license from the
|
|
|
|
original licensor to copy, distribute or modify the Program subject to
|
|
|
|
these terms and conditions. You may not impose any further
|
|
|
|
restrictions on the recipients' exercise of the rights granted herein.
|
|
|
|
You are not responsible for enforcing compliance by third parties to
|
|
|
|
this License.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
If, as a consequence of a court judgment or allegation of patent
|
|
|
|
infringement or for any other reason (not limited to patent issues),
|
|
|
|
conditions are imposed on you (whether by court order, agreement or
|
|
|
|
otherwise) that contradict the conditions of this License, they do not
|
|
|
|
excuse you from the conditions of this License. If you cannot
|
|
|
|
distribute so as to satisfy simultaneously your obligations under this
|
|
|
|
License and any other pertinent obligations, then as a consequence you
|
|
|
|
may not distribute the Program at all. For example, if a patent
|
|
|
|
license would not permit royalty-free redistribution of the Program by
|
|
|
|
all those who receive copies directly or indirectly through you, then
|
|
|
|
the only way you could satisfy both it and this License would be to
|
|
|
|
refrain entirely from distribution of the Program.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If any portion of this section is held invalid or unenforceable under
|
|
|
|
any particular circumstance, the balance of the section is intended to
|
|
|
|
apply and the section as a whole is intended to apply in other
|
|
|
|
circumstances.
|
|
|
|
|
|
|
|
It is not the purpose of this section to induce you to infringe any
|
|
|
|
patents or other property right claims or to contest validity of any
|
|
|
|
such claims; this section has the sole purpose of protecting the
|
|
|
|
integrity of the free software distribution system, which is
|
|
|
|
implemented by public license practices. Many people have made
|
|
|
|
generous contributions to the wide range of software distributed
|
|
|
|
through that system in reliance on consistent application of that
|
|
|
|
system; it is up to the author/donor to decide if he or she is willing
|
|
|
|
to distribute software through any other system and a licensee cannot
|
|
|
|
impose that choice.
|
|
|
|
|
|
|
|
This section is intended to make thoroughly clear what is believed to
|
|
|
|
be a consequence of the rest of this License.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
If the distribution and/or use of the Program is restricted in
|
|
|
|
certain countries either by patents or by copyrighted interfaces, the
|
|
|
|
original copyright holder who places the Program under this License
|
|
|
|
may add an explicit geographical distribution limitation excluding
|
|
|
|
those countries, so that distribution is permitted only in or among
|
|
|
|
countries not thus excluded. In such case, this License incorporates
|
|
|
|
the limitation as if written in the body of this License.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@item
|
1999-08-26 09:30:50 +00:00
|
|
|
The Free Software Foundation may publish revised and/or new versions
|
|
|
|
of the General Public License from time to time. Such new versions will
|
|
|
|
be similar in spirit to the present version, but may differ in detail to
|
|
|
|
address new problems or concerns.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Each version is given a distinguishing version number. If the Program
|
|
|
|
specifies a version number of this License which applies to it and ``any
|
|
|
|
later version'', you have the option of following the terms and conditions
|
|
|
|
either of that version or of any later version published by the Free
|
|
|
|
Software Foundation. If the Program does not specify a version number of
|
|
|
|
this License, you may choose any version ever published by the Free Software
|
|
|
|
Foundation.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
If you wish to incorporate parts of the Program into other free
|
|
|
|
programs whose distribution conditions are different, write to the author
|
|
|
|
to ask for permission. For software which is copyrighted by the Free
|
|
|
|
Software Foundation, write to the Free Software Foundation; we sometimes
|
|
|
|
make exceptions for this. Our decision will be guided by the two goals
|
|
|
|
of preserving the free status of all derivatives of our free software and
|
|
|
|
of promoting the sharing and reuse of software generally.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@iftex
|
|
|
|
@heading NO WARRANTY
|
|
|
|
@end iftex
|
|
|
|
@ifinfo
|
|
|
|
@center NO WARRANTY
|
|
|
|
@end ifinfo
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
|
|
|
|
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
|
|
|
|
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
|
|
|
|
PROVIDE THE PROGRAM ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
|
|
|
|
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
|
|
|
|
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
|
|
|
|
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
|
|
|
|
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
|
|
|
|
REPAIR OR CORRECTION.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
|
|
|
|
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
|
|
|
|
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
|
|
|
|
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
|
|
|
|
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
|
|
|
|
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
|
|
|
|
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
|
|
|
|
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
|
|
|
|
POSSIBILITY OF SUCH DAMAGES.
|
|
|
|
@end enumerate
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@iftex
|
|
|
|
@heading END OF TERMS AND CONDITIONS
|
|
|
|
@end iftex
|
|
|
|
@ifinfo
|
|
|
|
@center END OF TERMS AND CONDITIONS
|
|
|
|
@end ifinfo
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@page
|
|
|
|
@unnumberedsec How to Apply These Terms to Your New Programs
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If you develop a new program, and you want it to be of the greatest
|
|
|
|
possible use to the public, the best way to achieve this is to make it
|
|
|
|
free software which everyone can redistribute and change under these terms.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
To do so, attach the following notices to the program. It is safest
|
|
|
|
to attach them to the start of each source file to most effectively
|
|
|
|
convey the exclusion of warranty; and each file should have at least
|
|
|
|
the ``copyright'' line and a pointer to where the full notice is found.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@smallexample
|
|
|
|
@var{one line to give the program's name and a brief idea of what it does.}
|
1999-10-16 06:09:09 +00:00
|
|
|
Copyright (C) @var{yyyy} @var{name of author}
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
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
|
|
|
|
the Free Software Foundation; either version 2 of the License, or
|
|
|
|
(at your option) any later version.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program; if not, write to the Free Software
|
|
|
|
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
|
|
|
@end smallexample
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
Also add information on how to contact you by electronic and paper mail.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
If the program is interactive, make it output a short notice like this
|
|
|
|
when it starts in an interactive mode:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@smallexample
|
1999-10-16 06:09:09 +00:00
|
|
|
Gnomovision version 69, Copyright (C) @var{yyyy} @var{name of author}
|
1999-08-26 09:30:50 +00:00
|
|
|
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
|
|
|
|
type `show w'.
|
|
|
|
This is free software, and you are welcome to redistribute it
|
|
|
|
under certain conditions; type `show c' for details.
|
|
|
|
@end smallexample
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
The hypothetical commands @samp{show w} and @samp{show c} should show
|
|
|
|
the appropriate parts of the General Public License. Of course, the
|
|
|
|
commands you use may be called something other than @samp{show w} and
|
|
|
|
@samp{show c}; they could even be mouse-clicks or menu items---whatever
|
|
|
|
suits your program.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
You should also get your employer (if you work as a programmer) or your
|
|
|
|
school, if any, to sign a ``copyright disclaimer'' for the program, if
|
|
|
|
necessary. Here is a sample; alter the names:
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@smallexample
|
|
|
|
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
|
|
|
|
`Gnomovision' (which makes passes at compilers) written by James Hacker.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@var{signature of Ty Coon}, 1 April 1989
|
|
|
|
Ty Coon, President of Vice
|
|
|
|
@end smallexample
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
This General Public License does not permit incorporating your program into
|
|
|
|
proprietary programs. If your program is a subroutine library, you may
|
|
|
|
consider it more useful to permit linking proprietary applications with the
|
|
|
|
library. If this is what you want to do, use the GNU Library General
|
|
|
|
Public License instead of this License.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@node Contributors
|
1999-10-16 06:09:09 +00:00
|
|
|
@unnumbered Contributors to GCC
|
1999-08-26 09:30:50 +00:00
|
|
|
@cindex contributors
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
In addition to Richard Stallman, several people have written parts
|
1999-10-16 06:09:09 +00:00
|
|
|
of GCC.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Paul Rubin wrote most of the preprocessor.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Leonard Tower wrote parts of the parser, RTL generator, and RTL
|
|
|
|
definitions, and of the Vax machine description.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Ted Lemon wrote parts of the RTL reader and printer.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Jim Wilson implemented loop strength reduction and some other
|
|
|
|
loop optimizations.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Nobuyuki Hikichi of Software Research Associates, Tokyo, contributed
|
|
|
|
the support for the Sony NEWS machine.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Charles LaBrec contributed the support for the Integrated Solutions
|
|
|
|
68020 system.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Randy Smith finished the Sun FPA support.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Robert Brown implemented the support for Encore 32000 systems.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
David Kashtan of SRI adapted GCC to VMS.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Alex Crain provided changes for the 3b1.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
Greg Satz and Chris Hanson assisted in making GCC work on HP-UX for
|
1999-08-26 09:30:50 +00:00
|
|
|
the 9000 series 300.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
William Schelter did most of the work on the Intel 80386 support.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Christopher Smith did the port for Convex machines.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Paul Petersen wrote the machine description for the Alliant FX/8.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Dario Dariol contributed the four varieties of sample programs
|
|
|
|
that print a copy of their source.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
Alain Lichnewsky ported GCC to the Mips cpu.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
Devon Bowen, Dale Wiles and Kevin Zachmann ported GCC to the Tahoe.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Jonathan Stone wrote the machine description for the Pyramid computer.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
1999-10-16 06:09:09 +00:00
|
|
|
Gary Miller ported GCC to Charles River Data Systems machines.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Richard Kenner and Michael Tiemann jointly developed reorg.c, the delay
|
|
|
|
slot scheduler.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Mike Meissner and Tom Wood of Data General finished the port to the
|
|
|
|
Motorola 88000.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Masanobu Yuhara of Fujitsu Laboratories implemented the machine
|
|
|
|
description for the Tron architecture (specifically, the Gmicro).
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
James van Artsdalen wrote the code that makes efficient use of
|
|
|
|
the Intel 80387 register stack.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Torbjorn Granlund implemented multiply- and divide-by-constant
|
|
|
|
optimization, improved long long support, and improved leaf function
|
|
|
|
register allocation.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Mike Stump implemented the support for Elxsi 64 bit CPU.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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).
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Holger Teutsch provided the support for the Clipper cpu.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Kresten Krab Thorup wrote the run time support for the Objective C
|
|
|
|
language.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Stephen Moshier contributed the floating point emulator that assists in
|
|
|
|
cross-compilation and permits support for floating point numbers wider
|
|
|
|
than 64 bits.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
David Edelsohn contributed the changes to RS/6000 port to make it
|
|
|
|
support the PowerPC and POWER2 architectures.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Steve Chamberlain wrote the support for the Hitachi SH processor.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@item
|
|
|
|
Peter Schauer wrote the code to allow debugging to work on the Alpha.
|
1996-09-18 05:35:50 +00:00
|
|
|
|
1999-08-26 09:30:50 +00:00
|
|
|
@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
|
1996-09-18 05:35:50 +00:00
|
|
|
|
|
|
|
@node Index
|
|
|
|
@unnumbered Index
|
|
|
|
@end ifset
|
|
|
|
|
|
|
|
@ifclear INTERNALS
|
|
|
|
@node Index
|
|
|
|
@unnumbered Index
|
|
|
|
@end ifclear
|
|
|
|
|
|
|
|
@printindex cp
|
1999-08-26 09:30:50 +00:00
|
|
|
|
1996-09-18 05:35:50 +00:00
|
|
|
@summarycontents
|
|
|
|
@contents
|
|
|
|
@bye
|