OpenE2K/gcc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Initial revision

Browse Source 
From-SVN: r16272
This commit is contained in:
Jeff Law 1997-11-02 01:39:28 -07:00
parent 8072f69c31
commit 336b436af5
35 changed files with 33137 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
gcc/auto-config.h Normal file
View File

@ -0,0 +1,43 @@
/* auto-config.h. Generated automatically by configure. */
/* config.in. Generated automatically from configure.in by autoheader. */
/* Whether malloc must be declared even if <stdlib.h> is included. */
/* #undef NEED_DECLARATION_MALLOC */
/* Whether realloc must be declared even if <stdlib.h> is included. */
/* #undef NEED_DECLARATION_REALLOC */
/* Whether calloc must be declared even if <stdlib.h> is included. */
/* #undef NEED_DECLARATION_CALLOC */
/* Whether free must be declared even if <stdlib.h> is included. */
/* #undef NEED_DECLARATION_FREE */
/* Define if `sys_siglist' is declared by <signal.h>. */
#define SYS_SIGLIST_DECLARED 1
/* Define if you have the strerror function. */
#define HAVE_STRERROR 1
/* Define if you have the <inttypes.h> header file. */
/* #undef HAVE_INTTYPES_H */
/* Define if you have the <limits.h> header file. */
#define HAVE_LIMITS_H 1
/* Define if you have the <stddef.h> header file. */
#define HAVE_STDDEF_H 1
/* Define if you have the <stdlib.h> header file. */
#define HAVE_STDLIB_H 1
/* Define if you have the <string.h> header file. */
#define HAVE_STRING_H 1
/* Define if you have the <strings.h> header file. */
#define HAVE_STRINGS_H 1
/* Define if you have the <time.h> header file. */
#define HAVE_TIME_H 1
/* Define if you have the <unistd.h> header file. */
#define HAVE_UNISTD_H 1

75
gcc/cpp.info Normal file
View File

@ -0,0 +1,75 @@
This is Info file cpp.info, produced by Makeinfo version 1.67 from the
input file cpp.texi.
This file documents the GNU C Preprocessor.
Copyright 1987, 1989, 1991, 1992, 1993, 1994, 1995 Free Software
Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the entire resulting derived work is distributed under the terms
of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions.

Indirect:
cpp.info-1: 798
cpp.info-2: 50062
cpp.info-3: 91249

Tag Table:
(Indirect)
Node: Top798
Node: Global Actions3707
Node: Directives6227
Node: Header Files7914
Node: Header Uses8573
Node: Include Syntax10065
Node: Include Operation13207
Node: Once-Only15069
Node: Inheritance17494
Node: Macros20027
Node: Simple Macros20941
Node: Argument Macros23929
Node: Predefined29727
Node: Standard Predefined30157
Node: Nonstandard Predefined37948
Node: Stringification41524
Node: Concatenation44450
Node: Undefining47723
Node: Redefining48762
Node: Macro Pitfalls50062
Node: Misnesting51166
Node: Macro Parentheses52180
Node: Swallow Semicolon54048
Node: Side Effects55948
Node: Self-Reference57646
Node: Argument Prescan59922
Node: Cascaded Macros64924
Node: Newlines in Args66069
Node: Conditionals67414
Node: Conditional Uses68766
Node: Conditional Syntax70189
Node: #if Directive70775
Node: #else Directive73064
Node: #elif Directive73731
Node: Deleted Code75109
Node: Conditionals-Macros76170
Node: Assertions79855
Node: #error Directive84090
Node: Combining Sources85575
Node: Other Directives88486
Node: Output89940
Node: Invocation91249
Node: Concept Index103346
Node: Index106199

End Tag Table

1182
gcc/cpp.info-1 Normal file
View File

File diff suppressed because it is too large Load Diff

1058
gcc/cpp.info-2 Normal file
View File

File diff suppressed because it is too large Load Diff

478
gcc/cpp.info-3 Normal file
View File

@ -0,0 +1,478 @@
This is Info file cpp.info, produced by Makeinfo version 1.67 from the
input file cpp.texi.
This file documents the GNU C Preprocessor.
Copyright 1987, 1989, 1991, 1992, 1993, 1994, 1995 Free Software
Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the entire resulting derived work is distributed under the terms
of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions.

File: cpp.info, Node: Invocation, Next: Concept Index, Prev: Output, Up: Top
Invoking the C Preprocessor
===========================
Most often when you use the C preprocessor you will not have to
invoke it explicitly: the C compiler will do so automatically.
However, the preprocessor is sometimes useful on its own.
The C preprocessor expects two file names as arguments, INFILE and
OUTFILE. The preprocessor reads INFILE together with any other files
it specifies with `#include'. All the output generated by the combined
input files is written in OUTFILE.
Either INFILE or OUTFILE may be `-', which as INFILE means to read
from standard input and as OUTFILE means to write to standard output.
Also, if OUTFILE or both file names are omitted, the standard output
and standard input are used for the omitted file names.
Here is a table of command options accepted by the C preprocessor.
These options can also be given when compiling a C program; they are
passed along automatically to the preprocessor when it is invoked by the
compiler.
`-P'
Inhibit generation of `#'-lines with line-number information in
the output from the preprocessor (*note Output::.). This might be
useful when running the preprocessor on something that is not C
code and will be sent to a program which might be confused by the
`#'-lines.
`-C'
Do not discard comments: pass them through to the output file.
Comments appearing in arguments of a macro call will be copied to
the output before the expansion of the macro call.
`-traditional'
Try to imitate the behavior of old-fashioned C, as opposed to ANSI
C.
* Traditional macro expansion pays no attention to singlequote
or doublequote characters; macro argument symbols are
replaced by the argument values even when they appear within
apparent string or character constants.
* Traditionally, it is permissible for a macro expansion to end
in the middle of a string or character constant. The
constant continues into the text surrounding the macro call.
* However, traditionally the end of the line terminates a
string or character constant, with no error.
* In traditional C, a comment is equivalent to no text at all.
(In ANSI C, a comment counts as whitespace.)
* Traditional C does not have the concept of a "preprocessing
number". It considers `1.0e+4' to be three tokens: `1.0e',
`+', and `4'.
* A macro is not suppressed within its own definition, in
traditional C. Thus, any macro that is used recursively
inevitably causes an error.
* The character `#' has no special meaning within a macro
definition in traditional C.
* In traditional C, the text at the end of a macro expansion
can run together with the text after the macro call, to
produce a single token. (This is impossible in ANSI C.)
* Traditionally, `\' inside a macro argument suppresses the
syntactic significance of the following character.
`-trigraphs'
Process ANSI standard trigraph sequences. These are
three-character sequences, all starting with `??', that are
defined by ANSI C to stand for single characters. For example,
`??/' stands for `\', so `'??/n'' is a character constant for a
newline. Strictly speaking, the GNU C preprocessor does not
support all programs in ANSI Standard C unless `-trigraphs' is
used, but if you ever notice the difference it will be with relief.
You don't want to know any more about trigraphs.
`-pedantic'
Issue warnings required by the ANSI C standard in certain cases
such as when text other than a comment follows `#else' or `#endif'.
`-pedantic-errors'
Like `-pedantic', except that errors are produced rather than
warnings.
`-Wtrigraphs'
Warn if any trigraphs are encountered (assuming they are enabled).
`-Wcomment'
Warn whenever a comment-start sequence `/*' appears in a `/*'
comment, or whenever a Backslash-Newline appears in a `//' comment.
`-Wall'
Requests both `-Wtrigraphs' and `-Wcomment' (but not
`-Wtraditional' or `-Wundef').
`-Wtraditional'
Warn about certain constructs that behave differently in
traditional and ANSI C.
`-Wundef'
Warn if an undefined identifier is evaluated in an `#if' directive.
`-I DIRECTORY'
Add the directory DIRECTORY to the head of the list of directories
to be searched for header files (*note Include Syntax::.). This
can be used to override a system header file, substituting your
own version, since these directories are searched before the system
header file directories. If you use more than one `-I' option,
the directories are scanned in left-to-right order; the standard
system directories come after.
`-I-'
Any directories specified with `-I' options before the `-I-'
option are searched only for the case of `#include "FILE"'; they
are not searched for `#include <FILE>'.
If additional directories are specified with `-I' options after
the `-I-', these directories are searched for all `#include'
directives.
In addition, the `-I-' option inhibits the use of the current
directory as the first search directory for `#include "FILE"'.
Therefore, the current directory is searched only if it is
requested explicitly with `-I.'. Specifying both `-I-' and `-I.'
allows you to control precisely which directories are searched
before the current one and which are searched after.
`-nostdinc'
Do not search the standard system directories for header files.
Only the directories you have specified with `-I' options (and the
current directory, if appropriate) are searched.
`-nostdinc++'
Do not search for header files in the C++-specific standard
directories, but do still search the other standard directories.
(This option is used when building libg++.)
`-D NAME'
Predefine NAME as a macro, with definition `1'.
`-D NAME=DEFINITION'
Predefine NAME as a macro, with definition DEFINITION. There are
no restrictions on the contents of DEFINITION, but if you are
invoking the preprocessor from a shell or shell-like program you
may need to use the shell's quoting syntax to protect characters
such as spaces that have a meaning in the shell syntax. If you
use more than one `-D' for the same NAME, the rightmost definition
takes effect.
`-U NAME'
Do not predefine NAME. If both `-U' and `-D' are specified for
one name, the `-U' beats the `-D' and the name is not predefined.
`-undef'
Do not predefine any nonstandard macros.
`-A PREDICATE(ANSWER)'
Make an assertion with the predicate PREDICATE and answer ANSWER.
*Note Assertions::.
You can use `-A-' to disable all predefined assertions; it also
undefines all predefined macros that identify the type of target
system.
`-dM'
Instead of outputting the result of preprocessing, output a list of
`#define' directives for all the macros defined during the
execution of the preprocessor, including predefined macros. This
gives you a way of finding out what is predefined in your version
of the preprocessor; assuming you have no file `foo.h', the command
touch foo.h; cpp -dM foo.h
will show the values of any predefined macros.
`-dD'
Like `-dM' except in two respects: it does *not* include the
predefined macros, and it outputs *both* the `#define' directives
and the result of preprocessing. Both kinds of output go to the
standard output file.
`-dI'
Output `#include' directives in addition to the result of
preprocessing.
`-M [-MG]'
Instead of outputting the result of preprocessing, output a rule
suitable for `make' describing the dependencies of the main source
file. The preprocessor outputs one `make' rule containing the
object file name for that source file, a colon, and the names of
all the included files. If there are many included files then the
rule is split into several lines using `\'-newline.
`-MG' says to treat missing header files as generated files and
assume they live in the same directory as the source file. It
must be specified in addition to `-M'.
This feature is used in automatic updating of makefiles.
`-MM [-MG]'
Like `-M' but mention only the files included with `#include
"FILE"'. System header files included with `#include <FILE>' are
omitted.
`-MD FILE'
Like `-M' but the dependency information is written to FILE. This
is in addition to compiling the file as specified--`-MD' does not
inhibit ordinary compilation the way `-M' does.
When invoking gcc, do not specify the FILE argument. Gcc will
create file names made by replacing ".c" with ".d" at the end of
the input file names.
In Mach, you can use the utility `md' to merge multiple dependency
files into a single dependency file suitable for using with the
`make' command.
`-MMD FILE'
Like `-MD' except mention only user header files, not system
header files.
`-H'
Print the name of each header file used, in addition to other
normal activities.
`-imacros FILE'
Process FILE as input, discarding the resulting output, before
processing the regular input file. Because the output generated
from FILE is discarded, the only effect of `-imacros FILE' is to
make the macros defined in FILE available for use in the main
input.
`-include FILE'
Process FILE as input, and include all the resulting output,
before processing the regular input file.
`-idirafter DIR'
Add the directory DIR to the second include path. The directories
on the second include path are searched when a header file is not
found in any of the directories in the main include path (the one
that `-I' adds to).
`-iprefix PREFIX'
Specify PREFIX as the prefix for subsequent `-iwithprefix' options.
`-iwithprefix DIR'
Add a directory to the second include path. The directory's name
is made by concatenating PREFIX and DIR, where PREFIX was
specified previously with `-iprefix'.
`-isystem DIR'
Add a directory to the beginning of the second include path,
marking it as a system directory, so that it gets the same special
treatment as is applied to the standard system directories.
`-lang-c'
`-lang-c89'
`-lang-c++'
`-lang-objc'
`-lang-objc++'
Specify the source language. `-lang-c' is the default; it allows
recognition of C++ comments (comments that begin with `//' and end
at end of line) and hexadecimal floating-point constants, since
these features will most likely appear in the next C standard.
`-lang-c89' disables recognition of C++ comments and hexadecimal
floating-point constants. `-lang-c++' handles C++ comment syntax
and includes extra default include directories for C++.
`-lang-objc' enables the Objective C `#import' directive.
`-lang-objc++' enables both C++ and Objective C extensions.
These options are generated by the compiler driver `gcc', but not
passed from the `gcc' command line unless you use the driver's
`-Wp' option.
`-lint'
Look for commands to the program checker `lint' embedded in
comments, and emit them preceded by `#pragma lint'. For example,
the comment `/* NOTREACHED */' becomes `#pragma lint NOTREACHED'.
This option is available only when you call `cpp' directly; `gcc'
will not pass it from its command line.
`-$'
Forbid the use of `$' in identifiers. This was formerly required
for strict conformance to the C Standard before the standard was
corrected.
This option is available only when you call `cpp' directly; `gcc'
will not pass it from its command line.

File: cpp.info, Node: Concept Index, Next: Index, Prev: Invocation, Up: Top
Concept Index
*************
* Menu:
* ##: Concatenation.
* arguments in macro definitions: Argument Macros.
* assertions: Assertions.
* assertions, undoing: Assertions.
* blank macro arguments: Argument Macros.
* cascaded macros: Cascaded Macros.
* commenting out code: Deleted Code.
* computed #include: Include Syntax.
* concatenation: Concatenation.
* conditionals: Conditionals.
* directives: Directives.
* expansion of arguments: Argument Prescan.
* function-like macro: Argument Macros.
* header file: Header Files.
* including just once: Once-Only.
* inheritance: Inheritance.
* invocation of the preprocessor: Invocation.
* line control: Combining Sources.
* macro argument expansion: Argument Prescan.
* macro body uses macro: Cascaded Macros.
* macros with argument: Argument Macros.
* manifest constant: Simple Macros.
* newlines in macro arguments: Newlines in Args.
* null directive: Other Directives.
* options: Invocation.
* output format: Output.
* overriding a header file: Inheritance.
* parentheses in macro bodies: Macro Parentheses.
* pitfalls of macros: Macro Pitfalls.
* predefined macros: Predefined.
* predicates: Assertions.
* preprocessing directives: Directives.
* prescan of macro arguments: Argument Prescan.
* problems with macros: Macro Pitfalls.
* redefining macros: Redefining.
* repeated inclusion: Once-Only.
* retracting assertions: Assertions.
* second include path: Invocation.
* self-reference: Self-Reference.
* semicolons (after macro calls): Swallow Semicolon.
* side effects (in macro arguments): Side Effects.
* simple macro: Simple Macros.
* space as macro argument: Argument Macros.
* standard predefined macros: Standard Predefined.
* stringification: Stringification.
* testing predicates: Assertions.
* unassert: Assertions.
* undefining macros: Undefining.
* unsafe macros: Side Effects.

File: cpp.info, Node: Index, Prev: Concept Index, Up: Top
Index of Directives, Macros and Options
***************************************
* Menu:
* #assert: Assertions.
* #cpu: Assertions.
* #define: Argument Macros.
* #elif: #elif Directive.
* #else: #else Directive.
* #error: #error Directive.
* #ident: Other Directives.
* #if: Conditional Syntax.
* #ifdef: Conditionals-Macros.
* #ifndef: Conditionals-Macros.
* #import: Once-Only.
* #include: Include Syntax.
* #include_next: Inheritance.
* #line: Combining Sources.
* #machine: Assertions.
* #pragma: Other Directives.
* #pragma once: Once-Only.
* #system: Assertions.
* #unassert: Assertions.
* #warning: #error Directive.
* -$: Invocation.
* -A: Invocation.
* -C: Invocation.
* -D: Invocation.
* -dD: Invocation.
* -dI: Invocation.
* -dM: Invocation.
* -H: Invocation.
* -I: Invocation.
* -idirafter: Invocation.
* -imacros: Invocation.
* -include: Invocation.
* -iprefix: Invocation.
* -isystem: Invocation.
* -iwithprefix: Invocation.
* -lang-c: Invocation.
* -lang-c++: Invocation.
* -lang-c89: Invocation.
* -lang-objc: Invocation.
* -lang-objc++: Invocation.
* -M: Invocation.
* -MD: Invocation.
* -MM: Invocation.
* -MMD: Invocation.
* -nostdinc: Invocation.
* -nostdinc++: Invocation.
* -P: Invocation.
* -pedantic: Invocation.
* -pedantic-errors: Invocation.
* -traditional: Invocation.
* -trigraphs: Invocation.
* -U: Invocation.
* -undef: Invocation.
* -Wall: Invocation.
* -Wcomment: Invocation.
* -Wtraditional: Invocation.
* -Wtrigraphs: Invocation.
* -Wundef: Invocation.
* __BASE_FILE__: Standard Predefined.
* __CHAR_UNSIGNED__: Standard Predefined.
* __cplusplus: Standard Predefined.
* __DATE__: Standard Predefined.
* __FILE__: Standard Predefined.
* __GNUC__: Standard Predefined.
* __GNUC_MINOR__: Standard Predefined.
* __GNUG__: Standard Predefined.
* __INCLUDE_LEVEL_: Standard Predefined.
* __LINE__: Standard Predefined.
* __OPTIMIZE__: Standard Predefined.
* __REGISTER_PREFIX__: Standard Predefined.
* __STDC__: Standard Predefined.
* __STDC_VERSION__: Standard Predefined.
* __STRICT_ANSI__: Standard Predefined.
* __TIME__: Standard Predefined.
* __USER_LABEL_PREFIX__: Standard Predefined.
* __VERSION__: Standard Predefined.
* _AM29000: Nonstandard Predefined.
* _AM29K: Nonstandard Predefined.
* BSD: Nonstandard Predefined.
* defined: Conditionals-Macros.
* M68020: Nonstandard Predefined.
* m68k: Nonstandard Predefined.
* mc68000: Nonstandard Predefined.
* ns32000: Nonstandard Predefined.
* pyr: Nonstandard Predefined.
* sequent: Nonstandard Predefined.
* sun: Nonstandard Predefined.
* system header files: Header Uses.
* unix: Nonstandard Predefined.
* vax: Nonstandard Predefined.

1
gcc/cstamp-h Normal file
View File

@ -0,0 +1 @@

312
gcc/gcc.info Normal file
View File

@ -0,0 +1,312 @@
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
input file gcc.texi.
This file documents the use and the internals of the GNU compiler.
Published by the Free Software Foundation 59 Temple Place - Suite 330
Boston, MA 02111-1307 USA
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997 Free
Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License," "Funding for
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License," "Funding for Free Software," and "Protect Your Freedom--Fight
`Look And Feel'", and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.

Indirect:
gcc.info-1: 1402
gcc.info-2: 50964
gcc.info-3: 96983
gcc.info-4: 143917
gcc.info-5: 192350
gcc.info-6: 225344
gcc.info-7: 249300
gcc.info-8: 295618
gcc.info-9: 344449
gcc.info-10: 393730
gcc.info-11: 441350
gcc.info-12: 491094
gcc.info-13: 534183
gcc.info-14: 572713
gcc.info-15: 622155
gcc.info-16: 665863
gcc.info-17: 713227
gcc.info-18: 751237
gcc.info-19: 796779
gcc.info-20: 841999
gcc.info-21: 891870
gcc.info-22: 937562
gcc.info-23: 982612
gcc.info-24: 1026075
gcc.info-25: 1072705
gcc.info-26: 1121544
gcc.info-27: 1162761
gcc.info-28: 1187258

Tag Table:
(Indirect)
Node: Top1402
Node: G++ and GCC3216
Node: Invoking GCC5423
Node: Option Summary8802
Node: Overall Options20950
Node: Invoking G++25513
Node: C Dialect Options27386
Node: C++ Dialect Options38688
Node: Warning Options50964
Node: Debugging Options68134
Node: Optimize Options84249
Node: Preprocessor Options96983
Node: Assembler Options103446
Node: Link Options103813
Node: Directory Options109086
Node: Target Options112951
Node: Submodel Options116608
Node: M680x0 Options118040
Node: VAX Options122970
Node: SPARC Options123505
Node: Convex Options132591
Node: AMD29K Options134772
Node: ARM Options137997
Node: M32R/D Options141571
Node: M88K Options143917
Node: RS/6000 and PowerPC Options151867
Node: RT Options170743
Node: MIPS Options172447
Node: i386 Options180547
Node: HPPA Options185990
Node: Intel 960 Options189810
Node: DEC Alpha Options192350
Node: Clipper Options199428
Node: H8/300 Options199827
Node: SH Options200641
Node: System V Options201237
Node: V850 Options202046
Node: Code Gen Options204031
Node: Environment Variables214892
Node: Running Protoize219115
Node: Installation225344
Node: Configurations249300
Node: Other Dir287877
Node: Cross-Compiler289593
Node: Steps of Cross291424
Node: Configure Cross292542
Node: Tools and Libraries293179
Node: Cross Runtime295618
Node: Cross Headers299699
Node: Build Cross301698
Node: Sun Install303574
Node: VMS Install305042
Node: Collect2314971
Node: Header Dirs317680
Node: C Extensions319094
Node: Statement Exprs322450
Node: Local Labels324344
Node: Labels as Values326406
Node: Nested Functions328270
Node: Constructing Calls332126
Node: Naming Types334183
Node: Typeof335277
Node: Lvalues337142
Node: Conditionals339582
Node: Long Long340473
Node: Complex341913
Node: Zero Length343775
Node: Variable Length344449
Node: Macro Varargs346974
Node: Subscripting349077
Node: Pointer Arith349560
Node: Initializers350125
Node: Constructors350590
Node: Labeled Elements352284
Node: Case Ranges354913
Node: Cast to Union355594
Node: Function Attributes356672
Node: Function Prototypes371569
Node: C++ Comments373371
Node: Dollar Signs373907
Node: Character Escapes374365
Node: Alignment374652
Node: Variable Attributes376124
Node: Type Attributes384657
Node: Inline393730
Node: Extended Asm397607
Node: Asm Labels408173
Node: Explicit Reg Vars409492
Node: Global Reg Vars410740
Node: Local Reg Vars415305
Node: Alternate Keywords416897
Node: Incomplete Enums418299
Node: Function Names419055
Node: Return Address420329
Node: C++ Extensions422349
Node: Naming Results423583
Node: Min and Max426897
Node: Destructors and Goto428337
Node: C++ Interface428813
Node: Template Instantiation434047
Node: C++ Signatures441350
Node: Gcov445694
Node: Gcov Intro446217
Node: Invoking Gcov448898
Node: Gcov and Optimization454509
Node: Gcov Data Files455933
Node: Trouble459503
Node: Actual Bugs461204
Node: Installation Problems462473
Node: Cross-Compiler Problems476259
Node: Interoperation477730
Node: External Bugs491094
Node: Incompatibilities493226
Node: Fixed Headers501776
Node: Standard Libraries504118
Node: Disappointments505365
Node: C++ Misunderstandings509922
Node: Static Definitions510569
Node: Temporaries511623
Node: Protoize Caveats513827
Node: Non-bugs517783
Node: Warnings and Errors527210
Node: Bugs528980
Node: Bug Criteria530340
Node: Bug Lists532770
Node: Bug Reporting534183
Node: Sending Patches546601
Node: Service551988
Node: Contributing552558
Node: VMS553394
Node: Include Files and VMS553792
Node: Global Declarations557682
Node: VMS Misc561991
Node: Portability566317
Node: Interface568080
Node: Passes572713
Node: RTL590056
Node: RTL Objects591944
Node: Accessors594988
Node: Flags600314
Node: Machine Modes609333
Node: Constants616967
Node: Regs and Memory622155
Node: Arithmetic634208
Node: Comparisons640106
Node: Bit Fields644169
Node: Conversions645581
Node: RTL Declarations648469
Node: Side Effects649278
Node: Incdec661825
Node: Assembler664341
Node: Insns665863
Node: Calls688341
Node: Sharing690936
Node: Reading RTL694012
Node: Machine Desc694951
Node: Patterns696804
Node: Example699748
Node: RTL Template700876
Node: Output Template713227
Node: Output Statement717209
Node: Constraints720922
Node: Simple Constraints721925
Node: Multi-Alternative733837
Node: Class Preferences736673
Node: Modifiers737553
Node: Machine Constraints741097
Node: No Constraints750116
Node: Standard Names751237
Node: Pattern Ordering783426
Node: Dependent Patterns784653
Node: Jump Patterns787468
Node: Insn Canonicalizations793284
Node: Peephole Definitions796779
Node: Expander Definitions803697
Node: Insn Splitting811143
Node: Insn Attributes818158
Node: Defining Attributes819205
Node: Expressions821217
Node: Tagging Insns827525
Node: Attr Example831888
Node: Insn Lengths834264
Node: Constant Attributes837628
Node: Delay Slots838788
Node: Function Units841999
Node: Target Macros847669
Node: Driver849552
Node: Run-time Target863850
Node: Storage Layout869736
Node: Type Layout885097
Node: Registers891870
Node: Register Basics892850
Node: Allocation Order896887
Node: Values in Registers898305
Node: Leaf Functions902931
Node: Stack Registers905406
Node: Obsolete Register Macros906239
Node: Register Classes908822
Node: Stack and Calling928897
Node: Frame Layout929352
Node: Stack Checking933982
Node: Frame Registers937562
Node: Elimination941977
Node: Stack Arguments946233
Node: Register Arguments952841
Node: Scalar Return962634
Node: Aggregate Return966872
Node: Caller Saves970587
Node: Function Entry971737
Node: Profiling982612
Node: Varargs989691
Node: Trampolines997101
Node: Library Calls1003819
Node: Addressing Modes1011877
Node: Condition Code1019876
Node: Costs1026075
Node: Sections1034786
Node: PIC1040969
Node: Assembler Format1043679
Node: File Framework1044745
Node: Data Output1049443
Node: Uninitialized Data1056637
Node: Label Output1062043
Node: Initialization1072705
Node: Macros for Initialization1078848
Node: Instruction Output1083445
Node: Dispatch Tables1091632
Node: Exception Region Output1094079
Node: Alignment Output1097073
Node: Debugging Info1098821
Node: All Debuggers1099430
Node: DBX Options1101875
Node: DBX Hooks1107158
Node: File Names and DBX1110798
Node: SDB and DWARF1112771
Node: Cross-compilation1114978
Node: Misc1121544
Node: Config1139585
Node: Fragments1147323
Node: Target Fragment1147922
Node: Host Fragment1152088
Node: Funding1152690
Node: Look and Feel1155184
Node: Copying1162761
Node: Contributors1181953
Node: Index1187258

End Tag Table

1154
gcc/gcc.info-1 Normal file
View File

File diff suppressed because it is too large Load Diff

1079
gcc/gcc.info-10 Normal file
View File

File diff suppressed because it is too large Load Diff

1162
gcc/gcc.info-11 Normal file
View File

File diff suppressed because it is too large Load Diff

999
gcc/gcc.info-12 Normal file
View File

@ -0,0 +1,999 @@
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
input file gcc.texi.
This file documents the use and the internals of the GNU compiler.
Published by the Free Software Foundation 59 Temple Place - Suite 330
Boston, MA 02111-1307 USA
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997 Free
Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License," "Funding for
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License," "Funding for Free Software," and "Protect Your Freedom--Fight
`Look And Feel'", and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.

File: gcc.info, Node: External Bugs, Next: Incompatibilities, Prev: Interoperation, Up: Trouble
Problems Compiling Certain Programs
===================================
Certain programs have problems compiling.
* Parse errors may occur compiling X11 on a Decstation running
Ultrix 4.2 because of problems in DEC's versions of the X11 header
files `X11/Xlib.h' and `X11/Xutil.h'. People recommend adding
`-I/usr/include/mit' to use the MIT versions of the header files,
using the `-traditional' switch to turn off ANSI C, or fixing the
header files by adding this:
#ifdef __STDC__
#define NeedFunctionPrototypes 0
#endif
* If you have trouble compiling Perl on a SunOS 4 system, it may be
because Perl specifies `-I/usr/ucbinclude'. This accesses the
unfixed header files. Perl specifies the options
-traditional -Dvolatile=__volatile__
-I/usr/include/sun -I/usr/ucbinclude
-fpcc-struct-return
most of which are unnecessary with GCC 2.4.5 and newer versions.
You can make a properly working Perl by setting `ccflags' to
`-fwritable-strings' (implied by the `-traditional' in the
original options) and `cppflags' to empty in `config.sh', then
typing `./doSH; make depend; make'.
* On various 386 Unix systems derived from System V, including SCO,
ISC, and ESIX, you may get error messages about running out of
virtual memory while compiling certain programs.
You can prevent this problem by linking GNU CC with the GNU malloc
(which thus replaces the malloc that comes with the system). GNU
malloc is available as a separate package, and also in the file
`src/gmalloc.c' in the GNU Emacs 19 distribution.
If you have installed GNU malloc as a separate library package,
use this option when you relink GNU CC:
MALLOC=/usr/local/lib/libgmalloc.a
Alternatively, if you have compiled `gmalloc.c' from Emacs 19, copy
the object file to `gmalloc.o' and use this option when you relink
GNU CC:
MALLOC=gmalloc.o

