mirror of
https://github.com/pmret/gcc-papermario.git
synced 2024-11-08 11:53:01 +01:00
1208 lines
50 KiB
Plaintext
1208 lines
50 KiB
Plaintext
This is Info file gcc.info, produced by Makeinfo version 1.67 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, 1998
|
||
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: Function Units, Prev: Delay Slots, Up: Insn Attributes
|
||
|
||
Specifying Function Units
|
||
-------------------------
|
||
|
||
On most RISC machines, there are instructions whose results are not
|
||
available for a specific number of cycles. Common cases are
|
||
instructions that load data from memory. On many machines, a pipeline
|
||
stall will result if the data is referenced too soon after the load
|
||
instruction.
|
||
|
||
In addition, many newer microprocessors have multiple function
|
||
units, usually one for integer and one for floating point, and often
|
||
will incur pipeline stalls when a result that is needed is not yet
|
||
ready.
|
||
|
||
The descriptions in this section allow the specification of how much
|
||
time must elapse between the execution of an instruction and the time
|
||
when its result is used. It also allows specification of when the
|
||
execution of an instruction will delay execution of similar instructions
|
||
due to function unit conflicts.
|
||
|
||
For the purposes of the specifications in this section, a machine is
|
||
divided into "function units", each of which execute a specific class
|
||
of instructions in first-in-first-out order. Function units that
|
||
accept one instruction each cycle and allow a result to be used in the
|
||
succeeding instruction (usually via forwarding) need not be specified.
|
||
Classic RISC microprocessors will normally have a single function unit,
|
||
which we can call `memory'. The newer "superscalar" processors will
|
||
often have function units for floating point operations, usually at
|
||
least a floating point adder and multiplier.
|
||
|
||
Each usage of a function units by a class of insns is specified with
|
||
a `define_function_unit' expression, which looks like this:
|
||
|
||
(define_function_unit NAME MULTIPLICITY SIMULTANEITY
|
||
TEST READY-DELAY ISSUE-DELAY
|
||
[CONFLICT-LIST])
|
||
|
||
NAME is a string giving the name of the function unit.
|
||
|
||
MULTIPLICITY is an integer specifying the number of identical units
|
||
in the processor. If more than one unit is specified, they will be
|
||
scheduled independently. Only truly independent units should be
|
||
counted; a pipelined unit should be specified as a single unit. (The
|
||
only common example of a machine that has multiple function units for a
|
||
single instruction class that are truly independent and not pipelined
|
||
are the two multiply and two increment units of the CDC 6600.)
|
||
|
||
SIMULTANEITY specifies the maximum number of insns that can be
|
||
executing in each instance of the function unit simultaneously or zero
|
||
if the unit is pipelined and has no limit.
|
||
|
||
All `define_function_unit' definitions referring to function unit
|
||
NAME must have the same name and values for MULTIPLICITY and
|
||
SIMULTANEITY.
|
||
|
||
TEST is an attribute test that selects the insns we are describing
|
||
in this definition. Note that an insn may use more than one function
|
||
unit and a function unit may be specified in more than one
|
||
`define_function_unit'.
|
||
|
||
READY-DELAY is an integer that specifies the number of cycles after
|
||
which the result of the instruction can be used without introducing any
|
||
stalls.
|
||
|
||
ISSUE-DELAY is an integer that specifies the number of cycles after
|
||
the instruction matching the TEST expression begins using this unit
|
||
until a subsequent instruction can begin. A cost of N indicates an N-1
|
||
cycle delay. A subsequent instruction may also be delayed if an
|
||
earlier instruction has a longer READY-DELAY value. This blocking
|
||
effect is computed using the SIMULTANEITY, READY-DELAY, ISSUE-DELAY,
|
||
and CONFLICT-LIST terms. For a normal non-pipelined function unit,
|
||
SIMULTANEITY is one, the unit is taken to block for the READY-DELAY
|
||
cycles of the executing insn, and smaller values of ISSUE-DELAY are
|
||
ignored.
|
||
|
||
CONFLICT-LIST is an optional list giving detailed conflict costs for
|
||
this unit. If specified, it is a list of condition test expressions to
|
||
be applied to insns chosen to execute in NAME following the particular
|
||
insn matching TEST that is already executing in NAME. For each insn in
|
||
the list, ISSUE-DELAY specifies the conflict cost; for insns not in the
|
||
list, the cost is zero. If not specified, CONFLICT-LIST defaults to
|
||
all instructions that use the function unit.
|
||
|
||
Typical uses of this vector are where a floating point function unit
|
||
can pipeline either single- or double-precision operations, but not
|
||
both, or where a memory unit can pipeline loads, but not stores, etc.
|
||
|
||
As an example, consider a classic RISC machine where the result of a
|
||
load instruction is not available for two cycles (a single "delay"
|
||
instruction is required) and where only one load instruction can be
|
||
executed simultaneously. This would be specified as:
|
||
|
||
(define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 0)
|
||
|
||
For the case of a floating point function unit that can pipeline
|
||
either single or double precision, but not both, the following could be
|
||
specified:
|
||
|
||
(define_function_unit
|
||
"fp" 1 0 (eq_attr "type" "sp_fp") 4 4 [(eq_attr "type" "dp_fp")])
|
||
(define_function_unit
|
||
"fp" 1 0 (eq_attr "type" "dp_fp") 4 4 [(eq_attr "type" "sp_fp")])
|
||
|
||
*Note:* The scheduler attempts to avoid function unit conflicts and
|
||
uses all the specifications in the `define_function_unit' expression.
|
||
It has recently come to our attention that these specifications may not
|
||
allow modeling of some of the newer "superscalar" processors that have
|
||
insns using multiple pipelined units. These insns will cause a
|
||
potential conflict for the second unit used during their execution and
|
||
there is no way of representing that conflict. We welcome any examples
|
||
of how function unit conflicts work in such processors and suggestions
|
||
for their representation.
|
||
|
||
|
||
File: gcc.info, Node: Target Macros, Next: Config, Prev: Machine Desc, Up: Top
|
||
|
||
Target Description Macros
|
||
*************************
|
||
|
||
In addition to the file `MACHINE.md', a machine description includes
|
||
a C header file conventionally given the name `MACHINE.h'. This header
|
||
file defines numerous macros that convey the information about the
|
||
target machine that does not fit into the scheme of the `.md' file.
|
||
The file `tm.h' should be a link to `MACHINE.h'. The header file
|
||
`config.h' includes `tm.h' and most compiler source files include
|
||
`config.h'.
|
||
|
||
* Menu:
|
||
|
||
* Driver:: Controlling how the driver runs the compilation passes.
|
||
* Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'.
|
||
* Storage Layout:: Defining sizes and alignments of data.
|
||
* Type Layout:: Defining sizes and properties of basic user data types.
|
||
* Registers:: Naming and describing the hardware registers.
|
||
* Register Classes:: Defining the classes of hardware registers.
|
||
* Stack and Calling:: Defining which way the stack grows and by how much.
|
||
* Varargs:: Defining the varargs macros.
|
||
* Trampolines:: Code set up at run time to enter a nested function.
|
||
* Library Calls:: Controlling how library routines are implicitly called.
|
||
* Addressing Modes:: Defining addressing modes valid for memory operands.
|
||
* Condition Code:: Defining how insns update the condition code.
|
||
* Costs:: Defining relative costs of different operations.
|
||
* Sections:: Dividing storage into text, data, and other sections.
|
||
* PIC:: Macros for position independent code.
|
||
* Assembler Format:: Defining how to write insns and pseudo-ops to output.
|
||
* Debugging Info:: Defining the format of debugging output.
|
||
* Cross-compilation:: Handling floating point for cross-compilers.
|
||
* Misc:: Everything else.
|
||
|
||
|
||
File: gcc.info, Node: Driver, Next: Run-time Target, Up: Target Macros
|
||
|
||
Controlling the Compilation Driver, `gcc'
|
||
=========================================
|
||
|
||
You can control the compilation driver.
|
||
|
||
`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 as `DEFAULT_SWITCH_TAKES_ARG',
|
||
which handles the standard options properly. You need not define
|
||
`SWITCH_TAKES_ARG' unless you wish to add additional options which
|
||
take arguments. Any redefinition should call
|
||
`DEFAULT_SWITCH_TAKES_ARG' and then check for additional options.
|
||
|
||
`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 as
|
||
`DEFAULT_WORD_SWITCH_TAKES_ARG', which handles the standard options
|
||
properly. You need not define `WORD_SWITCH_TAKES_ARG' unless you
|
||
wish to add additional options which take arguments. Any
|
||
redefinition should call `DEFAULT_WORD_SWITCH_TAKES_ARG' and then
|
||
check for additional options.
|
||
|
||
`SWITCHES_NEED_SPACES'
|
||
A string-valued C expression which enumerates the options for which
|
||
the linker needs a space between the option and its argument.
|
||
|
||
If this macro is not defined, the default value is `""'.
|
||
|
||
`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.
|
||
|
||
`NO_BUILTIN_SIZE_TYPE'
|
||
If this macro is defined, the preprocessor will not define the
|
||
builtin macro `__SIZE_TYPE__'. The macro `__SIZE_TYPE__' must
|
||
then be defined by `CPP_SPEC' instead.
|
||
|
||
This should be defined if `SIZE_TYPE' depends on target dependent
|
||
flags which are not accessible to the preprocessor. Otherwise, it
|
||
should not be defined.
|
||
|
||
`NO_BUILTIN_PTRDIFF_TYPE'
|
||
If this macro is defined, the preprocessor will not define the
|
||
builtin macro `__PTRDIFF_TYPE__'. The macro `__PTRDIFF_TYPE__'
|
||
must then be defined by `CPP_SPEC' instead.
|
||
|
||
This should be defined if `PTRDIFF_TYPE' depends on target
|
||
dependent flags which are not accessible to the preprocessor.
|
||
Otherwise, it should not be defined.
|
||
|
||
`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'.
|
||
|
||
`LIBGCC_SPEC'
|
||
Another C string constant that tells the GNU CC driver program how
|
||
and when to place a reference to `libgcc.a' into the linker
|
||
command line. This constant is placed both before and after the
|
||
value of `LIB_SPEC'.
|
||
|
||
If this macro is not defined, the GNU CC driver provides a default
|
||
that passes the string `-lgcc' to the linker unless the `-shared'
|
||
option is specified.
|
||
|
||
`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.
|
||
|
||
`EXTRA_SPECS'
|
||
Define this macro to provide additional specifications to put in
|
||
the `specs' file that can be used in various specifications like
|
||
`CC1_SPEC'.
|
||
|
||
The definition should be an initializer for an array of structures,
|
||
containing a string constant, that defines the specification name,
|
||
and a string constant that provides the specification.
|
||
|
||
Do not define this macro if it does not need to do anything.
|
||
|
||
`EXTRA_SPECS' is useful when an architecture contains several
|
||
related targets, which have various `..._SPECS' which are similar
|
||
to each other, and the maintainer would like one central place to
|
||
keep these definitions.
|
||
|
||
For example, the PowerPC System V.4 targets use `EXTRA_SPECS' to
|
||
define either `_CALL_SYSV' when the System V calling sequence is
|
||
used or `_CALL_AIX' when the older AIX-based calling sequence is
|
||
used.
|
||
|
||
The `config/rs6000/rs6000.h' target file defines:
|
||
|
||
#define EXTRA_SPECS \
|
||
{ "cpp_sysv_default", CPP_SYSV_DEFAULT },
|
||
|
||
#define CPP_SYS_DEFAULT ""
|
||
|
||
The `config/rs6000/sysv.h' target file defines:
|
||
#undef CPP_SPEC
|
||
#define CPP_SPEC \
|
||
"%{posix: -D_POSIX_SOURCE } \
|
||
%{mcall-sysv: -D_CALL_SYSV } %{mcall-aix: -D_CALL_AIX } \
|
||
%{!mcall-sysv: %{!mcall-aix: %(cpp_sysv_default) }} \
|
||
%{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}"
|
||
|
||
#undef CPP_SYSV_DEFAULT
|
||
#define CPP_SYSV_DEFAULT "-D_CALL_SYSV"
|
||
|
||
while the `config/rs6000/eabiaix.h' target file defines
|
||
`CPP_SYSV_DEFAULT' as:
|
||
|
||
#undef CPP_SYSV_DEFAULT
|
||
#define CPP_SYSV_DEFAULT "-D_CALL_AIX"
|
||
|
||
`LINK_LIBGCC_SPECIAL'
|
||
Define this macro if the driver program should find the library
|
||
`libgcc.a' itself and should not pass `-L' options to the linker.
|
||
If you do not define this macro, the driver program will pass the
|
||
argument `-lgcc' to tell the linker to do the search and will pass
|
||
`-L' options to it.
|
||
|
||
`LINK_LIBGCC_SPECIAL_1'
|
||
Define this macro if the driver program should find the library
|
||
`libgcc.a'. If you do not define this macro, the driver program
|
||
will pass the argument `-lgcc' to tell the linker to do the search.
|
||
This macro is similar to `LINK_LIBGCC_SPECIAL', except that it does
|
||
not affect `-L' options.
|
||
|
||
`MULTILIB_DEFAULTS'
|
||
Define this macro as a C expression for the initializer of an
|
||
array of string to tell the driver program which options are
|
||
defaults for this target and thus do not need to be handled
|
||
specially when using `MULTILIB_OPTIONS'.
|
||
|
||
Do not define this macro if `MULTILIB_OPTIONS' is not defined in
|
||
the target makefile fragment or if none of the options listed in
|
||
`MULTILIB_OPTIONS' are set by default. *Note Target Fragment::.
|
||
|
||
`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.
|
||
|
||
`INIT_ENVIRONMENT'
|
||
Define this macro as a C string constant if you wish to set
|
||
environment variables for programs called by the driver, such as
|
||
the assembler and loader. The driver passes the value of this
|
||
macro to `putenv' to initialize the necessary environment
|
||
variables.
|
||
|
||
`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.
|
||
|
||
`STANDARD_INCLUDE_COMPONENT'
|
||
The "component" corresponding to `STANDARD_INCLUDE_DIR'. See
|
||
`INCLUDE_DEFAULTS', below, for the description of components. If
|
||
you do not define this macro, no component is used.
|
||
|
||
`INCLUDE_DEFAULTS'
|
||
Define this macro if you wish to override the entire default
|
||
search path for include files. For a native compiler, the default
|
||
search path usually consists of `GCC_INCLUDE_DIR',
|
||
`LOCAL_INCLUDE_DIR', `SYSTEM_INCLUDE_DIR',
|
||
`GPLUSPLUS_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition,
|
||
`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 four elements: the directory name (a
|
||
string constant), the component name, and flag for C++-only
|
||
directories, and a flag showing that the includes in the directory
|
||
don't need to be wrapped in `extern `C'' when compiling C++. Mark
|
||
the end of the array with a null element.
|
||
|
||
The component name denotes what GNU package the include file is
|
||
part of, if any, in all upper-case letters. For example, it might
|
||
be `GCC' or `BINUTILS'. If the package is part of the a
|
||
vendor-supplied operating system, code the component name as `0'.
|
||
|
||
For example, here is the definition used for VAX/VMS:
|
||
|
||
#define INCLUDE_DEFAULTS \
|
||
{ \
|
||
{ "GNU_GXX_INCLUDE:", "G++", 1, 1}, \
|
||
{ "GNU_CC_INCLUDE:", "GCC", 0, 0}, \
|
||
{ "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \
|
||
{ ".", 0, 0, 0}, \
|
||
{ 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' (native only, cross compilers do not use this).
|
||
|
||
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
|
||
=============================
|
||
|
||
Here are run-time target specifications.
|
||
|
||
`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.
|
||
|
||
`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.
|
||
|
||
You should not use this macro to change options that are not
|
||
machine-specific. These should uniformly selected by the same
|
||
optimization level on all supported machines. Use this macro to
|
||
enable machine-specific optimizations.
|
||
|
||
*Do not examine `write_symbols' in this macro!* The debugging
|
||
options are not supposed to alter the generated code.
|
||
|
||
`CAN_DEBUG_WITHOUT_FP'
|
||
Define this macro if debugging can be performed even without a
|
||
frame pointer. If this macro is defined, GNU CC will turn on the
|
||
`-fomit-frame-pointer' option whenever `-O' is specified.
|
||
|
||
|
||
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 have the value 1 if the most significant bit
|
||
in a byte has the lowest number; otherwise define it to have the
|
||
value zero. This means that bit-field instructions count from the
|
||
most significant bit. If the machine has no bit-field
|
||
instructions, then this must still be defined, but it doesn't
|
||
matter which value it is defined to. This macro need not be a
|
||
constant.
|
||
|
||
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 have the value 1 if the most significant byte
|
||
in a word has the lowest number. This macro need not be a
|
||
constant.
|
||
|
||
`WORDS_BIG_ENDIAN'
|
||
Define this macro to have the value 1 if, in a multiword object,
|
||
the most significant word has the lowest number. This applies to
|
||
both memory locations and registers; GNU CC fundamentally assumes
|
||
that the order of words in memory is the same as the order in
|
||
registers. This macro need not be a constant.
|
||
|
||
`LIBGCC2_WORDS_BIG_ENDIAN'
|
||
Define this macro if WORDS_BIG_ENDIAN is not constant. This must
|
||
be a constant value with the same meaning as WORDS_BIG_ENDIAN,
|
||
which will be used only when compiling libgcc2.c. Typically the
|
||
value will be set based on preprocessor defines.
|
||
|
||
`FLOAT_WORDS_BIG_ENDIAN'
|
||
Define this macro to have the value 1 if `DFmode', `XFmode' or
|
||
`TFmode' floating point numbers are stored in memory with the word
|
||
containing the sign bit at the lowest address; otherwise define it
|
||
to have the value 0. This macro need not be a constant.
|
||
|
||
You need not define this macro if the ordering is the same as for
|
||
multi-word integers.
|
||
|
||
`BITS_PER_UNIT'
|
||
Define this macro to be the 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.
|
||
|
||
`MIN_UNITS_PER_WORD'
|
||
Minimum number of units in a word. If this is undefined, the
|
||
default is `UNITS_PER_WORD'. Otherwise, it is the constant value
|
||
that is the smallest value that `UNITS_PER_WORD' can have at
|
||
run-time.
|
||
|
||
`POINTER_SIZE'
|
||
Width of a pointer, in bits. You must specify a value no wider
|
||
than the width of `Pmode'. If it is not equal to the width of
|
||
`Pmode', you must define `POINTERS_EXTEND_UNSIGNED'.
|
||
|
||
`POINTERS_EXTEND_UNSIGNED'
|
||
A C expression whose value is nonzero if pointers that need to be
|
||
extended from being `POINTER_SIZE' bits wide to `Pmode' are
|
||
sign-extended and zero if they are zero-extended.
|
||
|
||
You need not define this macro if the `POINTER_SIZE' is equal to
|
||
the width of `Pmode'.
|
||
|
||
`PROMOTE_MODE (M, UNSIGNEDP, TYPE)'
|
||
A macro to update M and UNSIGNEDP when an object whose type is
|
||
TYPE and which has the specified mode and signedness is to be
|
||
stored in a register. This macro is only called when TYPE is a
|
||
scalar type.
|
||
|
||
On most RISC machines, which only have operations that operate on
|
||
a full register, define this macro to set M to `word_mode' if M is
|
||
an integer mode narrower than `BITS_PER_WORD'. In most cases,
|
||
only integer modes should be widened because wider-precision
|
||
floating-point operations are usually more expensive than their
|
||
narrower counterparts.
|
||
|
||
For most machines, the macro definition does not change UNSIGNEDP.
|
||
However, some machines, have instructions that preferentially
|
||
handle either signed or unsigned quantities of certain modes. For
|
||
example, on the DEC Alpha, 32-bit loads from memory and 32-bit add
|
||
instructions sign-extend the result to 64 bits. On such machines,
|
||
set UNSIGNEDP according to which kind of extension is more
|
||
efficient.
|
||
|
||
Do not define this macro if it would never modify M.
|
||
|
||
`PROMOTE_FUNCTION_ARGS'
|
||
Define this macro if the promotion described by `PROMOTE_MODE'
|
||
should also be done for outgoing function arguments.
|
||
|
||
`PROMOTE_FUNCTION_RETURN'
|
||
Define this macro if the promotion described by `PROMOTE_MODE'
|
||
should also be done for the return value of functions.
|
||
|
||
If this macro is defined, `FUNCTION_VALUE' must perform the same
|
||
promotions done by `PROMOTE_MODE'.
|
||
|
||
`PROMOTE_FOR_CALL_ONLY'
|
||
Define this macro if the promotion described by `PROMOTE_MODE'
|
||
should *only* be performed for outgoing function arguments or
|
||
function return values, as specified by `PROMOTE_FUNCTION_ARGS'
|
||
and `PROMOTE_FUNCTION_RETURN', respectively.
|
||
|
||
`PARM_BOUNDARY'
|
||
Normal alignment required for function parameters on the stack, in
|
||
bits. All stack parameters receive at 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.
|
||
|
||
`MINIMUM_ATOMIC_ALIGNMENT'
|
||
If defined, the smallest alignment, in bits, that can be given to
|
||
an object that can be referenced in one operation, without
|
||
disturbing any nearby object. Normally, this is `BITS_PER_UNIT',
|
||
but may be larger on machines that don't have byte or half-word
|
||
store operations.
|
||
|
||
`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.
|
||
|
||
`ADJUST_FIELD_ALIGN (FIELD, COMPUTED)'
|
||
An expression for the alignment of a structure field FIELD if the
|
||
alignment computed in the usual way is COMPUTED. GNU CC uses this
|
||
value instead of the value in `BIGGEST_ALIGNMENT' or
|
||
`BIGGEST_FIELD_ALIGNMENT', if defined, 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.
|
||
|
||
If your aim is to make GNU CC use the same conventions for laying
|
||
out bitfields as are used by another compiler, here is how to
|
||
investigate what the other compiler does. Compile and run this
|
||
program:
|
||
|
||
struct foo1
|
||
{
|
||
char x;
|
||
char :0;
|
||
char y;
|
||
};
|
||
|
||
struct foo2
|
||
{
|
||
char x;
|
||
int :0;
|
||
char y;
|
||
};
|
||
|
||
main ()
|
||
{
|
||
printf ("Size of foo1 is %d\n",
|
||
sizeof (struct foo1));
|
||
printf ("Size of foo2 is %d\n",
|
||
sizeof (struct foo2));
|
||
exit (0);
|
||
}
|
||
|
||
If this prints 2 and 5, then the compiler's behavior is what you
|
||
would get from `PCC_BITFIELD_TYPE_MATTERS'.
|
||
|
||
`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, OVERFLOW)'
|
||
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 a mode of class `MODE_FLOAT'. OVERFLOW
|
||
is nonzero if the value is already known to be out of range.
|
||
|
||
If VALUE is not valid or if OVERFLOW is nonzero, you should set
|
||
OVERFLOW to 1 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.
|
||
|
||
The ordering of the component words of floating point values
|
||
stored in memory is controlled by `FLOAT_WORDS_BIG_ENDIAN' for the
|
||
target machine and `HOST_FLOAT_WORDS_BIG_ENDIAN' for the host.
|
||
|
||
`DEFAULT_VTABLE_THUNKS'
|
||
GNU CC supports two ways of implementing C++ vtables: traditional
|
||
or with so-called "thunks". The flag `-fvtable-thunk' chooses
|
||
between them. Define this macro to be a C expression for the
|
||
default value of that flag. If `DEFAULT_VTABLE_THUNKS' is 0, GNU
|
||
CC uses the traditional implementation by default. The "thunk"
|
||
implementation is more efficient (especially if you have provided
|
||
an implementation of `ASM_OUTPUT_MI_THUNK', see *Note Function
|
||
Entry::), but is not binary compatible with code compiled using
|
||
the traditional implementation. If you are writing a new ports,
|
||
define `DEFAULT_VTABLE_THUNKS' to 1.
|
||
|
||
If you do not define this macro, the default for `-fvtable-thunk'
|
||
is 0.
|
||
|
||
|
||
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.
|
||
|
||
`MAX_INT_TYPE_SIZE'
|
||
Maximum number for the size in bits of the type `int' on the target
|
||
machine. If this is undefined, the default is `INT_TYPE_SIZE'.
|
||
Otherwise, it is the constant value that is the largest value that
|
||
`INT_TYPE_SIZE' can have at run-time. This is used in `cpp'.
|
||
|
||
`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.
|
||
|
||
`MAX_LONG_TYPE_SIZE'
|
||
Maximum number for the size in bits of the type `long' on the
|
||
target machine. If this is undefined, the default is
|
||
`LONG_TYPE_SIZE'. Otherwise, it is the constant value that is the
|
||
largest value that `LONG_TYPE_SIZE' can have at run-time. This is
|
||
used in `cpp'.
|
||
|
||
`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. If you want to support GNU Ada on your machine, the value
|
||
of macro must be at least 64.
|
||
|
||
`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.)
|
||
|
||
`MAX_CHAR_TYPE_SIZE'
|
||
Maximum number for the size in bits of the type `char' on the
|
||
target machine. If this is undefined, the default is
|
||
`CHAR_TYPE_SIZE'. Otherwise, it is the constant value that is the
|
||
largest value that `CHAR_TYPE_SIZE' can have at run-time. This is
|
||
used in `cpp'.
|
||
|
||
`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.
|
||
|
||
`WIDEST_HARDWARE_FP_SIZE'
|
||
A C expression for the size in bits of the widest floating-point
|
||
format supported by the hardware. If you define this macro, you
|
||
must specify a value less than or equal to the value of
|
||
`LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the
|
||
value of `LONG_DOUBLE_TYPE_SIZE' is the default.
|
||
|
||
`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'.
|
||
|
||
`MAX_WCHAR_TYPE_SIZE'
|
||
Maximum number for the size in bits of the data type for wide
|
||
characters. If this is undefined, the default is
|
||
`WCHAR_TYPE_SIZE'. Otherwise, it is the constant value that is the
|
||
largest value that `WCHAR_TYPE_SIZE' can have at run-time. This is
|
||
used in `cpp'.
|
||
|
||
`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'.
|
||
|