This is doc/gcc.info, produced by makeinfo version 4.0 from
doc/gcc.texi.

INFO-DIR-SECTION Programming
START-INFO-DIR-ENTRY
* gcc: (gcc).                  The GNU Compiler Collection.
END-INFO-DIR-ENTRY
   This file documents the use and the internals of the GNU compiler.


   Published by the Free Software Foundation
59 Temple Place - Suite 330
Boston, MA 02111-1307 USA


   Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
1999, 2000, 2001 Free Software Foundation, Inc.


   Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "GNU General Public License" and "Funding Free
Software", the Front-Cover texts being (a) (see below), and with the
Back-Cover Texts being (b) (see below).  A copy of the license is
included in the section entitled "GNU Free Documentation License".

   (a) The FSF's Front-Cover Text is:

   A GNU Manual

   (b) The FSF's Back-Cover Text is:

   You have freedom to copy and modify this GNU Manual, like GNU
software.  Copies published by the Free Software Foundation raise
funds for GNU development.


File: gcc.info,  Node: Misc,  Prev: Mode Switching,  Up: Target Macros

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

   Here are several miscellaneous parameters.

`PREDICATE_CODES'
     Define this if you have defined special-purpose predicates in the
     file `MACHINE.c'.  This macro is called within an initializer of an
     array of structures.  The first field in the structure is the name
     of a predicate and the second field is an array of rtl codes.  For
     each predicate, list all rtl codes that can be in expressions
     matched by the predicate.  The list should have a trailing comma.
     Here is an example of two entries in the list for a typical RISC
     machine:

          #define PREDICATE_CODES \
            {"gen_reg_rtx_operand", {SUBREG, REG}},  \
            {"reg_or_short_cint_operand", {SUBREG, REG, CONST_INT}},

     Defining this macro does not affect the generated code (however,
     incorrect definitions that omit an rtl code that may be matched by
     the predicate can cause the compiler to malfunction).  Instead, it
     allows the table built by `genrecog' to be more compact and
     efficient, thus speeding up the compiler.  The most important
     predicates to include in the list specified by this macro are
     those used in the most insn patterns.

     For each predicate function named in `PREDICATE_CODES', a
     declaration will be generated in `insn-codes.h'.

`SPECIAL_MODE_PREDICATES'
     Define this if you have special predicates that know special things
     about modes.  Genrecog will warn about certain forms of
     `match_operand' without a mode; if the operand predicate is listed
     in `SPECIAL_MODE_PREDICATES', the warning will be suppressed.

     Here is an example from the IA-32 port (`ext_register_operand'
     specially checks for `HImode' or `SImode' in preparation for a
     byte extraction from `%ah' etc.).

          #define SPECIAL_MODE_PREDICATES \
            "ext_register_operand",

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

`CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY)'
     Optional: return the preferred mode for an `addr_diff_vec' when
     the minimum and maximum offset are known.  If you define this, it
     enables extra code in branch shortening to deal with
     `addr_diff_vec'.  To make this work, you also have to define
     INSN_ALIGN and make the alignment for `addr_diff_vec' explicit.
     The BODY argument is provided so that the offset_unsigned and scale
     flags can be updated.

`CASE_VECTOR_PC_RELATIVE'
     Define this macro to be a C expression to indicate when jump-tables
     should contain relative addresses.  If jump-tables never contain
     relative addresses, then you need not define this macro.

`CASE_DROPS_THROUGH'
     Define this if control falls through a `case' insn when the index
     value is out of range.  This means the specified default-label is
     actually ignored by the `case' insn proper.

`CASE_VALUES_THRESHOLD'
     Define this to be the smallest number of different values for
     which it is best to use a jump-table instead of a tree of
     conditional branches.  The default is four for machines with a
     `casesi' instruction and five otherwise.  This is best for most
     machines.

`WORD_REGISTER_OPERATIONS'
     Define this macro if operations between registers with integral
     mode smaller than a word are always performed on the entire
     register.  Most RISC machines have this property and most CISC
     machines do not.

`LOAD_EXTEND_OP (MODE)'
     Define this macro to be a C expression indicating when insns that
     read memory in MODE, an integral mode narrower than a word, set the
     bits outside of MODE to be either the sign-extension or the
     zero-extension of the data read.  Return `SIGN_EXTEND' for values
     of MODE for which the insn sign-extends, `ZERO_EXTEND' for which
     it zero-extends, and `NIL' for other modes.

     This macro is not called with MODE non-integral or with a width
     greater than or equal to `BITS_PER_WORD', so you may return any
     value in this case.  Do not define this macro if it would always
     return `NIL'.  On machines where this macro is defined, you will
     normally define it as the constant `SIGN_EXTEND' or `ZERO_EXTEND'.

`SHORT_IMMEDIATES_SIGN_EXTEND'
     Define this macro if loading short immediate values into registers
     sign extends.

`IMPLICIT_FIX_EXPR'
     An alias for a tree code that should be used by default for
     conversion of floating point values to fixed point.  Normally,
     `FIX_ROUND_EXPR' is used.

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

`EASY_DIV_EXPR'
     An alias for a tree code that is the easiest kind of division to
     compile code for in the general case.  It may be `TRUNC_DIV_EXPR',
     `FLOOR_DIV_EXPR', `CEIL_DIV_EXPR' or `ROUND_DIV_EXPR'.  These four
     division operators differ in how they round the result to an
     integer.  `EASY_DIV_EXPR' is used when it is permissible to use
     any of those kinds of division and the choice should be made on
     the basis of efficiency.

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

