--- gcc/gcc.info-14 2018/04/24 17:51:20 1.1 +++ gcc/gcc.info-14 2018/04/24 18:00:43 1.1.1.4 @@ -1,1090 +1,1183 @@ -This is Info file gcc.info, produced by Makeinfo-1.43 from the input +This is Info file gcc.info, produced by Makeinfo-1.49 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 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 section entitled "GNU General Public License" is 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. +that the sections entitled "GNU General Public License" 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 section entitled "GNU General Public -License" and this permission notice may be included in translations -approved by the Free Software Foundation instead of in the original -English. +versions, except that the sections entitled "GNU General Public +License" 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: Trampolines, Next: Library Calls, Prev: Varargs, Up: Machine Macros +File: gcc.info, Node: Driver, Next: Run-time Target, Up: Target Macros -Trampolines for Nested Functions -================================ +Controlling the Compilation Driver, `gcc' +========================================= - A "trampoline" is a small piece of code that is created at run time -when the address of a nested function is taken. It normally resides on -the stack, in the stack frame of the containing function. These macros -tell GNU CC how to generate code to allocate and initialize a -trampoline. - - The instructions in the trampoline must do two things: load a -constant address into the static chain register, and jump to the real -address of the nested function. On CISC machines such as the m68k, -this requires two instructions, a move immediate and a jump. Then the -two addresses exist in the trampoline as word-long immediate operands. - On RISC machines, it is often necessary to load each address into a -register in two parts. Then pieces of each address form separate -immediate operands. - - The code generated to initialize the trampoline must store the -variable parts--the static chain value and the function address--into -the immediate operands of the instructions. On a CISC machine, this is -simply a matter of copying each address to a memory reference at the -proper offset from the start of the trampoline. On a RISC machine, it -may be necessary to take out pieces of the address and store them -separately. - -`TRAMPOLINE_TEMPLATE (FILE)' - A C statement to output, on the stream FILE, assembler code for a - block of data that contains the constant parts of a trampoline. - This code should not include a label--the label is taken care of - automatically. - -`TRAMPOLINE_SIZE' - A C expression for the size in bytes of the trampoline, as an - integer. - -`TRAMPOLINE_ALIGNMENT' - Alignment required for trampolines, in bits. - - If you don't define this macro, the value of `BIGGEST_ALIGNMENT' - is used for aligning trampolines. - -`INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN)' - A C statement to initialize the variable parts of a trampoline. - ADDR is an RTX for the address of the trampoline; FNADDR is an - RTX for the address of the nested function; STATIC_CHAIN is an - RTX for the static chain value that should be passed to the - function when it is called. - -`ALLOCATE_TRAMPOLINE (FP)' - A C expression to allocate run-time space for a trampoline. The - expression value should be an RTX representing a memory reference - to the space for the trampoline. - - If this macro is not defined, by default the trampoline is - allocated as a stack slot. This default is right for most - machines. The exceptions are machines where it is impossible to - execute instructions in the stack area. On such machines, you - may have to implement a separate stack, using this macro in - conjunction with `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE'. - - FP points to a data structure, a `struct function', which - describes the compilation status of the immediate containing - function of the function which the trampoline is for. Normally - (when `ALLOCATE_TRAMPOLINE' is not defined), the stack slot for - the trampoline is in the stack frame of this containing function. - Other allocation strategies probably must do something analogous - with this information. - - Implementing trampolines is difficult on many machines because they -have separate instruction and data caches. Writing into a stack -location fails to clear the memory in the instruction cache, so when -the program jumps to that location, it executes the old contents. - - Here are two possible solutions. One is to clear the relevant -parts of the instruction cache whenever a trampoline is set up. The -other is to make all trampolines identical, by having them jump to a -standard subroutine. The former technique makes trampoline execution -faster; the latter makes initialization faster. - - To clear the instruction cache when a trampoline is initialized, -define the following macros which describe the shape of the cache. - -`INSN_CACHE_SIZE' - The total size in bytes of the cache. - -`INSN_CACHE_LINE_WIDTH' - The length in bytes of each cache line. The cache is divided - into cache lines which are disjoint slots, each holding a - contiguous chunk of data fetched from memory. Each time data is - brought into the cache, an entire line is read at once. The data - loaded into a cache line is always aligned on a boundary equal to - the line size. - -`INSN_CACHE_DEPTH' - The number of alternative cache lines that can hold any - particular memory location. - - To use a standard subroutine, define the following macro. In -addition, you must make sure that the instructions in a trampoline -fill an entire cache line with identical instructions, or else ensure -that the beginning of the trampoline code is always aligned at the -same point in its cache line. Look in `m68k.h' as a guide. - -`TRANSFER_FROM_TRAMPOLINE' - Define this macro if trampolines need a special subroutine to do - their work. The macro should expand to a series of `asm' - statements which will be compiled with GNU CC. They go in a - library function named `__transfer_from_trampoline'. - - If you need to avoid executing the ordinary prologue code of a - compiled C function when you jump to the subroutine, you can do - so by placing a special label of your own in the assembler code. - Use one `asm' statement to generate an assembler label, and - another to make the label global. Then trampolines can use that - label to jump directly to your special assembler code. +`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'. - -File: gcc.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Machine Macros + Do not define this macro unless you need to override the default + definition. -Implicit Calls to Library Routines -================================== +`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'. -`MULSI3_LIBCALL' - A C string constant giving the name of the function to call for - multiplication of one signed full-word by another. If you do not - define this macro, the default name is used, which is `__mulsi3', - a function defined in `libgcc.a'. - -`DIVSI3_LIBCALL' - A C string constant giving the name of the function to call for - division of one signed full-word by another. If you do not define - this macro, the default name is used, which is `__divsi3', a - function defined in `libgcc.a'. - -`UDIVSI3_LIBCALL' - A C string constant giving the name of the function to call for - division of one unsigned full-word by another. If you do not - define this macro, the default name is used, which is - `__udivsi3', a function defined in `libgcc.a'. - -`MODSI3_LIBCALL' - A C string constant giving the name of the function to call for - the remainder in division of one signed full-word by another. If - you do not define this macro, the default name is used, which is - `__modsi3', a function defined in `libgcc.a'. - -`UMODSI3_LIBCALL' - A C string constant giving the name of the function to call for - the remainder in division of one unsigned full-word by another. - If you do not define this macro, the default name is used, which - is `__umodsi3', a function defined in `libgcc.a'. - -`MULDI3_LIBCALL' - A C string constant giving the name of the function to call for - multiplication of one signed double-word by another. If you do - not define this macro, the default name is used, which is - `__muldi3', a function defined in `libgcc.a'. - -`DIVDI3_LIBCALL' - A C string constant giving the name of the function to call for - division of one signed double-word by another. If you do not - define this macro, the default name is used, which is `__divdi3', - a function defined in `libgcc.a'. - -`UDIVDI3_LIBCALL' - A C string constant giving the name of the function to call for - division of one unsigned full-word by another. If you do not - define this macro, the default name is used, which is - `__udivdi3', a function defined in `libgcc.a'. - -`MODDI3_LIBCALL' - A C string constant giving the name of the function to call for - the remainder in division of one signed double-word by another. - If you do not define this macro, the default name is used, which - is `__moddi3', a function defined in `libgcc.a'. - -`UMODDI3_LIBCALL' - A C string constant giving the name of the function to call for - the remainder in division of one unsigned full-word by another. - If you do not define this macro, the default name is used, which - is `__umoddi3', a function defined in `libgcc.a'. - -`TARGET_MEM_FUNCTIONS' - Define this macro if GNU CC should generate calls to the System V - (and ANSI C) library functions `memcpy' and `memset' rather than - the BSD functions `bcopy' and `bzero'. - -`LIBGCC_NEEDS_DOUBLE' - Define this macro if only `float' arguments cannot be passed to - library routines (so they must be converted to `double'). This - macro affects both how library calls are generated and how the - library routines in `libgcc1.c' accept their arguments. It is - useful on machines where floating and fixed point arguments are - passed differently, such as the i860. - -`FLOAT_ARG_TYPE' - Define this macro to override the type used by the library - routines to pick up arguments of type `float'. (By default, they - use a union of `float' and `int'.) - - The obvious choice would be `float'--but that won't work with - traditional C compilers that expect all arguments declared as - `float' to arrive as `double'. To avoid this conversion, the - library routines ask for the value as some other type and then - treat it as a `float'. - - On some systems, no other type will work for this. For these - systems, you must use `LIBGCC_NEEDS_DOUBLE' instead, to force - conversion of the values `double' before they are passed. - -`FLOATIFY (PASSED-VALUE)' - Define this macro to override the way library routines - redesignate a `float' argument as a `float' instead of the type - it was passed as. The default is an expression which takes the - `float' field of the union. - -`FLOAT_VALUE_TYPE' - Define this macro to override the type used by the library - routines to return values that ought to have type `float'. (By - default, they use `int'.) - - The obvious choice would be `float'--but that won't work with - traditional C compilers gratuitously convert values declared as - `float' into `double'. - -`INTIFY (FLOAT-VALUE)' - Define this macro to override the way the value of a - `float'-returning library routine should be packaged in order to - return it. These functions are actually declared to return type - `FLOAT_VALUE_TYPE' (normally `int'). - - These values can't be returned as type `float' because traditional - C compilers would gratuitously convert the value to a `double'. - - A local variable named `intify' is always available when the macro - `INTIFY' is used. It is a union of a `float' field named `f' and - a field named `i' whose type is `FLOAT_VALUE_TYPE' or `int'. - - If you don't define this macro, the default definition works by - copying the value through that union. - -`SItype' - Define this macro as the name of the data type corresponding to - `SImode' in the system's own C compiler. - - You need not define this macro if that type is `int', as it - usually is. - -`perform_...' - Define these macros to supply explicit C statements to carry out - various arithmetic operations on types `float' and `double' in the - library routines in `libgcc1.c'. See that file for a full list - of these macros and their arguments. - - On most machines, you don't need to define any of these macros, - because the C compiler that comes with the system takes care of - doing them. - -`NEXT_OBJC_RUNTIME' - Define this macro to generate code for Objective C message - sending using the calling convention of the NeXT system. This - calling convention involves passing the object, the selector and - the method arguments all at once to the method-lookup library - function. + Do not define this macro if it does not need to do anything. - The default calling convention passes just the object and the - selector to the lookup function, which returns a pointer to the - method. +`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'. - -File: gcc.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Machine Macros + Do not define this macro if it does not need to do anything. -Addressing Modes -================ +`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. -`HAVE_POST_INCREMENT' - Define this macro if the machine supports post-increment - addressing. - -`HAVE_PRE_INCREMENT' -`HAVE_POST_DECREMENT' -`HAVE_PRE_DECREMENT' - Similar for other kinds of addressing. - -`CONSTANT_ADDRESS_P (X)' - A C expression that is 1 if the RTX X is a constant which is a - valid address. On most machines, this can be defined as - `CONSTANT_P (X)', but a few machines are more restrictive in - which constant addresses are supported. - - `CONSTANT_P' accepts integer-values expressions whose values are - not explicitly known, such as `symbol_ref', `label_ref', and - `high' expressions and `const' arithmetic expressions, in - addition to `const_int' and `const_double' expressions. - -`MAX_REGS_PER_ADDRESS' - A number, the maximum number of registers that can appear in a - valid memory address. Note that it is up to you to specify a - value equal to the maximum number that `GO_IF_LEGITIMATE_ADDRESS' - would ever accept. - -`GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)' - A C compound statement with a conditional `goto LABEL;' executed - if X (an RTX) is a legitimate memory address on the target - machine for a memory operand of mode MODE. - - It usually pays to define several simpler macros to serve as - subroutines for this one. Otherwise it may be too complicated to - understand. - - This macro must exist in two variants: a strict variant and a - non-strict one. The strict variant is used in the reload pass. - It must be defined so that any pseudo-register that has not been - allocated a hard register is considered a memory reference. In - contexts where some kind of register is required, a - pseudo-register with no hard register must be rejected. - - The non-strict variant is used in other passes. It must be - defined to accept all pseudo-registers in every context where - some kind of register is required. - - Compiler source files that want to use the strict variant of this - macro define the macro `REG_OK_STRICT'. You should use an - `#ifdef REG_OK_STRICT' conditional to define the strict variant - in that case and the non-strict variant otherwise. - - Typically among the subroutines used to define - `GO_IF_LEGITIMATE_ADDRESS' are subroutines to check for - acceptable registers for various purposes (one for base - registers, one for index registers, and so on). Then only these - subroutine macros need have two variants; the higher levels of - macros may be the same whether strict or not. - - Normally, constant addresses which are the sum of a `symbol_ref' - and an integer are stored inside a `const' RTX to mark them as - constant. Therefore, there is no need to recognize such sums - specifically as legitimate addresses. Normally you would simply - recognize any `const' as legitimate. - - Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant - sums that are not marked with `const'. It assumes that a naked - `plus' indicates indexing. If so, then you *must* reject such - naked constant sums as illegitimate addresses, so that none of - them will be given to `PRINT_OPERAND_ADDRESS'. - - On some machines, whether a symbolic address is legitimate - depends on the section that the address refers to. On these - machines, define the macro `ENCODE_SECTION_INFO' to store the - information into the `symbol_ref', and then check for it here. - When you see a `const', you will have to look inside it to find - the `symbol_ref' in order to determine the section. *Note - Assembler Format::. - - The best way to modify the name string is by adding text to the - beginning, with suitable punctuation to prevent any ambiguity. - Allocate the new name in `saveable_obstack'. You will have to - modify `ASM_OUTPUT_LABELREF' to remove and decode the added text - and output the name accordingly. - - You can check the information stored here into the `symbol_ref' in - the definitions of `GO_IF_LEGITIMATE_ADDRESS' and - `PRINT_OPERAND_ADDRESS'. - -`REG_OK_FOR_BASE_P (X)' - A C expression that is nonzero if X (assumed to be a `reg' RTX) - is valid for use as a base register. For hard registers, it - should always accept those which the hardware permits and reject - the others. Whether the macro accepts or rejects pseudo - registers must be controlled by `REG_OK_STRICT' as described - above. This usually requires two variant definitions, of which - `REG_OK_STRICT' controls the one actually used. - -`REG_OK_FOR_INDEX_P (X)' - A C expression that is nonzero if X (assumed to be a `reg' RTX) - is valid for use as an index register. - - The difference between an index register and a base register is - that the index register may be scaled. If an address involves - the sum of two registers, neither one of them scaled, then either - one may be labeled the "base" and the other the "index"; but - whichever labeling is used must fit the machine's constraints of - which registers may serve in each capacity. The compiler will - try both labelings, looking for one that is valid, and will - reload one or both registers only if neither labeling works. - -`LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)' - A C compound statement that attempts to replace X with a valid - memory address for an operand of mode MODE. WIN will be a C - statement label elsewhere in the code; the macro definition may - use - - GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN); - - to avoid further processing if the address has become legitimate. - - X will always be the result of a call to `break_out_memory_refs', - and OLDX will be the operand that was given to that function to - produce X. - - The code generated by this macro should not alter the - substructure of X. If it transforms X into a more legitimate - form, it should assign X (which will always be a C variable) a - new value. - - It is not necessary for this macro to come up with a legitimate - address. The compiler has standard ways of doing so in all - cases. In fact, it is safe for this macro to do nothing. But - often a machine-dependent strategy can generate better code. - -`GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)' - A C statement or compound statement with a conditional `goto - LABEL;' executed if memory address X (an RTX) can have different - meanings depending on the machine mode of the memory reference it - is used for. - - Autoincrement and autodecrement addresses typically have - mode-dependent effects because the amount of the increment or - decrement is the size of the operand being addressed. Some - machines have other mode-dependent addresses. Many RISC machines - have no mode-dependent addresses. - - You may assume that ADDR is a valid address for the machine. - -`LEGITIMATE_CONSTANT_P (X)' - A C expression that is nonzero if X is a legitimate constant for - an immediate operand on the target machine. You can assume that - X satisfies `CONSTANT_P', so you need not check this. In fact, - `1' is a suitable definition for this macro on machines where - anything `CONSTANT_P' is valid. - -`LEGITIMATE_PIC_OPERAND_P (X)' - A C expression that is nonzero if X is a legitimate immediate - operand on the target machine when generating position - independent code. You can assume that X satisfies `CONSTANT_P', - so you need not check this. You can also assume FLAG_PIC is - true, so you need not check it either. You need not define this - macro if all constants (including `SYMBOL_REF') can be immediate - operands when generating position independent code. + Do not define this macro if it does not need to do anything. - -File: gcc.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Machine Macros +`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. -Condition Code Status -===================== + 3. The directories specified by the environment variable + `COMPILER_PATH'. - The file `conditions.h' defines a variable `cc_status' to describe -how the condition code was computed (in case the interpretation of the -condition code depends on the instruction that it was set by). This -variable contains the RTL expressions on which the condition code is -currently based, and several standard flags. - - Sometimes additional machine-specific flags must be defined in the -machine description header file. It can also add additional -machine-specific information by defining `CC_STATUS_MDEP'. - -`CC_STATUS_MDEP' - C code for a data type which is used for declaring the `mdep' - component of `cc_status'. It defaults to `int'. - - This macro is not used on machines that do not use `cc0'. - -`CC_STATUS_MDEP_INIT' - A C expression to initialize the `mdep' field to "empty". The - default definition does nothing, since most machines don't use - the field anyway. If you want to use the field, you should - probably define this macro to initialize it. - - This macro is not used on machines that do not use `cc0'. - -`NOTICE_UPDATE_CC (EXP, INSN)' - A C compound statement to set the components of `cc_status' - appropriately for an insn INSN whose body is EXP. It is this - macro's responsibility to recognize insns that set the condition - code as a byproduct of other activity as well as those that - explicitly set `(cc0)'. - - This macro is not used on machines that do not use `cc0'. - - If there are insns that do not set the condition code but do alter - other machine registers, this macro must check to see whether they - invalidate the expressions that the condition code is recorded as - reflecting. For example, on the 68000, insns that store in - address registers do not set the condition code, which means that - usually `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for - such insns. But suppose that the previous insn set the condition - code based on location `a4@(102)' and the current insn stores a - new value in `a4'. Although the condition code is not changed by - this, it will no longer be true that it reflects the contents of - `a4@(102)'. Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' - in this case to say that nothing is known about the condition - code value. - - The definition of `NOTICE_UPDATE_CC' must be prepared to deal - with the results of peephole optimization: insns whose patterns - are `parallel' RTXs containing various `reg', `mem' or constants - which are just the operands. The RTL structure of these insns is - not sufficient to indicate what the insns actually do. What - `NOTICE_UPDATE_CC' should do when it sees one is just to run - `CC_STATUS_INIT'. - - A possible definition of `NOTICE_UPDATE_CC' is to call a function - that looks at an attribute (*note Insn Attributes::.) named, for - example, `cc'. This avoids having detailed information about - patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'. - -`EXTRA_CC_MODES' - A list of names to be used for additional modes for condition code - values in registers (*note Jump Patterns::.). These names are - added to `enum machine_mode' and all have class `MODE_CC'. By - convention, they should start with `CC' and end with `mode'. - - You should only define this macro if your machine does not use - `cc0' and only if additional modes are required. - -`EXTRA_CC_NAMES' - A list of C strings giving the names for the modes listed in - `EXTRA_CC_MODES'. For example, the Sparc defines this macro and - `EXTRA_CC_MODES' as - - #define EXTRA_CC_MODES CC_NOOVmode, CCFPmode - #define EXTRA_CC_NAMES "CC_NOOV", "CCFP" - - This macro is not required if `EXTRA_CC_MODES' is not defined. - -`SELECT_CC_MODE (OP, X)' - Returns a mode from class `MODE_CC' to be used when comparison - operation code OP is applied to rtx X. For example, on the Sparc, - `SELECT_CC_MODE' is defined as (see *note Jump Patterns::. for a - description of the reason for this definition) - - #define SELECT_CC_MODE(OP,X) \ - (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT ? CCFPmode \ - : (GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ - || GET_CODE (X) == NEG) \ - ? CC_NOOVmode : CCmode) + 4. The macro `STANDARD_EXEC_PREFIX'. - This macro is not required if `EXTRA_CC_MODES' is not defined. + 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: Costs, Next: Sections, Prev: Condition Code, Up: Machine Macros +File: gcc.info, Node: Run-time Target, Next: Storage Layout, Prev: Driver, Up: Target Macros + +Run-time Target Specification +============================= -Describing Relative Costs of Operations -======================================= +`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. - These macros let you describe the relative speed of various -operations on the target machine. + LEVEL is the optimization level specified; 2 if -O2 is specified, + 1 if -O is specified, and 0 if neither is specified. -`CONST_COSTS (X, CODE)' - A part of a C `switch' statement that describes the relative costs - of constant RTL expressions. It must contain `case' labels for - expression codes `const_int', `const', `symbol_ref', `label_ref' - and `const_double'. Each case must ultimately reach a `return' - statement to return the relative cost of the use of that kind of - constant value in an expression. The cost may depend on the - precise value of the constant, which is available for examination - in X. - - CODE is the expression code--redundant, since it can be obtained - with `GET_CODE (X)'. - -`RTX_COSTS (X, CODE)' - Like `CONST_COSTS' but applies to nonconstant RTL expressions. - This can be used, for example, to indicate how costly a multiply - instruction is. In writing this macro, you can use the construct - `COSTS_N_INSNS (N)' to specify a cost equal to N fast - instructions. - - This macro is optional; do not define it if the default cost - assumptions are adequate for the target machine. - -`ADDRESS_COST (ADDRESS)' - An expression giving the cost of an addressing mode that contains - ADDRESS. If not defined, the cost is computed from the ADDRESS - expression and the `CONST_COSTS' values. - - For most CISC machines, the default cost is a good approximation - of the true cost of the addressing mode. However, on RISC - machines, all instructions normally have the same length and - execution time. Hence all addresses will have equal costs. - - In cases where more than one form of an address is known, the - form with the lowest cost will be used. If multiple forms have - the same, lowest, cost, the one that is the most complex will be - used. - - For example, suppose an address that is equal to the sum of a - register and a constant is used twice in the same basic block. - When this macro is not defined, the address will be computed in a - register and memory references will be indirect through that - register. On machines where the cost of the addressing mode - containing the sum is no higher than that of a simple indirect - reference, this will produce an additional instruction and - possibly require an additional register. Proper specification of - this macro eliminates this overhead for such machines. - - Similar use of this macro is made in strength reduction of loops. - - ADDRESS need not be valid as an address. In such a case, the cost - is not relevant and can be any value; invalid addresses need not - be assigned a different cost. - - On machines where an address involving more than one register is - as cheap as an address computation involving only one register, - defining `ADDRESS_COST' to reflect this can cause two registers - to be live over a region of code where only one would have been if - `ADDRESS_COST' were not defined in that manner. This effect - should be considered in the definition of this macro. Equivalent - costs should probably only be given to addresses with different - numbers of registers on machines with lots of registers. - - This macro will normally either not be defined or be defined as a - constant. - -`REGISTER_MOVE_COST (FROM, TO)' - A C expression for the cost of moving data from a register in - class FROM to one in class TO. The classes are expressed using - the enumeration values such as `GENERAL_REGS'. A value of 2 is - the default; other values are interpreted relative to that. - - It is not required that the cost always equal 2 when FROM is the - same as TO; on some machines it is expensive to move between - registers if they are not general registers. - - If reload sees an insn consisting of a single `set' between two - hard registers, and if `REGISTER_MOVE_COST' applied to their - classes returns a value of 2, reload does not check to ensure - that the constraints of the insn are met. Setting a cost of - other than 2 will allow reload to verify that the constraints are - met. You should do this if the `movM' pattern's constraints do - not allow such copying. - -`MEMORY_MOVE_COST (M)' - A C expression for the cost of moving data of mode M between a - register and memory. A value of 2 is the default; this cost is - relative to those in `REGISTER_MOVE_COST'. - - If moving between registers and memory is more expensive than - between two registers, you should define this macro to express - the relative cost. - -`BRANCH_COST' - A C expression for the cost of a branch instruction. A value of - 1 is the default; other values are interpreted relative to that. - - Here are additional macros which do not specify precise relative -costs, but only that certain actions are more expensive than GNU CC -would ordinarily expect. - -`SLOW_BYTE_ACCESS' - Define this macro as a C expression which is nonzero if accessing - less than a word of memory (i.e. a `char' or a `short') is no - faster than accessing a word of memory, i.e., if such access - require more than one instruction or if there is no difference in - cost between byte and (aligned) word loads. - - When this macro is not defined, the compiler will access a field - by finding the smallest containing object; when it is defined, a - fullword load will be used if alignment permits. Unless bytes - accesses are faster than word accesses, using word accesses is - preferable since it may eliminate subsequent memory access if - subsequent accesses occur to other fields in the same word of the - structure, but to different bytes. - -`SLOW_ZERO_EXTEND' - Define this macro if zero-extension (of a `char' or `short' to an - `int') can be done faster if the destination is a register that - is known to be zero. - - If you define this macro, you must have instruction patterns that - recognize RTL structures like this: - - (set (strict_low_part (subreg:QI (reg:SI ...) 0)) ...) - - and likewise for `HImode'. - -`SLOW_UNALIGNED_ACCESS' - Define this macro if unaligned accesses have a cost many times - greater than aligned accesses, for example if they are emulated - in a trap handler. - - When this macro is defined, the compiler will act as if - `STRICT_ALIGNMENT' were defined when generating code for block - moves. This can cause significantly more instructions to be - produced. Therefore, do not define this macro if unaligned - accesses only add a cycle or two to the time for a memory access. - -`DONT_REDUCE_ADDR' - Define this macro to inhibit strength reduction of memory - addresses. (On some machines, such strength reduction seems to - do harm rather than good.) - -`MOVE_RATIO' - The number of scalar move insns which should be generated instead - of a string move insn or a library call. Increasing the value - will always make code faster, but eventually incurs high cost in - increased code size. - - If you don't define this, a reasonable default is used. - -`NO_FUNCTION_CSE' - Define this macro if it is as good or better to call a constant - function address than to call an address kept in a register. - -`NO_RECURSIVE_FUNCTION_CSE' - Define this macro if it is as good or better for a function to - call itself with an explicit address than to call an address kept - in a register. + *Do not examine `write_symbols' in this macro!* The debugging + options are not supposed to alter the generated code.  -File: gcc.info, Node: Sections, Next: PIC, Prev: Costs, Up: Machine Macros +File: gcc.info, Node: Storage Layout, Next: Type Layout, Prev: Run-time Target, Up: Target Macros -Dividing the Output into Sections (Texts, Data, ...) -==================================================== +Storage Layout +============== - An object file is divided into sections containing different types -of data. In the most common case, there are three sections: the "text -section", which holds instructions and read-only data; the "data -section", which holds initialized writable data; and the "bss -section", which holds uninitialized data. Some systems have other -kinds of sections. - - The compiler must tell the assembler when to switch sections. These -macros control what commands to output to tell the assembler this. You -can also define additional sections. - -`TEXT_SECTION_ASM_OP' - A C string constant for the assembler operation that should - precede instructions and read-only data. Normally `".text"' is - right. - -`DATA_SECTION_ASM_OP' - A C string constant for the assembler operation to identify the - following data as writable initialized data. Normally `".data"' - is right. - -`SHARED_SECTION_ASM_OP' - If defined, a C string constant for the assembler operation to - identify the following data as shared data. If not defined, - `DATA_SECTION_ASM_OP' will be used. - -`INIT_SECTION_ASM_OP' - If defined, a C string constant for the assembler operation to - identify the following data as initialization code. If not - defined, GNU CC will assume such a section does not exist. - -`EXTRA_SECTIONS' - A list of names for sections other than the standard two, which - are `in_text' and `in_data'. You need not define this macro on a - system with no other sections (that GCC needs to use). - -`EXTRA_SECTION_FUNCTIONS' - One or more functions to be defined in `varasm.c'. These - functions should do jobs analogous to those of `text_section' and - `data_section', for your additional sections. Do not define this - macro if you do not define `EXTRA_SECTIONS'. - -`READONLY_DATA_SECTION' - On most machines, read-only variables, constants, and jump tables - are placed in the text section. If this is not the case on your - machine, this macro should be defined to be the name of a - function (either `data_section' or a function defined in - `EXTRA_SECTIONS') that switches to the section to be used for - read-only items. - - If these items should be placed in the text section, this macro - should not be defined. - -`SELECT_SECTION (EXP, RELOC)' - A C statement or statements to switch to the appropriate section - for output of EXP. You can assume that EXP is either a - `VAR_DECL' node or a constant of some sort. RELOC indicates - whether the initial value of EXP requires link-time relocations. - Select the section by calling `text_section' or one of the - alternatives for other sections. - - Do not define this macro if you put all read-only variables and - constants in the read-only data section (usually the text - section). - -`SELECT_RTX_SECTION (MODE, RTX)' - A C statement or statements to switch to the appropriate section - for output of RTX in mode MODE. You can assume that RTX is some - kind of constant in RTL. The argument MODE is redundant except - in the case of a `const_int' rtx. Select the section by calling - `text_section' or one of the alternatives for other sections. - - Do not define this macro if you put all constants in the read-only - data section. - -`JUMP_TABLES_IN_TEXT_SECTION' - Define this macro if jump tables (for `tablejump' insns) should be - output in the text section, along with the assembler instructions. - Otherwise, the readonly data section is used. - - This macro is irrelevant if there is no separate readonly data - section. - -`ENCODE_SECTION_INFO (DECL)' - Define this macro if references to a symbol must be treated - differently depending on something about the variable or function - named by the symbol (such as what section it is in). - - The macro definition, if any, is executed immediately after the - rtl for DECL has been created and stored in `DECL_RTL (DECL)'. - The value of the rtl will be a `mem' whose address is a - `symbol_ref'. - - The usual thing for this macro to do is to record a flag in the - `symbol_ref' (such as `SYMBOL_REF_FLAG') or to store a modified - name string in the `symbol_ref' (if one bit is not enough - information). + 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. 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. + +`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. + +`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 quanities 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'. + +`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. + +`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. + + 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)' + 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: PIC, Next: Assembler Format, Prev: Sections, Up: Machine Macros +File: gcc.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros -Position Independent Code -========================= +Layout of Source Language Data Types +==================================== - This section describes macros that help implement generation of -position independent code. Simply defining these macros is not enough -to generate valid PIC; you must also add support to the macros -`GO_IF_LEGITIMATE_ADDRESS' and `LEGITIMIZE_ADDRESS', and -`PRINT_OPERAND_ADDRESS' as well. You must modify the definition of -`movsi' to do something appropriate when the source operand contains a -symbolic address. You may also need to alter the handling of switch -statements so that they use relative addresses. - -`PIC_OFFSET_TABLE_REGNUM' - The register number of the register used to address a table of - static data addresses in memory. In some cases this register is - defined by a processor's "application binary interface" (ABI). - When this macro is defined, RTL is generated for this register - once, as with the stack pointer and frame pointer registers. If - this macro is not defined, it is up to the machine-dependent - files to allocate such a register (if necessary). - -`FINALIZE_PIC' - By generating position-independent code, when two different - programs (A and B) share a common library (libC.a), the text of - the library can be shared whether or not the library is linked at - the same address for both programs. In some of these - environments, position-independent code requires not only the use - of different addressing modes, but also special code to enable - the use of these addressing modes. - - The `FINALIZE_PIC' macro serves as a hook to emit these special - codes once the function is being compiled into assembly code, but - not before. (It is not done before, because in the case of - compiling an inline function, it would lead to multiple PIC - prologues being included in functions which used inline functions - and were compiled to assembly language.) + 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: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Machine Macros +File: gcc.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros -Defining the Output Assembler Language -====================================== +Register Usage +============== - This section describes macros whose principal purpose is to -describe how to write instructions in assembler language--rather than -what the instructions do. + 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: -* File Framework:: Structural information for the assembler file. -* Data Output:: Output of constants (numbers, strings, addresses). -* Uninitialized Data:: Output of uninitialized variables. -* Label Output:: Output and generation of labels. -* Constructor Output:: Output of initialization and termination routines. -* Instruction Output:: Output of actual instructions. -* Dispatch Tables:: Output of jump tables. -* Alignment Output:: Pseudo ops for alignment and skipping data. +* 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: File Framework, Next: Data Output, Prev: Assembler Format, Up: Assembler Format +File: gcc.info, Node: Register Basics, Next: Allocation Order, Up: Registers + +Basic Characteristics of Registers +---------------------------------- -The Overall Framework of an Assembler File ------------------------------------------- +`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'. -`ASM_FILE_START (STREAM)' - A C expression which outputs to the stdio stream STREAM some - appropriate text to go at the start of an assembler file. + +File: gcc.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers - Normally this macro is defined to output a line containing - `#NO_APP', which is a comment that has no effect on most - assemblers but tells the GNU assembler that it can save time by - not checking for certain assembler constructs. +Order of Allocation of Registers +-------------------------------- - On systems that use SDB, it is necessary to output certain - commands; see `attasm.h'. +`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. -`ASM_FILE_END (STREAM)' - A C expression which outputs to the stdio stream STREAM some - appropriate text to go at the end of an assembler file. + The macro body should not assume anything about the contents of + `reg_alloc_order' before execution of the macro. - If this macro is not defined, the default is to output nothing - special at the end of the file. Most systems don't require any - definition. + 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 makes 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. - On systems that use SDB, it is necessary to output certain - commands; see `attasm.h'. +`FIRST_STACK_REG' + The number of the first stack-like register. This one is the top + of the stack. -`ASM_IDENTIFY_GCC (FILE)' - A C statement to output assembler commands which will identify - the object file as having been compiled with GNU CC (or another - GNU compiler). - - If you don't define this macro, the string `gcc_compiled.:' is - output. This string is calculated to define a symbol which, on - BSD systems, will never be defined for any other reason. GDB - checks for the presence of this symbol when reading the symbol - table of an executable. - - On non-BSD systems, you must arrange communication with GDB in - some other fashion. If GDB is not used on your system, you can - define this macro with an empty body. - -`ASM_COMMENT_START' - A C string constant describing how to begin a comment in the - target assembler language. The compiler assumes that the comment - will end at the end of the line. - -`ASM_APP_ON' - A C string constant for text to be output before each `asm' - statement or group of consecutive ones. Normally this is - `"#APP"', which is a comment that has no effect on most - assemblers but tells the GNU assembler that it must check the - lines that follow for all valid assembler constructs. - -`ASM_APP_OFF' - A C string constant for text to be output after each `asm' - statement or group of consecutive ones. Normally this is - `"#NO_APP"', which tells the GNU assembler to resume making the - time-saving assumptions that are valid for ordinary compiler - output. - -`ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME)' - A C statement to output COFF information or DWARF debugging - information which indicates that filename NAME is the current - source file to the stdio stream STREAM. - - This macro need not be defined if the standard form of output for - the file format in use is appropriate. - -`ASM_OUTPUT_SOURCE_LINE (STREAM, LINE)' - A C statement to output DBX or SDB debugging information before - code for line number LINE of the current source file to the stdio - stream STREAM. - - This macro need not be defined if the standard form of debugging - information for the debugger in use is appropriate. - -`ASM_OUTPUT_IDENT (STREAM, STRING)' - A C statement to output something to the assembler file to handle - a `#ident' directive containing the text STRING. If this macro - is not defined, nothing is output for a `#ident' directive. - -`OBJC_PROLOGUE' - A C statement to output any assembler statements which are - required to precede any Objective C object definitions or message - sending. The statement is executed only when compiling an - Objective C program. +`LAST_STACK_REG' + The number of the last stack-like register. This one is the + bottom of the stack.  -File: gcc.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format +File: gcc.info, Node: Obsolete Register Macros, Prev: Stack Registers, Up: Registers -Output of Data --------------- +Obsolete Macros for Controlling Register Usage +---------------------------------------------- -`ASM_OUTPUT_LONG_DOUBLE (STREAM, VALUE)' -`ASM_OUTPUT_DOUBLE (STREAM, VALUE)' -`ASM_OUTPUT_FLOAT (STREAM, VALUE)' - A C statement to output to the stdio stream STREAM an assembler - instruction to assemble a floating-point constant of `TFmode', - `DFmode' or `SFmode', respectively, whose value is VALUE. VALUE - will be a C expression of type `REAL_VALUE__TYPE', usually - `double'. - -`ASM_OUTPUT_QUADRUPLE_INT (STREAM, EXP)' -`ASM_OUTPUT_DOUBLE_INT (STREAM, EXP)' -`ASM_OUTPUT_INT (STREAM, EXP)' -`ASM_OUTPUT_SHORT (STREAM, EXP)' -`ASM_OUTPUT_CHAR (STREAM, EXP)' - A C statement to output to the stdio stream STREAM an assembler - instruction to assemble an integer of 16, 8, 4, 2 or 1 bytes, - respectively, whose value is VALUE. The argument EXP will be an - RTL expression which represents a constant value. Use - `output_addr_const (STREAM, EXP)' to output this value as an - assembler expression. - - For sizes larger than `UNITS_PER_WORD', if the action of a macro - would be identical to repeatedly calling the macro corresponding - to a size of `UNITS_PER_WORD', once for each word, you need not - define the macro. - -`ASM_OUTPUT_BYTE (STREAM, VALUE)' - A C statement to output to the stdio stream STREAM an assembler - instruction to assemble a single byte containing the number VALUE. - -`ASM_BYTE_OP' - A C string constant giving the pseudo-op to use for a sequence of - single-byte constants. If this macro is not defined, the default - is `"byte"'. - -`ASM_OUTPUT_ASCII (STREAM, PTR, LEN)' - A C statement to output to the stdio stream STREAM an assembler - instruction to assemble a string constant containing the LEN - bytes at PTR. PTR will be a C expression of type `char *' and - LEN a C expression of type `int'. - - If the assembler has a `.ascii' pseudo-op as found in the - Berkeley Unix assembler, do not define the macro - `ASM_OUTPUT_ASCII'. - -`ASM_OUTPUT_POOL_PROLOGUE (FILE FUNNAME FUNDECL SIZE)' - A C statement to output assembler commands to define the start of - the constant pool for a function. FUNNAME is a string giving the - name of the function. Should the return type of the function be - required, it can be obtained via FUNDECL. SIZE is the size, in - bytes, of the constant pool that will be written immediately - after this call. - - If no constant-pool prefix is required, the usual case, this - macro need not be defined. - -`ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, LABELNO, JUMPTO)' - A C statement (with or without semicolon) to output a constant in - the constant pool, if it needs special treatment. (This macro - need not do anything for RTL expressions that can be output - normally.) - - The argument FILE is the standard I/O stream to output the - assembler code on. X is the RTL expression for the constant to - output, and MODE is the machine mode (in case X is a - `const_int'). ALIGN is the required alignment for the value X; - you should output an assembler directive to force this much - alignment. - - The argument LABELNO is a number to use in an internal label for - the address of this pool entry. The definition of this macro is - responsible for outputting the label definition at the proper - place. Here is how to do this: - - ASM_OUTPUT_INTERNAL_LABEL (FILE, "LC", LABELNO); - - When you output a pool entry specially, you should end with a - `goto' to the label JUMPTO. This will prevent the same pool - entry from being output a second time in the usual manner. - - You need not define this macro if it would do nothing. - -`ASM_OPEN_PAREN' -`ASM_CLOSE_PAREN' - These macros are defined as C string constant, describing the - syntax in the assembler for grouping arithmetic expressions. The - following definitions are correct for most assemblers: + 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.) - #define ASM_OPEN_PAREN "(" - #define ASM_CLOSE_PAREN ")" + If this macro is not defined, it means that no death notes need to + be preserved. This is the usual situation.  \ No newline at end of file