This is ../../gcc-3.4/gcc/doc/gccint.info, produced by makeinfo version
4.2 from ../../gcc-3.4/gcc/doc/gccint.texi.

Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
1999, 2000, 2001, 2002, 2003 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.2 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.
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

File: gccint.info,  Node: Mode Switching,  Next: Target Attributes,  Prev: Floating Point,  Up: Target Macros

Mode Switching Instructions
===========================

   The following macros control mode switching optimizations:

 - Macro: OPTIMIZE_MODE_SWITCHING (ENTITY)
     Define this macro if the port needs extra instructions inserted
     for mode switching in an optimizing compilation.

     For an example, the SH4 can perform both single and double
     precision floating point operations, but to perform a single
     precision operation, the FPSCR PR bit has to be cleared, while for
     a double precision operation, this bit has to be set.  Changing
     the PR bit requires a general purpose register as a scratch
     register, hence these FPSCR sets have to be inserted before
     reload, i.e. you can't put this into instruction emitting or
     `TARGET_MACHINE_DEPENDENT_REORG'.

     You can have multiple entities that are mode-switched, and select
     at run time which entities actually need it.
     `OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY
     that needs mode-switching.  If you define this macro, you also
     have to define `NUM_MODES_FOR_MODE_SWITCHING', `MODE_NEEDED',
     `MODE_PRIORITY_TO_MODE' and `EMIT_MODE_SET'.  `NORMAL_MODE' is
     optional.

 - Macro: NUM_MODES_FOR_MODE_SWITCHING
     If you define `OPTIMIZE_MODE_SWITCHING', you have to define this as
     initializer for an array of integers.  Each initializer element N
     refers to an entity that needs mode switching, and specifies the
     number of different modes that might need to be set for this
     entity.  The position of the initializer in the initializer -
     starting counting at zero - determines the integer that is used to
     refer to the mode-switched entity in question.  In macros that
     take mode arguments / yield a mode result, modes are represented
     as numbers 0 ... N - 1.  N is used to specify that no mode switch
     is needed / supplied.

 - Macro: MODE_NEEDED (ENTITY, INSN)
     ENTITY is an integer specifying a mode-switched entity.  If
     `OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to
     return an integer value not larger than the corresponding element
     in `NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY
     must be switched into prior to the execution of INSN.

 - Macro: NORMAL_MODE (ENTITY)
     If this macro is defined, it is evaluated for every ENTITY that
     needs mode switching.  It should evaluate to an integer, which is
     a mode that ENTITY is assumed to be switched to at function entry
     and exit.

 - Macro: MODE_PRIORITY_TO_MODE (ENTITY, N)
     This macro specifies the order in which modes for ENTITY are
     processed.  0 is the highest priority,
     `NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest.  The value
     of the macro should be an integer designating a mode for ENTITY.
     For any fixed ENTITY, `mode_priority_to_mode' (ENTITY, N) shall be
     a bijection in 0 ...  `num_modes_for_mode_switching[ENTITY] - 1'.

 - Macro: EMIT_MODE_SET (ENTITY, MODE, HARD_REGS_LIVE)
     Generate one or more insns to set ENTITY to MODE.  HARD_REG_LIVE
     is the set of hard registers live at the point where the insn(s)
     are to be inserted.


File: gccint.info,  Node: Target Attributes,  Next: MIPS Coprocessors,  Prev: Mode Switching,  Up: Target Macros

Defining target-specific uses of `__attribute__'
================================================

   Target-specific attributes may be defined for functions, data and
types.  These are described using the following target hooks; they also
need to be documented in `extend.texi'.

 - Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE
     If defined, this target hook points to an array of `struct
     attribute_spec' (defined in `tree.h') specifying the machine
     specific attributes for this target and some of the restrictions
     on the entities to which these attributes are applied and the
     arguments they take.

 - Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (tree TYPE1, tree TYPE2)
     If defined, this target hook is a function which returns zero if
     the attributes on TYPE1 and TYPE2 are incompatible, one if they
     are compatible, and two if they are nearly compatible (which
     causes a warning to be generated).  If this is not defined,
     machine-specific attributes are supposed always to be compatible.

 - Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE)
     If defined, this target hook is a function which assigns default
     attributes to newly defined TYPE.

 - Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree
          TYPE2)
     Define this target hook if the merging of type attributes needs
     special handling.  If defined, the result is a list of the combined
     `TYPE_ATTRIBUTES' of TYPE1 and TYPE2.  It is assumed that
     `comptypes' has already been called and returned 1.  This function
     may call `merge_attributes' to handle machine-independent merging.

 - Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree
          NEWDECL)
     Define this target hook if the merging of decl attributes needs
     special handling.  If defined, the result is a list of the combined
     `DECL_ATTRIBUTES' of OLDDECL and NEWDECL.  NEWDECL is a duplicate
     declaration of OLDDECL.  Examples of when this is needed are when
     one attribute overrides another, or when an attribute is nullified
     by a subsequent definition.  This function may call
     `merge_attributes' to handle machine-independent merging.

     If the only target-specific handling you require is `dllimport' for
     Windows targets, you should define the macro
     `TARGET_DLLIMPORT_DECL_ATTRIBUTES'.  This links in a function
     called `merge_dllimport_decl_attributes' which can then be defined
     as the expansion of `TARGET_MERGE_DECL_ATTRIBUTES'.  This is done
     in `i386/cygwin.h' and `i386/i386.c', for example.

 - Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree
          *ATTR_PTR)
     Define this target hook if you want to be able to add attributes
     to a decl when it is being created.  This is normally useful for
     back ends which wish to implement a pragma by using the attributes
     which correspond to the pragma's effect.  The NODE argument is the
     decl which is being created.  The ATTR_PTR argument is a pointer
     to the attribute list for this decl.  The list itself should not
     be modified, since it may be shared with other decls, but
     attributes may be chained on the head of the list and `*ATTR_PTR'
     modified to point to the new attributes, or a copy of the list may
     be made if further changes are needed.

 - Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (tree FNDECL)
     This target hook returns `true' if it is ok to inline FNDECL into
     the current function, despite its having target-specific
     attributes, `false' otherwise.  By default, if a function has a
     target specific attribute attached to it, it will not be inlined.


File: gccint.info,  Node: MIPS Coprocessors,  Next: Misc,  Prev: Target Attributes,  Up: Target Macros

Defining coprocessor specifics for MIPS targets.
================================================

   The MIPS specification allows MIPS implementations to have as many
as 4 coprocessors, each with as many as 32 private registers.  gcc
supports accessing these registers and transferring values between the
registers and memory using asm-ized variables.  For example:

       register unsigned int cp0count asm ("c0r1");
       unsigned int d;
     
       d = cp0count + 3;

   ("c0r1" is the default name of register 1 in coprocessor 0; alternate
names may be added as described below, or the default names may be
overridden entirely in `SUBTARGET_CONDITIONAL_REGISTER_USAGE'.)

   Coprocessor registers are assumed to be epilogue-used; sets to them
