n 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. If this macro is not defined, the default value, 1, is used. You need not define `STORE_FLAG_VALUE' if the machine has no store-flag instructions, or if the value generated by these instructions is 1. -- Macro: 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 machines that have comparison operations that return floating-point values. If there are no such operations, do not define this macro. -- Macro: VECTOR_STORE_FLAG_VALUE (MODE) A C expression that gives a rtx representing the nonzero true element for vector comparisons. The returned rtx should be valid for the inner mode of MODE which is guaranteed to be a vector mode. Define this macro on machines that have vector comparison operations that return a vector result. If there are no such operations, do not define this macro. Typically, this macro is defined as `const1_rtx' or `constm1_rtx'. This macro may return `NULL_RTX' to prevent the compiler optimizing such vector comparison operations for the given mode. -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE) A C expression that indicates whether the architecture defines a value for `clz' or `ctz' with a zero operand. A result of `0' indicates the value is undefined. If the value is defined for only the RTL expression, the macro should evaluate to `1'; if the value applies also to the corresponding optab entry (which is normally the case if it expands directly into the corresponding RTL), then the macro should evaluate to `2'. In the cases where the value is defined, VALUE should be set to this value. If this macro is not defined, the value of `clz' or `ctz' at zero is assumed to be undefined. This macro must be defined if the target's expansion for `ffs' relies on a particular value to get correct results. Otherwise it is not necessary, though it may be used to optimize some corner cases, and to provide a default expansion for the `ffs' optab. Note that regardless of this macro the "definedness" of `clz' and `ctz' at zero do _not_ extend to the builtin functions visible to the user. Thus one may be free to adjust the value at will to match the target expansion of these operations without fear of breaking the API. -- 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'. -- Macro: FUNCTION_MODE An alias for the machine mode used for memory references to functions being called, in `call' RTL expressions. On most CISC machines, where an instruction can begin at any byte address, this should be `QImode'. On most RISC machines, where all instructions have fixed size and alignment, this should be a mode with the same size and alignment as the machine instruction words - typically `SImode' or `HImode'. -- Macro: 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. -- Macro: 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" {...}'. -- Macro: REGISTER_TARGET_PRAGMAS () 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 `c_register_pragma' or `c_register_pragma_with_expansion' for each pragma. 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 c_register_pragma (const char *SPACE, const char *NAME, void (*CALLBACK) (struct cpp_reader *)) -- Function: void c_register_pragma_with_expansion (const char *SPACE, const char *NAME, void (*CALLBACK) (struct cpp_reader *)) Each call to `c_register_pragma' or `c_register_pragma_with_expansion' 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 `pragma_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'. Macro expansion occurs on the arguments of pragmas registered with `c_register_pragma_with_expansion' but not on the arguments of pragmas registered with `c_register_pragma'. Note that the use of `pragma_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 `pragma_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 `pragma_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. -- Macro: 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. A subtlety for Microsoft Visual C/C++ style bit-field packing (e.g. -mms-bitfields) for targets that support it: When a bit-field is inserted into a packed record, the whole size of the underlying type is used by one or more same-size adjacent bit-fields (that is, if its long:3, 32 bits is used in the record, and any additional adjacent long bit-fields are packed into the same chunk of 32 bits. However, if the size changes, a new field of that size is allocated). If both MS bit-fields and `__attribute__((packed))' are used, the latter will take precedence. If `__attribute__((packed))' is used on a single field when MS bit-fields are in use, it will take precedence for that field, but the alignment of the rest of the structure may affect its placement. 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. -- Macro: 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. -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION Define this macro, as well as `HANDLE_SYSV_PRAGMA', if macros should be expanded in the arguments of `#pragma pack'. -- Macro: TARGET_DEFAULT_PACK_STRUCT If your target requires a structure packing default other than 0 (meaning the machine default), define this macro to the necessary value (in bytes). This must be a value that would also be valid to use with `#pragma pack()' (that is, a small power of two). -- Macro: HANDLE_PRAGMA_PUSH_POP_MACRO Define this macro if you want to support the Win32 style pragmas `#pragma push_macro(macro-name-as-string)' and `#pragma pop_macro(macro-name-as-string)'. The `#pragma push_macro( macro-name-as-string)' pragma saves the named macro and via `#pragma pop_macro(macro-name-as-string)' it will return to the previous value. -- Macro: DOLLARS_IN_IDENTIFIERS Define this macro to control use of the character `$' in identifier names for the C family of languages. 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. -- Macro: 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. -- Macro: 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 `.'. -- Macro: 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. -- Macro: 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. -- Macro: MULTIPLE_SYMBOL_SPACES Define this macro as a C expression that is nonzero 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). You need not define this macro if it would always evaluate to zero. -- Target Hook: tree TARGET_MD_ASM_CLOBBERS (tree OUTPUTS, tree INPUTS, tree CLOBBERS) This target hook should add to CLOBBERS `STRING_CST' trees for any hard regs the port wishes to automatically clobber for an asm. It should return the result of the last `tree_cons' used to add a clobber. The OUTPUTS, INPUTS and CLOBBER lists are the corresponding parameters to the asm and may be inspected to avoid clobbering a register that is an input or output of the asm. You can use `tree_overlaps_hard_reg_set', declared in `tree.h', to test for overlap with regards to asm-declared registers. -- 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. -- Macro: 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. -- Macro: TARGET_POSIX_IO Define this macro if the target supports the following POSIX file functions, access, mkdir and file locking with fcntl / F_SETLKW. Defining `TARGET_POSIX_IO' will enable the test coverage code to use file locking when exiting a program, which avoids race conditions if the program has forked. It will also create directories at run-time for cross-profiling. -- Macro: 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. -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR) Used if the target needs to perform machine-dependent modifications on the conditionals used for turning basic blocks into conditionally executed code. CE_INFO points to a data structure, `struct ce_if_block', which contains information about the currently processed blocks. TRUE_EXPR and FALSE_EXPR are the tests that are used for converting the then-block and the else-block, respectively. Set either TRUE_EXPR or FALSE_EXPR to a null pointer if the tests cannot be converted. -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR, FALSE_EXPR) Like `IFCVT_MODIFY_TESTS', but used when converting more complicated if-statements into conditions combined by `and' and `or' operations. BB contains the basic block that contains the test that is currently being processed and about to be turned into a condition. -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN) A C expression to modify the PATTERN of an INSN that is to be converted to conditional execution format. CE_INFO points to a data structure, `struct ce_if_block', which contains information about the currently processed blocks. -- Macro: IFCVT_MODIFY_FINAL (CE_INFO) A C expression to perform any final machine dependent modifications in converting code to conditional execution. The involved basic blocks can be found in the `struct ce_if_block' structure that is pointed to by CE_INFO. -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO) A C expression to cancel any machine dependent modifications in converting code to conditional execution. The involved basic blocks can be found in the `struct ce_if_block' structure that is pointed to by CE_INFO. -- Macro: IFCVT_INIT_EXTRA_FIELDS (CE_INFO) A C expression to initialize any extra fields in a `struct ce_if_block' structure, which are defined by the `IFCVT_EXTRA_FIELDS' macro. -- Macro: IFCVT_EXTRA_FIELDS If defined, it should expand to a set of field declarations that will be added to the `struct ce_if_block' structure. These should be initialized by the `IFCVT_INIT_EXTRA_FIELDS' macro. -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG () If non-null, this hook performs a target-specific pass over the instruction stream. The compiler will run it at all optimization levels, just before the point at which it normally does delayed-branch scheduling. The exact purpose of the hook varies from target to target. Some use it to do transformations that are necessary for correctness, such as laying out in-function constant pools or avoiding hardware hazards. Others use it as an opportunity to do some machine-dependent optimizations. You need not implement the hook if it has nothing to do. The default definition is null. -- 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 `lang_hooks.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. -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (tree FNDECL, tree ARGLIST) Select a replacement for a machine specific built-in function that was set up by `TARGET_INIT_BUILTINS'. This is done _before_ regular type checking, and so allows the target to implement a crude form of function overloading. FNDECL is the declaration of the built-in function. ARGLIST is the list of arguments passed to the built-in function. The result is a complete expression that implements the operation, usually another `CALL_EXPR'. -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, tree ARGLIST, bool IGNORE) Fold a call to a machine specific built-in function that was set up by `TARGET_INIT_BUILTINS'. FNDECL is the declaration of the built-in function. ARGLIST is the list of arguments passed to the built-in function. The result is another tree containing a simplified expression for the call's result. If IGNORE is true the value will be ignored. -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (rtx INSN) Take an instruction in INSN and return NULL if it is valid within a low-overhead loop, otherwise return a string why doloop could not be applied. Many targets use special registers for low-overhead looping. For any instruction that clobbers these this function should return a string indicating the reason why the doloop could not be applied. By default, the RTL loop optimizer does not use a present doloop pattern for loops containing function calls or branch on table instructions. -- Macro: 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. -- Target Hook: bool TARGET_COMMUTATIVE_P (rtx X, OUTER_CODE) This target hook returns `true' if X is considered to be commutative. Usually, this is just COMMUTATIVE_P (X), but the HP PA doesn't consider PLUS to be commutative inside a MEM. OUTER_CODE is the rtx code of the enclosing rtl, if known, otherwise it is UNKNOWN. -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx 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. `TARGET_ALLOCATE_INITIAL_VALUE' 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 hook, functions that use `REG_N_SETS', to determine if the hard register in question will not be clobbered. The default value of this hook is `NULL', which disables any special allocation. -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned FLAGS) This target hook returns nonzero if X, an `unspec' or `unspec_volatile' operation, might cause a trap. Targets can use this hook to enhance precision of analysis for `unspec' and `unspec_volatile' operations. You may call `may_trap_p_1' to analyze inner elements of X in which case FLAGS should be passed along. -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL) The compiler invokes this hook whenever it changes its current function context (`cfun'). You can define this function if the back end needs to perform any initialization or reset actions on a per-function basis. For example, it may be used to implement function attributes that affect register usage or code generation patterns. The argument DECL is the declaration for the new function context, and may be null to indicate that the compiler has left a function context and is returning to processing at the top level. The default hook function does nothing. GCC sets `cfun' to a dummy function context during initialization of some parts of the back end. The hook function is not invoked in this situation; you need not worry about the hook being invoked recursively, or when the back end is in a partially-initialized state. -- Macro: 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. -- Macro: 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. -- Macro: 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. -- Macro: MODIFY_JNI_METHOD_CALL (MDECL) Define this macro to a C expression representing a variant of the method call MDECL, if Java Native Interface (JNI) methods must be invoked differently from other methods on your target. For example, on 32-bit Microsoft Windows, JNI methods must be invoked using the `stdcall' calling convention and this macro is then defined as this expression: build_type_attribute_variant (MDECL, build_tree_list (get_identifier ("stdcall"), NULL)) -- 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); } -- Target Hook: int TARGET_BRANCH_TARGET_REGISTER_CLASS (void) This target hook returns a register class for which branch target register optimizations should be applied. All registers in this class should be usable interchangeably. After reload, registers in this class will be re-allocated and loads will be hoisted out of loops and be subjected to inter-block scheduling. -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool AFTER_PROLOGUE_EPILOGUE_GEN) Branch target register optimization will by default exclude callee-saved registers that are not already live during the current function; if this target hook returns true, they will be included. The target code must than make sure that all target registers in the class returned by `TARGET_BRANCH_TARGET_REGISTER_CLASS' that might need saving are saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates if prologues and epilogues have already been generated. Note, even if you only return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, you still are likely to have to make special provisions in `INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved target registers. -- Macro: POWI_MAX_MULTS If defined, this macro is interpreted as a signed integer C expression that specifies the maximum number of floating point multiplications that should be emitted when expanding exponentiation by an integer constant inline. When this value is defined, exponentiation requiring more than this number of multiplications is implemented by calling the system library's `pow', `powf' or `powl' routines. The default value places no upper bound on the multiplication count. -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char *IPREFIX, int STDINC) This target hook should register any extra include files for the target. The parameter STDINC indicates if normal include files are present. The parameter SYSROOT is the system root directory. The parameter IPREFIX is the prefix for the gcc directory. -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const char *IPREFIX, int STDINC) This target hook should register any extra include files for the target before any standard headers. The parameter STDINC indicates if normal include files are present. The parameter SYSROOT is the system root directory. The parameter IPREFIX is the prefix for the gcc directory. -- Macro: void TARGET_OPTF (char *PATH) This target hook should register special include paths for the target. The parameter PATH is the include to register. On Darwin systems, this is used for Framework includes, which have semantics that are different from `-I'. -- Target Hook: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL) This target hook returns `true' if it is safe to use a local alias for a virtual function FNDECL when constructing thunks, `false' otherwise. By default, the hook returns `true' for all functions, if a target supports aliases (i.e. defines `ASM_OUTPUT_DEF'), `false' otherwise, -- Macro: TARGET_FORMAT_TYPES If defined, this macro is the name of a global variable containing target-specific format checking information for the `-Wformat' option. The default is to have no target-specific format checks. -- Macro: TARGET_N_FORMAT_TYPES If defined, this macro is the number of entries in `TARGET_FORMAT_TYPES'. -- Target Hook: bool TARGET_RELAXED_ORDERING If set to `true', means that the target's memory model does not guarantee that loads which do not depend on one another will access main memory in the order of the instruction stream; if ordering is important, an explicit memory barrier must be used. This is true of many recent processors which implement a policy of "relaxed," "weak," or "release" memory consistency, such as Alpha, PowerPC, and ia64. The default is `false'. -- Target Hook: const char *TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN (tree TYPELIST, tree FUNCDECL, tree VAL) If defined, this macro returns the diagnostic message when it is illegal to pass argument VAL to function FUNCDECL with prototype TYPELIST. -- Target Hook: const char * TARGET_INVALID_CONVERSION (tree FROMTYPE, tree TOTYPE) If defined, this macro returns the diagnostic message when it is invalid to convert from FROMTYPE to TOTYPE, or `NULL' if validity should be determined by the front end. -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, tree TYPE) If defined, this macro returns the diagnostic message when it is invalid to apply operation OP (where unary plus is denoted by `CONVERT_EXPR') to an operand of type TYPE, or `NULL' if validity should be determined by the front end. -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, tree TYPE1, tree TYPE2) If defined, this macro returns the diagnostic message when it is invalid to apply operation OP to operands of types TYPE1 and TYPE2, or `NULL' if validity should be determined by the front end. -- Macro: TARGET_USE_JCR_SECTION This macro determines whether to use the JCR section to register Java classes. By default, TARGET_USE_JCR_SECTION is defined to 1 if both SUPPORTS_WEAK and TARGET_HAVE_NAMED_SECTIONS are true, else 0. -- Macro: OBJC_JBLEN This macro determines the size of the objective C jump buffer for the NeXT runtime. By default, OBJC_JBLEN is defined to an innocuous value. -- Macro: LIBGCC2_UNWIND_ATTRIBUTE Define this macro if any target-specific attributes need to be attached to the functions in `libgcc' that provide low-level support for call stack unwinding. It is used in declarations in `unwind-generic.h' and the associated definitions of those functions.  File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top 16 Host Configuration ********************* Most details about the machine and system on which the compiler is actually running are detected by the `configure' script. Some things are impossible for `configure' to detect; these are described in two ways, either by macros defined in a file named `xm-MACHINE.h' or by hook functions in the file specified by the OUT_HOST_HOOK_OBJ variable in `config.gcc'. (The intention is that very few hosts will need a header file but nearly every fully supported host will need to override some hooks.) If you need to define only a few 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::. * Menu: * Host Common:: Things every host probably needs implemented. * Filesystem:: Your host can't have the letter `a' in filenames? * Host Misc:: Rare configuration options for hosts.  File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config 16.1 Host Common ================ Some things are just not portable, even between similar operating systems, and are too difficult for autoconf to detect. They get implemented using hook functions in the file specified by the HOST_HOOK_OBJ variable in `config.gcc'. -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void) This host hook is used to set up handling for extra signals. The most common thing to do in this hook is to detect stack overflow. -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int FD) This host hook returns the address of some space that is likely to be free in some subsequent invocation of the compiler. We intend to load the PCH data at this address such that the data need not be relocated. The area should be able to hold SIZE bytes. If the host uses `mmap', FD is an open file descriptor that can be used for probing. -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, size_t SIZE, int FD, size_t OFFSET) This host hook is called when a PCH file is about to be loaded. We want to load SIZE bytes from FD at OFFSET into memory at ADDRESS. The given address will be the result of a previous invocation of `HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we couldn't allocate SIZE bytes at ADDRESS. Return 0 if the memory is allocated but the data is not loaded. Return 1 if the hook has performed everything. If the implementation uses reserved address space, free any reserved space beyond SIZE, regardless of the return value. If no PCH will be loaded, this hook may be called with SIZE zero, in which case all reserved address space should be freed. Do not try to handle values of ADDRESS that could not have been returned by this executable; just return -1. Such values usually indicate an out-of-date PCH file (built by some other GCC executable), and such a PCH file won't work. -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void); This host hook returns the alignment required for allocating virtual memory. Usually this is the same as getpagesize, but on some hosts the alignment for reserving memory differs from the pagesize for committing memory.  File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config 16.2 Host Filesystem ==================== GCC needs to know a number of things about the semantics of the host machine's filesystem. Filesystems with Unix and MS-DOS semantics are automatically detected. For other systems, you can define the following macros in `xm-MACHINE.h'. `HAVE_DOS_BASED_FILE_SYSTEM' This macro is automatically defined by `system.h' 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. `DIR_SEPARATOR' `DIR_SEPARATOR_2' If defined, these macros expand to character constants specifying separators for directory names within a file specification. `system.h' will automatically give them appropriate values on Unix and MS-DOS file systems. If your file system is neither of these, define one or both appropriately in `xm-MACHINE.h'. However, operating systems like VMS, where constructing a pathname is more complicated than just stringing together directory names separated by a special character, should not define either of these macros. `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, but not always, use semicolon (`;'). `VMS' Define this macro if the host system is VMS. `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. `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. `DELETE_IF_ORDINARY' Define this macro to be a C statement (sans semicolon) that performs host-dependent removal of ordinary temp files in the compilation driver. If you do not define this macro, GCC will use the default version. You should define this macro if the default version does not reliably remove the temp file as, for example, on VMS which allows multiple versions of a file. `HOST_LACKS_INODE_NUMBERS' Define this macro if the host filesystem does not report meaningful inode numbers in struct stat.  File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config 16.3 Host Misc ============== `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. `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. `HOST_LONG_LONG_FORMAT' If defined, the string used to indicate an argument of type `long long' to functions like `printf'. The default value is `"ll"'. 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'.  File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top 17 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' (and occasionally `config.build' and `config.host'); *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 17.1 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 the ARM processor cannot execute both hardware floating point instructions and the reduced size THUMB instructions at the same time, so there is no need to build libraries with both of these options enabled. Therefore `MULTILIB_EXCEPTIONS' is set to: *mthumb/*mhard-float* `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. If you set this, you should probably set `CRTSTUFF_T_CFLAGS' to a dash followed by it. `NATIVE_SYSTEM_HEADER_DIR' If the default location for system headers is not `/usr/include', you must set this to the directory containing the headers. This value should match the value of the `SYSTEM_INCLUDE_DIR' macro. `SPECS' Unfortunately, setting `MULTILIB_EXTRA_OPTS' is not enough, since it does not affect the build of target libraries, at least not the build of the default multilib. One possible work-around is to use `DRIVER_SELF_SPECS' to bring options from the `specs' file as if they had been passed in the compiler driver command line. However, you don't want to be adding these options after the toolchain is installed, so you can instead tweak the `specs' file that will be used during the toolchain build, while you still install the original, built-in `specs'. The trick is to set `SPECS' to some other filename (say `specs.install'), that will then be created out of the built-in specs, and introduce a `Makefile' rule to generate the `specs' file that's going to be used at build time out of your `specs.install'.  File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments 17.2 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 18 `collect2' ************* GCC 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: Type Information, Prev: Collect2, Up: Top 19 Standard Header File Directories *********************************** `GCC_INCLUDE_DIR' means the same thing for native and cross. It is where GCC stores its private include files, and also where GCC stores the fixed include files. A cross compiled GCC runs `fixincludes' on the header files in `$(tooldir)/include'. (If the cross compilation header files need to be fixed, they must be installed before GCC is built. If the cross compilation header files are already suitable for GCC, 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. GCC 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. GCC 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 GCC 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.  File: gccint.info, Node: Type Information, Next: Funding, Prev: Header Dirs, Up: Top 20 Memory Management and Type Information ***************************************** GCC uses some fairly sophisticated memory management techniques, which involve determining information about GCC's data structures from GCC's source code and using this information to perform garbage collection and implement precompiled headers. A full C parser would be too complicated for this task, so a limited subset of C is interpreted and special markers are used to determine what parts of the source to look at. All `struct' and `union' declarations that define data structures that are allocated under control of the garbage collector must be marked. All global variables that hold pointers to garbage-collected memory must also be marked. Finally, all global variables that need to be saved and restored by a precompiled header must be marked. (The precompiled header mechanism can only save static variables if they're scalar. Complex data structures must be allocated in garbage-collected memory to be saved in a precompiled header.) The full format of a marker is GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...)) but in most cases no options are needed. The outer double parentheses are still necessary, though: `GTY(())'. Markers can appear: * In a structure definition, before the open brace; * In a global variable declaration, after the keyword `static' or `extern'; and * In a structure field definition, before the name of the field. Here are some examples of marking simple data structures and globals. struct TAG GTY(()) { FIELDS... }; typedef struct TAG GTY(()) { FIELDS... } *TYPENAME; static GTY(()) struct TAG *LIST; /* points to GC memory */ static GTY(()) int COUNTER; /* save counter in a PCH */ The parser understands simple typedefs such as `typedef struct TAG *NAME;' and `typedef int NAME;'. These don't need to be marked. * Menu: * GTY Options:: What goes inside a `GTY(())'. * GGC Roots:: Making global variables GGC roots. * Files:: How the generated files work.  File: gccint.info, Node: GTY Options, Next: GGC Roots, Up: Type Information 20.1 The Inside of a `GTY(())' ============================== Sometimes the C code is not enough to fully describe the type structure. Extra information can be provided with `GTY' options and additional markers. Some options take a parameter, which may be either a string or a type name, depending on the parameter. If an option takes no parameter, it is acceptable either to omit the parameter entirely, or to provide an empty string as a parameter. For example, `GTY ((skip))' and `GTY ((skip ("")))' are equivalent. When the parameter is a string, often it is a fragment of C code. Four special escapes may be used in these strings, to refer to pieces of the data structure being marked: `%h' The current structure. `%1' The structure that immediately contains the current structure. `%0' The outermost structure that contains the current structure. `%a' A partial expression of the form `[i1][i2]...' that indexes the array item currently being marked. For instance, suppose that you have a structure of the form struct A { ... }; struct B { struct A foo[12]; }; and `b' is a variable of type `struct B'. When marking `b.foo[11]', `%h' would expand to `b.foo[11]', `%0' and `%1' would both expand to `b', and `%a' would expand to `[11]'. As in ordinary C, adjacent strings will be concatenated; this is helpful when you have a complicated expression. GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE" " ? TYPE_NEXT_VARIANT (&%h.generic)" " : TREE_CHAIN (&%h.generic)"))) The available options are: `length ("EXPRESSION")' There are two places the type machinery will need to be explicitly told the length of an array. The first case is when a structure ends in a variable-length array, like this: struct rtvec_def GTY(()) { int num_elem; /* number of elements */ rtx GTY ((length ("%h.num_elem"))) elem[1]; }; In this case, the `length' option is used to override the specified array length (which should usually be `1'). The parameter of the option is a fragment of C code that calculates the length. The second case is when a structure or a global variable contains a pointer to an array, like this: tree * GTY ((length ("%h.regno_pointer_align_length"))) regno_decl; In this case, `regno_decl' has been allocated by writing something like x->regno_decl = ggc_alloc (x->regno_pointer_align_length * sizeof (tree)); and the `length' provides the length of the field. This second use of `length' also works on global variables, like: static GTY((length ("reg_base_value_size"))) rtx *reg_base_value; `skip' If `skip' is applied to a field, the type machinery will ignore it. This is somewhat dangerous; the only safe use is in a union when one field really isn't ever used. `desc ("EXPRESSION")' `tag ("CONSTANT")' `default' The type machinery needs to be told which field of a `union' is currently active. This is done by giving each field a constant `tag' value, and then specifying a discriminator using `desc'. The value of the expression given by `desc' is compared against each `tag' value, each of which should be different. If no `tag' is matched, the field marked with `default' is used if there is one, otherwise no field in the union will be marked. In the `desc' option, the "current structure" is the union that it discriminates. Use `%1' to mean the structure containing it. There are no escapes available to the `tag' option, since it is a constant. For example, struct tree_binding GTY(()) { struct tree_common common; union tree_binding_u { tree GTY ((tag ("0"))) scope; struct cp_binding_level * GTY ((tag ("1"))) level; } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope; tree value; }; In this example, the value of BINDING_HAS_LEVEL_P when applied to a `struct tree_binding *' is presumed to be 0 or 1. If 1, the type mechanism will treat the field `level' as being present and if 0, will treat the field `scope' as being present. `param_is (TYPE)' `use_param' Sometimes it's convenient to define some data structure to work on generic pointers (that is, `PTR') and then use it with a specific type. `param_is' specifies the real type pointed to, and `use_param' says where in the generic data structure that type should be put. For instance, to have a `htab_t' that points to trees, one would write the definition of `htab_t' like this: typedef struct GTY(()) { ... void ** GTY ((use_param, ...)) entries; ... } htab_t; and then declare variables like this: static htab_t GTY ((param_is (union tree_node))) ict; `paramN_is (TYPE)' `use_paramN' In more complicated cases, the data structure might need to work on several different types, which might not necessarily all be pointers. For this, `param1_is' through `param9_is' may be used to specify the real type of a field identified by `use_param1' through `use_param9'. `use_params' When a structure contains another structure that is parameterized, there's no need to do anything special, the inner structure inherits the parameters of the outer one. When a structure contains a pointer to a parameterized structure, the type machinery won't automatically detect this (it could, it just doesn't yet), so it's necessary to tell it that the pointed-to structure should use the same parameters as the outer structure. This is done by