1117 lines
46 KiB
Plaintext
1117 lines
46 KiB
Plaintext
This is Info file gcc.info, produced by Makeinfo-1.47 from the input
|
||
file gcc.texi.
|
||
|
||
This file documents the use and the internals of the GNU compiler.
|
||
|
||
Copyright (C) 1988, 1989, 1992 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 "Boycott"
|
||
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 "Boycott", 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: Driver, Next: Run-time Target, Up: Target Macros
|
||
|
||
Controlling the Compilation Driver, `gcc'
|
||
=========================================
|
||
|
||
`SWITCH_TAKES_ARG (CHAR)'
|
||
A C expression which determines whether the option `-CHAR' takes
|
||
arguments. The value should be the number of arguments that
|
||
option takes--zero, for many options.
|
||
|
||
By default, this macro is defined to handle the standard options
|
||
properly. You need not define it unless you wish to add additional
|
||
options which take arguments.
|
||
|
||
`WORD_SWITCH_TAKES_ARG (NAME)'
|
||
A C expression which determines whether the option `-NAME' takes
|
||
arguments. The value should be the number of arguments that
|
||
option takes--zero, for many options. This macro rather than
|
||
`SWITCH_TAKES_ARG' is used for multi-character option names.
|
||
|
||
By default, this macro is defined to handle the standard options
|
||
properly. You need not define it unless you wish to add additional
|
||
options which take arguments.
|
||
|
||
`SWITCHES_NEED_SPACES'
|
||
A string-valued C expression which is nonempty if the linker needs
|
||
a space between the `-L' or `-o' option and its argument.
|
||
|
||
If this macro is not defined, the default value is 0.
|
||
|
||
`CPP_SPEC'
|
||
A C string constant that tells the GNU CC driver program options to
|
||
pass to CPP. It can also specify how to translate options you
|
||
give to GNU CC into options for GNU CC to pass to the CPP.
|
||
|
||
Do not define this macro if it does not need to do anything.
|
||
|
||
`SIGNED_CHAR_SPEC'
|
||
A C string constant that tells the GNU CC driver program options to
|
||
pass to CPP. By default, this macro is defined to pass the option
|
||
`-D__CHAR_UNSIGNED__' to CPP if `char' will be treated as
|
||
`unsigned char' by `cc1'.
|
||
|
||
Do not define this macro unless you need to override the default
|
||
definition.
|
||
|
||
`CC1_SPEC'
|
||
A C string constant that tells the GNU CC driver program options to
|
||
pass to `cc1'. It can also specify how to translate options you
|
||
give to GNU CC into options for GNU CC to pass to the `cc1'.
|
||
|
||
Do not define this macro if it does not need to do anything.
|
||
|
||
`CC1PLUS_SPEC'
|
||
A C string constant that tells the GNU CC driver program options to
|
||
pass to `cc1plus'. It can also specify how to translate options
|
||
you give to GNU CC into options for GNU CC to pass to the
|
||
`cc1plus'.
|
||
|
||
Do not define this macro if it does not need to do anything.
|
||
|
||
`ASM_SPEC'
|
||
A C string constant that tells the GNU CC driver program options to
|
||
pass to the assembler. It can also specify how to translate
|
||
options you give to GNU CC into options for GNU CC to pass to the
|
||
assembler. See the file `sun3.h' for an example of this.
|
||
|
||
Do not define this macro if it does not need to do anything.
|
||
|
||
`ASM_FINAL_SPEC'
|
||
A C string constant that tells the GNU CC driver program how to
|
||
run any programs which cleanup after the normal assembler.
|
||
Normally, this is not needed. See the file `mips.h' for an
|
||
example of this.
|
||
|
||
Do not define this macro if it does not need to do anything.
|
||
|
||
`LINK_SPEC'
|
||
A C string constant that tells the GNU CC driver program options to
|
||
pass to the linker. It can also specify how to translate options
|
||
you give to GNU CC into options for GNU CC to pass to the linker.
|
||
|
||
Do not define this macro if it does not need to do anything.
|
||
|
||
`LIB_SPEC'
|
||
Another C string constant used much like `LINK_SPEC'. The
|
||
difference between the two is that `LIB_SPEC' is used at the end
|
||
of the command given to the linker.
|
||
|
||
If this macro is not defined, a default is provided that loads the
|
||
standard C library from the usual place. See `gcc.c'.
|
||
|
||
`STARTFILE_SPEC'
|
||
Another C string constant used much like `LINK_SPEC'. The
|
||
difference between the two is that `STARTFILE_SPEC' is used at the
|
||
very beginning of the command given to the linker.
|
||
|
||
If this macro is not defined, a default is provided that loads the
|
||
standard C startup file from the usual place. See `gcc.c'.
|
||
|
||
`ENDFILE_SPEC'
|
||
Another C string constant used much like `LINK_SPEC'. The
|
||
difference between the two is that `ENDFILE_SPEC' is used at the
|
||
very end of the command given to the linker.
|
||
|
||
Do not define this macro if it does not need to do anything.
|
||
|
||
`LINK_LIBGCC_SPECIAL'
|
||
Define this macro meaning that `gcc' should find the library
|
||
`libgcc.a' by hand, rather than passing the argument `-lgcc' to
|
||
tell the linker to do the search.
|
||
|
||
`RELATIVE_PREFIX_NOT_LINKDIR'
|
||
Define this macro to tell `gcc' that it should only translate a
|
||
`-B' prefix into a `-L' linker option if the prefix indicates an
|
||
absolute file name.
|
||
|
||
`STANDARD_EXEC_PREFIX'
|
||
Define this macro as a C string constant if you wish to override
|
||
the standard choice of `/usr/local/lib/gcc-lib/' as the default
|
||
prefix to try when searching for the executable files of the
|
||
compiler.
|
||
|
||
`MD_EXEC_PREFIX'
|
||
If defined, this macro is an additional prefix to try after
|
||
`STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when the
|
||
`-b' option is used, or the compiler is built as a cross compiler.
|
||
|
||
`STANDARD_STARTFILE_PREFIX'
|
||
Define this macro as a C string constant if you wish to override
|
||
the standard choice of `/usr/local/lib/' as the default prefix to
|
||
try when searching for startup files such as `crt0.o'.
|
||
|
||
`MD_STARTFILE_PREFIX'
|
||
If defined, this macro supplies an additional prefix to try after
|
||
the standard prefixes. `MD_EXEC_PREFIX' is not searched when the
|
||
`-b' option is used, or when the compiler is built as a cross
|
||
compiler.
|
||
|
||
`MD_STARTFILE_PREFIX_1'
|
||
If defined, this macro supplies yet another prefix to try after the
|
||
standard prefixes. It is not searched when the `-b' option is
|
||
used, or when the compiler is built as a cross compiler.
|
||
|
||
`LOCAL_INCLUDE_DIR'
|
||
Define this macro as a C string constant if you wish to override
|
||
the standard choice of `/usr/local/include' as the default prefix
|
||
to try when searching for local header files. `LOCAL_INCLUDE_DIR'
|
||
comes before `SYSTEM_INCLUDE_DIR' in the search order.
|
||
|
||
Cross compilers do not use this macro and do not search either
|
||
`/usr/local/include' or its replacement.
|
||
|
||
`SYSTEM_INCLUDE_DIR'
|
||
Define this macro as a C string constant if you wish to specify a
|
||
system-specific directory to search for header files before the
|
||
standard directory. `SYSTEM_INCLUDE_DIR' comes before
|
||
`STANDARD_INCLUDE_DIR' in the search order.
|
||
|
||
Cross compilers do not use this macro and do not search the
|
||
directory specified.
|
||
|
||
`STANDARD_INCLUDE_DIR'
|
||
Define this macro as a C string constant if you wish to override
|
||
the standard choice of `/usr/include' as the default prefix to try
|
||
when searching for header files.
|
||
|
||
Cross compilers do not use this macro and do not search either
|
||
`/usr/include' or its replacement.
|
||
|
||
`INCLUDE_DEFAULTS'
|
||
Define this macro if you wish to override the entire default
|
||
search path for include files. The default search path includes
|
||
`GPLUSPLUS_INCLUDE_DIR', `GCC_INCLUDE_DIR', `LOCAL_INCLUDE_DIR',
|
||
`SYSTEM_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition,
|
||
the macros `GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are
|
||
defined automatically by `Makefile', and specify private search
|
||
areas for GCC. The directory `GPLUSPLUS_INCLUDE_DIR' is used only
|
||
for C++ programs.
|
||
|
||
The definition should be an initializer for an array of structures.
|
||
Each array element should have two elements: the directory name (a
|
||
string constant) and a flag for C++-only directories. Mark the
|
||
end of the array with a null element. For example, here is the
|
||
definition used for VMS:
|
||
|
||
#define INCLUDE_DEFAULTS \
|
||
{ \
|
||
{ "GNU_GXX_INCLUDE:", 1}, \
|
||
{ "GNU_CC_INCLUDE:", 0}, \
|
||
{ "SYS$SYSROOT:[SYSLIB.]", 0}, \
|
||
{ ".", 0}, \
|
||
{ 0, 0} \
|
||
}
|
||
|
||
Here is the order of prefixes tried for exec files:
|
||
|
||
1. Any prefixes specified by the user with `-B'.
|
||
|
||
2. The environment variable `GCC_EXEC_PREFIX', if any.
|
||
|
||
3. The directories specified by the environment variable
|
||
`COMPILER_PATH'.
|
||
|
||
4. The macro `STANDARD_EXEC_PREFIX'.
|
||
|
||
5. `/usr/lib/gcc/'.
|
||
|
||
6. The macro `MD_EXEC_PREFIX', if any.
|
||
|
||
Here is the order of prefixes tried for startfiles:
|
||
|
||
1. Any prefixes specified by the user with `-B'.
|
||
|
||
2. The environment variable `GCC_EXEC_PREFIX', if any.
|
||
|
||
3. The directories specified by the environment variable
|
||
`LIBRARY_PATH'.
|
||
|
||
4. The macro `STANDARD_EXEC_PREFIX'.
|
||
|
||
5. `/usr/lib/gcc/'.
|
||
|
||
6. The macro `MD_EXEC_PREFIX', if any.
|
||
|
||
7. The macro `MD_STARTFILE_PREFIX', if any.
|
||
|
||
8. The macro `STANDARD_STARTFILE_PREFIX'.
|
||
|
||
9. `/lib/'.
|
||
|
||
10. `/usr/lib/'.
|
||
|
||
|
||
File: gcc.info, Node: Run-time Target, Next: Storage Layout, Prev: Driver, Up: Target Macros
|
||
|
||
Run-time Target Specification
|
||
=============================
|
||
|
||
`CPP_PREDEFINES'
|
||
Define this to be a string constant containing `-D' options to
|
||
define the predefined macros that identify this machine and system.
|
||
These macros will be predefined unless the `-ansi' option is
|
||
specified.
|
||
|
||
In addition, a parallel set of macros are predefined, whose names
|
||
are made by appending `__' at the beginning and at the end. These
|
||
`__' macros are permitted by the ANSI standard, so they are
|
||
predefined regardless of whether `-ansi' is specified.
|
||
|
||
For example, on the Sun, one can use the following value:
|
||
|
||
"-Dmc68000 -Dsun -Dunix"
|
||
|
||
The result is to define the macros `__mc68000__', `__sun__' and
|
||
`__unix__' unconditionally, and the macros `mc68000', `sun' and
|
||
`unix' provided `-ansi' is not specified.
|
||
|
||
`STDC_VALUE'
|
||
Define the value to be assigned to the built-in macro `__STDC__'.
|
||
The default is the value `1'.
|
||
|
||
`extern int target_flags;'
|
||
This declaration should be present.
|
||
|
||
`TARGET_...'
|
||
This series of macros is to allow compiler command arguments to
|
||
enable or disable the use of optional features of the target
|
||
machine. For example, one machine description serves both the
|
||
68000 and the 68020; a command argument tells the compiler whether
|
||
it should use 68020-only instructions or not. This command
|
||
argument works by means of a macro `TARGET_68020' that tests a bit
|
||
in `target_flags'.
|
||
|
||
Define a macro `TARGET_FEATURENAME' for each such option. Its
|
||
definition should test a bit in `target_flags'; for example:
|
||
|
||
#define TARGET_68020 (target_flags & 1)
|
||
|
||
One place where these macros are used is in the
|
||
condition-expressions of instruction patterns. Note how
|
||
`TARGET_68020' appears frequently in the 68000 machine description
|
||
file, `m68k.md'. Another place they are used is in the definitions
|
||
of the other macros in the `MACHINE.h' file.
|
||
|
||
`TARGET_SWITCHES'
|
||
This macro defines names of command options to set and clear bits
|
||
in `target_flags'. Its definition is an initializer with a
|
||
subgrouping for each command option.
|
||
|
||
Each subgrouping contains a string constant, that defines the
|
||
option name, and a number, which contains the bits to set in
|
||
`target_flags'. A negative number says to clear bits instead; the
|
||
negative of the number is which bits to clear. The actual option
|
||
name is made by appending `-m' to the specified name.
|
||
|
||
One of the subgroupings should have a null string. The number in
|
||
this grouping is the default value for `target_flags'. Any target
|
||
options act starting with that value.
|
||
|
||
Here is an example which defines `-m68000' and `-m68020' with
|
||
opposite meanings, and picks the latter as the default:
|
||
|
||
#define TARGET_SWITCHES \
|
||
{ { "68020", 1}, \
|
||
{ "68000", -1}, \
|
||
{ "", 1}}
|
||
|
||
`TARGET_OPTIONS'
|
||
This macro is similar to `TARGET_SWITCHES' but defines names of
|
||
command options that have values. Its definition is an
|
||
initializer with a subgrouping for each command option.
|
||
|
||
Each subgrouping contains a string constant, that defines the
|
||
fixed part of the option name, and the address of a variable. The
|
||
variable, type `char *', is set to the variable part of the given
|
||
option if the fixed part matches. The actual option name is made
|
||
by appending `-m' to the specified name.
|
||
|
||
Here is an example which defines `-mshort-data-NUMBER'. If the
|
||
given option is `-mshort-data-512', the variable `m88k_short_data'
|
||
will be set to the string `"512"'.
|
||
|
||
extern char *m88k_short_data;
|
||
#define TARGET_OPTIONS { { "short-data-", &m88k_short_data } }
|
||
|
||
`TARGET_VERSION'
|
||
This macro is a C statement to print on `stderr' a string
|
||
describing the particular machine description choice. Every
|
||
machine description should define `TARGET_VERSION'. For example:
|
||
|
||
#ifdef MOTOROLA
|
||
#define TARGET_VERSION fprintf (stderr, " (68k, Motorola syntax)");
|
||
#else
|
||
#define TARGET_VERSION fprintf (stderr, " (68k, MIT syntax)");
|
||
#endif
|
||
|
||
`OVERRIDE_OPTIONS'
|
||
Sometimes certain combinations of command options do not make
|
||
sense on a particular target machine. You can define a macro
|
||
`OVERRIDE_OPTIONS' to take account of this. This macro, if
|
||
defined, is executed once just after all the command options have
|
||
been parsed.
|
||
|
||
Don't use this macro to turn on various extra optimizations for
|
||
`-O'. That is what `OPTIMIZATION_OPTIONS' is for.
|
||
|
||
`OPTIMIZATION_OPTIONS (LEVEL)'
|
||
Some machines may desire to change what optimizations are
|
||
performed for various optimization levels. This macro, if
|
||
defined, is executed once just after the optimization level is
|
||
determined and before the remainder of the command options have
|
||
been parsed. Values set in this macro are used as the default
|
||
values for the other command line options.
|
||
|
||
LEVEL is the optimization level specified; 2 if -O2 is specified,
|
||
1 if -O is specified, and 0 if neither is specified.
|
||
|
||
*Do not examine `write_symbols' in this macro!* The debugging
|
||
options are not supposed to alter the generated code.
|
||
|
||
|
||
File: gcc.info, Node: Storage Layout, Next: Type Layout, Prev: Run-time Target, Up: Target Macros
|
||
|
||
Storage Layout
|
||
==============
|
||
|
||
Note that the definitions of the macros in this table which are
|
||
sizes or alignments measured in bits do not need to be constant. They
|
||
can be C expressions that refer to static variables, such as the
|
||
`target_flags'. *Note Run-time Target::.
|
||
|
||
`BITS_BIG_ENDIAN'
|
||
Define this macro to be the value 1 if the most significant bit in
|
||
a byte has the lowest number; otherwise define it to be the value
|
||
zero. This means that bit-field instructions count from the most
|
||
significant bit. If the machine has no bit-field instructions,
|
||
this macro is irrelevant.
|
||
|
||
This macro does not affect the way structure fields are packed into
|
||
bytes or words; that is controlled by `BYTES_BIG_ENDIAN'.
|
||
|
||
`BYTES_BIG_ENDIAN'
|
||
Define this macro to be 1 if the most significant byte in a word
|
||
has the lowest number.
|
||
|
||
`WORDS_BIG_ENDIAN'
|
||
Define this macro to be 1 if, in a multiword object, the most
|
||
significant word has the lowest number.
|
||
|
||
`BITS_PER_UNIT'
|
||
Number of bits in an addressable storage unit (byte); normally 8.
|
||
|
||
`BITS_PER_WORD'
|
||
Number of bits in a word; normally 32.
|
||
|
||
`MAX_BITS_PER_WORD'
|
||
Maximum number of bits in a word. If this is undefined, the
|
||
default is `BITS_PER_WORD'. Otherwise, it is the constant value
|
||
that is the largest value that `BITS_PER_WORD' can have at
|
||
run-time.
|
||
|
||
`UNITS_PER_WORD'
|
||
Number of storage units in a word; normally 4.
|
||
|
||
`POINTER_SIZE'
|
||
Width of a pointer, in bits.
|
||
|
||
`PARM_BOUNDARY'
|
||
Normal alignment required for function parameters on the stack, in
|
||
bits. All stack parameters receive least this much alignment
|
||
regardless of data type. On most machines, this is the same as the
|
||
size of an integer.
|
||
|
||
`STACK_BOUNDARY'
|
||
Define this macro if you wish to preserve a certain alignment for
|
||
the stack pointer. The definition is a C expression for the
|
||
desired alignment (measured in bits).
|
||
|
||
If `PUSH_ROUNDING' is not defined, the stack will always be aligned
|
||
to the specified boundary. If `PUSH_ROUNDING' is defined and
|
||
specifies a less strict alignment than `STACK_BOUNDARY', the stack
|
||
may be momentarily unaligned while pushing arguments.
|
||
|
||
`FUNCTION_BOUNDARY'
|
||
Alignment required for a function entry point, in bits.
|
||
|
||
`BIGGEST_ALIGNMENT'
|
||
Biggest alignment that any data type can require on this machine,
|
||
in bits.
|
||
|
||
`BIGGEST_FIELD_ALIGNMENT'
|
||
Biggest alignment that any structure field can require on this
|
||
machine, in bits. If defined, this overrides `BIGGEST_ALIGNMENT'
|
||
for structure fields only.
|
||
|
||
`MAX_OFILE_ALIGNMENT'
|
||
Biggest alignment supported by the object file format of this
|
||
machine. Use this macro to limit the alignment which can be
|
||
specified using the `__attribute__ ((aligned (N)))' construct. If
|
||
not defined, the default value is `BIGGEST_ALIGNMENT'.
|
||
|
||
`DATA_ALIGNMENT (TYPE, BASIC-ALIGN)'
|
||
If defined, a C expression to compute the alignment for a static
|
||
variable. TYPE is the data type, and BASIC-ALIGN is the alignment
|
||
that the object would ordinarily have. The value of this macro is
|
||
used instead of that alignment to align the object.
|
||
|
||
If this macro is not defined, then BASIC-ALIGN is used.
|
||
|
||
One use of this macro is to increase alignment of medium-size data
|
||
to make it all fit in fewer cache lines. Another is to cause
|
||
character arrays to be word-aligned so that `strcpy' calls that
|
||
copy constants to character arrays can be done inline.
|
||
|
||
`CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN)'
|
||
If defined, a C expression to compute the alignment given to a
|
||
constant that is being placed in memory. CONSTANT is the constant
|
||
and BASIC-ALIGN is the alignment that the object would ordinarily
|
||
have. The value of this macro is used instead of that alignment to
|
||
align the object.
|
||
|
||
If this macro is not defined, then BASIC-ALIGN is used.
|
||
|
||
The typical use of this macro is to increase alignment for string
|
||
constants to be word aligned so that `strcpy' calls that copy
|
||
constants can be done inline.
|
||
|
||
`EMPTY_FIELD_BOUNDARY'
|
||
Alignment in bits to be given to a structure bit field that
|
||
follows an empty field such as `int : 0;'.
|
||
|
||
Note that `PCC_BITFIELD_TYPE_MATTERS' also affects the alignment
|
||
that results from an empty field.
|
||
|
||
`STRUCTURE_SIZE_BOUNDARY'
|
||
Number of bits which any structure or union's size must be a
|
||
multiple of. Each structure or union's size is rounded up to a
|
||
multiple of this.
|
||
|
||
If you do not define this macro, the default is the same as
|
||
`BITS_PER_UNIT'.
|
||
|
||
`STRICT_ALIGNMENT'
|
||
Define this macro to be the value 1 if instructions will fail to
|
||
work if given data not on the nominal alignment. If instructions
|
||
will merely go slower in that case, define this macro as 0.
|
||
|
||
`PCC_BITFIELD_TYPE_MATTERS'
|
||
Define this if you wish to imitate the way many other C compilers
|
||
handle alignment of bitfields and the structures that contain them.
|
||
|
||
The behavior is that the type written for a bitfield (`int',
|
||
`short', or other integer type) imposes an alignment for the
|
||
entire structure, as if the structure really did contain an
|
||
ordinary field of that type. In addition, the bitfield is placed
|
||
within the structure so that it would fit within such a field, not
|
||
crossing a boundary for it.
|
||
|
||
Thus, on most machines, a bitfield whose type is written as `int'
|
||
would not cross a four-byte boundary, and would force four-byte
|
||
alignment for the whole structure. (The alignment used may not be
|
||
four bytes; it is controlled by the other alignment parameters.)
|
||
|
||
If the macro is defined, its definition should be a C expression;
|
||
a nonzero value for the expression enables this behavior.
|
||
|
||
Note that if this macro is not defined, or its value is zero, some
|
||
bitfields may cross more than one alignment boundary. The
|
||
compiler can support such references if there are `insv', `extv',
|
||
and `extzv' insns that can directly reference memory.
|
||
|
||
The other known way of making bitfields work is to define
|
||
`STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then
|
||
every structure can be accessed with fullwords.
|
||
|
||
Unless the machine has bitfield instructions or you define
|
||
`STRUCTURE_SIZE_BOUNDARY' that way, you must define
|
||
`PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value.
|
||
|
||
`BITFIELD_NBYTES_LIMITED'
|
||
Like PCC_BITFIELD_TYPE_MATTERS except that its effect is limited to
|
||
aligning a bitfield within the structure.
|
||
|
||
`ROUND_TYPE_SIZE (STRUCT, SIZE, ALIGN)'
|
||
Define this macro as an expression for the overall size of a
|
||
structure (given by STRUCT as a tree node) when the size computed
|
||
from the fields is SIZE and the alignment is ALIGN.
|
||
|
||
The default is to round SIZE up to a multiple of ALIGN.
|
||
|
||
`ROUND_TYPE_ALIGN (STRUCT, COMPUTED, SPECIFIED)'
|
||
Define this macro as an expression for the alignment of a structure
|
||
(given by STRUCT as a tree node) if the alignment computed in the
|
||
usual way is COMPUTED and the alignment explicitly specified was
|
||
SPECIFIED.
|
||
|
||
The default is to use SPECIFIED if it is larger; otherwise, use
|
||
the smaller of COMPUTED and `BIGGEST_ALIGNMENT'
|
||
|
||
`MAX_FIXED_MODE_SIZE'
|
||
An integer expression for the size in bits of the largest integer
|
||
machine mode that should actually be used. All integer machine
|
||
modes of this size or smaller can be used for structures and
|
||
unions with the appropriate sizes. If this macro is undefined,
|
||
`GET_MODE_BITSIZE (DImode)' is assumed.
|
||
|
||
`CHECK_FLOAT_VALUE (MODE, VALUE)'
|
||
A C statement to validate the value VALUE (of type `double') for
|
||
mode MODE. This means that you check whether VALUE fits within
|
||
the possible range of values for mode MODE on this target machine.
|
||
The mode MODE is always `SFmode' or `DFmode'.
|
||
|
||
If VALUE is not valid, you should call `error' to print an error
|
||
message and then assign some valid value to VALUE. Allowing an
|
||
invalid value to go through the compiler can produce incorrect
|
||
assembler code which may even cause Unix assemblers to crash.
|
||
|
||
This macro need not be defined if there is no work for it to do.
|
||
|
||
`TARGET_FLOAT_FORMAT'
|
||
A code distinguishing the floating point format of the target
|
||
machine. There are three defined values:
|
||
|
||
`IEEE_FLOAT_FORMAT'
|
||
This code indicates IEEE floating point. It is the default;
|
||
there is no need to define this macro when the format is IEEE.
|
||
|
||
`VAX_FLOAT_FORMAT'
|
||
This code indicates the peculiar format used on the Vax.
|
||
|
||
`UNKNOWN_FLOAT_FORMAT'
|
||
This code indicates any other format.
|
||
|
||
The value of this macro is compared with `HOST_FLOAT_FORMAT'
|
||
(*note Config::.) to determine whether the target machine has the
|
||
same format as the host machine. If any other formats are
|
||
actually in use on supported machines, new codes should be defined
|
||
for them.
|
||
|
||
|
||
File: gcc.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros
|
||
|
||
Layout of Source Language Data Types
|
||
====================================
|
||
|
||
These macros define the sizes and other characteristics of the
|
||
standard basic data types used in programs being compiled. Unlike the
|
||
macros in the previous section, these apply to specific features of C
|
||
and related languages, rather than to fundamental aspects of storage
|
||
layout.
|
||
|
||
`INT_TYPE_SIZE'
|
||
A C expression for the size in bits of the type `int' on the
|
||
target machine. If you don't define this, the default is one word.
|
||
|
||
`SHORT_TYPE_SIZE'
|
||
A C expression for the size in bits of the type `short' on the
|
||
target machine. If you don't define this, the default is half a
|
||
word. (If this would be less than one storage unit, it is rounded
|
||
up to one unit.)
|
||
|
||
`LONG_TYPE_SIZE'
|
||
A C expression for the size in bits of the type `long' on the
|
||
target machine. If you don't define this, the default is one word.
|
||
|
||
`LONG_LONG_TYPE_SIZE'
|
||
A C expression for the size in bits of the type `long long' on the
|
||
target machine. If you don't define this, the default is two
|
||
words.
|
||
|
||
`CHAR_TYPE_SIZE'
|
||
A C expression for the size in bits of the type `char' on the
|
||
target machine. If you don't define this, the default is one
|
||
quarter of a word. (If this would be less than one storage unit,
|
||
it is rounded up to one unit.)
|
||
|
||
`FLOAT_TYPE_SIZE'
|
||
A C expression for the size in bits of the type `float' on the
|
||
target machine. If you don't define this, the default is one word.
|
||
|
||
`DOUBLE_TYPE_SIZE'
|
||
A C expression for the size in bits of the type `double' on the
|
||
target machine. If you don't define this, the default is two
|
||
words.
|
||
|
||
`LONG_DOUBLE_TYPE_SIZE'
|
||
A C expression for the size in bits of the type `long double' on
|
||
the target machine. If you don't define this, the default is two
|
||
words.
|
||
|
||
`DEFAULT_SIGNED_CHAR'
|
||
An expression whose value is 1 or 0, according to whether the type
|
||
`char' should be signed or unsigned by default. The user can
|
||
always override this default with the options `-fsigned-char' and
|
||
`-funsigned-char'.
|
||
|
||
`DEFAULT_SHORT_ENUMS'
|
||
A C expression to determine whether to give an `enum' type only as
|
||
many bytes as it takes to represent the range of possible values
|
||
of that type. A nonzero value means to do that; a zero value
|
||
means all `enum' types should be allocated like `int'.
|
||
|
||
If you don't define the macro, the default is 0.
|
||
|
||
`SIZE_TYPE'
|
||
A C expression for a string describing the name of the data type
|
||
to use for size values. The typedef name `size_t' is defined
|
||
using the contents of the string.
|
||
|
||
The string can contain more than one keyword. If so, separate
|
||
them with spaces, and write first any length keyword, then
|
||
`unsigned' if appropriate, and finally `int'. The string must
|
||
exactly match one of the data type names defined in the function
|
||
`init_decl_processing' in the file `c-decl.c'. You may not omit
|
||
`int' or change the order--that would cause the compiler to crash
|
||
on startup.
|
||
|
||
If you don't define this macro, the default is `"long unsigned
|
||
int"'.
|
||
|
||
`PTRDIFF_TYPE'
|
||
A C expression for a string describing the name of the data type
|
||
to use for the result of subtracting two pointers. The typedef
|
||
name `ptrdiff_t' is defined using the contents of the string. See
|
||
`SIZE_TYPE' above for more information.
|
||
|
||
If you don't define this macro, the default is `"long int"'.
|
||
|
||
`WCHAR_TYPE'
|
||
A C expression for a string describing the name of the data type
|
||
to use for wide characters. The typedef name `wchar_t' is defined
|
||
using the contents of the string. See `SIZE_TYPE' above for more
|
||
information.
|
||
|
||
If you don't define this macro, the default is `"int"'.
|
||
|
||
`WCHAR_TYPE_SIZE'
|
||
A C expression for the size in bits of the data type for wide
|
||
characters. This is used in `cpp', which cannot make use of
|
||
`WCHAR_TYPE'.
|
||
|
||
`OBJC_INT_SELECTORS'
|
||
Define this macro if the type of Objective C selectors should be
|
||
`int'.
|
||
|
||
If this macro is not defined, then selectors should have the type
|
||
`struct objc_selector *'.
|
||
|
||
`OBJC_SELECTORS_WITHOUT_LABELS'
|
||
Define this macro if the compiler can group all the selectors
|
||
together into a vector and use just one label at the beginning of
|
||
the vector. Otherwise, the compiler must give each selector its
|
||
own assembler label.
|
||
|
||
On certain machines, it is important to have a separate label for
|
||
each selector because this enables the linker to eliminate
|
||
duplicate selectors.
|
||
|
||
`TARGET_BELL'
|
||
A C constant expression for the integer value for escape sequence
|
||
`\a'.
|
||
|
||
`TARGET_BS'
|
||
`TARGET_TAB'
|
||
`TARGET_NEWLINE'
|
||
C constant expressions for the integer values for escape sequences
|
||
`\b', `\t' and `\n'.
|
||
|
||
`TARGET_VT'
|
||
`TARGET_FF'
|
||
`TARGET_CR'
|
||
C constant expressions for the integer values for escape sequences
|
||
`\v', `\f' and `\r'.
|
||
|
||
|
||
File: gcc.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros
|
||
|
||
Register Usage
|
||
==============
|
||
|
||
This section explains how to describe what registers the target
|
||
machine has, and how (in general) they can be used.
|
||
|
||
The description of which registers a specific instruction can use is
|
||
done with register classes; see *Note Register Classes::. For
|
||
information on using registers to access a stack frame, see *Note Frame
|
||
Registers::. For passing values in registers, see *Note Register
|
||
Arguments::. For returning values in registers, see *Note Scalar
|
||
Return::.
|
||
|
||
* Menu:
|
||
|
||
* Register Basics:: Number and kinds of registers.
|
||
* Allocation Order:: Order in which registers are allocated.
|
||
* Values in Registers:: What kinds of values each reg can hold.
|
||
* Leaf Functions:: Renumbering registers for leaf functions.
|
||
* Stack Registers:: Handling a register stack such as 80387.
|
||
* Obsolete Register Macros:: Macros formerly used for the 80387.
|
||
|
||
|
||
File: gcc.info, Node: Register Basics, Next: Allocation Order, Up: Registers
|
||
|
||
Basic Characteristics of Registers
|
||
----------------------------------
|
||
|
||
`FIRST_PSEUDO_REGISTER'
|
||
Number of hardware registers known to the compiler. They receive
|
||
numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first
|
||
pseudo register's number really is assigned the number
|
||
`FIRST_PSEUDO_REGISTER'.
|
||
|
||
`FIXED_REGISTERS'
|
||
An initializer that says which registers are used for fixed
|
||
purposes all throughout the compiled code and are therefore not
|
||
available for general allocation. These would include the stack
|
||
pointer, the frame pointer (except on machines where that can be
|
||
used as a general register when no frame pointer is needed), the
|
||
program counter on machines where that is considered one of the
|
||
addressable registers, and any other numbered register with a
|
||
standard use.
|
||
|
||
This information is expressed as a sequence of numbers, separated
|
||
by commas and surrounded by braces. The Nth number is 1 if
|
||
register N is fixed, 0 otherwise.
|
||
|
||
The table initialized from this macro, and the table initialized by
|
||
the following one, may be overridden at run time either
|
||
automatically, by the actions of the macro
|
||
`CONDITIONAL_REGISTER_USAGE', or by the user with the command
|
||
options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'.
|
||
|
||
`CALL_USED_REGISTERS'
|
||
Like `FIXED_REGISTERS' but has 1 for each register that is
|
||
clobbered (in general) by function calls as well as for fixed
|
||
registers. This macro therefore identifies the registers that are
|
||
not available for general allocation of values that must live
|
||
across function calls.
|
||
|
||
If a register has 0 in `CALL_USED_REGISTERS', the compiler
|
||
automatically saves it on function entry and restores it on
|
||
function exit, if the register is used within the function.
|
||
|
||
`CONDITIONAL_REGISTER_USAGE'
|
||
Zero or more C statements that may conditionally modify two
|
||
variables `fixed_regs' and `call_used_regs' (both of type `char
|
||
[]') after they have been initialized from the two preceding
|
||
macros.
|
||
|
||
This is necessary in case the fixed or call-clobbered registers
|
||
depend on target flags.
|
||
|
||
You need not define this macro if it has no work to do.
|
||
|
||
If the usage of an entire class of registers depends on the target
|
||
flags, you may indicate this to GCC by using this macro to modify
|
||
`fixed_regs' and `call_used_regs' to 1 for each of the registers
|
||
in the classes which should not be used by GCC. Also define the
|
||
macro `REG_CLASS_FROM_LETTER' to return `NO_REGS' if it is called
|
||
with a letter for a class that shouldn't be used.
|
||
|
||
(However, if this class is not included in `GENERAL_REGS' and all
|
||
of the insn patterns whose constraints permit this class are
|
||
controlled by target switches, then GCC will automatically avoid
|
||
using these registers when the target switches are opposed to
|
||
them.)
|
||
|
||
`NON_SAVING_SETJMP'
|
||
If this macro is defined and has a nonzero value, it means that
|
||
`setjmp' and related functions fail to save the registers, or that
|
||
`longjmp' fails to restore them. To compensate, the compiler
|
||
avoids putting variables in registers in functions that use
|
||
`setjmp'.
|
||
|
||
|
||
File: gcc.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers
|
||
|
||
Order of Allocation of Registers
|
||
--------------------------------
|
||
|
||
`REG_ALLOC_ORDER'
|
||
If defined, an initializer for a vector of integers, containing the
|
||
numbers of hard registers in the order in which GNU CC should
|
||
prefer to use them (from most preferred to least).
|
||
|
||
If this macro is not defined, registers are used lowest numbered
|
||
first (all else being equal).
|
||
|
||
One use of this macro is on machines where the highest numbered
|
||
registers must always be saved and the save-multiple-registers
|
||
instruction supports only sequences of consecutive registers. On
|
||
such machines, define `REG_ALLOC_ORDER' to be an initializer that
|
||
lists the highest numbered allocatable register first.
|
||
|
||
`ORDER_REGS_FOR_LOCAL_ALLOC'
|
||
A C statement (sans semicolon) to choose the order in which to
|
||
allocate hard registers for pseudo-registers local to a basic
|
||
block.
|
||
|
||
Store the desired order of registers in the array
|
||
`reg_alloc_order'. Element 0 should be the register to allocate
|
||
first; element 1, the next register; and so on.
|
||
|
||
The macro body should not assume anything about the contents of
|
||
`reg_alloc_order' before execution of the macro.
|
||
|
||
On most machines, it is not necessary to define this macro.
|
||
|
||
|
||
File: gcc.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers
|
||
|
||
How Values Fit in Registers
|
||
---------------------------
|
||
|
||
This section discusses the macros that describe which kinds of values
|
||
(specifically, which machine modes) each register can hold, and how many
|
||
consecutive registers are needed for a given mode.
|
||
|
||
`HARD_REGNO_NREGS (REGNO, MODE)'
|
||
A C expression for the number of consecutive hard registers,
|
||
starting at register number REGNO, required to hold a value of mode
|
||
MODE.
|
||
|
||
On a machine where all registers are exactly one word, a suitable
|
||
definition of this macro is
|
||
|
||
#define HARD_REGNO_NREGS(REGNO, MODE) \
|
||
((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
|
||
/ UNITS_PER_WORD))
|
||
|
||
`HARD_REGNO_MODE_OK (REGNO, MODE)'
|
||
A C expression that is nonzero if it is permissible to store a
|
||
value of mode MODE in hard register number REGNO (or in several
|
||
registers starting with that one). For a machine where all
|
||
registers are equivalent, a suitable definition is
|
||
|
||
#define HARD_REGNO_MODE_OK(REGNO, MODE) 1
|
||
|
||
It is not necessary for this macro to check for the numbers of
|
||
fixed registers, because the allocation mechanism considers them
|
||
to be always occupied.
|
||
|
||
On some machines, double-precision values must be kept in even/odd
|
||
register pairs. The way to implement that is to define this macro
|
||
to reject odd register numbers for such modes.
|
||
|
||
The minimum requirement for a mode to be OK in a register is that
|
||
the `movMODE' instruction pattern support moves between the
|
||
register and any other hard register for which the mode is OK; and
|
||
that moving a value into the register and back out not alter it.
|
||
|
||
Since the same instruction used to move `SImode' will work for all
|
||
narrower integer modes, it is not necessary on any machine for
|
||
`HARD_REGNO_MODE_OK' to distinguish between these modes, provided
|
||
you define patterns `movhi', etc., to take advantage of this. This
|
||
is useful because of the interaction between `HARD_REGNO_MODE_OK'
|
||
and `MODES_TIEABLE_P'; it is very desirable for all integer modes
|
||
to be tieable.
|
||
|
||
Many machines have special registers for floating point arithmetic.
|
||
Often people assume that floating point machine modes are allowed
|
||
only in floating point registers. This is not true. Any
|
||
registers that can hold integers can safely *hold* a floating
|
||
point machine mode, whether or not floating arithmetic can be done
|
||
on it in those registers. Integer move instructions can be used
|
||
to move the values.
|
||
|
||
On some machines, though, the converse is true: fixed-point machine
|
||
modes may not go in floating registers. This is true if the
|
||
floating registers normalize any value stored in them, because
|
||
storing a non-floating value there would garble it. In this case,
|
||
`HARD_REGNO_MODE_OK' should reject fixed-point machine modes in
|
||
floating registers. But if the floating registers do not
|
||
automatically normalize, if you can store any bit pattern in one
|
||
and retrieve it unchanged without a trap, then any machine mode
|
||
may go in a floating register, so you can define this macro to say
|
||
so.
|
||
|
||
On some machines, such as the Sparc and the Mips, we get better
|
||
code by defining `HARD_REGNO_MODE_OK' to forbid integers in
|
||
floating registers, even though the hardware is capable of
|
||
handling them. This is because transferring values between
|
||
floating registers and general registers is so slow that it is
|
||
better to keep the integer in memory.
|
||
|
||
The primary significance of special floating registers is rather
|
||
that they are the registers acceptable in floating point arithmetic
|
||
instructions. However, this is of no concern to
|
||
`HARD_REGNO_MODE_OK'. You handle it by writing the proper
|
||
constraints for those instructions.
|
||
|
||
On some machines, the floating registers are especially slow to
|
||
access, so that it is better to store a value in a stack frame
|
||
than in such a register if floating point arithmetic is not being
|
||
done. As long as the floating registers are not in class
|
||
`GENERAL_REGS', they will not be used unless some pattern's
|
||
constraint asks for one.
|
||
|
||
`MODES_TIEABLE_P (MODE1, MODE2)'
|
||
A C expression that is nonzero if it is desirable to choose
|
||
register allocation so as to avoid move instructions between a
|
||
value of mode MODE1 and a value of mode MODE2.
|
||
|
||
If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R,
|
||
MODE2)' are ever different for any R, then `MODES_TIEABLE_P (MODE1,
|
||
MODE2)' must be zero.
|
||
|
||
|
||
File: gcc.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers
|
||
|
||
Handling Leaf Functions
|
||
-----------------------
|
||
|
||
On some machines, a leaf function (i.e., one which make no calls)
|
||
can run more efficiently if it does not make its own register window.
|
||
Often this means it is required to receive its arguments in the
|
||
registers where they are passed by the caller, instead of the registers
|
||
where they would normally arrive.
|
||
|
||
The special treatment for leaf functions generally applies only when
|
||
other conditions are met; for example, often they may use only those
|
||
registers for its own variables and temporaries. We use the term "leaf
|
||
function" to mean a function that is suitable for this special
|
||
handling, so that functions with no calls are not necessarily "leaf
|
||
functions".
|
||
|
||
GNU CC assigns register numbers before it knows whether the function
|
||
is suitable for leaf function treatment. So it needs to renumber the
|
||
registers in order to output a leaf function. The following macros
|
||
accomplish this.
|
||
|
||
`LEAF_REGISTERS'
|
||
A C initializer for a vector, indexed by hard register number,
|
||
which contains 1 for a register that is allowable in a candidate
|
||
for leaf function treatment.
|
||
|
||
If leaf function treatment involves renumbering the registers,
|
||
then the registers marked here should be the ones before
|
||
renumbering--those that GNU CC would ordinarily allocate. The
|
||
registers which will actually be used in the assembler code, after
|
||
renumbering, should not be marked with 1 in this vector.
|
||
|
||
Define this macro only if the target machine offers a way to
|
||
optimize the treatment of leaf functions.
|
||
|
||
`LEAF_REG_REMAP (REGNO)'
|
||
A C expression whose value is the register number to which REGNO
|
||
should be renumbered, when a function is treated as a leaf
|
||
function.
|
||
|
||
If REGNO is a register number which should not appear in a leaf
|
||
function before renumbering, then the expression should yield -1,
|
||
which will cause the compiler to abort.
|
||
|
||
Define this macro only if the target machine offers a way to
|
||
optimize the treatment of leaf functions, and registers need to be
|
||
renumbered to do this.
|
||
|
||
`REG_LEAF_ALLOC_ORDER'
|
||
If defined, an initializer for a vector of integers, containing the
|
||
numbers of hard registers in the order in which the GNU CC should
|
||
prefer to use them (from most preferred to least) in a leaf
|
||
function. If this macro is not defined, REG_ALLOC_ORDER is used
|
||
for both non-leaf and leaf-functions.
|
||
|
||
Normally, it is necessary for `FUNCTION_PROLOGUE' and
|
||
`FUNCTION_EPILOGUE' to treat leaf functions specially. It can test the
|
||
C variable `leaf_function' which is nonzero for leaf functions. (The
|
||
variable `leaf_function' is defined only if `LEAF_REGISTERS' is
|
||
defined.)
|
||
|
||
|
||
File: gcc.info, Node: Stack Registers, Next: Obsolete Register Macros, Prev: Leaf Functions, Up: Registers
|
||
|
||
Registers That Form a Stack
|
||
---------------------------
|
||
|
||
There are special features to handle computers where some of the
|
||
"registers" form a stack, as in the 80387 coprocessor for the 80386.
|
||
Stack registers are normally written by pushing onto the stack, and are
|
||
numbered relative to the top of the stack.
|
||
|
||
Currently, GNU CC can only handle one group of stack-like registers,
|
||
and they must be consecutively numbered.
|
||
|
||
`STACK_REGS'
|
||
Define this if the machine has any stack-like registers.
|
||
|
||
`FIRST_STACK_REG'
|
||
The number of the first stack-like register. This one is the top
|
||
of the stack.
|
||
|
||
`LAST_STACK_REG'
|
||
The number of the last stack-like register. This one is the
|
||
bottom of the stack.
|
||
|
||
|
||
File: gcc.info, Node: Obsolete Register Macros, Prev: Stack Registers, Up: Registers
|
||
|
||
Obsolete Macros for Controlling Register Usage
|
||
----------------------------------------------
|
||
|
||
These features do not work very well. They exist because they used
|
||
to be required to generate correct code for the 80387 coprocessor of the
|
||
80386. They are no longer used by that machine description and may be
|
||
removed in a later version of the compiler. Don't use them!
|
||
|
||
`OVERLAPPING_REGNO_P (REGNO)'
|
||
If defined, this is a C expression whose value is nonzero if hard
|
||
register number REGNO is an overlapping register. This means a
|
||
hard register which overlaps a hard register with a different
|
||
number. (Such overlap is undesirable, but occasionally it allows a
|
||
machine to be supported which otherwise could not be.) This macro
|
||
must return nonzero for *all* the registers which overlap each
|
||
other. GNU CC can use an overlapping register only in certain
|
||
limited ways. It can be used for allocation within a basic block,
|
||
and may be spilled for reloading; that is all.
|
||
|
||
If this macro is not defined, it means that none of the hard
|
||
registers overlap each other. This is the usual situation.
|
||
|
||
`INSN_CLOBBERS_REGNO_P (INSN, REGNO)'
|
||
If defined, this is a C expression whose value should be nonzero if
|
||
the insn INSN has the effect of mysteriously clobbering the
|
||
contents of hard register number REGNO. By "mysterious" we mean
|
||
that the insn's RTL expression doesn't describe such an effect.
|
||
|
||
If this macro is not defined, it means that no insn clobbers
|
||
registers mysteriously. This is the usual situation; all else
|
||
being equal, it is best for the RTL expression to show all the
|
||
activity.
|
||
|
||
`PRESERVE_DEATH_INFO_REGNO_P (REGNO)'
|
||
If defined, this is a C expression whose value is nonzero if
|
||
accurate `REG_DEAD' notes are needed for hard register number REGNO
|
||
at the time of outputting the assembler code. When this is so, a
|
||
few optimizations that take place after register allocation and
|
||
could invalidate the death notes are not done when this register is
|
||
involved.
|
||
|
||
You would arrange to preserve death info for a register when some
|
||
of the code in the machine description which is executed to write
|
||
the assembler code looks at the death notes. This is necessary
|
||
only when the actual hardware feature which GNU CC thinks of as a
|
||
register is not actually a register of the usual sort. (It might,
|
||
for example, be a hardware stack.)
|
||
|
||
If this macro is not defined, it means that no death notes need to
|
||
be preserved. This is the usual situation.
|
||
|
||
|