File: gcc.info, Node: Incompatibilities, Next: Fixed Headers, Prev: External Bugs, Up: Trouble
Incompatibilities of GNU CC
===========================
There are several noteworthy incompatibilities between GNU C and most
existing (non-ANSI) versions of C. The `-traditional' option
eliminates many of these incompatibilities, *but not all*, by telling
GNU C to behave like the other C compilers.
* GNU CC normally makes string constants read-only. If several
identical-looking string constants are used, GNU CC stores only one
copy of the string.
One consequence is that you cannot call `mktemp' with a string
constant argument. The function `mktemp' always alters the string
its argument points to.
Another consequence is that `sscanf' does not work on some systems
when passed a string constant as its format control string or
input. This is because `sscanf' incorrectly tries to write into
the string constant. Likewise `fscanf' and `scanf'.
The best solution to these problems is to change the program to use
`char'-array variables with initialization strings for these
purposes instead of string constants. But if this is not possible,
you can use the `-fwritable-strings' flag, which directs GNU CC to
handle string constants the same way most C compilers do.
`-traditional' also has this effect, among others.
* `-2147483648' is positive.
This is because 2147483648 cannot fit in the type `int', so
(following the ANSI C rules) its data type is `unsigned long int'.
Negating this value yields 2147483648 again.
* GNU CC does not substitute macro arguments when they appear inside
of string constants. For example, the following macro in GNU CC
#define foo(a) "a"
will produce output `"a"' regardless of what the argument A is.
The `-traditional' option directs GNU CC to handle such cases
(among others) in the old-fashioned (non-ANSI) fashion.
* When you use `setjmp' and `longjmp', the only automatic variables
guaranteed to remain valid are those declared `volatile'. This is
a consequence of automatic register allocation. Consider this
function:
jmp_buf j;
foo ()
{
int a, b;
a = fun1 ();
if (setjmp (j))
return a;
a = fun2 ();
/* `longjmp (j)' may occur in `fun3'. */
return a + fun3 ();
}
Here `a' may or may not be restored to its first value when the
`longjmp' occurs. If `a' is allocated in a register, then its
first value is restored; otherwise, it keeps the last value stored
in it.
If you use the `-W' option with the `-O' option, you will get a
warning when GNU CC thinks such a problem might be possible.
The `-traditional' option directs GNU C to put variables in the
stack by default, rather than in registers, in functions that call
`setjmp'. This results in the behavior found in traditional C
compilers.
* Programs that use preprocessing directives in the middle of macro
arguments do not work with GNU CC. For example, a program like
this will not work:
foobar (
#define luser
hack)
ANSI C does not permit such a construct. It would make sense to
support it when `-traditional' is used, but it is too much work to
implement.
* Declarations of external variables and functions within a block
apply only to the block containing the declaration. In other
words, they have the same scope as any other declaration in the
same place.
In some other C compilers, a `extern' declaration affects all the
rest of the file even if it happens within a block.
The `-traditional' option directs GNU C to treat all `extern'
declarations as global, like traditional compilers.
* In traditional C, you can combine `long', etc., with a typedef
name, as shown here:
typedef int foo;
typedef long foo bar;
In ANSI C, this is not allowed: `long' and other type modifiers
require an explicit `int'. Because this criterion is expressed by
Bison grammar rules rather than C code, the `-traditional' flag
cannot alter it.
* PCC allows typedef names to be used as function parameters. The
difficulty described immediately above applies here too.
* PCC allows whitespace in the middle of compound assignment
operators such as `+='. GNU CC, following the ANSI standard, does
not allow this. The difficulty described immediately above
applies here too.
* GNU CC complains about unterminated character constants inside of
preprocessing conditionals that fail. Some programs have English
comments enclosed in conditionals that are guaranteed to fail; if
these comments contain apostrophes, GNU CC will probably report an
error. For example, this code would produce an error:
#if 0
You can't expect this to work.
#endif
The best solution to such a problem is to put the text into an
actual C comment delimited by `/*...*/'. However, `-traditional'
suppresses these error messages.
* Many user programs contain the declaration `long time ();'. In the
past, the system header files on many systems did not actually
declare `time', so it did not matter what type your program
declared it to return. But in systems with ANSI C headers, `time'
is declared to return `time_t', and if that is not the same as
`long', then `long time ();' is erroneous.
The solution is to change your program to use `time_t' as the
return type of `time'.
* When compiling functions that return `float', PCC converts it to a
double. GNU CC actually returns a `float'. If you are concerned
with PCC compatibility, you should declare your functions to return
`double'; you might as well say what you mean.
* When compiling functions that return structures or unions, GNU CC
output code normally uses a method different from that used on most
versions of Unix. As a result, code compiled with GNU CC cannot
call a structure-returning function compiled with PCC, and vice
versa.
The method used by GNU CC is as follows: a structure or union
which is 1, 2, 4 or 8 bytes long is returned like a scalar. A
structure or union with any other size is stored into an address
supplied by the caller (usually in a special, fixed register, but
on some machines it is passed on the stack). The
machine-description macros `STRUCT_VALUE' and
`STRUCT_INCOMING_VALUE' tell GNU CC where to pass this address.
By contrast, PCC on most target machines returns structures and
unions of any size by copying the data into an area of static
storage, and then returning the address of that storage as if it
were a pointer value. The caller must copy the data from that
memory area to the place where the value is wanted. GNU CC does
not use this method because it is slower and nonreentrant.
On some newer machines, PCC uses a reentrant convention for all
structure and union returning. GNU CC on most of these machines
uses a compatible convention when returning structures and unions
in memory, but still returns small structures and unions in
registers.
You can tell GNU CC to use a compatible convention for all
structure and union returning with the option
`-fpcc-struct-return'.
* GNU C complains about program fragments such as `0x74ae-0x4000'
which appear to be two hexadecimal constants separated by the minus
operator. Actually, this string is a single "preprocessing token".
Each such token must correspond to one token in C. Since this
does not, GNU C prints an error message. Although it may appear
obvious that what is meant is an operator and two values, the ANSI
C standard specifically requires that this be treated as erroneous.
A "preprocessing token" is a "preprocessing number" if it begins
with a digit and is followed by letters, underscores, digits,
periods and `e+', `e-', `E+', or `E-' character sequences.
To make the above program fragment valid, place whitespace in
front of the minus sign. This whitespace will end the
preprocessing number.

