+++ /dev/null
-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.
-
-\1f
-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.
-
-\1f
-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
- <gcc@gcc.gnu.org>.
-
- 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(<n>)' and `#pragma weak <name> [=<value>]'
- 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);
- }
-
-\1f
-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::.
-
-\1f
-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.
-
-\1f
-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.
-
-\1f
-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.
-
-
-\1f
-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'.
-
-\1f
-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.
-
projects / msp430-gcc.git / blobdiff