--- gcc/gcc.info-15 2018/04/24 17:51:27 1.1 +++ gcc/gcc.info-15 2018/04/24 17:57:27 1.1.1.3 @@ -1,1120 +1,930 @@ -This is Info file gcc.info, produced by Makeinfo-1.43 from the input +This is Info file gcc.info, produced by Makeinfo-1.47 from the input file gcc.texi. This file documents the use and the internals of the GNU compiler. Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc. - Permission is granted to make and distribute verbatim copies of -this manual provided the copyright notice and this permission notice -are preserved on all copies. + Permission is granted to 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 "Boycott" +are included exactly as in the original, and provided that the entire +resulting derived work is distributed under the terms of a permission +notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified -versions, except that the 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 "Boycott", and this permission notice, may be included in +translations approved by the Free Software Foundation instead of in the +original English.  -File: gcc.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format +File: gcc.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling -Output of Uninitialized Variables ---------------------------------- +Function Entry and Exit +----------------------- - Each of the macros in this section is used to do the whole job of -outputting a single uninitialized variable. + This section describes the macros that output function entry +("prologue") and exit ("epilogue") code. -`ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED)' - A C statement (sans semicolon) to output to the stdio stream - STREAM the assembler definition of a common-label named NAME - whose size is SIZE bytes. The variable ROUNDED is the size - rounded up to whatever alignment the caller wants. - - Use the expression `assemble_name (STREAM, NAME)' to output the - name itself; before and after that, output the additional - assembler syntax for defining the name, and a newline. - - This macro controls how the assembler definitions of uninitialized - global variables are output. - -`ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT)' - Like `ASM_OUTPUT_COMMON' except takes the required alignment as a - separate, explicit argument. If you define this macro, it is - used in place of `ASM_OUTPUT_COMMON', and gives you more - flexibility in handling the required alignment of the variable. - -`ASM_OUTPUT_SHARED_COMMON (STREAM, NAME, SIZE, ROUNDED)' - If defined, it is similar to `ASM_OUTPUT_COMMON', except that it - is used when NAME is shared. If not defined, `ASM_OUTPUT_COMMON' - will be used. - -`ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED)' - A C statement (sans semicolon) to output to the stdio stream - STREAM the assembler definition of a local-common-label named - NAME whose size is SIZE bytes. The variable ROUNDED is the size - rounded up to whatever alignment the caller wants. - - Use the expression `assemble_name (STREAM, NAME)' to output the - name itself; before and after that, output the additional - assembler syntax for defining the name, and a newline. - - This macro controls how the assembler definitions of uninitialized - static variables are output. - -`ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT)' - Like `ASM_OUTPUT_LOCAL' except takes the required alignment as a - separate, explicit argument. If you define this macro, it is - used in place of `ASM_OUTPUT_LOCAL', and gives you more - flexibility in handling the required alignment of the variable. - -`ASM_OUTPUT_SHARED_LOCAL (STREAM, NAME, SIZE, ROUNDED)' - If defined, it is similar to `ASM_OUTPUT_LOCAL', except that it - is used when NAME is shared. If not defined, `ASM_OUTPUT_LOCAL' - will be used. +`FUNCTION_PROLOGUE (FILE, SIZE)' + A C compound statement that outputs the assembler code for entry + to a function. The prologue is responsible for setting up the + stack frame, initializing the frame pointer register, saving + registers that must be saved, and allocating SIZE additional bytes + of storage for the local variables. SIZE is an integer. FILE is + a stdio stream to which the assembler code should be output. + + The label for the beginning of the function need not be output by + this macro. That has already been done when the macro is run. + + To determine which registers to save, the macro can refer to the + array `regs_ever_live': element R is nonzero if hard register R is + used anywhere within the function. This implies the function + prologue should save register R, provided it is not one of the + call-used registers. (`FUNCTION_EPILOGUE' must likewise use + `regs_ever_live'.) + + On machines that have "register windows", the function entry code + does not save on the stack the registers that are in the windows, + even if they are supposed to be preserved by function calls; + instead it takes appropriate steps to "push" the register stack, + if any non-call-used registers are used in the function. + + On machines where functions may or may not have frame-pointers, the + function entry code must vary accordingly; it must set up the frame + pointer if one is wanted, and not otherwise. To determine whether + a frame pointer is in wanted, the macro can refer to the variable + `frame_pointer_needed'. The variable's value will be 1 at run + time in a function that needs a frame pointer. *Note + Elimination::. + + The function entry code is responsible for allocating any stack + space required for the function. This stack space consists of the + regions listed below. In most cases, these regions are allocated + in the order listed, with the last listed region closest to the + top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is + defined, and the highest address if it is not defined). You can + use a different order for a machine if doing so is more convenient + or required for compatibility reasons. Except in cases where + required by standard or by a debugger, there is no reason why the + stack layout used by GCC need agree with that used by other + compilers for a machine. + + * A region of `current_function_pretend_args_size' bytes of + uninitialized space just underneath the first argument + arriving on the stack. (This may not be at the very start of + the allocated stack region if the calling sequence has pushed + anything else since pushing the stack arguments. But + usually, on such machines, nothing else has been pushed yet, + because the function prologue itself does all the pushing.) + This region is used on machines where an argument may be + passed partly in registers and partly in memory, and, in some + cases to support the features in `varargs.h' and `stdargs.h'. + + * An area of memory used to save certain registers used by the + function. The size of this area, which may also include space + for such things as the return address and pointers to + previous stack frames, is machine-specific and usually + depends on which registers have been used in the function. + Machines with register windows often do not require a save + area. + + * A region of at least SIZE bytes, possibly rounded up to an + allocation boundary, to contain the local variables of the + function. On some machines, this region and the save area + may occur in the opposite order, with the save area closer to + the top of the stack. + + * Optionally, in the case that `ACCUMULATE_OUTGOING_ARGS' is + defined, a region of `current_function_outgoing_args_size' + bytes to be used for outgoing argument lists of the function. + *Note Stack Arguments::. + + Normally, it is necessary for `FUNCTION_PROLOGUE' and + `FUNCTION_EPILOGUE' to treat leaf functions specially. The C + variable `leaf_function' is nonzero for such a function. + +`EXIT_IGNORE_STACK' + Define this macro as a C expression that is nonzero if the return + instruction or the function epilogue ignores the value of the stack + pointer; in other words, if it is safe to delete an instruction to + adjust the stack pointer before a return from the function. + + Note that this macro's value is relevant only for functions for + which frame pointers are maintained. It is never safe to delete a + final stack adjustment in a function that has no frame pointer, + and the compiler knows this regardless of `EXIT_IGNORE_STACK'. + +`FUNCTION_EPILOGUE (FILE, SIZE)' + A C compound statement that outputs the assembler code for exit + from a function. The epilogue is responsible for restoring the + saved registers and stack pointer to their values when the + function was called, and returning control to the caller. This + macro takes the same arguments as the macro `FUNCTION_PROLOGUE', + and the registers to restore are determined from `regs_ever_live' + and `CALL_USED_REGISTERS' in the same way. + + On some machines, there is a single instruction that does all the + work of returning from the function. On these machines, give that + instruction the name `return' and do not define the macro + `FUNCTION_EPILOGUE' at all. + + Do not define a pattern named `return' if you want the + `FUNCTION_EPILOGUE' to be used. If you want the target switches + to control whether return instructions or epilogues are used, + define a `return' pattern with a validity condition that tests the + target switches appropriately. If the `return' pattern's validity + condition is false, epilogues will be used. + + On machines where functions may or may not have frame-pointers, the + function exit code must vary accordingly. Sometimes the code for + these two cases is completely different. To determine whether a + frame pointer is in wanted, the macro can refer to the variable + `frame_pointer_needed'. The variable's value will be 1 at run + time in a function that needs a frame pointer. + + Normally, it is necessary for `FUNCTION_PROLOGUE' and + `FUNCTION_EPILOGUE' to treat leaf functions specially. The C + variable `leaf_function' is nonzero for such a function. *Note + Leaf Functions::. + + On some machines, some functions pop their arguments on exit while + others leave that for the caller to do. For example, the 68020 + when given `-mrtd' pops arguments in functions that take a fixed + number of arguments. + + Your definition of the macro `RETURN_POPS_ARGS' decides which + functions pop their own arguments. `FUNCTION_EPILOGUE' needs to + know what was decided. The variable `current_function_pops_args' + is the number of bytes of its arguments that a function should pop. + *Note Scalar Return::. + +`DELAY_SLOTS_FOR_EPILOGUE' + Define this macro if the function epilogue contains delay slots to + which instructions from the rest of the function can be "moved". + The definition should be a C expression whose value is an integer + representing the number of delay slots there. + +`ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)' + A C expression that returns 1 if INSN can be placed in delay slot + number N of the epilogue. + + The argument N is an integer which identifies the delay slot now + being considered (since different slots may have different rules of + eligibility). It is never negative and is always less than the + number of epilogue delay slots (what `DELAY_SLOTS_FOR_EPILOGUE' + returns). If you reject a particular insn for a given delay slot, + in principle, it may be reconsidered for a subsequent delay slot. + Also, other insns may (at least in principle) be considered for + the so far unfilled delay slot. + + The insns accepted to fill the epilogue delay slots are put in an + RTL list made with `insn_list' objects, stored in the variable + `current_function_epilogue_delay_list'. The insn for the first + delay slot comes first in the list. Your definition of the macro + `FUNCTION_EPILOGUE' should fill the delay slots by outputting the + insns in this list, usually by calling `final_scan_insn'. - -File: gcc.info, Node: Label Output, Next: Constructor Output, Prev: Uninitialized Data, Up: Assembler Format - -Output and Generation of Labels -------------------------------- - -`ASM_OUTPUT_LABEL (STREAM, NAME)' - A C statement (sans semicolon) to output to the stdio stream - STREAM the assembler definition of a label named NAME. Use the - expression `assemble_name (STREAM, NAME)' to output the name - itself; before and after that, output the additional assembler - syntax for defining the name, and a newline. - -`ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL)' - A C statement (sans semicolon) to output to the stdio stream - STREAM any text necessary for declaring the name NAME of a - function which is being defined. This macro is responsible for - outputting the label definition (perhaps using - `ASM_OUTPUT_LABEL'). The argument DECL is the `FUNCTION_DECL' - tree node representing the function. - - If this macro is not defined, then the function name is defined - in the usual manner as a label (by means of `ASM_OUTPUT_LABEL'). - -`ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL)' - A C statement (sans semicolon) to output to the stdio stream - STREAM any text necessary for declaring the size of a function - which is being defined. The argument NAME is the name of the - function. The argument DECL is the `FUNCTION_DECL' tree node - representing the function. - - If this macro is not defined, then the function size is not - defined. - -`ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL)' - A C statement (sans semicolon) to output to the stdio stream - STREAM any text necessary for declaring the name NAME of an - initialized variable which is being defined. This macro must - output the label definition (perhaps using `ASM_OUTPUT_LABEL'). - The argument DECL is the `VAR_DECL' tree node representing the - variable. - - If this macro is not defined, then the variable name is defined - in the usual manner as a label (by means of `ASM_OUTPUT_LABEL'). - -`ASM_GLOBALIZE_LABEL (STREAM, NAME)' - A C statement (sans semicolon) to output to the stdio stream - STREAM some commands that will make the label NAME global; that - is, available for reference from other files. Use the expression - `assemble_name (STREAM, NAME)' to output the name itself; before - and after that, output the additional assembler syntax for making - that name global, and a newline. - -`ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME)' - A C statement (sans semicolon) to output to the stdio stream - STREAM any text necessary for declaring the name of an external - symbol named NAME which is referenced in this compilation but not - defined. The value of DECL is the tree node for the declaration. - - This macro need not be defined if it does not need to output - anything. The GNU assembler and most Unix assemblers don't - require anything. - -`ASM_OUTPUT_EXTERNAL_LIBCALL (STREAM, SYMREF)' - A C statement (sans semicolon) to output on STREAM an assembler - pseudo-op to declare a library function name external. The name - of the library function is given by SYMREF, which has type `rtx' - and is a `symbol_ref'. - - This macro need not be defined if it does not need to output - anything. The GNU assembler and most Unix assemblers don't - require anything. - -`ASM_OUTPUT_LABELREF (STREAM, NAME)' - A C statement (sans semicolon) to output to the stdio stream - STREAM a reference in assembler syntax to a label named NAME. - This should add `_' to the front of the name, if that is - customary on your operating system, as it is in most Berkeley Unix - systems. This macro is used in `assemble_name'. - -`ASM_OUTPUT_LABELREF_AS_INT (FILE, LABEL)' - Define this macro for systems that use the program `collect2'. - The definition should be a C statement to output a word containing - a reference to the label LABEL. - -`ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM)' - A C statement to store into the string STRING a label whose name - is made from the string PREFIX and the number NUM. - - This string, when output subsequently by `ASM_OUTPUT_LABELREF', - should produce the same output that `ASM_OUTPUT_INTERNAL_LABEL' - would produce with the same PREFIX and NUM. - -`ASM_OUTPUT_INTERNAL_LABEL (STREAM, PREFIX, NUM)' - A C statement to output to the stdio stream STREAM a label whose - name is made from the string PREFIX and the number NUM. These - labels are used for internal purposes, and there is no reason for - them to appear in the symbol table of the object file. On many - systems, the letter `L' at the beginning of a label has this - effect. The usual definition of this macro is as follows: - - fprintf (STREAM, "L%s%d:\n", PREFIX, NUM) - -`ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER)' - A C expression to assign to OUTVAR (which is a variable of type - `char *') a newly allocated string made from the string NAME and - the number NUMBER, with some suitable punctuation added. Use - `alloca' to get space for the string. - - This string will be used as the argument to `ASM_OUTPUT_LABELREF' - to produce an assembler label for an internal static variable - whose name is NAME. Therefore, the string must be such as to - result in valid assembler code. The argument NUMBER is different - each time this macro is executed; it prevents conflicts between - similarly-named internal static variables in different scopes. - - Ideally this string should not be a valid C identifier, to - prevent any conflict with the user's own symbols. Most - assemblers allow periods or percent signs in assembler symbols; - putting at least one of these between the name and the number - will suffice. - -`OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME, SEL_NAME)' - Define this macro to override the default assembler names used for - Objective C methods. - - The default name is a unique method number followed by the name - of the class (e.g. `_1_Foo'). For methods in categories, the - name of the category is also included in the assembler name (e.g. - `_1_Foo_Bar'). - - These names are safe on most systems, but make debugging - difficult since the method's selector is not present in the name. - Therefore, particular systems define other ways of computing - names. - - BUF is a buffer in which to store the name (256 chars max); - IS_INST specifies whether the method is an instance method or a - class method; CLASS_NAME is the name of the class; CAT_NAME is - the name of the category (or NULL if the method is not in a - category); and SEL_NAME is the name of the selector. - - On systems where the assembler can handle quoted names, you can - use this macro to provide more human-readable names. + You need not define this macro if you did not define + `DELAY_SLOTS_FOR_EPILOGUE'.  -File: gcc.info, Node: Constructor Output, Next: Instruction Output, Prev: Label Output, Up: Assembler Format +File: gcc.info, Node: Profiling, Prev: Function Entry, Up: Stack and Calling -Output of Initialization Routines ---------------------------------- +Generating Code for Profiling +----------------------------- - The compiled code for certain languages includes "constructors" -(also called "initialization routines")--functions to initialize data -in the program when the program is started. These functions need to -be called before the program is "started"--that is to say, before -`main' is called. - - Compiling some languages generates "destructors" (also called -"termination routines") that should be called when the program -terminates. - - To make the initialization and termination functions work, the -compiler must output something in the assembler code to cause those -functions to be called at the appropriate time. When you port the -compiler to a new system, you need to specify what assembler code is -needed to do this. - - Here are the two macros you should define if necessary: - -`ASM_OUTPUT_CONSTRUCTOR (STREAM, NAME)' - Define this macro as a C statement to output on the stream STREAM - the assembler code to arrange to call the function named NAME at - initialization time. - - Assume that NAME is the name of a C function generated - automatically by the compiler. This function takes no arguments. - Use the function `assemble_name' to output the name NAME; this - performs any system-specific syntactic transformations such as - adding an underscore. - - If you don't define this macro, nothing special is output to - arrange to call the function. This is correct when the function - will be called in some other manner--for example, by means of the - `collect' program, which looks through the symbol table to find - these functions by their names. If you want to use `collect', - then you need to arrange for it to be built and installed and - used on your system. - -`ASM_OUTPUT_DESTRUCTOR (STREAM, NAME)' - This is like `ASM_OUTPUT_CONSTRUCTOR' but used for termination - functions rather than initialization functions. +`FUNCTION_PROFILER (FILE, LABELNO)' + A C statement or compound statement to output to FILE some + assembler code to call the profiling subroutine `mcount'. Before + calling, the assembler code must load the address of a counter + variable into a register where `mcount' expects to find the + address. The name of this variable is `LP' followed by the number + LABELNO, so you would generate the name using `LP%d' in a + `fprintf'. + + The details of how the address should be passed to `mcount' are + determined by your operating system environment, not by GNU CC. To + figure them out, compile a small program for profiling using the + system's installed C compiler and look at the assembler code that + results. + +`PROFILE_BEFORE_PROLOGUE' + Define this macro if the code for function profiling should come + before the function prologue. Normally, the profiling code comes + after. + +`FUNCTION_BLOCK_PROFILER (FILE, LABELNO)' + A C statement or compound statement to output to FILE some + assembler code to initialize basic-block profiling for the current + object module. This code should call the subroutine + `__bb_init_func' once per object module, passing it as its sole + argument the address of a block allocated in the object module. + + The name of the block is a local symbol made with this statement: + + ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0); + + Of course, since you are writing the definition of + `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you + can take a short cut in the definition of this macro and use the + name that you know will result. + + The first word of this block is a flag which will be nonzero if the + object module has already been initialized. So test this word + first, and do not call `__bb_init_func' if the flag is nonzero. + +`BLOCK_PROFILER (FILE, BLOCKNO)' + A C statement or compound statement to increment the count + associated with the basic block number BLOCKNO. Basic blocks are + numbered separately from zero within each compilation. The count + associated with block number BLOCKNO is at index BLOCKNO in a + vector of words; the name of this array is a local symbol made + with this statement: + + ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2); + + Of course, since you are writing the definition of + `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you + can take a short cut in the definition of this macro and use the + name that you know will result.  -File: gcc.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Constructor Output, Up: Assembler Format +File: gcc.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros -Output of Assembler Instructions --------------------------------- +Implementing the Varargs Macros +=============================== -`REGISTER_NAMES' - A C initializer containing the assembler's names for the machine - registers, each one as a C string constant. This is what - translates register numbers in the compiler into assembler - language. - -`ADDITIONAL_REGISTER_NAMES' - If defined, a C initializer for an array of structures containing - a name and a register number. This macro defines additional - names for hard registers, thus allowing the `asm' option in - declarations to refer to registers using alternate names. - -`ASM_OUTPUT_OPCODE (STREAM, PTR)' - Define this macro if you are using an unusual assembler that - requires different names for the machine instructions. - - The definition is a C statement or statements which output an - assembler instruction opcode to the stdio stream STREAM. The - macro-operand PTR is a variable of type `char *' which points to - the opcode name in its "internal" form--the form that is written - in the machine description. The definition should output the - opcode name to STREAM, performing any translation you desire, and - increment the variable PTR to point at the end of the opcode so - that it will not be output twice. - - In fact, your macro definition may process less than the entire - opcode name, or more than the opcode name; but if you want to - process text that includes `%'-sequences to substitute operands, - you must take care of the substitution yourself. Just be sure to - increment PTR over whatever text should not be output normally. - - If you need to look at the operand values, they can be found as - the elements of `recog_operand'. - - If the macro definition does nothing, the instruction is output - in the usual way. - -`FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS)' - If defined, a C statement to be executed just prior to the output - of assembler code for INSN, to modify the extracted operands so - they will be output differently. - - Here the argument OPVEC is the vector containing the operands - extracted from INSN, and NOPERANDS is the number of elements of - the vector which contain meaningful data for this insn. The - contents of this vector are what will be used to convert the insn - template into assembler code, so you can change the assembler - output by changing the contents of the vector. - - This macro is useful when various assembler syntaxes share a - single file of instruction patterns; by defining this macro - differently, you can cause a large class of instructions to be - output differently (such as with rearranged operands). - Naturally, variations in assembler syntax affecting individual - insn patterns ought to be handled by writing conditional output - routines in those patterns. - - If this macro is not defined, it is equivalent to a null - statement. - -`PRINT_OPERAND (STREAM, X, CODE)' - A C compound statement to output to stdio stream STREAM the - assembler syntax for an instruction operand X. X is an RTL - expression. - - CODE is a value that can be used to specify one of several ways - of printing the operand. It is used when identical operands must - be printed differently depending on the context. CODE comes from - the `%' specification that was used to request printing of the - operand. If the specification was just `%DIGIT' then CODE is 0; - if the specification was `%LTR DIGIT' then CODE is the ASCII code - for LTR. - - If X is a register, this macro should print the register's name. - The names can be found in an array `reg_names' whose type is - `char *[]'. `reg_names' is initialized from `REGISTER_NAMES'. - - When the machine description has a specification `%PUNCT' (a `%' - followed by a punctuation character), this macro is called with a - null pointer for X and the punctuation character for CODE. - -`PRINT_OPERAND_PUNCT_VALID_P (CODE)' - A C expression which evaluates to true if CODE is a valid - punctuation character for use in the `PRINT_OPERAND' macro. If - `PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no - punctuation characters (except for the standard one, `%') are used - in this way. - -`PRINT_OPERAND_ADDRESS (STREAM, X)' - A C compound statement to output to stdio stream STREAM the - assembler syntax for an instruction operand that is a memory - reference whose address is X. X is an RTL expression. - - On some machines, the syntax for a symbolic address 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. *Note Assembler - Format::. - -`DBR_OUTPUT_SEQEND(FILE)' - A C statement, to be executed after all slot-filler instructions - have been output. If necessary, call `dbr_sequence_length' to - determine the number of slots filled in a sequence (zero if not - currently outputting a sequence), to decide how many no-ops to - output, or whatever. - - Don't define this macro if it has nothing to do, but it is - helpful in reading assembly output if the extent of the delay - sequence is made explicit (e.g. with white space). - - Note that output routines for instructions with delay slots must - be prepared to deal with not being output as part of a sequence - (i.e. when the scheduling pass is not run, or when no slot - fillers could be found.) The variable `final_sequence' is null - when not processing a sequence, otherwise it contains the - `sequence' rtx being output. - -`REGISTER_PREFIX' -`LOCAL_LABEL_PREFIX' -`USER_LABEL_PREFIX' -`IMMEDIATE_PREFIX' - If defined, C string expressions to be used for the `%R', `%L', - `%U', and `%I' options of `asm_fprintf' (see `final.c'). These - are useful when a single `md' file must support multiple - assembler formats. In that case, the various `tm.h' files can - define these macros differently. - -`ASM_OUTPUT_REG_PUSH (STREAM, REGNO)' - A C expression to output to STREAM some assembler code which will - push hard register number REGNO onto the stack. The code need - not be optimal, since this macro is used only when profiling. - -`ASM_OUTPUT_REG_POP (STREAM, REGNO)' - A C expression to output to STREAM some assembler code which will - pop hard register number REGNO off of the stack. The code need - not be optimal, since this macro is used only when profiling. + GNU CC comes with an implementation of `varargs.h' and `stdarg.h' +that work without change on machines that pass arguments on the stack. +Other machines require their own implementations of varargs, and the +two machine independent header files must have conditionals to include +it. + + ANSI `stdarg.h' differs from traditional `varargs.h' mainly in the +calling convention for `va_start'. The traditional implementation +takes just one argument, which is the variable in which to store the +argument pointer. The ANSI implementation of `va_start' takes an +additional second argument. The user is supposed to write the last +named argument of the function here. + + However, `va_start' should not use this argument. The way to find +the end of the named arguments is with the built-in functions described +below. + +`__builtin_saveregs ()' + Use this built-in function to save the argument registers in + memory so that the varargs mechanism can access them. Both ANSI + and traditional versions of `va_start' must use + `__builtin_saveregs', unless you use `SETUP_INCOMING_VARARGS' (see + below) instead. + + On some machines, `__builtin_saveregs' is open-coded under the + control of the macro `EXPAND_BUILTIN_SAVEREGS'. On other machines, + it calls a routine written in assembler language, found in + `libgcc2.c'. + + Regardless of what code is generated for the call to + `__builtin_saveregs', it appears at the beginning of the function, + not where the call to `__builtin_saveregs' is written. This is + because the registers must be saved before the function starts to + use them for its own purposes. + +`__builtin_args_info (CATEGORY)' + Use this built-in function to find the first anonymous arguments in + registers. + + In general, a machine may have several categories of registers + used for arguments, each for a particular category of data types. + (For example, on some machines, floating-point registers are used + for floating-point arguments while other arguments are passed in + the general registers.) To make non-varargs functions use the + proper calling convention, you have defined the `CUMULATIVE_ARGS' + data type to record how many registers in each category have been + used so far + + `__builtin_args_info' accesses the same data structure of type + `CUMULATIVE_ARGS' after the ordinary argument layout is finished + with it, with CATEGORY specifying which word to access. Thus, the + value indicates the first unused register in a given category. + + Normally, you would use `__builtin_args_info' in the implementation + of `va_start', accessing each category just once and storing the + value in the `va_list' object. This is because `va_list' will + have to update the values, and there is no way to alter the values + accessed by `__builtin_args_info'. + +`__builtin_next_arg ()' + This is the equivalent of `__builtin_args_info', for stack + arguments. It returns the address of the first anonymous stack + argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns + the address of the location above the first anonymous stack + argument. Use it in `va_start' to initialize the pointer for + fetching arguments from the stack. + +`__builtin_classify_type (OBJECT)' + Since each machine has its own conventions for which data types are + passed in which kind of register, your implementation of `va_arg' + has to embody these conventions. The easiest way to categorize the + specified data type is to use `__builtin_classify_type' together + with `sizeof' and `__alignof__'. + + `__builtin_classify_type' ignores the value of OBJECT, considering + only its data type. It returns an integer describing what kind of + type that is--integer, floating, pointer, structure, and so on. + + The file `typeclass.h' defines an enumeration that you can use to + interpret the values of `__builtin_classify_type'. + + These machine description macros help implement varargs: + +`EXPAND_BUILTIN_SAVEREGS (ARGS)' + If defined, is a C expression that produces the machine-specific + code for a call to `__builtin_saveregs'. This code will be moved + to the very beginning of the function, before any parameter access + are made. The return value of this function should be an RTX that + contains the value to use as the return of `__builtin_saveregs'. + + The argument ARGS is a `tree_list' containing the arguments that + were passed to `__builtin_saveregs'. + + If this macro is not defined, the compiler will output an ordinary + call to the library function `__builtin_saveregs'. + +`SETUP_INCOMING_VARARGS (ARGS_SO_FAR, MODE, TYPE, PRETEND_ARGS_SIZE, SECOND_TIME)' + This macro offers an alternative to using `__builtin_saveregs' and + defining the macro `EXPAND_BUILTIN_SAVEREGS'. Use it to store the + anonymous register arguments into the stack so that all the + arguments appear to have been passed consecutively on the stack. + Once this is done, you can use the standard implementation of + varargs that works for machines that pass all their arguments on + the stack. + + The argument ARGS_SO_FAR is the `CUMULATIVE_ARGS' data structure, + containing the values that obtain after processing of the named + arguments. The arguments MODE and TYPE describe the last named + argument--its machine mode and its data type as a tree node. + + The macro implementation should do two things: first, push onto the + stack all the argument registers *not* used for the named + arguments, and second, store the size of the data thus pushed into + the `int'-valued variable whose name is supplied as the argument + PRETEND_ARGS_SIZE. The value that you store here will serve as + additional offset for setting up the stack frame. + + Because you must generate code to push the anonymous arguments at + compile time without knowing their data types, + `SETUP_INCOMING_VARARGS' is only useful on machines that have just + a single category of argument register and use it uniformly for + all data types. + + If the argument SECOND_TIME is nonzero, it means that the + arguments of the function are being analyzed for the second time. + This happens for an inline function, which is not actually + compiled until the end of the source file. The macro + `SETUP_INCOMING_VARARGS' should not generate any instructions in + this case.  -File: gcc.info, Node: Dispatch Tables, Next: Alignment Output, Prev: Instruction Output, Up: Assembler Format - -Output of Dispatch Tables -------------------------- +File: gcc.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros -`ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, VALUE, REL)' - This macro should be provided on machines where the addresses in - a dispatch table are relative to the table's own address. - - The definition should be a C statement to output to the stdio - stream STREAM an assembler pseudo-instruction to generate a - difference between two labels. VALUE and REL are the numbers of - two internal labels. The definitions of these labels are output - using `ASM_OUTPUT_INTERNAL_LABEL', and they must be printed in - the same way here. For example, - - fprintf (STREAM, "\t.word L%d-L%d\n", - VALUE, REL) - -`ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE)' - This macro should be provided on machines where the addresses in - a dispatch table are absolute. - - The definition should be a C statement to output to the stdio - stream STREAM an assembler pseudo-instruction to generate a - reference to a label. VALUE is the number of an internal label - whose definition is output using `ASM_OUTPUT_INTERNAL_LABEL'. - For example, - - fprintf (STREAM, "\t.word L%d\n", VALUE) - -`ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE)' - Define this if the label before a jump-table needs to be output - specially. The first three arguments are the same as for - `ASM_OUTPUT_INTERNAL_LABEL'; the fourth argument is the - jump-table which follows (a `jump_insn' containing an `addr_vec' - or `addr_diff_vec'). - - This feature is used on system V to output a `swbeg' statement - for the table. - - If this macro is not defined, these labels are output with - `ASM_OUTPUT_INTERNAL_LABEL'. - -`ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE)' - Define this if something special must be output at the end of a - jump-table. The definition should be a C statement to be executed - after the assembler code for the table is written. It should - write the appropriate code to stdio stream STREAM. The argument - TABLE is the jump-table insn, and NUM is the label-number of the - preceding label. +Trampolines for Nested Functions +================================ - If this macro is not defined, nothing special is output at the - end of the jump-table. + 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.  -File: gcc.info, Node: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format +File: gcc.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros -Assembler Commands for Alignment --------------------------------- +Implicit Calls to Library Routines +================================== -`ASM_OUTPUT_ALIGN_CODE (FILE)' - A C expression to output text to align the location counter in - the way that is desirable at a point in the code that is reached - only by jumping. - - This macro need not be defined if you don't want any special - alignment to be done at such a time. Most machine descriptions - do not currently define the macro. - -`ASM_OUTPUT_LOOP_ALIGN (FILE)' - A C expression to output text to align the location counter in - the way that is desirable at the beginning of a loop. - - This macro need not be defined if you don't want any special - alignment to be done at such a time. Most machine descriptions - do not currently define the macro. - -`ASM_OUTPUT_SKIP (STREAM, NBYTES)' - A C statement to output to the stdio stream STREAM an assembler - instruction to advance the location counter by NBYTES bytes. - Those bytes should be zero when loaded. NBYTES will be a C - expression of type `int'. - -`ASM_NO_SKIP_IN_TEXT' - Define this macro if `ASM_OUTPUT_SKIP' should not be used in the - text section because it fails put zeros in the bytes that are - skipped. This is true on many Unix systems, where the pseudo--op - to skip bytes produces no-op instructions rather than zeros when - used in the text section. - -`ASM_OUTPUT_ALIGN (STREAM, POWER)' - A C statement to output to the stdio stream STREAM an assembler - command to advance the location counter to a multiple of 2 to the - POWER bytes. POWER will be a C expression of type `int'. +`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. + +`nongcc_SI_type' + Define this macro as the name of the data type corresponding to + `SImode' in the system's own C compiler. + + You need not define this macro if that type is `int', as it usually + is. + +`perform_...' + Define these macros to supply explicit C statements to carry out + various arithmetic operations on types `float' and `double' in the + library routines in `libgcc1.c'. See that file for a full list of + these macros and their arguments. + + On most machines, you don't need to define any of these macros, + because the C compiler that comes with the system takes care of + doing them. + +`NEXT_OBJC_RUNTIME' + Define this macro to generate code for Objective C message sending + using the calling convention of the NeXT system. This calling + convention involves passing the object, the selector and the + method arguments all at once to the method-lookup library function. + + The default calling convention passes just the object and the + selector to the lookup function, which returns a pointer to the + method.  -File: gcc.info, Node: Debugging Info, Next: Cross-compilation, Prev: Assembler Format, Up: Machine Macros +File: gcc.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Target Macros -Controlling Debugging Information Format -======================================== +Addressing Modes +================ -`DBX_REGISTER_NUMBER (REGNO)' - A C expression that returns the DBX register number for the - compiler register number REGNO. In simple cases, the value of - this expression may be REGNO itself. But sometimes there are some - registers that the compiler knows about and DBX does not, or vice - versa. In such cases, some register may need to have one number - in the compiler and another for DBX. - - If two registers have consecutive numbers inside GNU CC, and they - can be used as a pair to hold a multiword value, then they *must* - have consecutive numbers after renumbering with - `DBX_REGISTER_NUMBER'. Otherwise, debuggers will be unable to - access such a pair, because they expect register pairs to be - consecutive in their own numbering scheme. - - If you find yourself defining `DBX_REGISTER_NUMBER' in way that - does not preserve register pairs, then what you must do instead is - redefine the actual register numbering scheme. - -`DBX_DEBUGGING_INFO' - Define this macro if GNU CC should produce debugging output for - DBX in response to the `-g' option. - -`SDB_DEBUGGING_INFO' - Define this macro if GNU CC should produce COFF-style debugging - output for SDB in response to the `-g' option. - -`DWARF_DEBUGGING_INFO' - Define this macro if GNU CC should produce dwarf format debugging - output in response to the `-g' option. - -`DEFAULT_GDB_EXTENSIONS' - Define this macro to control whether GNU CC should by default - generate GDB's extended version of DBX debugging information - (assuming DBX-format debugging information is enabled at all). - If you don't define the macro, the default is 1: always generate - the extended information. - -`DEBUG_SYMS_TEXT' - Define this macro if all `.stabs' commands should be output while - in the text section. - -`DEBUGGER_AUTO_OFFSET (X)' - A C expression that returns the integer offset value for an - automatic variable having address X (an RTL expression). The - default computation assumes that X is based on the frame-pointer - and gives the offset from the frame-pointer. This is required - for targets that produce debugging output for DBX or COFF-style - debugging output for SDB and allow the frame-pointer to be - eliminated when the `-g' options is used. - -`DEBUGGER_ARG_OFFSET (OFFSET, X)' - A C expression that returns the integer offset value for an - argument having address X (an RTL expression). The nominal - offset is OFFSET. - -`ASM_STABS_OP' - A C string constant naming the assembler pseudo op to use instead - of `.stabs' to define an ordinary debugging symbol. If you don't - define this macro, `.stabs' is used. This macro applies only to - DBX debugging information format. - -`ASM_STABD_OP' - A C string constant naming the assembler pseudo op to use instead - of `.stabd' to define a debugging symbol whose value is the - current location. If you don't define this macro, `.stabd' is - used. This macro applies only to DBX debugging information - format. - -`ASM_STABN_OP' - A C string constant naming the assembler pseudo op to use instead - of `.stabn' to define a debugging symbol with no name. If you - don't define this macro, `.stabn' is used. This macro applies - only to DBX debugging information format. - -`PUT_SDB_...' - Define these macros to override the assembler syntax for the - special SDB assembler directives. See `sdbout.c' for a list of - these macros and their arguments. If the standard syntax is - used, you need not define them yourself. - -`SDB_DELIM' - Some assemblers do not support a semicolon as a delimiter, even - between SDB assembler directives. In that case, define this - macro to be the delimiter to use (usually `\n'). It is not - necessary to define a new set of `PUT_SDB_OP' macros if this is - the only change required. - -`SDB_GENERATE_FAKE' - Define this macro to override the usual method of constructing a - dummy name for anonymous structure and union types. See - `sdbout.c' for more information. - -`SDB_ALLOW_UNKNOWN_REFERENCES' - Define this macro to allow references to unknown structure, - union, or enumeration tags to be emitted. Standard COFF does not - allow handling of unknown references, MIPS ECOFF has support for - it. - -`SDB_ALLOW_FORWARD_REFERENCES' - Define this macro to allow references to structure, union, or - enumeration tags that have not yet been seen to be handled. Some - assemblers choke if forward tags are used, while some require it. - -`DBX_NO_XREFS' - Define this macro if DBX on your system does not support the - construct `xsTAGNAME'. On some systems, this construct is used to - describe a forward reference to a structure named TAGNAME. On - other systems, this construct is not supported at all. - -`DBX_CONTIN_LENGTH' - A symbol name in DBX-format debugging information is normally - continued (split into two separate `.stabs' directives) when it - exceeds a certain length (by default, 80 characters). On some - operating systems, DBX requires this splitting; on others, - splitting must not be done. You can inhibit splitting by - defining this macro with the value zero. You can override the - default splitting-length by defining this macro as an expression - for the length you desire. - -`DBX_CONTIN_CHAR' - Normally continuation is indicated by adding a `\' character to - the end of a `.stabs' string when a continuation follows. To use - a different character instead, define this macro as a character - constant for the character you want to use. Do not define this - macro if backslash is correct for your system. - -`DBX_STATIC_STAB_DATA_SECTION' - Define this macro if it is necessary to go to the data section - before outputting the `.stabs' pseudo-op for a non-global static - variable. - -`DBX_LBRAC_FIRST' - Define this macro if the `N_LBRAC' symbol for a block should - precede the debugging information for variables and functions - defined in that block. Normally, in DBX format, the `N_LBRAC' - symbol comes first. - -`DBX_FUNCTION_FIRST' - Define this macro if the DBX information for a function and its - arguments should precede the assembler code for the function. - Normally, in DBX format, the debugging information entirely - follows the assembler code. - -`DBX_OUTPUT_FUNCTION_END (STREAM, FUNCTION)' - Define this macro if the target machine requires special output - at the end of the debugging information for a function. The - definition should be a C statement (sans semicolon) to output the - appropriate information to STREAM. FUNCTION is the - `FUNCTION_DECL' node for the function. - -`DBX_OUTPUT_STANDARD_TYPES (SYMS)' - Define this macro if you need to control the order of output of - the standard data types at the beginning of compilation. The - argument SYMS is a `tree' which is a chain of all the predefined - global symbols, including names of data types. - - Normally, DBX output starts with definitions of the types for - integers and characters, followed by all the other predefined - types of the particular language in no particular order. - - On some machines, it is necessary to output different particular - types first. To do this, define `DBX_OUTPUT_STANDARD_TYPES' to - output those symbols in the necessary order. Any predefined - types that you don't explicitly output will be output afterward - in no particular order. - - Be careful not to define this macro so that it works only for C. - There are no global variables to access most of the built-in - types, because another language may have another set of types. - The way to output a particular type is to look through SYMS to - see if you can find it. Here is an example: - - { - tree decl; - for (decl = syms; decl; decl = TREE_CHAIN (decl)) - if (!strcmp (IDENTIFIER_POINTER (DECL_NAME (decl)), "long int")) - dbxout_symbol (decl); - ... - } - - This does nothing if the expected type does not exist. - - See the function `init_decl_processing' in source file `c-decl.c' - to find the names to use for all the built-in C types. - -`DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME)' - A C statement to output DBX debugging information to the stdio - stream STREAM which indicates that file NAME is the main source - file--the file specified as the input file for compilation. This - macro is called only once, at the beginning of compilation. - - This macro need not be defined if the standard form of output for - DBX debugging information is appropriate. - -`DBX_OUTPUT_MAIN_SOURCE_DIRECTORY (STREAM, NAME)' - A C statement to output DBX debugging information to the stdio - stream STREAM which indicates that the current directory during - compilation is named NAME. - - This macro need not be defined if the standard form of output for - DBX debugging information is appropriate. - -`DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME)' - A C statement to output DBX debugging information at the end of - compilation of the main source file NAME. - - If you don't define this macro, nothing special is output at the - end of compilation, which is correct for most machines. - -`DBX_OUTPUT_SOURCE_FILENAME (STREAM, NAME)' - A C statement to output DBX debugging information to the stdio - stream STREAM which indicates that file NAME is the current source - file. This output is generated each time input shifts to a - different source file as a result of `#include', the end of an - included file, or a `#line' command. - - This macro need not be defined if the standard form of output for - DBX debugging information is appropriate. +`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.  -File: gcc.info, Node: Cross-compilation, Next: Misc, Prev: Debugging INfo, Up: Machine Macros - -Cross Compilation and Floating Point Format -=========================================== +File: gcc.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Target Macros - While all modern machines use 2's complement representation for -integers, there are a variety of representations for floating point -numbers. This means that in a cross-compiler the representation of -floating point numbers in the compiled program may be different from -that used in the machine doing the compilation. - - Because different representation systems may offer different -amounts of range and precision, the cross compiler cannot safely use -the host machine's floating point arithmetic. Therefore, floating -point constants must be represented in the target machine's format. -This means that the cross compiler cannot use `atof' to parse a -floating point constant; it must have its own special routine to use -instead. Also, constant folding must emulate the target machine's -arithmetic (or must not be done at all). - - The macros in the following table should be defined only if you are -cross compiling between different floating point formats. - - Otherwise, don't define them. Then default definitions will be set -up which use `double' as the data type, `==' to test for equality, etc. - - You don't need to worry about how many times you use an operand of -any of these macros. The compiler never uses operands which have side -effects. - -`REAL_VALUE_TYPE' - A macro for the C data type to be used to hold a floating point - value in the target machine's format. Typically this would be a - `struct' containing an array of `int'. - -`REAL_VALUES_EQUAL (X, Y)' - A macro for a C expression which compares for equality the two - values, X and Y, both of type `REAL_VALUE_TYPE'. - -`REAL_VALUES_LESS (X, Y)' - A macro for a C expression which tests whether X is less than Y, - both values being of type `REAL_VALUE_TYPE' and interpreted as - floating point numbers in the target machine's representation. - -`REAL_VALUE_LDEXP (X, SCALE)' - A macro for a C expression which performs the standard library - function `ldexp', but using the target machine's floating point - representation. Both X and the value of the expression have type - `REAL_VALUE_TYPE'. The second argument, SCALE, is an integer. - -`REAL_VALUE_FIX (X)' - A macro whose definition is a C expression to convert the - target-machine floating point value X to a signed integer. X has - type `REAL_VALUE_TYPE'. - -`REAL_VALUE_UNSIGNED_FIX (X)' - A macro whose definition is a C expression to convert the - target-machine floating point value X to an unsigned integer. X - has type `REAL_VALUE_TYPE'. - -`REAL_VALUE_FIX_TRUNCATE (X)' - A macro whose definition is a C expression to convert the - target-machine floating point value X to a signed integer, - rounding toward 0. X has type `REAL_VALUE_TYPE'. - -`REAL_VALUE_UNSIGNED_FIX_TRUNCATE (X)' - A macro whose definition is a C expression to convert the - target-machine floating point value X to an unsigned integer, - rounding toward 0. X has type `REAL_VALUE_TYPE'. - -`REAL_VALUE_ATOF (STRING)' - A macro for a C expression which converts STRING, an expression - of type `char *', into a floating point number in the target - machine's representation. The value has type `REAL_VALUE_TYPE'. - -`REAL_INFINITY' - Define this macro if infinity is a possible floating point value, - and therefore division by 0 is legitimate. - -`REAL_VALUE_ISINF (X)' - A macro for a C expression which determines whether X, a floating - point value, is infinity. The value has type `int'. By default, - this is defined to call `isinf'. - -`REAL_VALUE_ISNAN (X)' - A macro for a C expression which determines whether X, a floating - point value, is a "nan" (not-a-number). The value has type - `int'. By default, this is defined to call `isnan'. - - Define the following additional macros if you want to make floating -point constant folding work while cross compiling. If you don't -define them, cross compilation is still possible, but constant folding -will not happen for floating point values. - -`REAL_ARITHMETIC (OUTPUT, CODE, X, Y)' - A macro for a C statement which calculates an arithmetic - operation of the two floating point values X and Y, both of type - `REAL_VALUE_TYPE' in the target machine's representation, to - produce a result of the same type and representation which is - stored in OUTPUT (which will be a variable). - - The operation to be performed is specified by CODE, a tree code - which will always be one of the following: `PLUS_EXPR', - `MINUS_EXPR', `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'. - - The expansion of this macro is responsible for checking for - overflow. If overflow happens, the macro expansion should - execute the statement `return 0;', which indicates the inability - to perform the arithmetic operation requested. - -`REAL_VALUE_NEGATE (X)' - A macro for a C expression which returns the negative of the - floating point value X. Both X and the value of the expression - have type `REAL_VALUE_TYPE' and are in the target machine's - floating point representation. - - There is no way for this macro to report overflow, since overflow - can't happen in the negation operation. - -`REAL_VALUE_TRUNCATE (X)' - A macro for a C expression which converts the double-precision - floating point value X to single-precision. - - Both X and the value of the expression have type - `REAL_VALUE_TYPE' and are in the target machine's floating point - representation. However, the value should have an appropriate bit - pattern to be output properly as a single-precision floating - constant. - - There is no way for this macro to report overflow. - -`REAL_VALUE_TO_INT (LOW, HIGH, X)' - A macro for a C expression which converts a floating point value - X into a double-precision integer which is then stored into LOW - and HIGH, two variables of type INT. - -`REAL_VALUE_FROM_INT (X, LOW, HIGH)' - A macro for a C expression which converts a double-precision - integer found in LOW and HIGH, two variables of type INT, into a - floating point value which is then stored into X. - - -File: gcc.info, Node: Misc, Prev: Cross-compilation, Up: Machine Macros +Condition Code Status +===================== -Miscellaneous Parameters -======================== + 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) -`PREDICATE_CODES' - Optionally define this if you have added predicates to - `MACHINE.c'. This macro is called within an initializer of an - array of structures. The first field in the structure is the - name of a predicate and the second field is an arrary of rtl - codes. For each predicate, list all rtl codes that can be in - expressions matched by the predicate. The list should have a - trailing comma. Here is an example of two entries in the list - for a typical RISC machine: - - #define PREDICATE_CODES \ - {"gen_reg_rtx_operand", {SUBREG, REG}}, \ - {"reg_or_short_cint_operand", {SUBREG, REG, CONST_INT}}, - - Defining this macro does not affect the generated code (however, - incorrect definitions that omit an rtl code that may be matched - by the predicate can cause the compiler to malfunction). - Instead, it allows the table built by `genrecog' to be more - compact and efficient, thus speeding up the compiler. The most - important predicates to include in the list specified by this - macro are thoses used in the most insn patterns. - -`CASE_VECTOR_MODE' - An alias for a machine mode name. This is the machine mode that - elements of a jump-table should have. - -`CASE_VECTOR_PC_RELATIVE' - Define this macro if jump-tables should contain relative - addresses. - -`CASE_DROPS_THROUGH' - Define this if control falls through a `case' insn when the index - value is out of range. This means the specified default-label is - actually ignored by the `case' insn proper. - -`BYTE_LOADS_ZERO_EXTEND' - Define this macro if an instruction to load a value narrower than - a word from memory into a register also zero-extends the value to - the whole register. - -`IMPLICIT_FIX_EXPR' - An alias for a tree code that should be used by default for - conversion of floating point values to fixed point. Normally, - `FIX_ROUND_EXPR' is used. - -`FIXUNS_TRUNC_LIKE_FIX_TRUNC' - Define this macro if the same instructions that convert a floating - point number to a signed fixed point number also convert validly - to an unsigned one. - -`EASY_DIV_EXPR' - An alias for a tree code that is the easiest kind of division to - compile code for in the general case. It may be - `TRUNC_DIV_EXPR', `FLOOR_DIV_EXPR', `CEIL_DIV_EXPR' or - `ROUND_DIV_EXPR'. These four division operators differ in how - they round the result to an integer. `EASY_DIV_EXPR' is used - when it is permissible to use any of those kinds of division and - the choice should be made on the basis of efficiency. - -`MOVE_MAX' - The maximum number of bytes that a single instruction can move - quickly from memory to memory. - -`SHIFT_COUNT_TRUNCATED' - Defining this macro causes the compiler to omit a sign-extend, - zero-extend, or bitwise `and' instruction that truncates the - count of a shift operation to a width equal to the number of bits - needed to represent the size of the object being shifted. On - machines that have instructions that act on bitfields at variable - positions, including `bit test' instructions, defining - `SHIFT_COUNT_TRUNCATED' also causes truncation not to be applied - to these instructions. - - If both types of instructions truncate the count (for shifts) and - position (for bitfield operations), or if no variable-position - bitfield instructions exist, you should define this macro. - - However, on some machines, such as the 80386, truncation only - applies to shift operations and not bitfield operations. Do not - define `SHIFT_COUNT_TRUNCATED' on such machines. Instead, add - patterns to the `md' file that include the implied truncation of - the shift instructions. - -`TRULY_NOOP_TRUNCATION (OUTPREC, INPREC)' - A C expression which is nonzero if on this machine it is safe to - "convert" an integer of INPREC bits to one of OUTPREC bits (where - OUTPREC is smaller than INPREC) by merely operating on it as if - it had only OUTPREC bits. - - On many machines, this expression can be 1. - - It is reported that suboptimal code can result when - `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for modes - for which `MODES_TIEABLE_P' is 0. If this is the case, making - `TRULY_NOOP_TRUNCATION' return 0 in such cases may improve things. - -`STORE_FLAG_VALUE' - A C expression describing the value returned by a comparison - operator and stored by a store-flag instruction (`sCOND') when the - condition is true. This description must apply to *all* the - `sCOND' patterns and all the comparison operators. - - A value of 1 or -1 means that the instruction implementing the - comparison operator returns exactly 1 or -1 when the comparison - is true and 0 when the comparison is false. Otherwise, the value - indicates which bits of the result are guaranteed to be 1 when - the comparison is true. This value is interpreted in the mode of - the comparison operation, which is given by the mode of the first - operand in the `sCOND' pattern. Either the low bit or the sign - bit of `STORE_FLAG_VALUE' be on. Presently, only those bits are - used by the compiler. - - If `STORE_FLAG_VALUE' is neither 1 or -1, the compiler will - generate code that depends only on the specified bits. It can - also replace comparison operators with equivalent operations if - they cause the required bits to be set, even if the remaining - bits are undefined. For example, on a machine whose comparison - operators return an `SImode' value and where `STORE_FLAG_VALUE' - is defined as `0x80000000', saying that just the sign bit is - relevant, the expression - - (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) - - can be converted to - - (ashift:SI X (const_int N)) - - where N is the appropriate shift count to move the bit being - tested into the sign bit. - - There is no way to describe a machine that always sets the - low-order bit for a true value, but does not guarantee the value - of any other bits, but we do not know of any machine that has - such an instruction. If you are trying to port GNU CC to such a - machine, include an instruction to perform a logical-and of the - result with 1 in the pattern for the comparison operators and let - us know (*note Bug Reporting::.). - - Often, a machine will have multiple instructions that obtain a - value from a comparison (or the condition codes). Here are rules - to guide the choice of value for `STORE_FLAG_VALUE', and hence - the instructions to be used: - - * Use the shortest sequence that yields a valid definition for - `STORE_FLAG_VALUE'. It is more efficent for the compiler to - "normalize" the value (convert it to, e.g., 1 or 0) than for - the comparison operators to do so because there may be - opportunities to combine the normalization with other - operations. - - * For equal-length sequences, use a value of 1 or -1, with -1 - being slightly preferred on machines with expensive jumps - and 1 preferred on other machines. - - * As a second choice, choose a value of `0x80000001' if - instructions exist that set both the sign and low-order bits - but do not define the others. - - * Otherwise, use a value of `0x80000000'. - - You need not define `STORE_FLAG_VALUE' if the machine has no - store-flag instructions. - -`Pmode' - An alias for the machine mode for pointers. Normally the - definition can be - - #define Pmode SImode - -`FUNCTION_MODE' - An alias for the machine mode used for memory references to - functions being called, in `call' RTL expressions. On most - machines this should be `QImode'. - -`INTEGRATE_THRESHOLD (DECL)' - A C expression for the maximum number of instructions above which - the function DECL should not be inlined. DECL is a - `FUNCTION_DECL' node. - - The default definition of this macro is 64 plus 8 times the - number of arguments that the function accepts. Some people think - a larger threshold should be used on RISC machines. - -`SCCS_DIRECTIVE' - Define this if the preprocessor should ignore `#sccs' directives - and print no error message. - -`HANDLE_PRAGMA (STREAM)' - Define this macro if you want to implement any pragmas. If - defined, it should be a C statement to be executed when `#pragma' - is seen. The argument STREAM is the stdio input stream from - which the source text can be read. - - It is generally a bad idea to implement new uses of `#pragma'. - The only reason to define this macro is for compatibility with - other compilers that do support `#pragma' for the sake of any user - programs which already use it. - -`HAVE_VPRINTF' - Define this if the library function `vprintf' is available on your - system. - -`DOLLARS_IN_IDENTIFIERS' - Define this macro to control use of the character `$' in - identifier names. The value should be 0, 1, or 2. 0 means `$' - is not allowed by default; 1 means it is allowed by default if - `-traditional' is used; 2 means it is allowed by default provided - `-ansi' is not used. 1 is the default; there is no need to - define this macro in that case. - -`DEFAULT_MAIN_RETURN' - Define this macro if the target system expects every program's - `main' function to return a standard "success" value by default - (if no other value is explicitly returned). - - The definition should be a C statement (sans semicolon) to - generate the appropriate rtl instructions. It is used only when - compiling the end of `main'. - -`HAVE_ATEXIT' - Define this if the target system supports the function `atexit' - from the ANSI C standard. If this is not defined, and - `INIT_SECTION_ASM_OP' is not defined, a default `exit' function - will be provided to support C++. - -`EXIT_BODY' - Define this if your `exit' function needs to do something besides - calling an external function `_cleanup' before terminating with - `_exit'. The `EXIT_BODY' macro is only needed if netiher - `HAVE_ATEXIT' nor `INIT_SECTION_ASM_OP' are defined. + This macro is not required if `EXTRA_CC_MODES' is not defined.  \ No newline at end of file