This is doc/gccint.info, produced by makeinfo version 4.2 from doc/gccint.texi. INFO-DIR-SECTION Programming START-INFO-DIR-ENTRY * gccint: (gccint). Internals of the GNU Compiler Collection. END-INFO-DIR-ENTRY This file documents the internals of the GNU compilers. Published by the Free Software Foundation 59 Temple Place - Suite 330 Boston, MA 02111-1307 USA Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being "GNU General Public License" and "Funding Free Software", the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the section entitled "GNU Free Documentation License". (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development.  File: gccint.info, Node: Target Attributes, Next: Misc, Prev: Mode Switching, Up: Target Macros Defining target-specific uses of `__attribute__' ================================================ Target-specific attributes may be defined for functions, data and types. These are described using the following target hooks; they also need to be documented in `extend.texi'. - Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE If defined, this target hook points to an array of `struct attribute_spec' (defined in `tree.h') specifying the machine specific attributes for this target and some of the restrictions on the entities to which these attributes are applied and the arguments they take. - Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (tree TYPE1, tree TYPE2) If defined, this target hook is a function which returns zero if the attributes on TYPE1 and TYPE2 are incompatible, one if they are compatible, and two if they are nearly compatible (which causes a warning to be generated). If this is not defined, machine-specific attributes are supposed always to be compatible. - Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE) If defined, this target hook is a function which assigns default attributes to newly defined TYPE. - Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree TYPE2) Define this target hook if the merging of type attributes needs special handling. If defined, the result is a list of the combined `TYPE_ATTRIBUTES' of TYPE1 and TYPE2. It is assumed that `comptypes' has already been called and returned 1. This function may call `merge_attributes' to handle machine-independent merging. - Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree NEWDECL) Define this target hook if the merging of decl attributes needs special handling. If defined, the result is a list of the combined `DECL_ATTRIBUTES' of OLDDECL and NEWDECL. NEWDECL is a duplicate declaration of OLDDECL. Examples of when this is needed are when one attribute overrides another, or when an attribute is nullified by a subsequent definition. This function may call `merge_attributes' to handle machine-independent merging. If the only target-specific handling you require is `dllimport' for Windows targets, you should define the macro `TARGET_DLLIMPORT_DECL_ATTRIBUTES'. This links in a function called `merge_dllimport_decl_attributes' which can then be defined as the expansion of `TARGET_MERGE_DECL_ATTRIBUTES'. This is done in `i386/cygwin.h' and `i386/i386.c', for example. - Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree *ATTR_PTR) Define this target hook if you want to be able to add attributes to a decl when it is being created. This is normally useful for back ends which wish to implement a pragma by using the attributes which correspond to the pragma's effect. The NODE argument is the decl which is being created. The ATTR_PTR argument is a pointer to the attribute list for this decl. The list itself should not be modified, since it may be shared with other decls, but attributes may be chained on the head of the list and `*ATTR_PTR' modified to point to the new attributes, or a copy of the list may be made if further changes are needed. - Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (tree FNDECL) This target hook returns `true' if it is ok to inline FNDECL into the current function, despite its having target-specific attributes, `false' otherwise. By default, if a function has a target specific attribute attached to it, it will not be inlined.  File: gccint.info, Node: Misc, Prev: Target Attributes, Up: Target Macros Miscellaneous Parameters ======================== Here are several miscellaneous parameters. `PREDICATE_CODES' Define this if you have defined special-purpose predicates in the file `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 array 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 those used in the most insn patterns. For each predicate function named in `PREDICATE_CODES', a declaration will be generated in `insn-codes.h'. `SPECIAL_MODE_PREDICATES' Define this if you have special predicates that know special things about modes. Genrecog will warn about certain forms of `match_operand' without a mode; if the operand predicate is listed in `SPECIAL_MODE_PREDICATES', the warning will be suppressed. Here is an example from the IA-32 port (`ext_register_operand' specially checks for `HImode' or `SImode' in preparation for a byte extraction from `%ah' etc.). #define SPECIAL_MODE_PREDICATES \ "ext_register_operand", `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_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY)' Optional: return the preferred mode for an `addr_diff_vec' when the minimum and maximum offset are known. If you define this, it enables extra code in branch shortening to deal with `addr_diff_vec'. To make this work, you also have to define INSN_ALIGN and make the alignment for `addr_diff_vec' explicit. The BODY argument is provided so that the offset_unsigned and scale flags can be updated. `CASE_VECTOR_PC_RELATIVE' Define this macro to be a C expression to indicate when jump-tables should contain relative addresses. If jump-tables never contain relative addresses, then you need not define this macro. `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. `CASE_VALUES_THRESHOLD' Define this to be the smallest number of different values for which it is best to use a jump-table instead of a tree of conditional branches. The default is four for machines with a `casesi' instruction and five otherwise. This is best for most machines. `WORD_REGISTER_OPERATIONS' Define this macro if operations between registers with integral mode smaller than a word are always performed on the entire register. Most RISC machines have this property and most CISC machines do not. `LOAD_EXTEND_OP (MODE)' Define this macro to be a C expression indicating when insns that read memory in MODE, an integral mode narrower than a word, set the bits outside of MODE to be either the sign-extension or the zero-extension of the data read. Return `SIGN_EXTEND' for values of MODE for which the insn sign-extends, `ZERO_EXTEND' for which it zero-extends, and `NIL' for other modes. This macro is not called with MODE non-integral or with a width greater than or equal to `BITS_PER_WORD', so you may return any value in this case. Do not define this macro if it would always return `NIL'. On machines where this macro is defined, you will normally define it as the constant `SIGN_EXTEND' or `ZERO_EXTEND'. `SHORT_IMMEDIATES_SIGN_EXTEND' Define this macro if loading short immediate values into registers sign extends. `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. `MOVE_MAX' The maximum number of bytes that a single instruction can move quickly between memory and registers or between two memory locations. `MAX_MOVE_MAX' The maximum number of bytes that a single instruction can move quickly between memory and registers or between two memory locations. If this is undefined, the default is `MOVE_MAX'. Otherwise, it is the constant value that is the largest value that `MOVE_MAX' can have at run-time. `SHIFT_COUNT_TRUNCATED' A C expression that is nonzero if on this machine the number of bits actually used for the count of a shift operation is equal to the number of bits needed to represent the size of the object being shifted. When this macro is nonzero, the compiler will assume that it is safe to omit a sign-extend, zero-extend, and certain bitwise `and' instructions that truncates the count of a shift operation. On machines that have instructions that act on bit-fields at variable positions, which may include `bit test' instructions, a nonzero `SHIFT_COUNT_TRUNCATED' also enables deletion of truncations of the values that serve as arguments to bit-field instructions. If both types of instructions truncate the count (for shifts) and position (for bit-field operations), or if no variable-position bit-field instructions exist, you should define this macro. However, on some machines, such as the 80386 and the 680x0, truncation only applies to shift operations and not the (real or pretended) bit-field operations. Define `SHIFT_COUNT_TRUNCATED' to be zero on such machines. Instead, add patterns to the `md' file that include the implied truncation of the shift instructions. You need not define this macro if it would always have the value of zero. `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. When `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for modes for which `MODES_TIEABLE_P' is 0, suboptimal code can result. 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 with an integral mode 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 whose results have a `MODE_INT' mode. 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 GCC 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 at . 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 efficient 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'. Many machines can produce both the value chosen for `STORE_FLAG_VALUE' and its negation in the same number of instructions. On those machines, you should also define a pattern for those cases, e.g., one matching (set A (neg:M (ne:M B C))) Some machines can also perform `and' or `plus' operations on condition code values with less instructions than the corresponding `sCOND' insn followed by `and' or `plus'. On those machines, define the appropriate patterns. Use the names `incscc' and `decscc', respectively, for the patterns which perform `plus' or `minus' operations on condition code values. See `rs6000.md' for some examples. The GNU Superoptizer can be used to find such instruction sequences on other machines. You need not define `STORE_FLAG_VALUE' if the machine has no store-flag instructions. `FLOAT_STORE_FLAG_VALUE (MODE)' A C expression that gives a nonzero `REAL_VALUE_TYPE' value that is returned when comparison operators with floating-point results are true. Define this macro on machine that have comparison operations that return floating-point values. If there are no such operations, do not define this macro. `Pmode' An alias for the machine mode for pointers. On most machines, define this to be the integer mode corresponding to the width of a hardware pointer; `SImode' on 32-bit machine or `DImode' on 64-bit machines. On some machines you must define this to be one of the partial integer modes, such as `PSImode'. The width of `Pmode' must be at least as large as the value of `POINTER_SIZE'. If it is not equal, you must define the macro `POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to `Pmode'. `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. `STDC_0_IN_SYSTEM_HEADERS' In normal operation, the preprocessor expands `__STDC__' to the constant 1, to signify that GCC conforms to ISO Standard C. On some hosts, like Solaris, the system compiler uses a different convention, where `__STDC__' is normally 0, but is 1 if the user specifies strict conformance to the C Standard. Defining `STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host convention when processing system header files, but when processing user files `__STDC__' will always expand to 1. `SCCS_DIRECTIVE' Define this if the preprocessor should ignore `#sccs' directives and print no error message. `NO_IMPLICIT_EXTERN_C' Define this macro if the system header files support C++ as well as C. This macro inhibits the usual method of using system header files in C++, which is to pretend that the file's contents are enclosed in `extern "C" {...}'. `HANDLE_PRAGMA (GETC, UNGETC, NAME)' This macro is no longer supported. You must use `REGISTER_TARGET_PRAGMAS' instead. `REGISTER_TARGET_PRAGMAS (PFILE)' Define this macro if you want to implement any target-specific pragmas. If defined, it is a C expression which makes a series of calls to `cpp_register_pragma' for each pragma, with PFILE passed as the first argument to to these functions. The macro may also do any setup required for the pragmas. The primary reason to define this macro is to provide compatibility with other compilers for the same target. In general, we discourage definition of target-specific pragmas for GCC. If the pragma can be implemented by attributes then you should consider defining the target hook `TARGET_INSERT_ATTRIBUTES' as well. Preprocessor macros that appear on pragma lines are not expanded. All `#pragma' directives that do not match any registered pragma are silently ignored, unless the user specifies `-Wunknown-pragmas'. - Function: void cpp_register_pragma (cpp_reader *PFILE, const char *SPACE, const char *NAME, void (*CALLBACK) (cpp_reader *)) Each call to `cpp_register_pragma' establishes one pragma. The CALLBACK routine will be called when the preprocessor encounters a pragma of the form #pragma [SPACE] NAME ... SPACE is the case-sensitive namespace of the pragma, or `NULL' to put the pragma in the global namespace. The callback routine receives PFILE as its first argument, which can be passed on to cpplib's functions if necessary. You can lex tokens after the NAME by calling `c_lex'. Tokens that are not read by the callback will be silently ignored. The end of the line is indicated by a token of type `CPP_EOF'. For an example use of this routine, see `c4x.h' and the callback routines defined in `c4x-c.c'. Note that the use of `c_lex' is specific to the C and C++ compilers. It will not work in the Java or Fortran compilers, or any other language compilers for that matter. Thus if `c_lex' is going to be called from target-specific code, it must only be done so when building the C and C++ compilers. This can be done by defining the variables `c_target_objs' and `cxx_target_objs' in the target entry in the `config.gcc' file. These variables should name the target-specific, language-specific object file which contains the code that uses `c_lex'. Note it will also be necessary to add a rule to the makefile fragment pointed to by `tmake_file' that shows how to build this object file. `HANDLE_SYSV_PRAGMA' Define this macro (to a value of 1) if you want the System V style pragmas `#pragma pack()' and `#pragma weak [=]' to be supported by gcc. The pack pragma specifies the maximum alignment (in bytes) of fields within a structure, in much the same way as the `__aligned__' and `__packed__' `__attribute__'s do. A pack value of zero resets the behavior to the default. The weak pragma only works if `SUPPORTS_WEAK' and `ASM_WEAKEN_LABEL' are defined. If enabled it allows the creation of specifically named weak labels, optionally with a value. `HANDLE_PRAGMA_PACK_PUSH_POP' Define this macro (to a value of 1) if you want to support the Win32 style pragmas `#pragma pack(push,N)' and `#pragma pack(pop)'. The `pack(push,N)' pragma specifies the maximum alignment (in bytes) of fields within a structure, in much the same way as the `__aligned__' and `__packed__' `__attribute__'s do. A pack value of zero resets the behavior to the default. Successive invocations of this pragma cause the previous values to be stacked, so that invocations of `#pragma pack(pop)' will return to the previous value. `DOLLARS_IN_IDENTIFIERS' Define this macro to control use of the character `$' in identifier names. 0 means `$' is not allowed by default; 1 means it is allowed. 1 is the default; there is no need to define this macro in that case. This macro controls the compiler proper; it does not affect the preprocessor. `NO_DOLLAR_IN_LABEL' Define this macro if the assembler does not accept the character `$' in label names. By default constructors and destructors in G++ have `$' in the identifiers. If this macro is defined, `.' is used instead. `NO_DOT_IN_LABEL' Define this macro if the assembler does not accept the character `.' in label names. By default constructors and destructors in G++ have names that use `.'. If this macro is defined, these names are rewritten to avoid `.'. `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'. `NEED_ATEXIT' Define this if the target system lacks the function `atexit' from the ISO C standard. If this macro is defined, a default definition will be provided to support C++. If `ON_EXIT' is not defined, a default `exit' function will also be provided. `ON_EXIT' Define this macro if the target has another way to implement atexit functionality without replacing `exit'. For instance, SunOS 4 has a similar `on_exit' library function. The definition should be a functional macro which can be used just like the `atexit' function. `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 `NEED_ATEXIT' is defined and `ON_EXIT' is not defined. `INSN_SETS_ARE_DELAYED (INSN)' Define this macro as a C expression that is nonzero if it is safe for the delay slot scheduler to place instructions in the delay slot of INSN, even if they appear to use a resource set or clobbered in INSN. INSN is always a `jump_insn' or an `insn'; GCC knows that every `call_insn' has this behavior. On machines where some `insn' or `jump_insn' is really a function call and hence has this behavior, you should define this macro. You need not define this macro if it would always return zero. `INSN_REFERENCES_ARE_DELAYED (INSN)' Define this macro as a C expression that is nonzero if it is safe for the delay slot scheduler to place instructions in the delay slot of INSN, even if they appear to set or clobber a resource referenced in INSN. INSN is always a `jump_insn' or an `insn'. On machines where some `insn' or `jump_insn' is really a function call and its operands are registers whose use is actually in the subroutine it calls, you should define this macro. Doing so allows the delay slot scheduler to move instructions which copy arguments into the argument registers into the delay slot of INSN. You need not define this macro if it would always return zero. `MACHINE_DEPENDENT_REORG (INSN)' In rare cases, correct code generation requires extra machine dependent processing between the second jump optimization pass and delayed branch scheduling. On those machines, define this macro as a C statement to act on the code starting at INSN. `MULTIPLE_SYMBOL_SPACES' Define this macro if in some cases global symbols from one translation unit may not be bound to undefined symbols in another translation unit without user intervention. For instance, under Microsoft Windows symbols must be explicitly imported from shared libraries (DLLs). `MD_ASM_CLOBBERS (CLOBBERS)' A C statement that adds to CLOBBERS `STRING_CST' trees for any hard regs the port wishes to automatically clobber for all asms. `MAX_INTEGER_COMPUTATION_MODE' Define this to the largest integer machine mode which can be used for operations other than load, store and copy operations. You need only define this macro if the target holds values larger than `word_mode' in general purpose registers. Most targets should not define this macro. `MATH_LIBRARY' Define this macro as a C string constant for the linker argument to link in the system math library, or `""' if the target does not have a separate math library. You need only define this macro if the default of `"-lm"' is wrong. `LIBRARY_PATH_ENV' Define this macro as a C string constant for the environment variable that specifies where the linker should look for libraries. You need only define this macro if the default of `"LIBRARY_PATH"' is wrong. `TARGET_HAS_F_SETLKW' Define this macro if the target supports file locking with fcntl / F_SETLKW. Note that this functionality is part of POSIX. Defining `TARGET_HAS_F_SETLKW' will enable the test coverage code to use file locking when exiting a program, which avoids race conditions if the program has forked. `MAX_CONDITIONAL_EXECUTE' A C expression for the maximum number of instructions to execute via conditional execution instructions instead of a branch. A value of `BRANCH_COST'+1 is the default if the machine does not use cc0, and 1 if it does use cc0. `IFCVT_MODIFY_TESTS' A C expression to modify the tests in `TRUE_EXPR', and `FALSE_EXPR' for use in converting insns in `TEST_BB', `THEN_BB', `ELSE_BB', and `JOIN_BB' basic blocks to conditional execution. Set either `TRUE_EXPR' or `FALSE_EXPR' to a null pointer if the tests cannot be converted. `IFCVT_MODIFY_INSN' A C expression to modify the `PATTERN' of an `INSN' that is to be converted to conditional execution format. `IFCVT_MODIFY_FINAL' A C expression to perform any final machine dependent modifications in converting code to conditional execution in the basic blocks `TEST_BB', `THEN_BB', `ELSE_BB', and `JOIN_BB'. `IFCVT_MODIFY_CANCEL' A C expression to cancel any machine dependent modifications in converting code to conditional execution in the basic blocks `TEST_BB', `THEN_BB', `ELSE_BB', and `JOIN_BB'. - Target Hook: void TARGET_INIT_BUILTINS () Define this hook if you have any machine-specific built-in functions that need to be defined. It should be a function that performs the necessary setup. Machine specific built-in functions can be useful to expand special machine instructions that would otherwise not normally be generated because they have no equivalent in the source language (for example, SIMD vector instructions or prefetch instructions). To create a built-in function, call the function `builtin_function' which is defined by the language front end. You can use any type nodes set up by `build_common_tree_nodes' and `build_common_tree_nodes_2'; only language front ends that use those two functions will call `TARGET_INIT_BUILTINS'. - Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx SUBTARGET, enum machine_mode MODE, int IGNORE) Expand a call to a machine specific built-in function that was set up by `TARGET_INIT_BUILTINS'. EXP is the expression for the function call; the result should go to TARGET if that is convenient, and have mode MODE if that is convenient. SUBTARGET may be used as the target for computing one of EXP's operands. IGNORE is nonzero if the value is to be ignored. This function should return the result of the call to the built-in function. `MD_CAN_REDIRECT_BRANCH(BRANCH1, BRANCH2)' Take a branch insn in BRANCH1 and another in BRANCH2. Return true if redirecting BRANCH1 to the destination of BRANCH2 is possible. On some targets, branches may have a limited range. Optimizing the filling of delay slots can result in branches being redirected, and this may in turn cause a branch offset to overflow. `ALLOCATE_INITIAL_VALUE(HARD_REG)' When the initial value of a hard register has been copied in a pseudo register, it is often not necessary to actually allocate another register to this pseudo register, because the original hard register or a stack slot it has been saved into can be used. `ALLOCATE_INITIAL_VALUE', if defined, is called at the start of register allocation once for each hard register that had its initial value copied by using `get_func_hard_reg_initial_val' or `get_hard_reg_initial_val'. Possible values are `NULL_RTX', if you don't want to do any special allocation, a `REG' rtx--that would typically be the hard register itself, if it is known not to be clobbered--or a `MEM'. If you are returning a `MEM', this is only a hint for the allocator; it might decide to use another register anyways. You may use `current_function_leaf_function' in the definition of the macro, functions that use `REG_N_SETS', to determine if the hard register in question will not be clobbered. `TARGET_OBJECT_SUFFIX' Define this macro to be a C string representing the suffix for object files on your target machine. If you do not define this macro, GCC will use `.o' as the suffix for object files. `TARGET_EXECUTABLE_SUFFIX' Define this macro to be a C string representing the suffix to be automatically added to executable files on your target machine. If you do not define this macro, GCC will use the null string as the suffix for executable files. `COLLECT_EXPORT_LIST' If defined, `collect2' will scan the individual object files specified on its command line and create an export list for the linker. Define this macro for systems like AIX, where the linker discards object files that are not referenced from `main' and uses export lists. - Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void) This target hook returns `true' past the point in which new jump instructions could be created. On machines that require a register for every jump such as the SHmedia ISA of SH5, this point would typically be reload, so this target hook should be defined to a function such as: static bool cannot_modify_jumps_past_reload_p () { return (reload_completed || reload_in_progress); }  File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top Host Configuration Headers ************************** Host configuration headers contain macro definitions that describe the machine and system on which the compiler is running. They are usually unnecessary. Most of the things GCC needs to know about the host system can be deduced by the `configure' script. If your host does need a special configuration header, it should be named `xm-MACHINE.h', where MACHINE is a short mnemonic for the machine. Here are some macros which this header can define. `VMS' Define this macro if the host system is VMS. `FATAL_EXIT_CODE' A C expression for the status code to be returned when the compiler exits after serious errors. The default is the system-provided macro `EXIT_FAILURE', or `1' if the system doesn't define that macro. Define this macro only if these defaults are incorrect. `SUCCESS_EXIT_CODE' A C expression for the status code to be returned when the compiler exits without serious errors. (Warnings are not serious errors.) The default is the system-provided macro `EXIT_SUCCESS', or `0' if the system doesn't define that macro. Define this macro only if these defaults are incorrect. `USE_C_ALLOCA' Define this macro if GCC should use the C implementation of `alloca' provided by `libiberty.a'. This only affects how some parts of the compiler itself allocate memory. It does not change code generation. When GCC is built with a compiler other than itself, the C `alloca' is always used. This is because most other implementations have serious bugs. You should define this macro only on a system where no stack-based `alloca' can possibly work. For instance, if a system has a small limit on the size of the stack, GCC's builtin `alloca' will not work reliably. `HAVE_DOS_BASED_FILE_SYSTEM' Define this macro if the host file system obeys the semantics defined by MS-DOS instead of Unix. DOS file systems are case insensitive, file specifications may begin with a drive letter, and both forward slash and backslash (`/' and `\') are directory separators. If you define this macro, you probably need to define the next three macros too. `PATH_SEPARATOR' If defined, this macro should expand to a character constant specifying the separator for elements of search paths. The default value is a colon (`:'). DOS-based systems usually use semicolon (`;'). `DIR_SEPARATOR' `DIR_SEPARATOR_2' If defined, these macros expand to character constants specifying separators for directory names within a file specification. They are used somewhat inconsistently throughout the compiler. If your system behaves like Unix (only forward slash separates pathnames), define neither of them. If your system behaves like DOS (both forward and backward slash can be used), define `DIR_SEPARATOR' to `/' and `DIR_SEPARATOR_2' to `\'. `HOST_OBJECT_SUFFIX' Define this macro to be a C string representing the suffix for object files on your host machine. If you do not define this macro, GCC will use `.o' as the suffix for object files. `HOST_EXECUTABLE_SUFFIX' Define this macro to be a C string representing the suffix for executable files on your host machine. If you do not define this macro, GCC will use the null string as the suffix for executable files. `HOST_BIT_BUCKET' A pathname defined by the host operating system, which can be opened as a file and written to, but all the information written is discarded. This is commonly known as a "bit bucket" or "null device". If you do not define this macro, GCC will use `/dev/null' as the bit bucket. If the host does not support a bit bucket, define this macro to an invalid filename. `COLLECT2_HOST_INITIALIZATION' If defined, a C statement (sans semicolon) that performs host-dependent initialization when `collect2' is being initialized. `GCC_DRIVER_HOST_INITIALIZATION' If defined, a C statement (sans semicolon) that performs host-dependent initialization when a compilation driver is being initialized. `UPDATE_PATH_HOST_CANONICALIZE (PATH)' If defined, a C statement (sans semicolon) that performs host-dependent canonicalization when a path used in a compilation driver or preprocessor is canonicalized. PATH is a malloc-ed path to be canonicalized. If the C statement does canonicalize PATH into a different buffer, the old path should be freed and the new buffer should have been allocated with malloc. `DUMPFILE_FORMAT' Define this macro to be a C string representing the format to use for constructing the index part of debugging dump file names. The resultant string must fit in fifteen bytes. The full filename will be the concatenation of: the prefix of the assembler file name, the string resulting from applying this format to an index number, and a string unique to each dump file kind, e.g. `rtl'. If you do not define this macro, GCC will use `.%02d.'. You should define this macro if using the default will create an invalid file name. `SMALL_ARG_MAX' Define this macro if the host system has a small limit on the total size of an argument vector. This causes the driver to take more care not to pass unnecessary arguments to subprocesses. In addition, if `configure' generates an incorrect definition of any of the macros in `auto-host.h', you can override that definition in a host configuration header. If you need to do this, first see if it is possible to fix `configure'. If you need to define only a few of these macros, and they have simple definitions, consider using the `xm_defines' variable in your `config.gcc' entry instead of creating a host configuration header. *Note System Config::.  File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top Makefile Fragments ****************** When you configure GCC using the `configure' script, it will construct the file `Makefile' from the template file `Makefile.in'. When it does this, it can incorporate makefile fragments from the `config' directory. These are used to set Makefile parameters that are not amenable to being calculated by autoconf. The list of fragments to incorporate is set by `config.gcc'; *Note System Config::. Fragments are named either `t-TARGET' or `x-HOST', depending on whether they are relevant to configuring GCC to produce code for a particular target, or to configuring GCC to run on a particular host. Here TARGET and HOST are mnemonics which usually have some relationship to the canonical system name, but no formal connection. If these files do not exist, it means nothing needs to be added for a given target or host. Most targets need a few `t-TARGET' fragments, but needing `x-HOST' fragments is rare. * Menu: * Target Fragment:: Writing `t-TARGET' files. * Host Fragment:: Writing `x-HOST' files.  File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments Target Makefile Fragments ========================= Target makefile fragments can set these Makefile variables. `LIBGCC2_CFLAGS' Compiler flags to use when compiling `libgcc2.c'. `LIB2FUNCS_EXTRA' A list of source file names to be compiled or assembled and inserted into `libgcc.a'. `Floating Point Emulation' To have GCC include software floating point libraries in `libgcc.a' define `FPBIT' and `DPBIT' along with a few rules as follows: # We want fine grained libraries, so use the new code # to build the floating point emulation libraries. FPBIT = fp-bit.c DPBIT = dp-bit.c fp-bit.c: $(srcdir)/config/fp-bit.c echo '#define FLOAT' > fp-bit.c cat $(srcdir)/config/fp-bit.c >> fp-bit.c dp-bit.c: $(srcdir)/config/fp-bit.c cat $(srcdir)/config/fp-bit.c > dp-bit.c You may need to provide additional #defines at the beginning of `fp-bit.c' and `dp-bit.c' to control target endianness and other options. `CRTSTUFF_T_CFLAGS' Special flags used when compiling `crtstuff.c'. *Note Initialization::. `CRTSTUFF_T_CFLAGS_S' Special flags used when compiling `crtstuff.c' for shared linking. Used if you use `crtbeginS.o' and `crtendS.o' in `EXTRA-PARTS'. *Note Initialization::. `MULTILIB_OPTIONS' For some targets, invoking GCC in different ways produces objects that can not be linked together. For example, for some targets GCC produces both big and little endian code. For these targets, you must arrange for multiple versions of `libgcc.a' to be compiled, one for each set of incompatible options. When GCC invokes the linker, it arranges to link in the right version of `libgcc.a', based on the command line options used. The `MULTILIB_OPTIONS' macro lists the set of options for which special versions of `libgcc.a' must be built. Write options that are mutually incompatible side by side, separated by a slash. Write options that may be used together separated by a space. The build procedure will build all combinations of compatible options. For example, if you set `MULTILIB_OPTIONS' to `m68000/m68020 msoft-float', `Makefile' will build special versions of `libgcc.a' using the following sets of options: `-m68000', `-m68020', `-msoft-float', `-m68000 -msoft-float', and `-m68020 -msoft-float'. `MULTILIB_DIRNAMES' If `MULTILIB_OPTIONS' is used, this variable specifies the directory names that should be used to hold the various libraries. Write one element in `MULTILIB_DIRNAMES' for each element in `MULTILIB_OPTIONS'. If `MULTILIB_DIRNAMES' is not used, the default value will be `MULTILIB_OPTIONS', with all slashes treated as spaces. For example, if `MULTILIB_OPTIONS' is set to `m68000/m68020 msoft-float', then the default value of `MULTILIB_DIRNAMES' is `m68000 m68020 msoft-float'. You may specify a different value if you desire a different set of directory names. `MULTILIB_MATCHES' Sometimes the same option may be written in two different ways. If an option is listed in `MULTILIB_OPTIONS', GCC needs to know about any synonyms. In that case, set `MULTILIB_MATCHES' to a list of items of the form `option=option' to describe all relevant synonyms. For example, `m68000=mc68000 m68020=mc68020'. `MULTILIB_EXCEPTIONS' Sometimes when there are multiple sets of `MULTILIB_OPTIONS' being specified, there are combinations that should not be built. In that case, set `MULTILIB_EXCEPTIONS' to be all of the switch exceptions in shell case syntax that should not be built. For example, in the PowerPC embedded ABI support, it is not desirable to build libraries compiled with the `-mcall-aix' option and either of the `-fleading-underscore' or `-mlittle' options at the same time. Therefore `MULTILIB_EXCEPTIONS' is set to *mcall-aix/*fleading-underscore* *mlittle/*mcall-aix* `MULTILIB_EXTRA_OPTS' Sometimes it is desirable that when building multiple versions of `libgcc.a' certain options should always be passed on to the compiler. In that case, set `MULTILIB_EXTRA_OPTS' to be the list of options to be used for all builds.  File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments Host Makefile Fragments ======================= The use of `x-HOST' fragments is discouraged. You should do so only if there is no other mechanism to get the behavior desired. Host fragments should never forcibly override variables set by the configure script, as they may have been adjusted by the user. Variables provided for host fragments to set include: `X_CFLAGS' `X_CPPFLAGS' These are extra flags to pass to the C compiler and preprocessor, respectively. They are used both when building GCC, and when compiling things with the just-built GCC. `XCFLAGS' These are extra flags to use when building the compiler. They are not used when compiling `libgcc.a'. However, they _are_ used when recompiling the compiler with itself in later stages of a bootstrap. `BOOT_LDFLAGS' Flags to be passed to the linker when recompiling the compiler with itself in later stages of a bootstrap. You might need to use this if, for instance, one of the front ends needs more text space than the linker provides by default. `EXTRA_PROGRAMS' A list of additional programs required to use the compiler on this host, which should be compiled with GCC and installed alongside the front ends. If you set this variable, you must also provide rules to build the extra programs.  File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top `collect2' ********** GNU CC uses a utility called `collect2' on nearly all systems to arrange to call various initialization functions at start time. The program `collect2' works by linking the program once and looking through the linker output file for symbols with particular names indicating they are constructor functions. If it finds any, it creates a new temporary `.c' file containing a table of them, compiles it, and links the program a second time including that file. The actual calls to the constructors are carried out by a subroutine called `__main', which is called (automatically) at the beginning of the body of `main' (provided `main' was compiled with GNU CC). Calling `__main' is necessary, even when compiling C code, to allow linking C and C++ object code together. (If you use `-nostdlib', you get an unresolved reference to `__main', since it's defined in the standard GCC library. Include `-lgcc' at the end of your compiler command line to resolve this reference.) The program `collect2' is installed as `ld' in the directory where the passes of the compiler are installed. When `collect2' needs to find the _real_ `ld', it tries the following file names: * `real-ld' in the directories listed in the compiler's search directories. * `real-ld' in the directories listed in the environment variable `PATH'. * The file specified in the `REAL_LD_FILE_NAME' configuration macro, if specified. * `ld' in the compiler's search directories, except that `collect2' will not execute itself recursively. * `ld' in `PATH'. "The compiler's search directories" means all the directories where `gcc' searches for passes of the compiler. This includes directories that you specify with `-B'. Cross-compilers search a little differently: * `real-ld' in the compiler's search directories. * `TARGET-real-ld' in `PATH'. * The file specified in the `REAL_LD_FILE_NAME' configuration macro, if specified. * `ld' in the compiler's search directories. * `TARGET-ld' in `PATH'. `collect2' explicitly avoids running `ld' using the file name under which `collect2' itself was invoked. In fact, it remembers up a list of such names--in case one copy of `collect2' finds another copy (or version) of `collect2' installed as `ld' in a second place in the search path. `collect2' searches for the utilities `nm' and `strip' using the same algorithm as above for `ld'.  File: gccint.info, Node: Header Dirs, Next: Funding, Prev: Collect2, Up: Top Standard Header File Directories ******************************** `GCC_INCLUDE_DIR' means the same thing for native and cross. It is where GNU CC stores its private include files, and also where GNU CC stores the fixed include files. A cross compiled GNU CC runs `fixincludes' on the header files in `$(tooldir)/include'. (If the cross compilation header files need to be fixed, they must be installed before GNU CC is built. If the cross compilation header files are already suitable for ISO C and GNU CC, nothing special need be done). `GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It is where `g++' looks first for header files. The C++ library installs only target independent header files in that directory. `LOCAL_INCLUDE_DIR' is used only by native compilers. GNU CC doesn't install anything there. It is normally `/usr/local/include'. This is where local additions to a packaged system should place header files. `CROSS_INCLUDE_DIR' is used only by cross compilers. GNU CC doesn't install anything there. `TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is the place for other packages to install header files that GNU CC will use. For a cross-compiler, this is the equivalent of `/usr/include'. When you build a cross-compiler, `fixincludes' processes any header files in this directory.