`MAX_MOVE_MAX'
     The maximum number of bytes that a single instruction can move
     quickly between memory and registers or between two memory
     locations.  If this is undefined, the default is `MOVE_MAX'.
     Otherwise, it is the constant value that is the largest value that
     `MOVE_MAX' can have at run-time.

`SHIFT_COUNT_TRUNCATED'
     A C expression that is nonzero if on this machine the number of
     bits actually used for the count of a shift operation is equal to
     the number of bits needed to represent the size of the object
     being shifted.  When this macro is nonzero, the compiler will
     assume that it is safe to omit a sign-extend, zero-extend, and
     certain bitwise `and' instructions that truncates the count of a
     shift operation.  On machines that have instructions that act on
     bit-fields at variable positions, which may include `bit test'
     instructions, a nonzero `SHIFT_COUNT_TRUNCATED' also enables
     deletion of truncations of the values that serve as arguments to
     bit-field instructions.

     If both types of instructions truncate the count (for shifts) and
     position (for bit-field operations), or if no variable-position
     bit-field instructions exist, you should define this macro.

     However, on some machines, such as the 80386 and the 680x0,
     truncation only applies to shift operations and not the (real or
     pretended) bit-field operations.  Define `SHIFT_COUNT_TRUNCATED'
     to be zero on such machines.  Instead, add patterns to the `md'
     file that include the implied truncation of the shift instructions.

     You need not define this macro if it would always have the value
     of zero.

`TRULY_NOOP_TRUNCATION (OUTPREC, INPREC)'
     A C expression which is nonzero if on this machine it is safe to
     "convert" an integer of INPREC bits to one of OUTPREC bits (where
     OUTPREC is smaller than INPREC) by merely operating on it as if it
     had only OUTPREC bits.

     On many machines, this expression can be 1.

     When `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for
     modes for which `MODES_TIEABLE_P' is 0, suboptimal code can result.
     If this is the case, making `TRULY_NOOP_TRUNCATION' return 0 in
     such cases may improve things.

`STORE_FLAG_VALUE'
     A C expression describing the value returned by a comparison
     operator with an integral mode and stored by a store-flag
     instruction (`sCOND') when the condition is true.  This
     description must apply to _all_ the `sCOND' patterns and all the
     comparison operators whose results have a `MODE_INT' mode.

     A value of 1 or -1 means that the instruction implementing the
     comparison operator returns exactly 1 or -1 when the comparison is
     true and 0 when the comparison is false.  Otherwise, the value
     indicates which bits of the result are guaranteed to be 1 when the
     comparison is true.  This value is interpreted in the mode of the
     comparison operation, which is given by the mode of the first
     operand in the `sCOND' pattern.  Either the low bit or the sign
     bit of `STORE_FLAG_VALUE' be on.  Presently, only those bits are
     used by the compiler.

     If `STORE_FLAG_VALUE' is neither 1 or -1, the compiler will
     generate code that depends only on the specified bits.  It can also
     replace comparison operators with equivalent operations if they
     cause the required bits to be set, even if the remaining bits are
     undefined.  For example, on a machine whose comparison operators
     return an `SImode' value and where `STORE_FLAG_VALUE' is defined as
     `0x80000000', saying that just the sign bit is relevant, the
     expression

          (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0))

     can be converted to

          (ashift:SI X (const_int N))

     where N is the appropriate shift count to move the bit being
     tested into the sign bit.

     There is no way to describe a machine that always sets the
     low-order bit for a true value, but does not guarantee the value
     of any other bits, but we do not know of any machine that has such
     an instruction.  If you are trying to port GCC to such a machine,
     include an instruction to perform a logical-and of the result with
     1 in the pattern for the comparison operators and let us know
     (*note How to Report Bugs: Bug Reporting.).

     Often, a machine will have multiple instructions that obtain a
     value from a comparison (or the condition codes).  Here are rules
     to guide the choice of value for `STORE_FLAG_VALUE', and hence the
     instructions to be used:

        * Use the shortest sequence that yields a valid definition for
          `STORE_FLAG_VALUE'.  It is more efficient for the compiler to
          "normalize" the value (convert it to, e.g., 1 or 0) than for
          the comparison operators to do so because there may be
          opportunities to combine the normalization with other
          operations.

        * For equal-length sequences, use a value of 1 or -1, with -1
          being slightly preferred on machines with expensive jumps and
          1 preferred on other machines.

        * As a second choice, choose a value of `0x80000001' if
          instructions exist that set both the sign and low-order bits
          but do not define the others.

        * Otherwise, use a value of `0x80000000'.

     Many machines can produce both the value chosen for
     `STORE_FLAG_VALUE' and its negation in the same number of
     instructions.  On those machines, you should also define a pattern
     for those cases, e.g., one matching

          (set A (neg:M (ne:M B C)))

     Some machines can also perform `and' or `plus' operations on
     condition code values with less instructions than the corresponding
     `sCOND' insn followed by `and' or `plus'.  On those machines,
     define the appropriate patterns.  Use the names `incscc' and
     `decscc', respectively, for the patterns which perform `plus' or
     `minus' operations on condition code values.  See `rs6000.md' for
     some examples.  The GNU Superoptizer can be used to find such
     instruction sequences on other machines.

     You need not define `STORE_FLAG_VALUE' if the machine has no
     store-flag instructions.

`FLOAT_STORE_FLAG_VALUE (MODE)'
     A C expression that gives a nonzero `REAL_VALUE_TYPE' value that is
     returned when comparison operators with floating-point results are
     true.  Define this macro on machine that have comparison
     operations that return floating-point values.  If there are no
     such operations, do not define this macro.

`Pmode'
     An alias for the machine mode for pointers.  On most machines,
     define this to be the integer mode corresponding to the width of a
     hardware pointer; `SImode' on 32-bit machine or `DImode' on 64-bit
     machines.  On some machines you must define this to be one of the
     partial integer modes, such as `PSImode'.

     The width of `Pmode' must be at least as large as the value of
     `POINTER_SIZE'.  If it is not equal, you must define the macro
     `POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to
     `Pmode'.

`FUNCTION_MODE'
     An alias for the machine mode used for memory references to
     functions being called, in `call' RTL expressions.  On most
     machines this should be `QImode'.

`INTEGRATE_THRESHOLD (DECL)'
     A C expression for the maximum number of instructions above which
     the function DECL should not be inlined.  DECL is a
     `FUNCTION_DECL' node.

     The default definition of this macro is 64 plus 8 times the number
     of arguments that the function accepts.  Some people think a larger
     threshold should be used on RISC machines.

`SCCS_DIRECTIVE'
     Define this if the preprocessor should ignore `#sccs' directives
     and print no error message.

`NO_IMPLICIT_EXTERN_C'
     Define this macro if the system header files support C++ as well
     as C.  This macro inhibits the usual method of using system header
     files in C++, which is to pretend that the file's contents are
     enclosed in `extern "C" {...}'.

`HANDLE_PRAGMA (GETC, UNGETC, NAME)'
     This macro is no longer supported.  You must use
     `REGISTER_TARGET_PRAGMAS' instead.

`REGISTER_TARGET_PRAGMAS (PFILE)'
     Define this macro if you want to implement any target-specific
     pragmas.  If defined, it is a C expression which makes a series of
     calls to the `cpp_register_pragma' and/or
     `cpp_register_pragma_space' functions.  The PFILE argument is the
     first argument to supply to these functions.  The macro may also
     do 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 the macro
     `INSERT_ATTRIBUTES' might be a useful one to define as well.

     Preprocessor macros that appear on pragma lines are not expanded.
     All `#pragma' directives that do not match any registered pragma
     are silently ignored, unless the user specifies
     `-Wunknown-pragmas'.

      - Function: void cpp_register_pragma (cpp_reader *PFILE, const
               char *SPACE, const char *NAME, void (*CALLBACK)
               (cpp_reader *))
          Each call to `cpp_register_pragma' establishes one pragma.
          The CALLBACK routine will be called when the preprocessor
          encounters a pragma of the form

               #pragma [SPACE] NAME ...

          SPACE must have been the subject of a previous call to
          `cpp_register_pragma_space', or else be a null pointer.  The
          callback routine receives PFILE as its first argument, but
          must not use it for anything (this may change in the future).
          It may read any text after the NAME by making calls to
          `c_lex'.  Text which is not read by the callback will be
          silently ignored.

          Note that both SPACE and NAME are case sensitive.

          For an example use of this routine, see `c4x.h' and the
          callback routines defined in `c4x.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.

      - Function: void cpp_register_pragma_space (cpp_reader *PFILE,
               const char *SPACE)
          This routine establishes a namespace for pragmas, which will
          be registered by subsequent calls to `cpp_register_pragma'.
          For example, pragmas defined by the C standard are in the
          `STDC' namespace, and pragmas specific to GCC are in the
          `GCC' namespace.

          For an example use of this routine in a target header, see
          `v850.h'.

`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 behaviour to the default.

     The weak pragma only works if `SUPPORTS_WEAK' and
     `ASM_WEAKEN_LABEL' are defined.  If enabled it allows the creation
     of specifically named weak labels, optionally with a value.

`HANDLE_PRAGMA_PACK_PUSH_POP'
     Define this macro (to a value of 1) if you want to support the
     Win32 style pragmas `#pragma pack(push,N)' and `#pragma
     pack(pop)'.  The `pack(push,N)' pragma specifies the maximum
     alignment (in bytes) of fields within a structure, in much the
     same way as the `__aligned__' and `__packed__' `__attribute__'s
     do.  A pack value of zero resets the behaviour 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.

`VALID_MACHINE_DECL_ATTRIBUTE (DECL, ATTRIBUTES, IDENTIFIER, ARGS)'
     If defined, a C expression whose value is nonzero if IDENTIFIER
     with arguments ARGS is a valid machine specific attribute for DECL.
     The attributes in ATTRIBUTES have previously been assigned to DECL.

`VALID_MACHINE_TYPE_ATTRIBUTE (TYPE, ATTRIBUTES, IDENTIFIER, ARGS)'
     If defined, a C expression whose value is nonzero if IDENTIFIER
     with arguments ARGS is a valid machine specific attribute for TYPE.
     The attributes in ATTRIBUTES have previously been assigned to TYPE.

`COMP_TYPE_ATTRIBUTES (TYPE1, TYPE2)'
     If defined, a C expression whose value is 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).

`SET_DEFAULT_TYPE_ATTRIBUTES (TYPE)'
     If defined, a C statement that assigns default attributes to newly
     defined TYPE.

`MERGE_MACHINE_TYPE_ATTRIBUTES (TYPE1, TYPE2)'
     Define this macro 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.

`MERGE_MACHINE_DECL_ATTRIBUTES (OLDDECL, NEWDECL)'
     Define this macro if the merging of decl attributes needs special
     handling.  If defined, the result is a list of the combined
     DECL_MACHINE_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.

`INSERT_ATTRIBUTES (NODE, ATTR_PTR, PREFIX_PTR)'
     Define this macro 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 PREFIX_PTR is a pointer
     to the list of attributes that have appeared after the specifiers
     and modifiers of the declaration, but before the declaration
     proper.

`SET_DEFAULT_DECL_ATTRIBUTES (DECL, ATTRIBUTES)'
     If defined, a C statement that assigns default attributes to newly
     defined DECL.

`DOLLARS_IN_IDENTIFIERS'
     Define this macro to control use of the character `$' in identifier
     names.  0 means `$' is not allowed by default; 1 means it is
     allowed.  1 is the default; there is no need to define this macro
     in that case.  This macro controls the compiler proper; it does
     not affect the preprocessor.

`NO_DOLLAR_IN_LABEL'
     Define this macro if the assembler does not accept the character
     `$' in label names.  By default constructors and destructors in
     G++ have `$' in the identifiers.  If this macro is defined, `.' is
     used instead.

`NO_DOT_IN_LABEL'
     Define this macro if the assembler does not accept the character
     `.' in label names.  By default constructors and destructors in G++
     have names that use `.'.  If this macro is defined, these names
     are rewritten to avoid `.'.

`DEFAULT_MAIN_RETURN'
     Define this macro if the target system expects every program's
     `main' function to return a standard "success" value by default
     (if no other value is explicitly returned).

     The definition should be a C statement (sans semicolon) to
     generate the appropriate rtl instructions.  It is used only when
     compiling the end of `main'.

`NEED_ATEXIT'
     Define this if the target system lacks the function `atexit' from
     the ISO C standard.  If this macro is defined, a default definition
     will be provided to support C++.  If `ON_EXIT' is not defined, a
     default `exit' function will also be provided.

`ON_EXIT'
     Define this macro if the target has another way to implement atexit
     functionality without replacing `exit'.  For instance, SunOS 4 has
     a similar `on_exit' library function.

     The definition should be a functional macro which can be used just
     like the `atexit' function.

`EXIT_BODY'
     Define this if your `exit' function needs to do something besides
     calling an external function `_cleanup' before terminating with
     `_exit'.  The `EXIT_BODY' macro is only needed if `NEED_ATEXIT' is
     defined and `ON_EXIT' is not defined.

`INSN_SETS_ARE_DELAYED (INSN)'
     Define this macro as a C expression that is nonzero if it is safe
     for the delay slot scheduler to place instructions in the delay
     slot of INSN, even if they appear to use a resource set or
     clobbered in INSN.  INSN is always a `jump_insn' or an `insn'; GCC
     knows that every `call_insn' has this behavior.  On machines where
     some `insn' or `jump_insn' is really a function call and hence has
     this behavior, you should define this macro.

     You need not define this macro if it would always return zero.

`INSN_REFERENCES_ARE_DELAYED (INSN)'
     Define this macro as a C expression that is nonzero if it is safe
     for the delay slot scheduler to place instructions in the delay
     slot of INSN, even if they appear to set or clobber a resource
     referenced in INSN.  INSN is always a `jump_insn' or an `insn'.
     On machines where some `insn' or `jump_insn' is really a function
     call and its operands are registers whose use is actually in the
     subroutine it calls, you should define this macro.  Doing so
     allows the delay slot scheduler to move instructions which copy
     arguments into the argument registers into the delay slot of INSN.

     You need not define this macro if it would always return zero.

`MACHINE_DEPENDENT_REORG (INSN)'
     In rare cases, correct code generation requires extra machine
     dependent processing between the second jump optimization pass and
     delayed branch scheduling.  On those machines, define this macro
     as a C statement to act on the code starting at INSN.

`MULTIPLE_SYMBOL_SPACES'
     Define this macro if in some cases global symbols from one
     translation unit may not be bound to undefined symbols in another
     translation unit without user intervention.  For instance, under
     Microsoft Windows symbols must be explicitly imported from shared
     libraries (DLLs).

`MD_ASM_CLOBBERS (CLOBBERS)'
     A C statement that adds to CLOBBERS `STRING_CST' trees for any
     hard regs the port wishes to automatically clobber for all asms.

`ISSUE_RATE'
     A C expression that returns how many instructions can be issued at
     the same time if the machine is a superscalar machine.

`MD_SCHED_INIT (FILE, VERBOSE, MAX_READY)'
     A C statement which is executed by the scheduler at the beginning
     of each block of instructions that are to be scheduled.  FILE is
     either a null pointer, or a stdio stream to write any debug output
     to.  VERBOSE is the verbose level provided by `-fsched-verbose-N'.
     MAX_READY is the maximum number of insns in the current
     scheduling region that can be live at the same time.  This can be
     used to allocate scratch space if it is needed.

`MD_SCHED_FINISH (FILE, VERBOSE)'
     A C statement which is executed by the scheduler at the end of
     each block of instructions that are to be scheduled.  It can be
     used to perform cleanup of any actions done by the other
     scheduling macros.  FILE is either a null pointer, or a stdio
     stream to write any debug output to.  VERBOSE is the verbose level
     provided by `-fsched-verbose-N'.

`MD_SCHED_REORDER (FILE, VERBOSE, READY, N_READY, CLOCK, CAN_ISSUE_MORE)'
     A C statement which is executed by the scheduler after it has
     scheduled the ready list to allow the machine description to
     reorder it (for example to combine two small instructions together
     on `VLIW' machines).  FILE is either a null pointer, or a stdio
     stream to write any debug output to.  VERBOSE is the verbose level
     provided by `-fsched-verbose-N'.  READY is a pointer to the ready
     list of instructions that are ready to be scheduled.  N_READY is
     the number of elements in the ready list.  The scheduler reads the
     ready list in reverse order, starting with READY[N_READY-1] and
     going to READY[0].  CLOCK is the timer tick of the scheduler.
     CAN_ISSUE_MORE is an output parameter that is set to the number of
     insns that can issue this clock; normally this is just
     `issue_rate'.  See also `MD_SCHED_REORDER2'.

`MD_SCHED_REORDER2 (FILE, VERBOSE, READY, N_READY, CLOCK, CAN_ISSUE_MORE)'
     Like `MD_SCHED_REORDER', but called at a different time.  While the
     `MD_SCHED_REORDER' macro is called whenever the scheduler starts a
     new cycle, this macro is used immediately after
     `MD_SCHED_VARIABLE_ISSUE' is called; it can reorder the ready list
     and set CAN_ISSUE_MORE to determine whether there are more insns
     to be scheduled in the same cycle.  Defining this macro can be
     useful if there are frequent situations where scheduling one insn
     causes other insns to become ready in the same cycle, these other
     insns can then be taken into account properly.

`MD_SCHED_VARIABLE_ISSUE (FILE, VERBOSE, INSN, MORE)'
     A C statement which is executed by the scheduler after it has
     scheduled an insn from the ready list.  FILE is either a null
     pointer, or a stdio stream to write any debug output to.  VERBOSE
     is the verbose level provided by `-fsched-verbose-N'.  INSN is the
     instruction that was scheduled.  MORE is the number of
     instructions that can be issued in the current cycle.  The
     `MD_SCHED_VARIABLE_ISSUE' macro is responsible for updating the
     value of MORE (typically by `MORE--').

`MAX_INTEGER_COMPUTATION_MODE'
     Define this to the largest integer machine mode which can be used
     for operations other than load, store and copy operations.

     You need only define this macro if the target holds values larger
     than `word_mode' in general purpose registers.  Most targets
     should not define this macro.

`MATH_LIBRARY'
     Define this macro as a C string constant for the linker argument
     to link in the system math library, or `""' if the target does not
     have a separate math library.

     You need only define this macro if the default of `"-lm"' is wrong.

`LIBRARY_PATH_ENV'
     Define this macro as a C string constant for the environment
     variable that specifies where the linker should look for libraries.

     You need only define this macro if the default of `"LIBRARY_PATH"'
     is wrong.

`TARGET_HAS_F_SETLKW'
     Define this macro if the target supports file locking with fcntl /
     F_SETLKW.  Note that this functionality is part of POSIX.
     Defining `TARGET_HAS_F_SETLKW' will enable the test coverage code
     to use file locking when exiting a program, which avoids race
     conditions if the program has forked.

`MAX_CONDITIONAL_EXECUTE'
     A C expression for the maximum number of instructions to execute
     via conditional execution instructions instead of a branch.  A
     value of `BRANCH_COST'+1 is the default if the machine does not
     use cc0, and 1 if it does use cc0.

`IFCVT_MODIFY_TESTS'
     A C expression to modify the tests in `TRUE_EXPR', and
     `FALSE_EXPR' for use in converting insns in `TEST_BB', `THEN_BB',
     `ELSE_BB', and `JOIN_BB' basic blocks to conditional execution.
     Set either `TRUE_EXPR' or `FALSE_EXPR' to a null pointer if the
     tests cannot be converted.

`IFCVT_MODIFY_INSN'
     A C expression to modify the `PATTERN' of an `INSN' that is to be
     converted to conditional execution format.

`IFCVT_MODIFY_FINAL'
     A C expression to perform any final machine dependent
     modifications in converting code to conditional execution in the
     basic blocks `TEST_BB', `THEN_BB', `ELSE_BB', and `JOIN_BB'.

`IFCVT_MODIFY_CANCEL'
     A C expression to cancel any machine dependent modifications in
     converting code to conditional execution in the basic blocks
     `TEST_BB', `THEN_BB', `ELSE_BB', and `JOIN_BB'.

`MD_INIT_BUILTINS'
     Define this macro if you have any machine-specific built-in
     functions that need to be defined.  It should be a C expression
     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
     these two functions will use `MD_INIT_BUILTINS'.

`MD_EXPAND_BUILTIN(EXP, TARGET, SUBTARGET, MODE, IGNORE)'
     Expand a call to a machine specific built-in function that was set
     up by `MD_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 macro should return the
     result of the call to the built-in function.


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

The Configuration File
**********************

   The configuration file `xm-MACHINE.h' contains macro definitions
that describe the machine and system on which the compiler is running,
unlike the definitions in `MACHINE.h', which describe the machine for
which the compiler is producing output.  Most of the values in
`xm-MACHINE.h' are actually the same on all machines that GCC runs on,
so large parts of all configuration files are identical.  But there are
some macros that vary:

`USG'
     Define this macro if the host system is System V.

`VMS'
     Define this macro if the host system is VMS.

`FATAL_EXIT_CODE'
     A C expression for the status code to be returned when the compiler
     exits after serious errors.

`SUCCESS_EXIT_CODE'
     A C expression for the status code to be returned when the compiler
     exits without serious errors.

`HOST_WORDS_BIG_ENDIAN'
     Defined if the host machine stores words of multi-word values in
     big-endian order.  (GCC does not depend on the host byte ordering
     within a word.)

`HOST_FLOAT_WORDS_BIG_ENDIAN'
     Define this macro to be 1 if the host machine stores `DFmode',
     `XFmode' or `TFmode' floating point numbers in memory with the
     word containing the sign bit at the lowest address; otherwise,
     define it to be zero.

     This macro need not be defined if the ordering is the same as for
     multi-word integers.

`HOST_FLOAT_FORMAT'
     A numeric code distinguishing the floating point format for the
     host machine.  See `TARGET_FLOAT_FORMAT' in *Note Storage Layout::
     for the alternatives and default.

`HOST_BITS_PER_CHAR'
     A C expression for the number of bits in `char' on the host
     machine.

`HOST_BITS_PER_SHORT'
     A C expression for the number of bits in `short' on the host
     machine.

`HOST_BITS_PER_INT'
     A C expression for the number of bits in `int' on the host machine.

`HOST_BITS_PER_LONG'
     A C expression for the number of bits in `long' on the host
     machine.

`HOST_BITS_PER_LONGLONG'
     A C expression for the number of bits in `long long' on the host
     machine.

`ONLY_INT_FIELDS'
     Define this macro to indicate that the host compiler only supports
     `int' bit-fields, rather than other integral types, including
     `enum', as do most C compilers.

`OBSTACK_CHUNK_SIZE'
     A C expression for the size of ordinary obstack chunks.  If you
     don't define this, a usually-reasonable default is used.

`OBSTACK_CHUNK_ALLOC'
     The function used to allocate obstack chunks.  If you don't define
     this, `xmalloc' is used.

`OBSTACK_CHUNK_FREE'
     The function used to free obstack chunks.  If you don't define
     this, `free' is used.

`USE_C_ALLOCA'
     Define this macro to indicate that the compiler is running with the
     `alloca' implemented in C.  This version of `alloca' can be found
     in the file `alloca.c'; to use it, you must also alter the
     `Makefile' variable `ALLOCA'.  (This is done automatically for the
     systems on which we know it is needed.)

     If you do define this macro, you should probably do it as follows:

          #ifndef __GNUC__
          #define USE_C_ALLOCA
          #else
          #define alloca __builtin_alloca
          #endif

     so that when the compiler is compiled with GCC it uses the more
     efficient built-in `alloca' function.

`FUNCTION_CONVERSION_BUG'
     Define this macro to indicate that the host compiler does not
     properly handle converting a function value to a
     pointer-to-function when it is used in an expression.

`MULTIBYTE_CHARS'
     Define this macro to enable support for multibyte characters in the
     input to GCC.  This requires that the host system support the ISO C
     library functions for converting multibyte characters to wide
     characters.

`POSIX'
     Define this if your system is POSIX.1 compliant.

`USE_PROTOTYPES'
     Define this to be 1 if you know that the host compiler supports
     prototypes, even if it doesn't define __STDC__, or define it to be
     0 if you do not want any prototypes used in compiling GCC.  If
     `USE_PROTOTYPES' is not defined, it will be determined
     automatically whether your compiler supports prototypes by
     checking if `__STDC__' is defined.

`PATH_SEPARATOR'
     Define this macro to be a C character constant representing the
     character used to separate components in paths.  The default value
     is the colon character

`DIR_SEPARATOR'
     If your system uses some character other than slash to separate
     directory names within a file specification, define this macro to
     be a C character constant specifying that character.  When GCC
     displays file names, the character you specify will be used.  GCC
     will test for both slash and the character you specify when
     parsing filenames.

`DIR_SEPARATOR_2'
     If your system uses an alternative character other than
     `DIR_SEPARATOR' to separate directory names within a file
     specification, define this macro to be a C character constant
     specifying that character.  If you define this macro, GCC will
     test for slash, `DIR_SEPARATOR', and `DIR_SEPARATOR_2' when
     parsing filenames.

`OBJECT_SUFFIX'
     Define this macro to be a C string representing the suffix for
     object files on your machine.  If you do not define this macro,
     GCC will use `.o' as the suffix for object files.

`EXECUTABLE_SUFFIX'
     Define this macro to be a C string representing the suffix for
     executable files on your machine.  If you do not define this
     macro, GCC will use the null string as the suffix for object files.

`NO_AUTO_EXE_SUFFIX'
     Define this macro if executable files on your machine have a
     suffix, but the compiler driver should not automatically append it
     to the output file name, if user hasn't specified one.

`HOST_BIT_BUCKET'
     The name of a file or file-like object on the host system which
     acts as a "bit bucket".  If you do not define this macro, GCC will
     use `/dev/null' as the bit bucket.  If the target does not support
     a bit bucket, this should be defined to the null string, or some
     other illegal filename.  If the bit bucket is not writable, GCC
     will use a temporary file instead.

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

`COLLECT2_HOST_INITIALIZATION'
     If defined, a C statement (sans semicolon) that performs
     host-dependent initialization when `collect2' is being initialized.

`GCC_DRIVER_HOST_INITIALIZATION'
     If defined, a C statement (sans semicolon) that performs
     host-dependent initialization when a compilation driver is being
     initialized.

`UPDATE_PATH_HOST_CANONICALIZE (PATH, KEY)'
     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 the path to be
     canonicalized, and KEY is a translation prefix when its value
     isn't `NULL'.  If the C statement does canonicalize PATH, the new
     path should be returned.

   In addition, configuration files for system V define `bcopy',
`bzero' and `bcmp' as aliases.  Some files define `alloca' as a macro
when compiled with GCC, in order to take advantage of the benefit of
GCC's built-in `alloca'.


File: gcc.info,  Node: Fragments,  Next: Funding,  Prev: Config,  Up: Top

Makefile Fragments
******************

   When you configure GCC using the `configure' script (*note
Installation::), it will construct the file `Makefile' from the
template file `Makefile.in'.  When it does this, it will incorporate
makefile fragment files from the `config' directory, named `t-TARGET'
and `x-HOST'.  If these files do not exist, it means nothing needs to
be added for a given target or host.

* Menu:

* Target Fragment:: Writing the `t-TARGET' file.
* Host Fragment::   Writing the `x-HOST' file.


File: gcc.info,  Node: Target Fragment,  Next: Host Fragment,  Up: Fragments

The Target Makefile Fragment
============================

   The target makefile fragment, `t-TARGET', defines special target
dependent variables and targets used in the `Makefile':

`LIBGCC1'
     The rule to use to build `libgcc1.a'.  If your target does not
     need to use the functions in `libgcc1.a', set this to empty.
     *Note Interface::.

`CROSS_LIBGCC1'
     The rule to use to build `libgcc1.a' when building a cross
     compiler.  If your target does not need to use the functions in
     `libgcc1.a', set this to empty.

`LIBGCC2_CFLAGS'
     Compiler flags to use when compiling `libgcc2.c'.

`LIB2FUNCS_EXTRA'
     A list of source file names to be compiled or assembled and
     inserted into `libgcc.a'.

`Floating Point Emulation'
     To have GCC include software floating point libraries in `libgcc.a'
     define `FPBIT' and `DPBIT' along with a few rules as follows:
          # We want fine grained libraries, so use the new code
          # to build the floating point emulation libraries.
          FPBIT = fp-bit.c
          DPBIT = dp-bit.c
          
          
          fp-bit.c: $(srcdir)/config/fp-bit.c
                  echo '#define FLOAT' > fp-bit.c
                  cat $(srcdir)/config/fp-bit.c >> fp-bit.c
          
          dp-bit.c: $(srcdir)/config/fp-bit.c
                  cat $(srcdir)/config/fp-bit.c > dp-bit.c

     You may need to provide additional #defines at the beginning of
     `fp-bit.c' and `dp-bit.c' to control target endianness and other
     options.

`CRTSTUFF_T_CFLAGS'
     Special flags used when compiling `crtstuff.c'.  *Note
     Initialization::.

`CRTSTUFF_T_CFLAGS_S'
     Special flags used when compiling `crtstuff.c' for shared linking.
     Used if you use `crtbeginS.o' and `crtendS.o' in `EXTRA-PARTS'.
     *Note Initialization::.

`MULTILIB_OPTIONS'
     For some targets, invoking GCC in different ways produces objects
     that can not be linked together.  For example, for some targets GCC
     produces both big and little endian code.  For these targets, you
     must arrange for multiple versions of `libgcc.a' to be compiled,
     one for each set of incompatible options.  When GCC invokes the
     linker, it arranges to link in the right version of `libgcc.a',
     based on the command line options used.

     The `MULTILIB_OPTIONS' macro lists the set of options for which
     special versions of `libgcc.a' must be built.  Write options that
     are mutually incompatible side by side, separated by a slash.
     Write options that may be used together separated by a space.  The
     build procedure will build all combinations of compatible options.

     For example, if you set `MULTILIB_OPTIONS' to `m68000/m68020
     msoft-float', `Makefile' will build special versions of `libgcc.a'
     using the following sets of options:  `-m68000', `-m68020',
     `-msoft-float', `-m68000 -msoft-float', and `-m68020 -msoft-float'.

`MULTILIB_DIRNAMES'
     If `MULTILIB_OPTIONS' is used, this variable specifies the
     directory names that should be used to hold the various libraries.
     Write one element in `MULTILIB_DIRNAMES' for each element in
     `MULTILIB_OPTIONS'.  If `MULTILIB_DIRNAMES' is not used, the
     default value will be `MULTILIB_OPTIONS', with all slashes treated
     as spaces.

     For example, if `MULTILIB_OPTIONS' is set to `m68000/m68020
     msoft-float', then the default value of `MULTILIB_DIRNAMES' is
     `m68000 m68020 msoft-float'.  You may specify a different value if
     you desire a different set of directory names.

`MULTILIB_MATCHES'
     Sometimes the same option may be written in two different ways.
     If an option is listed in `MULTILIB_OPTIONS', GCC needs to know
     about any synonyms.  In that case, set `MULTILIB_MATCHES' to a
     list of items of the form `option=option' to describe all relevant
     synonyms.  For example, `m68000=mc68000 m68020=mc68020'.

`MULTILIB_EXCEPTIONS'
     Sometimes when there are multiple sets of `MULTILIB_OPTIONS' being
     specified, there are combinations that should not be built.  In
     that case, set `MULTILIB_EXCEPTIONS' to be all of the switch
     exceptions in shell case syntax that should not be built.

     For example, in the PowerPC embedded ABI support, it is not
     desirable to build libraries compiled with the `-mcall-aix' option
     and either of the `-fleading-underscore' or `-mlittle' options at
     the same time.  Therefore `MULTILIB_EXCEPTIONS' is set to
     `*mcall-aix/*fleading-underscore* *mlittle/*mcall-aix*'.

`MULTILIB_EXTRA_OPTS'
     Sometimes it is desirable that when building multiple versions of
     `libgcc.a' certain options should always be passed on to the
     compiler.  In that case, set `MULTILIB_EXTRA_OPTS' to be the list
     of options to be used for all builds.


File: gcc.info,  Node: Host Fragment,  Prev: Target Fragment,  Up: Fragments

The Host Makefile Fragment
==========================

   The host makefile fragment, `x-HOST', defines special host dependent
variables and targets used in the `Makefile':

`CC'
     The compiler to use when building the first stage.

`CLIB'
     Additional host libraries to link with.

`OLDCC'
     The compiler to use when building `libgcc1.a' for a native
     compilation.

`OLDAR'
     The version of `ar' to use when building `libgcc1.a' for a native
     compilation.

`INSTALL'
     The install program to use.


File: gcc.info,  Node: Funding,  Next: GNU/Linux,  Prev: Fragments,  Up: Top

Funding Free Software
*********************

   If you want to have more free software a few years from now, it makes
sense for you to help encourage people to contribute funds for its
development.  The most effective approach known is to encourage
commercial redistributors to donate.

   Users of free software systems can boost the pace of development by
encouraging for-a-fee distributors to donate part of their selling price
to free software developers--the Free Software Foundation, and others.

   The way to convince distributors to do this is to demand it and
expect it from them.  So when you compare distributors, judge them
partly by how much they give to free software development.  Show
distributors they must compete to be the one who gives the most.

   To make this approach work, you must insist on numbers that you can
compare, such as, "We will donate ten dollars to the Frobnitz project
for each disk sold."  Don't be satisfied with a vague promise, such as
"A portion of the profits are donated," since it doesn't give a basis
for comparison.

   Even a precise fraction "of the profits from this disk" is not very
meaningful, since creative accounting and unrelated business decisions
can greatly alter what fraction of the sales price counts as profit.
If the price you pay is $50, ten percent of the profit is probably less
than a dollar; it might be a few cents, or nothing at all.

   Some redistributors do development work themselves.  This is useful
too; but to keep everyone honest, you need to inquire how much they do,
and what kind.  Some kinds of development make much more long-term
difference than others.  For example, maintaining a separate version of
a program contributes very little; maintaining the standard version of a
program for the whole community contributes much.  Easy new ports
contribute little, since someone else would surely do them; difficult
ports such as adding a new CPU to the GNU Compiler Collection
contribute more; major new features or packages contribute the most.

   By establishing the idea that supporting further development is "the
proper thing to do" when distributing free software for a fee, we can
assure a steady flow of resources into making more free software.

     Copyright (C) 1994 Free Software Foundation, Inc.
     Verbatim copying and redistribution of this section is permitted
     without royalty; alteration is not permitted.

