ytshih/ios2024
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ba9ef819bad9441f0649e9ce72cae13ab30bb311
ios2024/usr/local/nachos/info/gcc.info-28
T

1018 lines
45 KiB
Plaintext
Raw Blame History

This is Info file gcc.info, produced by Makeinfo version 1.68 from the
input file ../../gcc-2.95.2/gcc/gcc.texi.
INFO-DIR-SECTION Programming
START-INFO-DIR-ENTRY
* gcc: (gcc). The GNU Compiler Collection.
END-INFO-DIR-ENTRY
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, 1998,
1999 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" and "Funding
for Free Software" are included exactly as in the original, and
provided that the entire resulting derived work is distributed under
the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License" and "Funding for Free Software", and this permission notice,
may be included in translations approved by the Free Software Foundation
instead of in the original English.

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
those 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_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY)'
Optional: return the preferred mode for an `addr_diff_vec' when
the minimum and maximum offset are known. If you define this, it
enables extra code in branch shortening to deal with
`addr_diff_vec'. To make this work, you also have to define
INSN_ALIGN and make the alignment for `addr_diff_vec' explicit.
The BODY argument is provided so that the offset_unsigned and scale
flags can be updated.
`CASE_VECTOR_PC_RELATIVE'
Define this macro to be a C expression to indicate when jump-tables
should contain relative addresses. If jump-tables never contain
relative addresses, then you need not define this macro.
`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'.
`SHORT_IMMEDIATES_SIGN_EXTEND'
Define this macro if loading short immediate values into registers
sign extends.
`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 (GETC, UNGETC, NAME)'
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 macro, zero otherwise. The argument GETC is a
function of type `int (*)(void)' which will return the next
character in the input stream, or EOF if no characters are left.
The argument UNGETC is a function of type `void (*)(int)' which
will push a character back into the input stream. The argument
NAME is the word following #pragma in the input stream. The input
stream pointer will be pointing just beyond the end of this word.
The input stream should be left undistrubed if the expression
returns zero, otherwise it should be pointing at the next
character after the end of the pragma. Any characters remaining
on the line will be ignored.
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.
If the pragma can be implemented by atttributes then the macro
`INSERT_ATTRIBUTES' might be a useful one to define as well.
Note: older versions of this macro only had two arguments: STREAM
and TOKEN. The macro was changed in order to allow it to work
when gcc is built both with and without a cpp library.
`HANDLE_SYSV_PRAGMA'
Define this macro (to a value of 1) if you want the System V style
pragmas `#pragma pack(<n>)' and `#pragma weak <name> [=<value>]'
to be supported by gcc.
The pack pragma specifies the maximum alignment (in bytes) of
fields within a structure, in much the same way as the
`__aligned__' and `__packed__' `__attribute__'s do. A pack value
of zero resets the behaviour to the default.
The weak pragma only works if `SUPPORTS_WEAK' and
`ASM_WEAKEN_LABEL' are defined. If enabled it allows the creation
of specifically named weak labels, optionally with a value.
`HANDLE_PRAGMA_PACK_PUSH_POP'
Define this macro (to a value of 1) if you want to support the
Win32 style pragmas `#pragma pack(push,<n>)' and `#pragma
pack(pop)'. The pack(push,<n>) pragma specifies the maximum
alignment (in bytes) of fields within a structure, in much the
same way as the `__aligned__' and `__packed__' `__attribute__'s
do. A pack value of zero resets the behaviour to the default.
Successive invocations of this pragma cause the previous values to
be stacked, so that invocations of `#pragma pack(pop)' will return
to the previous value.
`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.
`MERGE_MACHINE_TYPE_ATTRIBUTES (TYPE1, TYPE2)'
Define this macro if the merging of type attributes needs special
handling. If defined, the result is a list of the combined
TYPE_ATTRIBUTES of TYPE1 and TYPE2. It is assumed that comptypes
has already been called and returned 1.
`MERGE_MACHINE_DECL_ATTRIBUTES (OLDDECL, NEWDECL)'
Define this macro if the merging of decl attributes needs special
handling. If defined, the result is a list of the combined
DECL_MACHINE_ATTRIBUTES of OLDDECL and NEWDECL. NEWDECL is a
duplicate declaration of OLDDECL. Examples of when this is needed
are when one attribute overrides another, or when an attribute is
nullified by a subsequent definition.
`INSERT_ATTRIBUTES (NODE, ATTR_PTR, PREFIX_PTR)'
Define this macro if you want to be able to add attributes to a
decl when it is being created. This is normally useful for
backends which wish to implement a pragma by using the attributes
which correspond to the pragma's effect. The NODE argument is the
decl which is being created. The ATTR_PTR argument is a pointer
to the attribute list for this decl. The PREFIX_PTR is a pointer
to the list of attributes that have appeared after the specifiers
and modifiers of the declaration, but before the declaration
proper.
`SET_DEFAULT_DECL_ATTRIBUTES (DECL, ATTRIBUTES)'
If defined, a C statement that assigns default attributes to newly
defined DECL.
`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).
`ISSUE_RATE'
A C expression that returns how many instructions can be issued at
the same time if the machine is a superscalar machine. This is
only used by the `Haifa' scheduler, and not the traditional
scheduler.
`MD_SCHED_INIT (FILE, VERBOSE)'
A C statement which is executed by the `Haifa' scheduler at the
beginning of each block of instructions that are to be scheduled.
FILE is either a null pointer, or a stdio stream to write any
debug output to. VERBOSE is the verbose level provided by
`-fsched-verbose-'N.
`MD_SCHED_REORDER (FILE, VERBOSE, READY, N_READY)'
A C statement which is executed by the `Haifa' scheduler after it
has scheduled the ready list to allow the machine description to
reorder it (for example to combine two small instructions together
on `VLIW' machines). FILE is either a null pointer, or a stdio
stream to write any debug output to. VERBOSE is the verbose level
provided by `-fsched-verbose-'N. READY is a pointer to the ready
list of instructions that are ready to be scheduled. N_READY is
the number of elements in the ready list. The scheduler reads the
ready list in reverse order, starting with READY[N_READY-1] and
going to READY[0].
`MD_SCHED_VARIABLE_ISSUE (FILE, VERBOSE, INSN, MORE)'
A C statement which is executed by the `Haifa' scheduler after it
has scheduled an insn from the ready list. FILE is either a null
pointer, or a stdio stream to write any debug output to. VERBOSE
is the verbose level provided by `-fsched-verbose-'N. INSN is the
instruction that was scheduled. MORE is the number of
instructions that can be issued in the current cycle. The
`MD_SCHED_VARIABLE_ISSUE' macro is responsible for updating the
value of MORE (typically by MORE-).
`MAX_INTEGER_COMPUTATION_MODE'
Define this to the largest integer machine mode which can be used
for operations other than load, store and copy operations.
You need only define this macro if the target holds values larger
than `word_mode' in general purpose registers. Most targets
should not define this macro.
`MATH_LIBRARY'
Define this macro as a C string constant for the linker argument
to link in the system math library, or `""' if the target does not
have a separate math library.
You need only define this macro if the default of `"-lm"' is wrong.

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 GCC 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. (GCC 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 GCC 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.
`MULTIBYTE_CHARS'
Define this macro to enable support for multibyte characters in the
input to GCC. This requires that the host system support the ANSI
C library functions for converting multibyte characters to wide
characters.
`POSIX'
Define this if your system is POSIX.1 compliant.
`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 GCC. 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
GCC. 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.
`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 GCC
displays file names, the character you specify will be used. GCC
will test for both slash and the character you specify when
parsing filenames.
`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,
GCC 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, GCC 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 GCC, in order to take advantage of the benefit of
GCC's built-in `alloca'.

File: gcc.info, Node: Fragments, Next: Funding, Prev: Config, Up: Top
Makefile Fragments
******************
When you configure GCC 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 GCC in different ways produces objects
that can not be linked together. For example, for some targets GCC
produces both big and little endian code. For these targets, you
must arrange for multiple versions of `libgcc.a' to be compiled,
one for each set of incompatible options. When GCC 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 following 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 set to `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', GCC 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: GNU/Linux, 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 Compiler Collection
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: GNU/Linux, Next: Copying, Prev: Funding, Up: Top
Linux and the GNU Project
*************************
Many computer users run a modified version of the GNU system every
day, without realizing it. Through a peculiar turn of events, the
version of GNU which is widely used today is more often known as
"Linux", and many users are not aware of the extent of its connection
with the GNU Project.
There really is a Linux; it is a kernel, and these people are using
it. But you can't use a kernel by itself; a kernel is useful only as
part of a whole system. The system in which Linux is typically used is
a modified variant of the GNU system--in other words, a Linux-based GNU
system.
Many users are not fully aware of the distinction between the kernel,
which is Linux, and the whole system, which they also call "Linux".
The ambiguous use of the name doesn't promote understanding.
Programmers generally know that Linux is a kernel. But since they
have generally heard the whole system called "Linux" as well, they
often envisage a history which fits that name. For example, many
believe that once Linus Torvalds finished writing the kernel, his
friends looked around for other free software, and for no particular
reason most everything necessary to make a Unix-like system was already
available.
What they found was no accident--it was the GNU system. The
available free software added up to a complete system because the GNU
Project had been working since 1984 to make one. The GNU Manifesto had
set forth the goal of developing a free Unix-like system, called GNU.
By the time Linux was written, the system was almost finished.
Most free software projects have the goal of developing a particular
program for a particular job. For example, Linus Torvalds set out to
write a Unix-like kernel (Linux); Donald Knuth set out to write a text
formatter (TeX); Bob Scheifler set out to develop a window system (X
Windows). It's natural to measure the contribution of this kind of
project by specific programs that came from the project.
If we tried to measure the GNU Project's contribution in this way,
what would we conclude? One CD-ROM vendor found that in their "Linux
distribution", GNU software was the largest single contingent, around
28% of the total source code, and this included some of the essential
major components without which there could be no system. Linux itself
was about 3%. So if you were going to pick a name for the system based
on who wrote the programs in the system, the most appropriate single
choice would be "GNU".
But we don't think that is the right way to consider the question.
The GNU Project was not, is not, a project to develop specific software
packages. It was not a project to develop a C compiler, although we
did. It was not a project to develop a text editor, although we
developed one. The GNU Project's aim was to develop *a complete free
Unix-like system*.
Many people have made major contributions to the free software in the
system, and they all deserve credit. But the reason it is *a
system*--and not just a collection of useful programs--is because the
GNU Project set out to make it one. We wrote the programs that were
needed to make a *complete* free system. We wrote essential but
unexciting major components, such as the assembler and linker, because
you can't have a system without them. A complete system needs more
than just programming tools, so we wrote other components as well, such
as the Bourne Again SHell, the PostScript interpreter Ghostscript, and
the GNU C library.
By the early 90s we had put together the whole system aside from the
kernel (and we were also working on a kernel, the GNU Hurd, which runs
on top of Mach). Developing this kernel has been a lot harder than we
expected, and we are still working on finishing it.
Fortunately, you don't have to wait for it, because Linux is working
now. When Linus Torvalds wrote Linux, he filled the last major gap.
People could then put Linux together with the GNU system to make a
complete free system: a Linux-based GNU system (or GNU/Linux system,
for short).
Putting them together sounds simple, but it was not a trivial job.
The GNU C library (called glibc for short) needed substantial changes.
Integrating a complete system as a distribution that would work "out of
the box" was a big job, too. It required addressing the issue of how
to install and boot the system--a problem we had not tackled, because
we hadn't yet reached that point. The people who developed the various
system distributions made a substantial contribution.
The GNU Project supports GNU/Linux systems as well as *the* GNU
system--even with funds. We funded the rewriting of the Linux-related
extensions to the GNU C library, so that now they are well integrated,
and the newest GNU/Linux systems use the current library release with
no changes. We also funded an early stage of the development of Debian
GNU/Linux.
We use Linux-based GNU systems today for most of our work, and we
hope you use them too. But please don't confuse the public by using the
name "Linux" ambiguously. Linux is the kernel, one of the essential
major components of the system. The system as a whole is more or less
the GNU system.
Reference in New Issue View Git Blame Copy Permalink