File: gcc.info, Node: Fixed Headers, Next: Standard Libraries, Prev: Incompatibilities, Up: Trouble
Fixed Header Files
==================
GNU CC needs to install corrected versions of some system header
files. This is because most target systems have some header files that
won't work with GNU CC unless they are changed. Some have bugs, some
are incompatible with ANSI C, and some depend on special features of
other compilers.
Installing GNU CC automatically creates and installs the fixed header
files, by running a program called `fixincludes' (or for certain
targets an alternative such as `fixinc.svr4'). Normally, you don't
need to pay attention to this. But there are cases where it doesn't do
the right thing automatically.
* If you update the system's header files, such as by installing a
new system version, the fixed header files of GNU CC are not
automatically updated. The easiest way to update them is to
reinstall GNU CC. (If you want to be clever, look in the makefile
and you can find a shortcut.)
* On some systems, in particular SunOS 4, header file directories
contain machine-specific symbolic links in certain places. This
makes it possible to share most of the header files among hosts
running the same version of SunOS 4 on different machine models.
The programs that fix the header files do not understand this
special way of using symbolic links; therefore, the directory of
fixed header files is good only for the machine model used to
build it.
In SunOS 4, only programs that look inside the kernel will notice
the difference between machine models. Therefore, for most
purposes, you need not be concerned about this.
It is possible to make separate sets of fixed header files for the
different machine models, and arrange a structure of symbolic
links so as to use the proper set, but you'll have to do this by
hand.
* On Lynxos, GNU CC by default does not fix the header files. This
is because bugs in the shell cause the `fixincludes' script to
fail.
This means you will encounter problems due to bugs in the system
header files. It may be no comfort that they aren't GNU CC's
fault, but it does mean that there's nothing for us to do about
them.

File: gcc.info, Node: Standard Libraries, Next: Disappointments, Prev: Fixed Headers, Up: Trouble
Standard Libraries
==================
GNU CC by itself attempts to be what the ISO/ANSI C standard calls a
"conforming freestanding implementation". This means all ANSI C
language features are available, as well as the contents of `float.h',
`limits.h', `stdarg.h', and `stddef.h'. The rest of the C library is
supplied by the vendor of the operating system. If that C library
doesn't conform to the C standards, then your programs might get
warnings (especially when using `-Wall') that you don't expect.
For example, the `sprintf' function on SunOS 4.1.3 returns `char *'
while the C standard says that `sprintf' returns an `int'. The
`fixincludes' program could make the prototype for this function match
the Standard, but that would be wrong, since the function will still
return `char *'.
If you need a Standard compliant library, then you need to find one,
as GNU CC does not provide one. The GNU C library (called `glibc') has
been ported to a number of operating systems, and provides ANSI/ISO,
POSIX, BSD and SystemV compatibility. You could also ask your operating
system vendor if newer libraries are available.

File: gcc.info, Node: Disappointments, Next: C++ Misunderstandings, Prev: Standard Libraries, Up: Trouble
Disappointments and Misunderstandings
=====================================
These problems are perhaps regrettable, but we don't know any
practical way around them.
* Certain local variables aren't recognized by debuggers when you
compile with optimization.
This occurs because sometimes GNU CC optimizes the variable out of
existence. There is no way to tell the debugger how to compute the
value such a variable "would have had", and it is not clear that
would be desirable anyway. So GNU CC simply does not mention the
eliminated variable when it writes debugging information.
You have to expect a certain amount of disagreement between the
executable and your source code, when you use optimization.
* Users often think it is a bug when GNU CC reports an error for code
like this:
int foo (struct mumble *);
struct mumble { ... };
int foo (struct mumble *x)
{ ... }
This code really is erroneous, because the scope of `struct
mumble' in the prototype is limited to the argument list
containing it. It does not refer to the `struct mumble' defined
with file scope immediately below--they are two unrelated types
with similar names in different scopes.
But in the definition of `foo', the file-scope type is used
because that is available to be inherited. Thus, the definition
and the prototype do not match, and you get an error.
This behavior may seem silly, but it's what the ANSI standard
specifies. It is easy enough for you to make your code work by
moving the definition of `struct mumble' above the prototype.
It's not worth being incompatible with ANSI C just to avoid an
error for the example shown above.
* Accesses to bitfields even in volatile objects works by accessing
larger objects, such as a byte or a word. You cannot rely on what
size of object is accessed in order to read or write the bitfield;
it may even vary for a given bitfield according to the precise
usage.
If you care about controlling the amount of memory that is
accessed, use volatile but do not use bitfields.
* GNU CC comes with shell scripts to fix certain known problems in
system header files. They install corrected copies of various
header files in a special directory where only GNU CC will
normally look for them. The scripts adapt to various systems by
searching all the system header files for the problem cases that
we know about.
If new system header files are installed, nothing automatically
arranges to update the corrected header files. You will have to
reinstall GNU CC to fix the new header files. More specifically,
go to the build directory and delete the files `stmp-fixinc' and
`stmp-headers', and the subdirectory `include'; then do `make
install' again.
* On 68000 and x86 systems, for instance, you can get paradoxical
results if you test the precise values of floating point numbers.
For example, you can find that a floating point value which is not
a NaN is not equal to itself. This results from the fact that the
floating point registers hold a few more bits of precision than
fit in a `double' in memory. Compiled code moves values between
memory and floating point registers at its convenience, and moving
them into memory truncates them.
You can partially avoid this problem by using the `-ffloat-store'
option (*note Optimize Options::.).
* On the MIPS, variable argument functions using `varargs.h' cannot
have a floating point value for the first argument. The reason
for this is that in the absence of a prototype in scope, if the
first argument is a floating point, it is passed in a floating
point register, rather than an integer register.
If the code is rewritten to use the ANSI standard `stdarg.h'
method of variable arguments, and the prototype is in scope at the
time of the call, everything will work fine.
* On the H8/300 and H8/300H, variable argument functions must be
implemented using the ANSI standard `stdarg.h' method of variable
arguments. Furthermore, calls to functions using `stdarg.h'
variable arguments must have a prototype for the called function
in scope at the time of the call.

File: gcc.info, Node: C++ Misunderstandings, Next: Protoize Caveats, Prev: Disappointments, Up: Trouble
Common Misunderstandings with GNU C++
=====================================
C++ is a complex language and an evolving one, and its standard
definition (the ANSI C++ draft standard) is also evolving. As a result,
your C++ compiler may occasionally surprise you, even when its behavior
is correct. This section discusses some areas that frequently give
rise to questions of this sort.
* Menu:
* Static Definitions:: Static member declarations are not definitions
* Temporaries:: Temporaries may vanish before you expect

File: gcc.info, Node: Static Definitions, Next: Temporaries, Up: C++ Misunderstandings
Declare *and* Define Static Members
-----------------------------------
When a class has static data members, it is not enough to *declare*
the static member; you must also *define* it. For example:
class Foo
{
...
void method();
static int bar;
};
This declaration only establishes that the class `Foo' has an `int'
named `Foo::bar', and a member function named `Foo::method'. But you
still need to define *both* `method' and `bar' elsewhere. According to
the draft ANSI standard, you must supply an initializer in one (and
only one) source file, such as:
int Foo::bar = 0;
Other C++ compilers may not correctly implement the standard
behavior. As a result, when you switch to `g++' from one of these
compilers, you may discover that a program that appeared to work
correctly in fact does not conform to the standard: `g++' reports as
undefined symbols any static data members that lack definitions.

File: gcc.info, Node: Temporaries, Prev: Static Definitions, Up: C++ Misunderstandings
Temporaries May Vanish Before You Expect
----------------------------------------
It is dangerous to use pointers or references to *portions* of a
temporary object. The compiler may very well delete the object before
you expect it to, leaving a pointer to garbage. The most common place
where this problem crops up is in classes like the libg++ `String'
class, that define a conversion function to type `char *' or `const
char *'. However, any class that returns a pointer to some internal
structure is potentially subject to this problem.
For example, a program may use a function `strfunc' that returns
`String' objects, and another function `charfunc' that operates on
pointers to `char':
String strfunc ();
void charfunc (const char *);
In this situation, it may seem natural to write
`charfunc (strfunc ());' based on the knowledge that class `String' has
an explicit conversion to `char' pointers. However, what really
happens is akin to `charfunc (strfunc ().convert ());', where the
`convert' method is a function to do the same data conversion normally
performed by a cast. Since the last use of the temporary `String'
object is the call to the conversion function, the compiler may delete
that object before actually calling `charfunc'. The compiler has no
way of knowing that deleting the `String' object will invalidate the
pointer. The pointer then points to garbage, so that by the time
`charfunc' is called, it gets an invalid argument.
Code like this may run successfully under some other compilers,
especially those that delete temporaries relatively late. However, the
GNU C++ behavior is also standard-conforming, so if your program depends
on late destruction of temporaries it is not portable.
If you think this is surprising, you should be aware that the ANSI
C++ committee continues to debate the lifetime-of-temporaries problem.
For now, at least, the safe way to write such code is to give the
temporary a name, which forces it to remain until the end of the scope
of the name. For example:
String& tmp = strfunc ();
charfunc (tmp);

File: gcc.info, Node: Protoize Caveats, Next: Non-bugs, Prev: C++ Misunderstandings, Up: Trouble
Caveats of using `protoize'
===========================
The conversion programs `protoize' and `unprotoize' can sometimes
change a source file in a way that won't work unless you rearrange it.
* `protoize' can insert references to a type name or type tag before
the definition, or in a file where they are not defined.
If this happens, compiler error messages should show you where the
new references are, so fixing the file by hand is straightforward.
* There are some C constructs which `protoize' cannot figure out.
For example, it can't determine argument types for declaring a
pointer-to-function variable; this you must do by hand. `protoize'
inserts a comment containing `???' each time it finds such a
variable; so you can find all such variables by searching for this
string. ANSI C does not require declaring the argument types of
pointer-to-function types.
* Using `unprotoize' can easily introduce bugs. If the program
relied on prototypes to bring about conversion of arguments, these
conversions will not take place in the program without prototypes.
One case in which you can be sure `unprotoize' is safe is when you
are removing prototypes that were made with `protoize'; if the
program worked before without any prototypes, it will work again
without them.
You can find all the places where this problem might occur by
compiling the program with the `-Wconversion' option. It prints a
warning whenever an argument is converted.
* Both conversion programs can be confused if there are macro calls
in and around the text to be converted. In other words, the
standard syntax for a declaration or definition must not result
from expanding a macro. This problem is inherent in the design of
C and cannot be fixed. If only a few functions have confusing
macro calls, you can easily convert them manually.
* `protoize' cannot get the argument types for a function whose
definition was not actually compiled due to preprocessing
conditionals. When this happens, `protoize' changes nothing in
regard to such a function. `protoize' tries to detect such
instances and warn about them.
You can generally work around this problem by using `protoize' step
by step, each time specifying a different set of `-D' options for
compilation, until all of the functions have been converted.
There is no automatic way to verify that you have got them all,
however.
* Confusion may result if there is an occasion to convert a function
declaration or definition in a region of source code where there
is more than one formal parameter list present. Thus, attempts to
convert code containing multiple (conditionally compiled) versions
of a single function header (in the same vicinity) may not produce
the desired (or expected) results.
If you plan on converting source files which contain such code, it
is recommended that you first make sure that each conditionally
compiled region of source code which contains an alternative
function header also contains at least one additional follower
token (past the final right parenthesis of the function header).
This should circumvent the problem.
* `unprotoize' can become confused when trying to convert a function
definition or declaration which contains a declaration for a
pointer-to-function formal argument which has the same name as the
function being defined or declared. We recommand you avoid such
choices of formal parameter names.
* You might also want to correct some of the indentation by hand and
break long lines. (The conversion programs don't write lines
longer than eighty characters in any case.)

File: gcc.info, Node: Non-bugs, Next: Warnings and Errors, Prev: Protoize Caveats, Up: Trouble
Certain Changes We Don't Want to Make
=====================================
This section lists changes that people frequently request, but which
we do not make because we think GNU CC is better without them.
* Checking the number and type of arguments to a function which has
an old-fashioned definition and no prototype.
Such a feature would work only occasionally--only for calls that
appear in the same file as the called function, following the
definition. The only way to check all calls reliably is to add a
prototype for the function. But adding a prototype eliminates the
motivation for this feature. So the feature is not worthwhile.
* Warning about using an expression whose type is signed as a shift
count.
Shift count operands are probably signed more often than unsigned.
Warning about this would cause far more annoyance than good.
* Warning about assigning a signed value to an unsigned variable.
Such assignments must be very common; warning about them would
cause more annoyance than good.
* Warning about unreachable code.
It's very common to have unreachable code in machine-generated
programs. For example, this happens normally in some files of GNU
C itself.
* Warning when a non-void function value is ignored.
Coming as I do from a Lisp background, I balk at the idea that
there is something dangerous about discarding a value. There are
functions that return values which some callers may find useful;
it makes no sense to clutter the program with a cast to `void'
whenever the value isn't useful.
* Assuming (for optimization) that the address of an external symbol
is never zero.
This assumption is false on certain systems when `#pragma weak' is
used.
* Making `-fshort-enums' the default.
This would cause storage layout to be incompatible with most other
C compilers. And it doesn't seem very important, given that you
can get the same result in other ways. The case where it matters
most is when the enumeration-valued object is inside a structure,
and in that case you can specify a field width explicitly.
* Making bitfields unsigned by default on particular machines where
"the ABI standard" says to do so.
The ANSI C standard leaves it up to the implementation whether a
bitfield declared plain `int' is signed or not. This in effect
creates two alternative dialects of C.
The GNU C compiler supports both dialects; you can specify the
signed dialect with `-fsigned-bitfields' and the unsigned dialect
with `-funsigned-bitfields'. However, this leaves open the
question of which dialect to use by default.
Currently, the preferred dialect makes plain bitfields signed,
because this is simplest. Since `int' is the same as `signed int'
in every other context, it is cleanest for them to be the same in
bitfields as well.
Some computer manufacturers have published Application Binary
Interface standards which specify that plain bitfields should be
unsigned. It is a mistake, however, to say anything about this
issue in an ABI. This is because the handling of plain bitfields
distinguishes two dialects of C. Both dialects are meaningful on
every type of machine. Whether a particular object file was
compiled using signed bitfields or unsigned is of no concern to
other object files, even if they access the same bitfields in the
same data structures.
A given program is written in one or the other of these two
dialects. The program stands a chance to work on most any machine
if it is compiled with the proper dialect. It is unlikely to work
at all if compiled with the wrong dialect.
Many users appreciate the GNU C compiler because it provides an
environment that is uniform across machines. These users would be
inconvenienced if the compiler treated plain bitfields differently
on certain machines.
Occasionally users write programs intended only for a particular
machine type. On these occasions, the users would benefit if the
GNU C compiler were to support by default the same dialect as the
other compilers on that machine. But such applications are rare.
And users writing a program to run on more than one type of
machine cannot possibly benefit from this kind of compatibility.
This is why GNU CC does and will treat plain bitfields in the same
fashion on all types of machines (by default).
There are some arguments for making bitfields unsigned by default
on all machines. If, for example, this becomes a universal de
facto standard, it would make sense for GNU CC to go along with
it. This is something to be considered in the future.
(Of course, users strongly concerned about portability should
indicate explicitly in each bitfield whether it is signed or not.
In this way, they write programs which have the same meaning in
both C dialects.)
* Undefining `__STDC__' when `-ansi' is not used.
Currently, GNU CC defines `__STDC__' as long as you don't use
`-traditional'. This provides good results in practice.
Programmers normally use conditionals on `__STDC__' to ask whether
it is safe to use certain features of ANSI C, such as function
prototypes or ANSI token concatenation. Since plain `gcc' supports
all the features of ANSI C, the correct answer to these questions
is "yes".
Some users try to use `__STDC__' to check for the availability of
certain library facilities. This is actually incorrect usage in
an ANSI C program, because the ANSI C standard says that a
conforming freestanding implementation should define `__STDC__'
even though it does not have the library facilities. `gcc -ansi
-pedantic' is a conforming freestanding implementation, and it is
therefore required to define `__STDC__', even though it does not
come with an ANSI C library.
Sometimes people say that defining `__STDC__' in a compiler that
does not completely conform to the ANSI C standard somehow
violates the standard. This is illogical. The standard is a
standard for compilers that claim to support ANSI C, such as `gcc
-ansi'--not for other compilers such as plain `gcc'. Whatever the
ANSI C standard says is relevant to the design of plain `gcc'
without `-ansi' only for pragmatic reasons, not as a requirement.
GNU CC normally defines `__STDC__' to be 1, and in addition
defines `__STRICT_ANSI__' if you specify the `-ansi' option. On
some hosts, system include files use a different convention, where
`__STDC__' is normally 0, but is 1 if the user specifies strict
conformance to the C Standard. GNU CC follows the host convention
when processing system include files, but when processing user
files it follows the usual GNU C convention.
* Undefining `__STDC__' in C++.
Programs written to compile with C++-to-C translators get the
value of `__STDC__' that goes with the C compiler that is
subsequently used. These programs must test `__STDC__' to
determine what kind of C preprocessor that compiler uses: whether
they should concatenate tokens in the ANSI C fashion or in the
traditional fashion.
These programs work properly with GNU C++ if `__STDC__' is defined.
They would not work otherwise.
In addition, many header files are written to provide prototypes
in ANSI C but not in traditional C. Many of these header files
can work without change in C++ provided `__STDC__' is defined. If
`__STDC__' is not defined, they will all fail, and will all need
to be changed to test explicitly for C++ as well.
* Deleting "empty" loops.
GNU CC does not delete "empty" loops because the most likely reason
you would put one in a program is to have a delay. Deleting them
will not make real programs run any faster, so it would be
pointless.
It would be different if optimization of a nonempty loop could
produce an empty one. But this generally can't happen.
* Making side effects happen in the same order as in some other
compiler.
It is never safe to depend on the order of evaluation of side
effects. For example, a function call like this may very well
behave differently from one compiler to another:
void func (int, int);
int i = 2;
func (i++, i++);
There is no guarantee (in either the C or the C++ standard language
definitions) that the increments will be evaluated in any
particular order. Either increment might happen first. `func'
might get the arguments `2, 3', or it might get `3, 2', or even
`2, 2'.
* Not allowing structures with volatile fields in registers.
Strictly speaking, there is no prohibition in the ANSI C standard
against allowing structures with volatile fields in registers, but
it does not seem to make any sense and is probably not what you
wanted to do. So the compiler will give an error message in this
case.

File: gcc.info, Node: Warnings and Errors, Prev: Non-bugs, Up: Trouble
Warning Messages and Error Messages
===================================
The GNU compiler can produce two kinds of diagnostics: errors and
warnings. Each kind has a different purpose:
*Errors* report problems that make it impossible to compile your
program. GNU CC reports errors with the source file name and line
number where the problem is apparent.
*Warnings* report other unusual conditions in your code that *may*
indicate a problem, although compilation can (and does) proceed.
Warning messages also report the source file name and line number,
but include the text `warning:' to distinguish them from error
messages.
Warnings may indicate danger points where you should check to make
sure that your program really does what you intend; or the use of
obsolete features; or the use of nonstandard features of GNU C or C++.
Many warnings are issued only if you ask for them, with one of the `-W'
options (for instance, `-Wall' requests a variety of useful warnings).
GNU CC always tries to compile your program if possible; it never
gratuitously rejects a program whose meaning is clear merely because
(for instance) it fails to conform to a standard. In some cases,
however, the C and C++ standards specify that certain extensions are
forbidden, and a diagnostic *must* be issued by a conforming compiler.
The `-pedantic' option tells GNU CC to issue warnings in such cases;
`-pedantic-errors' says to make them errors instead. This does not
mean that *all* non-ANSI constructs get warnings or errors.
*Note Options to Request or Suppress Warnings: Warning Options, for
more detail on these and related command-line options.

File: gcc.info, Node: Bugs, Next: Service, Prev: Trouble, Up: Top
Reporting Bugs
**************
Your bug reports play an essential role in making GNU CC reliable.
When you encounter a problem, the first thing to do is to see if it
is already known. *Note Trouble::. If it isn't known, then you should
report the problem.
Reporting a bug may help you by bringing a solution to your problem,
or it may not. (If it does not, look in the service directory; see
*Note Service::.) In any case, the principal function of a bug report
is to help the entire community by making the next version of GNU CC
work better. Bug reports are your contribution to the maintenance of
GNU CC.
Since the maintainers are very overloaded, we cannot respond to every
bug report. However, if the bug has not been fixed, we are likely to
send you a patch and ask you to tell us whether it works.
In order for a bug report to serve its purpose, you must include the
information that makes for fixing the bug.
* Menu:
* Criteria: Bug Criteria. Have you really found a bug?
* Where: Bug Lists. Where to send your bug report.
* Reporting: Bug Reporting. How to report a bug effectively.
* Patches: Sending Patches. How to send a patch for GNU CC.
* Known: Trouble. Known problems.
* Help: Service. Where to ask for help.

File: gcc.info, Node: Bug Criteria, Next: Bug Lists, Up: Bugs
Have You Found a Bug?
=====================
If you are not sure whether you have found a bug, here are some
guidelines:
* If the compiler gets a fatal signal, for any input whatever, that
is a compiler bug. Reliable compilers never crash.
* If the compiler produces invalid assembly code, for any input
whatever (except an `asm' statement), that is a compiler bug,
unless the compiler reports errors (not just warnings) which would
ordinarily prevent the assembler from being run.
* If the compiler produces valid assembly code that does not
correctly execute the input source code, that is a compiler bug.
However, you must double-check to make sure, because you may have
run into an incompatibility between GNU C and traditional C (*note
Incompatibilities::.). These incompatibilities might be considered
bugs, but they are inescapable consequences of valuable features.
Or you may have a program whose behavior is undefined, which
happened by chance to give the desired results with another C or
C++ compiler.
For example, in many nonoptimizing compilers, you can write `x;'
at the end of a function instead of `return x;', with the same
results. But the value of the function is undefined if `return'
is omitted; it is not a bug when GNU CC produces different results.
Problems often result from expressions with two increment
operators, as in `f (*p++, *p++)'. Your previous compiler might
have interpreted that expression the way you intended; GNU CC might
interpret it another way. Neither compiler is wrong. The bug is
in your code.
After you have localized the error to a single source line, it
should be easy to check for these things. If your program is
correct and well defined, you have found a compiler bug.
* If the compiler produces an error message for valid input, that is
a compiler bug.
* If the compiler does not produce an error message for invalid
input, that is a compiler bug. However, you should note that your
idea of "invalid input" might be my idea of "an extension" or
"support for traditional practice".
* If you are an experienced user of C or C++ compilers, your
suggestions for improvement of GNU CC or GNU C++ are welcome in
any case.

File: gcc.info, Node: Bug Lists, Next: Bug Reporting, Prev: Bug Criteria, Up: Bugs
Where to Report Bugs
====================
Send bug reports for GNU C to `bug-gcc@prep.ai.mit.edu'.
Send bug reports for GNU C++ to `bug-g++@prep.ai.mit.edu'. If your
bug involves the C++ class library libg++, send mail instead to the
address `bug-lib-g++@prep.ai.mit.edu'. If you're not sure, you can
send the bug report to both lists.
*Do not send bug reports to `help-gcc@prep.ai.mit.edu' or to the
newsgroup `gnu.gcc.help'.* Most users of GNU CC do not want to receive
bug reports. Those that do, have asked to be on `bug-gcc' and/or
`bug-g++'.
The mailing lists `bug-gcc' and `bug-g++' both have newsgroups which
serve as repeaters: `gnu.gcc.bug' and `gnu.g++.bug'. Each mailing list
and its newsgroup carry exactly the same messages.
Often people think of posting bug reports to the newsgroup instead of
mailing them. This appears to work, but it has one problem which can be
crucial: a newsgroup posting does not contain a mail path back to the
sender. Thus, if maintainers need more information, they may be unable
to reach you. For this reason, you should always send bug reports by
mail to the proper mailing list.
As a last resort, send bug reports on paper to:
GNU Compiler Bugs
Free Software Foundation
59 Temple Place - Suite 330
Boston, MA 02111-1307, USA

853
gcc/gcc.info-13 Normal file
View File

@ -0,0 +1,853 @@
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
input file gcc.texi.
This file documents the use and the internals of the GNU compiler.
Published by the Free Software Foundation 59 Temple Place - Suite 330
Boston, MA 02111-1307 USA
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997 Free
Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License," "Funding for
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License," "Funding for Free Software," and "Protect Your Freedom--Fight
`Look And Feel'", and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.

File: gcc.info, Node: Bug Reporting, Next: Sending Patches, Prev: Bug Lists, Up: Bugs
How to Report Bugs
==================
The fundamental principle of reporting bugs usefully is this:
*report all the facts*. If you are not sure whether to state a fact or
leave it out, state it!
Often people omit facts because they think they know what causes the
problem and they conclude that some details don't matter. Thus, you
might assume that the name of the variable you use in an example does
not matter. Well, probably it doesn't, but one cannot be sure.
Perhaps the bug is a stray memory reference which happens to fetch from
the location where that name is stored in memory; perhaps, if the name
were different, the contents of that location would fool the compiler
into doing the right thing despite the bug. Play it safe and give a
specific, complete example. That is the easiest thing for you to do,
and the most helpful.
Keep in mind that the purpose of a bug report is to enable someone to
fix the bug if it is not known. It isn't very important what happens if
the bug is already known. Therefore, always write your bug reports on
the assumption that the bug is not known.
Sometimes people give a few sketchy facts and ask, "Does this ring a
bell?" This cannot help us fix a bug, so it is basically useless. We
respond by asking for enough details to enable us to investigate. You
might as well expedite matters by sending them to begin with.
Try to make your bug report self-contained. If we have to ask you
for more information, it is best if you include all the previous
information in your response, as well as the information that was
missing.
Please report each bug in a separate message. This makes it easier
for us to track which bugs have been fixed and to forward your bugs
reports to the appropriate maintainer.
Do not compress and encode any part of your bug report using programs
such as `uuencode'. If you do so it will slow down the processing of
your bug. If you must submit multiple large files, use `shar', which
allows us to read your message without having to run any decompression
programs.
To enable someone to investigate the bug, you should include all
these things:
* The version of GNU CC. You can get this by running it with the
`-v' option.
Without this, we won't know whether there is any point in looking
for the bug in the current version of GNU CC.
* A complete input file that will reproduce the bug. If the bug is
in the C preprocessor, send a source file and any header files
that it requires. If the bug is in the compiler proper (`cc1'),
run your source file through the C preprocessor by doing `gcc -E
SOURCEFILE > OUTFILE', then include the contents of OUTFILE in the
bug report. (When you do this, use the same `-I', `-D' or `-U'
options that you used in actual compilation.)
A single statement is not enough of an example. In order to
compile it, it must be embedded in a complete file of compiler
input; and the bug might depend on the details of how this is done.
Without a real example one can compile, all anyone can do about
your bug report is wish you luck. It would be futile to try to
guess how to provoke the bug. For example, bugs in register
allocation and reloading frequently depend on every little detail
of the function they happen in.
Even if the input file that fails comes from a GNU program, you
should still send the complete test case. Don't ask the GNU CC
maintainers to do the extra work of obtaining the program in
question--they are all overworked as it is. Also, the problem may
depend on what is in the header files on your system; it is
unreliable for the GNU CC maintainers to try the problem with the
header files available to them. By sending CPP output, you can
eliminate this source of uncertainty and save us a certain
percentage of wild goose chases.
* The command arguments you gave GNU CC or GNU C++ to compile that
example and observe the bug. For example, did you use `-O'? To
guarantee you won't omit something important, list all the options.
If we were to try to guess the arguments, we would probably guess
wrong and then we would not encounter the bug.
* The type of machine you are using, and the operating system name
and version number.
* The operands you gave to the `configure' command when you installed
the compiler.
* A complete list of any modifications you have made to the compiler
source. (We don't promise to investigate the bug unless it
happens in an unmodified compiler. But if you've made
modifications and don't tell us, then you are sending us on a wild
goose chase.)
Be precise about these changes. A description in English is not
enough--send a context diff for them.
Adding files of your own (such as a machine description for a
machine we don't support) is a modification of the compiler source.
* Details of any other deviations from the standard procedure for
installing GNU CC.
* A description of what behavior you observe that you believe is
incorrect. For example, "The compiler gets a fatal signal," or,
"The assembler instruction at line 208 in the output is incorrect."
Of course, if the bug is that the compiler gets a fatal signal,
then one can't miss it. But if the bug is incorrect output, the
maintainer might not notice unless it is glaringly wrong. None of
us has time to study all the assembler code from a 50-line C
program just on the chance that one instruction might be wrong.
We need *you* to do this part!
Even if the problem you experience is a fatal signal, you should
still say so explicitly. Suppose something strange is going on,
such as, your copy of the compiler is out of synch, or you have
encountered a bug in the C library on your system. (This has
happened!) Your copy might crash and the copy here would not. If
you said to expect a crash, then when the compiler here fails to
crash, we would know that the bug was not happening. If you don't
say to expect a crash, then we would not know whether the bug was
happening. We would not be able to draw any conclusion from our
observations.
If the problem is a diagnostic when compiling GNU CC with some
other compiler, say whether it is a warning or an error.
Often the observed symptom is incorrect output when your program
is run. Sad to say, this is not enough information unless the
program is short and simple. None of us has time to study a large
program to figure out how it would work if compiled correctly,
much less which line of it was compiled wrong. So you will have
to do that. Tell us which source line it is, and what incorrect
result happens when that line is executed. A person who
understands the program can find this as easily as finding a bug
in the program itself.
* If you send examples of assembler code output from GNU CC or GNU
C++, please use `-g' when you make them. The debugging information
includes source line numbers which are essential for correlating
the output with the input.
* If you wish to mention something in the GNU CC source, refer to it
by context, not by line number.
The line numbers in the development sources don't match those in
your sources. Your line numbers would convey no useful
information to the maintainers.
* Additional information from a debugger might enable someone to
find a problem on a machine which he does not have available.
However, you need to think when you collect this information if
you want it to have any chance of being useful.
For example, many people send just a backtrace, but that is never
useful by itself. A simple backtrace with arguments conveys little
about GNU CC because the compiler is largely data-driven; the same
functions are called over and over for different RTL insns, doing
different things depending on the details of the insn.
Most of the arguments listed in the backtrace are useless because
they are pointers to RTL list structure. The numeric values of the
pointers, which the debugger prints in the backtrace, have no
significance whatever; all that matters is the contents of the
objects they point to (and most of the contents are other such
pointers).
In addition, most compiler passes consist of one or more loops that
scan the RTL insn sequence. The most vital piece of information
about such a loop--which insn it has reached--is usually in a
local variable, not in an argument.
What you need to provide in addition to a backtrace are the values
of the local variables for several stack frames up. When a local
variable or an argument is an RTX, first print its value and then
use the GDB command `pr' to print the RTL expression that it points
to. (If GDB doesn't run on your machine, use your debugger to call
the function `debug_rtx' with the RTX as an argument.) In
general, whenever a variable is a pointer, its value is no use
without the data it points to.
Here are some things that are not necessary:
* A description of the envelope of the bug.
Often people who encounter a bug spend a lot of time investigating
which changes to the input file will make the bug go away and which
changes will not affect it.
This is often time consuming and not very useful, because the way
we will find the bug is by running a single example under the
debugger with breakpoints, not by pure deduction from a series of
examples. You might as well save your time for something else.
Of course, if you can find a simpler example to report *instead* of
the original one, that is a convenience. Errors in the output
will be easier to spot, running under the debugger will take less
time, etc. Most GNU CC bugs involve just one function, so the
most straightforward way to simplify an example is to delete all
the function definitions except the one where the bug occurs.
Those earlier in the file may be replaced by external declarations
if the crucial function depends on them. (Exception: inline
functions may affect compilation of functions defined later in the
file.)
However, simplification is not vital; if you don't want to do this,
report the bug anyway and send the entire test case you used.
* In particular, some people insert conditionals `#ifdef BUG' around
a statement which, if removed, makes the bug not happen. These
are just clutter; we won't pay any attention to them anyway.
Besides, you should send us cpp output, and that can't have
conditionals.
* A patch for the bug.
A patch for the bug is useful if it is a good one. But don't omit
the necessary information, such as the test case, on the
assumption that a patch is all we need. We might see problems
with your patch and decide to fix the problem another way, or we
might not understand it at all.
Sometimes with a program as complicated as GNU CC it is very hard
to construct an example that will make the program follow a
certain path through the code. If you don't send the example, we
won't be able to construct one, so we won't be able to verify that
the bug is fixed.
And if we can't understand what bug you are trying to fix, or why
your patch should be an improvement, we won't install it. A test
case will help us to understand.
*Note Sending Patches::, for guidelines on how to make it easy for
us to understand and install your patches.
* A guess about what the bug is or what it depends on.
Such guesses are usually wrong. Even I can't guess right about
such things without first using the debugger to find the facts.
* A core dump file.
We have no way of examining a core dump for your type of machine
unless we have an identical system--and if we do have one, we
should be able to reproduce the crash ourselves.

File: gcc.info, Node: Sending Patches, Prev: Bug Reporting, Up: Bugs
Sending Patches for GNU CC
==========================
If you would like to write bug fixes or improvements for the GNU C
compiler, that is very helpful. Send suggested fixes to the bug report
mailing list, `bug-gcc@prep.ai.mit.edu'.
Please follow these guidelines so we can study your patches
efficiently. If you don't follow these guidelines, your information
might still be useful, but using it will take extra work. Maintaining
GNU C is a lot of work in the best of circumstances, and we can't keep
up unless you do your best to help.
* Send an explanation with your changes of what problem they fix or
what improvement they bring about. For a bug fix, just include a
copy of the bug report, and explain why the change fixes the bug.
(Referring to a bug report is not as good as including it, because
then we will have to look it up, and we have probably already
deleted it if we've already fixed the bug.)
* Always include a proper bug report for the problem you think you
have fixed. We need to convince ourselves that the change is
right before installing it. Even if it is right, we might have
trouble judging it if we don't have a way to reproduce the problem.
* Include all the comments that are appropriate to help people
reading the source in the future understand why this change was
needed.
* Don't mix together changes made for different reasons. Send them
*individually*.
If you make two changes for separate reasons, then we might not
want to install them both. We might want to install just one. If
you send them all jumbled together in a single set of diffs, we
have to do extra work to disentangle them--to figure out which
parts of the change serve which purpose. If we don't have time
for this, we might have to ignore your changes entirely.
If you send each change as soon as you have written it, with its
own explanation, then the two changes never get tangled up, and we
can consider each one properly without any extra work to
disentangle them.
Ideally, each change you send should be impossible to subdivide
into parts that we might want to consider separately, because each
of its parts gets its motivation from the other parts.
* Send each change as soon as that change is finished. Sometimes
people think they are helping us by accumulating many changes to
send them all together. As explained above, this is absolutely
the worst thing you could do.
Since you should send each change separately, you might as well
send it right away. That gives us the option of installing it
immediately if it is important.
* Use `diff -c' to make your diffs. Diffs without context are hard
for us to install reliably. More than that, they make it hard for
us to study the diffs to decide whether we want to install them.
Unidiff format is better than contextless diffs, but not as easy
to read as `-c' format.
If you have GNU diff, use `diff -cp', which shows the name of the
function that each change occurs in.
* Write the change log entries for your changes. We get lots of
changes, and we don't have time to do all the change log writing
ourselves.
Read the `ChangeLog' file to see what sorts of information to put
in, and to learn the style that we use. The purpose of the change
log is to show people where to find what was changed. So you need
to be specific about what functions you changed; in large
functions, it's often helpful to indicate where within the
function the change was.
On the other hand, once you have shown people where to find the
change, you need not explain its purpose. Thus, if you add a new
function, all you need to say about it is that it is new. If you
feel that the purpose needs explaining, it probably does--but the
explanation will be much more useful if you put it in comments in
the code.
If you would like your name to appear in the header line for who
made the change, send us the header line.
* When you write the fix, keep in mind that we can't install a
change that would break other systems.
People often suggest fixing a problem by changing
machine-independent files such as `toplev.c' to do something
special that a particular system needs. Sometimes it is totally
obvious that such changes would break GNU CC for almost all users.
We can't possibly make a change like that. At best it might tell
us how to write another patch that would solve the problem
acceptably.
Sometimes people send fixes that *might* be an improvement in
general--but it is hard to be sure of this. It's hard to install
such changes because we have to study them very carefully. Of
course, a good explanation of the reasoning by which you concluded
the change was correct can help convince us.
The safest changes are changes to the configuration files for a
particular machine. These are safe because they can't create new
bugs on other machines.
Please help us keep up with the workload by designing the patch in
a form that is good to install.

File: gcc.info, Node: Service, Next: Contributing, Prev: Bugs, Up: Top
How To Get Help with GNU CC
***************************
If you need help installing, using or changing GNU CC, there are two
ways to find it:
* Send a message to a suitable network mailing list. First try
`bug-gcc@prep.ai.mit.edu', and if that brings no response, try
`help-gcc@prep.ai.mit.edu'.
* Look in the service directory for someone who might help you for a
fee. The service directory is found in the file named `SERVICE'
in the GNU CC distribution.

File: gcc.info, Node: Contributing, Next: VMS, Prev: Service, Up: Top
Contributing to GNU CC Development
**********************************
If you would like to help pretest GNU CC releases to assure they work
well, or if you would like to work on improving GNU CC, please contact
the maintainers at `bug-gcc@gnu.ai.mit.edu'. A pretester should be
willing to try to investigate bugs as well as report them.
If you'd like to work on improvements, please ask for suggested
projects or suggest your own ideas. If you have already written an
improvement, please tell us about it. If you have not yet started
work, it is useful to contact `bug-gcc@prep.ai.mit.edu' before you
start; the maintainers may be able to suggest ways to make your
extension fit in better with the rest of GNU CC and with other
development plans.

File: gcc.info, Node: VMS, Next: Portability, Prev: Contributing, Up: Top
Using GNU CC on VMS
*******************
Here is how to use GNU CC on VMS.
* Menu:
* Include Files and VMS:: Where the preprocessor looks for the include files.
* Global Declarations:: How to do globaldef, globalref and globalvalue with
GNU CC.
* VMS Misc:: Misc information.

File: gcc.info, Node: Include Files and VMS, Next: Global Declarations, Up: VMS
Include Files and VMS
=====================
Due to the differences between the filesystems of Unix and VMS, GNU
CC attempts to translate file names in `#include' into names that VMS
will understand. The basic strategy is to prepend a prefix to the
specification of the include file, convert the whole filename to a VMS
filename, and then try to open the file. GNU CC tries various prefixes
one by one until one of them succeeds:
1. The first prefix is the `GNU_CC_INCLUDE:' logical name: this is
where GNU C header files are traditionally stored. If you wish to
store header files in non-standard locations, then you can assign
the logical `GNU_CC_INCLUDE' to be a search list, where each
element of the list is suitable for use with a rooted logical.
2. The next prefix tried is `SYS$SYSROOT:[SYSLIB.]'. This is where
VAX-C header files are traditionally stored.
3. If the include file specification by itself is a valid VMS
filename, the preprocessor then uses this name with no prefix in
an attempt to open the include file.
4. If the file specification is not a valid VMS filename (i.e. does
not contain a device or a directory specifier, and contains a `/'
character), the preprocessor tries to convert it from Unix syntax
to VMS syntax.
Conversion works like this: the first directory name becomes a
device, and the rest of the directories are converted into
VMS-format directory names. For example, the name `X11/foobar.h'
is translated to `X11:[000000]foobar.h' or `X11:foobar.h',
whichever one can be opened. This strategy allows you to assign a
logical name to point to the actual location of the header files.
5. If none of these strategies succeeds, the `#include' fails.
Include directives of the form:
#include foobar
are a common source of incompatibility between VAX-C and GNU CC. VAX-C
treats this much like a standard `#include <foobar.h>' directive. That
is incompatible with the ANSI C behavior implemented by GNU CC: to
expand the name `foobar' as a macro. Macro expansion should eventually
yield one of the two standard formats for `#include':
#include "FILE"
#include <FILE>
If you have this problem, the best solution is to modify the source
to convert the `#include' directives to one of the two standard forms.
That will work with either compiler. If you want a quick and dirty fix,
define the file names as macros with the proper expansion, like this:
#define stdio <stdio.h>
This will work, as long as the name doesn't conflict with anything else
in the program.
Another source of incompatibility is that VAX-C assumes that:
#include "foobar"
is actually asking for the file `foobar.h'. GNU CC does not make this
assumption, and instead takes what you ask for literally; it tries to
read the file `foobar'. The best way to avoid this problem is to
always specify the desired file extension in your include directives.
GNU CC for VMS is distributed with a set of include files that is
sufficient to compile most general purpose programs. Even though the
GNU CC distribution does not contain header files to define constants
and structures for some VMS system-specific functions, there is no
reason why you cannot use GNU CC with any of these functions. You first
may have to generate or create header files, either by using the public
domain utility `UNSDL' (which can be found on a DECUS tape), or by
extracting the relevant modules from one of the system macro libraries,
and using an editor to construct a C header file.
A `#include' file name cannot contain a DECNET node name. The
preprocessor reports an I/O error if you attempt to use a node name,
whether explicitly, or implicitly via a logical name.

File: gcc.info, Node: Global Declarations, Next: VMS Misc, Prev: Include Files and VMS, Up: VMS
Global Declarations and VMS
===========================
GNU CC does not provide the `globalref', `globaldef' and
`globalvalue' keywords of VAX-C. You can get the same effect with an
obscure feature of GAS, the GNU assembler. (This requires GAS version
1.39 or later.) The following macros allow you to use this feature in
a fairly natural way:
#ifdef __GNUC__
#define GLOBALREF(TYPE,NAME) \
TYPE NAME \
asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME)
#define GLOBALDEF(TYPE,NAME,VALUE) \
TYPE NAME \
asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME) \
= VALUE
#define GLOBALVALUEREF(TYPE,NAME) \
const TYPE NAME[1] \
asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME)
#define GLOBALVALUEDEF(TYPE,NAME,VALUE) \
const TYPE NAME[1] \
asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME) \
= {VALUE}
#else
#define GLOBALREF(TYPE,NAME) \
globalref TYPE NAME
#define GLOBALDEF(TYPE,NAME,VALUE) \
globaldef TYPE NAME = VALUE
#define GLOBALVALUEDEF(TYPE,NAME,VALUE) \
globalvalue TYPE NAME = VALUE
#define GLOBALVALUEREF(TYPE,NAME) \
globalvalue TYPE NAME
#endif
(The `_$$PsectAttributes_GLOBALSYMBOL' prefix at the start of the name
is removed by the assembler, after it has modified the attributes of
the symbol). These macros are provided in the VMS binaries
distribution in a header file `GNU_HACKS.H'. An example of the usage
is:
GLOBALREF (int, ijk);
GLOBALDEF (int, jkl, 0);
The macros `GLOBALREF' and `GLOBALDEF' cannot be used
straightforwardly for arrays, since there is no way to insert the array
dimension into the declaration at the right place. However, you can
declare an array with these macros if you first define a typedef for the
array type, like this:
typedef int intvector[10];
GLOBALREF (intvector, foo);
Array and structure initializers will also break the macros; you can
define the initializer to be a macro of its own, or you can expand the
`GLOBALDEF' macro by hand. You may find a case where you wish to use
the `GLOBALDEF' macro with a large array, but you are not interested in
explicitly initializing each element of the array. In such cases you
can use an initializer like: `{0,}', which will initialize the entire
array to `0'.
A shortcoming of this implementation is that a variable declared with
`GLOBALVALUEREF' or `GLOBALVALUEDEF' is always an array. For example,
the declaration:
GLOBALVALUEREF(int, ijk);
declares the variable `ijk' as an array of type `int [1]'. This is
done because a globalvalue is actually a constant; its "value" is what
the linker would normally consider an address. That is not how an
integer value works in C, but it is how an array works. So treating
the symbol as an array name gives consistent results--with the
exception that the value seems to have the wrong type. *Don't try to
access an element of the array.* It doesn't have any elements. The
array "address" may not be the address of actual storage.
The fact that the symbol is an array may lead to warnings where the
variable is used. Insert type casts to avoid the warnings. Here is an
example; it takes advantage of the ANSI C feature allowing macros that
expand to use the same name as the macro itself.
GLOBALVALUEREF (int, ss$_normal);
GLOBALVALUEDEF (int, xyzzy,123);
#ifdef __GNUC__
#define ss$_normal ((int) ss$_normal)
#define xyzzy ((int) xyzzy)
#endif
Don't use `globaldef' or `globalref' with a variable whose type is
an enumeration type; this is not implemented. Instead, make the
variable an integer, and use a `globalvaluedef' for each of the
enumeration values. An example of this would be:
#ifdef __GNUC__
GLOBALDEF (int, color, 0);
GLOBALVALUEDEF (int, RED, 0);
GLOBALVALUEDEF (int, BLUE, 1);
GLOBALVALUEDEF (int, GREEN, 3);
#else
enum globaldef color {RED, BLUE, GREEN = 3};
#endif

File: gcc.info, Node: VMS Misc, Prev: Global Declarations, Up: VMS
Other VMS Issues
================
GNU CC automatically arranges for `main' to return 1 by default if
you fail to specify an explicit return value. This will be interpreted
by VMS as a status code indicating a normal successful completion.
Version 1 of GNU CC did not provide this default.
GNU CC on VMS works only with the GNU assembler, GAS. You need
version 1.37 or later of GAS in order to produce value debugging
information for the VMS debugger. Use the ordinary VMS linker with the
object files produced by GAS.
Under previous versions of GNU CC, the generated code would
occasionally give strange results when linked to the sharable `VAXCRTL'
library. Now this should work.
A caveat for use of `const' global variables: the `const' modifier
must be specified in every external declaration of the variable in all
of the source files that use that variable. Otherwise the linker will
issue warnings about conflicting attributes for the variable. Your
program will still work despite the warnings, but the variable will be
placed in writable storage.
Although the VMS linker does distinguish between upper and lower case
letters in global symbols, most VMS compilers convert all such symbols
into upper case and most run-time library routines also have upper case
names. To be able to reliably call such routines, GNU CC (by means of
the assembler GAS) converts global symbols into upper case like other
VMS compilers. However, since the usual practice in C is to distinguish
case, GNU CC (via GAS) tries to preserve usual C behavior by augmenting
each name that is not all lower case. This means truncating the name
to at most 23 characters and then adding more characters at the end
which encode the case pattern of those 23. Names which contain at
least one dollar sign are an exception; they are converted directly into
upper case without augmentation.
Name augmentation yields bad results for programs that use
precompiled libraries (such as Xlib) which were generated by another
compiler. You can use the compiler option `/NOCASE_HACK' to inhibit
augmentation; it makes external C functions and variables
case-independent as is usual on VMS. Alternatively, you could write
all references to the functions and variables in such libraries using
lower case; this will work on VMS, but is not portable to other
systems. The compiler option `/NAMES' also provides control over
global name handling.
Function and variable names are handled somewhat differently with GNU
C++. The GNU C++ compiler performs "name mangling" on function names,
which means that it adds information to the function name to describe
the data types of the arguments that the function takes. One result of
this is that the name of a function can become very long. Since the
VMS linker only recognizes the first 31 characters in a name, special
action is taken to ensure that each function and variable has a unique
name that can be represented in 31 characters.
If the name (plus a name augmentation, if required) is less than 32
characters in length, then no special action is performed. If the name
is longer than 31 characters, the assembler (GAS) will generate a hash
string based upon the function name, truncate the function name to 23
characters, and append the hash string to the truncated name. If the
`/VERBOSE' compiler option is used, the assembler will print both the
full and truncated names of each symbol that is truncated.
The `/NOCASE_HACK' compiler option should not be used when you are
compiling programs that use libg++. libg++ has several instances of
objects (i.e. `Filebuf' and `filebuf') which become indistinguishable
in a case-insensitive environment. This leads to cases where you need
to inhibit augmentation selectively (if you were using libg++ and Xlib
in the same program, for example). There is no special feature for
doing this, but you can get the result by defining a macro for each
mixed case symbol for which you wish to inhibit augmentation. The
macro should expand into the lower case equivalent of itself. For
example:
#define StuDlyCapS studlycaps
These macro definitions can be placed in a header file to minimize
the number of changes to your source code.

File: gcc.info, Node: Portability, Next: Interface, Prev: VMS, Up: Top
GNU CC and Portability
**********************
The main goal of GNU CC was to make a good, fast compiler for
machines in the class that the GNU system aims to run on: 32-bit
machines that address 8-bit bytes and have several general registers.
Elegance, theoretical power and simplicity are only secondary.
GNU CC gets most of the information about the target machine from a
machine description which gives an algebraic formula for each of the
machine's instructions. This is a very clean way to describe the
target. But when the compiler needs information that is difficult to
express in this fashion, I have not hesitated to define an ad-hoc
parameter to the machine description. The purpose of portability is to
reduce the total work needed on the compiler; it was not of interest
for its own sake.
GNU CC does not contain machine dependent code, but it does contain
code that depends on machine parameters such as endianness (whether the
most significant byte has the highest or lowest address of the bytes in
a word) and the availability of autoincrement addressing. In the
RTL-generation pass, it is often necessary to have multiple strategies
for generating code for a particular kind of syntax tree, strategies
that are usable for different combinations of parameters. Often I have
not tried to address all possible cases, but only the common ones or
only the ones that I have encountered. As a result, a new target may
require additional strategies. You will know if this happens because
the compiler will call `abort'. Fortunately, the new strategies can be
added in a machine-independent fashion, and will affect only the target
machines that need them.

File: gcc.info, Node: Interface, Next: Passes, Prev: Portability, Up: Top
Interfacing to GNU CC Output
****************************
GNU CC is normally configured to use the same function calling
convention normally in use on the target system. This is done with the
machine-description macros described (*note Target Macros::.).
However, returning of structure and union values is done differently
on some target machines. As a result, functions compiled with PCC
returning such types cannot be called from code compiled with GNU CC,
and vice versa. This does not cause trouble often because few Unix
library routines return structures or unions.
GNU CC code returns structures and unions that are 1, 2, 4 or 8 bytes
long in the same registers used for `int' or `double' return values.
(GNU CC typically allocates variables of such types in registers also.)
Structures and unions of other sizes are returned by storing them into
an address passed by the caller (usually in a register). The
machine-description macros `STRUCT_VALUE' and `STRUCT_INCOMING_VALUE'
tell GNU CC where to pass this address.
By contrast, PCC on most target machines returns structures and
unions of any size by copying the data into an area of static storage,
and then returning the address of that storage as if it were a pointer
value. The caller must copy the data from that memory area to the
place where the value is wanted. This is slower than the method used
by GNU CC, and fails to be reentrant.
On some target machines, such as RISC machines and the 80386, the
standard system convention is to pass to the subroutine the address of
where to return the value. On these machines, GNU CC has been
configured to be compatible with the standard compiler, when this method
is used. It may not be compatible for structures of 1, 2, 4 or 8 bytes.
GNU CC uses the system's standard convention for passing arguments.
On some machines, the first few arguments are passed in registers; in
others, all are passed on the stack. It would be possible to use
registers for argument passing on any machine, and this would probably
result in a significant speedup. But the result would be complete
incompatibility with code that follows the standard convention. So this
change is practical only if you are switching to GNU CC as the sole C
compiler for the system. We may implement register argument passing on
certain machines once we have a complete GNU system so that we can
compile the libraries with GNU CC.
On some machines (particularly the Sparc), certain types of arguments
are passed "by invisible reference". This means that the value is
stored in memory, and the address of the memory location is passed to
the subroutine.
If you use `longjmp', beware of automatic variables. ANSI C says
that automatic variables that are not declared `volatile' have undefined
values after a `longjmp'. And this is all GNU CC promises to do,
because it is very difficult to restore register variables correctly,
and one of GNU CC's features is that it can put variables in registers
without your asking it to.
If you want a variable to be unaltered by `longjmp', and you don't
want to write `volatile' because old C compilers don't accept it, just
take the address of the variable. If a variable's address is ever
taken, even if just to compute it and ignore it, then the variable
cannot go in a register:
{
int careful;
&careful;
...
}
Code compiled with GNU CC may call certain library routines. Most of
them handle arithmetic for which there are no instructions. This
includes multiply and divide on some machines, and floating point
operations on any machine for which floating point support is disabled
with `-msoft-float'. Some standard parts of the C library, such as
`bcopy' or `memcpy', are also called automatically. The usual function
call interface is used for calling the library routines.
These library routines should be defined in the library `libgcc.a',
which GNU CC automatically searches whenever it links a program. On
machines that have multiply and divide instructions, if hardware
floating point is in use, normally `libgcc.a' is not needed, but it is
searched just in case.
Each arithmetic function is defined in `libgcc1.c' to use the
corresponding C arithmetic operator. As long as the file is compiled
with another C compiler, which supports all the C arithmetic operators,
this file will work portably. However, `libgcc1.c' does not work if
compiled with GNU CC, because each arithmetic function would compile
into a call to itself!

1161
gcc/gcc.info-14 Normal file
View File

File diff suppressed because it is too large Load Diff

1010
gcc/gcc.info-15 Normal file
View File

File diff suppressed because it is too large Load Diff

1053
gcc/gcc.info-16 Normal file
View File

File diff suppressed because it is too large Load Diff

1112
gcc/gcc.info-17 Normal file
View File

File diff suppressed because it is too large Load Diff

1031
gcc/gcc.info-18 Normal file
View File

File diff suppressed because it is too large Load Diff

1072
gcc/gcc.info-19 Normal file
View File

File diff suppressed because it is too large Load Diff

1142
gcc/gcc.info-2 Normal file
View File

File diff suppressed because it is too large Load Diff

1207
gcc/gcc.info-20 Normal file
View File

File diff suppressed because it is too large Load Diff

1028
gcc/gcc.info-21 Normal file
View File

File diff suppressed because it is too large Load Diff

961
gcc/gcc.info-22 Normal file
View File

@ -0,0 +1,961 @@
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
input file gcc.texi.
This file documents the use and the internals of the GNU compiler.
Published by the Free Software Foundation 59 Temple Place - Suite 330
Boston, MA 02111-1307 USA
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997 Free
Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License," "Funding for
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License," "Funding for Free Software," and "Protect Your Freedom--Fight
`Look And Feel'", and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.

File: gcc.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling
Registers That Address the Stack Frame
--------------------------------------
This discusses registers that address the stack frame.
`STACK_POINTER_REGNUM'
The register number of the stack pointer register, which must also
be a fixed register according to `FIXED_REGISTERS'. On most
machines, the hardware determines which register this is.
`FRAME_POINTER_REGNUM'
The register number of the frame pointer register, which is used to
access automatic variables in the stack frame. On some machines,
the hardware determines which register this is. On other
machines, you can choose any register you wish for this purpose.
`HARD_FRAME_POINTER_REGNUM'
On some machines the offset between the frame pointer and starting
offset of the automatic variables is not known until after register
allocation has been done (for example, because the saved registers
are between these two locations). On those machines, define
`FRAME_POINTER_REGNUM' the number of a special, fixed register to
be used internally until the offset is known, and define
`HARD_FRAME_POINTER_REGNUM' to be actual the hard register number
used for the frame pointer.
You should define this macro only in the very rare circumstances
when it is not possible to calculate the offset between the frame
pointer and the automatic variables until after register
allocation has been completed. When this macro is defined, you
must also indicate in your definition of `ELIMINABLE_REGS' how to
eliminate `FRAME_POINTER_REGNUM' into either
`HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'.
Do not define this macro if it would be the same as
`FRAME_POINTER_REGNUM'.
`ARG_POINTER_REGNUM'
The register number of the arg pointer register, which is used to
access the function's argument list. On some machines, this is
the same as the frame pointer register. On some machines, the
hardware determines which register this is. On other machines,
you can choose any register you wish for this purpose. If this is
not the same register as the frame pointer register, then you must
mark it as a fixed register according to `FIXED_REGISTERS', or
arrange to be able to eliminate it (*note Elimination::.).
`RETURN_ADDRESS_POINTER_REGNUM'
The register number of the return address pointer register, which
is used to access the current function's return address from the
stack. On some machines, the return address is not at a fixed
offset from the frame pointer or stack pointer or argument
pointer. This register can be defined to point to the return
address on the stack, and then be converted by `ELIMINABLE_REGS'
into either the frame pointer or stack pointer.
Do not define this macro unless there is no other way to get the
return address from the stack.
`STATIC_CHAIN_REGNUM'
`STATIC_CHAIN_INCOMING_REGNUM'
Register numbers used for passing a function's static chain
pointer. If register windows are used, the register number as
seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM',
while the register number as seen by the calling function is
`STATIC_CHAIN_REGNUM'. If these registers are the same,
`STATIC_CHAIN_INCOMING_REGNUM' need not be defined.
The static chain register need not be a fixed register.
If the static chain is passed in memory, these macros should not be
defined; instead, the next two macros should be defined.
`STATIC_CHAIN'
`STATIC_CHAIN_INCOMING'
If the static chain is passed in memory, these macros provide rtx
giving `mem' expressions that denote where they are stored.
`STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as
seen by the calling and called functions, respectively. Often the
former will be at an offset from the stack pointer and the latter
at an offset from the frame pointer.
The variables `stack_pointer_rtx', `frame_pointer_rtx', and
`arg_pointer_rtx' will have been initialized prior to the use of
these macros and should be used to refer to those items.
If the static chain is passed in a register, the two previous
macros should be defined instead.

File: gcc.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling
Eliminating Frame Pointer and Arg Pointer
-----------------------------------------
This is about eliminating the frame pointer and arg pointer.
`FRAME_POINTER_REQUIRED'
A C expression which is nonzero if a function must have and use a
frame pointer. This expression is evaluated in the reload pass.
If its value is nonzero the function will have a frame pointer.
The expression can in principle examine the current function and
decide according to the facts, but on most machines the constant 0
or the constant 1 suffices. Use 0 when the machine allows code to
be generated with no frame pointer, and doing so saves some time
or space. Use 1 when there is no possible advantage to avoiding a
frame pointer.
In certain cases, the compiler does not know how to produce valid
code without a frame pointer. The compiler recognizes those cases
and automatically gives the function a frame pointer regardless of
what `FRAME_POINTER_REQUIRED' says. You don't need to worry about
them.
In a function that does not require a frame pointer, the frame
pointer register can be allocated for ordinary usage, unless you
mark it as a fixed register. See `FIXED_REGISTERS' for more
information.
`INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)'
A C statement to store in the variable DEPTH-VAR the difference
between the frame pointer and the stack pointer values immediately
after the function prologue. The value would be computed from
information such as the result of `get_frame_size ()' and the
tables of registers `regs_ever_live' and `call_used_regs'.
If `ELIMINABLE_REGS' is defined, this macro will be not be used and
need not be defined. Otherwise, it must be defined even if
`FRAME_POINTER_REQUIRED' is defined to always be true; in that
case, you may set DEPTH-VAR to anything.
`ELIMINABLE_REGS'
If defined, this macro specifies a table of register pairs used to
eliminate unneeded registers that point into the stack frame. If
it is not defined, the only elimination attempted by the compiler
is to replace references to the frame pointer with references to
the stack pointer.
The definition of this macro is a list of structure
initializations, each of which specifies an original and
replacement register.
On some machines, the position of the argument pointer is not
known until the compilation is completed. In such a case, a
separate hard register must be used for the argument pointer.
This register can be eliminated by replacing it with either the
frame pointer or the argument pointer, depending on whether or not
the frame pointer has been eliminated.
In this case, you might specify:
#define ELIMINABLE_REGS \
{{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
{ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \
{FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}
Note that the elimination of the argument pointer with the stack
pointer is specified first since that is the preferred elimination.
`CAN_ELIMINATE (FROM-REG, TO-REG)'
A C expression that returns non-zero if the compiler is allowed to
try to replace register number FROM-REG with register number
TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is
defined, and will usually be the constant 1, since most of the
cases preventing register elimination are things that the compiler
already knows about.
`INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)'
This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It
specifies the initial difference between the specified pair of
registers. This macro must be defined if `ELIMINABLE_REGS' is
defined.
`LONGJMP_RESTORE_FROM_STACK'
Define this macro if the `longjmp' function restores registers from
the stack frames, rather than from those saved specifically by
`setjmp'. Certain quantities must not be kept in registers across
a call to `setjmp' on such machines.

File: gcc.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling
Passing Function Arguments on the Stack
---------------------------------------
The macros in this section control how arguments are passed on the
stack. See the following section for other macros that control passing
certain arguments in registers.
`PROMOTE_PROTOTYPES'
Define this macro if an argument declared in a prototype as an
integral type smaller than `int' should actually be passed as an
`int'. In addition to avoiding errors in certain cases of
mismatch, it also makes for better code on certain machines.
`PUSH_ROUNDING (NPUSHED)'
A C expression that is the number of bytes actually pushed onto the
stack when an instruction attempts to push NPUSHED bytes.
If the target machine does not have a push instruction, do not
define this macro. That directs GNU CC to use an alternate
strategy: to allocate the entire argument block and then store the
arguments into it.
On some machines, the definition
#define PUSH_ROUNDING(BYTES) (BYTES)
will suffice. But on other machines, instructions that appear to
push one byte actually push two bytes in an attempt to maintain
alignment. Then the definition should be
#define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
`ACCUMULATE_OUTGOING_ARGS'
If defined, the maximum amount of space required for outgoing
arguments will be computed and placed into the variable
`current_function_outgoing_args_size'. No space will be pushed
onto the stack for each call; instead, the function prologue should
increase the stack frame size by this amount.
Defining both `PUSH_ROUNDING' and `ACCUMULATE_OUTGOING_ARGS' is
not proper.
`REG_PARM_STACK_SPACE (FNDECL)'
Define this macro if functions should assume that stack space has
been allocated for arguments even when their values are passed in
registers.
The value of this macro is the size, in bytes, of the area
reserved for arguments passed in registers for the function
represented by FNDECL.
This space can be allocated by the caller, or be a part of the
machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says
which.
`MAYBE_REG_PARM_STACK_SPACE'
`FINAL_REG_PARM_STACK_SPACE (CONST_SIZE, VAR_SIZE)'
Define these macros in addition to the one above if functions might
allocate stack space for arguments even when their values are
passed in registers. These should be used when the stack space
allocated for arguments in registers is not a simple constant
independent of the function declaration.
The value of the first macro is the size, in bytes, of the area
that we should initially assume would be reserved for arguments
passed in registers.
The value of the second macro is the actual size, in bytes, of the
area that will be reserved for arguments passed in registers.
This takes two arguments: an integer representing the number of
bytes of fixed sized arguments on the stack, and a tree
representing the number of bytes of variable sized arguments on
the stack.
When these macros are defined, `REG_PARM_STACK_SPACE' will only be
called for libcall functions, the current function, or for a
function being called when it is known that such stack space must
be allocated. In each case this value can be easily computed.
When deciding whether a called function needs such stack space,
and how much space to reserve, GNU CC uses these two macros
instead of `REG_PARM_STACK_SPACE'.
`OUTGOING_REG_PARM_STACK_SPACE'
Define this if it is the responsibility of the caller to allocate
the area reserved for arguments passed in registers.
If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls
whether the space for these arguments counts in the value of
`current_function_outgoing_args_size'.
`STACK_PARMS_IN_REG_PARM_AREA'
Define this macro if `REG_PARM_STACK_SPACE' is defined, but the
stack parameters don't skip the area specified by it.
Normally, when a parameter is not passed in registers, it is
placed on the stack beyond the `REG_PARM_STACK_SPACE' area.
Defining this macro suppresses this behavior and causes the
parameter to be passed on the stack in its natural location.
`RETURN_POPS_ARGS (FUNDECL, FUNTYPE, STACK-SIZE)'
A C expression that should indicate the number of bytes of its own
arguments that a function pops on returning, or 0 if the function
pops no arguments and the caller must therefore pop them all after
the function returns.
FUNDECL is a C variable whose value is a tree node that describes
the function in question. Normally it is a node of type
`FUNCTION_DECL' that describes the declaration of the function.
From this you can obtain the DECL_MACHINE_ATTRIBUTES of the
function.
FUNTYPE is a C variable whose value is a tree node that describes
the function in question. Normally it is a node of type
`FUNCTION_TYPE' that describes the data type of the function.
From this it is possible to obtain the data types of the value and
arguments (if known).
When a call to a library function is being considered, FUNDECL
will contain an identifier node for the library function. Thus, if
you need to distinguish among various library functions, you can
do so by their names. Note that "library function" in this
context means a function used to perform arithmetic, whose name is
known specially in the compiler and was not mentioned in the C
code being compiled.
STACK-SIZE is the number of bytes of arguments passed on the
stack. If a variable number of bytes is passed, it is zero, and
argument popping will always be the responsibility of the calling
function.
On the Vax, all functions always pop their arguments, so the
definition of this macro is STACK-SIZE. On the 68000, using the
standard calling convention, no functions pop their arguments, so
the value of the macro is always 0 in this case. But an
alternative calling convention is available in which functions
that take a fixed number of arguments pop them but other functions
(such as `printf') pop nothing (the caller pops all). When this
convention is in use, FUNTYPE is examined to determine whether a
function takes a fixed number of arguments.

File: gcc.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling
Passing Arguments in Registers
------------------------------
This section describes the macros which let you control how various
types of arguments are passed in registers or how they are arranged in
the stack.
`FUNCTION_ARG (CUM, MODE, TYPE, NAMED)'
A C expression that controls whether a function argument is passed
in a register, and which register.
The arguments are CUM, which summarizes all the previous
arguments; MODE, the machine mode of the argument; TYPE, the data
type of the argument as a tree node or 0 if that is not known
(which happens for C support library functions); and NAMED, which
is 1 for an ordinary argument and 0 for nameless arguments that
correspond to `...' in the called function's prototype.
The value of the expression is usually either a `reg' RTX for the
hard register in which to pass the argument, or zero to pass the
argument on the stack.
For machines like the Vax and 68000, where normally all arguments
are pushed, zero suffices as a definition.
The value of the expression can also be a `parallel' RTX. This is
used when an argument is passed in multiple locations. The mode
of the of the `parallel' should be the mode of the entire
argument. The `parallel' holds any number of `expr_list' pairs;
each one describes where part of the argument is passed. In each
`expr_list', the first operand can be either a `reg' RTX for the
hard register in which to pass this part of the argument, or zero
to pass the argument on the stack. If this operand is a `reg',
then the mode indicates how large this part of the argument is.
The second operand of the `expr_list' is a `const_int' which gives
the offset in bytes into the entire argument where this part
starts.
The usual way to make the ANSI library `stdarg.h' work on a machine
where some arguments are usually passed in registers, is to cause
nameless arguments to be passed on the stack instead. This is done
by making `FUNCTION_ARG' return 0 whenever NAMED is 0.
You may use the macro `MUST_PASS_IN_STACK (MODE, TYPE)' in the
definition of this macro to determine if this argument is of a
type that must be passed in the stack. If `REG_PARM_STACK_SPACE'
is not defined and `FUNCTION_ARG' returns non-zero for such an
argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is
defined, the argument will be computed in the stack and then
loaded into a register.
`FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)'
Define this macro if the target machine has "register windows", so
that the register in which a function sees an arguments is not
necessarily the same as the one in which the caller passed the
argument.
For such machines, `FUNCTION_ARG' computes the register in which
the caller passes the value, and `FUNCTION_INCOMING_ARG' should be
defined in a similar fashion to tell the function being called
where the arguments will arrive.
If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
both purposes.
`FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)'
A C expression for the number of words, at the beginning of an
argument, must be put in registers. The value must be zero for
arguments that are passed entirely in registers or that are
entirely pushed on the stack.
On some machines, certain arguments must be passed partially in
registers and partially in memory. On these machines, typically
the first N words of arguments are passed in registers, and the
rest on the stack. If a multi-word argument (a `double' or a
structure) crosses that boundary, its first few words must be
passed in registers and the rest must be pushed. This macro tells
the compiler when this occurs, and how many of the words should go
in registers.
`FUNCTION_ARG' for these arguments should return the first
register to be used by the caller for this argument; likewise
`FUNCTION_INCOMING_ARG', for the called function.
`FUNCTION_ARG_PASS_BY_REFERENCE (CUM, MODE, TYPE, NAMED)'
A C expression that indicates when an argument must be passed by
reference. If nonzero for an argument, a copy of that argument is
made in memory and a pointer to the argument is passed instead of
the argument itself. The pointer is passed in whatever way is
appropriate for passing a pointer to that type.
On machines where `REG_PARM_STACK_SPACE' is not defined, a suitable
definition of this macro might be
#define FUNCTION_ARG_PASS_BY_REFERENCE\
(CUM, MODE, TYPE, NAMED) \
MUST_PASS_IN_STACK (MODE, TYPE)
`FUNCTION_ARG_CALLEE_COPIES (CUM, MODE, TYPE, NAMED)'
If defined, a C expression that indicates when it is the called
function's responsibility to make a copy of arguments passed by
invisible reference. Normally, the caller makes a copy and passes
the address of the copy to the routine being called. When
FUNCTION_ARG_CALLEE_COPIES is defined and is nonzero, the caller
does not make a copy. Instead, it passes a pointer to the "live"
value. The called function must not modify this value. If it can
be determined that the value won't be modified, it need not make a
copy; otherwise a copy must be made.
`CUMULATIVE_ARGS'
A C type for declaring a variable that is used as the first
argument of `FUNCTION_ARG' and other related values. For some
target machines, the type `int' suffices and can hold the number
of bytes of argument so far.
There is no need to record in `CUMULATIVE_ARGS' anything about the
arguments that have been passed on the stack. The compiler has
other variables to keep track of that. For target machines on
which all arguments are passed on the stack, there is no need to
store anything in `CUMULATIVE_ARGS'; however, the data structure
must exist and should not be empty, so use `int'.
`INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, INDIRECT)'
A C statement (sans semicolon) for initializing the variable CUM
for the state at the beginning of the argument list. The variable
has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node
for the data type of the function which will receive the args, or 0
if the args are to a compiler support library function. The value
of INDIRECT is nonzero when processing an indirect call, for
example a call through a function pointer. The value of INDIRECT
is zero for a call to an explicitly named function, a library
function call, or when `INIT_CUMULATIVE_ARGS' is used to find
arguments for the function being compiled.
When processing a call to a compiler support library function,
LIBNAME identifies which one. It is a `symbol_ref' rtx which
contains the name of the function, as a string. LIBNAME is 0 when
an ordinary C function call is being processed. Thus, each time
this macro is called, either LIBNAME or FNTYPE is nonzero, but
never both of them at once.
`INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)'
Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of
finding the arguments for the function being compiled. If this
macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead.
The value passed for LIBNAME is always 0, since library routines
with special calling conventions are never compiled with GNU CC.
The argument LIBNAME exists for symmetry with
`INIT_CUMULATIVE_ARGS'.
`FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)'
A C statement (sans semicolon) to update the summarizer variable
CUM to advance past an argument in the argument list. The values
MODE, TYPE and NAMED describe that argument. Once this is done,
the variable CUM is suitable for analyzing the *following*
argument with `FUNCTION_ARG', etc.
This macro need not do anything if the argument in question was
passed on the stack. The compiler knows how to track the amount
of stack space used for arguments without any special help.
`FUNCTION_ARG_PADDING (MODE, TYPE)'
If defined, a C expression which determines whether, and in which
direction, to pad out an argument with extra space. The value
should be of type `enum direction': either `upward' to pad above
the argument, `downward' to pad below, or `none' to inhibit
padding.
The *amount* of padding is always just enough to reach the next
multiple of `FUNCTION_ARG_BOUNDARY'; this macro does not control
it.
This macro has a default definition which is right for most
systems. For little-endian machines, the default is to pad
upward. For big-endian machines, the default is to pad downward
for an argument of constant size shorter than an `int', and upward
otherwise.
`FUNCTION_ARG_BOUNDARY (MODE, TYPE)'
If defined, a C expression that gives the alignment boundary, in
bits, of an argument with the specified mode and type. If it is
not defined, `PARM_BOUNDARY' is used for all arguments.
`FUNCTION_ARG_REGNO_P (REGNO)'
A C expression that is nonzero if REGNO is the number of a hard
register in which function arguments are sometimes passed. This
does *not* include implicit arguments such as the static chain and
the structure-value address. On many machines, no registers can be
used for this purpose since all function arguments are pushed on
the stack.

File: gcc.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling
How Scalar Function Values Are Returned
---------------------------------------
This section discusses the macros that control returning scalars as
values--values that can fit in registers.
`TRADITIONAL_RETURN_FLOAT'
Define this macro if `-traditional' should not cause functions
declared to return `float' to convert the value to `double'.
`FUNCTION_VALUE (VALTYPE, FUNC)'
A C expression to create an RTX representing the place where a
function returns a value of data type VALTYPE. VALTYPE is a tree
node representing a data type. Write `TYPE_MODE (VALTYPE)' to get
the machine mode used to represent that type. On many machines,
only the mode is relevant. (Actually, on most machines, scalar
values are returned in the same place regardless of mode).
The value of the expression is usually a `reg' RTX for the hard
register where the return value is stored. The value can also be a
`parallel' RTX, if the return value is in multiple places. See
`FUNCTION_ARG' for an explanation of the `parallel' form.
If `PROMOTE_FUNCTION_RETURN' is defined, you must apply the same
promotion rules specified in `PROMOTE_MODE' if VALTYPE is a scalar
type.
If the precise function being called is known, FUNC is a tree node
(`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This
makes it possible to use a different value-returning convention
for specific functions when all their calls are known.
`FUNCTION_VALUE' is not used for return vales with aggregate data
types, because these are returned in another way. See
`STRUCT_VALUE_REGNUM' and related macros, below.
`FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)'
Define this macro if the target machine has "register windows" so
that the register in which a function returns its value is not the
same as the one in which the caller sees the value.
For such machines, `FUNCTION_VALUE' computes the register in which
the caller will see the value. `FUNCTION_OUTGOING_VALUE' should be
defined in a similar fashion to tell the function where to put the
value.
If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE'
serves both purposes.
`FUNCTION_OUTGOING_VALUE' is not used for return vales with
aggregate data types, because these are returned in another way.
See `STRUCT_VALUE_REGNUM' and related macros, below.
`LIBCALL_VALUE (MODE)'
A C expression to create an RTX representing the place where a
library function returns a value of mode MODE. If the precise
function being called is known, FUNC is a tree node
(`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This
makes it possible to use a different value-returning convention
for specific functions when all their calls are known.
Note that "library function" in this context means a compiler
support routine, used to perform arithmetic, whose name is known
specially by the compiler and was not mentioned in the C code being
compiled.
The definition of `LIBRARY_VALUE' need not be concerned aggregate
data types, because none of the library functions returns such
types.
`FUNCTION_VALUE_REGNO_P (REGNO)'
A C expression that is nonzero if REGNO is the number of a hard
register in which the values of called function may come back.
A register whose use for returning values is limited to serving as
the second of a pair (for a value of type `double', say) need not
be recognized by this macro. So for most machines, this definition
suffices:
#define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
If the machine has register windows, so that the caller and the
called function use different registers for the return value, this
macro should recognize only the caller's register numbers.
`APPLY_RESULT_SIZE'
Define this macro if `untyped_call' and `untyped_return' need more
space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and
restoring an arbitrary return value.

File: gcc.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling
How Large Values Are Returned
-----------------------------
When a function value's mode is `BLKmode' (and in some other cases),
the value is not returned according to `FUNCTION_VALUE' (*note Scalar
Return::.). Instead, the caller passes the address of a block of
memory in which the value should be stored. This address is called the
"structure value address".
This section describes how to control returning structure values in
memory.
`RETURN_IN_MEMORY (TYPE)'
A C expression which can inhibit the returning of certain function
values in registers, based on the type of value. A nonzero value
says to return the function value in memory, just as large
structures are always returned. Here TYPE will be a C expression
of type `tree', representing the data type of the value.
Note that values of mode `BLKmode' must be explicitly handled by
this macro. Also, the option `-fpcc-struct-return' takes effect
regardless of this macro. On most systems, it is possible to
leave the macro undefined; this causes a default definition to be
used, whose value is the constant 1 for `BLKmode' values, and 0
otherwise.
Do not use this macro to indicate that structures and unions
should always be returned in memory. You should instead use
`DEFAULT_PCC_STRUCT_RETURN' to indicate this.
`DEFAULT_PCC_STRUCT_RETURN'
Define this macro to be 1 if all structure and union return values
must be in memory. Since this results in slower code, this should
be defined only if needed for compatibility with other compilers
or with an ABI. If you define this macro to be 0, then the
conventions used for structure and union return values are decided
by the `RETURN_IN_MEMORY' macro.
If not defined, this defaults to the value 1.
`STRUCT_VALUE_REGNUM'
If the structure value address is passed in a register, then
`STRUCT_VALUE_REGNUM' should be the number of that register.
`STRUCT_VALUE'
If the structure value address is not passed in a register, define
`STRUCT_VALUE' as an expression returning an RTX for the place
where the address is passed. If it returns 0, the address is
passed as an "invisible" first argument.
`STRUCT_VALUE_INCOMING_REGNUM'
On some architectures the place where the structure value address
is found by the called function is not the same place that the
caller put it. This can be due to register windows, or it could
be because the function prologue moves it to a different place.
If the incoming location of the structure value address is in a
register, define this macro as the register number.
`STRUCT_VALUE_INCOMING'
If the incoming location is not a register, then you should define
`STRUCT_VALUE_INCOMING' as an expression for an RTX for where the
called function should find the value. If it should find the
value on the stack, define this to create a `mem' which refers to
the frame pointer. A definition of 0 means that the address is
passed as an "invisible" first argument.
`PCC_STATIC_STRUCT_RETURN'
Define this macro if the usual system convention on the target
machine for returning structures and unions is for the called
function to return the address of a static variable containing the
value.
Do not define this if the usual system convention is for the
caller to pass an address to the subroutine.
This macro has effect in `-fpcc-struct-return' mode, but it does
nothing when you use `-freg-struct-return' mode.

File: gcc.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling
Caller-Saves Register Allocation
--------------------------------
If you enable it, GNU CC can save registers around function calls.
This makes it possible to use call-clobbered registers to hold
variables that must live across calls.
`DEFAULT_CALLER_SAVES'
Define this macro if function calls on the target machine do not
preserve any registers; in other words, if `CALL_USED_REGISTERS'
has 1 for all registers. This macro enables `-fcaller-saves' by
default. Eventually that option will be enabled by default on all
machines and both the option and this macro will be eliminated.
`CALLER_SAVE_PROFITABLE (REFS, CALLS)'
A C expression to determine whether it is worthwhile to consider
placing a pseudo-register in a call-clobbered hard register and
saving and restoring it around each function call. The expression
should be 1 when this is worth doing, and 0 otherwise.
If you don't define this macro, a default is used which is good on
most machines: `4 * CALLS < REFS'.

File: gcc.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling
Function Entry and Exit
-----------------------
This section describes the macros that output function entry
("prologue") and exit ("epilogue") code.
`FUNCTION_PROLOGUE (FILE, SIZE)'
A C compound statement that outputs the assembler code for entry
to a function. The prologue is responsible for setting up the
stack frame, initializing the frame pointer register, saving
registers that must be saved, and allocating SIZE additional bytes
of storage for the local variables. SIZE is an integer. FILE is
a stdio stream to which the assembler code should be output.
The label for the beginning of the function need not be output by
this macro. That has already been done when the macro is run.
To determine which registers to save, the macro can refer to the
array `regs_ever_live': element R is nonzero if hard register R is
used anywhere within the function. This implies the function
prologue should save register R, provided it is not one of the
call-used registers. (`FUNCTION_EPILOGUE' must likewise use
`regs_ever_live'.)
On machines that have "register windows", the function entry code
does not save on the stack the registers that are in the windows,
even if they are supposed to be preserved by function calls;
instead it takes appropriate steps to "push" the register stack,
if any non-call-used registers are used in the function.
On machines where functions may or may not have frame-pointers, the
function entry code must vary accordingly; it must set up the frame
pointer if one is wanted, and not otherwise. To determine whether
a frame pointer is in wanted, the macro can refer to the variable
`frame_pointer_needed'. The variable's value will be 1 at run
time in a function that needs a frame pointer. *Note
Elimination::.
The function entry code is responsible for allocating any stack
space required for the function. This stack space consists of the
regions listed below. In most cases, these regions are allocated
in the order listed, with the last listed region closest to the
top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is
defined, and the highest address if it is not defined). You can
use a different order for a machine if doing so is more convenient
or required for compatibility reasons. Except in cases where
required by standard or by a debugger, there is no reason why the
stack layout used by GCC need agree with that used by other
compilers for a machine.
* A region of `current_function_pretend_args_size' bytes of
uninitialized space just underneath the first argument
arriving on the stack. (This may not be at the very start of
the allocated stack region if the calling sequence has pushed
anything else since pushing the stack arguments. But
usually, on such machines, nothing else has been pushed yet,
because the function prologue itself does all the pushing.)
This region is used on machines where an argument may be
passed partly in registers and partly in memory, and, in some
cases to support the features in `varargs.h' and `stdargs.h'.
* An area of memory used to save certain registers used by the
function. The size of this area, which may also include
space for such things as the return address and pointers to
previous stack frames, is machine-specific and usually
depends on which registers have been used in the function.
Machines with register windows often do not require a save
area.
* A region of at least SIZE bytes, possibly rounded up to an
allocation boundary, to contain the local variables of the
function. On some machines, this region and the save area
may occur in the opposite order, with the save area closer to
the top of the stack.
* Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a
region of `current_function_outgoing_args_size' bytes to be
used for outgoing argument lists of the function. *Note
Stack Arguments::.
Normally, it is necessary for the macros `FUNCTION_PROLOGUE' and
`FUNCTION_EPILOGUE' to treat leaf functions specially. The C
variable `leaf_function' is nonzero for such a function.
`EXIT_IGNORE_STACK'
Define this macro as a C expression that is nonzero if the return
instruction or the function epilogue ignores the value of the stack
pointer; in other words, if it is safe to delete an instruction to
adjust the stack pointer before a return from the function.
Note that this macro's value is relevant only for functions for
which frame pointers are maintained. It is never safe to delete a
final stack adjustment in a function that has no frame pointer,
and the compiler knows this regardless of `EXIT_IGNORE_STACK'.
`EPILOGUE_USES (REGNO)'
Define this macro as a C expression that is nonzero for registers
are used by the epilogue or the `return' pattern. The stack and
frame pointer registers are already be assumed to be used as
needed.
`FUNCTION_EPILOGUE (FILE, SIZE)'
A C compound statement that outputs the assembler code for exit
from a function. The epilogue is responsible for restoring the
saved registers and stack pointer to their values when the
function was called, and returning control to the caller. This
macro takes the same arguments as the macro `FUNCTION_PROLOGUE',
and the registers to restore are determined from `regs_ever_live'
and `CALL_USED_REGISTERS' in the same way.
On some machines, there is a single instruction that does all the
work of returning from the function. On these machines, give that
instruction the name `return' and do not define the macro
`FUNCTION_EPILOGUE' at all.
Do not define a pattern named `return' if you want the
`FUNCTION_EPILOGUE' to be used. If you want the target switches
to control whether return instructions or epilogues are used,
define a `return' pattern with a validity condition that tests the
target switches appropriately. If the `return' pattern's validity
condition is false, epilogues will be used.
On machines where functions may or may not have frame-pointers, the
function exit code must vary accordingly. Sometimes the code for
these two cases is completely different. To determine whether a
frame pointer is wanted, the macro can refer to the variable
`frame_pointer_needed'. The variable's value will be 1 when
compiling a function that needs a frame pointer.
Normally, `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE' must treat
leaf functions specially. The C variable `leaf_function' is
nonzero for such a function. *Note Leaf Functions::.
On some machines, some functions pop their arguments on exit while
others leave that for the caller to do. For example, the 68020
when given `-mrtd' pops arguments in functions that take a fixed
number of arguments.
Your definition of the macro `RETURN_POPS_ARGS' decides which
functions pop their own arguments. `FUNCTION_EPILOGUE' needs to
know what was decided. The variable that is called
`current_function_pops_args' is the number of bytes of its
arguments that a function should pop. *Note Scalar Return::.
`DELAY_SLOTS_FOR_EPILOGUE'
Define this macro if the function epilogue contains delay slots to
which instructions from the rest of the function can be "moved".
The definition should be a C expression whose value is an integer
representing the number of delay slots there.
`ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)'
A C expression that returns 1 if INSN can be placed in delay slot
number N of the epilogue.
The argument N is an integer which identifies the delay slot now
being considered (since different slots may have different rules of
eligibility). It is never negative and is always less than the
number of epilogue delay slots (what `DELAY_SLOTS_FOR_EPILOGUE'
returns). If you reject a particular insn for a given delay slot,
in principle, it may be reconsidered for a subsequent delay slot.
Also, other insns may (at least in principle) be considered for
the so far unfilled delay slot.
The insns accepted to fill the epilogue delay slots are put in an
RTL list made with `insn_list' objects, stored in the variable
`current_function_epilogue_delay_list'. The insn for the first
delay slot comes first in the list. Your definition of the macro
`FUNCTION_EPILOGUE' should fill the delay slots by outputting the
insns in this list, usually by calling `final_scan_insn'.
You need not define this macro if you did not define
`DELAY_SLOTS_FOR_EPILOGUE'.
`ASM_OUTPUT_MI_THUNK (FILE, THUNK_FNDECL, DELTA, FUNCTION)'
A C compound statement that outputs the assembler code for a thunk
function, used to implement C++ virtual function calls with
multiple inheritance. The thunk acts as a wrapper around a
virtual function, adjusting the implicit object parameter before
handing control off to the real function.
First, emit code to add the integer DELTA to the location that
contains the incoming first argument. Assume that this argument
contains a pointer, and is the one used to pass the `this' pointer
in C++. This is the incoming argument *before* the function
prologue, e.g. `%o0' on a sparc. The addition must preserve the
values of all other incoming arguments.
After the addition, emit code to jump to FUNCTION, which is a
`FUNCTION_DECL'. This is a direct pure jump, not a call, and does
not touch the return address. Hence returning from FUNCTION will
return to whoever called the current `thunk'.
The effect must be as if FUNCTION had been called directly with
the adjusted first argument. This macro is responsible for
emitting all of the code for a thunk function; `FUNCTION_PROLOGUE'
and `FUNCTION_EPILOGUE' are not invoked.
The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already
been extracted from it.) It might possibly be useful on some
targets, but probably not.
If you do not define this macro, the target-independent code in
the C++ frontend will generate a less efficient heavyweight thunk
that calls FUNCTION instead of jumping to it. The generic
approach does not support varargs.

