X-Git-Url: https://oss.titaniummirror.com/gitweb?a=blobdiff_plain;f=gcc%2Fdoc%2Fgccint.info-20;fp=gcc%2Fdoc%2Fgccint.info-20;h=0000000000000000000000000000000000000000;hb=6fed43773c9b0ce596dca5686f37ac3fc0fa11c0;hp=0939fc154a5a9ada1cfcb0615336a5e1b1bac7c4;hpb=27b11d56b743098deb193d510b337ba22dc52e5c;p=msp430-gcc.git diff --git a/gcc/doc/gccint.info-20 b/gcc/doc/gccint.info-20 deleted file mode 100644 index 0939fc15..00000000 --- a/gcc/doc/gccint.info-20 +++ /dev/null @@ -1,1110 +0,0 @@ -This is doc/gccint.info, produced by makeinfo version 4.5 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. -