will be preserved even if it does not appear that the register is used
again later in the function.

   Another note: according to the MIPS spec, coprocessor 1 (if present)
is the FPU.  One accesses COP1 registers through standard mips
floating-point support; they are not included in this mechanism.

   There is one macro used in defining the MIPS coprocessor interface
which you may want to override in subtargets; it is described below.

 - Macro: ALL_COP_ADDITIONAL_REGISTER_NAMES
     A comma-separated list (with leading comma) of pairs describing the
     alternate names of coprocessor registers.  The format of each
     entry should be
          { ALTERNATENAME, REGISTER_NUMBER}
     Default: empty.


File: gccint.info,  Node: Misc,  Prev: MIPS Coprocessors,  Up: Target Macros

Miscellaneous Parameters
========================

   Here are several miscellaneous parameters.

 - Macro: 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'.

 - Macro: 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",

 - Macro: CASE_VECTOR_MODE
     An alias for a machine mode name.  This is the machine mode that
     elements of a jump-table should have.

 - Macro: 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.

 - Macro: 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.

 - 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.

 - Macro: 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.

 - Macro: CASE_USE_BIT_TESTS
     Define this macro to be a C expression to indicate whether C switch
     statements may be implemented by a sequence of bit tests.  This is
     advantageous on processors that can efficiently implement left
     shift of 1 by the number of bits held in a register, but
     inappropriate on targets that would require a loop.  By default,
     this macro returns `true' if the target defines an `ashlsi3'
     pattern, and `false' otherwise.

 - Macro: 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.

 - Macro: 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'.

 - Macro: SHORT_IMMEDIATES_SIGN_EXTEND
     Define this macro if loading short immediate values into registers
     sign extends.

 - Macro: 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.

 - Macro: MOVE_MAX
     The maximum number of bytes that a single instruction can move
     quickly between memory and registers or between two memory
     locations.

 - Macro: 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.

 - Macro: 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.

 - Macro: 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.

 - Macro: 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.

     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 machine that have comparison
     operations that return floating-point values.  If there are no
     such operations, do not define this macro.

 - Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
 - Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
     A C expression that evaluates to true if the architecture defines
     a value for `clz' or `ctz' with a zero operand.  If so, VALUE
     should be set to this value.  If this macro is not defined, the
     value of `clz' or `ctz' 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.

     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
     machines this should be `QImode'.

 - Macro: 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.

 - 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' 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 *))
     Each call to `c_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.

 - Macro: 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.

     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: 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: 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'.

 - 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 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).

 - Macro: 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.

 - Macro: 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.

 - 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_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.

 - 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 `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.

 - 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.

 - Macro: 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.

 - 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 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.


File: gccint.info,  Node: Host Config,  Next: Fragments,  Prev: Target Macros,  Up: Top

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

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)
     This host hook returns the address of some space in which a PCH
     may be loaded with `HOST_HOOKS_PCH_LOAD_PCH'.  The space will need
     to have SIZE bytes.  If insufficient space is available, `NULL'
     may be returned; the PCH machinery will try to find a suitable
     address using a heuristic.

     The memory does not have to be available now.  In fact, usually
     `HOST_HOOKS_PCH_LOAD_PCH' will already have been called.  The
     memory need only be available in future invocations of GCC.

 - Host Hook: bool HOST_HOOKS_GT_PCH_USE_ADDRESS (size_t SIZE, void *
          ADDRESS)
     This host hook is called when a PCH file is about to be loaded.  If
     ADDRESS is the address that would have been returned by
     `HOST_HOOKS_PCH_MEMORY_ADDRESS', and SIZE is smaller than the
     maximum than `HOST_HOOKS_PCH_MEMORY_ADDRESS' would have accepted,
     return true, otherwise return false.

     In addition, free any address space reserved that isn't needed to
     hold SIZE bytes (whether or not true is returned).  The PCH
     machinery will use `mmap' with `MAP_FIXED' to load the PCH if
     `HAVE_MMAP_FILE', or will use `fread' otherwise.

     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 false.  Such values
     usually indicate an out-of-date PCH file (built by some other GCC
     executable), and such a PCH file won't work.


File: gccint.info,  Node: Filesystem,  Next: Host Misc,  Prev: Host Common,  Up: Host Config

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.