972
gcc/gcc.info-23 Normal file
View File

@ -0,0 +1,972 @@
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
input file gcc.texi.
This file documents the use and the internals of the GNU compiler.
Published by the Free Software Foundation 59 Temple Place - Suite 330
Boston, MA 02111-1307 USA
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997 Free
Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License," "Funding for
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License," "Funding for Free Software," and "Protect Your Freedom--Fight
`Look And Feel'", and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.

File: gcc.info, Node: Profiling, Prev: Function Entry, Up: Stack and Calling
Generating Code for Profiling
-----------------------------
These macros will help you generate code for profiling.
`FUNCTION_PROFILER (FILE, LABELNO)'
A C statement or compound statement to output to FILE some
assembler code to call the profiling subroutine `mcount'. Before
calling, the assembler code must load the address of a counter
variable into a register where `mcount' expects to find the
address. The name of this variable is `LP' followed by the number
LABELNO, so you would generate the name using `LP%d' in a
`fprintf'.
The details of how the address should be passed to `mcount' are
determined by your operating system environment, not by GNU CC. To
figure them out, compile a small program for profiling using the
system's installed C compiler and look at the assembler code that
results.
`PROFILE_BEFORE_PROLOGUE'
Define this macro if the code for function profiling should come
before the function prologue. Normally, the profiling code comes
after.
`FUNCTION_BLOCK_PROFILER (FILE, LABELNO)'
A C statement or compound statement to output to FILE some
assembler code to initialize basic-block profiling for the current
object module. The global compile flag `profile_block_flag'
distingishes two profile modes.
`profile_block_flag != 2'
Output code to call the subroutine `__bb_init_func' once per
object module, passing it as its sole argument the address of
a block allocated in the object module.
The name of the block is a local symbol made with this
statement:
ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0);
Of course, since you are writing the definition of
`ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro,
you can take a short cut in the definition of this macro and
use the name that you know will result.
The first word of this block is a flag which will be nonzero
if the object module has already been initialized. So test
this word first, and do not call `__bb_init_func' if the flag
is nonzero. BLOCK_OR_LABEL contains a unique number which
may be used to generate a label as a branch destination when
`__bb_init_func' will not be called.
Described in assembler language, the code to be output looks
like:
cmp (LPBX0),0
bne local_label
parameter1 <- LPBX0
call __bb_init_func
local_label:
`profile_block_flag == 2'
Output code to call the subroutine `__bb_init_trace_func' and
pass two parameters to it. The first parameter is the same as
for `__bb_init_func'. The second parameter is the number of
the first basic block of the function as given by
BLOCK_OR_LABEL. Note that `__bb_init_trace_func' has to be
called, even if the object module has been initialized
already.
Described in assembler language, the code to be output looks
like:
parameter1 <- LPBX0
parameter2 <- BLOCK_OR_LABEL
call __bb_init_trace_func
`BLOCK_PROFILER (FILE, BLOCKNO)'
A C statement or compound statement to output to FILE some
assembler code to increment the count associated with the basic
block number BLOCKNO. The global compile flag
`profile_block_flag' distingishes two profile modes.
`profile_block_flag != 2'
Output code to increment the counter directly. Basic blocks
are numbered separately from zero within each compilation.
The count associated with block number BLOCKNO is at index
BLOCKNO in a vector of words; the name of this array is a
local symbol made with this statement:
ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2);
Of course, since you are writing the definition of
`ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro,
you can take a short cut in the definition of this macro and
use the name that you know will result.
Described in assembler language, the code to be output looks
like:
inc (LPBX2+4*BLOCKNO)
`profile_block_flag == 2'
Output code to initialize the global structure `__bb' and
call the function `__bb_trace_func', which will increment the
counter.
`__bb' consists of two words. In the first word, the current
basic block number, as given by BLOCKNO, has to be stored. In
the second word, the address of a block allocated in the
object module has to be stored. The address is given by the
label created with this statement:
ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0);
Described in assembler language, the code to be output looks
like:
move BLOCKNO -> (__bb)
move LPBX0 -> (__bb+4)
call __bb_trace_func
`FUNCTION_BLOCK_PROFILER_EXIT (FILE)'
A C statement or compound statement to output to FILE assembler
code to call function `__bb_trace_ret'. The assembler code should
only be output if the global compile flag `profile_block_flag' ==
2. This macro has to be used at every place where code for
returning from a function is generated (e.g. `FUNCTION_EPILOGUE').
Although you have to write the definition of `FUNCTION_EPILOGUE'
as well, you have to define this macro to tell the compiler, that
the proper call to `__bb_trace_ret' is produced.
`MACHINE_STATE_SAVE (ID)'
A C statement or compound statement to save all registers, which
may be clobbered by a function call, including condition codes.
The `asm' statement will be mostly likely needed to handle this
task. Local labels in the assembler code can be concatenated with
the string ID, to obtain a unique lable name.
Registers or condition codes clobbered by `FUNCTION_PROLOGUE' or
`FUNCTION_EPILOGUE' must be saved in the macros
`FUNCTION_BLOCK_PROFILER', `FUNCTION_BLOCK_PROFILER_EXIT' and
`BLOCK_PROFILER' prior calling `__bb_init_trace_func',
`__bb_trace_ret' and `__bb_trace_func' respectively.
`MACHINE_STATE_RESTORE (ID)'
A C statement or compound statement to restore all registers,
including condition codes, saved by `MACHINE_STATE_SAVE'.
Registers or condition codes clobbered by `FUNCTION_PROLOGUE' or
`FUNCTION_EPILOGUE' must be restored in the macros
`FUNCTION_BLOCK_PROFILER', `FUNCTION_BLOCK_PROFILER_EXIT' and
`BLOCK_PROFILER' after calling `__bb_init_trace_func',
`__bb_trace_ret' and `__bb_trace_func' respectively.
`BLOCK_PROFILER_CODE'
A C function or functions which are needed in the library to
support block profiling.

File: gcc.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros
Implementing the Varargs Macros
===============================
GNU CC comes with an implementation of `varargs.h' and `stdarg.h'
that work without change on machines that pass arguments on the stack.
Other machines require their own implementations of varargs, and the
two machine independent header files must have conditionals to include
it.
ANSI `stdarg.h' differs from traditional `varargs.h' mainly in the
calling convention for `va_start'. The traditional implementation
takes just one argument, which is the variable in which to store the
argument pointer. The ANSI implementation of `va_start' takes an
additional second argument. The user is supposed to write the last
named argument of the function here.
However, `va_start' should not use this argument. The way to find
the end of the named arguments is with the built-in functions described
below.
`__builtin_saveregs ()'
Use this built-in function to save the argument registers in
memory so that the varargs mechanism can access them. Both ANSI
and traditional versions of `va_start' must use
`__builtin_saveregs', unless you use `SETUP_INCOMING_VARARGS' (see
below) instead.
On some machines, `__builtin_saveregs' is open-coded under the
control of the macro `EXPAND_BUILTIN_SAVEREGS'. On other machines,
it calls a routine written in assembler language, found in
`libgcc2.c'.
Code generated for the call to `__builtin_saveregs' appears at the
beginning of the function, as opposed to where the call to
`__builtin_saveregs' is written, regardless of what the code is.
This is because the registers must be saved before the function
starts to use them for its own purposes.
`__builtin_args_info (CATEGORY)'
Use this built-in function to find the first anonymous arguments in
registers.
In general, a machine may have several categories of registers
used for arguments, each for a particular category of data types.
(For example, on some machines, floating-point registers are used
for floating-point arguments while other arguments are passed in
the general registers.) To make non-varargs functions use the
proper calling convention, you have defined the `CUMULATIVE_ARGS'
data type to record how many registers in each category have been
used so far
`__builtin_args_info' accesses the same data structure of type
`CUMULATIVE_ARGS' after the ordinary argument layout is finished
with it, with CATEGORY specifying which word to access. Thus, the
value indicates the first unused register in a given category.
Normally, you would use `__builtin_args_info' in the implementation
of `va_start', accessing each category just once and storing the
value in the `va_list' object. This is because `va_list' will
have to update the values, and there is no way to alter the values
accessed by `__builtin_args_info'.
`__builtin_next_arg (LASTARG)'
This is the equivalent of `__builtin_args_info', for stack
arguments. It returns the address of the first anonymous stack
argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns
the address of the location above the first anonymous stack
argument. Use it in `va_start' to initialize the pointer for
fetching arguments from the stack. Also use it in `va_start' to
verify that the second parameter LASTARG is the last named argument
of the current function.
`__builtin_classify_type (OBJECT)'
Since each machine has its own conventions for which data types are
passed in which kind of register, your implementation of `va_arg'
has to embody these conventions. The easiest way to categorize the
specified data type is to use `__builtin_classify_type' together
with `sizeof' and `__alignof__'.
`__builtin_classify_type' ignores the value of OBJECT, considering
only its data type. It returns an integer describing what kind of
type that is--integer, floating, pointer, structure, and so on.
The file `typeclass.h' defines an enumeration that you can use to
interpret the values of `__builtin_classify_type'.
These machine description macros help implement varargs:
`EXPAND_BUILTIN_SAVEREGS (ARGS)'
If defined, is a C expression that produces the machine-specific
code for a call to `__builtin_saveregs'. This code will be moved
to the very beginning of the function, before any parameter access
are made. The return value of this function should be an RTX that
contains the value to use as the return of `__builtin_saveregs'.
The argument ARGS is a `tree_list' containing the arguments that
were passed to `__builtin_saveregs'.
If this macro is not defined, the compiler will output an ordinary
call to the library function `__builtin_saveregs'.
`SETUP_INCOMING_VARARGS (ARGS_SO_FAR, MODE, TYPE,'
PRETEND_ARGS_SIZE, SECOND_TIME) This macro offers an alternative
to using `__builtin_saveregs' and defining the macro
`EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous register
arguments into the stack so that all the arguments appear to have
been passed consecutively on the stack. Once this is done, you
can use the standard implementation of varargs that works for
machines that pass all their arguments on the stack.
The argument ARGS_SO_FAR is the `CUMULATIVE_ARGS' data structure,
containing the values that obtain after processing of the named
arguments. The arguments MODE and TYPE describe the last named
argument--its machine mode and its data type as a tree node.
The macro implementation should do two things: first, push onto the
stack all the argument registers *not* used for the named
arguments, and second, store the size of the data thus pushed into
the `int'-valued variable whose name is supplied as the argument
PRETEND_ARGS_SIZE. The value that you store here will serve as
additional offset for setting up the stack frame.
Because you must generate code to push the anonymous arguments at
compile time without knowing their data types,
`SETUP_INCOMING_VARARGS' is only useful on machines that have just
a single category of argument register and use it uniformly for
all data types.
If the argument SECOND_TIME is nonzero, it means that the
arguments of the function are being analyzed for the second time.
This happens for an inline function, which is not actually
compiled until the end of the source file. The macro
`SETUP_INCOMING_VARARGS' should not generate any instructions in
this case.
`STRICT_ARGUMENT_NAMING'
Define this macro if the location where a function argument is
passed depends on whether or not it is a named argument.
This macro controls how the NAMED argument to `FUNCTION_ARG' is
set for varargs and stdarg functions. With this macro defined,
the NAMED argument is always true for named arguments, and false
for unnamed arguments. If this is not defined, but
`SETUP_INCOMING_VARARGS' is defined, then all arguments are
treated as named. Otherwise, all named arguments except the last
are treated as named.

File: gcc.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros
Trampolines for Nested Functions
================================
A "trampoline" is a small piece of code that is created at run time
when the address of a nested function is taken. It normally resides on
the stack, in the stack frame of the containing function. These macros
tell GNU CC how to generate code to allocate and initialize a
trampoline.
The instructions in the trampoline must do two things: load a
constant address into the static chain register, and jump to the real
address of the nested function. On CISC machines such as the m68k,
this requires two instructions, a move immediate and a jump. Then the
two addresses exist in the trampoline as word-long immediate operands.
On RISC machines, it is often necessary to load each address into a
register in two parts. Then pieces of each address form separate
immediate operands.
The code generated to initialize the trampoline must store the
variable parts--the static chain value and the function address--into
the immediate operands of the instructions. On a CISC machine, this is
simply a matter of copying each address to a memory reference at the
proper offset from the start of the trampoline. On a RISC machine, it
may be necessary to take out pieces of the address and store them
separately.
`TRAMPOLINE_TEMPLATE (FILE)'
A C statement to output, on the stream FILE, assembler code for a
block of data that contains the constant parts of a trampoline.
This code should not include a label--the label is taken care of
automatically.
If you do not define this macro, it means no template is needed
for the target. Do not define this macro on systems where the
block move code to copy the trampoline into place would be larger
than the code to generate it on the spot.
`TRAMPOLINE_SECTION'
The name of a subroutine to switch to the section in which the
trampoline template is to be placed (*note Sections::.). The
default is a value of `readonly_data_section', which places the
trampoline in the section containing read-only data.
`TRAMPOLINE_SIZE'
A C expression for the size in bytes of the trampoline, as an
integer.
`TRAMPOLINE_ALIGNMENT'
Alignment required for trampolines, in bits.
If you don't define this macro, the value of `BIGGEST_ALIGNMENT'
is used for aligning trampolines.
`INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN)'
A C statement to initialize the variable parts of a trampoline.
ADDR is an RTX for the address of the trampoline; FNADDR is an RTX
for the address of the nested function; STATIC_CHAIN is an RTX for
the static chain value that should be passed to the function when
it is called.
`ALLOCATE_TRAMPOLINE (FP)'
A C expression to allocate run-time space for a trampoline. The
expression value should be an RTX representing a memory reference
to the space for the trampoline.
If this macro is not defined, by default the trampoline is
allocated as a stack slot. This default is right for most
machines. The exceptions are machines where it is impossible to
execute instructions in the stack area. On such machines, you may
have to implement a separate stack, using this macro in
conjunction with `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE'.
FP points to a data structure, a `struct function', which
describes the compilation status of the immediate containing
function of the function which the trampoline is for. Normally
(when `ALLOCATE_TRAMPOLINE' is not defined), the stack slot for the
trampoline is in the stack frame of this containing function.
Other allocation strategies probably must do something analogous
with this information.
Implementing trampolines is difficult on many machines because they
have separate instruction and data caches. Writing into a stack
location fails to clear the memory in the instruction cache, so when
the program jumps to that location, it executes the old contents.
Here are two possible solutions. One is to clear the relevant parts
of the instruction cache whenever a trampoline is set up. The other is
to make all trampolines identical, by having them jump to a standard
subroutine. The former technique makes trampoline execution faster; the
latter makes initialization faster.
To clear the instruction cache when a trampoline is initialized,
define the following macros which describe the shape of the cache.
`INSN_CACHE_SIZE'
The total size in bytes of the cache.
`INSN_CACHE_LINE_WIDTH'
The length in bytes of each cache line. The cache is divided into
cache lines which are disjoint slots, each holding a contiguous
chunk of data fetched from memory. Each time data is brought into
the cache, an entire line is read at once. The data loaded into a
cache line is always aligned on a boundary equal to the line size.
`INSN_CACHE_DEPTH'
The number of alternative cache lines that can hold any particular
memory location.
Alternatively, if the machine has system calls or instructions to
clear the instruction cache directly, you can define the following
macro.
`CLEAR_INSN_CACHE (BEG, END)'
If defined, expands to a C expression clearing the *instruction
cache* in the specified interval. If it is not defined, and the
macro INSN_CACHE_SIZE is defined, some generic code is generated
to clear the cache. The definition of this macro would typically
be a series of `asm' statements. Both BEG and END are both pointer
expressions.
To use a standard subroutine, define the following macro. In
addition, you must make sure that the instructions in a trampoline fill
an entire cache line with identical instructions, or else ensure that
the beginning of the trampoline code is always aligned at the same
point in its cache line. Look in `m68k.h' as a guide.
`TRANSFER_FROM_TRAMPOLINE'
Define this macro if trampolines need a special subroutine to do
their work. The macro should expand to a series of `asm'
statements which will be compiled with GNU CC. They go in a
library function named `__transfer_from_trampoline'.
If you need to avoid executing the ordinary prologue code of a
compiled C function when you jump to the subroutine, you can do so
by placing a special label of your own in the assembler code. Use
one `asm' statement to generate an assembler label, and another to
make the label global. Then trampolines can use that label to
jump directly to your special assembler code.

File: gcc.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros
Implicit Calls to Library Routines
==================================
Here is an explanation of implicit calls to library routines.
`MULSI3_LIBCALL'
A C string constant giving the name of the function to call for
multiplication of one signed full-word by another. If you do not
define this macro, the default name is used, which is `__mulsi3',
a function defined in `libgcc.a'.
`DIVSI3_LIBCALL'
A C string constant giving the name of the function to call for
division of one signed full-word by another. If you do not define
this macro, the default name is used, which is `__divsi3', a
function defined in `libgcc.a'.
`UDIVSI3_LIBCALL'
A C string constant giving the name of the function to call for
division of one unsigned full-word by another. If you do not
define this macro, the default name is used, which is `__udivsi3',
a function defined in `libgcc.a'.
`MODSI3_LIBCALL'
A C string constant giving the name of the function to call for the
remainder in division of one signed full-word by another. If you
do not define this macro, the default name is used, which is
`__modsi3', a function defined in `libgcc.a'.
`UMODSI3_LIBCALL'
A C string constant giving the name of the function to call for the
remainder in division of one unsigned full-word by another. If
you do not define this macro, the default name is used, which is
`__umodsi3', a function defined in `libgcc.a'.
`MULDI3_LIBCALL'
A C string constant giving the name of the function to call for
multiplication of one signed double-word by another. If you do not
define this macro, the default name is used, which is `__muldi3',
a function defined in `libgcc.a'.
`DIVDI3_LIBCALL'
A C string constant giving the name of the function to call for
division of one signed double-word by another. If you do not
define this macro, the default name is used, which is `__divdi3', a
function defined in `libgcc.a'.
`UDIVDI3_LIBCALL'
A C string constant giving the name of the function to call for
division of one unsigned full-word by another. If you do not
define this macro, the default name is used, which is `__udivdi3',
a function defined in `libgcc.a'.
`MODDI3_LIBCALL'
A C string constant giving the name of the function to call for the
remainder in division of one signed double-word by another. If
you do not define this macro, the default name is used, which is
`__moddi3', a function defined in `libgcc.a'.
`UMODDI3_LIBCALL'
A C string constant giving the name of the function to call for the
remainder in division of one unsigned full-word by another. If
you do not define this macro, the default name is used, which is
`__umoddi3', a function defined in `libgcc.a'.
`INIT_TARGET_OPTABS'
Define this macro as a C statement that declares additional library
routines renames existing ones. `init_optabs' calls this macro
after initializing all the normal library routines.
`TARGET_EDOM'
The value of `EDOM' on the target machine, as a C integer constant
expression. If you don't define this macro, GNU CC does not
attempt to deposit the value of `EDOM' into `errno' directly.
Look in `/usr/include/errno.h' to find the value of `EDOM' on your
system.
If you do not define `TARGET_EDOM', then compiled code reports
domain errors by calling the library function and letting it
report the error. If mathematical functions on your system use
`matherr' when there is an error, then you should leave
`TARGET_EDOM' undefined so that `matherr' is used normally.
`GEN_ERRNO_RTX'
Define this macro as a C expression to create an rtl expression
that refers to the global "variable" `errno'. (On certain systems,
`errno' may not actually be a variable.) If you don't define this
macro, a reasonable default is used.
`TARGET_MEM_FUNCTIONS'
Define this macro if GNU CC should generate calls to the System V
(and ANSI C) library functions `memcpy' and `memset' rather than
the BSD functions `bcopy' and `bzero'.
`LIBGCC_NEEDS_DOUBLE'
Define this macro if only `float' arguments cannot be passed to
library routines (so they must be converted to `double'). This
macro affects both how library calls are generated and how the
library routines in `libgcc1.c' accept their arguments. It is
useful on machines where floating and fixed point arguments are
passed differently, such as the i860.
`FLOAT_ARG_TYPE'
Define this macro to override the type used by the library
routines to pick up arguments of type `float'. (By default, they
use a union of `float' and `int'.)
The obvious choice would be `float'--but that won't work with
traditional C compilers that expect all arguments declared as
`float' to arrive as `double'. To avoid this conversion, the
library routines ask for the value as some other type and then
treat it as a `float'.
On some systems, no other type will work for this. For these
systems, you must use `LIBGCC_NEEDS_DOUBLE' instead, to force
conversion of the values `double' before they are passed.
`FLOATIFY (PASSED-VALUE)'
Define this macro to override the way library routines redesignate
a `float' argument as a `float' instead of the type it was passed
as. The default is an expression which takes the `float' field of
the union.
`FLOAT_VALUE_TYPE'
Define this macro to override the type used by the library
routines to return values that ought to have type `float'. (By
default, they use `int'.)
The obvious choice would be `float'--but that won't work with
traditional C compilers gratuitously convert values declared as
`float' into `double'.
`INTIFY (FLOAT-VALUE)'
Define this macro to override the way the value of a
`float'-returning library routine should be packaged in order to
return it. These functions are actually declared to return type
`FLOAT_VALUE_TYPE' (normally `int').
These values can't be returned as type `float' because traditional
C compilers would gratuitously convert the value to a `double'.
A local variable named `intify' is always available when the macro
`INTIFY' is used. It is a union of a `float' field named `f' and
a field named `i' whose type is `FLOAT_VALUE_TYPE' or `int'.
If you don't define this macro, the default definition works by
copying the value through that union.
`nongcc_SI_type'
Define this macro as the name of the data type corresponding to
`SImode' in the system's own C compiler.
You need not define this macro if that type is `long int', as it
usually is.
`nongcc_word_type'
Define this macro as the name of the data type corresponding to the
word_mode in the system's own C compiler.
You need not define this macro if that type is `long int', as it
usually is.
`perform_...'
Define these macros to supply explicit C statements to carry out
various arithmetic operations on types `float' and `double' in the
library routines in `libgcc1.c'. See that file for a full list of
these macros and their arguments.
On most machines, you don't need to define any of these macros,
because the C compiler that comes with the system takes care of
doing them.
`NEXT_OBJC_RUNTIME'
Define this macro to generate code for Objective C message sending
using the calling convention of the NeXT system. This calling
convention involves passing the object, the selector and the
method arguments all at once to the method-lookup library function.
The default calling convention passes just the object and the
selector to the lookup function, which returns a pointer to the
method.

File: gcc.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Target Macros
Addressing Modes
================
This is about addressing modes.
`HAVE_POST_INCREMENT'
Define this macro if the machine supports post-increment
addressing.
`HAVE_PRE_INCREMENT'
`HAVE_POST_DECREMENT'
`HAVE_PRE_DECREMENT'
Similar for other kinds of addressing.
`CONSTANT_ADDRESS_P (X)'
A C expression that is 1 if the RTX X is a constant which is a
valid address. On most machines, this can be defined as
`CONSTANT_P (X)', but a few machines are more restrictive in which
constant addresses are supported.
`CONSTANT_P' accepts integer-values expressions whose values are
not explicitly known, such as `symbol_ref', `label_ref', and
`high' expressions and `const' arithmetic expressions, in addition
to `const_int' and `const_double' expressions.
`MAX_REGS_PER_ADDRESS'
A number, the maximum number of registers that can appear in a
valid memory address. Note that it is up to you to specify a
value equal to the maximum number that `GO_IF_LEGITIMATE_ADDRESS'
would ever accept.
`GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)'
A C compound statement with a conditional `goto LABEL;' executed
if X (an RTX) is a legitimate memory address on the target machine
for a memory operand of mode MODE.
It usually pays to define several simpler macros to serve as
subroutines for this one. Otherwise it may be too complicated to
understand.
This macro must exist in two variants: a strict variant and a
non-strict one. The strict variant is used in the reload pass. It
must be defined so that any pseudo-register that has not been
allocated a hard register is considered a memory reference. In
contexts where some kind of register is required, a pseudo-register
with no hard register must be rejected.
The non-strict variant is used in other passes. It must be
defined to accept all pseudo-registers in every context where some
kind of register is required.
Compiler source files that want to use the strict variant of this
macro define the macro `REG_OK_STRICT'. You should use an `#ifdef
REG_OK_STRICT' conditional to define the strict variant in that
case and the non-strict variant otherwise.
Subroutines to check for acceptable registers for various purposes
(one for base registers, one for index registers, and so on) are
typically among the subroutines used to define
`GO_IF_LEGITIMATE_ADDRESS'. Then only these subroutine macros
need have two variants; the higher levels of macros may be the
same whether strict or not.
Normally, constant addresses which are the sum of a `symbol_ref'
and an integer are stored inside a `const' RTX to mark them as
constant. Therefore, there is no need to recognize such sums
specifically as legitimate addresses. Normally you would simply
recognize any `const' as legitimate.
Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant
sums that are not marked with `const'. It assumes that a naked
`plus' indicates indexing. If so, then you *must* reject such
naked constant sums as illegitimate addresses, so that none of
them will be given to `PRINT_OPERAND_ADDRESS'.
On some machines, whether a symbolic address is legitimate depends
on the section that the address refers to. On these machines,
define the macro `ENCODE_SECTION_INFO' to store the information
into the `symbol_ref', and then check for it here. When you see a
`const', you will have to look inside it to find the `symbol_ref'
in order to determine the section. *Note Assembler Format::.
The best way to modify the name string is by adding text to the
beginning, with suitable punctuation to prevent any ambiguity.
Allocate the new name in `saveable_obstack'. You will have to
modify `ASM_OUTPUT_LABELREF' to remove and decode the added text
and output the name accordingly, and define `STRIP_NAME_ENCODING'
to access the original name string.
You can check the information stored here into the `symbol_ref' in
the definitions of the macros `GO_IF_LEGITIMATE_ADDRESS' and
`PRINT_OPERAND_ADDRESS'.
`REG_OK_FOR_BASE_P (X)'
A C expression that is nonzero if X (assumed to be a `reg' RTX) is
valid for use as a base register. For hard registers, it should
always accept those which the hardware permits and reject the
others. Whether the macro accepts or rejects pseudo registers
must be controlled by `REG_OK_STRICT' as described above. This
usually requires two variant definitions, of which `REG_OK_STRICT'
controls the one actually used.
`REG_MODE_OK_FOR_BASE_P (X, MODE)'
A C expression that is just like `REG_OK_FOR_BASE_P', except that
that expression may examine the mode of the memory reference in
MODE. You should define this macro if the mode of the memory
reference affects whether a register may be used as a base
register. If you define this macro, the compiler will use it
instead of `REG_OK_FOR_BASE_P'.
`REG_OK_FOR_INDEX_P (X)'
A C expression that is nonzero if X (assumed to be a `reg' RTX) is
valid for use as an index register.
The difference between an index register and a base register is
that the index register may be scaled. If an address involves the
sum of two registers, neither one of them scaled, then either one
may be labeled the "base" and the other the "index"; but whichever
labeling is used must fit the machine's constraints of which
registers may serve in each capacity. The compiler will try both
labelings, looking for one that is valid, and will reload one or
both registers only if neither labeling works.
`LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)'
A C compound statement that attempts to replace X with a valid
memory address for an operand of mode MODE. WIN will be a C
statement label elsewhere in the code; the macro definition may use
GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN);
to avoid further processing if the address has become legitimate.
X will always be the result of a call to `break_out_memory_refs',
and OLDX will be the operand that was given to that function to
produce X.
The code generated by this macro should not alter the substructure
of X. If it transforms X into a more legitimate form, it should
assign X (which will always be a C variable) a new value.
It is not necessary for this macro to come up with a legitimate
address. The compiler has standard ways of doing so in all cases.
In fact, it is safe for this macro to do nothing. But often a
machine-dependent strategy can generate better code.
`GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)'
A C statement or compound statement with a conditional `goto
LABEL;' executed if memory address X (an RTX) can have different
meanings depending on the machine mode of the memory reference it
is used for or if the address is valid for some modes but not
others.
Autoincrement and autodecrement addresses typically have
mode-dependent effects because the amount of the increment or
decrement is the size of the operand being addressed. Some
machines have other mode-dependent addresses. Many RISC machines
have no mode-dependent addresses.
You may assume that ADDR is a valid address for the machine.
`LEGITIMATE_CONSTANT_P (X)'
A C expression that is nonzero if X is a legitimate constant for
an immediate operand on the target machine. You can assume that X
satisfies `CONSTANT_P', so you need not check this. In fact, `1'
is a suitable definition for this macro on machines where anything
`CONSTANT_P' is valid.

File: gcc.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Target Macros
Condition Code Status
=====================
This describes the condition code status.
The file `conditions.h' defines a variable `cc_status' to describe
how the condition code was computed (in case the interpretation of the
condition code depends on the instruction that it was set by). This
variable contains the RTL expressions on which the condition code is
currently based, and several standard flags.
Sometimes additional machine-specific flags must be defined in the
machine description header file. It can also add additional
machine-specific information by defining `CC_STATUS_MDEP'.
`CC_STATUS_MDEP'
C code for a data type which is used for declaring the `mdep'
component of `cc_status'. It defaults to `int'.
This macro is not used on machines that do not use `cc0'.
`CC_STATUS_MDEP_INIT'
A C expression to initialize the `mdep' field to "empty". The
default definition does nothing, since most machines don't use the
field anyway. If you want to use the field, you should probably
define this macro to initialize it.
This macro is not used on machines that do not use `cc0'.
`NOTICE_UPDATE_CC (EXP, INSN)'
A C compound statement to set the components of `cc_status'
appropriately for an insn INSN whose body is EXP. It is this
macro's responsibility to recognize insns that set the condition
code as a byproduct of other activity as well as those that
explicitly set `(cc0)'.
This macro is not used on machines that do not use `cc0'.
If there are insns that do not set the condition code but do alter
other machine registers, this macro must check to see whether they
invalidate the expressions that the condition code is recorded as
reflecting. For example, on the 68000, insns that store in address
registers do not set the condition code, which means that usually
`NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns.
But suppose that the previous insn set the condition code based
on location `a4@(102)' and the current insn stores a new value in
`a4'. Although the condition code is not changed by this, it will
no longer be true that it reflects the contents of `a4@(102)'.
Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case
to say that nothing is known about the condition code value.
The definition of `NOTICE_UPDATE_CC' must be prepared to deal with
the results of peephole optimization: insns whose patterns are
`parallel' RTXs containing various `reg', `mem' or constants which
are just the operands. The RTL structure of these insns is not
sufficient to indicate what the insns actually do. What
`NOTICE_UPDATE_CC' should do when it sees one is just to run
`CC_STATUS_INIT'.
A possible definition of `NOTICE_UPDATE_CC' is to call a function
that looks at an attribute (*note Insn Attributes::.) named, for
example, `cc'. This avoids having detailed information about
patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'.
`EXTRA_CC_MODES'
A list of names to be used for additional modes for condition code
values in registers (*note Jump Patterns::.). These names are
added to `enum machine_mode' and all have class `MODE_CC'. By
convention, they should start with `CC' and end with `mode'.
You should only define this macro if your machine does not use
`cc0' and only if additional modes are required.
`EXTRA_CC_NAMES'
A list of C strings giving the names for the modes listed in
`EXTRA_CC_MODES'. For example, the Sparc defines this macro and
`EXTRA_CC_MODES' as
#define EXTRA_CC_MODES CC_NOOVmode, CCFPmode, CCFPEmode
#define EXTRA_CC_NAMES "CC_NOOV", "CCFP", "CCFPE"
This macro is not required if `EXTRA_CC_MODES' is not defined.
`SELECT_CC_MODE (OP, X, Y)'
Returns a mode from class `MODE_CC' to be used when comparison
operation code OP is applied to rtx X and Y. For example, on the
Sparc, `SELECT_CC_MODE' is defined as (see *note Jump Patterns::.
for a description of the reason for this definition)
#define SELECT_CC_MODE(OP,X,Y) \
(GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \
? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode) \
: ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \
|| GET_CODE (X) == NEG) \
? CC_NOOVmode : CCmode))
You need not define this macro if `EXTRA_CC_MODES' is not defined.
`CANONICALIZE_COMPARISON (CODE, OP0, OP1)'
One some machines not all possible comparisons are defined, but
you can convert an invalid comparison into a valid one. For
example, the Alpha does not have a `GT' comparison, but you can
use an `LT' comparison instead and swap the order of the operands.
On such machines, define this macro to be a C statement to do any
required conversions. CODE is the initial comparison code and OP0
and OP1 are the left and right operands of the comparison,
respectively. You should modify CODE, OP0, and OP1 as required.
GNU CC will not assume that the comparison resulting from this
macro is valid but will see if the resulting insn matches a
pattern in the `md' file.
You need not define this macro if it would never change the
comparison code or operands.
`REVERSIBLE_CC_MODE (MODE)'
A C expression whose value is one if it is always safe to reverse a
comparison whose mode is MODE. If `SELECT_CC_MODE' can ever
return MODE for a floating-point inequality comparison, then
`REVERSIBLE_CC_MODE (MODE)' must be zero.
You need not define this macro if it would always returns zero or
if the floating-point format is anything other than
`IEEE_FLOAT_FORMAT'. For example, here is the definition used on
the Sparc, where floating-point inequality comparisons are always
given `CCFPEmode':
#define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode)

