1 \input texinfo @c -*-texinfo-*-
4 @c @setfilename usegcc.info
5 @c @setfilename portgcc.info
6 @c To produce the full manual, use the "gcc.info" setfilename, and
7 @c make sure the following do NOT begin with '@c' (and the @clear lines DO)
10 @c To produce a user-only manual, use the "usegcc.info" setfilename, and
11 @c make sure the following does NOT begin with '@c':
13 @c To produce a porter-only manual, use the "portgcc.info" setfilename,
14 @c and make sure the following does NOT begin with '@c':
17 @c (For FSF printing, turn on smallbook, comment out finalout below;
18 @c that is all that is needed.)
20 @c 6/27/96 FSF DO wants smallbook fmt for 1st bound edition.
23 @c i also commented out the finalout command, so if there *are* any
24 @c overfulls, you'll (hopefully) see the rectangle in the right hand
25 @c margin. -mew 15june93
28 @c NOTE: checks/things to do:
30 @c -have bob do a search in all seven files for "mew" (ideally --mew,
31 @c but i may have forgotten the occasional "--"..).
32 @c Just checked... all have `--'! Bob 22Jul96
33 @c Use this to search: grep -n '\-\-mew' *.texi
34 @c -item/itemx, text after all (sub/sub)section titles, etc..
35 @c -consider putting the lists of options on pp 17--> etc in columns or
38 @c -continuity of phrasing; ie, bit-field vs bitfield in rtl.texi
39 @c -overfulls. do a search for "mew" in the files, and you will see
40 @c overfulls that i noted but could not deal with.
41 @c -have to add text: beginning of chapter 8
44 @c anything else? --mew 10feb93
46 @macro gcctabopt{body}
49 @macro gccoptlist{body}
54 @c Makeinfo handles the above macro OK, TeX needs manual line breaks;
55 @c they get lost at some point in handling the macro. But if @macro is
56 @c used here rather than @alias, it produces double line breaks.
67 @settitle Using and Porting the GNU Compiler Collection (GCC)
70 @c seems reasonable to assume at least one of INTERNALS or USING is set...
72 @settitle Using the GNU Compiler Collection
75 @settitle Porting the GNU Compiler Collection
82 @c Use with @@smallbook.
84 @c Cause even numbered pages to be printed on the left hand side of
85 @c the page and odd numbered pages to be printed on the right hand
86 @c side of the page. Using this, you can print on both sides of a
87 @c sheet of paper and have the text on the same part of the sheet.
89 @c The text on right hand pages is pushed towards the right hand
90 @c margin and the text on left hand pages is pushed toward the left
92 @c (To provide the reverse effect, set bindingoffset to -0.75in.)
95 @c \global\bindingoffset=0.75in
96 @c \global\normaloffset =0.75in
100 @dircategory Programming
102 * gcc: (gcc). The GNU Compiler Collection.
106 This file documents the use and the internals of the GNU compiler.
110 This file documents the internals of the GNU compiler.
113 This file documents the use of the GNU compiler.
116 Published by the Free Software Foundation@*
117 59 Temple Place - Suite 330@*
118 Boston, MA 02111-1307 USA
120 @c When you update the list of years below, search for copyright{} and
121 @c update the other copy too.
122 Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
123 1999, 2000, 2001 Free Software Foundation, Inc.
125 Permission is granted to make and distribute verbatim copies of
126 this manual provided the copyright notice and this permission notice
127 are preserved on all copies.
130 Permission is granted to process this file through Tex and print the
131 results, provided the printed document carries copying permission
132 notice identical to this one except for the removal of this paragraph
133 (this paragraph not being relevant to the printed manual).
136 Permission is granted to copy and distribute modified versions of this
137 manual under the conditions for verbatim copying, provided also that the
138 sections entitled ``GNU General Public License'' and ``Funding for Free
139 Software'' are included exactly as in the original, and provided that
140 the entire resulting derived work is distributed under the terms of a
141 permission notice identical to this one.
143 Permission is granted to copy and distribute translations of this manual
144 into another language, under the above conditions for modified versions,
145 except that the sections entitled ``GNU General Public License'' and
146 ``Funding for Free Software'', and this permission notice, may be
147 included in translations approved by the Free Software Foundation
148 instead of in the original English.
151 @setchapternewpage odd
156 @center @titlefont{Using and Porting the GNU Compiler Collection}
161 @title Using the GNU Compiler Collection
164 @title Porting the GNU Compiler Collection
167 @center Richard M. Stallman
169 @center Last updated 13 January 2001
171 @c The version number appears five times more in this file.
175 @vskip 0pt plus 1filll
176 Copyright @copyright{} 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1998,
177 1999, 2000, 2001 Free Software Foundation, Inc.
179 For GCC Version 2.97@*
181 Published by the Free Software Foundation @*
182 59 Temple Place - Suite 330@*
183 Boston, MA 02111-1307, USA@*
184 Last printed April, 1998.@*
185 Printed copies are available for $50 each.@*
188 Permission is granted to make and distribute verbatim copies of
189 this manual provided the copyright notice and this permission notice
190 are preserved on all copies.
192 Permission is granted to copy and distribute modified versions of this
193 manual under the conditions for verbatim copying, provided also that the
194 sections entitled ``GNU General Public License'' and ``Funding for Free
195 Software'' are included exactly as in the original, and provided that
196 the entire resulting derived work is distributed under the terms of a
197 permission notice identical to this one.
199 Permission is granted to copy and distribute translations of this manual
200 into another language, under the above conditions for modified versions,
201 except that the sections entitled ``GNU General Public License'' and
202 ``Funding for Free Software'', and this permission notice, may be
203 included in translations approved by the Free Software Foundation
204 instead of in the original English.
208 @node Top, G++ and GCC,, (DIR)
214 This manual documents how to run, install and port the GNU
215 compiler, as well as its new features and incompatibilities, and how to
216 report bugs. It corresponds to GCC version 2.97.
221 This manual documents how to run and install the GNU compiler,
222 as well as its new features and incompatibilities, and how to report
223 bugs. It corresponds to GCC version 2.97.
226 This manual documents how to port the GNU compiler,
227 as well as its new features and incompatibilities, and how to report
228 bugs. It corresponds to GCC version 2.97.
233 * G++ and GCC:: You can compile C or C++ programs.
234 * Standards:: Language standards supported by GCC.
235 * Invoking GCC:: Command options supported by @samp{gcc}.
236 * Installation:: How to configure, compile and install GCC.
237 * C Extensions:: GNU extensions to the C language family.
238 * C++ Extensions:: GNU extensions to the C++ language.
239 * Gcov:: gcov: a GCC test coverage program.
240 * Trouble:: If you have trouble installing GCC.
241 * Bugs:: How, why and where to report bugs.
242 * Service:: How to find suppliers of support for GCC.
243 * Contributing:: How to contribute to testing and developing GCC.
244 * VMS:: Using GCC on VMS.
247 * Portability:: Goals of GCC's portability features.
248 * Interface:: Function-call interface of GCC output.
249 * Passes:: Order of passes, what they do, and what each file is for.
250 * RTL:: The intermediate representation that most passes work on.
251 * Machine Desc:: How to write machine description instruction patterns.
252 * Target Macros:: How to write the machine description C macros.
253 * Config:: Writing the @file{xm-@var{machine}.h} file.
254 * Fragments:: Writing the @file{t-@var{target}} and @file{x-@var{host}} files.
257 * Funding:: How to help assure funding for free software.
258 * GNU/Linux:: Linux and the GNU Project
260 * Copying:: GNU General Public License says
261 how you can copy and share GCC.
262 * Contributors:: People who have contributed to GCC.
264 * Index:: Index of concepts and symbol names.
269 @chapter Compile C, C++, Objective C, Fortran, Java or CHILL
272 Several versions of the compiler (C, C++, Objective C, Fortran, Java
273 and CHILL) are integrated; this is why we use the name
274 ``GNU Compiler Collection''. GCC can compile programs written in any of these
275 languages. The Fortran and CHILL compilers are described in
276 separate manuals. The Java compiler currently has no manual documenting it.
279 ``GCC'' is a common shorthand term for the GNU Compiler Collection. This is both
280 the most general name for the compiler, and the name used when the
281 emphasis is on compiling C programs (as the abbreviation formerly
282 stood for ``GNU C Compiler'').
286 When referring to C++ compilation, it is usual to call the compiler
287 ``G++''. Since there is only one compiler, it is also accurate to call
288 it ``GCC'' no matter what the language context; however, the term
289 ``G++'' is more useful when the emphasis is on compiling C++ programs.
291 We use the name ``GCC'' to refer to the compilation system as a
292 whole, and more specifically to the language-independent part of the
293 compiler. For example, we refer to the optimization options as
294 affecting the behavior of ``GCC'' or sometimes just ``the compiler''.
296 Front ends for other languages, such as Ada 95 and Pascal exist but
297 have not yet been integrated into GCC. These front-ends, like that for C++,
298 are built in subdirectories of GCC and link to it. The result is an
299 integrated compiler that can compile programs written in C, C++,
300 Objective C, or any of the languages for which you have installed front
303 In this manual, we only discuss the options for the C, Objective-C, and
304 C++ compilers and those of the GCC core. Consult the documentation
305 of the other front ends for the options to use when compiling programs
306 written in other languages.
308 @cindex compiler compared to C++ preprocessor
309 @cindex intermediate C version, nonexistent
310 @cindex C intermediate output, nonexistent
311 G++ is a @emph{compiler}, not merely a preprocessor. G++ builds object
312 code directly from your C++ program source. There is no intermediate C
313 version of the program. (By contrast, for example, some other
314 implementations use a program that generates a C program from your C++
315 source.) Avoiding an intermediate C representation of the program means
316 that you get better object code, and better debugging information. The
317 GNU debugger, GDB, works with this information in the object code to
318 give you comprehensive C++ source-level editing capabilities
319 (@pxref{C,,C and C++,gdb.info, Debugging with GDB}).
321 @c FIXME! Someone who knows something about Objective C ought to put in
322 @c a paragraph or two about it here, and move the index entry down when
323 @c there is more to point to than the general mention in the 1st par.
326 @chapter Language Standards Supported by GCC
329 @cindex ANSI C standard
333 @cindex ANSI X3.159-1989
335 @cindex ISO C standard
350 @cindex Technical Corrigenda
352 @cindex Technical Corrigendum 1
354 @cindex Technical Corrigendum 2
356 @cindex freestanding implementation
357 @cindex freestanding environment
358 @cindex hosted implementation
359 @cindex hosted environment
360 @findex __STDC_HOSTED__
362 For each language compiled by GCC for which there is a standard, GCC
363 attempts to follow one or more versions of that standard, possibly
364 with some exceptions, and possibly with some extensions.
366 GCC supports three versions of the C standard, although support for
367 the most recent version is not yet complete.
369 The original ANSI C standard (X3.159-1989) was ratified in 1989 and
370 published in 1990. This standard was ratified as an ISO standard
371 (ISO/IEC 9899:1990) later in 1990. There were no technical
372 differences between these publications, although the sections of the
373 ANSI standard were renumbered and became clauses in the ISO standard.
374 This standard, in both its forms, is commonly known as @dfn{C89}, or
375 occasionally as @dfn{C90}, from the dates of ratification. The ANSI
376 standard, but not the ISO standard, also came with a Rationale
377 document. To select this standard in GCC, use one of the options
378 @samp{-ansi}, @samp{-std=c89} or @samp{-std=iso9899:1990}; to obtain
379 all the diagnostics required by the standard, you should also specify
380 @samp{-pedantic} (or @samp{-pedantic-errors} if you want them to be
381 errors rather than warnings). @xref{C Dialect Options,,Options
382 Controlling C Dialect}.
384 Errors in the 1990 ISO C standard were corrected in two Technical
385 Corrigenda published in 1994 and 1996. GCC does not support the
388 An amendment to the 1990 standard was published in 1995. This
389 amendment added digraphs and @code{__STDC_VERSION__} to the language,
390 but otherwise concerned the library. This amendment is commonly known
391 as @dfn{AMD1}; the amended standard is sometimes known as @dfn{C94} or
392 @dfn{C95}. To select this standard in GCC, use the option
393 @samp{-std=iso9899:199409} (with, as for other standard versions,
394 @samp{-pedantic} to receive all required diagnostics).
396 A new edition of the ISO C standard was published in 1999 as ISO/IEC
397 9899:1999, and is commonly known as @dfn{C99}. GCC has incomplete
398 support for this standard version; see
399 @uref{http://gcc.gnu.org/c99status.html} for details. To select this
400 standard, use @samp{-std=c99} or @samp{-std=iso9899:1999}. (While in
401 development, drafts of this standard version were referred to as
404 GCC also has some limited support for traditional (pre-ISO) C with the
405 @samp{-traditional} option. This support may be of use for compiling
406 some very old programs that have not been updated to ISO C, but should
407 not be used for new programs. It will not work with some modern C
408 libraries such as the GNU C library.
410 By default, GCC provides some extensions to the C language that on
411 rare occasions conflict with the C standard. @xref{C
412 Extensions,,Extensions to the C Language Family}. Use of the
413 @samp{-std} options listed above will disable these extensions where
414 they conflict with the C standard version selected. You may also
415 select an extended version of the C language explicitly with
416 @samp{-std=gnu89} (for C89 with GNU extensions) or @samp{-std=gnu99}
417 (for C99 with GNU extensions). The default, if no C language dialect
418 options are given, is @samp{-std=gnu89}; this will change to
419 @samp{-std=gnu99} in some future release when the C99 support is
420 complete. Some features that are part of the C99 standard are
421 accepted as extensions in C89 mode.
423 The ISO C standard defines (in clause 4) two classes of conforming
424 implementation. A @dfn{conforming hosted implementation} supports the
425 whole standard including all the library facilities; a @dfn{conforming
426 freestanding implementation} is only required to provide certain
427 library facilities: those in @code{<float.h>}, @code{<limits.h>},
428 @code{<stdarg.h>}, and @code{<stddef.h>}; since AMD1, also those in
429 @code{<iso646.h>}; and in C99, also those in @code{<stdbool.h>} and
430 @code{<stdint.h>}. In addition, complex types, added in C99, are not
431 required for freestanding implementations. The standard also defines
432 two environments for programs, a @dfn{freestanding environment},
433 required of all implementations and which may not have library
434 facilities beyond those required of freestanding implementations,
435 where the handling of program startup and termination are
436 implementation-defined, and a @dfn{hosted environment}, which is not
437 required, in which all the library facilities are provided and startup
438 is through a function @code{int main (void)} or @code{int main (int,
439 char *[])}. An OS kernel would be a freestanding environment; a
440 program using the facilities of an operating system would normally be
441 in a hosted implementation.
443 GNU CC aims towards being usable as a conforming freestanding
444 implementation, or as the compiler for a conforming hosted
445 implementation. By default, it will act as the compiler for a hosted
446 implementation, defining @code{__STDC_HOSTED__} as @code{1} and
447 presuming that when the names of ISO C functions are used, they have
448 the semantics defined in the standard. To make it act as a conforming
449 freestanding implementation for a freestanding environment, use the
450 option @samp{-ffreestanding}; it will then define
451 @code{__STDC_HOSTED__} to @code{0} and not make assumptions about the
452 meanings of function names from the standard library. To build an OS
453 kernel, you may well still need to make your own arrangements for
454 linking and startup. @xref{C Dialect Options,,Options Controlling C
457 GNU CC does not provide the library facilities required only of hosted
458 implementations, nor yet all the facilities required by C99 of
459 freestanding implementations; to use the facilities of a hosted
460 environment, you will need to find them elsewhere (for example, in the
461 GNU C library). @xref{Standard Libraries,,Standard Libraries}.
463 For references to Technical Corrigenda, Rationale documents and
464 information concerning the history of C that is available online, see
465 @uref{http://gcc.gnu.org/readings.html}
467 @c FIXME: details of C++ standard.
468 @c FIXME: definitions of Java and Objective C.
470 @xref{Language,,The GNU Fortran Language, g77, Using and Porting GNU
471 Fortran}, for details of the Fortran language supported by GCC.
473 @xref{References,,Language Definition References, chill, GNU Chill},
474 for details of the CHILL standard.
478 @include install.texi
485 @chapter Known Causes of Trouble with GCC
487 @cindex installation trouble
488 @cindex known causes of trouble
490 This section describes known problems that affect users of GCC. Most
491 of these are not GCC bugs per se---if they were, we would fix them.
492 But the result for a user may be like the result of a bug.
494 Some of these problems are due to bugs in other software, some are
495 missing features that are too much work to add, and some are places
496 where people's opinions differ as to what is best.
499 * Actual Bugs:: Bugs we will fix later.
500 * Installation Problems:: Problems that manifest when you install GCC.
501 * Cross-Compiler Problems:: Common problems of cross compiling with GCC.
502 * Interoperation:: Problems using GCC with other compilers,
503 and with certain linkers, assemblers and debuggers.
504 * External Bugs:: Problems compiling certain programs.
505 * Incompatibilities:: GCC is incompatible with traditional C.
506 * Fixed Headers:: GNU C uses corrected versions of system header files.
507 This is necessary, but doesn't always work smoothly.
508 * Standard Libraries:: GNU C uses the system C library, which might not be
509 compliant with the ISO C standard.
510 * Disappointments:: Regrettable things we can't change, but not quite bugs.
511 * C++ Misunderstandings:: Common misunderstandings with GNU C++.
512 * Protoize Caveats:: Things to watch out for when using @code{protoize}.
513 * Non-bugs:: Things we think are right, but some others disagree.
514 * Warnings and Errors:: Which problems in your code get warnings,
515 and which get errors.
519 @section Actual Bugs We Haven't Fixed Yet
523 The @code{fixincludes} script interacts badly with automounters; if the
524 directory of system header files is automounted, it tends to be
525 unmounted while @code{fixincludes} is running. This would seem to be a
526 bug in the automounter. We don't know any good way to work around it.
529 The @code{fixproto} script will sometimes add prototypes for the
530 @code{sigsetjmp} and @code{siglongjmp} functions that reference the
531 @code{jmp_buf} type before that type is defined. To work around this,
532 edit the offending file and place the typedef in front of the
536 There are several obscure case of mis-using struct, union, and
537 enum tags that are not detected as errors by the compiler.
540 When @samp{-pedantic-errors} is specified, GCC will incorrectly give
541 an error message when a function name is specified in an expression
542 involving the comma operator.
545 Loop unrolling doesn't work properly for certain C++ programs. This is
546 a bug in the C++ front end. It sometimes emits incorrect debug info, and
547 the loop unrolling code is unable to recover from this error.
550 @node Installation Problems
551 @section Installation Problems
553 This is a list of problems (and some apparent problems which don't
554 really mean anything is wrong) that show up during installation of GNU
559 On certain systems, defining certain environment variables such as
560 @code{CC} can interfere with the functioning of @code{make}.
563 If you encounter seemingly strange errors when trying to build the
564 compiler in a directory other than the source directory, it could be
565 because you have previously configured the compiler in the source
566 directory. Make sure you have done all the necessary preparations.
570 If you build GCC on a BSD system using a directory stored in a System
571 V file system, problems may occur in running @code{fixincludes} if the
572 System V file system doesn't support symbolic links. These problems
573 result in a failure to fix the declaration of @code{size_t} in
574 @file{sys/types.h}. If you find that @code{size_t} is a signed type and
575 that type mismatches occur, this could be the cause.
577 The solution is not to use such a directory for building GCC.
580 In previous versions of GCC, the @code{gcc} driver program looked for
581 @code{as} and @code{ld} in various places; for example, in files
582 beginning with @file{/usr/local/lib/gcc-}. GCC version 2 looks for
583 them in the directory
584 @file{/usr/local/lib/gcc-lib/@var{target}/@var{version}}.
586 Thus, to use a version of @code{as} or @code{ld} that is not the system
587 default, for example @code{gas} or GNU @code{ld}, you must put them in
588 that directory (or make links to them from that directory).
591 Some commands executed when making the compiler may fail (return a
592 non-zero status) and be ignored by @code{make}. These failures, which
593 are often due to files that were not found, are expected, and can safely
597 It is normal to have warnings in compiling certain files about
598 unreachable code and about enumeration type clashes. These files' names
599 begin with @samp{insn-}. Also, @file{real.c} may get some warnings that
603 Sometimes @code{make} recompiles parts of the compiler when installing
604 the compiler. In one case, this was traced down to a bug in
605 @code{make}. Either ignore the problem or switch to GNU Make.
608 If you have installed a program known as purify, you may find that it
609 causes errors while linking @code{enquire}, which is part of building
610 GCC. The fix is to get rid of the file @code{real-ld} which purify
611 installs---so that GCC won't try to use it.
614 On GNU/Linux SLS 1.01, there is a problem with @file{libc.a}: it does not
615 contain the obstack functions. However, GCC assumes that the obstack
616 functions are in @file{libc.a} when it is the GNU C library. To work
617 around this problem, change the @code{__GNU_LIBRARY__} conditional
618 around line 31 to @samp{#if 1}.
621 On some 386 systems, building the compiler never finishes because
622 @code{enquire} hangs due to a hardware problem in the motherboard---it
623 reports floating point exceptions to the kernel incorrectly. You can
624 install GCC except for @file{float.h} by patching out the command to
625 run @code{enquire}. You may also be able to fix the problem for real by
626 getting a replacement motherboard. This problem was observed in
627 Revision E of the Micronics motherboard, and is fixed in Revision F.
628 It has also been observed in the MYLEX MXA-33 motherboard.
630 If you encounter this problem, you may also want to consider removing
631 the FPU from the socket during the compilation. Alternatively, if you
632 are running SCO Unix, you can reboot and force the FPU to be ignored.
633 To do this, type @samp{hd(40)unix auto ignorefpu}.
636 On some 386 systems, GCC crashes trying to compile @file{enquire.c}.
637 This happens on machines that don't have a 387 FPU chip. On 386
638 machines, the system kernel is supposed to emulate the 387 when you
639 don't have one. The crash is due to a bug in the emulator.
641 One of these systems is the Unix from Interactive Systems: 386/ix.
642 On this system, an alternate emulator is provided, and it does work.
643 To use it, execute this command as super-user:
646 ln /etc/emulator.rel1 /etc/emulator
650 and then reboot the system. (The default emulator file remains present
651 under the name @file{emulator.dflt}.)
653 Try using @file{/etc/emulator.att}, if you have such a problem on the
656 Another system which has this problem is Esix. We don't know whether it
657 has an alternate emulator that works.
659 On NetBSD 0.8, a similar problem manifests itself as these error messages:
662 enquire.c: In function `fprop':
663 enquire.c:2328: floating overflow
667 On SCO systems, when compiling GCC with the system's compiler,
668 do not use @samp{-O}. Some versions of the system's compiler miscompile
671 @cindex @code{genflags}, crash on Sun 4
673 Sometimes on a Sun 4 you may observe a crash in the program
674 @code{genflags} or @code{genoutput} while building GCC. This is said to
675 be due to a bug in @code{sh}. You can probably get around it by running
676 @code{genflags} or @code{genoutput} manually and then retrying the
680 On Solaris 2, executables of GCC version 2.0.2 are commonly
681 available, but they have a bug that shows up when compiling current
682 versions of GCC: undefined symbol errors occur during assembly if you
685 The solution is to compile the current version of GCC without
686 @samp{-g}. That makes a working compiler which you can use to recompile
690 Solaris 2 comes with a number of optional OS packages. Some of these
691 packages are needed to use GCC fully. If you did not install all
692 optional packages when installing Solaris, you will need to verify that
693 the packages that GCC needs are installed.
695 To check whether an optional package is installed, use
696 the @code{pkginfo} command. To add an optional package, use the
697 @code{pkgadd} command. For further details, see the Solaris
700 For Solaris 2.0 and 2.1, GCC needs six packages: @samp{SUNWarc},
701 @samp{SUNWbtool}, @samp{SUNWesu}, @samp{SUNWhea}, @samp{SUNWlibm}, and
704 For Solaris 2.2, GCC needs an additional seventh package: @samp{SUNWsprot}.
707 On Solaris 2, trying to use the linker and other tools in
708 @file{/usr/ucb} to install GCC has been observed to cause trouble.
709 For example, the linker may hang indefinitely. The fix is to remove
710 @file{/usr/ucb} from your @code{PATH}.
713 If you use the 1.31 version of the MIPS assembler (such as was shipped
714 with Ultrix 3.1), you will need to use the -fno-delayed-branch switch
715 when optimizing floating point code. Otherwise, the assembler will
716 complain when the GCC compiler fills a branch delay slot with a
717 floating point instruction, such as @code{add.d}.
720 If on a MIPS system you get an error message saying ``does not have gp
721 sections for all it's [sic] sectons [sic]'', don't worry about it. This
722 happens whenever you use GAS with the MIPS linker, but there is not
723 really anything wrong, and it is okay to use the output file. You can
724 stop such warnings by installing the GNU linker.
726 It would be nice to extend GAS to produce the gp tables, but they are
727 optional, and there should not be a warning about their absence.
730 In Ultrix 4.0 on the MIPS machine, @file{stdio.h} does not work with GNU
731 CC at all unless it has been fixed with @code{fixincludes}. This causes
732 problems in building GCC. Once GCC is installed, the problems go
735 To work around this problem, when making the stage 1 compiler, specify
739 GCC_FOR_TARGET="./xgcc -B./ -I./include"
742 When making stage 2 and stage 3, specify this option:
745 CFLAGS="-g -I./include"
749 Users have reported some problems with version 2.0 of the MIPS
750 compiler tools that were shipped with Ultrix 4.1. Version 2.10
751 which came with Ultrix 4.2 seems to work fine.
753 Users have also reported some problems with version 2.20 of the
754 MIPS compiler tools that were shipped with RISC/os 4.x. The earlier
755 version 2.11 seems to work fine.
758 Some versions of the MIPS linker will issue an assertion failure
759 when linking code that uses @code{alloca} against shared
760 libraries on RISC-OS 5.0, and DEC's OSF/1 systems. This is a bug
761 in the linker, that is supposed to be fixed in future revisions.
762 To protect against this, GCC passes @samp{-non_shared} to the
763 linker unless you pass an explicit @samp{-shared} or
764 @samp{-call_shared} switch.
767 On System V release 3, you may get this error message
771 ld fatal: failed to write symbol name @var{something}
772 in strings table for file @var{whatever}
775 This probably indicates that the disk is full or your ULIMIT won't allow
776 the file to be as large as it needs to be.
778 This problem can also result because the kernel parameter @code{MAXUMEM}
779 is too small. If so, you must regenerate the kernel and make the value
780 much larger. The default value is reported to be 1024; a value of 32768
781 is said to work. Smaller values may also work.
784 On System V, if you get an error like this,
787 /usr/local/lib/bison.simple: In function `yyparse':
788 /usr/local/lib/bison.simple:625: virtual memory exhausted
792 that too indicates a problem with disk space, ULIMIT, or @code{MAXUMEM}.
795 Current GCC versions probably do not work on version 2 of the NeXT
799 On NeXTStep 3.0, the Objective C compiler does not work, due,
800 apparently, to a kernel bug that it happens to trigger. This problem
801 does not happen on 3.1.
804 On the Tower models 4@var{n}0 and 6@var{n}0, by default a process is not
805 allowed to have more than one megabyte of memory. GCC cannot compile
806 itself (or many other programs) with @samp{-O} in that much memory.
808 To solve this problem, reconfigure the kernel adding the following line
809 to the configuration file:
816 On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a bug
817 in the assembler that must be fixed before GCC can be built. This
818 bug manifests itself during the first stage of compilation, while
819 building @file{libgcc2.a}:
823 cc1: warning: `-g' option not supported on this version of GCC
824 cc1: warning: `-g1' option not supported on this version of GCC
825 ./xgcc: Internal compiler error: program as got fatal signal 11
828 A patched version of the assembler is available as the file
829 @uref{ftp://altdorf.ai.mit.edu/archive/cph/hpux-8.0-assembler}. If you
830 have HP software support, the patch can also be obtained directly from
831 HP, as described in the following note:
834 This is the patched assembler, to patch SR#1653-010439, where the
835 assembler aborts on floating point constants.
837 The bug is not really in the assembler, but in the shared library
838 version of the function ``cvtnum(3c)''. The bug on ``cvtnum(3c)'' is
839 SR#4701-078451. Anyway, the attached assembler uses the archive
840 library version of ``cvtnum(3c)'' and thus does not exhibit the bug.
843 This patch is also known as PHCO_4484.
846 On HP-UX version 8.05, but not on 8.07 or more recent versions,
847 the @code{fixproto} shell script triggers a bug in the system shell.
848 If you encounter this problem, upgrade your operating system or
849 use BASH (the GNU shell) to run @code{fixproto}.
852 Some versions of the Pyramid C compiler are reported to be unable to
853 compile GCC. You must use an older version of GCC for
854 bootstrapping. One indication of this problem is if you get a crash
855 when GCC compiles the function @code{muldi3} in file @file{libgcc2.c}.
857 You may be able to succeed by getting GCC version 1, installing it,
858 and using it to compile GCC version 2. The bug in the Pyramid C
859 compiler does not seem to affect GCC version 1.
862 There may be similar problems on System V Release 3.1 on 386 systems.
865 On the Intel Paragon (an i860 machine), if you are using operating
866 system version 1.0, you will get warnings or errors about redefinition
867 of @code{va_arg} when you build GCC.
869 If this happens, then you need to link most programs with the library
870 @file{iclib.a}. You must also modify @file{stdio.h} as follows: before
874 #if defined(__i860__) && !defined(_VA_LIST)
889 extern int vprintf(const char *, va_list );
890 extern int vsprintf(char *, const char *, va_list );
901 These problems don't exist in operating system version 1.1.
904 On the Altos 3068, programs compiled with GCC won't work unless you
905 fix a kernel bug. This happens using system versions V.2.2 1.0gT1 and
906 V.2.2 1.0e and perhaps later versions as well. See the file
910 You will get several sorts of compilation and linking errors on the
911 we32k if you don't follow the special instructions. @xref{Configurations}.
914 A bug in the HP-UX 8.05 (and earlier) shell will cause the fixproto
915 program to report an error of the form:
918 ./fixproto: sh internal 1K buffer overflow
921 To fix this, change the first line of the fixproto script to look like:
928 @node Cross-Compiler Problems
929 @section Cross-Compiler Problems
931 You may run into problems with cross compilation on certain machines,
936 Cross compilation can run into trouble for certain machines because
937 some target machines' assemblers require floating point numbers to be
938 written as @emph{integer} constants in certain contexts.
940 The compiler writes these integer constants by examining the floating
941 point value as an integer and printing that integer, because this is
942 simple to write and independent of the details of the floating point
943 representation. But this does not work if the compiler is running on
944 a different machine with an incompatible floating point format, or
945 even a different byte-ordering.
947 In addition, correct constant folding of floating point values
948 requires representing them in the target machine's format.
949 (The C standard does not quite require this, but in practice
950 it is the only way to win.)
952 It is now possible to overcome these problems by defining macros such
953 as @code{REAL_VALUE_TYPE}. But doing so is a substantial amount of
954 work for each target machine.
956 @xref{Cross-compilation}.
959 @xref{Cross-compilation,,Cross Compilation and Floating Point Format,
960 gcc.info, Using and Porting GCC}.
964 At present, the program @file{mips-tfile} which adds debug
965 support to object files on MIPS systems does not work in a cross
970 @section Interoperation
972 This section lists various difficulties encountered in using GNU C or
973 GNU C++ together with other compilers or with the assemblers, linkers,
974 libraries and debuggers on certain systems.
978 Objective C does not work on the RS/6000.
981 GNU C++ does not do name mangling in the same way as other C++
982 compilers. This means that object files compiled with one compiler
983 cannot be used with another.
985 This effect is intentional, to protect you from more subtle problems.
986 Compilers differ as to many internal details of C++ implementation,
987 including: how class instances are laid out, how multiple inheritance is
988 implemented, and how virtual function calls are handled. If the name
989 encoding were made the same, your programs would link against libraries
990 provided from other compilers---but the programs would then crash when
991 run. Incompatible libraries are then detected at link time, rather than
995 Older GDB versions sometimes fail to read the output of GCC version
996 2. If you have trouble, get GDB version 4.4 or later.
1000 DBX rejects some files produced by GCC, though it accepts similar
1001 constructs in output from PCC. Until someone can supply a coherent
1002 description of what is valid DBX input and what is not, there is
1003 nothing I can do about these problems. You are on your own.
1006 The GNU assembler (GAS) does not support PIC. To generate PIC code, you
1007 must use some other assembler, such as @file{/bin/as}.
1010 On some BSD systems, including some versions of Ultrix, use of profiling
1011 causes static variable destructors (currently used only in C++) not to
1015 Use of @samp{-I/usr/include} may cause trouble.
1017 Many systems come with header files that won't work with GCC unless
1018 corrected by @code{fixincludes}. The corrected header files go in a new
1019 directory; GCC searches this directory before @file{/usr/include}.
1020 If you use @samp{-I/usr/include}, this tells GCC to search
1021 @file{/usr/include} earlier on, before the corrected headers. The
1022 result is that you get the uncorrected header files.
1024 Instead, you should use these options (when compiling C programs):
1027 -I/usr/local/lib/gcc-lib/@var{target}/@var{version}/include -I/usr/include
1030 For C++ programs, GCC also uses a special directory that defines C++
1031 interfaces to standard C subroutines. This directory is meant to be
1032 searched @emph{before} other standard include directories, so that it
1033 takes precedence. If you are compiling C++ programs and specifying
1034 include directories explicitly, use this option first, then the two
1038 -I/usr/local/lib/g++-include
1042 @cindex @code{vfork}, for the Sun-4
1044 There is a bug in @code{vfork} on the Sun-4 which causes the registers
1045 of the child process to clobber those of the parent. Because of this,
1046 programs that call @code{vfork} are likely to lose when compiled
1047 optimized with GCC when the child code alters registers which contain
1048 C variables in the parent. This affects variables which are live in the
1049 parent across the call to @code{vfork}.
1051 If you encounter this, you can work around the problem by declaring
1052 variables @code{volatile} in the function that calls @code{vfork}, until
1053 the problem goes away, or by not declaring them @code{register} and not
1054 using @samp{-O} for those source files.
1058 On some SGI systems, when you use @samp{-lgl_s} as an option,
1059 it gets translated magically to @samp{-lgl_s -lX11_s -lc_s}.
1060 Naturally, this does not happen when you use GCC.
1061 You must specify all three options explicitly.
1064 On a Sparc, GCC aligns all values of type @code{double} on an 8-byte
1065 boundary, and it expects every @code{double} to be so aligned. The Sun
1066 compiler usually gives @code{double} values 8-byte alignment, with one
1067 exception: function arguments of type @code{double} may not be aligned.
1069 As a result, if a function compiled with Sun CC takes the address of an
1070 argument of type @code{double} and passes this pointer of type
1071 @code{double *} to a function compiled with GCC, dereferencing the
1072 pointer may cause a fatal signal.
1074 One way to solve this problem is to compile your entire program with GNU
1075 CC. Another solution is to modify the function that is compiled with
1076 Sun CC to copy the argument into a local variable; local variables
1077 are always properly aligned. A third solution is to modify the function
1078 that uses the pointer to dereference it via the following function
1079 @code{access_double} instead of directly with @samp{*}:
1083 access_double (double *unaligned_ptr)
1085 union d2i @{ double d; int i[2]; @};
1087 union d2i *p = (union d2i *) unaligned_ptr;
1098 Storing into the pointer can be done likewise with the same union.
1101 On Solaris, the @code{malloc} function in the @file{libmalloc.a} library
1102 may allocate memory that is only 4 byte aligned. Since GCC on the
1103 Sparc assumes that doubles are 8 byte aligned, this may result in a
1104 fatal signal if doubles are stored in memory allocated by the
1105 @file{libmalloc.a} library.
1107 The solution is to not use the @file{libmalloc.a} library. Use instead
1108 @code{malloc} and related functions from @file{libc.a}; they do not have
1112 Sun forgot to include a static version of @file{libdl.a} with some
1113 versions of SunOS (mainly 4.1). This results in undefined symbols when
1114 linking static binaries (that is, if you use @samp{-static}). If you
1115 see undefined symbols @code{_dlclose}, @code{_dlsym} or @code{_dlopen}
1116 when linking, compile and link against the file
1117 @file{mit/util/misc/dlsym.c} from the MIT version of X windows.
1120 The 128-bit long double format that the Sparc port supports currently
1121 works by using the architecturally defined quad-word floating point
1122 instructions. Since there is no hardware that supports these
1123 instructions they must be emulated by the operating system. Long
1124 doubles do not work in Sun OS versions 4.0.3 and earlier, because the
1125 kernel emulator uses an obsolete and incompatible format. Long doubles
1126 do not work in Sun OS version 4.1.1 due to a problem in a Sun library.
1127 Long doubles do work on Sun OS versions 4.1.2 and higher, but GCC
1128 does not enable them by default. Long doubles appear to work in Sun OS
1132 On HP-UX version 9.01 on the HP PA, the HP compiler @code{cc} does not
1133 compile GCC correctly. We do not yet know why. However, GCC
1134 compiled on earlier HP-UX versions works properly on HP-UX 9.01 and can
1135 compile itself properly on 9.01.
1138 On the HP PA machine, ADB sometimes fails to work on functions compiled
1139 with GCC. Specifically, it fails to work on functions that use
1140 @code{alloca} or variable-size arrays. This is because GCC doesn't
1141 generate HP-UX unwind descriptors for such functions. It may even be
1142 impossible to generate them.
1145 Debugging (@samp{-g}) is not supported on the HP PA machine, unless you use
1146 the preliminary GNU tools (@pxref{Installation}).
1149 Taking the address of a label may generate errors from the HP-UX
1150 PA assembler. GAS for the PA does not have this problem.
1153 Using floating point parameters for indirect calls to static functions
1154 will not work when using the HP assembler. There simply is no way for GCC
1155 to specify what registers hold arguments for static functions when using
1156 the HP assembler. GAS for the PA does not have this problem.
1159 In extremely rare cases involving some very large functions you may
1160 receive errors from the HP linker complaining about an out of bounds
1161 unconditional branch offset. This used to occur more often in previous
1162 versions of GCC, but is now exceptionally rare. If you should run
1163 into it, you can work around by making your function smaller.
1166 GCC compiled code sometimes emits warnings from the HP-UX assembler of
1170 (warning) Use of GR3 when
1171 frame >= 8192 may cause conflict.
1174 These warnings are harmless and can be safely ignored.
1177 The current version of the assembler (@file{/bin/as}) for the RS/6000
1178 has certain problems that prevent the @samp{-g} option in GCC from
1179 working. Note that @file{Makefile.in} uses @samp{-g} by default when
1180 compiling @file{libgcc2.c}.
1182 IBM has produced a fixed version of the assembler. The upgraded
1183 assembler unfortunately was not included in any of the AIX 3.2 update
1184 PTF releases (3.2.2, 3.2.3, or 3.2.3e). Users of AIX 3.1 should request
1185 PTF U403044 from IBM and users of AIX 3.2 should request PTF U416277.
1186 See the file @file{README.RS6000} for more details on these updates.
1188 You can test for the presence of a fixed assembler by using the
1196 If the command exits normally, the assembler fix already is installed.
1197 If the assembler complains that "-u" is an unknown flag, you need to
1201 On the IBM RS/6000, compiling code of the form
1212 will cause the linker to report an undefined symbol @code{foo}.
1213 Although this behavior differs from most other systems, it is not a
1214 bug because redefining an @code{extern} variable as @code{static}
1215 is undefined in ISO C.
1218 AIX on the RS/6000 provides support (NLS) for environments outside of
1219 the United States. Compilers and assemblers use NLS to support
1220 locale-specific representations of various objects including
1221 floating-point numbers ("." vs "," for separating decimal fractions).
1222 There have been problems reported where the library linked with GCC does
1223 not produce the same floating-point formats that the assembler accepts.
1224 If you have this problem, set the LANG environment variable to "C" or
1228 Even if you specify @samp{-fdollars-in-identifiers},
1229 you cannot successfully use @samp{$} in identifiers on the RS/6000 due
1230 to a restriction in the IBM assembler. GAS supports these
1234 On the RS/6000, XLC version 1.3.0.0 will miscompile @file{jump.c}. XLC
1235 version 1.3.0.1 or later fixes this problem. You can obtain XLC-1.3.0.2
1236 by requesting PTF 421749 from IBM.
1239 There is an assembler bug in versions of DG/UX prior to 5.4.2.01 that
1240 occurs when the @samp{fldcr} instruction is used. GCC uses
1241 @samp{fldcr} on the 88100 to serialize volatile memory references. Use
1242 the option @samp{-mno-serialize-volatile} if your version of the
1243 assembler has this bug.
1246 On VMS, GAS versions 1.38.1 and earlier may cause spurious warning
1247 messages from the linker. These warning messages complain of mismatched
1248 psect attributes. You can ignore them. @xref{VMS Install}.
1251 On NewsOS version 3, if you include both of the files @file{stddef.h}
1252 and @file{sys/types.h}, you get an error because there are two typedefs
1253 of @code{size_t}. You should change @file{sys/types.h} by adding these
1254 lines around the definition of @code{size_t}:
1259 @var{actual typedef here}
1265 On the Alliant, the system's own convention for returning structures
1266 and unions is unusual, and is not compatible with GCC no matter
1267 what options are used.
1272 On the IBM RT PC, the MetaWare HighC compiler (hc) uses a different
1273 convention for structure and union returning. Use the option
1274 @samp{-mhc-struct-return} to tell GCC to use a convention compatible
1277 @cindex Vax calling convention
1278 @cindex Ultrix calling convention
1280 On Ultrix, the Fortran compiler expects registers 2 through 5 to be saved
1281 by function calls. However, the C compiler uses conventions compatible
1282 with BSD Unix: registers 2 through 5 may be clobbered by function calls.
1284 GCC uses the same convention as the Ultrix C compiler. You can use
1285 these options to produce code compatible with the Fortran compiler:
1288 -fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5
1292 On the WE32k, you may find that programs compiled with GCC do not
1293 work with the standard shared C library. You may need to link with
1294 the ordinary C compiler. If you do so, you must specify the following
1298 -L/usr/local/lib/gcc-lib/we32k-att-sysv/2.8.1 -lgcc -lc_s
1301 The first specifies where to find the library @file{libgcc.a}
1302 specified with the @samp{-lgcc} option.
1304 GCC does linking by invoking @code{ld}, just as @code{cc} does, and
1305 there is no reason why it @emph{should} matter which compilation program
1306 you use to invoke @code{ld}. If someone tracks this problem down,
1307 it can probably be fixed easily.
1310 On the Alpha, you may get assembler errors about invalid syntax as a
1311 result of floating point constants. This is due to a bug in the C
1312 library functions @code{ecvt}, @code{fcvt} and @code{gcvt}. Given valid
1313 floating point numbers, they sometimes print @samp{NaN}.
1316 On Irix 4.0.5F (and perhaps in some other versions), an assembler bug
1317 sometimes reorders instructions incorrectly when optimization is turned
1318 on. If you think this may be happening to you, try using the GNU
1319 assembler; GAS version 2.1 supports ECOFF on Irix.
1321 Or use the @samp{-noasmopt} option when you compile GCC with itself,
1322 and then again when you compile your program. (This is a temporary
1323 kludge to turn off assembler optimization on Irix.) If this proves to
1324 be what you need, edit the assembler spec in the file @file{specs} so
1325 that it unconditionally passes @samp{-O0} to the assembler, and never
1326 passes @samp{-O2} or @samp{-O3}.
1330 @section Problems Compiling Certain Programs
1332 @c prevent bad page break with this line
1333 Certain programs have problems compiling.
1337 Parse errors may occur compiling X11 on a Decstation running Ultrix 4.2
1338 because of problems in DEC's versions of the X11 header files
1339 @file{X11/Xlib.h} and @file{X11/Xutil.h}. People recommend adding
1340 @samp{-I/usr/include/mit} to use the MIT versions of the header files,
1341 using the @samp{-traditional} switch to turn off ISO C, or fixing the
1342 header files by adding this:
1346 #define NeedFunctionPrototypes 0
1351 On various 386 Unix systems derived from System V, including SCO, ISC,
1352 and ESIX, you may get error messages about running out of virtual memory
1353 while compiling certain programs.
1355 You can prevent this problem by linking GCC with the GNU malloc
1356 (which thus replaces the malloc that comes with the system). GNU malloc
1357 is available as a separate package, and also in the file
1358 @file{src/gmalloc.c} in the GNU Emacs 19 distribution.
1360 If you have installed GNU malloc as a separate library package, use this
1361 option when you relink GCC:
1364 MALLOC=/usr/local/lib/libgmalloc.a
1367 Alternatively, if you have compiled @file{gmalloc.c} from Emacs 19, copy
1368 the object file to @file{gmalloc.o} and use this option when you relink
1376 @node Incompatibilities
1377 @section Incompatibilities of GCC
1378 @cindex incompatibilities of GCC
1380 There are several noteworthy incompatibilities between GNU C and K&R
1381 (non-ISO) versions of C. The @samp{-traditional} option
1382 eliminates many of these incompatibilities, @emph{but not all}, by
1383 telling GNU C to behave like a K&R C compiler.
1386 @cindex string constants
1387 @cindex read-only strings
1388 @cindex shared strings
1390 GCC normally makes string constants read-only. If several
1391 identical-looking string constants are used, GCC stores only one
1394 @cindex @code{mktemp}, and constant strings
1395 One consequence is that you cannot call @code{mktemp} with a string
1396 constant argument. The function @code{mktemp} always alters the
1397 string its argument points to.
1399 @cindex @code{sscanf}, and constant strings
1400 @cindex @code{fscanf}, and constant strings
1401 @cindex @code{scanf}, and constant strings
1402 Another consequence is that @code{sscanf} does not work on some systems
1403 when passed a string constant as its format control string or input.
1404 This is because @code{sscanf} incorrectly tries to write into the string
1405 constant. Likewise @code{fscanf} and @code{scanf}.
1407 The best solution to these problems is to change the program to use
1408 @code{char}-array variables with initialization strings for these
1409 purposes instead of string constants. But if this is not possible,
1410 you can use the @samp{-fwritable-strings} flag, which directs GCC
1411 to handle string constants the same way most C compilers do.
1412 @samp{-traditional} also has this effect, among others.
1415 @code{-2147483648} is positive.
1417 This is because 2147483648 cannot fit in the type @code{int}, so
1418 (following the ISO C rules) its data type is @code{unsigned long int}.
1419 Negating this value yields 2147483648 again.
1422 GCC does not substitute macro arguments when they appear inside of
1423 string constants. For example, the following macro in GCC
1430 will produce output @code{"a"} regardless of what the argument @var{a} is.
1432 The @samp{-traditional} option directs GCC to handle such cases
1433 (among others) in the old-fashioned (non-ISO) fashion.
1435 @cindex @code{setjmp} incompatibilities
1436 @cindex @code{longjmp} incompatibilities
1438 When you use @code{setjmp} and @code{longjmp}, the only automatic
1439 variables guaranteed to remain valid are those declared
1440 @code{volatile}. This is a consequence of automatic register
1441 allocation. Consider this function:
1455 /* @r{@code{longjmp (j)} may occur in @code{fun3}.} */
1460 Here @code{a} may or may not be restored to its first value when the
1461 @code{longjmp} occurs. If @code{a} is allocated in a register, then
1462 its first value is restored; otherwise, it keeps the last value stored
1465 If you use the @samp{-W} option with the @samp{-O} option, you will
1466 get a warning when GCC thinks such a problem might be possible.
1468 The @samp{-traditional} option directs GNU C to put variables in
1469 the stack by default, rather than in registers, in functions that
1470 call @code{setjmp}. This results in the behavior found in
1471 traditional C compilers.
1474 Programs that use preprocessing directives in the middle of macro
1475 arguments do not work with GCC. For example, a program like this
1484 ISO C does not permit such a construct. It would make sense to support
1485 it when @samp{-traditional} is used, but it is too much work to
1489 K&R compilers allow comments to cross over an inclusion boundary (i.e.
1490 started in an include file and ended in the including file). I think
1491 this would be quite ugly and can't imagine it could be needed.
1493 @cindex external declaration scope
1494 @cindex scope of external declarations
1495 @cindex declaration scope
1497 Declarations of external variables and functions within a block apply
1498 only to the block containing the declaration. In other words, they
1499 have the same scope as any other declaration in the same place.
1501 In some other C compilers, a @code{extern} declaration affects all the
1502 rest of the file even if it happens within a block.
1504 The @samp{-traditional} option directs GNU C to treat all @code{extern}
1505 declarations as global, like traditional compilers.
1508 In traditional C, you can combine @code{long}, etc., with a typedef name,
1513 typedef long foo bar;
1516 In ISO C, this is not allowed: @code{long} and other type modifiers
1517 require an explicit @code{int}. Because this criterion is expressed
1518 by Bison grammar rules rather than C code, the @samp{-traditional}
1519 flag cannot alter it.
1521 @cindex typedef names as function parameters
1523 PCC allows typedef names to be used as function parameters. The
1524 difficulty described immediately above applies here too.
1527 When in @samp{-traditional} mode, GCC allows the following erroneous
1528 pair of declarations to appear together in a given scope:
1536 GCC treats all characters of identifiers as significant, even when in
1537 @samp{-traditional} mode. According to K&R-1 (2.2), ``No more than the
1538 first eight characters are significant, although more may be used.''.
1539 Also according to K&R-1 (2.2), ``An identifier is a sequence of letters
1540 and digits; the first character must be a letter. The underscore _
1541 counts as a letter.'', but GCC also allows dollar signs in identifiers.
1545 PCC allows whitespace in the middle of compound assignment operators
1546 such as @samp{+=}. GCC, following the ISO standard, does not
1547 allow this. The difficulty described immediately above applies here
1553 GCC complains about unterminated character constants inside of
1554 preprocessing conditionals that fail. Some programs have English
1555 comments enclosed in conditionals that are guaranteed to fail; if these
1556 comments contain apostrophes, GCC will probably report an error. For
1557 example, this code would produce an error:
1561 You can't expect this to work.
1565 The best solution to such a problem is to put the text into an actual
1566 C comment delimited by @samp{/*@dots{}*/}. However,
1567 @samp{-traditional} suppresses these error messages.
1570 Many user programs contain the declaration @samp{long time ();}. In the
1571 past, the system header files on many systems did not actually declare
1572 @code{time}, so it did not matter what type your program declared it to
1573 return. But in systems with ISO C headers, @code{time} is declared to
1574 return @code{time_t}, and if that is not the same as @code{long}, then
1575 @samp{long time ();} is erroneous.
1577 The solution is to change your program to use appropriate system headers
1578 (@code{<time.h>} on systems with ISO C headers) and not to declare
1579 @code{time} if the system header files declare it, or failing that to
1580 use @code{time_t} as the return type of @code{time}.
1582 @cindex @code{float} as function value type
1584 When compiling functions that return @code{float}, PCC converts it to
1585 a double. GCC actually returns a @code{float}. If you are concerned
1586 with PCC compatibility, you should declare your functions to return
1587 @code{double}; you might as well say what you mean.
1592 When compiling functions that return structures or unions, GCC
1593 output code normally uses a method different from that used on most
1594 versions of Unix. As a result, code compiled with GCC cannot call
1595 a structure-returning function compiled with PCC, and vice versa.
1597 The method used by GCC is as follows: a structure or union which is
1598 1, 2, 4 or 8 bytes long is returned like a scalar. A structure or union
1599 with any other size is stored into an address supplied by the caller
1600 (usually in a special, fixed register, but on some machines it is passed
1601 on the stack). The machine-description macros @code{STRUCT_VALUE} and
1602 @code{STRUCT_INCOMING_VALUE} tell GCC where to pass this address.
1604 By contrast, PCC on most target machines returns structures and unions
1605 of any size by copying the data into an area of static storage, and then
1606 returning the address of that storage as if it were a pointer value.
1607 The caller must copy the data from that memory area to the place where
1608 the value is wanted. GCC does not use this method because it is
1609 slower and nonreentrant.
1611 On some newer machines, PCC uses a reentrant convention for all
1612 structure and union returning. GCC on most of these machines uses a
1613 compatible convention when returning structures and unions in memory,
1614 but still returns small structures and unions in registers.
1616 You can tell GCC to use a compatible convention for all structure and
1617 union returning with the option @samp{-fpcc-struct-return}.
1619 @cindex preprocessing tokens
1620 @cindex preprocessing numbers
1622 GNU C complains about program fragments such as @samp{0x74ae-0x4000}
1623 which appear to be two hexadecimal constants separated by the minus
1624 operator. Actually, this string is a single @dfn{preprocessing token}.
1625 Each such token must correspond to one token in C. Since this does not,
1626 GNU C prints an error message. Although it may appear obvious that what
1627 is meant is an operator and two values, the ISO C standard specifically
1628 requires that this be treated as erroneous.
1630 A @dfn{preprocessing token} is a @dfn{preprocessing number} if it
1631 begins with a digit and is followed by letters, underscores, digits,
1632 periods and @samp{e+}, @samp{e-}, @samp{E+}, or @samp{E-} character
1635 To make the above program fragment valid, place whitespace in front of
1636 the minus sign. This whitespace will end the preprocessing number.
1640 @section Fixed Header Files
1642 GCC needs to install corrected versions of some system header files.
1643 This is because most target systems have some header files that won't
1644 work with GCC unless they are changed. Some have bugs, some are
1645 incompatible with ISO C, and some depend on special features of other
1648 Installing GCC automatically creates and installs the fixed header
1649 files, by running a program called @code{fixincludes} (or for certain
1650 targets an alternative such as @code{fixinc.svr4}). Normally, you
1651 don't need to pay attention to this. But there are cases where it
1652 doesn't do the right thing automatically.
1656 If you update the system's header files, such as by installing a new
1657 system version, the fixed header files of GCC are not automatically
1658 updated. The easiest way to update them is to reinstall GCC. (If
1659 you want to be clever, look in the makefile and you can find a
1663 On some systems, in particular SunOS 4, header file directories contain
1664 machine-specific symbolic links in certain places. This makes it
1665 possible to share most of the header files among hosts running the
1666 same version of SunOS 4 on different machine models.
1668 The programs that fix the header files do not understand this special
1669 way of using symbolic links; therefore, the directory of fixed header
1670 files is good only for the machine model used to build it.
1672 In SunOS 4, only programs that look inside the kernel will notice the
1673 difference between machine models. Therefore, for most purposes, you
1674 need not be concerned about this.
1676 It is possible to make separate sets of fixed header files for the
1677 different machine models, and arrange a structure of symbolic links so
1678 as to use the proper set, but you'll have to do this by hand.
1681 On Lynxos, GCC by default does not fix the header files. This is
1682 because bugs in the shell cause the @code{fixincludes} script to fail.
1684 This means you will encounter problems due to bugs in the system header
1685 files. It may be no comfort that they aren't GCC's fault, but it
1686 does mean that there's nothing for us to do about them.
1689 @node Standard Libraries
1690 @section Standard Libraries
1692 GCC by itself attempts to be a conforming freestanding implementation.
1693 @xref{Standards,,Language Standards Supported by GCC}, for details of
1694 what this means. Beyond the library facilities required of such an
1695 implementation, the rest of the C library is supplied by the vendor of
1696 the operating system. If that C library doesn't conform to the C
1697 standards, then your programs might get warnings (especially when using
1698 @samp{-Wall}) that you don't expect.
1700 For example, the @code{sprintf} function on SunOS 4.1.3 returns
1701 @code{char *} while the C standard says that @code{sprintf} returns an
1702 @code{int}. The @code{fixincludes} program could make the prototype for
1703 this function match the Standard, but that would be wrong, since the
1704 function will still return @code{char *}.
1706 If you need a Standard compliant library, then you need to find one, as
1707 GCC does not provide one. The GNU C library (called @code{glibc})
1708 provides ISO C, POSIX, BSD, SystemV and X/Open compatibility for
1709 GNU/Linux and HURD-based GNU systems; no recent version of it supports
1710 other systems, though some very old versions did. Version 2.2 of the
1711 GNU C library includes nearly complete C99 support. You could also ask
1712 your operating system vendor if newer libraries are available.
1714 @node Disappointments
1715 @section Disappointments and Misunderstandings
1717 These problems are perhaps regrettable, but we don't know any practical
1722 Certain local variables aren't recognized by debuggers when you compile
1725 This occurs because sometimes GCC optimizes the variable out of
1726 existence. There is no way to tell the debugger how to compute the
1727 value such a variable ``would have had'', and it is not clear that would
1728 be desirable anyway. So GCC simply does not mention the eliminated
1729 variable when it writes debugging information.
1731 You have to expect a certain amount of disagreement between the
1732 executable and your source code, when you use optimization.
1734 @cindex conflicting types
1735 @cindex scope of declaration
1737 Users often think it is a bug when GCC reports an error for code
1741 int foo (struct mumble *);
1743 struct mumble @{ @dots{} @};
1745 int foo (struct mumble *x)
1749 This code really is erroneous, because the scope of @code{struct
1750 mumble} in the prototype is limited to the argument list containing it.
1751 It does not refer to the @code{struct mumble} defined with file scope
1752 immediately below---they are two unrelated types with similar names in
1755 But in the definition of @code{foo}, the file-scope type is used
1756 because that is available to be inherited. Thus, the definition and
1757 the prototype do not match, and you get an error.
1759 This behavior may seem silly, but it's what the ISO standard specifies.
1760 It is easy enough for you to make your code work by moving the
1761 definition of @code{struct mumble} above the prototype. It's not worth
1762 being incompatible with ISO C just to avoid an error for the example
1766 Accesses to bitfields even in volatile objects works by accessing larger
1767 objects, such as a byte or a word. You cannot rely on what size of
1768 object is accessed in order to read or write the bitfield; it may even
1769 vary for a given bitfield according to the precise usage.
1771 If you care about controlling the amount of memory that is accessed, use
1772 volatile but do not use bitfields.
1775 GCC comes with shell scripts to fix certain known problems in system
1776 header files. They install corrected copies of various header files in
1777 a special directory where only GCC will normally look for them. The
1778 scripts adapt to various systems by searching all the system header
1779 files for the problem cases that we know about.
1781 If new system header files are installed, nothing automatically arranges
1782 to update the corrected header files. You will have to reinstall GCC
1783 to fix the new header files. More specifically, go to the build
1784 directory and delete the files @file{stmp-fixinc} and
1785 @file{stmp-headers}, and the subdirectory @code{include}; then do
1786 @samp{make install} again.
1789 @cindex floating point precision
1790 On 68000 and x86 systems, for instance, you can get paradoxical results
1791 if you test the precise values of floating point numbers. For example,
1792 you can find that a floating point value which is not a NaN is not equal
1793 to itself. This results from the fact that the floating point registers
1794 hold a few more bits of precision than fit in a @code{double} in memory.
1795 Compiled code moves values between memory and floating point registers
1796 at its convenience, and moving them into memory truncates them.
1798 You can partially avoid this problem by using the @samp{-ffloat-store}
1799 option (@pxref{Optimize Options}).
1802 On the MIPS, variable argument functions using @file{varargs.h}
1803 cannot have a floating point value for the first argument. The
1804 reason for this is that in the absence of a prototype in scope,
1805 if the first argument is a floating point, it is passed in a
1806 floating point register, rather than an integer register.
1808 If the code is rewritten to use the ISO standard @file{stdarg.h}
1809 method of variable arguments, and the prototype is in scope at
1810 the time of the call, everything will work fine.
1813 On the H8/300 and H8/300H, variable argument functions must be
1814 implemented using the ISO standard @file{stdarg.h} method of
1815 variable arguments. Furthermore, calls to functions using @file{stdarg.h}
1816 variable arguments must have a prototype for the called function
1817 in scope at the time of the call.
1820 @node C++ Misunderstandings
1821 @section Common Misunderstandings with GNU C++
1823 @cindex misunderstandings in C++
1824 @cindex surprises in C++
1825 @cindex C++ misunderstandings
1826 C++ is a complex language and an evolving one, and its standard
1827 definition (the ISO C++ standard) was only recently completed. As a
1828 result, your C++ compiler may occasionally surprise you, even when its
1829 behavior is correct. This section discusses some areas that frequently
1830 give rise to questions of this sort.
1833 * Static Definitions:: Static member declarations are not definitions
1834 * Temporaries:: Temporaries may vanish before you expect
1835 * Copy Assignment:: Copy Assignment operators copy virtual bases twice
1838 @node Static Definitions
1839 @subsection Declare @emph{and} Define Static Members
1841 @cindex C++ static data, declaring and defining
1842 @cindex static data in C++, declaring and defining
1843 @cindex declaring static data in C++
1844 @cindex defining static data in C++
1845 When a class has static data members, it is not enough to @emph{declare}
1846 the static member; you must also @emph{define} it. For example:
1857 This declaration only establishes that the class @code{Foo} has an
1858 @code{int} named @code{Foo::bar}, and a member function named
1859 @code{Foo::method}. But you still need to define @emph{both}
1860 @code{method} and @code{bar} elsewhere. According to the ISO
1861 standard, you must supply an initializer in one (and only one) source
1868 Other C++ compilers may not correctly implement the standard behavior.
1869 As a result, when you switch to @code{g++} from one of these compilers,
1870 you may discover that a program that appeared to work correctly in fact
1871 does not conform to the standard: @code{g++} reports as undefined
1872 symbols any static data members that lack definitions.
1875 @subsection Temporaries May Vanish Before You Expect
1877 @cindex temporaries, lifetime of
1878 @cindex portions of temporary objects, pointers to
1879 It is dangerous to use pointers or references to @emph{portions} of a
1880 temporary object. The compiler may very well delete the object before
1881 you expect it to, leaving a pointer to garbage. The most common place
1882 where this problem crops up is in classes like string classes,
1883 especially ones that define a conversion function to type @code{char *}
1884 or @code{const char *} -- which is one reason why the standard
1885 @code{string} class requires you to call the @code{c_str} member
1886 function. However, any class that returns a pointer to some internal
1887 structure is potentially subject to this problem.
1889 For example, a program may use a function @code{strfunc} that returns
1890 @code{string} objects, and another function @code{charfunc} that
1891 operates on pointers to @code{char}:
1895 void charfunc (const char *);
1900 const char *p = strfunc().c_str();
1909 In this situation, it may seem reasonable to save a pointer to the C
1910 string returned by the @code{c_str} member function and use that rather
1911 than call @code{c_str} repeatedly. However, the temporary string
1912 created by the call to @code{strfunc} is destroyed after @code{p} is
1913 initialized, at which point @code{p} is left pointing to freed memory.
1915 Code like this may run successfully under some other compilers,
1916 particularly obsolete cfront-based compilers that delete temporaries
1917 along with normal local variables. However, the GNU C++ behavior is
1918 standard-conforming, so if your program depends on late destruction of
1919 temporaries it is not portable.
1921 The safe way to write such code is to give the temporary a name, which
1922 forces it to remain until the end of the scope of the name. For
1926 string& tmp = strfunc ();
1927 charfunc (tmp.c_str ());
1930 @node Copy Assignment
1931 @subsection Implicit Copy-Assignment for Virtual Bases
1933 When a base class is virtual, only one subobject of the base class
1934 belongs to each full object. Also, the constructors and destructors are
1935 invoked only once, and called from the most-derived class. However, such
1936 objects behave unspecified when being assigned. For example:
1941 Base(char *n) : name(strdup(n))@{@}
1942 Base& operator= (const Base& other)@{
1944 name = strdup (other.name);
1948 struct A:virtual Base@{
1953 struct B:virtual Base@{
1958 struct Derived:public A, public B@{
1959 Derived():Base("Derived")@{@}
1962 void func(Derived &d1, Derived &d2)
1968 The C++ standard specifies that @samp{Base::Base} is only called once
1969 when constructing or copy-constructing a Derived object. It is
1970 unspecified whether @samp{Base::operator=} is called more than once when
1971 the implicit copy-assignment for Derived objects is invoked (as it is
1972 inside @samp{func} in the example).
1974 g++ implements the "intuitive" algorithm for copy-assignment: assign all
1975 direct bases, then assign all members. In that algorithm, the virtual
1976 base subobject can be encountered many times. In the example, copying
1977 proceeds in the following order: @samp{val}, @samp{name} (via
1978 @code{strdup}), @samp{bval}, and @samp{name} again.
1980 If application code relies on copy-assignment, a user-defined
1981 copy-assignment operator removes any uncertainties. With such an
1982 operator, the application can define whether and how the virtual base
1983 subobject is assigned.
1985 @node Protoize Caveats
1986 @section Caveats of using @code{protoize}
1988 The conversion programs @code{protoize} and @code{unprotoize} can
1989 sometimes change a source file in a way that won't work unless you
1994 @code{protoize} can insert references to a type name or type tag before
1995 the definition, or in a file where they are not defined.
1997 If this happens, compiler error messages should show you where the new
1998 references are, so fixing the file by hand is straightforward.
2001 There are some C constructs which @code{protoize} cannot figure out.
2002 For example, it can't determine argument types for declaring a
2003 pointer-to-function variable; this you must do by hand. @code{protoize}
2004 inserts a comment containing @samp{???} each time it finds such a
2005 variable; so you can find all such variables by searching for this
2006 string. ISO C does not require declaring the argument types of
2007 pointer-to-function types.
2010 Using @code{unprotoize} can easily introduce bugs. If the program
2011 relied on prototypes to bring about conversion of arguments, these
2012 conversions will not take place in the program without prototypes.
2013 One case in which you can be sure @code{unprotoize} is safe is when
2014 you are removing prototypes that were made with @code{protoize}; if
2015 the program worked before without any prototypes, it will work again
2018 You can find all the places where this problem might occur by compiling
2019 the program with the @samp{-Wconversion} option. It prints a warning
2020 whenever an argument is converted.
2023 Both conversion programs can be confused if there are macro calls in and
2024 around the text to be converted. In other words, the standard syntax
2025 for a declaration or definition must not result from expanding a macro.
2026 This problem is inherent in the design of C and cannot be fixed. If
2027 only a few functions have confusing macro calls, you can easily convert
2031 @code{protoize} cannot get the argument types for a function whose
2032 definition was not actually compiled due to preprocessing conditionals.
2033 When this happens, @code{protoize} changes nothing in regard to such
2034 a function. @code{protoize} tries to detect such instances and warn
2037 You can generally work around this problem by using @code{protoize} step
2038 by step, each time specifying a different set of @samp{-D} options for
2039 compilation, until all of the functions have been converted. There is
2040 no automatic way to verify that you have got them all, however.
2043 Confusion may result if there is an occasion to convert a function
2044 declaration or definition in a region of source code where there is more
2045 than one formal parameter list present. Thus, attempts to convert code
2046 containing multiple (conditionally compiled) versions of a single
2047 function header (in the same vicinity) may not produce the desired (or
2050 If you plan on converting source files which contain such code, it is
2051 recommended that you first make sure that each conditionally compiled
2052 region of source code which contains an alternative function header also
2053 contains at least one additional follower token (past the final right
2054 parenthesis of the function header). This should circumvent the
2058 @code{unprotoize} can become confused when trying to convert a function
2059 definition or declaration which contains a declaration for a
2060 pointer-to-function formal argument which has the same name as the
2061 function being defined or declared. We recommend you avoid such choices
2062 of formal parameter names.
2065 You might also want to correct some of the indentation by hand and break
2066 long lines. (The conversion programs don't write lines longer than
2067 eighty characters in any case.)
2071 @section Certain Changes We Don't Want to Make
2073 This section lists changes that people frequently request, but which
2074 we do not make because we think GCC is better without them.
2078 Checking the number and type of arguments to a function which has an
2079 old-fashioned definition and no prototype.
2081 Such a feature would work only occasionally---only for calls that appear
2082 in the same file as the called function, following the definition. The
2083 only way to check all calls reliably is to add a prototype for the
2084 function. But adding a prototype eliminates the motivation for this
2085 feature. So the feature is not worthwhile.
2088 Warning about using an expression whose type is signed as a shift count.
2090 Shift count operands are probably signed more often than unsigned.
2091 Warning about this would cause far more annoyance than good.
2094 Warning about assigning a signed value to an unsigned variable.
2096 Such assignments must be very common; warning about them would cause
2097 more annoyance than good.
2100 Warning when a non-void function value is ignored.
2102 Coming as I do from a Lisp background, I balk at the idea that there is
2103 something dangerous about discarding a value. There are functions that
2104 return values which some callers may find useful; it makes no sense to
2105 clutter the program with a cast to @code{void} whenever the value isn't
2109 Assuming (for optimization) that the address of an external symbol is
2112 This assumption is false on certain systems when @samp{#pragma weak} is
2116 Making @samp{-fshort-enums} the default.
2118 This would cause storage layout to be incompatible with most other C
2119 compilers. And it doesn't seem very important, given that you can get
2120 the same result in other ways. The case where it matters most is when
2121 the enumeration-valued object is inside a structure, and in that case
2122 you can specify a field width explicitly.
2125 Making bitfields unsigned by default on particular machines where ``the
2126 ABI standard'' says to do so.
2128 The ISO C standard leaves it up to the implementation whether a bitfield
2129 declared plain @code{int} is signed or not. This in effect creates two
2130 alternative dialects of C.
2132 The GNU C compiler supports both dialects; you can specify the signed
2133 dialect with @samp{-fsigned-bitfields} and the unsigned dialect with
2134 @samp{-funsigned-bitfields}. However, this leaves open the question of
2135 which dialect to use by default.
2137 Currently, the preferred dialect makes plain bitfields signed, because
2138 this is simplest. Since @code{int} is the same as @code{signed int} in
2139 every other context, it is cleanest for them to be the same in bitfields
2142 Some computer manufacturers have published Application Binary Interface
2143 standards which specify that plain bitfields should be unsigned. It is
2144 a mistake, however, to say anything about this issue in an ABI. This is
2145 because the handling of plain bitfields distinguishes two dialects of C.
2146 Both dialects are meaningful on every type of machine. Whether a
2147 particular object file was compiled using signed bitfields or unsigned
2148 is of no concern to other object files, even if they access the same
2149 bitfields in the same data structures.
2151 A given program is written in one or the other of these two dialects.
2152 The program stands a chance to work on most any machine if it is
2153 compiled with the proper dialect. It is unlikely to work at all if
2154 compiled with the wrong dialect.
2156 Many users appreciate the GNU C compiler because it provides an
2157 environment that is uniform across machines. These users would be
2158 inconvenienced if the compiler treated plain bitfields differently on
2161 Occasionally users write programs intended only for a particular machine
2162 type. On these occasions, the users would benefit if the GNU C compiler
2163 were to support by default the same dialect as the other compilers on
2164 that machine. But such applications are rare. And users writing a
2165 program to run on more than one type of machine cannot possibly benefit
2166 from this kind of compatibility.
2168 This is why GCC does and will treat plain bitfields in the same
2169 fashion on all types of machines (by default).
2171 There are some arguments for making bitfields unsigned by default on all
2172 machines. If, for example, this becomes a universal de facto standard,
2173 it would make sense for GCC to go along with it. This is something
2174 to be considered in the future.
2176 (Of course, users strongly concerned about portability should indicate
2177 explicitly in each bitfield whether it is signed or not. In this way,
2178 they write programs which have the same meaning in both C dialects.)
2181 Undefining @code{__STDC__} when @samp{-ansi} is not used.
2183 Currently, GCC defines @code{__STDC__} as long as you don't use
2184 @samp{-traditional}. This provides good results in practice.
2186 Programmers normally use conditionals on @code{__STDC__} to ask whether
2187 it is safe to use certain features of ISO C, such as function
2188 prototypes or ISO token concatenation. Since plain @samp{gcc} supports
2189 all the features of ISO C, the correct answer to these questions is
2192 Some users try to use @code{__STDC__} to check for the availability of
2193 certain library facilities. This is actually incorrect usage in an ISO
2194 C program, because the ISO C standard says that a conforming
2195 freestanding implementation should define @code{__STDC__} even though it
2196 does not have the library facilities. @samp{gcc -ansi -pedantic} is a
2197 conforming freestanding implementation, and it is therefore required to
2198 define @code{__STDC__}, even though it does not come with an ISO C
2201 Sometimes people say that defining @code{__STDC__} in a compiler that
2202 does not completely conform to the ISO C standard somehow violates the
2203 standard. This is illogical. The standard is a standard for compilers
2204 that claim to support ISO C, such as @samp{gcc -ansi}---not for other
2205 compilers such as plain @samp{gcc}. Whatever the ISO C standard says
2206 is relevant to the design of plain @samp{gcc} without @samp{-ansi} only
2207 for pragmatic reasons, not as a requirement.
2209 GCC normally defines @code{__STDC__} to be 1, and in addition
2210 defines @code{__STRICT_ANSI__} if you specify the @option{-ansi} option,
2211 or a @option{-std} option for strict conformance to some version of ISO C.
2212 On some hosts, system include files use a different convention, where
2213 @code{__STDC__} is normally 0, but is 1 if the user specifies strict
2214 conformance to the C Standard. GCC follows the host convention when
2215 processing system include files, but when processing user files it follows
2216 the usual GNU C convention.
2219 Undefining @code{__STDC__} in C++.
2221 Programs written to compile with C++-to-C translators get the
2222 value of @code{__STDC__} that goes with the C compiler that is
2223 subsequently used. These programs must test @code{__STDC__}
2224 to determine what kind of C preprocessor that compiler uses:
2225 whether they should concatenate tokens in the ISO C fashion
2226 or in the traditional fashion.
2228 These programs work properly with GNU C++ if @code{__STDC__} is defined.
2229 They would not work otherwise.
2231 In addition, many header files are written to provide prototypes in ISO
2232 C but not in traditional C. Many of these header files can work without
2233 change in C++ provided @code{__STDC__} is defined. If @code{__STDC__}
2234 is not defined, they will all fail, and will all need to be changed to
2235 test explicitly for C++ as well.
2238 Deleting ``empty'' loops.
2240 Historically, GCC has not deleted ``empty'' loops under the
2241 assumption that the most likely reason you would put one in a program is
2242 to have a delay, so deleting them will not make real programs run any
2245 However, the rationale here is that optimization of a nonempty loop
2246 cannot produce an empty one, which holds for C but is not always the
2249 Moreover, with @samp{-funroll-loops} small ``empty'' loops are already
2250 removed, so the current behavior is both sub-optimal and inconsistent
2251 and will change in the future.
2254 Making side effects happen in the same order as in some other compiler.
2256 @cindex side effects, order of evaluation
2257 @cindex order of evaluation, side effects
2258 It is never safe to depend on the order of evaluation of side effects.
2259 For example, a function call like this may very well behave differently
2260 from one compiler to another:
2263 void func (int, int);
2269 There is no guarantee (in either the C or the C++ standard language
2270 definitions) that the increments will be evaluated in any particular
2271 order. Either increment might happen first. @code{func} might get the
2272 arguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}.
2275 Not allowing structures with volatile fields in registers.
2277 Strictly speaking, there is no prohibition in the ISO C standard
2278 against allowing structures with volatile fields in registers, but
2279 it does not seem to make any sense and is probably not what you wanted
2280 to do. So the compiler will give an error message in this case.
2283 Making certain warnings into errors by default.
2285 Some ISO C testsuites report failure when the compiler does not produce
2286 an error message for a certain program.
2288 ISO C requires a ``diagnostic'' message for certain kinds of invalid
2289 programs, but a warning is defined by GCC to count as a diagnostic. If
2290 GCC produces a warning but not an error, that is correct ISO C support.
2291 If test suites call this ``failure'', they should be run with the GCC
2292 option @samp{-pedantic-errors}, which will turn these warnings into
2297 @node Warnings and Errors
2298 @section Warning Messages and Error Messages
2300 @cindex error messages
2301 @cindex warnings vs errors
2302 @cindex messages, warning and error
2303 The GNU compiler can produce two kinds of diagnostics: errors and
2304 warnings. Each kind has a different purpose:
2308 @emph{Errors} report problems that make it impossible to compile your
2309 program. GCC reports errors with the source file name and line
2310 number where the problem is apparent.
2313 @emph{Warnings} report other unusual conditions in your code that
2314 @emph{may} indicate a problem, although compilation can (and does)
2315 proceed. Warning messages also report the source file name and line
2316 number, but include the text @samp{warning:} to distinguish them
2317 from error messages.
2320 Warnings may indicate danger points where you should check to make sure
2321 that your program really does what you intend; or the use of obsolete
2322 features; or the use of nonstandard features of GNU C or C++. Many
2323 warnings are issued only if you ask for them, with one of the @samp{-W}
2324 options (for instance, @samp{-Wall} requests a variety of useful
2327 GCC always tries to compile your program if possible; it never
2328 gratuitously rejects a program whose meaning is clear merely because
2329 (for instance) it fails to conform to a standard. In some cases,
2330 however, the C and C++ standards specify that certain extensions are
2331 forbidden, and a diagnostic @emph{must} be issued by a conforming
2332 compiler. The @samp{-pedantic} option tells GCC to issue warnings in
2333 such cases; @samp{-pedantic-errors} says to make them errors instead.
2334 This does not mean that @emph{all} non-ISO constructs get warnings
2337 @xref{Warning Options,,Options to Request or Suppress Warnings}, for
2338 more detail on these and related command-line options.
2341 @chapter Reporting Bugs
2343 @cindex reporting bugs
2345 Your bug reports play an essential role in making GCC reliable.
2347 When you encounter a problem, the first thing to do is to see if it is
2348 already known. @xref{Trouble}. If it isn't known, then you should
2351 Reporting a bug may help you by bringing a solution to your problem, or
2352 it may not. (If it does not, look in the service directory; see
2353 @ref{Service}.) In any case, the principal function of a bug report is
2354 to help the entire community by making the next version of GCC work
2355 better. Bug reports are your contribution to the maintenance of GCC.
2357 Since the maintainers are very overloaded, we cannot respond to every
2358 bug report. However, if the bug has not been fixed, we are likely to
2359 send you a patch and ask you to tell us whether it works.
2361 In order for a bug report to serve its purpose, you must include the
2362 information that makes for fixing the bug.
2365 * Criteria: Bug Criteria. Have you really found a bug?
2366 * Where: Bug Lists. Where to send your bug report.
2367 * Reporting: Bug Reporting. How to report a bug effectively.
2368 * GNATS: gccbug. You can use a bug reporting tool.
2369 * Patches: Sending Patches. How to send a patch for GCC.
2370 * Known: Trouble. Known problems.
2371 * Help: Service. Where to ask for help.
2374 @node Bug Criteria,Bug Lists,,Bugs
2375 @section Have You Found a Bug?
2376 @cindex bug criteria
2378 If you are not sure whether you have found a bug, here are some guidelines:
2381 @cindex fatal signal
2384 If the compiler gets a fatal signal, for any input whatever, that is a
2385 compiler bug. Reliable compilers never crash.
2387 @cindex invalid assembly code
2388 @cindex assembly code, invalid
2390 If the compiler produces invalid assembly code, for any input whatever
2391 (except an @code{asm} statement), that is a compiler bug, unless the
2392 compiler reports errors (not just warnings) which would ordinarily
2393 prevent the assembler from being run.
2395 @cindex undefined behavior
2396 @cindex undefined function value
2397 @cindex increment operators
2399 If the compiler produces valid assembly code that does not correctly
2400 execute the input source code, that is a compiler bug.
2402 However, you must double-check to make sure, because you may have run
2403 into an incompatibility between GNU C and traditional C
2404 (@pxref{Incompatibilities}). These incompatibilities might be considered
2405 bugs, but they are inescapable consequences of valuable features.
2407 Or you may have a program whose behavior is undefined, which happened
2408 by chance to give the desired results with another C or C++ compiler.
2410 For example, in many nonoptimizing compilers, you can write @samp{x;}
2411 at the end of a function instead of @samp{return x;}, with the same
2412 results. But the value of the function is undefined if @code{return}
2413 is omitted; it is not a bug when GCC produces different results.
2415 Problems often result from expressions with two increment operators,
2416 as in @code{f (*p++, *p++)}. Your previous compiler might have
2417 interpreted that expression the way you intended; GCC might
2418 interpret it another way. Neither compiler is wrong. The bug is
2421 After you have localized the error to a single source line, it should
2422 be easy to check for these things. If your program is correct and
2423 well defined, you have found a compiler bug.
2426 If the compiler produces an error message for valid input, that is a
2429 @cindex invalid input
2431 If the compiler does not produce an error message for invalid input,
2432 that is a compiler bug. However, you should note that your idea of
2433 ``invalid input'' might be my idea of ``an extension'' or ``support
2434 for traditional practice''.
2437 If you are an experienced user of one of the languages GCC supports, your
2438 suggestions for improvement of GCC are welcome in any case.
2441 @node Bug Lists,Bug Reporting,Bug Criteria,Bugs
2442 @section Where to Report Bugs
2443 @cindex bug report mailing lists
2444 @kindex gcc-bugs@@gcc.gnu.org or bug-gcc@@gnu.org
2445 Send bug reports for the GNU Compiler Collection to
2446 @email{gcc-bugs@@gcc.gnu.org}. In accordance with the GNU-wide
2447 convention, in which bug reports for tool ``foo'' are sent
2448 to @samp{bug-foo@@gnu.org}, the address @email{bug-gcc@@gnu.org}
2449 may also be used; it will forward to the address given above.
2451 Please read @uref{http://www.gnu.org/software/gcc/bugs.html} for
2452 bug reporting instructions before you post a bug report.
2454 Often people think of posting bug reports to the newsgroup instead of
2455 mailing them. This appears to work, but it has one problem which can be
2456 crucial: a newsgroup posting does not contain a mail path back to the
2457 sender. Thus, if maintainers need more information, they may be unable
2458 to reach you. For this reason, you should always send bug reports by
2459 mail to the proper mailing list.
2461 As a last resort, send bug reports on paper to:
2465 Free Software Foundation
2466 59 Temple Place - Suite 330
2467 Boston, MA 02111-1307, USA
2470 @node Bug Reporting,gccbug,Bug Lists,Bugs
2471 @section How to Report Bugs
2472 @cindex compiler bugs, reporting
2474 You may find additional and/or more up-to-date instructions at
2475 @uref{http://www.gnu.org/software/gcc/bugs.html}.
2477 The fundamental principle of reporting bugs usefully is this:
2478 @strong{report all the facts}. If you are not sure whether to state a
2479 fact or leave it out, state it!
2481 Often people omit facts because they think they know what causes the
2482 problem and they conclude that some details don't matter. Thus, you might
2483 assume that the name of the variable you use in an example does not matter.
2484 Well, probably it doesn't, but one cannot be sure. Perhaps the bug is a
2485 stray memory reference which happens to fetch from the location where that
2486 name is stored in memory; perhaps, if the name were different, the contents
2487 of that location would fool the compiler into doing the right thing despite
2488 the bug. Play it safe and give a specific, complete example. That is the
2489 easiest thing for you to do, and the most helpful.
2491 Keep in mind that the purpose of a bug report is to enable someone to
2492 fix the bug if it is not known. It isn't very important what happens if
2493 the bug is already known. Therefore, always write your bug reports on
2494 the assumption that the bug is not known.
2496 Sometimes people give a few sketchy facts and ask, ``Does this ring a
2497 bell?'' This cannot help us fix a bug, so it is basically useless. We
2498 respond by asking for enough details to enable us to investigate.
2499 You might as well expedite matters by sending them to begin with.
2501 Try to make your bug report self-contained. If we have to ask you for
2502 more information, it is best if you include all the previous information
2503 in your response, as well as the information that was missing.
2505 Please report each bug in a separate message. This makes it easier for
2506 us to track which bugs have been fixed and to forward your bugs reports
2507 to the appropriate maintainer.
2509 To enable someone to investigate the bug, you should include all these
2514 The version of GCC. You can get this by running it with the
2517 Without this, we won't know whether there is any point in looking for
2518 the bug in the current version of GCC.
2521 A complete input file that will reproduce the bug. If the bug is in the
2522 C preprocessor, send a source file and any header files that it
2523 requires. If the bug is in the compiler proper (@file{cc1}), send the
2524 preprocessor output generated by adding @samp{-save-temps} to the
2525 compilation command (@pxref{Debugging Options}). When you do this, use
2526 the same @samp{-I}, @samp{-D} or @samp{-U} options that you used in
2527 actual compilation. Then send the @var{input}.i or @var{input}.ii files
2530 A single statement is not enough of an example. In order to compile it,
2531 it must be embedded in a complete file of compiler input; and the bug
2532 might depend on the details of how this is done.
2534 Without a real example one can compile, all anyone can do about your bug
2535 report is wish you luck. It would be futile to try to guess how to
2536 provoke the bug. For example, bugs in register allocation and reloading
2537 frequently depend on every little detail of the function they happen in.
2539 Even if the input file that fails comes from a GNU program, you should
2540 still send the complete test case. Don't ask the GCC maintainers to
2541 do the extra work of obtaining the program in question---they are all
2542 overworked as it is. Also, the problem may depend on what is in the
2543 header files on your system; it is unreliable for the GCC maintainers
2544 to try the problem with the header files available to them. By sending
2545 CPP output, you can eliminate this source of uncertainty and save us
2546 a certain percentage of wild goose chases.
2549 The command arguments you gave GCC to compile that example
2550 and observe the bug. For example, did you use @samp{-O}? To guarantee
2551 you won't omit something important, list all the options.
2553 If we were to try to guess the arguments, we would probably guess wrong
2554 and then we would not encounter the bug.
2557 The type of machine you are using, and the operating system name and
2561 The operands you gave to the @code{configure} command when you installed
2565 A complete list of any modifications you have made to the compiler
2566 source. (We don't promise to investigate the bug unless it happens in
2567 an unmodified compiler. But if you've made modifications and don't tell
2568 us, then you are sending us on a wild goose chase.)
2570 Be precise about these changes. A description in English is not
2571 enough---send a context diff for them.
2573 Adding files of your own (such as a machine description for a machine we
2574 don't support) is a modification of the compiler source.
2577 Details of any other deviations from the standard procedure for installing
2581 A description of what behavior you observe that you believe is
2582 incorrect. For example, ``The compiler gets a fatal signal,'' or,
2583 ``The assembler instruction at line 208 in the output is incorrect.''
2585 Of course, if the bug is that the compiler gets a fatal signal, then one
2586 can't miss it. But if the bug is incorrect output, the maintainer might
2587 not notice unless it is glaringly wrong. None of us has time to study
2588 all the assembler code from a 50-line C program just on the chance that
2589 one instruction might be wrong. We need @emph{you} to do this part!
2591 Even if the problem you experience is a fatal signal, you should still
2592 say so explicitly. Suppose something strange is going on, such as, your
2593 copy of the compiler is out of synch, or you have encountered a bug in
2594 the C library on your system. (This has happened!) Your copy might
2595 crash and the copy here would not. If you @i{said} to expect a crash,
2596 then when the compiler here fails to crash, we would know that the bug
2597 was not happening. If you don't say to expect a crash, then we would
2598 not know whether the bug was happening. We would not be able to draw
2599 any conclusion from our observations.
2601 If the problem is a diagnostic when compiling GCC with some other
2602 compiler, say whether it is a warning or an error.
2604 Often the observed symptom is incorrect output when your program is run.
2605 Sad to say, this is not enough information unless the program is short
2606 and simple. None of us has time to study a large program to figure out
2607 how it would work if compiled correctly, much less which line of it was
2608 compiled wrong. So you will have to do that. Tell us which source line
2609 it is, and what incorrect result happens when that line is executed. A
2610 person who understands the program can find this as easily as finding a
2611 bug in the program itself.
2614 If you send examples of assembler code output from GCC,
2615 please use @samp{-g} when you make them. The debugging information
2616 includes source line numbers which are essential for correlating the
2617 output with the input.
2620 If you wish to mention something in the GCC source, refer to it by
2621 context, not by line number.
2623 The line numbers in the development sources don't match those in your
2624 sources. Your line numbers would convey no useful information to the
2628 Additional information from a debugger might enable someone to find a
2629 problem on a machine which he does not have available. However, you
2630 need to think when you collect this information if you want it to have
2631 any chance of being useful.
2633 @cindex backtrace for bug reports
2634 For example, many people send just a backtrace, but that is never
2635 useful by itself. A simple backtrace with arguments conveys little
2636 about GCC because the compiler is largely data-driven; the same
2637 functions are called over and over for different RTL insns, doing
2638 different things depending on the details of the insn.
2640 Most of the arguments listed in the backtrace are useless because they
2641 are pointers to RTL list structure. The numeric values of the
2642 pointers, which the debugger prints in the backtrace, have no
2643 significance whatever; all that matters is the contents of the objects
2644 they point to (and most of the contents are other such pointers).
2646 In addition, most compiler passes consist of one or more loops that
2647 scan the RTL insn sequence. The most vital piece of information about
2648 such a loop---which insn it has reached---is usually in a local variable,
2652 What you need to provide in addition to a backtrace are the values of
2653 the local variables for several stack frames up. When a local
2654 variable or an argument is an RTX, first print its value and then use
2655 the GDB command @code{pr} to print the RTL expression that it points
2656 to. (If GDB doesn't run on your machine, use your debugger to call
2657 the function @code{debug_rtx} with the RTX as an argument.) In
2658 general, whenever a variable is a pointer, its value is no use
2659 without the data it points to.
2662 Here are some things that are not necessary:
2666 A description of the envelope of the bug.
2668 Often people who encounter a bug spend a lot of time investigating
2669 which changes to the input file will make the bug go away and which
2670 changes will not affect it.
2672 This is often time consuming and not very useful, because the way we
2673 will find the bug is by running a single example under the debugger with
2674 breakpoints, not by pure deduction from a series of examples. You might
2675 as well save your time for something else.
2677 Of course, if you can find a simpler example to report @emph{instead} of
2678 the original one, that is a convenience. Errors in the output will be
2679 easier to spot, running under the debugger will take less time, etc.
2680 Most GCC bugs involve just one function, so the most straightforward
2681 way to simplify an example is to delete all the function definitions
2682 except the one where the bug occurs. Those earlier in the file may be
2683 replaced by external declarations if the crucial function depends on
2684 them. (Exception: inline functions may affect compilation of functions
2685 defined later in the file.)
2687 However, simplification is not vital; if you don't want to do this,
2688 report the bug anyway and send the entire test case you used.
2691 In particular, some people insert conditionals @samp{#ifdef BUG} around
2692 a statement which, if removed, makes the bug not happen. These are just
2693 clutter; we won't pay any attention to them anyway. Besides, you should
2694 send us cpp output, and that can't have conditionals.
2697 A patch for the bug.
2699 A patch for the bug is useful if it is a good one. But don't omit the
2700 necessary information, such as the test case, on the assumption that a
2701 patch is all we need. We might see problems with your patch and decide
2702 to fix the problem another way, or we might not understand it at all.
2704 Sometimes with a program as complicated as GCC it is very hard to
2705 construct an example that will make the program follow a certain path
2706 through the code. If you don't send the example, we won't be able to
2707 construct one, so we won't be able to verify that the bug is fixed.
2709 And if we can't understand what bug you are trying to fix, or why your
2710 patch should be an improvement, we won't install it. A test case will
2711 help us to understand.
2713 @xref{Sending Patches}, for guidelines on how to make it easy for us to
2714 understand and install your patches.
2717 A guess about what the bug is or what it depends on.
2719 Such guesses are usually wrong. Even I can't guess right about such
2720 things without first using the debugger to find the facts.
2725 We have no way of examining a core dump for your type of machine
2726 unless we have an identical system---and if we do have one,
2727 we should be able to reproduce the crash ourselves.
2730 @node gccbug,Sending Patches, Bug Reporting, Bugs
2731 @section The gccbug script
2732 @cindex gccbug script
2734 To simplify creation of bug reports, and to allow better tracking of
2735 reports, we use the GNATS bug tracking system. Part of that system is
2736 the @code{gccbug} script. This is a Unix shell script, so you need a
2737 shell to run it. It is normally installed in the same directory where
2738 @code{gcc} is installed.
2740 The gccbug script is derived from send-pr, @pxref{using
2741 send-pr,,Creating new Problem Reports,send-pr,Reporting Problems}. When
2742 invoked, it starts a text editor so you can fill out the various fields
2743 of the report. When the you quit the editor, the report is automatically
2744 send to the bug reporting address.
2746 A number of fields in this bug report form are specific to GCC, and are
2751 @cindex @code{Category} field
2752 @cindex @code{>Category:}
2754 The category of a GCC problem can be one of the following:
2758 A problem with the C compiler proper.
2762 A problem with the C++ compiler.
2766 A problem with the Fortran 77.
2769 A problem with the Java compiler.
2772 A problem with the Objective C compiler.
2775 A problem with the C++ standard library.
2778 A problem with the Fortran 77 library.
2781 A problem with the Objective C library.
2784 The problem occurs only when generating optimized code.
2787 The problem occurs only when generating code for debugging.
2790 The problem is specific to the target architecture.
2793 The problem is independent from target architecture and programming
2797 It is a problem in some other part of the GCC software.
2800 There is a problem with the GCC home page.
2804 @cindex @code{Class} field
2805 @cindex @code{>Class:}
2807 The class of a problem can be one of the following:
2810 @cindex @emph{doc-bug} class
2812 A problem with the documentation.
2814 @cindex @emph{accepts-illegal} class
2815 @item accepts-illegal
2816 GCC fails to reject erroneous code.
2818 @cindex @emph{rejects-legal} class
2820 GCC gives an error message for correct code.
2822 @cindex @emph{wrong-code} class
2824 The machine code generated by gcc is incorrect.
2826 @cindex @emph{ice-on-legal-code} class
2827 @item ice-on-legal-code
2828 GCC gives an Internal Compiler Error (ICE) for correct code.
2830 @cindex @emph{ice-on-illegal-code} class
2831 @item ice-on-illegal-code
2832 GCC gives an ICE instead of reporting an error
2834 @cindex @emph{pessimizes-code} class
2835 @item pessimizes-code
2836 GCC misses an important optimization opportunity.
2838 @cindex @emph{sw-bug} class
2840 A general product problem. (@samp{sw} stands for ``software''.)
2842 @cindex @emph{change-request} class
2843 @item change-request
2844 A request for a change in behavior, etc.
2846 @cindex @emph{support} class
2848 A support problem or question.
2850 @cindex @emph{duplicate} class
2851 @item duplicate (@var{pr-number})
2852 Duplicate PR. @var{pr-number} should be the number of the original PR.
2855 The default is @samp{sw-bug}.
2861 @node Sending Patches,, gccbug, Bugs
2862 @section Sending Patches for GCC
2864 If you would like to write bug fixes or improvements for the GNU C
2865 compiler, that is very helpful. Send suggested fixes to the patches
2866 mailing list, @email{gcc-patches@@gcc.gnu.org}.
2868 Please follow these guidelines so we can study your patches efficiently.
2869 If you don't follow these guidelines, your information might still be
2870 useful, but using it will take extra work. Maintaining GNU C is a lot
2871 of work in the best of circumstances, and we can't keep up unless you do
2876 Send an explanation with your changes of what problem they fix or what
2877 improvement they bring about. For a bug fix, just include a copy of the
2878 bug report, and explain why the change fixes the bug.
2880 (Referring to a bug report is not as good as including it, because then
2881 we will have to look it up, and we have probably already deleted it if
2882 we've already fixed the bug.)
2885 Always include a proper bug report for the problem you think you have
2886 fixed. We need to convince ourselves that the change is right before
2887 installing it. Even if it is right, we might have trouble judging it if
2888 we don't have a way to reproduce the problem.
2891 Include all the comments that are appropriate to help people reading the
2892 source in the future understand why this change was needed.
2895 Don't mix together changes made for different reasons.
2896 Send them @emph{individually}.
2898 If you make two changes for separate reasons, then we might not want to
2899 install them both. We might want to install just one. If you send them
2900 all jumbled together in a single set of diffs, we have to do extra work
2901 to disentangle them---to figure out which parts of the change serve
2902 which purpose. If we don't have time for this, we might have to ignore
2903 your changes entirely.
2905 If you send each change as soon as you have written it, with its own
2906 explanation, then the two changes never get tangled up, and we can
2907 consider each one properly without any extra work to disentangle them.
2909 Ideally, each change you send should be impossible to subdivide into
2910 parts that we might want to consider separately, because each of its
2911 parts gets its motivation from the other parts.
2914 Send each change as soon as that change is finished. Sometimes people
2915 think they are helping us by accumulating many changes to send them all
2916 together. As explained above, this is absolutely the worst thing you
2919 Since you should send each change separately, you might as well send it
2920 right away. That gives us the option of installing it immediately if it
2924 Use @samp{diff -c} to make your diffs. Diffs without context are hard
2925 for us to install reliably. More than that, they make it hard for us to
2926 study the diffs to decide whether we want to install them. Unidiff
2927 format is better than contextless diffs, but not as easy to read as
2930 If you have GNU diff, use @samp{diff -cp}, which shows the name of the
2931 function that each change occurs in.
2934 Write the change log entries for your changes. We get lots of changes,
2935 and we don't have time to do all the change log writing ourselves.
2937 Read the @file{ChangeLog} file to see what sorts of information to put
2938 in, and to learn the style that we use. The purpose of the change log
2939 is to show people where to find what was changed. So you need to be
2940 specific about what functions you changed; in large functions, it's
2941 often helpful to indicate where within the function the change was.
2943 On the other hand, once you have shown people where to find the change,
2944 you need not explain its purpose. Thus, if you add a new function, all
2945 you need to say about it is that it is new. If you feel that the
2946 purpose needs explaining, it probably does---but the explanation will be
2947 much more useful if you put it in comments in the code.
2949 If you would like your name to appear in the header line for who made
2950 the change, send us the header line.
2953 When you write the fix, keep in mind that we can't install a change that
2954 would break other systems.
2956 People often suggest fixing a problem by changing machine-independent
2957 files such as @file{toplev.c} to do something special that a particular
2958 system needs. Sometimes it is totally obvious that such changes would
2959 break GCC for almost all users. We can't possibly make a change like
2960 that. At best it might tell us how to write another patch that would
2961 solve the problem acceptably.
2963 Sometimes people send fixes that @emph{might} be an improvement in
2964 general---but it is hard to be sure of this. It's hard to install
2965 such changes because we have to study them very carefully. Of course,
2966 a good explanation of the reasoning by which you concluded the change
2967 was correct can help convince us.
2969 The safest changes are changes to the configuration files for a
2970 particular machine. These are safe because they can't create new bugs
2973 Please help us keep up with the workload by designing the patch in a
2974 form that is good to install.
2978 @chapter How To Get Help with GCC
2980 If you need help installing, using or changing GCC, there are two
2985 Send a message to a suitable network mailing list. First try
2986 @email{gcc-help@@gcc.gnu.org} (for help installing or using GCC), and if
2987 that brings no response, try @email{gcc@@gcc.gnu.org}. For help
2988 changing GCC, ask @email{gcc@@gcc.gnu.org}. If you think you have found
2989 a bug in GCC, please report it following the instructions at
2990 @uref{http://gcc.gnu.org/bugs.html}.
2993 Look in the service directory for someone who might help you for a fee.
2994 The service directory is found at
2995 @uref{http://www.gnu.org/prep/service.html}.
2998 @c For further information, see
2999 @c @uref{http://gcc.gnu.org/cgi-bin/fom.cgi?file=12}.
3000 @c FIXME: this URL may be too volatile, this FAQ entry needs to move to
3001 @c the regular web pages before we can uncomment the reference.
3004 @chapter Contributing to GCC Development
3006 If you would like to help pretest GCC releases to assure they work well,
3007 our current development sources are available by CVS (see
3008 @uref{http://gcc.gnu.org/cvs.html}). Source and binary snapshots are
3009 also available for FTP; see @uref{http://gcc.gnu.org/snapshots.html}.
3010 Remember that snapshots of the current development sources may not be of
3011 production quality; if you find problems (whether compiler crashes,
3012 miscompiled code, poor optimization or any other problem), please report
3013 them following our bug reporting instructions at
3014 @uref{http://gcc.gnu.org/bugs.html}.
3016 If you would like to work on improvements to GCC, please read
3017 @uref{http://gcc.gnu.org/contribute.html} and
3018 @uref{http://gcc.gnu.org/contributewhy.html} for information on how to
3019 make useful contributions and avoid duplication of effort. Suggested
3020 projects are listed at @uref{http://gcc.gnu.org/projects/}.
3023 @chapter Using GCC on VMS
3025 @c prevent bad page break with this line
3026 Here is how to use GCC on VMS.
3029 * Include Files and VMS:: Where the preprocessor looks for the include files.
3030 * Global Declarations:: How to do globaldef, globalref and globalvalue with
3032 * VMS Misc:: Misc information.
3035 @node Include Files and VMS
3036 @section Include Files and VMS
3038 @cindex include files and VMS
3039 @cindex VMS and include files
3040 @cindex header files and VMS
3041 Due to the differences between the filesystems of Unix and VMS, GCC
3042 attempts to translate file names in @samp{#include} into names that VMS
3043 will understand. The basic strategy is to prepend a prefix to the
3044 specification of the include file, convert the whole filename to a VMS
3045 filename, and then try to open the file. GCC tries various prefixes
3046 one by one until one of them succeeds:
3050 The first prefix is the @samp{GNU_CC_INCLUDE:} logical name: this is
3051 where GNU C header files are traditionally stored. If you wish to store
3052 header files in non-standard locations, then you can assign the logical
3053 @samp{GNU_CC_INCLUDE} to be a search list, where each element of the
3054 list is suitable for use with a rooted logical.
3057 The next prefix tried is @samp{SYS$SYSROOT:[SYSLIB.]}. This is where
3058 VAX-C header files are traditionally stored.
3061 If the include file specification by itself is a valid VMS filename, the
3062 preprocessor then uses this name with no prefix in an attempt to open
3066 If the file specification is not a valid VMS filename (i.e. does not
3067 contain a device or a directory specifier, and contains a @samp{/}
3068 character), the preprocessor tries to convert it from Unix syntax to
3071 Conversion works like this: the first directory name becomes a device,
3072 and the rest of the directories are converted into VMS-format directory
3073 names. For example, the name @file{X11/foobar.h} is
3074 translated to @file{X11:[000000]foobar.h} or @file{X11:foobar.h},
3075 whichever one can be opened. This strategy allows you to assign a
3076 logical name to point to the actual location of the header files.
3079 If none of these strategies succeeds, the @samp{#include} fails.
3082 Include directives of the form:
3089 are a common source of incompatibility between VAX-C and GCC. VAX-C
3090 treats this much like a standard @code{#include <foobar.h>} directive.
3091 That is incompatible with the ISO C behavior implemented by GCC: to
3092 expand the name @code{foobar} as a macro. Macro expansion should
3093 eventually yield one of the two standard formats for @code{#include}:
3096 #include "@var{file}"
3097 #include <@var{file}>
3100 If you have this problem, the best solution is to modify the source to
3101 convert the @code{#include} directives to one of the two standard forms.
3102 That will work with either compiler. If you want a quick and dirty fix,
3103 define the file names as macros with the proper expansion, like this:
3106 #define stdio <stdio.h>
3110 This will work, as long as the name doesn't conflict with anything else
3113 Another source of incompatibility is that VAX-C assumes that:
3120 is actually asking for the file @file{foobar.h}. GCC does not
3121 make this assumption, and instead takes what you ask for literally;
3122 it tries to read the file @file{foobar}. The best way to avoid this
3123 problem is to always specify the desired file extension in your include
3126 GCC for VMS is distributed with a set of include files that is
3127 sufficient to compile most general purpose programs. Even though the
3128 GCC distribution does not contain header files to define constants
3129 and structures for some VMS system-specific functions, there is no
3130 reason why you cannot use GCC with any of these functions. You first
3131 may have to generate or create header files, either by using the public
3132 domain utility @code{UNSDL} (which can be found on a DECUS tape), or by
3133 extracting the relevant modules from one of the system macro libraries,
3134 and using an editor to construct a C header file.
3136 A @code{#include} file name cannot contain a DECNET node name. The
3137 preprocessor reports an I/O error if you attempt to use a node name,
3138 whether explicitly, or implicitly via a logical name.
3140 @node Global Declarations
3141 @section Global Declarations and VMS
3145 @findex GLOBALVALUEDEF
3146 @findex GLOBALVALUEREF
3147 GCC does not provide the @code{globalref}, @code{globaldef} and
3148 @code{globalvalue} keywords of VAX-C. You can get the same effect with
3149 an obscure feature of GAS, the GNU assembler. (This requires GAS
3150 version 1.39 or later.) The following macros allow you to use this
3151 feature in a fairly natural way:
3155 #define GLOBALREF(TYPE,NAME) \
3157 asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME)
3158 #define GLOBALDEF(TYPE,NAME,VALUE) \
3160 asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME) \
3162 #define GLOBALVALUEREF(TYPE,NAME) \
3163 const TYPE NAME[1] \
3164 asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME)
3165 #define GLOBALVALUEDEF(TYPE,NAME,VALUE) \
3166 const TYPE NAME[1] \
3167 asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME) \
3170 #define GLOBALREF(TYPE,NAME) \
3172 #define GLOBALDEF(TYPE,NAME,VALUE) \
3173 globaldef TYPE NAME = VALUE
3174 #define GLOBALVALUEDEF(TYPE,NAME,VALUE) \
3175 globalvalue TYPE NAME = VALUE
3176 #define GLOBALVALUEREF(TYPE,NAME) \
3177 globalvalue TYPE NAME
3182 (The @code{_$$PsectAttributes_GLOBALSYMBOL} prefix at the start of the
3183 name is removed by the assembler, after it has modified the attributes
3184 of the symbol). These macros are provided in the VMS binaries
3185 distribution in a header file @file{GNU_HACKS.H}. An example of the
3189 GLOBALREF (int, ijk);
3190 GLOBALDEF (int, jkl, 0);
3193 The macros @code{GLOBALREF} and @code{GLOBALDEF} cannot be used
3194 straightforwardly for arrays, since there is no way to insert the array
3195 dimension into the declaration at the right place. However, you can
3196 declare an array with these macros if you first define a typedef for the
3197 array type, like this:
3200 typedef int intvector[10];
3201 GLOBALREF (intvector, foo);
3204 Array and structure initializers will also break the macros; you can
3205 define the initializer to be a macro of its own, or you can expand the
3206 @code{GLOBALDEF} macro by hand. You may find a case where you wish to
3207 use the @code{GLOBALDEF} macro with a large array, but you are not
3208 interested in explicitly initializing each element of the array. In
3209 such cases you can use an initializer like: @code{@{0,@}}, which will
3210 initialize the entire array to @code{0}.
3212 A shortcoming of this implementation is that a variable declared with
3213 @code{GLOBALVALUEREF} or @code{GLOBALVALUEDEF} is always an array. For
3214 example, the declaration:
3217 GLOBALVALUEREF(int, ijk);
3221 declares the variable @code{ijk} as an array of type @code{int [1]}.
3222 This is done because a globalvalue is actually a constant; its ``value''
3223 is what the linker would normally consider an address. That is not how
3224 an integer value works in C, but it is how an array works. So treating
3225 the symbol as an array name gives consistent results---with the
3226 exception that the value seems to have the wrong type. @strong{Don't
3227 try to access an element of the array.} It doesn't have any elements.
3228 The array ``address'' may not be the address of actual storage.
3230 The fact that the symbol is an array may lead to warnings where the
3231 variable is used. Insert type casts to avoid the warnings. Here is an
3232 example; it takes advantage of the ISO C feature allowing macros that
3233 expand to use the same name as the macro itself.
3236 GLOBALVALUEREF (int, ss$_normal);
3237 GLOBALVALUEDEF (int, xyzzy,123);
3239 #define ss$_normal ((int) ss$_normal)
3240 #define xyzzy ((int) xyzzy)
3244 Don't use @code{globaldef} or @code{globalref} with a variable whose
3245 type is an enumeration type; this is not implemented. Instead, make the
3246 variable an integer, and use a @code{globalvaluedef} for each of the
3247 enumeration values. An example of this would be:
3251 GLOBALDEF (int, color, 0);
3252 GLOBALVALUEDEF (int, RED, 0);
3253 GLOBALVALUEDEF (int, BLUE, 1);
3254 GLOBALVALUEDEF (int, GREEN, 3);
3256 enum globaldef color @{RED, BLUE, GREEN = 3@};
3261 @section Other VMS Issues
3263 @cindex exit status and VMS
3264 @cindex return value of @code{main}
3265 @cindex @code{main} and the exit status
3266 GCC automatically arranges for @code{main} to return 1 by default if
3267 you fail to specify an explicit return value. This will be interpreted
3268 by VMS as a status code indicating a normal successful completion.
3269 Version 1 of GCC did not provide this default.
3271 GCC on VMS works only with the GNU assembler, GAS. You need version
3272 1.37 or later of GAS in order to produce value debugging information for
3273 the VMS debugger. Use the ordinary VMS linker with the object files
3276 @cindex shared VMS run time system
3277 @cindex @file{VAXCRTL}
3278 Under previous versions of GCC, the generated code would occasionally
3279 give strange results when linked to the sharable @file{VAXCRTL} library.
3280 Now this should work.
3282 A caveat for use of @code{const} global variables: the @code{const}
3283 modifier must be specified in every external declaration of the variable
3284 in all of the source files that use that variable. Otherwise the linker
3285 will issue warnings about conflicting attributes for the variable. Your
3286 program will still work despite the warnings, but the variable will be
3287 placed in writable storage.
3289 @cindex name augmentation
3290 @cindex case sensitivity and VMS
3291 @cindex VMS and case sensitivity
3292 Although the VMS linker does distinguish between upper and lower case
3293 letters in global symbols, most VMS compilers convert all such symbols
3294 into upper case and most run-time library routines also have upper case
3295 names. To be able to reliably call such routines, GCC (by means of
3296 the assembler GAS) converts global symbols into upper case like other
3297 VMS compilers. However, since the usual practice in C is to distinguish
3298 case, GCC (via GAS) tries to preserve usual C behavior by augmenting
3299 each name that is not all lower case. This means truncating the name
3300 to at most 23 characters and then adding more characters at the end
3301 which encode the case pattern of those 23. Names which contain at
3302 least one dollar sign are an exception; they are converted directly into
3303 upper case without augmentation.
3305 Name augmentation yields bad results for programs that use precompiled
3306 libraries (such as Xlib) which were generated by another compiler. You
3307 can use the compiler option @samp{/NOCASE_HACK} to inhibit augmentation;
3308 it makes external C functions and variables case-independent as is usual
3309 on VMS. Alternatively, you could write all references to the functions
3310 and variables in such libraries using lower case; this will work on VMS,
3311 but is not portable to other systems. The compiler option @samp{/NAMES}
3312 also provides control over global name handling.
3314 Function and variable names are handled somewhat differently with GNU
3315 C++. The GNU C++ compiler performs @dfn{name mangling} on function
3316 names, which means that it adds information to the function name to
3317 describe the data types of the arguments that the function takes. One
3318 result of this is that the name of a function can become very long.
3319 Since the VMS linker only recognizes the first 31 characters in a name,
3320 special action is taken to ensure that each function and variable has a
3321 unique name that can be represented in 31 characters.
3323 If the name (plus a name augmentation, if required) is less than 32
3324 characters in length, then no special action is performed. If the name
3325 is longer than 31 characters, the assembler (GAS) will generate a
3326 hash string based upon the function name, truncate the function name to
3327 23 characters, and append the hash string to the truncated name. If the
3328 @samp{/VERBOSE} compiler option is used, the assembler will print both
3329 the full and truncated names of each symbol that is truncated.
3331 The @samp{/NOCASE_HACK} compiler option should not be used when you are
3332 compiling programs that use libg++. libg++ has several instances of
3333 objects (i.e. @code{Filebuf} and @code{filebuf}) which become
3334 indistinguishable in a case-insensitive environment. This leads to
3335 cases where you need to inhibit augmentation selectively (if you were
3336 using libg++ and Xlib in the same program, for example). There is no
3337 special feature for doing this, but you can get the result by defining a
3338 macro for each mixed case symbol for which you wish to inhibit
3339 augmentation. The macro should expand into the lower case equivalent of
3340 itself. For example:
3343 #define StuDlyCapS studlycaps
3346 These macro definitions can be placed in a header file to minimize the
3347 number of changes to your source code.
3352 @chapter GCC and Portability
3354 @cindex GCC and portability
3356 The main goal of GCC was to make a good, fast compiler for machines in
3357 the class that the GNU system aims to run on: 32-bit machines that address
3358 8-bit bytes and have several general registers. Elegance, theoretical
3359 power and simplicity are only secondary.
3361 GCC gets most of the information about the target machine from a machine
3362 description which gives an algebraic formula for each of the machine's
3363 instructions. This is a very clean way to describe the target. But when
3364 the compiler needs information that is difficult to express in this
3365 fashion, I have not hesitated to define an ad-hoc parameter to the machine
3366 description. The purpose of portability is to reduce the total work needed
3367 on the compiler; it was not of interest for its own sake.
3370 @cindex autoincrement addressing, availability
3372 GCC does not contain machine dependent code, but it does contain code
3373 that depends on machine parameters such as endianness (whether the most
3374 significant byte has the highest or lowest address of the bytes in a word)
3375 and the availability of autoincrement addressing. In the RTL-generation
3376 pass, it is often necessary to have multiple strategies for generating code
3377 for a particular kind of syntax tree, strategies that are usable for different
3378 combinations of parameters. Often I have not tried to address all possible
3379 cases, but only the common ones or only the ones that I have encountered.
3380 As a result, a new target may require additional strategies. You will know
3381 if this happens because the compiler will call @code{abort}. Fortunately,
3382 the new strategies can be added in a machine-independent fashion, and will
3383 affect only the target machines that need them.
3388 @chapter Interfacing to GCC Output
3389 @cindex interfacing to GCC output
3390 @cindex run-time conventions
3391 @cindex function call conventions
3392 @cindex conventions, run-time
3394 GCC is normally configured to use the same function calling convention
3395 normally in use on the target system. This is done with the
3396 machine-description macros described (@pxref{Target Macros}).
3398 @cindex unions, returning
3399 @cindex structures, returning
3400 @cindex returning structures and unions
3401 However, returning of structure and union values is done differently on
3402 some target machines. As a result, functions compiled with PCC
3403 returning such types cannot be called from code compiled with GCC,
3404 and vice versa. This does not cause trouble often because few Unix
3405 library routines return structures or unions.
3407 GCC code returns structures and unions that are 1, 2, 4 or 8 bytes
3408 long in the same registers used for @code{int} or @code{double} return
3409 values. (GCC typically allocates variables of such types in
3410 registers also.) Structures and unions of other sizes are returned by
3411 storing them into an address passed by the caller (usually in a
3412 register). The machine-description macros @code{STRUCT_VALUE} and
3413 @code{STRUCT_INCOMING_VALUE} tell GCC where to pass this address.
3415 By contrast, PCC on most target machines returns structures and unions
3416 of any size by copying the data into an area of static storage, and then
3417 returning the address of that storage as if it were a pointer value.
3418 The caller must copy the data from that memory area to the place where
3419 the value is wanted. This is slower than the method used by GCC, and
3420 fails to be reentrant.
3422 On some target machines, such as RISC machines and the 80386, the
3423 standard system convention is to pass to the subroutine the address of
3424 where to return the value. On these machines, GCC has been
3425 configured to be compatible with the standard compiler, when this method
3426 is used. It may not be compatible for structures of 1, 2, 4 or 8 bytes.
3428 @cindex argument passing
3429 @cindex passing arguments
3430 GCC uses the system's standard convention for passing arguments. On
3431 some machines, the first few arguments are passed in registers; in
3432 others, all are passed on the stack. It would be possible to use
3433 registers for argument passing on any machine, and this would probably
3434 result in a significant speedup. But the result would be complete
3435 incompatibility with code that follows the standard convention. So this
3436 change is practical only if you are switching to GCC as the sole C
3437 compiler for the system. We may implement register argument passing on
3438 certain machines once we have a complete GNU system so that we can
3439 compile the libraries with GCC.
3441 On some machines (particularly the Sparc), certain types of arguments
3442 are passed ``by invisible reference''. This means that the value is
3443 stored in memory, and the address of the memory location is passed to
3446 @cindex @code{longjmp} and automatic variables
3447 If you use @code{longjmp}, beware of automatic variables. ISO C says that
3448 automatic variables that are not declared @code{volatile} have undefined
3449 values after a @code{longjmp}. And this is all GCC promises to do,
3450 because it is very difficult to restore register variables correctly, and
3451 one of GCC's features is that it can put variables in registers without
3454 If you want a variable to be unaltered by @code{longjmp}, and you don't
3455 want to write @code{volatile} because old C compilers don't accept it,
3456 just take the address of the variable. If a variable's address is ever
3457 taken, even if just to compute it and ignore it, then the variable cannot
3468 @cindex arithmetic libraries
3469 @cindex math libraries
3470 Code compiled with GCC may call certain library routines. Most of
3471 them handle arithmetic for which there are no instructions. This
3472 includes multiply and divide on some machines, and floating point
3473 operations on any machine for which floating point support is disabled
3474 with @samp{-msoft-float}. Some standard parts of the C library, such as
3475 @code{bcopy} or @code{memcpy}, are also called automatically. The usual
3476 function call interface is used for calling the library routines.
3478 These library routines should be defined in the library @file{libgcc.a},
3479 which GCC automatically searches whenever it links a program. On
3480 machines that have multiply and divide instructions, if hardware
3481 floating point is in use, normally @file{libgcc.a} is not needed, but it
3482 is searched just in case.
3484 Each arithmetic function is defined in @file{libgcc1.c} to use the
3485 corresponding C arithmetic operator. As long as the file is compiled
3486 with another C compiler, which supports all the C arithmetic operators,
3487 this file will work portably. However, @file{libgcc1.c} does not work if
3488 compiled with GCC, because each arithmetic function would compile
3489 into a call to itself!
3494 @chapter Passes and Files of the Compiler
3495 @cindex passes and files of the compiler
3496 @cindex files and passes of the compiler
3497 @cindex compiler passes and files
3499 @cindex top level of compiler
3500 The overall control structure of the compiler is in @file{toplev.c}. This
3501 file is responsible for initialization, decoding arguments, opening and
3502 closing files, and sequencing the passes.
3504 @cindex parsing pass
3505 The parsing pass is invoked only once, to parse the entire input. The RTL
3506 intermediate code for a function is generated as the function is parsed, a
3507 statement at a time. Each statement is read in as a syntax tree and then
3508 converted to RTL; then the storage for the tree for the statement is
3509 reclaimed. Storage for types (and the expressions for their sizes),
3510 declarations, and a representation of the binding contours and how they nest,
3511 remain until the function is finished being compiled; these are all needed
3512 to output the debugging information.
3514 @findex rest_of_compilation
3515 @findex rest_of_decl_compilation
3516 Each time the parsing pass reads a complete function definition or
3517 top-level declaration, it calls either the function
3518 @code{rest_of_compilation}, or the function
3519 @code{rest_of_decl_compilation} in @file{toplev.c}, which are
3520 responsible for all further processing necessary, ending with output of
3521 the assembler language. All other compiler passes run, in sequence,
3522 within @code{rest_of_compilation}. When that function returns from
3523 compiling a function definition, the storage used for that function
3524 definition's compilation is entirely freed, unless it is an inline
3527 (@pxref{Inline,,An Inline Function is As Fast As a Macro}).
3530 (@pxref{Inline,,An Inline Function is As Fast As a Macro,gcc.texi,Using GCC}).
3533 Here is a list of all the passes of the compiler and their source files.
3534 Also included is a description of where debugging dumps can be requested
3535 with @samp{-d} options.
3539 Parsing. This pass reads the entire text of a function definition,
3540 constructing partial syntax trees. This and RTL generation are no longer
3541 truly separate passes (formerly they were), but it is easier to think
3542 of them as separate.
3544 The tree representation does not entirely follow C syntax, because it is
3545 intended to support other languages as well.
3547 Language-specific data type analysis is also done in this pass, and every
3548 tree node that represents an expression has a data type attached.
3549 Variables are represented as declaration nodes.
3551 @cindex constant folding
3552 @cindex arithmetic simplifications
3553 @cindex simplifications, arithmetic
3554 Constant folding and some arithmetic simplifications are also done
3557 The language-independent source files for parsing are
3558 @file{stor-layout.c}, @file{fold-const.c}, and @file{tree.c}.
3559 There are also header files @file{tree.h} and @file{tree.def}
3560 which define the format of the tree representation.@refill
3562 @c Avoiding overfull is tricky here.
3563 The source files to parse C are
3567 @file{c-aux-info.c},
3570 along with header files
3574 The source files for parsing C++ are in @file{cp/}.
3575 They are @file{parse.y},
3577 @file{cvt.c}, @file{decl.c}, @file{decl2.c},
3579 @file{expr.c}, @file{init.c}, @file{lex.c},
3580 @file{method.c}, @file{ptree.c},@*
3581 @file{search.c}, @file{tree.c},
3582 @file{typeck2.c}, and
3583 @file{typeck.c}, along with header files @file{cp-tree.def},
3584 @file{cp-tree.h}, and @file{decl.h}.
3586 The special source files for parsing Objective C are in @file{objc/}.
3587 They are @file{objc-parse.y}, @file{objc-act.c}, @file{objc-tree.def}, and
3588 @file{objc-act.h}. Certain C-specific files are used for this as
3591 The file @file{c-common.c} is also used for all of the above languages.
3593 @cindex RTL generation
3595 RTL generation. This is the conversion of syntax tree into RTL code.
3596 It is actually done statement-by-statement during parsing, but for
3597 most purposes it can be thought of as a separate pass.
3599 @cindex target-parameter-dependent code
3600 This is where the bulk of target-parameter-dependent code is found,
3601 since often it is necessary for strategies to apply only when certain
3602 standard kinds of instructions are available. The purpose of named
3603 instruction patterns is to provide this information to the RTL
3606 @cindex tail recursion optimization
3607 Optimization is done in this pass for @code{if}-conditions that are
3608 comparisons, boolean operations or conditional expressions. Tail
3609 recursion is detected at this time also. Decisions are made about how
3610 best to arrange loops and how to output @code{switch} statements.
3612 @c Avoiding overfull is tricky here.
3613 The source files for RTL generation include
3621 and @file{emit-rtl.c}.
3623 @file{insn-emit.c}, generated from the machine description by the
3624 program @code{genemit}, is used in this pass. The header file
3625 @file{expr.h} is used for communication within this pass.@refill
3629 The header files @file{insn-flags.h} and @file{insn-codes.h},
3630 generated from the machine description by the programs @code{genflags}
3631 and @code{gencodes}, tell this pass which standard names are available
3632 for use and which patterns correspond to them.@refill
3634 Aside from debugging information output, none of the following passes
3635 refers to the tree structure representation of the function (only
3636 part of which is saved).
3638 @cindex inline, automatic
3639 The decision of whether the function can and should be expanded inline
3640 in its subsequent callers is made at the end of rtl generation. The
3641 function must meet certain criteria, currently related to the size of
3642 the function and the types and number of parameters it has. Note that
3643 this function may contain loops, recursive calls to itself
3644 (tail-recursive functions can be inlined!), gotos, in short, all
3645 constructs supported by GCC. The file @file{integrate.c} contains
3646 the code to save a function's rtl for later inlining and to inline that
3647 rtl when the function is called. The header file @file{integrate.h}
3648 is also used for this purpose.
3650 The option @samp{-dr} causes a debugging dump of the RTL code after
3651 this pass. This dump file's name is made by appending @samp{.rtl} to
3652 the input file name.
3654 @cindex jump optimization
3655 @cindex unreachable code
3658 Jump optimization. This pass simplifies jumps to the following
3659 instruction, jumps across jumps, and jumps to jumps. It deletes
3660 unreferenced labels and unreachable code, except that unreachable code
3661 that contains a loop is not recognized as unreachable in this pass.
3662 (Such loops are deleted later in the basic block analysis.) It also
3663 converts some code originally written with jumps into sequences of
3664 instructions that directly set values from the results of comparisons,
3665 if the machine has such instructions.
3667 Jump optimization is performed two or three times. The first time is
3668 immediately following RTL generation. The second time is after CSE,
3669 but only if CSE says repeated jump optimization is needed. The
3670 last time is right before the final pass. That time, cross-jumping
3671 and deletion of no-op move instructions are done together with the
3672 optimizations described above.
3674 The source file of this pass is @file{jump.c}.
3676 The option @samp{-dj} causes a debugging dump of the RTL code after
3677 this pass is run for the first time. This dump file's name is made by
3678 appending @samp{.jump} to the input file name.
3680 @cindex register use analysis
3682 Register scan. This pass finds the first and last use of each
3683 register, as a guide for common subexpression elimination. Its source
3684 is in @file{regclass.c}.
3686 @cindex jump threading
3688 Jump threading. This pass detects a condition jump that branches to an
3689 identical or inverse test. Such jumps can be @samp{threaded} through
3690 the second conditional test. The source code for this pass is in
3691 @file{jump.c}. This optimization is only performed if
3692 @samp{-fthread-jumps} is enabled.
3694 @cindex common subexpression elimination
3695 @cindex constant propagation
3697 Common subexpression elimination. This pass also does constant
3698 propagation. Its source file is @file{cse.c}. If constant
3699 propagation causes conditional jumps to become unconditional or to
3700 become no-ops, jump optimization is run again when CSE is finished.
3702 The option @samp{-ds} causes a debugging dump of the RTL code after
3703 this pass. This dump file's name is made by appending @samp{.cse} to
3704 the input file name.
3706 @cindex global common subexpression elimination
3707 @cindex constant propagation
3708 @cindex copy propagation
3710 Global common subexpression elimination. This pass performs GCSE
3711 using Morel-Renvoise Partial Redundancy Elimination, with the exception
3712 that it does not try to move invariants out of loops - that is left to
3713 the loop optimization pass. This pass also performs global constant
3714 and copy propagation.
3716 The source file for this pass is gcse.c.
3718 The option @samp{-dG} causes a debugging dump of the RTL code after
3719 this pass. This dump file's name is made by appending @samp{.gcse} to
3720 the input file name.
3722 @cindex loop optimization
3724 @cindex strength-reduction
3726 Loop optimization. This pass moves constant expressions out of loops,
3727 and optionally does strength-reduction and loop unrolling as well.
3728 Its source files are @file{loop.c} and @file{unroll.c}, plus the header
3729 @file{loop.h} used for communication between them. Loop unrolling uses
3730 some functions in @file{integrate.c} and the header @file{integrate.h}.
3732 The option @samp{-dL} causes a debugging dump of the RTL code after
3733 this pass. This dump file's name is made by appending @samp{.loop} to
3734 the input file name.
3737 If @samp{-frerun-cse-after-loop} was enabled, a second common
3738 subexpression elimination pass is performed after the loop optimization
3739 pass. Jump threading is also done again at this time if it was specified.
3741 The option @samp{-dt} causes a debugging dump of the RTL code after
3742 this pass. This dump file's name is made by appending @samp{.cse2} to
3743 the input file name.
3745 @cindex data flow analysis
3746 @cindex analysis, data flow
3747 @cindex basic blocks
3749 Data flow analysis (@file{flow.c}). This pass divides the program
3750 into basic blocks (and in the process deletes unreachable loops); then
3751 it computes which pseudo-registers are live at each point in the
3752 program, and makes the first instruction that uses a value point at
3753 the instruction that computed the value.
3755 @cindex autoincrement/decrement analysis
3756 This pass also deletes computations whose results are never used, and
3757 combines memory references with add or subtract instructions to make
3758 autoincrement or autodecrement addressing.
3760 The option @samp{-df} causes a debugging dump of the RTL code after
3761 this pass. This dump file's name is made by appending @samp{.flow} to
3762 the input file name. If stupid register allocation is in use, this
3763 dump file reflects the full results of such allocation.
3765 @cindex instruction combination
3767 Instruction combination (@file{combine.c}). This pass attempts to
3768 combine groups of two or three instructions that are related by data
3769 flow into single instructions. It combines the RTL expressions for
3770 the instructions by substitution, simplifies the result using algebra,
3771 and then attempts to match the result against the machine description.
3773 The option @samp{-dc} causes a debugging dump of the RTL code after
3774 this pass. This dump file's name is made by appending @samp{.combine}
3775 to the input file name.
3777 @cindex register movement
3779 Register movement (@file{regmove.c}). This pass looks for cases where
3780 matching constraints would force an instruction to need a reload, and
3781 this reload would be a register to register move. It then attempts
3782 to change the registers used by the instruction to avoid the move
3785 The option @samp{-dN} causes a debugging dump of the RTL code after
3786 this pass. This dump file's name is made by appending @samp{.regmove}
3787 to the input file name.
3789 @cindex instruction scheduling
3790 @cindex scheduling, instruction
3792 Instruction scheduling (@file{sched.c}). This pass looks for
3793 instructions whose output will not be available by the time that it is
3794 used in subsequent instructions. (Memory loads and floating point
3795 instructions often have this behavior on RISC machines). It re-orders
3796 instructions within a basic block to try to separate the definition and
3797 use of items that otherwise would cause pipeline stalls.
3799 Instruction scheduling is performed twice. The first time is immediately
3800 after instruction combination and the second is immediately after reload.
3802 The option @samp{-dS} causes a debugging dump of the RTL code after this
3803 pass is run for the first time. The dump file's name is made by
3804 appending @samp{.sched} to the input file name.
3806 @cindex register class preference pass
3808 Register class preferencing. The RTL code is scanned to find out
3809 which register class is best for each pseudo register. The source
3810 file is @file{regclass.c}.
3812 @cindex register allocation
3813 @cindex local register allocation
3815 Local register allocation (@file{local-alloc.c}). This pass allocates
3816 hard registers to pseudo registers that are used only within one basic
3817 block. Because the basic block is linear, it can use fast and
3818 powerful techniques to do a very good job.
3820 The option @samp{-dl} causes a debugging dump of the RTL code after
3821 this pass. This dump file's name is made by appending @samp{.lreg} to
3822 the input file name.
3824 @cindex global register allocation
3826 Global register allocation (@file{global.c}). This pass
3827 allocates hard registers for the remaining pseudo registers (those
3828 whose life spans are not contained in one basic block).
3832 Reloading. This pass renumbers pseudo registers with the hardware
3833 registers numbers they were allocated. Pseudo registers that did not
3834 get hard registers are replaced with stack slots. Then it finds
3835 instructions that are invalid because a value has failed to end up in
3836 a register, or has ended up in a register of the wrong kind. It fixes
3837 up these instructions by reloading the problematical values
3838 temporarily into registers. Additional instructions are generated to
3841 The reload pass also optionally eliminates the frame pointer and inserts
3842 instructions to save and restore call-clobbered registers around calls.
3844 Source files are @file{reload.c} and @file{reload1.c}, plus the header
3845 @file{reload.h} used for communication between them.
3847 The option @samp{-dg} causes a debugging dump of the RTL code after
3848 this pass. This dump file's name is made by appending @samp{.greg} to
3849 the input file name.
3851 @cindex instruction scheduling
3852 @cindex scheduling, instruction
3854 Instruction scheduling is repeated here to try to avoid pipeline stalls
3855 due to memory loads generated for spilled pseudo registers.
3857 The option @samp{-dR} causes a debugging dump of the RTL code after
3858 this pass. This dump file's name is made by appending @samp{.sched2}
3859 to the input file name.
3861 @cindex cross-jumping
3862 @cindex no-op move instructions
3864 Jump optimization is repeated, this time including cross-jumping
3865 and deletion of no-op move instructions.
3867 The option @samp{-dJ} causes a debugging dump of the RTL code after
3868 this pass. This dump file's name is made by appending @samp{.jump2}
3869 to the input file name.
3871 @cindex delayed branch scheduling
3872 @cindex scheduling, delayed branch
3874 Delayed branch scheduling. This optional pass attempts to find
3875 instructions that can go into the delay slots of other instructions,
3876 usually jumps and calls. The source file name is @file{reorg.c}.
3878 The option @samp{-dd} causes a debugging dump of the RTL code after
3879 this pass. This dump file's name is made by appending @samp{.dbr}
3880 to the input file name.
3882 @cindex branch shortening
3884 Branch shortening. On many RISC machines, branch instructions have a
3885 limited range. Thus, longer sequences of instructions must be used for
3886 long branches. In this pass, the compiler figures out what how far each
3887 instruction will be from each other instruction, and therefore whether
3888 the usual instructions, or the longer sequences, must be used for each
3891 @cindex register-to-stack conversion
3893 Conversion from usage of some hard registers to usage of a register
3894 stack may be done at this point. Currently, this is supported only
3895 for the floating-point registers of the Intel 80387 coprocessor. The
3896 source file name is @file{reg-stack.c}.
3898 The options @samp{-dk} causes a debugging dump of the RTL code after
3899 this pass. This dump file's name is made by appending @samp{.stack}
3900 to the input file name.
3903 @cindex peephole optimization
3905 Final. This pass outputs the assembler code for the function. It is
3906 also responsible for identifying spurious test and compare
3907 instructions. Machine-specific peephole optimizations are performed
3908 at the same time. The function entry and exit sequences are generated
3909 directly as assembler code in this pass; they never exist as RTL.
3911 The source files are @file{final.c} plus @file{insn-output.c}; the
3912 latter is generated automatically from the machine description by the
3913 tool @file{genoutput}. The header file @file{conditions.h} is used
3914 for communication between these files.
3916 @cindex debugging information generation
3918 Debugging information output. This is run after final because it must
3919 output the stack slot offsets for pseudo registers that did not get
3920 hard registers. Source files are @file{dbxout.c} for DBX symbol table
3921 format, @file{sdbout.c} for SDB symbol table format, and
3922 @file{dwarfout.c} for DWARF symbol table format.
3925 Some additional files are used by all or many passes:
3929 Every pass uses @file{machmode.def} and @file{machmode.h} which define
3933 Several passes use @file{real.h}, which defines the default
3934 representation of floating point constants and how to operate on them.
3937 All the passes that work with RTL use the header files @file{rtl.h}
3938 and @file{rtl.def}, and subroutines in file @file{rtl.c}. The tools
3939 @code{gen*} also use these files to read and work with the machine
3944 Several passes refer to the header file @file{insn-config.h} which
3945 contains a few parameters (C macro definitions) generated
3946 automatically from the machine description RTL by the tool
3949 @cindex instruction recognizer
3951 Several passes use the instruction recognizer, which consists of
3952 @file{recog.c} and @file{recog.h}, plus the files @file{insn-recog.c}
3953 and @file{insn-extract.c} that are generated automatically from the
3954 machine description by the tools @file{genrecog} and
3955 @file{genextract}.@refill
3958 Several passes use the header files @file{regs.h} which defines the
3959 information recorded about pseudo register usage, and @file{basic-block.h}
3960 which defines the information recorded about basic blocks.
3963 @file{hard-reg-set.h} defines the type @code{HARD_REG_SET}, a bit-vector
3964 with a bit for each hard register, and some macros to manipulate it.
3965 This type is just @code{int} if the machine has few enough hard registers;
3966 otherwise it is an array of @code{int} and some of the macros expand
3970 Several passes use instruction attributes. A definition of the
3971 attributes defined for a particular machine is in file
3972 @file{insn-attr.h}, which is generated from the machine description by
3973 the program @file{genattr}. The file @file{insn-attrtab.c} contains
3974 subroutines to obtain the attribute values for insns. It is generated
3975 from the machine description by the program @file{genattrtab}.@refill
3987 @chapter The Configuration File
3988 @cindex configuration file
3989 @cindex @file{xm-@var{machine}.h}
3991 The configuration file @file{xm-@var{machine}.h} contains macro
3992 definitions that describe the machine and system on which the compiler
3993 is running, unlike the definitions in @file{@var{machine}.h}, which
3994 describe the machine for which the compiler is producing output. Most
3995 of the values in @file{xm-@var{machine}.h} are actually the same on all
3996 machines that GCC runs on, so large parts of all configuration files
3997 are identical. But there are some macros that vary:
4002 Define this macro if the host system is System V.
4006 Define this macro if the host system is VMS.
4008 @findex FATAL_EXIT_CODE
4009 @item FATAL_EXIT_CODE
4010 A C expression for the status code to be returned when the compiler
4011 exits after serious errors.
4013 @findex SUCCESS_EXIT_CODE
4014 @item SUCCESS_EXIT_CODE
4015 A C expression for the status code to be returned when the compiler
4016 exits without serious errors.
4018 @findex HOST_WORDS_BIG_ENDIAN
4019 @item HOST_WORDS_BIG_ENDIAN
4020 Defined if the host machine stores words of multi-word values in
4021 big-endian order. (GCC does not depend on the host byte ordering
4024 @findex HOST_FLOAT_WORDS_BIG_ENDIAN
4025 @item HOST_FLOAT_WORDS_BIG_ENDIAN
4026 Define this macro to be 1 if the host machine stores @code{DFmode},
4027 @code{XFmode} or @code{TFmode} floating point numbers in memory with the
4028 word containing the sign bit at the lowest address; otherwise, define it
4031 This macro need not be defined if the ordering is the same as for
4032 multi-word integers.
4034 @findex HOST_FLOAT_FORMAT
4035 @item HOST_FLOAT_FORMAT
4036 A numeric code distinguishing the floating point format for the host
4037 machine. See @code{TARGET_FLOAT_FORMAT} in @ref{Storage Layout} for the
4038 alternatives and default.
4040 @findex HOST_BITS_PER_CHAR
4041 @item HOST_BITS_PER_CHAR
4042 A C expression for the number of bits in @code{char} on the host
4045 @findex HOST_BITS_PER_SHORT
4046 @item HOST_BITS_PER_SHORT
4047 A C expression for the number of bits in @code{short} on the host
4050 @findex HOST_BITS_PER_INT
4051 @item HOST_BITS_PER_INT
4052 A C expression for the number of bits in @code{int} on the host
4055 @findex HOST_BITS_PER_LONG
4056 @item HOST_BITS_PER_LONG
4057 A C expression for the number of bits in @code{long} on the host
4060 @findex ONLY_INT_FIELDS
4061 @item ONLY_INT_FIELDS
4062 Define this macro to indicate that the host compiler only supports
4063 @code{int} bit fields, rather than other integral types, including
4064 @code{enum}, as do most C compilers.
4066 @findex OBSTACK_CHUNK_SIZE
4067 @item OBSTACK_CHUNK_SIZE
4068 A C expression for the size of ordinary obstack chunks.
4069 If you don't define this, a usually-reasonable default is used.
4071 @findex OBSTACK_CHUNK_ALLOC
4072 @item OBSTACK_CHUNK_ALLOC
4073 The function used to allocate obstack chunks.
4074 If you don't define this, @code{xmalloc} is used.
4076 @findex OBSTACK_CHUNK_FREE
4077 @item OBSTACK_CHUNK_FREE
4078 The function used to free obstack chunks.
4079 If you don't define this, @code{free} is used.
4081 @findex USE_C_ALLOCA
4083 Define this macro to indicate that the compiler is running with the
4084 @code{alloca} implemented in C. This version of @code{alloca} can be
4085 found in the file @file{alloca.c}; to use it, you must also alter the
4086 @file{Makefile} variable @code{ALLOCA}. (This is done automatically
4087 for the systems on which we know it is needed.)
4089 If you do define this macro, you should probably do it as follows:
4093 #define USE_C_ALLOCA
4095 #define alloca __builtin_alloca
4100 so that when the compiler is compiled with GCC it uses the more
4101 efficient built-in @code{alloca} function.
4103 @item FUNCTION_CONVERSION_BUG
4104 @findex FUNCTION_CONVERSION_BUG
4105 Define this macro to indicate that the host compiler does not properly
4106 handle converting a function value to a pointer-to-function when it is
4107 used in an expression.
4109 @findex MULTIBYTE_CHARS
4110 @item MULTIBYTE_CHARS
4111 Define this macro to enable support for multibyte characters in the
4112 input to GCC. This requires that the host system support the ISO C
4113 library functions for converting multibyte characters to wide
4118 Define this if your system is POSIX.1 compliant.
4120 @findex USE_PROTOTYPES
4121 @item USE_PROTOTYPES
4122 Define this to be 1 if you know that the host compiler supports
4123 prototypes, even if it doesn't define __STDC__, or define
4124 it to be 0 if you do not want any prototypes used in compiling
4125 GCC. If @samp{USE_PROTOTYPES} is not defined, it will be
4126 determined automatically whether your compiler supports
4127 prototypes by checking if @samp{__STDC__} is defined.
4129 @findex PATH_SEPARATOR
4130 @item PATH_SEPARATOR
4131 Define this macro to be a C character constant representing the
4132 character used to separate components in paths. The default value is
4135 @findex DIR_SEPARATOR
4137 If your system uses some character other than slash to separate
4138 directory names within a file specification, define this macro to be a C
4139 character constant specifying that character. When GCC displays file
4140 names, the character you specify will be used. GCC will test for
4141 both slash and the character you specify when parsing filenames.
4143 @findex OBJECT_SUFFIX
4145 Define this macro to be a C string representing the suffix for object
4146 files on your machine. If you do not define this macro, GCC will use
4147 @samp{.o} as the suffix for object files.
4149 @findex EXECUTABLE_SUFFIX
4150 @item EXECUTABLE_SUFFIX
4151 Define this macro to be a C string representing the suffix for executable
4152 files on your machine. If you do not define this macro, GCC will use
4153 the null string as the suffix for object files.
4155 @findex HOST_BIT_BUCKET
4156 @item HOST_BIT_BUCKET
4157 The name of a file or file-like object on the host system which acts as
4158 a ``bit bucket''. If you do not define this macro, GCC will use
4159 @samp{/dev/null} as the bit bucket. If the target does not support a
4160 bit bucket, this should be defined to the null string, or some other
4161 illegal filename. If the bit bucket is not writable, GCC will use a
4162 temporary file instead.
4164 @findex COLLECT_EXPORT_LIST
4165 @item COLLECT_EXPORT_LIST
4166 If defined, @code{collect2} will scan the individual object files
4167 specified on its command line and create an export list for the linker.
4168 Define this macro for systems like AIX, where the linker discards
4169 object files that are not referenced from @code{main} and uses export
4172 @findex COLLECT2_HOST_INITIALIZATION
4173 @item COLLECT2_HOST_INITIALIZATION
4174 If defined, a C statement (sans semicolon) that performs host-dependent
4175 initialization when @code{collect2} is being initialized.
4177 @findex GCC_DRIVER_HOST_INITIALIZATION
4178 @item GCC_DRIVER_HOST_INITIALIZATION
4179 If defined, a C statement (sans semicolon) that performs host-dependent
4180 initialization when a compilation driver is being initialized.
4182 @findex UPDATE_PATH_HOST_CANONICALIZE
4183 @item UPDATE_PATH_HOST_CANONICALIZE (@var{path}, @var{key})
4184 If defined, a C statement (sans semicolon) that performs host-dependent
4185 canonicalization when a path used in a compilation driver or preprocessor is
4186 canonicalized. @var{path} is the path to be canonicalized, and @var{key} is
4187 a translation prefix when its value isn't @code{NULL}. If the C statement
4188 does canonicalize @var{path}, the new path should be returned.
4193 In addition, configuration files for system V define @code{bcopy},
4194 @code{bzero} and @code{bcmp} as aliases. Some files define @code{alloca}
4195 as a macro when compiled with GCC, in order to take advantage of the
4196 benefit of GCC's built-in @code{alloca}.
4199 @chapter Makefile Fragments
4200 @cindex makefile fragment
4202 When you configure GCC using the @file{configure} script
4203 (@pxref{Installation}), it will construct the file @file{Makefile} from
4204 the template file @file{Makefile.in}. When it does this, it will
4205 incorporate makefile fragment files from the @file{config} directory,
4206 named @file{t-@var{target}} and @file{x-@var{host}}. If these files do
4207 not exist, it means nothing needs to be added for a given target or
4211 * Target Fragment:: Writing the @file{t-@var{target}} file.
4212 * Host Fragment:: Writing the @file{x-@var{host}} file.
4215 @node Target Fragment
4216 @section The Target Makefile Fragment
4217 @cindex target makefile fragment
4218 @cindex @file{t-@var{target}}
4220 The target makefile fragment, @file{t-@var{target}}, defines special
4221 target dependent variables and targets used in the @file{Makefile}:
4226 The rule to use to build @file{libgcc1.a}.
4227 If your target does not need to use the functions in @file{libgcc1.a},
4231 @findex CROSS_LIBGCC1
4233 The rule to use to build @file{libgcc1.a} when building a cross
4234 compiler. If your target does not need to use the functions in
4235 @file{libgcc1.a}, set this to empty. @xref{Cross Runtime}.
4237 @findex LIBGCC2_CFLAGS
4238 @item LIBGCC2_CFLAGS
4239 Compiler flags to use when compiling @file{libgcc2.c}.
4241 @findex LIB2FUNCS_EXTRA
4242 @item LIB2FUNCS_EXTRA
4243 A list of source file names to be compiled or assembled and inserted
4244 into @file{libgcc.a}.
4246 @findex Floating Point Emulation
4247 @item Floating Point Emulation
4248 To have GCC include software floating point libraries in @file{libgcc.a}
4249 define @code{FPBIT} and @code{DPBIT} along with a few rules as follows:
4251 # We want fine grained libraries, so use the new code to build the
4252 # floating point emulation libraries.
4257 fp-bit.c: $(srcdir)/config/fp-bit.c
4258 echo '#define FLOAT' > fp-bit.c
4259 cat $(srcdir)/config/fp-bit.c >> fp-bit.c
4261 dp-bit.c: $(srcdir)/config/fp-bit.c
4262 cat $(srcdir)/config/fp-bit.c > dp-bit.c
4265 You may need to provide additional #defines at the beginning of @file{fp-bit.c}
4266 and @file{dp-bit.c} to control target endianness and other options.
4269 @findex CRTSTUFF_T_CFLAGS
4270 @item CRTSTUFF_T_CFLAGS
4271 Special flags used when compiling @file{crtstuff.c}.
4272 @xref{Initialization}.
4274 @findex CRTSTUFF_T_CFLAGS_S
4275 @item CRTSTUFF_T_CFLAGS_S
4276 Special flags used when compiling @file{crtstuff.c} for shared
4277 linking. Used if you use @file{crtbeginS.o} and @file{crtendS.o}
4278 in @code{EXTRA-PARTS}.
4279 @xref{Initialization}.
4281 @findex MULTILIB_OPTIONS
4282 @item MULTILIB_OPTIONS
4283 For some targets, invoking GCC in different ways produces objects
4284 that can not be linked together. For example, for some targets GCC
4285 produces both big and little endian code. For these targets, you must
4286 arrange for multiple versions of @file{libgcc.a} to be compiled, one for
4287 each set of incompatible options. When GCC invokes the linker, it
4288 arranges to link in the right version of @file{libgcc.a}, based on
4289 the command line options used.
4291 The @code{MULTILIB_OPTIONS} macro lists the set of options for which
4292 special versions of @file{libgcc.a} must be built. Write options that
4293 are mutually incompatible side by side, separated by a slash. Write
4294 options that may be used together separated by a space. The build
4295 procedure will build all combinations of compatible options.
4297 For example, if you set @code{MULTILIB_OPTIONS} to @samp{m68000/m68020
4298 msoft-float}, @file{Makefile} will build special versions of
4299 @file{libgcc.a} using the following sets of options: @samp{-m68000},
4300 @samp{-m68020}, @samp{-msoft-float}, @samp{-m68000 -msoft-float}, and
4301 @samp{-m68020 -msoft-float}.
4303 @findex MULTILIB_DIRNAMES
4304 @item MULTILIB_DIRNAMES
4305 If @code{MULTILIB_OPTIONS} is used, this variable specifies the
4306 directory names that should be used to hold the various libraries.
4307 Write one element in @code{MULTILIB_DIRNAMES} for each element in
4308 @code{MULTILIB_OPTIONS}. If @code{MULTILIB_DIRNAMES} is not used, the
4309 default value will be @code{MULTILIB_OPTIONS}, with all slashes treated
4312 For example, if @code{MULTILIB_OPTIONS} is set to @samp{m68000/m68020
4313 msoft-float}, then the default value of @code{MULTILIB_DIRNAMES} is
4314 @samp{m68000 m68020 msoft-float}. You may specify a different value if
4315 you desire a different set of directory names.
4317 @findex MULTILIB_MATCHES
4318 @item MULTILIB_MATCHES
4319 Sometimes the same option may be written in two different ways. If an
4320 option is listed in @code{MULTILIB_OPTIONS}, GCC needs to know about
4321 any synonyms. In that case, set @code{MULTILIB_MATCHES} to a list of
4322 items of the form @samp{option=option} to describe all relevant
4323 synonyms. For example, @samp{m68000=mc68000 m68020=mc68020}.
4325 @findex MULTILIB_EXCEPTIONS
4326 @item MULTILIB_EXCEPTIONS
4327 Sometimes when there are multiple sets of @code{MULTILIB_OPTIONS} being
4328 specified, there are combinations that should not be built. In that
4329 case, set @code{MULTILIB_EXCEPTIONS} to be all of the switch exceptions
4330 in shell case syntax that should not be built.
4332 For example, in the PowerPC embedded ABI support, it is not desirable
4333 to build libraries compiled with the @samp{-mcall-aix} option
4334 and either of the @samp{-fleading-underscore} or @samp{-mlittle} options
4335 at the same time. Therefore @code{MULTILIB_EXCEPTIONS} is set to
4336 @code{*mcall-aix/*fleading-underscore* *mlittle/*mcall-aix*}.
4338 @findex MULTILIB_EXTRA_OPTS
4339 @item MULTILIB_EXTRA_OPTS
4340 Sometimes it is desirable that when building multiple versions of
4341 @file{libgcc.a} certain options should always be passed on to the
4342 compiler. In that case, set @code{MULTILIB_EXTRA_OPTS} to be the list
4343 of options to be used for all builds.
4347 @section The Host Makefile Fragment
4348 @cindex host makefile fragment
4349 @cindex @file{x-@var{host}}
4351 The host makefile fragment, @file{x-@var{host}}, defines special host
4352 dependent variables and targets used in the @file{Makefile}:
4357 The compiler to use when building the first stage.
4361 Additional host libraries to link with.
4365 The compiler to use when building @file{libgcc1.a} for a native
4370 The version of @code{ar} to use when building @file{libgcc1.a} for a native
4375 The install program to use.
4380 @unnumbered Funding Free Software
4382 If you want to have more free software a few years from now, it makes
4383 sense for you to help encourage people to contribute funds for its
4384 development. The most effective approach known is to encourage
4385 commercial redistributors to donate.
4387 Users of free software systems can boost the pace of development by
4388 encouraging for-a-fee distributors to donate part of their selling price
4389 to free software developers---the Free Software Foundation, and others.
4391 The way to convince distributors to do this is to demand it and expect
4392 it from them. So when you compare distributors, judge them partly by
4393 how much they give to free software development. Show distributors
4394 they must compete to be the one who gives the most.
4396 To make this approach work, you must insist on numbers that you can
4397 compare, such as, ``We will donate ten dollars to the Frobnitz project
4398 for each disk sold.'' Don't be satisfied with a vague promise, such as
4399 ``A portion of the profits are donated,'' since it doesn't give a basis
4402 Even a precise fraction ``of the profits from this disk'' is not very
4403 meaningful, since creative accounting and unrelated business decisions
4404 can greatly alter what fraction of the sales price counts as profit.
4405 If the price you pay is $50, ten percent of the profit is probably
4406 less than a dollar; it might be a few cents, or nothing at all.
4408 Some redistributors do development work themselves. This is useful too;
4409 but to keep everyone honest, you need to inquire how much they do, and
4410 what kind. Some kinds of development make much more long-term
4411 difference than others. For example, maintaining a separate version of
4412 a program contributes very little; maintaining the standard version of a
4413 program for the whole community contributes much. Easy new ports
4414 contribute little, since someone else would surely do them; difficult
4415 ports such as adding a new CPU to the GNU Compiler Collection contribute more;
4416 major new features or packages contribute the most.
4418 By establishing the idea that supporting further development is ``the
4419 proper thing to do'' when distributing free software for a fee, we can
4420 assure a steady flow of resources into making more free software.
4423 Copyright (C) 1994 Free Software Foundation, Inc.
4424 Verbatim copying and redistribution of this section is permitted
4425 without royalty; alteration is not permitted.
4429 @unnumbered Linux and the GNU Project
4431 Many computer users run a modified version of the GNU system every
4432 day, without realizing it. Through a peculiar turn of events, the
4433 version of GNU which is widely used today is more often known as
4434 ``Linux'', and many users are not aware of the extent of its
4435 connection with the GNU Project.
4437 There really is a Linux; it is a kernel, and these people are using
4438 it. But you can't use a kernel by itself; a kernel is useful only as
4439 part of a whole system. The system in which Linux is typically used
4440 is a modified variant of the GNU system---in other words, a Linux-based
4443 Many users are not fully aware of the distinction between the kernel,
4444 which is Linux, and the whole system, which they also call ``Linux''.
4445 The ambiguous use of the name doesn't promote understanding.
4447 Programmers generally know that Linux is a kernel. But since they
4448 have generally heard the whole system called ``Linux'' as well, they
4449 often envisage a history which fits that name. For example, many
4450 believe that once Linus Torvalds finished writing the kernel, his
4451 friends looked around for other free software, and for no particular
4452 reason most everything necessary to make a Unix-like system was
4455 What they found was no accident---it was the GNU system. The available
4456 free software added up to a complete system because the GNU Project
4457 had been working since 1984 to make one. The GNU Manifesto
4458 had set forth the goal of developing a free Unix-like system, called
4459 GNU. By the time Linux was written, the system was almost finished.
4461 Most free software projects have the goal of developing a particular
4462 program for a particular job. For example, Linus Torvalds set out to
4463 write a Unix-like kernel (Linux); Donald Knuth set out to write a text
4464 formatter (TeX); Bob Scheifler set out to develop a window system (X
4465 Windows). It's natural to measure the contribution of this kind of
4466 project by specific programs that came from the project.
4468 If we tried to measure the GNU Project's contribution in this way,
4469 what would we conclude? One CD-ROM vendor found that in their ``Linux
4470 distribution'', GNU software was the largest single contingent, around
4471 28% of the total source code, and this included some of the essential
4472 major components without which there could be no system. Linux itself
4473 was about 3%. So if you were going to pick a name for the system
4474 based on who wrote the programs in the system, the most appropriate
4475 single choice would be ``GNU''.
4477 But we don't think that is the right way to consider the question.
4478 The GNU Project was not, is not, a project to develop specific
4479 software packages. It was not a project to develop a C compiler,
4480 although we did. It was not a project to develop a text editor,
4481 although we developed one. The GNU Project's aim was to develop
4482 @emph{a complete free Unix-like system}.
4484 Many people have made major contributions to the free software in the
4485 system, and they all deserve credit. But the reason it is @emph{a
4486 system}---and not just a collection of useful programs---is because the
4487 GNU Project set out to make it one. We wrote the programs that were
4488 needed to make a @emph{complete} free system. We wrote essential but
4489 unexciting major components, such as the assembler and linker, because
4490 you can't have a system without them. A complete system needs more
4491 than just programming tools, so we wrote other components as well,
4492 such as the Bourne Again SHell, the PostScript interpreter
4493 Ghostscript, and the GNU C library.
4495 By the early 90s we had put together the whole system aside from the
4496 kernel (and we were also working on a kernel, the GNU Hurd, which runs
4497 on top of Mach). Developing this kernel has been a lot harder than we
4498 expected, and we are still working on finishing it.
4500 Fortunately, you don't have to wait for it, because Linux is working
4501 now. When Linus Torvalds wrote Linux, he filled the last major gap.
4502 People could then put Linux together with the GNU system to make a
4503 complete free system: a Linux-based GNU system (or GNU/Linux system,
4506 Putting them together sounds simple, but it was not a trivial job.
4507 The GNU C library (called glibc for short) needed substantial changes.
4508 Integrating a complete system as a distribution that would work ``out
4509 of the box'' was a big job, too. It required addressing the issue of
4510 how to install and boot the system---a problem we had not tackled,
4511 because we hadn't yet reached that point. The people who developed
4512 the various system distributions made a substantial contribution.
4514 The GNU Project supports GNU/Linux systems as well as @emph{the}
4515 GNU system---even with funds. We funded the rewriting of the
4516 Linux-related extensions to the GNU C library, so that now they are
4517 well integrated, and the newest GNU/Linux systems use the current
4518 library release with no changes. We also funded an early stage of the
4519 development of Debian GNU/Linux.
4521 We use Linux-based GNU systems today for most of our work, and we hope
4522 you use them too. But please don't confuse the public by using the
4523 name ``Linux'' ambiguously. Linux is the kernel, one of the essential
4524 major components of the system. The system as a whole is more or less
4528 @unnumbered GNU GENERAL PUBLIC LICENSE
4529 @center Version 2, June 1991
4532 Copyright @copyright{} 1989, 1991 Free Software Foundation, Inc.
4533 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
4535 Everyone is permitted to copy and distribute verbatim copies
4536 of this license document, but changing it is not allowed.
4539 @unnumberedsec Preamble
4541 The licenses for most software are designed to take away your
4542 freedom to share and change it. By contrast, the GNU General Public
4543 License is intended to guarantee your freedom to share and change free
4544 software---to make sure the software is free for all its users. This
4545 General Public License applies to most of the Free Software
4546 Foundation's software and to any other program whose authors commit to
4547 using it. (Some other Free Software Foundation software is covered by
4548 the GNU Library General Public License instead.) You can apply it to
4551 When we speak of free software, we are referring to freedom, not
4552 price. Our General Public Licenses are designed to make sure that you
4553 have the freedom to distribute copies of free software (and charge for
4554 this service if you wish), that you receive source code or can get it
4555 if you want it, that you can change the software or use pieces of it
4556 in new free programs; and that you know you can do these things.
4558 To protect your rights, we need to make restrictions that forbid
4559 anyone to deny you these rights or to ask you to surrender the rights.
4560 These restrictions translate to certain responsibilities for you if you
4561 distribute copies of the software, or if you modify it.
4563 For example, if you distribute copies of such a program, whether
4564 gratis or for a fee, you must give the recipients all the rights that
4565 you have. You must make sure that they, too, receive or can get the
4566 source code. And you must show them these terms so they know their
4569 We protect your rights with two steps: (1) copyright the software, and
4570 (2) offer you this license which gives you legal permission to copy,
4571 distribute and/or modify the software.
4573 Also, for each author's protection and ours, we want to make certain
4574 that everyone understands that there is no warranty for this free
4575 software. If the software is modified by someone else and passed on, we
4576 want its recipients to know that what they have is not the original, so
4577 that any problems introduced by others will not reflect on the original
4578 authors' reputations.
4580 Finally, any free program is threatened constantly by software
4581 patents. We wish to avoid the danger that redistributors of a free
4582 program will individually obtain patent licenses, in effect making the
4583 program proprietary. To prevent this, we have made it clear that any
4584 patent must be licensed for everyone's free use or not licensed at all.
4586 The precise terms and conditions for copying, distribution and
4587 modification follow.
4590 @unnumberedsec TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
4593 @center TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
4598 This License applies to any program or other work which contains
4599 a notice placed by the copyright holder saying it may be distributed
4600 under the terms of this General Public License. The ``Program'', below,
4601 refers to any such program or work, and a ``work based on the Program''
4602 means either the Program or any derivative work under copyright law:
4603 that is to say, a work containing the Program or a portion of it,
4604 either verbatim or with modifications and/or translated into another
4605 language. (Hereinafter, translation is included without limitation in
4606 the term ``modification''.) Each licensee is addressed as ``you''.
4608 Activities other than copying, distribution and modification are not
4609 covered by this License; they are outside its scope. The act of
4610 running the Program is not restricted, and the output from the Program
4611 is covered only if its contents constitute a work based on the
4612 Program (independent of having been made by running the Program).
4613 Whether that is true depends on what the Program does.
4616 You may copy and distribute verbatim copies of the Program's
4617 source code as you receive it, in any medium, provided that you
4618 conspicuously and appropriately publish on each copy an appropriate
4619 copyright notice and disclaimer of warranty; keep intact all the
4620 notices that refer to this License and to the absence of any warranty;
4621 and give any other recipients of the Program a copy of this License
4622 along with the Program.
4624 You may charge a fee for the physical act of transferring a copy, and
4625 you may at your option offer warranty protection in exchange for a fee.
4628 You may modify your copy or copies of the Program or any portion
4629 of it, thus forming a work based on the Program, and copy and
4630 distribute such modifications or work under the terms of Section 1
4631 above, provided that you also meet all of these conditions:
4635 You must cause the modified files to carry prominent notices
4636 stating that you changed the files and the date of any change.
4639 You must cause any work that you distribute or publish, that in
4640 whole or in part contains or is derived from the Program or any
4641 part thereof, to be licensed as a whole at no charge to all third
4642 parties under the terms of this License.
4645 If the modified program normally reads commands interactively
4646 when run, you must cause it, when started running for such
4647 interactive use in the most ordinary way, to print or display an
4648 announcement including an appropriate copyright notice and a
4649 notice that there is no warranty (or else, saying that you provide
4650 a warranty) and that users may redistribute the program under
4651 these conditions, and telling the user how to view a copy of this
4652 License. (Exception: if the Program itself is interactive but
4653 does not normally print such an announcement, your work based on
4654 the Program is not required to print an announcement.)
4657 These requirements apply to the modified work as a whole. If
4658 identifiable sections of that work are not derived from the Program,
4659 and can be reasonably considered independent and separate works in
4660 themselves, then this License, and its terms, do not apply to those
4661 sections when you distribute them as separate works. But when you
4662 distribute the same sections as part of a whole which is a work based
4663 on the Program, the distribution of the whole must be on the terms of
4664 this License, whose permissions for other licensees extend to the
4665 entire whole, and thus to each and every part regardless of who wrote it.
4667 Thus, it is not the intent of this section to claim rights or contest
4668 your rights to work written entirely by you; rather, the intent is to
4669 exercise the right to control the distribution of derivative or
4670 collective works based on the Program.
4672 In addition, mere aggregation of another work not based on the Program
4673 with the Program (or with a work based on the Program) on a volume of
4674 a storage or distribution medium does not bring the other work under
4675 the scope of this License.
4678 You may copy and distribute the Program (or a work based on it,
4679 under Section 2) in object code or executable form under the terms of
4680 Sections 1 and 2 above provided that you also do one of the following:
4684 Accompany it with the complete corresponding machine-readable
4685 source code, which must be distributed under the terms of Sections
4686 1 and 2 above on a medium customarily used for software interchange; or,
4689 Accompany it with a written offer, valid for at least three
4690 years, to give any third party, for a charge no more than your
4691 cost of physically performing source distribution, a complete
4692 machine-readable copy of the corresponding source code, to be
4693 distributed under the terms of Sections 1 and 2 above on a medium
4694 customarily used for software interchange; or,
4697 Accompany it with the information you received as to the offer
4698 to distribute corresponding source code. (This alternative is
4699 allowed only for noncommercial distribution and only if you
4700 received the program in object code or executable form with such
4701 an offer, in accord with Subsection b above.)
4704 The source code for a work means the preferred form of the work for
4705 making modifications to it. For an executable work, complete source
4706 code means all the source code for all modules it contains, plus any
4707 associated interface definition files, plus the scripts used to
4708 control compilation and installation of the executable. However, as a
4709 special exception, the source code distributed need not include
4710 anything that is normally distributed (in either source or binary
4711 form) with the major components (compiler, kernel, and so on) of the
4712 operating system on which the executable runs, unless that component
4713 itself accompanies the executable.
4715 If distribution of executable or object code is made by offering
4716 access to copy from a designated place, then offering equivalent
4717 access to copy the source code from the same place counts as
4718 distribution of the source code, even though third parties are not
4719 compelled to copy the source along with the object code.
4722 You may not copy, modify, sublicense, or distribute the Program
4723 except as expressly provided under this License. Any attempt
4724 otherwise to copy, modify, sublicense or distribute the Program is
4725 void, and will automatically terminate your rights under this License.
4726 However, parties who have received copies, or rights, from you under
4727 this License will not have their licenses terminated so long as such
4728 parties remain in full compliance.
4731 You are not required to accept this License, since you have not
4732 signed it. However, nothing else grants you permission to modify or
4733 distribute the Program or its derivative works. These actions are
4734 prohibited by law if you do not accept this License. Therefore, by
4735 modifying or distributing the Program (or any work based on the
4736 Program), you indicate your acceptance of this License to do so, and
4737 all its terms and conditions for copying, distributing or modifying
4738 the Program or works based on it.
4741 Each time you redistribute the Program (or any work based on the
4742 Program), the recipient automatically receives a license from the
4743 original licensor to copy, distribute or modify the Program subject to
4744 these terms and conditions. You may not impose any further
4745 restrictions on the recipients' exercise of the rights granted herein.
4746 You are not responsible for enforcing compliance by third parties to
4750 If, as a consequence of a court judgment or allegation of patent
4751 infringement or for any other reason (not limited to patent issues),
4752 conditions are imposed on you (whether by court order, agreement or
4753 otherwise) that contradict the conditions of this License, they do not
4754 excuse you from the conditions of this License. If you cannot
4755 distribute so as to satisfy simultaneously your obligations under this
4756 License and any other pertinent obligations, then as a consequence you
4757 may not distribute the Program at all. For example, if a patent
4758 license would not permit royalty-free redistribution of the Program by
4759 all those who receive copies directly or indirectly through you, then
4760 the only way you could satisfy both it and this License would be to
4761 refrain entirely from distribution of the Program.
4763 If any portion of this section is held invalid or unenforceable under
4764 any particular circumstance, the balance of the section is intended to
4765 apply and the section as a whole is intended to apply in other
4768 It is not the purpose of this section to induce you to infringe any
4769 patents or other property right claims or to contest validity of any
4770 such claims; this section has the sole purpose of protecting the
4771 integrity of the free software distribution system, which is
4772 implemented by public license practices. Many people have made
4773 generous contributions to the wide range of software distributed
4774 through that system in reliance on consistent application of that
4775 system; it is up to the author/donor to decide if he or she is willing
4776 to distribute software through any other system and a licensee cannot
4779 This section is intended to make thoroughly clear what is believed to
4780 be a consequence of the rest of this License.
4783 If the distribution and/or use of the Program is restricted in
4784 certain countries either by patents or by copyrighted interfaces, the
4785 original copyright holder who places the Program under this License
4786 may add an explicit geographical distribution limitation excluding
4787 those countries, so that distribution is permitted only in or among
4788 countries not thus excluded. In such case, this License incorporates
4789 the limitation as if written in the body of this License.
4792 The Free Software Foundation may publish revised and/or new versions
4793 of the General Public License from time to time. Such new versions will
4794 be similar in spirit to the present version, but may differ in detail to
4795 address new problems or concerns.
4797 Each version is given a distinguishing version number. If the Program
4798 specifies a version number of this License which applies to it and ``any
4799 later version'', you have the option of following the terms and conditions
4800 either of that version or of any later version published by the Free
4801 Software Foundation. If the Program does not specify a version number of
4802 this License, you may choose any version ever published by the Free Software
4806 If you wish to incorporate parts of the Program into other free
4807 programs whose distribution conditions are different, write to the author
4808 to ask for permission. For software which is copyrighted by the Free
4809 Software Foundation, write to the Free Software Foundation; we sometimes
4810 make exceptions for this. Our decision will be guided by the two goals
4811 of preserving the free status of all derivatives of our free software and
4812 of promoting the sharing and reuse of software generally.
4815 @heading NO WARRANTY
4822 BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
4823 FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
4824 OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
4825 PROVIDE THE PROGRAM ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
4826 OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
4827 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
4828 TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
4829 PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
4830 REPAIR OR CORRECTION.
4833 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
4834 WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
4835 REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
4836 INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
4837 OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
4838 TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
4839 YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
4840 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
4841 POSSIBILITY OF SUCH DAMAGES.
4845 @heading END OF TERMS AND CONDITIONS
4848 @center END OF TERMS AND CONDITIONS
4852 @unnumberedsec How to Apply These Terms to Your New Programs
4854 If you develop a new program, and you want it to be of the greatest
4855 possible use to the public, the best way to achieve this is to make it
4856 free software which everyone can redistribute and change under these terms.
4858 To do so, attach the following notices to the program. It is safest
4859 to attach them to the start of each source file to most effectively
4860 convey the exclusion of warranty; and each file should have at least
4861 the ``copyright'' line and a pointer to where the full notice is found.
4864 @var{one line to give the program's name and a brief idea of what it does.}
4865 Copyright (C) @var{yyyy} @var{name of author}
4867 This program is free software; you can redistribute it and/or modify
4868 it under the terms of the GNU General Public License as published by
4869 the Free Software Foundation; either version 2 of the License, or
4870 (at your option) any later version.
4872 This program is distributed in the hope that it will be useful,
4873 but WITHOUT ANY WARRANTY; without even the implied warranty of
4874 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
4875 GNU General Public License for more details.
4877 You should have received a copy of the GNU General Public License
4878 along with this program; if not, write to the Free Software
4879 Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
4882 Also add information on how to contact you by electronic and paper mail.
4884 If the program is interactive, make it output a short notice like this
4885 when it starts in an interactive mode:
4888 Gnomovision version 69, Copyright (C) @var{yyyy} @var{name of author}
4889 Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
4891 This is free software, and you are welcome to redistribute it
4892 under certain conditions; type `show c' for details.
4895 The hypothetical commands @samp{show w} and @samp{show c} should show
4896 the appropriate parts of the General Public License. Of course, the
4897 commands you use may be called something other than @samp{show w} and
4898 @samp{show c}; they could even be mouse-clicks or menu items---whatever
4901 You should also get your employer (if you work as a programmer) or your
4902 school, if any, to sign a ``copyright disclaimer'' for the program, if
4903 necessary. Here is a sample; alter the names:
4906 Yoyodyne, Inc., hereby disclaims all copyright interest in the program
4907 `Gnomovision' (which makes passes at compilers) written by James Hacker.
4909 @var{signature of Ty Coon}, 1 April 1989
4910 Ty Coon, President of Vice
4913 This General Public License does not permit incorporating your program into
4914 proprietary programs. If your program is a subroutine library, you may
4915 consider it more useful to permit linking proprietary applications with the
4916 library. If this is what you want to do, use the GNU Library General
4917 Public License instead of this License.
4920 @unnumbered Contributors to GCC
4921 @cindex contributors
4922 @include contrib.texi