--- gcc/gcc.info-22 2018/04/24 18:19:40 1.1.1.3 +++ gcc/gcc.info-22 2018/04/24 18:26:06 1.1.1.4 @@ -3,11 +3,11 @@ file gcc.texi. This file documents the use and the internals of the GNU compiler. - Published by the Free Software Foundation 675 Massachusetts Avenue -Cambridge, MA 02139 USA + Published by the Free Software Foundation 59 Temple Place - Suite 330 +Boston, MA 02111-1307 USA - Copyright (C) 1988, 1989, 1992, 1993, 1994 Free Software Foundation, -Inc. + Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 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 @@ -30,979 +30,1087 @@ translations approved by the Free Softwa original English.  -File: gcc.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format +File: gcc.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros -How Initialization Functions Are Handled ----------------------------------------- +Implicit Calls to Library Routines +================================== - 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 how to do this. - - There are two major ways that GCC currently supports the execution of -initialization and termination functions. Each way has two variants. -Much of the structure is common to all four variations. - - The linker must build two lists of these functions--a list of -initialization functions, called `__CTOR_LIST__', and a list of -termination functions, called `__DTOR_LIST__'. - - Each list always begins with an ignored function pointer (which may -hold 0, -1, or a count of the function pointers after it, depending on -the environment). This is followed by a series of zero or more function -pointers to constructors (or destructors), followed by a function -pointer containing zero. - - Depending on the operating system and its executable file format, -either `crtstuff.c' or `libgcc2.c' traverses these lists at startup -time and exit time. Constructors are called in forward order of the -list; destructors in reverse order. - - The best way to handle static constructors works only for object file -formats which provide arbitrarily-named sections. A section is set -aside for a list of constructors, and another for a list of destructors. -Traditionally these are called `.ctors' and `.dtors'. Each object file -that defines an initialization function also puts a word in the -constructor section to point to that function. The linker accumulates -all these words into one contiguous `.ctors' section. Termination -functions are handled similarly. - - To use this method, you need appropriate definitions of the macros -`ASM_OUTPUT_CONSTRUCTOR' and `ASM_OUTPUT_DESTRUCTOR'. Usually you can -get them by including `svr4.h'. - - When arbitrary sections are available, there are two variants, -depending upon how the code in `crtstuff.c' is called. On systems that -support an "init" section which is executed at program startup, parts -of `crtstuff.c' are compiled into that section. The program is linked -by the `gcc' driver like this: - - ld -o OUTPUT_FILE crtbegin.o ... crtend.o -lgcc - - The head of a function (`__do_global_ctors') appears in the init -section of `crtbegin.o'; the remainder of the function appears in the -init section of `crtend.o'. The linker will pull these two parts of -the section together, making a whole function. If any of the user's -object files linked into the middle of it contribute code, then that -code will be executed as part of the body of `__do_global_ctors'. - - To use this variant, you must define the `INIT_SECTION_ASM_OP' macro -properly. - - If no init section is available, do not define -`INIT_SECTION_ASM_OP'. Then `__do_global_ctors' is built into the text -section like all other functions, and resides in `libgcc.a'. When GCC -compiles any function called `main', it inserts a procedure call to -`__main' as the first executable code after the function prologue. The -`__main' function, also defined in `libgcc2.c', simply calls -`__do_global_ctors'. - - In file formats that don't support arbitrary sections, there are -again two variants. In the simplest variant, the GNU linker (GNU `ld') -and an `a.out' format must be used. In this case, -`ASM_OUTPUT_CONSTRUCTOR' is defined to produce a `.stabs' entry of type -`N_SETT', referencing the name `__CTOR_LIST__', and with the address of -the void function containing the initialization code as its value. The -GNU linker recognizes this as a request to add the value to a "set"; -the values are accumulated, and are eventually placed in the executable -as a vector in the format described above, with a leading (ignored) -count and a trailing zero element. `ASM_OUTPUT_DESTRUCTOR' is handled -similarly. Since no init section is available, the absence of -`INIT_SECTION_ASM_OP' causes the compilation of `main' to call `__main' -as above, starting the initialization process. - - The last variant uses neither arbitrary sections nor the GNU linker. -This is preferable when you want to do dynamic linking and when using -file formats which the GNU linker does not support, such as `ECOFF'. In -this case, `ASM_OUTPUT_CONSTRUCTOR' does not produce an `N_SETT' -symbol; initialization and termination functions are recognized simply -by their names. This requires an extra program in the linkage step, -called `collect2'. This program pretends to be the linker, for use -with GNU CC; it does its job by running the ordinary linker, but also -arranges to include the vectors of initialization and termination -functions. These functions are called via `__main' as described above. - - Choosing among these configuration options has been simplified by a -set of operating-system-dependent files in the `config' subdirectory. -These files define all of the relevant parameters. Usually it is -sufficient to include one into your specific machine-dependent -configuration file. These files are: - -`aoutos.h' - For operating systems using the `a.out' format. - -`next.h' - For operating systems using the `MachO' format. - -`svr3.h' - For System V Release 3 and similar systems using `COFF' format. + Here is an explanation of implicit calls to library routines. -`svr4.h' - For System V Release 4 and similar systems using `ELF' format. - -`vms.h' - For the VMS operating system. - - The following section describes the specific macros that control and -customize the handling of initialization and termination functions. +`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'. + +`INIT_TARGET_OPTABS' + Define this macro as a C statement that declares additional library + routines renames existing ones. `init_optabs' calls this macro + after initializing all the normal library routines. + +`TARGET_EDOM' + The value of `EDOM' on the target machine, as a C integer constant + expression. If you don't define this macro, GNU CC does not + attempt to deposit the value of `EDOM' into `errno' directly. + Look in `/usr/include/errno.h' to find the value of `EDOM' on your + system. + + If you do not define `TARGET_EDOM', then compiled code reports + domain errors by calling the library function and letting it + report the error. If mathematical functions on your system use + `matherr' when there is an error, then you should leave + `TARGET_EDOM' undefined so that `matherr' is used normally. + +`GEN_ERRNO_RTX' + Define this macro as a C expression to create an rtl expression + that refers to the global "variable" `errno'. (On certain systems, + `errno' may not actually be a variable.) If you don't define this + macro, a reasonable default is used. + +`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 `long int', as it + usually is. + +`nongcc_word_type' + Define this macro as the name of the data type corresponding to the + word_mode in the system's own C compiler. + + You need not define this macro if that type is `long 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: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format - -Macros Controlling Initialization Routines ------------------------------------------- +File: gcc.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Target Macros - Here are the macros that control how the compiler handles -initialization and termination functions: +Addressing Modes +================ -`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. When - you are using special sections for initialization and termination - functions, this macro also controls how `crtstuff.c' and - `libgcc2.c' arrange to run the initialization functions. - -`HAS_INIT_SECTION' - If defined, `main' will not call `__main' as described above. - This macro should be defined for systems that control the contents - of the init section on a symbol-by-symbol basis, such as OSF/1, - and should not be defined explicitly for systems that support - `INIT_SECTION_ASM_OP'. - -`INVOKE__main' - If defined, `main' will call `__main' despite the presence of - `INIT_SECTION_ASM_OP'. This macro should be defined for systems - where the init section is not actually run automatically, but is - still useful for collecting the lists of constructors and - destructors. - -`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 - `collect2' program, which looks through the symbol table to find - these functions by their names. - -`ASM_OUTPUT_DESTRUCTOR (STREAM, NAME)' - This is like `ASM_OUTPUT_CONSTRUCTOR' but used for termination - functions rather than initialization functions. - - If your system uses `collect2' as the means of processing -constructors, then that program normally uses `nm' to scan an object -file for constructor functions to be called. On certain kinds of -systems, you can define these macros to make `collect2' work faster -(and, in some cases, make it work at all): - -`OBJECT_FORMAT_COFF' - Define this macro if the system uses COFF (Common Object File - Format) object files, so that `collect2' can assume this format - and scan object files directly for dynamic constructor/destructor - functions. - -`OBJECT_FORMAT_ROSE' - Define this macro if the system uses ROSE format object files, so - that `collect2' can assume this format and scan object files - directly for dynamic constructor/destructor functions. - -`REAL_NM_FILE_NAME' - Define this macro as a C string constant containing the file name - to use to execute `nm'. The default is to search the path - normally for `nm'. + This is about addressing modes. - These macros are effective only in a native compiler; `collect2' as -part of a cross compiler always uses `nm' for the target machine. +`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. + + Subroutines to check for acceptable registers for various purposes + (one for base registers, one for index registers, and so on) are + typically among the subroutines used to define + `GO_IF_LEGITIMATE_ADDRESS'. 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, and define `STRIP_NAME_ENCODING' + to access the original name string. + + You can check the information stored here into the `symbol_ref' in + the definitions of the macros `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 or if the address is valid for some modes but not + others. + + 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.  -File: gcc.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format +File: gcc.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Target Macros -Output of Assembler Instructions --------------------------------- +Condition Code Status +===================== - This describes assembler instruction output. + This describes the condition code status. -`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. - -`ASSEMBLER_DIALECT' - If your target supports multiple dialects of assembler language - (such as different opcodes), define this macro as a C expression - that gives the numeric index of the assembler langauge dialect to - use, with zero as the first variant. - - If this macro is defined, you may use - `{option0|option1|option2...}' constructs in the output templates - of patterns (*note Output Template::.) or in the first argument of - `asm_fprintf'. This construct outputs `option0', `option1' or - `option2', etc., if the value of `ASSEMBLER_DIALECT' is zero, one - or two, etc. Any special characters within these strings retain - their usual meaning. - - If you do not define this macro, the characters `{', `|' and `}' - do not have any special meaning when used in templates or operands - to `asm_fprintf'. - - Define the macros `REGISTER_PREFIX', `LOCAL_LABEL_PREFIX', - `USER_LABEL_PREFIX' and `IMMEDIATE_PREFIX' if you can express the - variations in assemble language syntax with that mechanism. Define - `ASSEMBLER_DIALECT' and use the `{option0|option1}' syntax if the - syntax variant are larger and involve such things as different - opcodes or operand order. - -`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. + 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, CCFPEmode + #define EXTRA_CC_NAMES "CC_NOOV", "CCFP", "CCFPE" + + This macro is not required if `EXTRA_CC_MODES' is not defined. + +`SELECT_CC_MODE (OP, X, Y)' + Returns a mode from class `MODE_CC' to be used when comparison + operation code OP is applied to rtx X and Y. 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,Y) \ + (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ + ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode) \ + : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ + || GET_CODE (X) == NEG) \ + ? CC_NOOVmode : CCmode)) + + You need not define this macro if `EXTRA_CC_MODES' is not defined. + +`CANONICALIZE_COMPARISON (CODE, OP0, OP1)' + One some machines not all possible comparisons are defined, but + you can convert an invalid comparison into a valid one. For + example, the Alpha does not have a `GT' comparison, but you can + use an `LT' comparison instead and swap the order of the operands. + + On such machines, define this macro to be a C statement to do any + required conversions. CODE is the initial comparison code and OP0 + and OP1 are the left and right operands of the comparison, + respectively. You should modify CODE, OP0, and OP1 as required. + + GNU CC will not assume that the comparison resulting from this + macro is valid but will see if the resulting insn matches a + pattern in the `md' file. + + You need not define this macro if it would never change the + comparison code or operands. + +`REVERSIBLE_CC_MODE (MODE)' + A C expression whose value is one if it is always safe to reverse a + comparison whose mode is MODE. If `SELECT_CC_MODE' can ever + return MODE for a floating-point inequality comparison, then + `REVERSIBLE_CC_MODE (MODE)' must be zero. + + You need not define this macro if it would always returns zero or + if the floating-point format is anything other than + `IEEE_FLOAT_FORMAT'. For example, here is the definition used on + the Sparc, where floating-point inequality comparisons are always + given `CCFPEmode': - -File: gcc.info, Node: Dispatch Tables, Next: Alignment Output, Prev: Instruction Output, Up: Assembler Format - -Output of Dispatch Tables -------------------------- - - This concerns dispatch tables. - -`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. - - If this macro is not defined, nothing special is output at the end - of the jump-table. + #define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode)  -File: gcc.info, Node: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format - -Assembler Commands for Alignment --------------------------------- +File: gcc.info, Node: Costs, Next: Sections, Prev: Condition Code, Up: Target Macros - This describes commands for alignment. +Describing Relative Costs of Operations +======================================= -`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. + These macros let you describe the relative speed of various +operations on the target machine. - 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'. +`CONST_COSTS (X, CODE, OUTER_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, and the rtx code of the expression in which it is contained, + found in OUTER_CODE. + + CODE is the expression code--redundant, since it can be obtained + with `GET_CODE (X)'. + +`RTX_COSTS (X, CODE, OUTER_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. OUTER_CODE is the code of the expression in which X + is contained. + + 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 4 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 to be the value 1 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 non-zero, the compiler will act as if + `STRICT_ALIGNMENT' were non-zero when generating code for block + moves. This can cause significantly more instructions to be + produced. Therefore, do not set this macro non-zero if unaligned + accesses only add a cycle or two to the time for a memory access. + + If the value of this macro is always zero, it need not be defined. + +`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. + +`ADJUST_COST (INSN, LINK, DEP_INSN, COST)' + A C statement (sans semicolon) to update the integer variable COST + based on the relationship between INSN that is dependent on + DEP_INSN through the dependence LINK. The default is to make no + adjustment to COST. This can be used for example to specify to + the scheduler that an output- or anti-dependence does not incur + the same cost as a data-dependence.  -File: gcc.info, Node: Debugging Info, Next: Cross-compilation, Prev: Assembler Format, Up: Target Macros +File: gcc.info, Node: Sections, Next: PIC, Prev: Costs, Up: Target Macros -Controlling Debugging Information Format -======================================== +Dividing the Output into Sections (Texts, Data, ...) +==================================================== - This describes how to specify debugging information. - -* Menu: + 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 expression whose value is a string containing the assembler + operation that should precede instructions and read-only data. + Normally `".text"' is right. + +`DATA_SECTION_ASM_OP' + A C expression whose value is a string containing the assembler + operation to identify the following data as writable initialized + data. Normally `".data"' is right. + +`SHARED_SECTION_ASM_OP' + if defined, a C expression whose value is a string containing the + assembler operation to identify the following data as shared data. + If not defined, `DATA_SECTION_ASM_OP' will be used. -* All Debuggers:: Macros that affect all debugging formats uniformly. -* DBX Options:: Macros enabling specific options in DBX format. -* DBX Hooks:: Hook macros for varying DBX format. -* File Names and DBX:: Macros controlling output of file names in DBX format. -* SDB and DWARF:: Macros for SDB (COFF) and DWARF formats. +`INIT_SECTION_ASM_OP' + if defined, a C expression whose value is a string containing 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). + +`STRIP_NAME_ENCODING (VAR, SYM_NAME)' + Decode SYM_NAME and store the real name part in VAR, sans the + characters that encode section info. Define this macro if + `ENCODE_SECTION_INFO' alters the symbol's name string.  -File: gcc.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info - -Macros Affecting All Debugging Formats --------------------------------------- +File: gcc.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros - These macros affect all debugging formats. +Position Independent Code +========================= -`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. - -`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. - -`PREFERRED_DEBUGGING_TYPE' - A C expression that returns the type of debugging output GNU CC - produces when the user specifies `-g' or `-ggdb'. Define this if - you have arranged for GNU CC to support more than one format of - debugging output. Currently, the allowable values are `DBX_DEBUG', - `SDB_DEBUG', `DWARF_DEBUG', and `XCOFF_DEBUG'. - - The value of this macro only affects the default debugging output; - the user can always get a specific type of output by using - `-gstabs', `-gcoff', `-gdwarf', or `-gxcoff'. + 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 `PRINT_OPERAND_ADDRESS', as well as +`LEGITIMIZE_ADDRESS'. 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). + +`PIC_OFFSET_TABLE_REG_CALL_CLOBBERED' + Define this macro if the register defined by + `PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. Do not define + this macro if `PPIC_OFFSET_TABLE_REGNUM' is not defined. + +`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.) + +`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: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info - -Specific Options for DBX Output -------------------------------- - - These are specific options for DBX output. - -`DBX_DEBUGGING_INFO' - Define this macro if GNU CC should produce debugging output for DBX - in response to the `-g' option. - -`XCOFF_DEBUGGING_INFO' - Define this macro if GNU CC should produce XCOFF format debugging - output in response to the `-g' option. This is a variant of DBX - format. - -`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 if there is any occasion to. - -`DEBUG_SYMS_TEXT' - Define this macro if all `.stabs' commands should be output while - in the text section. - -`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. - -`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_TYPE_DECL_STABS_CODE' - The value to use in the "code" field of the `.stabs' directive for - a typedef. The default is `N_LSYM'. - -`DBX_STATIC_CONST_VAR_CODE' - The value to use in the "code" field of the `.stabs' directive for - a static variable located in the text section. DBX format does not - provide any "right" way to do this. The default is `N_FUN'. - -`DBX_REGPARM_STABS_CODE' - The value to use in the "code" field of the `.stabs' directive for - a parameter passed in registers. DBX format does not provide any - "right" way to do this. The default is `N_RSYM'. - -`DBX_REGPARM_STABS_LETTER' - The letter to use in DBX symbol data to identify a symbol as a - parameter passed in registers. DBX format does not customarily - provide any way to do this. The default is `'P''. - -`DBX_MEMPARM_STABS_LETTER' - The letter to use in DBX symbol data to identify a symbol as a - stack parameter. The default is `'p''. - -`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_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_BLOCKS_FUNCTION_RELATIVE' - Define this macro if the value of a symbol describing the scope of - a block (`N_LBRAC' or `N_RBRAC') should be relative to the start - of the enclosing function. Normally, GNU C uses an absolute - address. +File: gcc.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros - -File: gcc.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info +Defining the Output Assembler Language +====================================== -Open-Ended Hooks for DBX Format -------------------------------- + This section describes macros whose principal purpose is to describe +how to write instructions in assembler language-rather than what the +instructions do. - These are hooks for DBX format. +* Menu: -`DBX_OUTPUT_LBRAC (STREAM, NAME)' - Define this macro to say how to output to STREAM the debugging - information for the start of a scope level for variable names. The - argument NAME is the name of an assembler symbol (for use with - `assemble_name') whose value is the address where the scope begins. - -`DBX_OUTPUT_RBRAC (STREAM, NAME)' - Like `DBX_OUTPUT_LBRAC', but for the end of a scope level. - -`DBX_OUTPUT_ENUM (STREAM, TYPE)' - Define this macro if the target machine requires special handling - to output an enumeration type. The definition should be a C - statement (sans semicolon) to output the appropriate information - to STREAM for the type TYPE. - -`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 `c-decl.c' to find the - names to use for all the built-in C types. - - Here is another way of finding a particular type: - - { - tree decl; - for (decl = syms; decl; decl = TREE_CHAIN (decl)) - if (TREE_CODE (decl) == TYPE_DECL - && (TREE_CODE (TREE_TYPE (decl)) - == INTEGER_CST) - && TYPE_PRECISION (TREE_TYPE (decl)) == 16 - && TYPE_UNSIGNED (TREE_TYPE (decl))) - /* This must be `unsigned short'. */ - dbxout_symbol (decl); - ... - } +* 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. +* Initialization:: General principles of initialization + and termination routines. +* Macros for Initialization:: + Specific macros that control the handling 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.  -File: gcc.info, Node: File Names and DBX, Next: SDB and DWARF, Prev: DBX Hooks, Up: Debugging Info - -File Names in DBX Format ------------------------- +File: gcc.info, Node: File Framework, Next: Data Output, Up: Assembler Format - This describes file names in DBX format. - -`DBX_WORKING_DIRECTORY' - Define this if DBX wants to have the current directory recorded in - each object file. +The Overall Framework of an Assembler File +------------------------------------------ - Note that the working directory is always recorded if GDB - extensions are enabled. + This describes the overall framework of an assembler file. -`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. +`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. + + 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. + + On systems that use SDB, it is necessary to output certain + commands; see `attasm.h'. + +`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. + + 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 systems that use SDB, it is necessary to output certain + commands; see `attasm.h'. + +`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 - DBX debugging information is appropriate. + the file format in use 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. +`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. + +`ASM_OUTPUT_SECTION_NAME (STREAM, DECL, NAME)' + A C statement to output something to the assembler file to switch + to section NAME for object DECL which is either a `FUNCTION_DECL', + a `VAR_DECL' or `NULL_TREE'. Some target formats do not support + arbitrary sections. Do not define this macro in such cases. + + At present this macro is only used to support section attributes. + When this macro is undefined, section attributes are disabled. + +`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. - This macro need not be defined if the standard form of output for - DBX debugging information is appropriate. + +File: gcc.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format -`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. +Output of Data +-------------- - This macro need not be defined if the standard form of output for - DBX debugging information is appropriate. + This describes data output. - -File: gcc.info, Node: SDB and DWARF, Prev: File Names and DBX, Up: Debugging Info +`ASM_OUTPUT_LONG_DOUBLE (STREAM, VALUE)' +`ASM_OUTPUT_DOUBLE (STREAM, VALUE)' +`ASM_OUTPUT_FLOAT (STREAM, VALUE)' +`ASM_OUTPUT_THREE_QUARTER_FLOAT (STREAM, VALUE)' +`ASM_OUTPUT_SHORT_FLOAT (STREAM, VALUE)' +`ASM_OUTPUT_BYTE_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', `SFmode', `TQFmode', `HFmode', or `QFmode', + respectively, whose value is VALUE. VALUE will be a C expression + of type `REAL_VALUE_TYPE'. Macros such as + `REAL_VALUE_TO_TARGET_DOUBLE' are useful for writing these + definitions. + +`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. -Macros for SDB and DWARF Output -------------------------------- +`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. - Here are macros for SDB and DWARF output. +`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"'. -`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. - -`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. +`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'. - -File: gcc.info, Node: Cross-compilation, Next: Misc, Prev: Debugging Info, Up: Target Macros + If the assembler has a `.ascii' pseudo-op as found in the Berkeley + Unix assembler, do not define the macro `ASM_OUTPUT_ASCII'. -Cross Compilation and Floating Point -==================================== +`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. + +`IS_ASM_LOGICAL_LINE_SEPARATOR (C)' + Define this macro as a C expression which is nonzero if C is used + as a logical line separator by the assembler. + + If you do not define this macro, the default is that only the + character `;' is treated as a logical line separator. + +`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: + + #define ASM_OPEN_PAREN "(" + #define ASM_CLOSE_PAREN ")" + + These macros are provided by `real.h' for writing the definitions of +`ASM_OUTPUT_DOUBLE' and the like: + +`REAL_VALUE_TO_TARGET_SINGLE (X, L)' +`REAL_VALUE_TO_TARGET_DOUBLE (X, L)' +`REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L)' + These translate X, of type `REAL_VALUE_TYPE', to the target's + floating point representation, and store its bit pattern in the + array of `long int' whose address is L. The number of elements in + the output array is determined by the size of the desired target + floating point data type: 32 bits of it go in each `long int' array + element. Each array element holds 32 bits of the result, even if + `long int' is wider than 32 bits on the host machine. + + The array element values are designed so that you can print them + out using `fprintf' in the order they should appear in the target + machine's memory. + +`REAL_VALUE_TO_DECIMAL (X, FORMAT, STRING)' + This macro converts X, of type `REAL_VALUE_TYPE', to a decimal + number and stores it as a string into STRING. You must pass, as + STRING, the address of a long enough block of space to hold the + result. - 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_RNDZINT (X)' - A macro whose definition is a C expression to round the - target-machine floating point value X towards zero to an integer - value (but still as a floating point number). X has type - `REAL_VALUE_TYPE', and so does the value. - -`REAL_VALUE_UNSIGNED_RNDZINT (X)' - A macro whose definition is a C expression to round the - target-machine floating point value X towards zero to an unsigned - integer value (but still represented as a floating point number). - x has type `REAL_VALUE_TYPE', and so does the value. - -`REAL_VALUE_ATOF (STRING, MODE)' - 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 for mode MODE. 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 (MODE, X)' - A macro for a C expression which converts the floating point value - X to mode MODE. - - Both X and the value of the expression are in the target machine's - floating point representation and have type `REAL_VALUE_TYPE'. - However, the value should have an appropriate bit pattern to be - output properly as a floating constant whose precision accords - with mode MODE. - - 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. + The argument FORMAT is a `printf'-specification that serves as a + suggestion for how to format the output string.