1043
gcc/gcc.info-24 Normal file
View File

File diff suppressed because it is too large Load Diff

1143
gcc/gcc.info-25 Normal file
View File

File diff suppressed because it is too large Load Diff

973
gcc/gcc.info-26 Normal file
View File

@ -0,0 +1,973 @@
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
input file gcc.texi.
This file documents the use and the internals of the GNU compiler.
Published by the Free Software Foundation 59 Temple Place - Suite 330
Boston, MA 02111-1307 USA
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997 Free
Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License," "Funding for
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License," "Funding for Free Software," and "Protect Your Freedom--Fight
`Look And Feel'", and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.

File: gcc.info, Node: Misc, Prev: Cross-compilation, Up: Target Macros
Miscellaneous Parameters
========================
Here are several miscellaneous parameters.
`PREDICATE_CODES'
Define this if you have defined special-purpose predicates in the
file `MACHINE.c'. This macro is called within an initializer of an
array of structures. The first field in the structure is the name
of a predicate and the second field is an array of rtl codes. For
each predicate, list all rtl codes that can be in expressions
matched by the predicate. The list should have a trailing comma.
Here is an example of two entries in the list for a typical RISC
machine:
#define PREDICATE_CODES \
{"gen_reg_rtx_operand", {SUBREG, REG}}, \
{"reg_or_short_cint_operand", {SUBREG, REG, CONST_INT}},
Defining this macro does not affect the generated code (however,
incorrect definitions that omit an rtl code that may be matched by
the predicate can cause the compiler to malfunction). Instead, it
allows the table built by `genrecog' to be more compact and
efficient, thus speeding up the compiler. The most important
predicates to include in the list specified by this macro are
thoses used in the most insn patterns.
`CASE_VECTOR_MODE'
An alias for a machine mode name. This is the machine mode that
elements of a jump-table should have.
`CASE_VECTOR_PC_RELATIVE'
Define this macro if jump-tables should contain relative addresses.
`CASE_DROPS_THROUGH'
Define this if control falls through a `case' insn when the index
value is out of range. This means the specified default-label is
actually ignored by the `case' insn proper.
`CASE_VALUES_THRESHOLD'
Define this to be the smallest number of different values for
which it is best to use a jump-table instead of a tree of
conditional branches. The default is four for machines with a
`casesi' instruction and five otherwise. This is best for most
machines.
`WORD_REGISTER_OPERATIONS'
Define this macro if operations between registers with integral
mode smaller than a word are always performed on the entire
register. Most RISC machines have this property and most CISC
machines do not.
`LOAD_EXTEND_OP (MODE)'
Define this macro to be a C expression indicating when insns that
read memory in MODE, an integral mode narrower than a word, set the
bits outside of MODE to be either the sign-extension or the
zero-extension of the data read. Return `SIGN_EXTEND' for values
of MODE for which the insn sign-extends, `ZERO_EXTEND' for which
it zero-extends, and `NIL' for other modes.
This macro is not called with MODE non-integral or with a width
greater than or equal to `BITS_PER_WORD', so you may return any
value in this case. Do not define this macro if it would always
return `NIL'. On machines where this macro is defined, you will
normally define it as the constant `SIGN_EXTEND' or `ZERO_EXTEND'.
`IMPLICIT_FIX_EXPR'
An alias for a tree code that should be used by default for
conversion of floating point values to fixed point. Normally,
`FIX_ROUND_EXPR' is used.
`FIXUNS_TRUNC_LIKE_FIX_TRUNC'
Define this macro if the same instructions that convert a floating
point number to a signed fixed point number also convert validly
to an unsigned one.
`EASY_DIV_EXPR'
An alias for a tree code that is the easiest kind of division to
compile code for in the general case. It may be `TRUNC_DIV_EXPR',
`FLOOR_DIV_EXPR', `CEIL_DIV_EXPR' or `ROUND_DIV_EXPR'. These four
division operators differ in how they round the result to an
integer. `EASY_DIV_EXPR' is used when it is permissible to use
any of those kinds of division and the choice should be made on
the basis of efficiency.
`MOVE_MAX'
The maximum number of bytes that a single instruction can move
quickly between memory and registers or between two memory
locations.
`MAX_MOVE_MAX'
The maximum number of bytes that a single instruction can move
quickly between memory and registers or between two memory
locations. If this is undefined, the default is `MOVE_MAX'.
Otherwise, it is the constant value that is the largest value that
`MOVE_MAX' can have at run-time.
`SHIFT_COUNT_TRUNCATED'
A C expression that is nonzero if on this machine the number of
bits actually used for the count of a shift operation is equal to
the number of bits needed to represent the size of the object
being shifted. When this macro is non-zero, the compiler will
assume that it is safe to omit a sign-extend, zero-extend, and
certain bitwise `and' instructions that truncates the count of a
shift operation. On machines that have instructions that act on
bitfields at variable positions, which may include `bit test'
instructions, a nonzero `SHIFT_COUNT_TRUNCATED' also enables
deletion of truncations of the values that serve as arguments to
bitfield instructions.
If both types of instructions truncate the count (for shifts) and
position (for bitfield operations), or if no variable-position
bitfield instructions exist, you should define this macro.
However, on some machines, such as the 80386 and the 680x0,
truncation only applies to shift operations and not the (real or
pretended) bitfield operations. Define `SHIFT_COUNT_TRUNCATED' to
be zero on such machines. Instead, add patterns to the `md' file
that include the implied truncation of the shift instructions.
You need not define this macro if it would always have the value
of zero.
`TRULY_NOOP_TRUNCATION (OUTPREC, INPREC)'
A C expression which is nonzero if on this machine it is safe to
"convert" an integer of INPREC bits to one of OUTPREC bits (where
OUTPREC is smaller than INPREC) by merely operating on it as if it
had only OUTPREC bits.
On many machines, this expression can be 1.
When `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for
modes for which `MODES_TIEABLE_P' is 0, suboptimal code can result.
If this is the case, making `TRULY_NOOP_TRUNCATION' return 0 in
such cases may improve things.
`STORE_FLAG_VALUE'
A C expression describing the value returned by a comparison
operator with an integral mode and stored by a store-flag
instruction (`sCOND') when the condition is true. This
description must apply to *all* the `sCOND' patterns and all the
comparison operators whose results have a `MODE_INT' mode.
A value of 1 or -1 means that the instruction implementing the
comparison operator returns exactly 1 or -1 when the comparison is
true and 0 when the comparison is false. Otherwise, the value
indicates which bits of the result are guaranteed to be 1 when the
comparison is true. This value is interpreted in the mode of the
comparison operation, which is given by the mode of the first
operand in the `sCOND' pattern. Either the low bit or the sign
bit of `STORE_FLAG_VALUE' be on. Presently, only those bits are
used by the compiler.
If `STORE_FLAG_VALUE' is neither 1 or -1, the compiler will
generate code that depends only on the specified bits. It can also
replace comparison operators with equivalent operations if they
cause the required bits to be set, even if the remaining bits are
undefined. For example, on a machine whose comparison operators
return an `SImode' value and where `STORE_FLAG_VALUE' is defined as
`0x80000000', saying that just the sign bit is relevant, the
expression
(ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0))
can be converted to
(ashift:SI X (const_int N))
where N is the appropriate shift count to move the bit being
tested into the sign bit.
There is no way to describe a machine that always sets the
low-order bit for a true value, but does not guarantee the value
of any other bits, but we do not know of any machine that has such
an instruction. If you are trying to port GNU CC to such a
machine, include an instruction to perform a logical-and of the
result with 1 in the pattern for the comparison operators and let
us know (*note How to Report Bugs: Bug Reporting.).
Often, a machine will have multiple instructions that obtain a
value from a comparison (or the condition codes). Here are rules
to guide the choice of value for `STORE_FLAG_VALUE', and hence the
instructions to be used:
* Use the shortest sequence that yields a valid definition for
`STORE_FLAG_VALUE'. It is more efficient for the compiler to
"normalize" the value (convert it to, e.g., 1 or 0) than for
the comparison operators to do so because there may be
opportunities to combine the normalization with other
operations.
* For equal-length sequences, use a value of 1 or -1, with -1
being slightly preferred on machines with expensive jumps and
1 preferred on other machines.
* As a second choice, choose a value of `0x80000001' if
instructions exist that set both the sign and low-order bits
but do not define the others.
* Otherwise, use a value of `0x80000000'.
Many machines can produce both the value chosen for
`STORE_FLAG_VALUE' and its negation in the same number of
instructions. On those machines, you should also define a pattern
for those cases, e.g., one matching
(set A (neg:M (ne:M B C)))
Some machines can also perform `and' or `plus' operations on
condition code values with less instructions than the corresponding
`sCOND' insn followed by `and' or `plus'. On those machines,
define the appropriate patterns. Use the names `incscc' and
`decscc', respectively, for the patterns which perform `plus' or
`minus' operations on condition code values. See `rs6000.md' for
some examples. The GNU Superoptizer can be used to find such
instruction sequences on other machines.
You need not define `STORE_FLAG_VALUE' if the machine has no
store-flag instructions.
`FLOAT_STORE_FLAG_VALUE'
A C expression that gives a non-zero floating point value that is
returned when comparison operators with floating-point results are
true. Define this macro on machine that have comparison
operations that return floating-point values. If there are no
such operations, do not define this macro.
`Pmode'
An alias for the machine mode for pointers. On most machines,
define this to be the integer mode corresponding to the width of a
hardware pointer; `SImode' on 32-bit machine or `DImode' on 64-bit
machines. On some machines you must define this to be one of the
partial integer modes, such as `PSImode'.
The width of `Pmode' must be at least as large as the value of
`POINTER_SIZE'. If it is not equal, you must define the macro
`POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to
`Pmode'.
`FUNCTION_MODE'
An alias for the machine mode used for memory references to
functions being called, in `call' RTL expressions. On most
machines this should be `QImode'.
`INTEGRATE_THRESHOLD (DECL)'
A C expression for the maximum number of instructions above which
the function DECL should not be inlined. DECL is a
`FUNCTION_DECL' node.
The default definition of this macro is 64 plus 8 times the number
of arguments that the function accepts. Some people think a larger
threshold should be used on RISC machines.
`SCCS_DIRECTIVE'
Define this if the preprocessor should ignore `#sccs' directives
and print no error message.
`NO_IMPLICIT_EXTERN_C'
Define this macro if the system header files support C++ as well
as C. This macro inhibits the usual method of using system header
files in C++, which is to pretend that the file's contents are
enclosed in `extern "C" {...}'.
`HANDLE_PRAGMA (STREAM, NODE)'
Define this macro if you want to implement any pragmas. If
defined, it is a C expression whose value is 1 if the pragma was
handled by the function. The argument STREAM is the stdio input
stream from which the source text can be read. NODE is the tree
node for the identifier after the `#pragma'.
It is generally a bad idea to implement new uses of `#pragma'. The
only reason to define this macro is for compatibility with other
compilers that do support `#pragma' for the sake of any user
programs which already use it.
`VALID_MACHINE_DECL_ATTRIBUTE (DECL, ATTRIBUTES, IDENTIFIER, ARGS)'
If defined, a C expression whose value is nonzero if IDENTIFIER
with arguments ARGS is a valid machine specific attribute for DECL.
The attributes in ATTRIBUTES have previously been assigned to DECL.
`VALID_MACHINE_TYPE_ATTRIBUTE (TYPE, ATTRIBUTES, IDENTIFIER, ARGS)'
If defined, a C expression whose value is nonzero if IDENTIFIER
with arguments ARGS is a valid machine specific attribute for TYPE.
The attributes in ATTRIBUTES have previously been assigned to TYPE.
`COMP_TYPE_ATTRIBUTES (TYPE1, TYPE2)'
If defined, a C expression whose value is zero if the attributes on
TYPE1 and TYPE2 are incompatible, one if they are compatible, and
two if they are nearly compatible (which causes a warning to be
generated).
`SET_DEFAULT_TYPE_ATTRIBUTES (TYPE)'
If defined, a C statement that assigns default attributes to newly
defined TYPE.
`DOLLARS_IN_IDENTIFIERS'
Define this macro to control use of the character `$' in identifier
names. 0 means `$' is not allowed by default; 1 means it is
allowed. 1 is the default; there is no need to define this macro
in that case. This macro controls the compiler proper; it does
not affect the preprocessor.
`NO_DOLLAR_IN_LABEL'
Define this macro if the assembler does not accept the character
`$' in label names. By default constructors and destructors in
G++ have `$' in the identifiers. If this macro is defined, `.' is
used instead.
`NO_DOT_IN_LABEL'
Define this macro if the assembler does not accept the character
`.' in label names. By default constructors and destructors in G++
have names that use `.'. If this macro is defined, these names
are rewritten to avoid `.'.
`DEFAULT_MAIN_RETURN'
Define this macro if the target system expects every program's
`main' function to return a standard "success" value by default
(if no other value is explicitly returned).
The definition should be a C statement (sans semicolon) to
generate the appropriate rtl instructions. It is used only when
compiling the end of `main'.
`HAVE_ATEXIT'
Define this if the target system supports the function `atexit'
from the ANSI C standard. If this is not defined, and
`INIT_SECTION_ASM_OP' is not defined, a default `exit' function
will be provided to support C++.
`EXIT_BODY'
Define this if your `exit' function needs to do something besides
calling an external function `_cleanup' before terminating with
`_exit'. The `EXIT_BODY' macro is only needed if neither
`HAVE_ATEXIT' nor `INIT_SECTION_ASM_OP' are defined.
`INSN_SETS_ARE_DELAYED (INSN)'
Define this macro as a C expression that is nonzero if it is safe
for the delay slot scheduler to place instructions in the delay
slot of INSN, even if they appear to use a resource set or
clobbered in INSN. INSN is always a `jump_insn' or an `insn'; GNU
CC knows that every `call_insn' has this behavior. On machines
where some `insn' or `jump_insn' is really a function call and
hence has this behavior, you should define this macro.
You need not define this macro if it would always return zero.
`INSN_REFERENCES_ARE_DELAYED (INSN)'
Define this macro as a C expression that is nonzero if it is safe
for the delay slot scheduler to place instructions in the delay
slot of INSN, even if they appear to set or clobber a resource
referenced in INSN. INSN is always a `jump_insn' or an `insn'.
On machines where some `insn' or `jump_insn' is really a function
call and its operands are registers whose use is actually in the
subroutine it calls, you should define this macro. Doing so
allows the delay slot scheduler to move instructions which copy
arguments into the argument registers into the delay slot of INSN.
You need not define this macro if it would always return zero.
`MACHINE_DEPENDENT_REORG (INSN)'
In rare cases, correct code generation requires extra machine
dependent processing between the second jump optimization pass and
delayed branch scheduling. On those machines, define this macro
as a C statement to act on the code starting at INSN.
`MULTIPLE_SYMBOL_SPACES'
Define this macro if in some cases global symbols from one
translation unit may not be bound to undefined symbols in another
translation unit without user intervention. For instance, under
Microsoft Windows symbols must be explicitly imported from shared
libraries (DLLs).
`GIV_SORT_CRITERION (GIV1, GIV2)'
In some cases, the strength reduction optimization pass can
produce better code if this is defined. This macro controls the
order that induction variables are combined. This macro is
particularly useful if the target has limited addressing modes.
For instance, the SH target has only positive offsets in
addresses. Thus sorting to put the smallest address first allows
the most combinations to be found.

File: gcc.info, Node: Config, Next: Fragments, Prev: Target Macros, Up: Top
The Configuration File
**********************
The configuration file `xm-MACHINE.h' contains macro definitions
that describe the machine and system on which the compiler is running,
unlike the definitions in `MACHINE.h', which describe the machine for
which the compiler is producing output. Most of the values in
`xm-MACHINE.h' are actually the same on all machines that GNU CC runs
on, so large parts of all configuration files are identical. But there
are some macros that vary:
`USG'
Define this macro if the host system is System V.
`VMS'
Define this macro if the host system is VMS.
`FATAL_EXIT_CODE'
A C expression for the status code to be returned when the compiler
exits after serious errors.
`SUCCESS_EXIT_CODE'
A C expression for the status code to be returned when the compiler
exits without serious errors.
`HOST_WORDS_BIG_ENDIAN'
Defined if the host machine stores words of multi-word values in
big-endian order. (GNU CC does not depend on the host byte
ordering within a word.)
`HOST_FLOAT_WORDS_BIG_ENDIAN'
Define this macro to be 1 if the host machine stores `DFmode',
`XFmode' or `TFmode' floating point numbers in memory with the
word containing the sign bit at the lowest address; otherwise,
define it to be zero.
This macro need not be defined if the ordering is the same as for
multi-word integers.
`HOST_FLOAT_FORMAT'
A numeric code distinguishing the floating point format for the
host machine. See `TARGET_FLOAT_FORMAT' in *Note Storage Layout::
for the alternatives and default.
`HOST_BITS_PER_CHAR'
A C expression for the number of bits in `char' on the host
machine.
`HOST_BITS_PER_SHORT'
A C expression for the number of bits in `short' on the host
machine.
`HOST_BITS_PER_INT'
A C expression for the number of bits in `int' on the host machine.
`HOST_BITS_PER_LONG'
A C expression for the number of bits in `long' on the host
machine.
`ONLY_INT_FIELDS'
Define this macro to indicate that the host compiler only supports
`int' bit fields, rather than other integral types, including
`enum', as do most C compilers.
`OBSTACK_CHUNK_SIZE'
A C expression for the size of ordinary obstack chunks. If you
don't define this, a usually-reasonable default is used.
`OBSTACK_CHUNK_ALLOC'
The function used to allocate obstack chunks. If you don't define
this, `xmalloc' is used.
`OBSTACK_CHUNK_FREE'
The function used to free obstack chunks. If you don't define
this, `free' is used.
`USE_C_ALLOCA'
Define this macro to indicate that the compiler is running with the
`alloca' implemented in C. This version of `alloca' can be found
in the file `alloca.c'; to use it, you must also alter the
`Makefile' variable `ALLOCA'. (This is done automatically for the
systems on which we know it is needed.)
If you do define this macro, you should probably do it as follows:
#ifndef __GNUC__
#define USE_C_ALLOCA
#else
#define alloca __builtin_alloca
#endif
so that when the compiler is compiled with GNU CC it uses the more
efficient built-in `alloca' function.
`FUNCTION_CONVERSION_BUG'
Define this macro to indicate that the host compiler does not
properly handle converting a function value to a
pointer-to-function when it is used in an expression.
`HAVE_VPRINTF'
Define this if the library function `vprintf' is available on your
system.
`MULTIBYTE_CHARS'
Define this macro to enable support for multibyte characters in the
input to GNU CC. This requires that the host system support the
ANSI C library functions for converting multibyte characters to
wide characters.
`HAVE_PUTENV'
Define this if the library function `putenv' is available on your
system.
`POSIX'
Define this if your system is POSIX.1 compliant.
`HAVE_POPEN'
Define this if the library function `popen' is available on your
system.
`NO_SYS_SIGLIST'
Define this if your system *does not* provide the variable
`sys_siglist'.
Some systems do provide this variable, but with a different name
such as `_sys_siglist'. On these systems, you can define
`sys_siglist' as a macro which expands into the name actually
provided.
Autoconf normally defines `SYS_SIGLIST_DECLARED' when it finds a
declaration of `sys_siglist' in the system header files. However,
when you define `sys_siglist' to a different name autoconf will
not automatically define `SYS_SIGLIST_DECLARED'. Therefore, if
you define `sys_siglist', you should also define
`SYS_SIGLIST_DECLARED'.
`USE_PROTOTYPES'
Define this to be 1 if you know that the host compiler supports
prototypes, even if it doesn't define __STDC__, or define it to be
0 if you do not want any prototypes used in compiling GNU CC. If
`USE_PROTOTYPES' is not defined, it will be determined
automatically whether your compiler supports prototypes by
checking if `__STDC__' is defined.
`NO_MD_PROTOTYPES'
Define this if you wish suppression of prototypes generated from
the machine description file, but to use other prototypes within
GNU CC. If `USE_PROTOTYPES' is defined to be 0, or the host
compiler does not support prototypes, this macro has no effect.
`MD_CALL_PROTOTYPES'
Define this if you wish to generate prototypes for the `gen_call'
or `gen_call_value' functions generated from the machine
description file. If `USE_PROTOTYPES' is defined to be 0, or the
host compiler does not support prototypes, or `NO_MD_PROTOTYPES'
is defined, this macro has no effect. As soon as all of the
machine descriptions are modified to have the appropriate number
of arguments, this macro will be removed.
`NO_STAB_H'
Define this if your system does not have the include file
`stab.h'. If `USG' is defined, `NO_STAB_H' is assumed.
`PATH_SEPARATOR'
Define this macro to be a C character constant representing the
character used to separate components in paths. The default value
is the colon character
`DIR_SEPARATOR'
If your system uses some character other than slash to separate
directory names within a file specification, define this macro to
be a C character constant specifying that character. When GNU CC
displays file names, the character you specify will be used. GNU
CC will test for both slash and the character you specify when
parsing filenames.
`OBJECT_SUFFIX'
Define this macro to be a C string representing the suffix for
object files on your machine. If you do not define this macro,
GNU CC will use `.o' as the suffix for object files.
`EXECUTABLE_SUFFIX'
Define this macro to be a C string representing the suffix for
executable files on your machine. If you do not define this
macro, GNU CC will use the null string as the suffix for object
files.
`COLLECT_EXPORT_LIST'
If defined, `collect2' will scan the individual object files
specified on its command line and create an export list for the
linker. Define this macro for systems like AIX, where the linker
discards object files that are not referenced from `main' and uses
export lists.
In addition, configuration files for system V define `bcopy',
`bzero' and `bcmp' as aliases. Some files define `alloca' as a macro
when compiled with GNU CC, in order to take advantage of the benefit of
GNU CC's built-in `alloca'.

File: gcc.info, Node: Fragments, Next: Funding, Prev: Config, Up: Top
Makefile Fragments
******************
When you configure GNU CC using the `configure' script (*note
Installation::.), it will construct the file `Makefile' from the
template file `Makefile.in'. When it does this, it will incorporate
makefile fragment files from the `config' directory, named `t-TARGET'
and `x-HOST'. If these files do not exist, it means nothing needs to
be added for a given target or host.
* Menu:
* Target Fragment:: Writing the `t-TARGET' file.
* Host Fragment:: Writing the `x-HOST' file.

File: gcc.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments
The Target Makefile Fragment
============================
The target makefile fragment, `t-TARGET', defines special target
dependent variables and targets used in the `Makefile':
`LIBGCC1'
The rule to use to build `libgcc1.a'. If your target does not
need to use the functions in `libgcc1.a', set this to empty.
*Note Interface::.
`CROSS_LIBGCC1'
The rule to use to build `libgcc1.a' when building a cross
compiler. If your target does not need to use the functions in
`libgcc1.a', set this to empty. *Note Cross Runtime::.
`LIBGCC2_CFLAGS'
Compiler flags to use when compiling `libgcc2.c'.
`LIB2FUNCS_EXTRA'
A list of source file names to be compiled or assembled and
inserted into `libgcc.a'.
`CRTSTUFF_T_CFLAGS'
Special flags used when compiling `crtstuff.c'. *Note
Initialization::.
`CRTSTUFF_T_CFLAGS_S'
Special flags used when compiling `crtstuff.c' for shared linking.
Used if you use `crtbeginS.o' and `crtendS.o' in `EXTRA-PARTS'.
*Note Initialization::.
`MULTILIB_OPTIONS'
For some targets, invoking GNU CC in different ways produces
objects that can not be linked together. For example, for some
targets GNU CC produces both big and little endian code. For
these targets, you must arrange for multiple versions of
`libgcc.a' to be compiled, one for each set of incompatible
options. When GNU CC invokes the linker, it arranges to link in
the right version of `libgcc.a', based on the command line options
used.
The `MULTILIB_OPTIONS' macro lists the set of options for which
special versions of `libgcc.a' must be built. Write options that
are mutually incompatible side by side, separated by a slash.
Write options that may be used together separated by a space. The
build procedure will build all combinations of compatible options.
For example, if you set `MULTILIB_OPTIONS' to `m68000/m68020
msoft-float', `Makefile' will build special versions of `libgcc.a'
using the sets of options `-m68000', `-m68020', `-msoft-float',
`-m68000 -msoft-float', and `-m68020 -msoft-float'.
`MULTILIB_DIRNAMES'
If `MULTILIB_OPTIONS' is used, this variable specifies the
directory names that should be used to hold the various libraries.
Write one element in `MULTILIB_DIRNAMES' for each element in
`MULTILIB_OPTIONS'. If `MULTILIB_DIRNAMES' is not used, the
default value will be `MULTILIB_OPTIONS', with all slashes treated
as spaces.
For example, if `MULTILIB_OPTIONS' is specified as `m68000/m68020
msoft-float', then the default value of `MULTILIB_DIRNAMES' is
`m68000 m68020 msoft-float'. You may specify a different value if
you desire a different set of directory names.
`MULTILIB_MATCHES'
Sometimes the same option may be written in two different ways.
If an option is listed in `MULTILIB_OPTIONS', GNU CC needs to know
about any synonyms. In that case, set `MULTILIB_MATCHES' to a
list of items of the form `option=option' to describe all relevant
synonyms. For example, `m68000=mc68000 m68020=mc68020'.
`MULTILIB_EXCEPTIONS'
Sometimes when there are multiple sets of `MULTILIB_OPTIONS' being
specified, there are combinations that should not be built. In
that case, set `MULTILIB_EXCEPTIONS' to be all of the switch
exceptions in shell case syntax that should not be built.
For example, in the PowerPC embedded ABI support, it was not
desirable to build libraries that compiled with the
`-mcall-aixdesc' option and either of the `-mcall-aixdesc' or
`-mlittle' options at the same time, and therefore
`MULTILIB_EXCEPTIONS' is set to `*mrelocatable/*mcall-aixdesc*
*mlittle/*mcall-aixdesc*'.
`MULTILIB_EXTRA_OPTS'
Sometimes it is desirable that when building multiple versions of
`libgcc.a' certain options should always be passed on to the
compiler. In that case, set `MULTILIB_EXTRA_OPTS' to be the list
of options to be used for all builds.

File: gcc.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments
The Host Makefile Fragment
==========================
The host makefile fragment, `x-HOST', defines special host dependent
variables and targets used in the `Makefile':
`CC'
The compiler to use when building the first stage.
`CLIB'
Additional host libraries to link with.
`OLDCC'
The compiler to use when building `libgcc1.a' for a native
compilation.
`OLDAR'
The version of `ar' to use when building `libgcc1.a' for a native
compilation.
`INSTALL'
The install program to use.

File: gcc.info, Node: Funding, Next: Look and Feel, Prev: Fragments, Up: Top
Funding Free Software
*********************
If you want to have more free software a few years from now, it makes
sense for you to help encourage people to contribute funds for its
development. The most effective approach known is to encourage
commercial redistributors to donate.
Users of free software systems can boost the pace of development by
encouraging for-a-fee distributors to donate part of their selling price
to free software developers--the Free Software Foundation, and others.
The way to convince distributors to do this is to demand it and
expect it from them. So when you compare distributors, judge them
partly by how much they give to free software development. Show
distributors they must compete to be the one who gives the most.
To make this approach work, you must insist on numbers that you can
compare, such as, "We will donate ten dollars to the Frobnitz project
for each disk sold." Don't be satisfied with a vague promise, such as
"A portion of the profits are donated," since it doesn't give a basis
for comparison.
Even a precise fraction "of the profits from this disk" is not very
meaningful, since creative accounting and unrelated business decisions
can greatly alter what fraction of the sales price counts as profit.
If the price you pay is $50, ten percent of the profit is probably less
than a dollar; it might be a few cents, or nothing at all.
Some redistributors do development work themselves. This is useful
too; but to keep everyone honest, you need to inquire how much they do,
and what kind. Some kinds of development make much more long-term
difference than others. For example, maintaining a separate version of
a program contributes very little; maintaining the standard version of a
program for the whole community contributes much. Easy new ports
contribute little, since someone else would surely do them; difficult
ports such as adding a new CPU to the GNU C compiler contribute more;
major new features or packages contribute the most.
By establishing the idea that supporting further development is "the
proper thing to do" when distributing free software for a fee, we can
assure a steady flow of resources into making more free software.
Copyright (C) 1994 Free Software Foundation, Inc.
Verbatim copying and redistribution of this section is permitted
without royalty; alteration is not permitted.

File: gcc.info, Node: Look and Feel, Next: Copying, Prev: Funding, Up: Top
Protect Your Freedom--Fight "Look And Feel"
*******************************************
This section is a political message from the League for Programming
Freedom to the users of GNU CC. We have included it here because
the issue of interface copyright is important to the GNU project.
Apple, Lotus, and now CDC have tried to create a new form of legal
monopoly: a copyright on a user interface.
An interface is a kind of language--a set of conventions for
communication between two entities, human or machine. Until a few years
ago, the law seemed clear: interfaces were outside the domain of
copyright, so programmers could program freely and implement whatever
interface the users demanded. Imitating de-facto standard interfaces,
sometimes with improvements, was standard practice in the computer
field. These improvements, if accepted by the users, caught on and
became the norm; in this way, much progress took place.
Computer users, and most software developers, were happy with this
state of affairs. However, large companies such as Apple and Lotus
would prefer a different system--one in which they can own interfaces
and thereby rid themselves of all serious competitors. They hope that
interface copyright will give them, in effect, monopolies on major
classes of software.
Other large companies such as IBM and Digital also favor interface
monopolies, for the same reason: if languages become property, they
expect to own many de-facto standard languages. But Apple and Lotus are
the ones who have actually sued. Apple's lawsuit was defeated, for
reasons only partly related to the general issue of interface copyright.
Lotus won lawsuits against two small companies, which were thus put
out of business. Then Lotus sued Borland; Lotus won in the trial court
(no surprise, since it was the same court that had ruled for Lotus twice
before), but the court of appeals ruled in favor of Borland, which was
assisted by a friend-of-the-court brief from the League for Programming
Freedom.
Lotus appealed the case to the Supreme Court, which heard the case
but was unable to reach a decision. This failure means that the appeals
court decision stands, in one portion of the United States, and may
influence the other appeals courts, but it does not set a nationwide
precedent. The battle is not over, and it is not limited to the United
States.
The battle is extending into other areas of software as well. In
1995 a company that produced a simulator for a CDC computer was shut
down by a copyright lawsuit, in which CDC charged that the simulator
infringed the copyright on the manuals for the computer.
If the monopolists get their way, they will hobble the software
field:
* Gratuitous incompatibilities will burden users. Imagine if each
car manufacturer had to design a different way to start, stop, and
steer a car.
* Users will be "locked in" to whichever interface they learn; then
they will be prisoners of one supplier, who will charge a
monopolistic price.
* Large companies have an unfair advantage wherever lawsuits become
commonplace. Since they can afford to sue, they can intimidate
smaller developers with threats even when they don't really have a
case.
* Interface improvements will come slower, since incremental
evolution through creative partial imitation will no longer occur.
If interface monopolies are accepted, other large companies are
waiting to grab theirs:
* Adobe is expected to claim a monopoly on the interfaces of various
popular application programs, if Lotus ultimately wins the case
against Borland.
* Open Computing magazine reported a Microsoft vice president as
threatening to sue people who imitate the interface of Windows.
Users invest a great deal of time and money in learning to use
computer interfaces. Far more, in fact, than software developers
invest in developing *and even implementing* the interfaces. Whoever
can own an interface, has made its users into captives, and
misappropriated their investment.
To protect our freedom from monopolies like these, a group of
programmers and users have formed a grass-roots political organization,
the League for Programming Freedom.
The purpose of the League is to oppose monopolistic practices such as
interface copyright and software patents. The League calls for a return
to the legal policies of the recent past, in which programmers could
program freely. The League is not concerned with free software as an
issue, and is not affiliated with the Free Software Foundation.
The League's activities include publicizing the issues, as is being
done here, and filing friend-of-the-court briefs on behalf of
defendants sued by monopolists.
The League's membership rolls include Donald Knuth, the foremost
authority on algorithms, John McCarthy, inventor of Lisp, Marvin Minsky,
founder of the MIT Artificial Intelligence lab, Guy L. Steele, Jr.,
author of well-known books on Lisp and C, as well as Richard Stallman,
the developer of GNU CC. Please join and add your name to the list.
Membership dues in the League are $42 per year for programmers, managers
and professionals; $10.50 for students; $21 for others.
Activist members are especially important, but members who have no
time to give are also important. Surveys at major ACM conferences have
indicated a vast majority of attendees agree with the League on both
issues (interface copyrights and software patents). If just ten percent
of the programmers who agree with the League join the League, we will
probably triumph.
To join, or for more information, send electronic mail to the
address `lpf@uunet.uu.net' or write to:
League for Programming Freedom
1 Kendall Square #143
P.O. Box 9171
Cambridge, MA 02139
In addition to joining the League, here are some suggestions from the
League for other things you can do to protect your freedom to write
programs:
* Tell your friends and colleagues about this issue and how it
threatens to ruin the computer industry.
* Mention that you are a League member in your `.signature', and
mention the League's email address for inquiries.
* Ask the companies you consider working for or working with to make
statements against software monopolies, and give preference to
those that do.
* When employers ask you to sign contracts giving them copyright on
your work, insist on a clause saying they will not claim the
copyright covers imitating the interface.
* When employers ask you to sign contracts giving them patent rights,
insist on clauses saying they can use these rights only
defensively. Don't rely on "company policy," since that can
change at any time; don't rely on an individual executive's
private word, since that person may be replaced. Get a commitment
just as binding as the commitment they get from you.
* Write to Congress to explain the importance of these issues.
House Subcommittee on Intellectual Property
2137 Rayburn Bldg
Washington, DC 20515
Senate Subcommittee on Patents, Trademarks and Copyrights
United States Senate
Washington, DC 20510
(These committees have received lots of mail already; let's give
them even more.)
Democracy means nothing if you don't use it. Stand up and be
counted!

534
gcc/gcc.info-27 Normal file
View File

@ -0,0 +1,534 @@
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
input file gcc.texi.
This file documents the use and the internals of the GNU compiler.
Published by the Free Software Foundation 59 Temple Place - Suite 330
Boston, MA 02111-1307 USA
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997 Free
Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License," "Funding for
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License," "Funding for Free Software," and "Protect Your Freedom--Fight
`Look And Feel'", and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.

File: gcc.info, Node: Copying, Next: Contributors, Prev: Look and Feel, Up: Top
GNU GENERAL PUBLIC LICENSE
**************************
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
========
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it in
new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software,
and (2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains a
notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program",
below, refers to any such program or work, and a "work based on
the Program" means either the Program or any derivative work under
copyright law: that is to say, a work containing the Program or a
portion of it, either verbatim or with modifications and/or
translated into another language. (Hereinafter, translation is
included without limitation in the term "modification".) Each
licensee is addressed as "you".
Activities other than copying, distribution and modification are
not covered by this License; they are outside its scope. The act
of running the Program is not restricted, and the output from the
Program is covered only if its contents constitute a work based on
the Program (independent of having been made by running the
Program). Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any
warranty; and give any other recipients of the Program a copy of
this License along with the Program.
You may charge a fee for the physical act of transferring a copy,
and you may at your option offer warranty protection in exchange
for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a. You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b. You must cause any work that you distribute or publish, that
in whole or in part contains or is derived from the Program
or any part thereof, to be licensed as a whole at no charge
to all third parties under the terms of this License.
c. If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display
an announcement including an appropriate copyright notice and
a notice that there is no warranty (or else, saying that you
provide a warranty) and that users may redistribute the
program under these conditions, and telling the user how to
view a copy of this License. (Exception: if the Program
itself is interactive but does not normally print such an
announcement, your work based on the Program is not required
to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the
Program, and can be reasonably considered independent and separate
works in themselves, then this License, and its terms, do not
apply to those sections when you distribute them as separate
works. But when you distribute the same sections as part of a
whole which is a work based on the Program, the distribution of
the whole must be on the terms of this License, whose permissions
for other licensees extend to the entire whole, and thus to each
and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or
contest your rights to work written entirely by you; rather, the
intent is to exercise the right to control the distribution of
derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the
Program with the Program (or with a work based on the Program) on
a volume of a storage or distribution medium does not bring the
other work under the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms
of Sections 1 and 2 above provided that you also do one of the
following:
a. Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of
Sections 1 and 2 above on a medium customarily used for
software interchange; or,
b. Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a
medium customarily used for software interchange; or,
c. Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with
such an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete
source code means all the source code for all modules it contains,
plus any associated interface definition files, plus the scripts
used to control compilation and installation of the executable.
However, as a special exception, the source code distributed need
not include anything that is normally distributed (in either
source or binary form) with the major components (compiler,
kernel, and so on) of the operating system on which the executable
runs, unless that component itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this
License. However, parties who have received copies, or rights,
from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify
or distribute the Program or its derivative works. These actions
are prohibited by law if you do not accept this License.
Therefore, by modifying or distributing the Program (or any work
based on the Program), you indicate your acceptance of this
License to do so, and all its terms and conditions for copying,
distributing or modifying the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program
subject to these terms and conditions. You may not impose any
further restrictions on the recipients' exercise of the rights
granted herein. You are not responsible for enforcing compliance
by third parties to this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent
issues), conditions are imposed on you (whether by court order,
agreement or otherwise) that contradict the conditions of this
License, they do not excuse you from the conditions of this
License. If you cannot distribute so as to satisfy simultaneously
your obligations under this License and any other pertinent
obligations, then as a consequence you may not distribute the
Program at all. For example, if a patent license would not permit
royalty-free redistribution of the Program by all those who
receive copies directly or indirectly through you, then the only
way you could satisfy both it and this License would be to refrain
entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable
under any particular circumstance, the balance of the section is
intended to apply and the section as a whole is intended to apply
in other circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of
any such claims; this section has the sole purpose of protecting
the integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is
willing to distribute software through any other system and a
licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed
to be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces,
the original copyright holder who places the Program under this
License may add an explicit geographical distribution limitation
excluding those countries, so that distribution is permitted only
in or among countries not thus excluded. In such case, this
License incorporates the limitation as if written in the body of
this License.
9. The Free Software Foundation may publish revised and/or new
versions of the General Public License from time to time. Such
new versions will be similar in spirit to the present version, but
may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the
Program specifies a version number of this License which applies
to it and "any later version", you have the option of following
the terms and conditions either of that version or of any later
version published by the Free Software Foundation. If the Program
does not specify a version number of this License, you may choose
any version ever published by the Free Software Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the
author to ask for permission. For software which is copyrighted
by the Free Software Foundation, write to the Free Software
Foundation; we sometimes make exceptions for this. Our decision
will be guided by the two goals of preserving the free status of
all derivatives of our free software and of promoting the sharing
and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE
QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE
LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU
OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
=============================================
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these
terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
Copyright (C) 19YY NAME OF AUTHOR
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
Also add information on how to contact you by electronic and paper
mail.
If the program is interactive, make it output a short notice like
this when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19YY NAME OF AUTHOR
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the
appropriate parts of the General Public License. Of course, the
commands you use may be called something other than `show w' and `show
c'; they could even be mouse-clicks or menu items--whatever suits your
program.
You should also get your employer (if you work as a programmer) or
your school, if any, to sign a "copyright disclaimer" for the program,
if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
SIGNATURE OF TY COON, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your
program into proprietary programs. If your program is a subroutine
library, you may consider it more useful to permit linking proprietary
applications with the library. If this is what you want to do, use the
GNU Library General Public License instead of this License.

File: gcc.info, Node: Contributors, Next: Index, Prev: Copying, Up: Top
Contributors to GNU CC
**********************
In addition to Richard Stallman, several people have written parts
of GNU CC.
* The idea of using RTL and some of the optimization ideas came from
the program PO written at the University of Arizona by Jack
Davidson and Christopher Fraser. See "Register Allocation and
Exhaustive Peephole Optimization", Software Practice and
Experience 14 (9), Sept. 1984, 857-866.
* Paul Rubin wrote most of the preprocessor.
* Leonard Tower wrote parts of the parser, RTL generator, and RTL
definitions, and of the Vax machine description.
* Ted Lemon wrote parts of the RTL reader and printer.
* Jim Wilson implemented loop strength reduction and some other loop
optimizations.
* Nobuyuki Hikichi of Software Research Associates, Tokyo,
contributed the support for the Sony NEWS machine.
* Charles LaBrec contributed the support for the Integrated Solutions
68020 system.
* Michael Tiemann of Cygnus Support wrote the front end for C++, as
well as the support for inline functions and instruction
scheduling. Also the descriptions of the National Semiconductor
32000 series cpu, the SPARC cpu and part of the Motorola 88000 cpu.
* Gerald Baumgartner added the signature extension to the C++
front-end.
* Jan Stein of the Chalmers Computer Society provided support for
Genix, as well as part of the 32000 machine description.
* Randy Smith finished the Sun FPA support.
* Robert Brown implemented the support for Encore 32000 systems.
* David Kashtan of SRI adapted GNU CC to VMS.
* Alex Crain provided changes for the 3b1.
* Greg Satz and Chris Hanson assisted in making GNU CC work on HP-UX
for the 9000 series 300.
* William Schelter did most of the work on the Intel 80386 support.
* Christopher Smith did the port for Convex machines.
* Paul Petersen wrote the machine description for the Alliant FX/8.
* Dario Dariol contributed the four varieties of sample programs
that print a copy of their source.
* Alain Lichnewsky ported GNU CC to the Mips cpu.
* Devon Bowen, Dale Wiles and Kevin Zachmann ported GNU CC to the
Tahoe.
* Jonathan Stone wrote the machine description for the Pyramid
computer.
* Gary Miller ported GNU CC to Charles River Data Systems machines.
* Richard Kenner of the New York University Ultracomputer Research
Laboratory wrote the machine descriptions for the AMD 29000, the
DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the
support for instruction attributes. He also made changes to
better support RISC processors including changes to common
subexpression elimination, strength reduction, function calling
sequence handling, and condition code support, in addition to
generalizing the code for frame pointer elimination.
* Richard Kenner and Michael Tiemann jointly developed reorg.c, the
delay slot scheduler.
* Mike Meissner and Tom Wood of Data General finished the port to the
Motorola 88000.
* Masanobu Yuhara of Fujitsu Laboratories implemented the machine
description for the Tron architecture (specifically, the Gmicro).
* NeXT, Inc. donated the front end that supports the Objective C
language.
* James van Artsdalen wrote the code that makes efficient use of the
Intel 80387 register stack.
* Mike Meissner at the Open Software Foundation finished the port to
the MIPS cpu, including adding ECOFF debug support, and worked on
the Intel port for the Intel 80386 cpu. Later at Cygnus Support,
he worked on the rs6000 and PowerPC ports.
* Ron Guilmette implemented the `protoize' and `unprotoize' tools,
the support for Dwarf symbolic debugging information, and much of
the support for System V Release 4. He has also worked heavily on
the Intel 386 and 860 support.
* Torbjorn Granlund implemented multiply- and divide-by-constant
optimization, improved long long support, and improved leaf
function register allocation.
* Mike Stump implemented the support for Elxsi 64 bit CPU.
* John Wehle added the machine description for the Western Electric
32000 processor used in several 3b series machines (no relation to
the National Semiconductor 32000 processor).
* Holger Teutsch provided the support for the Clipper cpu.
* Kresten Krab Thorup wrote the run time support for the Objective C
language.
* Stephen Moshier contributed the floating point emulator that
assists in cross-compilation and permits support for floating
point numbers wider than 64 bits.
* David Edelsohn contributed the changes to RS/6000 port to make it
support the PowerPC and POWER2 architectures.
* Steve Chamberlain wrote the support for the Hitachi SH processor.
* Peter Schauer wrote the code to allow debugging to work on the
Alpha.
* Oliver M. Kellogg of Deutsche Aerospace contributed the port to the
MIL-STD-1750A.
* Michael K. Gschwind contributed the port to the PDP-11.
* David Reese of Sun Microsystems contributed to the Solaris on
PowerPC port.

2030
gcc/gcc.info-28 Normal file
View File

File diff suppressed because it is too large Load Diff

1198
gcc/gcc.info-3 Normal file
View File

File diff suppressed because it is too large Load Diff

1171
gcc/gcc.info-4 Normal file
View File

File diff suppressed because it is too large Load Diff

836
gcc/gcc.info-5 Normal file
View File

@ -0,0 +1,836 @@
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
input file gcc.texi.
This file documents the use and the internals of the GNU compiler.
Published by the Free Software Foundation 59 Temple Place - Suite 330
Boston, MA 02111-1307 USA
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997 Free
Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License," "Funding for
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License," "Funding for Free Software," and "Protect Your Freedom--Fight
`Look And Feel'", and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.

File: gcc.info, Node: DEC Alpha Options, Next: Clipper Options, Prev: Intel 960 Options, Up: Submodel Options
DEC Alpha Options
-----------------
These `-m' options are defined for the DEC Alpha implementations:
`-mno-soft-float'
`-msoft-float'
Use (do not use) the hardware floating-point instructions for
floating-point operations. When `-msoft-float' is specified,
functions in `libgcc1.c' will be used to perform floating-point
operations. Unless they are replaced by routines that emulate the
floating-point operations, or compiled in such a way as to call
such emulations routines, these routines will issue floating-point
operations. If you are compiling for an Alpha without
floating-point operations, you must ensure that the library is
built so as not to call them.
Note that Alpha implementations without floating-point operations
are required to have floating-point registers.
`-mfp-reg'
`-mno-fp-regs'
Generate code that uses (does not use) the floating-point register
set. `-mno-fp-regs' implies `-msoft-float'. If the floating-point
register set is not used, floating point operands are passed in
integer registers as if they were integers and floating-point
results are passed in $0 instead of $f0. This is a non-standard
calling sequence, so any function with a floating-point argument
or return value called by code compiled with `-mno-fp-regs' must
also be compiled with that option.
A typical use of this option is building a kernel that does not
use, and hence need not save and restore, any floating-point
registers.
`-mieee'
The Alpha architecture implements floating-point hardware
optimized for maximum performance. It is mostly compliant with
the IEEE floating point standard. However, for full compliance,
software assistance is required. This option generates code fully
IEEE compliant code *except* that the INEXACT FLAG is not
maintained (see below). If this option is turned on, the CPP
macro `_IEEE_FP' is defined during compilation. The option is a
shorthand for: `-D_IEEE_FP -mfp-trap-mode=su -mtrap-precision=i
-mieee-conformant'. The resulting code is less efficient but is
able to correctly support denormalized numbers and exceptional
IEEE values such as not-a-number and plus/minus infinity. Other
Alpha compilers call this option `-ieee_with_no_inexact'.
`-mieee-with-inexact'
This is like `-mieee' except the generated code also maintains the
IEEE INEXACT FLAG. Turning on this option causes the generated
code to implement fully-compliant IEEE math. The option is a
shorthand for `-D_IEEE_FP -D_IEEE_FP_INEXACT' plus the three
following: `-mieee-conformant', `-mfp-trap-mode=sui', and
`-mtrap-precision=i'. On some Alpha implementations the resulting
code may execute significantly slower than the code generated by
default. Since there is very little code that depends on the
INEXACT FLAG, you should normally not specify this option. Other
Alpha compilers call this option `-ieee_with_inexact'.
`-mfp-trap-mode=TRAP MODE'
This option controls what floating-point related traps are enabled.
Other Alpha compilers call this option `-fptm 'TRAP MODE. The
trap mode can be set to one of four values:
`n'
This is the default (normal) setting. The only traps that
are enabled are the ones that cannot be disabled in software
(e.g., division by zero trap).
`u'
In addition to the traps enabled by `n', underflow traps are
enabled as well.
`su'
Like `su', but the instructions are marked to be safe for
software completion (see Alpha architecture manual for
details).
`sui'
Like `su', but inexact traps are enabled as well.
`-mfp-rounding-mode=ROUNDING MODE'
Selects the IEEE rounding mode. Other Alpha compilers call this
option `-fprm 'ROUNDING MODE. The ROUNDING MODE can be one of:
`n'
Normal IEEE rounding mode. Floating point numbers are
rounded towards the nearest machine number or towards the
even machine number in case of a tie.
`m'
Round towards minus infinity.
`c'
Chopped rounding mode. Floating point numbers are rounded
towards zero.
`d'
Dynamic rounding mode. A field in the floating point control
register (FPCR, see Alpha architecture reference manual)
controls the rounding mode in effect. The C library
initializes this register for rounding towards plus infinity.
Thus, unless your program modifies the FPCR, `d' corresponds
to round towards plus infinity.
`-mtrap-precision=TRAP PRECISION'
In the Alpha architecture, floating point traps are imprecise.
This means without software assistance it is impossible to recover
from a floating trap and program execution normally needs to be
terminated. GNU CC can generate code that can assist operating
system trap handlers in determining the exact location that caused
a floating point trap. Depending on the requirements of an
application, different levels of precisions can be selected:
`p'
Program precision. This option is the default and means a
trap handler can only identify which program caused a
floating point exception.
`f'
Function precision. The trap handler can determine the
function that caused a floating point exception.
`i'
Instruction precision. The trap handler can determine the
exact instruction that caused a floating point exception.
Other Alpha compilers provide the equivalent options called
`-scope_safe' and `-resumption_safe'.
`-mieee-conformant'
This option marks the generated code as IEEE conformant. You must
not use this option unless you also specify `-mtrap-precision=i'
and either `-mfp-trap-mode=su' or `-mfp-trap-mode=sui'. Its only
effect is to emit the line `.eflag 48' in the function prologue of
the generated assembly file. Under DEC Unix, this has the effect
that IEEE-conformant math library routines will be linked in.
`-mbuild-constants'
Normally GNU CC examines a 32- or 64-bit integer constant to see
if it can construct it from smaller constants in two or three
instructions. If it cannot, it will output the constant as a
literal and generate code to load it from the data segement at
runtime.
Use this option to require GNU CC to construct *all* integer
constants using code, even if it takes more instructions (the
maximum is six).
You would typically use this option to build a shared library
dynamic loader. Itself a shared library, it must relocate itself
in memory before it can find the variables and constants in its
own data segment.

File: gcc.info, Node: Clipper Options, Next: H8/300 Options, Prev: DEC Alpha Options, Up: Submodel Options
Clipper Options
---------------
These `-m' options are defined for the Clipper implementations:
`-mc300'
Produce code for a C300 Clipper processor. This is the default.
`-mc400'
Produce code for a C400 Clipper processor i.e. use floating point
registers f8..f15.

File: gcc.info, Node: H8/300 Options, Next: SH Options, Prev: Clipper Options, Up: Submodel Options
H8/300 Options
--------------
These `-m' options are defined for the H8/300 implementations:
`-mrelax'
Shorten some address references at link time, when possible; uses
the linker option `-relax'. *Note `ld' and the H8/300:
(ld.info)H8/300, for a fuller description.
`-mh'
Generate code for the H8/300H.
`-ms'
Generate code for the H8/S.
`-mint32'
Make `int' data 32 bits by default.
`-malign-300'
On the h8/300h, use the same alignment rules as for the h8/300.
The default for the h8/300h is to align longs and floats on 4 byte
boundaries. `-malign-300' causes them to be aligned on 2 byte
boundaries. This option has no effect on the h8/300.

File: gcc.info, Node: SH Options, Next: System V Options, Prev: H8/300 Options, Up: Submodel Options
SH Options
----------
These `-m' options are defined for the SH implementations:
`-m1'
Generate code for the SH1.
`-m2'
Generate code for the SH2.
`-m3'
Generate code for the SH3.
`-m3e'
Generate code for the SH3e.
`-mb'
Compile code for the processor in big endian mode.
`-ml'
Compile code for the processor in little endian mode.
`-mrelax'
Shorten some address references at link time, when possible; uses
the linker option `-relax'.

File: gcc.info, Node: System V Options, Next: V850 Options, Prev: SH Options, Up: Submodel Options
Options for System V
--------------------
These additional options are available on System V Release 4 for
compatibility with other compilers on those systems:
`-G'
Create a shared object. It is recommended that `-symbolic' or
`-shared' be used instead.
`-Qy'
Identify the versions of each tool used by the compiler, in a
`.ident' assembler directive in the output.
`-Qn'
Refrain from adding `.ident' directives to the output file (this is
the default).
`-YP,DIRS'
Search the directories DIRS, and no others, for libraries
specified with `-l'.
`-Ym,DIR'
Look in the directory DIR to find the M4 preprocessor. The
assembler uses this option.

File: gcc.info, Node: V850 Options, Prev: System V Options, Up: Submodel Options
V850 Options
------------
These `-m' options are defined for V850 implementations:
`-mlong-calls'
`-mno-long-calls'
Treat all calls as being far away (near). If calls are assumed to
be far away, the compiler will always load the functions address
up into a register, and call indirect through the pointer.
`-mno-ep'
`-mep'
Do not optimize (do optimize) basic blocks that use the same index
pointer 4 or more times to copy pointer into the `ep' register, and
use the shorter `sld' and `sst' instructions. The `-mep' option
is on by default if you optimize.
`-mno-prolog-function'
`-mprolog-function'
Do not use (do use) external functions to save and restore
registers at the prolog and epilog of a function. The external
functions are slower, but use less code space if more than one
function saves the same number of registers. The
`-mprolog-function' option is on by default if you optimize.
`-mspace'
Try to make the code as small as possible. At present, this just
turns on the `-mep' and `-mprolog-function' options.
`-mtda=N'
Put static or global variables whose size is N bytes or less into
the tiny data area that register `ep' points to. The tiny data
area can hold up to 256 bytes in total (128 bytes for byte
references).
`-msda=N'
Put static or global variables whose size is N bytes or less into
the small data area that register `gp' points to. The small data
area can hold up to 64 kilobytes.
`-mzda=N'
Put static or global variables whose size is N bytes or less into
the first 32 kilobytes of memory.
`-mv850'
Specify that the target processor is the V850.
`-mbig-switch'
Generate code suitable for big switch tables. Use this option
only if the assembler/linker complain about out of range branches
within a switch table.

File: gcc.info, Node: Code Gen Options, Next: Environment Variables, Prev: Submodel Options, Up: Invoking GCC
Options for Code Generation Conventions
=======================================
These machine-independent options control the interface conventions
used in code generation.
Most of them have both positive and negative forms; the negative form
of `-ffoo' would be `-fno-foo'. In the table below, only one of the
forms is listed--the one which is not the default. You can figure out
the other form by either removing `no-' or adding it.
`-fpcc-struct-return'
Return "short" `struct' and `union' values in memory like longer
ones, rather than in registers. This convention is less
efficient, but it has the advantage of allowing intercallability
between GNU CC-compiled files and files compiled with other
compilers.
The precise convention for returning structures in memory depends
on the target configuration macros.
Short structures and unions are those whose size and alignment
match that of some integer type.
`-freg-struct-return'
Use the convention that `struct' and `union' values are returned
in registers when possible. This is more efficient for small
structures than `-fpcc-struct-return'.
If you specify neither `-fpcc-struct-return' nor its contrary
`-freg-struct-return', GNU CC defaults to whichever convention is
standard for the target. If there is no standard convention, GNU
CC defaults to `-fpcc-struct-return', except on targets where GNU
CC is the principal compiler. In those cases, we can choose the
standard, and we chose the more efficient register return
alternative.
`-fshort-enums'
Allocate to an `enum' type only as many bytes as it needs for the
declared range of possible values. Specifically, the `enum' type
will be equivalent to the smallest integer type which has enough
room.
`-fshort-double'
Use the same size for `double' as for `float'.
`-fshared-data'
Requests that the data and non-`const' variables of this
compilation be shared data rather than private data. The
distinction makes sense only on certain operating systems, where
shared data is shared between processes running the same program,
while private data exists in one copy per process.
`-fno-common'
Allocate even uninitialized global variables in the bss section of
the object file, rather than generating them as common blocks.
This has the effect that if the same variable is declared (without
`extern') in two different compilations, you will get an error
when you link them. The only reason this might be useful is if
you wish to verify that the program will work on other systems
which always work this way.
`-fno-ident'
Ignore the `#ident' directive.
`-fno-gnu-linker'
Do not output global initializations (such as C++ constructors and
destructors) in the form used by the GNU linker (on systems where
the GNU linker is the standard method of handling them). Use this
option when you want to use a non-GNU linker, which also requires
using the `collect2' program to make sure the system linker
includes constructors and destructors. (`collect2' is included in
the GNU CC distribution.) For systems which *must* use
`collect2', the compiler driver `gcc' is configured to do this
automatically.
`-finhibit-size-directive'
Don't output a `.size' assembler directive, or anything else that
would cause trouble if the function is split in the middle, and the
two halves are placed at locations far apart in memory. This
option is used when compiling `crtstuff.c'; you should not need to
use it for anything else.
`-fverbose-asm'
Put extra commentary information in the generated assembly code to
make it more readable. This option is generally only of use to
those who actually need to read the generated assembly code
(perhaps while debugging the compiler itself).
`-fverbose-asm' is the default. `-fno-verbose-asm' causes the
extra information to be omitted and is useful when comparing two
assembler files.
`-fvolatile'
Consider all memory references through pointers to be volatile.
`-fvolatile-global'
Consider all memory references to extern and global data items to
be volatile.
`-fpic'
Generate position-independent code (PIC) suitable for use in a
shared library, if supported for the target machine. Such code
accesses all constant addresses through a global offset table
(GOT). The dynamic loader resolves the GOT entries when the
program starts (the dynamic loader is not part of GNU CC; it is
part of the operating system). If the GOT size for the linked
executable exceeds a machine-specific maximum size, you get an
error message from the linker indicating that `-fpic' does not
work; in that case, recompile with `-fPIC' instead. (These
maximums are 16k on the m88k, 8k on the Sparc, and 32k on the m68k
and RS/6000. The 386 has no such limit.)
Position-independent code requires special support, and therefore
works only on certain machines. For the 386, GNU CC supports PIC
for System V but not for the Sun 386i. Code generated for the IBM
RS/6000 is always position-independent.
`-fPIC'
If supported for the target machine, emit position-independent
code, suitable for dynamic linking and avoiding any limit on the
size of the global offset table. This option makes a difference
on the m68k, m88k, and the Sparc.
Position-independent code requires special support, and therefore
works only on certain machines.
`-ffixed-REG'
Treat the register named REG as a fixed register; generated code
should never refer to it (except perhaps as a stack pointer, frame
pointer or in some other fixed role).
REG must be the name of a register. The register names accepted
are machine-specific and are defined in the `REGISTER_NAMES' macro
in the machine description macro file.
This flag does not have a negative form, because it specifies a
three-way choice.
`-fcall-used-REG'
Treat the register named REG as an allocatable register that is
clobbered by function calls. It may be allocated for temporaries
or variables that do not live across a call. Functions compiled
this way will not save and restore the register REG.
Use of this flag for a register that has a fixed pervasive role in
the machine's execution model, such as the stack pointer or frame
pointer, will produce disastrous results.
This flag does not have a negative form, because it specifies a
three-way choice.
`-fcall-saved-REG'
Treat the register named REG as an allocatable register saved by
functions. It may be allocated even for temporaries or variables
that live across a call. Functions compiled this way will save
and restore the register REG if they use it.
Use of this flag for a register that has a fixed pervasive role in
the machine's execution model, such as the stack pointer or frame
pointer, will produce disastrous results.
A different sort of disaster will result from the use of this flag
for a register in which function values may be returned.
This flag does not have a negative form, because it specifies a
three-way choice.
`-fpack-struct'
Pack all structure members together without holes. Usually you
would not want to use this option, since it makes the code
suboptimal, and the offsets of structure members won't agree with
system libraries.
`-fcheck-memory-usage'
Generate extra code to check each memory access. GNU CC will
generate code that is suitable for a detector of bad memory
accesses such as `Checker'. If you specify this option, you can
not use the `asm' or `__asm__' keywords.
You must also specify this option when you compile functions you
call that have side effects. If you do not, you may get erronous
messages from the detector. Normally, you should compile all
your code with this option. If you use functions from a library
that have side-effects (such as `read'), you may not be able to
recompile the library and specify this option. In that case, you
can enable the `-fprefix-function-name' option, which requests GNU
CC to encapsulate your code and make other functions look as if
they were compiled with `-fcheck-memory-usage'. This is done by
calling "stubs", which are provided by the detector. If you
cannot find or build stubs for every function you call, you may
have to specify `-fcheck-memory-usage' without
`-fprefix-function-name'.
`-fprefix-function-name'
Request GNU CC to add a prefix to the symbols generated for
function names. GNU CC adds a prefix to the names of functions
defined as well as functions called. Code compiled with this
option and code compiled without the option can't be linked
together, unless or stubs are used.
If you compile the following code with `-fprefix-function-name'
extern void bar (int);
void
foo (int a)
{
return bar (a + 5);
}
GNU CC will compile the code as if it was written:
extern void prefix_bar (int);
void
prefix_foo (int a)
{
return prefix_bar (a + 5);
}
This option is designed to be used with `-fcheck-memory-usage'.
`-fstack-check'
Generate code to verify that you do not go beyond the boundary of
the stack. You should specify this flag if you are running in an
environment with multiple threads, but only rarely need to specify
it in a single-threaded environment since stack overflow is
automatically detected on nearly all systems if there is only one
stack.
`+e0'
`+e1'
Control whether virtual function definitions in classes are used to
generate code, or only to define interfaces for their callers.
(C++ only).
These options are provided for compatibility with `cfront' 1.x
usage; the recommended alternative GNU C++ usage is in flux.
*Note Declarations and Definitions in One Header: C++ Interface.
With `+e0', virtual function definitions in classes are declared
`extern'; the declaration is used only as an interface
specification, not to generate code for the virtual functions (in
this compilation).
With `+e1', G++ actually generates the code implementing virtual
functions defined in the code, and makes them publicly visible.

File: gcc.info, Node: Environment Variables, Next: Running Protoize, Prev: Code Gen Options, Up: Invoking GCC
Environment Variables Affecting GNU CC
======================================
This section describes several environment variables that affect how
GNU CC operates. They work by specifying directories or prefixes to use
when searching for various kinds of files.
Note that you can also specify places to search using options such as
`-B', `-I' and `-L' (*note Directory Options::.). These take
precedence over places specified using environment variables, which in
turn take precedence over those specified by the configuration of GNU
CC. *Note Driver::.
`TMPDIR'
If `TMPDIR' is set, it specifies the directory to use for temporary
files. GNU CC uses temporary files to hold the output of one
stage of compilation which is to be used as input to the next
stage: for example, the output of the preprocessor, which is the
input to the compiler proper.
`GCC_EXEC_PREFIX'
If `GCC_EXEC_PREFIX' is set, it specifies a prefix to use in the
names of the subprograms executed by the compiler. No slash is
added when this prefix is combined with the name of a subprogram,
but you can specify a prefix that ends with a slash if you wish.
If GNU CC cannot find the subprogram using the specified prefix, it
tries looking in the usual places for the subprogram.
The default value of `GCC_EXEC_PREFIX' is `PREFIX/lib/gcc-lib/'
where PREFIX is the value of `prefix' when you ran the `configure'
script.
Other prefixes specified with `-B' take precedence over this
prefix.
This prefix is also used for finding files such as `crt0.o' that
are used for linking.
In addition, the prefix is used in an unusual way in finding the
directories to search for header files. For each of the standard
directories whose name normally begins with
`/usr/local/lib/gcc-lib' (more precisely, with the value of
`GCC_INCLUDE_DIR'), GNU CC tries replacing that beginning with the
specified prefix to produce an alternate directory name. Thus,
with `-Bfoo/', GNU CC will search `foo/bar' where it would
normally search `/usr/local/lib/bar'. These alternate directories
are searched first; the standard directories come next.
`COMPILER_PATH'
The value of `COMPILER_PATH' is a colon-separated list of
directories, much like `PATH'. GNU CC tries the directories thus
specified when searching for subprograms, if it can't find the
subprograms using `GCC_EXEC_PREFIX'.
`LIBRARY_PATH'
The value of `LIBRARY_PATH' is a colon-separated list of
directories, much like `PATH'. When configured as a native
compiler, GNU CC tries the directories thus specified when
searching for special linker files, if it can't find them using
`GCC_EXEC_PREFIX'. Linking using GNU CC also uses these
directories when searching for ordinary libraries for the `-l'
option (but directories specified with `-L' come first).
`C_INCLUDE_PATH'
`CPLUS_INCLUDE_PATH'
`OBJC_INCLUDE_PATH'
These environment variables pertain to particular languages. Each
variable's value is a colon-separated list of directories, much
like `PATH'. When GNU CC searches for header files, it tries the
directories listed in the variable for the language you are using,
after the directories specified with `-I' but before the standard
header file directories.
`DEPENDENCIES_OUTPUT'
If this variable is set, its value specifies how to output
dependencies for Make based on the header files processed by the
compiler. This output looks much like the output from the `-M'
option (*note Preprocessor Options::.), but it goes to a separate
file, and is in addition to the usual results of compilation.
The value of `DEPENDENCIES_OUTPUT' can be just a file name, in
which case the Make rules are written to that file, guessing the
target name from the source file name. Or the value can have the
form `FILE TARGET', in which case the rules are written to file
FILE using TARGET as the target name.

File: gcc.info, Node: Running Protoize, Prev: Environment Variables, Up: Invoking GCC
Running Protoize
================
The program `protoize' is an optional part of GNU C. You can use it
to add prototypes to a program, thus converting the program to ANSI C
in one respect. The companion program `unprotoize' does the reverse:
it removes argument types from any prototypes that are found.
When you run these programs, you must specify a set of source files
as command line arguments. The conversion programs start out by
compiling these files to see what functions they define. The
information gathered about a file FOO is saved in a file named `FOO.X'.
After scanning comes actual conversion. The specified files are all
eligible to be converted; any files they include (whether sources or
just headers) are eligible as well.
But not all the eligible files are converted. By default,
`protoize' and `unprotoize' convert only source and header files in the
current directory. You can specify additional directories whose files
should be converted with the `-d DIRECTORY' option. You can also
specify particular files to exclude with the `-x FILE' option. A file
is converted if it is eligible, its directory name matches one of the
specified directory names, and its name within the directory has not
been excluded.
Basic conversion with `protoize' consists of rewriting most function
definitions and function declarations to specify the types of the
arguments. The only ones not rewritten are those for varargs functions.
`protoize' optionally inserts prototype declarations at the
beginning of the source file, to make them available for any calls that
precede the function's definition. Or it can insert prototype
declarations with block scope in the blocks where undeclared functions
are called.
Basic conversion with `unprotoize' consists of rewriting most
function declarations to remove any argument types, and rewriting
function definitions to the old-style pre-ANSI form.
Both conversion programs print a warning for any function
declaration or definition that they can't convert. You can suppress
these warnings with `-q'.
The output from `protoize' or `unprotoize' replaces the original
source file. The original file is renamed to a name ending with
`.save'. If the `.save' file already exists, then the source file is
simply discarded.
`protoize' and `unprotoize' both depend on GNU CC itself to scan the
program and collect information about the functions it uses. So
neither of these programs will work until GNU CC is installed.
Here is a table of the options you can use with `protoize' and
`unprotoize'. Each option works with both programs unless otherwise
stated.
`-B DIRECTORY'
Look for the file `SYSCALLS.c.X' in DIRECTORY, instead of the
usual directory (normally `/usr/local/lib'). This file contains
prototype information about standard system functions. This option
applies only to `protoize'.
`-c COMPILATION-OPTIONS'
Use COMPILATION-OPTIONS as the options when running `gcc' to
produce the `.X' files. The special option `-aux-info' is always
passed in addition, to tell `gcc' to write a `.X' file.
Note that the compilation options must be given as a single
argument to `protoize' or `unprotoize'. If you want to specify
several `gcc' options, you must quote the entire set of
compilation options to make them a single word in the shell.
There are certain `gcc' arguments that you cannot use, because they
would produce the wrong kind of output. These include `-g', `-O',
`-c', `-S', and `-o' If you include these in the
COMPILATION-OPTIONS, they are ignored.
`-C'
Rename files to end in `.C' instead of `.c'. This is convenient
if you are converting a C program to C++. This option applies
only to `protoize'.
`-g'
Add explicit global declarations. This means inserting explicit
declarations at the beginning of each source file for each function
that is called in the file and was not declared. These
declarations precede the first function definition that contains a
call to an undeclared function. This option applies only to
`protoize'.
`-i STRING'
Indent old-style parameter declarations with the string STRING.
This option applies only to `protoize'.
`unprotoize' converts prototyped function definitions to old-style
function definitions, where the arguments are declared between the
argument list and the initial `{'. By default, `unprotoize' uses
five spaces as the indentation. If you want to indent with just
one space instead, use `-i " "'.
`-k'
Keep the `.X' files. Normally, they are deleted after conversion
is finished.
`-l'
Add explicit local declarations. `protoize' with `-l' inserts a
prototype declaration for each function in each block which calls
the function without any declaration. This option applies only to
`protoize'.
`-n'
Make no real changes. This mode just prints information about the
conversions that would have been done without `-n'.
`-N'
Make no `.save' files. The original files are simply deleted.
Use this option with caution.
`-p PROGRAM'
Use the program PROGRAM as the compiler. Normally, the name `gcc'
is used.
`-q'
Work quietly. Most warnings are suppressed.
`-v'
Print the version number, just like `-v' for `gcc'.
If you need special compiler options to compile one of your program's
source files, then you should generate that file's `.X' file specially,
by running `gcc' on that source file with the appropriate options and
the option `-aux-info'. Then run `protoize' on the entire set of
files. `protoize' will use the existing `.X' file because it is newer
than the source file. For example:
gcc -Dfoo=bar file1.c -aux-info
protoize *.c
You need to include the special files along with the rest in the
`protoize' command, even though their `.X' files already exist, because
otherwise they won't get converted.
*Note Protoize Caveats::, for more information on how to use
`protoize' successfully.

537
gcc/gcc.info-6 Normal file
View File

@ -0,0 +1,537 @@
This is Info file gcc.info, produced by Makeinfo version 1.68 from the
input file gcc.texi.
This file documents the use and the internals of the GNU compiler.
Published by the Free Software Foundation 59 Temple Place - Suite 330
Boston, MA 02111-1307 USA
Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997 Free
Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License," "Funding for
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License," "Funding for Free Software," and "Protect Your Freedom--Fight
`Look And Feel'", and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.

File: gcc.info, Node: Installation, Next: C Extensions, Prev: Invoking GCC, Up: Top
Installing GNU CC
*****************
* Menu:
* Configurations:: Configurations Supported by GNU CC.
* Other Dir:: Compiling in a separate directory (not where the source is).
* Cross-Compiler:: Building and installing a cross-compiler.
* Sun Install:: See below for installation on the Sun.
* VMS Install:: See below for installation on VMS.
* Collect2:: How `collect2' works; how it finds `ld'.
* Header Dirs:: Understanding the standard header file directories.
Here is the procedure for installing GNU CC on a Unix system. See
*Note VMS Install::, for VMS systems. In this section we assume you
compile in the same directory that contains the source files; see *Note
Other Dir::, to find out how to compile in a separate directory on Unix
systems.
You cannot install GNU C by itself on MSDOS; it will not compile
under any MSDOS compiler except itself. You need to get the complete
compilation package DJGPP, which includes binaries as well as sources,
and includes all the necessary compilation tools and libraries.
1. If you have built GNU CC previously in the same directory for a
different target machine, do `make distclean' to delete all files
that might be invalid. One of the files this deletes is
`Makefile'; if `make distclean' complains that `Makefile' does not
exist, it probably means that the directory is already suitably
clean.
2. On a System V release 4 system, make sure `/usr/bin' precedes
`/usr/ucb' in `PATH'. The `cc' command in `/usr/ucb' uses
libraries which have bugs.
3. Specify the host, build and target machine configurations. You do
this by running the file `configure'.
The "build" machine is the system which you are using, the "host"
machine is the system where you want to run the resulting compiler
(normally the build machine), and the "target" machine is the
system for which you want the compiler to generate code.
If you are building a compiler to produce code for the machine it
runs on (a native compiler), you normally do not need to specify
any operands to `configure'; it will try to guess the type of
machine you are on and use that as the build, host and target
machines. So you don't need to specify a configuration when
building a native compiler unless `configure' cannot figure out
what your configuration is or guesses wrong.
In those cases, specify the build machine's "configuration name"
with the `--build' option; the host and target will default to be
the same as the build machine. (If you are building a
cross-compiler, see *Note Cross-Compiler::.)
Here is an example:
./configure --build=sparc-sun-sunos4.1
A configuration name may be canonical or it may be more or less
abbreviated.
A canonical configuration name has three parts, separated by
dashes. It looks like this: `CPU-COMPANY-SYSTEM'. (The three
parts may themselves contain dashes; `configure' can figure out
which dashes serve which purpose.) For example,
`m68k-sun-sunos4.1' specifies a Sun 3.
You can also replace parts of the configuration by nicknames or
aliases. For example, `sun3' stands for `m68k-sun', so
`sun3-sunos4.1' is another way to specify a Sun 3. You can also
use simply `sun3-sunos', since the version of SunOS is assumed by
default to be version 4.
You can specify a version number after any of the system types,
and some of the CPU types. In most cases, the version is
irrelevant, and will be ignored. So you might as well specify the
version if you know it.
See *Note Configurations::, for a list of supported configuration
names and notes on many of the configurations. You should check
the notes in that section before proceeding any further with the
installation of GNU CC.
There are four additional options you can specify independently to
describe variant hardware and software configurations. These are
`--with-gnu-as', `--with-gnu-ld', `--with-stabs' and `--nfp'.
`--with-gnu-as'
If you will use GNU CC with the GNU assembler (GAS), you
should declare this by using the `--with-gnu-as' option when
you run `configure'.
Using this option does not install GAS. It only modifies the
output of GNU CC to work with GAS. Building and installing
GAS is up to you.
Conversely, if you *do not* wish to use GAS and do not specify
`--with-gnu-as' when building GNU CC, it is up to you to make
sure that GAS is not installed. GNU CC searches for a
program named `as' in various directories; if the program it
finds is GAS, then it runs GAS. If you are not sure where
GNU CC finds the assembler it is using, try specifying `-v'
when you run it.
The systems where it makes a difference whether you use GAS
are
`hppa1.0-ANY-ANY', `hppa1.1-ANY-ANY', `i386-ANY-sysv',
`i386-ANY-isc',
`i860-ANY-bsd', `m68k-bull-sysv',
`m68k-hp-hpux', `m68k-sony-bsd',
`m68k-altos-sysv', `m68000-hp-hpux',
`m68000-att-sysv', `ANY-lynx-lynxos', and `mips-ANY'). On
any other system, `--with-gnu-as' has no effect.
On the systems listed above (except for the HP-PA, for ISC on
the 386, and for `mips-sgi-irix5.*'), if you use GAS, you
should also use the GNU linker (and specify `--with-gnu-ld').
`--with-gnu-ld'
Specify the option `--with-gnu-ld' if you plan to use the GNU
linker with GNU CC.
This option does not cause the GNU linker to be installed; it
just modifies the behavior of GNU CC to work with the GNU
linker. Specifically, it inhibits the installation of
`collect2', a program which otherwise serves as a front-end
for the system's linker on most configurations.
`--with-stabs'
On MIPS based systems and on Alphas, you must specify whether
you want GNU CC to create the normal ECOFF debugging format,
or to use BSD-style stabs passed through the ECOFF symbol
table. The normal ECOFF debug format cannot fully handle
languages other than C. BSD stabs format can handle other
languages, but it only works with the GNU debugger GDB.
Normally, GNU CC uses the ECOFF debugging format by default;
if you prefer BSD stabs, specify `--with-stabs' when you
configure GNU CC.
No matter which default you choose when you configure GNU CC,
the user can use the `-gcoff' and `-gstabs+' options to
specify explicitly the debug format for a particular
compilation.
`--with-stabs' is meaningful on the ISC system on the 386,
also, if `--with-gas' is used. It selects use of stabs
debugging information embedded in COFF output. This kind of
debugging information supports C++ well; ordinary COFF
debugging information does not.
`--with-stabs' is also meaningful on 386 systems running
SVR4. It selects use of stabs debugging information embedded
in ELF output. The C++ compiler currently (2.6.0) does not
support the DWARF debugging information normally used on 386
SVR4 platforms; stabs provide a workable alternative. This
requires gas and gdb, as the normal SVR4 tools can not
generate or interpret stabs.
`--nfp'
On certain systems, you must specify whether the machine has
a floating point unit. These systems include
`m68k-sun-sunosN' and `m68k-isi-bsd'. On any other system,
`--nfp' currently has no effect, though perhaps there are
other systems where it could usefully make a difference.
`--enable-objcthreads=TYPE'
Certain systems, notably Linux-based GNU systems, can't be
relied on to supply a threads facility for the Objective C
runtime and so will default to single-threaded runtime. They
may, however, have a library threads implementation
available, in which case threads can be enabled with this
option by supplying a suitable TYPE, probably `posix'. The
possibilities for TYPE are `single', `posix', `win32',
`solaris', `irix' and `mach'.
The `configure' script searches subdirectories of the source
directory for other compilers that are to be integrated into GNU
CC. The GNU compiler for C++, called G++ is in a subdirectory
named `cp'. `configure' inserts rules into `Makefile' to build
all of those compilers.
Here we spell out what files will be set up by `configure'.
Normally you need not be concerned with these files.
* A file named `config.h' is created that contains a `#include'
of the top-level config file for the machine you will run the
compiler on (*note Config::.). This file is responsible for
defining information about the host machine. It includes
`tm.h'.
The top-level config file is located in the subdirectory
`config'. Its name is always `xm-SOMETHING.h'; usually
`xm-MACHINE.h', but there are some exceptions.
If your system does not support symbolic links, you might
want to set up `config.h' to contain a `#include' command
which refers to the appropriate file.
* A file named `tconfig.h' is created which includes the
top-level config file for your target machine. This is used
for compiling certain programs to run on that machine.
* A file named `tm.h' is created which includes the
machine-description macro file for your target machine. It
should be in the subdirectory `config' and its name is often
`MACHINE.h'.
* The command file `configure' also constructs the file
`Makefile' by adding some text to the template file
`Makefile.in'. The additional text comes from files in the
`config' directory, named `t-TARGET' and `x-HOST'. If these
files do not exist, it means nothing needs to be added for a
given target or host.
4. The standard directory for installing GNU CC is `/usr/local/lib'.
If you want to install its files somewhere else, specify
`--prefix=DIR' when you run `configure'. Here DIR is a directory
name to use instead of `/usr/local' for all purposes with one
exception: the directory `/usr/local/include' is searched for
header files no matter where you install the compiler. To override
this name, use the `--local-prefix' option below.
5. Specify `--local-prefix=DIR' if you want the compiler to search
directory `DIR/include' for locally installed header files
*instead* of `/usr/local/include'.
You should specify `--local-prefix' *only* if your site has a
different convention (not `/usr/local') for where to put
site-specific files.
The default value for `--local-prefix' is `/usr/local' regardless
of the value of `--prefix'. Specifying `--prefix' has no effect
on which directory GNU CC searches for local header files. This
may seem counterintuitive, but actually it is logical.
The purpose of `--prefix' is to specify where to *install GNU CC*.
The local header files in `/usr/local/include'--if you put any in
that directory--are not part of GNU CC. They are part of other
programs--perhaps many others. (GNU CC installs its own header
files in another directory which is based on the `--prefix' value.)
*Do not* specify `/usr' as the `--local-prefix'! The directory
you use for `--local-prefix' *must not* contain any of the
system's standard header files. If it did contain them, certain
programs would be miscompiled (including GNU Emacs, on certain
targets), because this would override and nullify the header file
corrections made by the `fixincludes' script.
Indications are that people who use this option use it based on
mistaken ideas of what it is for. People use it as if it specified
where to install part of GNU CC. Perhaps they make this assumption
because installing GNU CC creates the directory.
6. Make sure the Bison parser generator is installed. (This is
unnecessary if the Bison output files `c-parse.c' and `cexp.c' are
more recent than `c-parse.y' and `cexp.y' and you do not plan to
change the `.y' files.)
Bison versions older than Sept 8, 1988 will produce incorrect
output for `c-parse.c'.
7. If you have chosen a configuration for GNU CC which requires other
GNU tools (such as GAS or the GNU linker) instead of the standard
system tools, install the required tools in the build directory
under the names `as', `ld' or whatever is appropriate. This will
enable the compiler to find the proper tools for compilation of
the program `enquire'.
Alternatively, you can do subsequent compilation using a value of
the `PATH' environment variable such that the necessary GNU tools
come before the standard system tools.
8. Build the compiler. Just type `make LANGUAGES=c' in the compiler
directory.
`LANGUAGES=c' specifies that only the C compiler should be
compiled. The makefile normally builds compilers for all the
supported languages; currently, C, C++ and Objective C. However,
C is the only language that is sure to work when you build with
other non-GNU C compilers. In addition, building anything but C
at this stage is a waste of time.
In general, you can specify the languages to build by typing the
argument `LANGUAGES="LIST"', where LIST is one or more words from
the list `c', `c++', and `objective-c'. If you have any
additional GNU compilers as subdirectories of the GNU CC source
directory, you may also specify their names in this list.
Ignore any warnings you may see about "statement not reached" in
`insn-emit.c'; they are normal. Also, warnings about "unknown
escape sequence" are normal in `genopinit.c' and perhaps some
other files. Likewise, you should ignore warnings about "constant
is so large that it is unsigned" in `insn-emit.c' and
`insn-recog.c' and a warning about a comparison always being zero
in `enquire.o'. Any other compilation errors may represent bugs in
the port to your machine or operating system, and should be
investigated and reported (*note Bugs::.).
Some commercial compilers fail to compile GNU CC because they have
bugs or limitations. For example, the Microsoft compiler is said
to run out of macro space. Some Ultrix compilers run out of
expression space; then you need to break up the statement where
the problem happens.
9. If you are building a cross-compiler, stop here. *Note
Cross-Compiler::.
10. Move the first-stage object files and executables into a
subdirectory with this command:
make stage1
The files are moved into a subdirectory named `stage1'. Once
installation is complete, you may wish to delete these files with
`rm -r stage1'.
11. If you have chosen a configuration for GNU CC which requires other
GNU tools (such as GAS or the GNU linker) instead of the standard
system tools, install the required tools in the `stage1'
subdirectory under the names `as', `ld' or whatever is
appropriate. This will enable the stage 1 compiler to find the
proper tools in the following stage.
Alternatively, you can do subsequent compilation using a value of
the `PATH' environment variable such that the necessary GNU tools
come before the standard system tools.
12. Recompile the compiler with itself, with this command:
make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2"
This is called making the stage 2 compiler.
The command shown above builds compilers for all the supported
languages. If you don't want them all, you can specify the
languages to build by typing the argument `LANGUAGES="LIST"'. LIST
should contain one or more words from the list `c', `c++',
`objective-c', and `proto'. Separate the words with spaces.
`proto' stands for the programs `protoize' and `unprotoize'; they
are not a separate language, but you use `LANGUAGES' to enable or
disable their installation.
If you are going to build the stage 3 compiler, then you might
want to build only the C language in stage 2.
Once you have built the stage 2 compiler, if you are short of disk
space, you can delete the subdirectory `stage1'.
On a 68000 or 68020 system lacking floating point hardware, unless
you have selected a `tm.h' file that expects by default that there
is no such hardware, do this instead:
make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2 -msoft-float"
13. If you wish to test the compiler by compiling it with itself one
more time, install any other necessary GNU tools (such as GAS or
the GNU linker) in the `stage2' subdirectory as you did in the
`stage1' subdirectory, then do this:
make stage2
make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O2"
This is called making the stage 3 compiler. Aside from the `-B'
option, the compiler options should be the same as when you made
the stage 2 compiler. But the `LANGUAGES' option need not be the
same. The command shown above builds compilers for all the
supported languages; if you don't want them all, you can specify
the languages to build by typing the argument `LANGUAGES="LIST"',
as described above.
If you do not have to install any additional GNU tools, you may
use the command
make bootstrap LANGUAGES=LANGUAGE-LIST BOOT_CFLAGS=OPTION-LIST
instead of making `stage1', `stage2', and performing the two
compiler builds.
14. Then compare the latest object files with the stage 2 object
files--they ought to be identical, aside from time stamps (if any).
On some systems, meaningful comparison of object files is
impossible; they always appear "different." This is currently
true on Solaris and some systems that use ELF object file format.
On some versions of Irix on SGI machines and DEC Unix (OSF/1) on
Alpha systems, you will not be able to compare the files without
specifying `-save-temps'; see the description of individual
systems above to see if you get comparison failures. You may have
similar problems on other systems.
Use this command to compare the files:
make compare
This will mention any object files that differ between stage 2 and
stage 3. Any difference, no matter how innocuous, indicates that
the stage 2 compiler has compiled GNU CC incorrectly, and is
therefore a potentially serious bug which you should investigate
and report (*note Bugs::.).
If your system does not put time stamps in the object files, then
this is a faster way to compare them (using the Bourne shell):
for file in *.o; do
cmp $file stage2/$file
done
If you have built the compiler with the `-mno-mips-tfile' option on
MIPS machines, you will not be able to compare the files.
15. Install the compiler driver, the compiler's passes and run-time
support with `make install'. Use the same value for `CC',
`CFLAGS' and `LANGUAGES' that you used when compiling the files
that are being installed. One reason this is necessary is that
some versions of Make have bugs and recompile files gratuitously
when you do this step. If you use the same variable values, those
files will be recompiled properly.
For example, if you have built the stage 2 compiler, you can use
the following command:
make install CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O" LANGUAGES="LIST"
This copies the files `cc1', `cpp' and `libgcc.a' to files `cc1',
`cpp' and `libgcc.a' in the directory
`/usr/local/lib/gcc-lib/TARGET/VERSION', which is where the
compiler driver program looks for them. Here TARGET is the target
machine type specified when you ran `configure', and VERSION is
the version number of GNU CC. This naming scheme permits various
versions and/or cross-compilers to coexist. It also copies the
executables for compilers for other languages (e.g., `cc1plus' for
C++) to the same directory.
This also copies the driver program `xgcc' into
`/usr/local/bin/gcc', so that it appears in typical execution
search paths. It also copies `gcc.1' into `/usr/local/man/man1'
and info pages into `/usr/local/info'.
On some systems, this command causes recompilation of some files.
This is usually due to bugs in `make'. You should either ignore
this problem, or use GNU Make.
*Warning: there is a bug in `alloca' in the Sun library. To avoid
this bug, be sure to install the executables of GNU CC that were
compiled by GNU CC. (That is, the executables from stage 2 or 3,
not stage 1.) They use `alloca' as a built-in function and never
the one in the library.*
(It is usually better to install GNU CC executables from stage 2
or 3, since they usually run faster than the ones compiled with
some other compiler.)
16. If you're going to use C++, it's likely that you need to also
install the libg++ distribution. It should be available from the
same place where you got the GNU C distribution. Just as GNU C
does not distribute a C runtime library, it also does not include
a C++ run-time library. All I/O functionality, special class
libraries, etc., are available in the libg++ distribution.
17. GNU CC includes a runtime library for Objective-C because it is an
integral part of the language. You can find the files associated
with the library in the subdirectory `objc'. The GNU Objective-C
Runtime Library requires header files for the target's C library in
order to be compiled,and also requires the header files for the
target's thread library if you want thread support. *Note
Cross-Compilers and Header Files: Cross Headers, for discussion
about header files issues for cross-compilation.
When you run `configure', it picks the appropriate Objective-C
thread implementation file for the target platform. In some
situations, you may wish to choose a different back-end as some
platforms support multiple thread implementations or you may wish
to disable thread support completely. You do this by specifying a
value for the OBJC_THREAD_FILE makefile variable on the command
line when you run make, for example:
make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O2" OBJC_THREAD_FILE=thr-single
Below is a list of the currently available back-ends.
* thr-single Disable thread support, should work for all
platforms.
* thr-decosf1 DEC OSF/1 thread support.
* thr-irix SGI IRIX thread support.
* thr-mach Generic MACH thread support, known to work on
NEXTSTEP.
* thr-os2 IBM OS/2 thread support.
* thr-posix Generix POSIX thread support.
* thr-pthreads PCThreads on Linux-based GNU systems.
* thr-solaris SUN Solaris thread support.
* thr-win32 Microsoft Win32 API thread support.

1100
gcc/gcc.info-7 Normal file
View File

File diff suppressed because it is too large Load Diff

1202
gcc/gcc.info-8 Normal file
View File

File diff suppressed because it is too large Load Diff

1225
gcc/gcc.info-9 Normal file
View File

File diff suppressed because it is too large Load Diff