-This is doc/gccint.info, produced by makeinfo version 4.5 from
-doc/gccint.texi.
+This is doc/gccint.info, produced by makeinfo version 4.13 from
+/d/gcc-4.4.3/gcc-4.4.3/gcc/doc/gccint.texi.
-INFO-DIR-SECTION Programming
+Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
+1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 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 "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 Software development
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
+ This file documents the internals of the GNU compilers.
- Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-1999, 2000, 2001, 2002 Free Software Foundation, Inc.
+ Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
+1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 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
+ 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".
+Invariant Sections being "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) The FSF's Front-Cover Text is:
- A GNU Manual
+ A GNU Manual
- (b) The FSF's Back-Cover Text is:
+ (b) The FSF's Back-Cover Text is:
- You have freedom to copy and modify this GNU Manual, like GNU
+ You have freedom to copy and modify this GNU Manual, like GNU
software. Copies published by the Free Software Foundation raise
funds for GNU development.
+
+\1f
+File: gccint.info, Node: Top, Next: Contributing, Up: (DIR)
+
+Introduction
+************
+
+This manual documents the internals of the GNU compilers, including how
+to port them to new targets and some information about how to write
+front ends for new languages. It corresponds to the compilers
+(GCC) version 4.4.3. The use of the GNU compilers is documented in a
+separate manual. *Note Introduction: (gcc)Top.
+
+ This manual is mainly a reference manual rather than a tutorial. It
+discusses how to contribute to GCC (*note Contributing::), the
+characteristics of the machines supported by GCC as hosts and targets
+(*note Portability::), how GCC relates to the ABIs on such systems
+(*note Interface::), and the characteristics of the languages for which
+GCC front ends are written (*note Languages::). It then describes the
+GCC source tree structure and build system, some of the interfaces to
+GCC front ends, and how support for a target system is implemented in
+GCC.
+
+ Additional tutorial information is linked to from
+`http://gcc.gnu.org/readings.html'.
+
+* Menu:
+
+* Contributing:: How to contribute to testing and developing GCC.
+* Portability:: Goals of GCC's portability features.
+* Interface:: Function-call interface of GCC output.
+* Libgcc:: Low-level runtime library used by GCC.
+* Languages:: Languages for which GCC front ends are written.
+* Source Tree:: GCC source tree structure and build system.
+* Options:: Option specification files.
+* Passes:: Order of passes, what they do, and what each file is for.
+* Trees:: The source representation used by the C and C++ front ends.
+* GENERIC:: Language-independent representation generated by Front Ends
+* GIMPLE:: Tuple representation used by Tree SSA optimizers
+* Tree SSA:: Analysis and optimization of GIMPLE
+* RTL:: Machine-dependent low-level intermediate representation.
+* Control Flow:: Maintaining and manipulating the control flow graph.
+* Loop Analysis and Representation:: Analysis and representation of loops
+* Machine Desc:: How to write machine description instruction patterns.
+* Target Macros:: How to write the machine description C macros and functions.
+* Host Config:: Writing the `xm-MACHINE.h' file.
+* Fragments:: Writing the `t-TARGET' and `x-HOST' files.
+* Collect2:: How `collect2' works; how it finds `ld'.
+* Header Dirs:: Understanding the standard header file directories.
+* Type Information:: GCC's memory management; generating type information.
+
+* Funding:: How to help assure funding for free software.
+* GNU Project:: The GNU Project and GNU/Linux.
+
+* Copying:: GNU General Public License says
+ how you can copy and share GCC.
+* GNU Free Documentation License:: How you can copy and share this manual.
+* Contributors:: People who have contributed to GCC.
+
+* Option Index:: Index to command line options.
+* Concept Index:: Index of concepts and symbol names.
+
+\1f
+File: gccint.info, Node: Contributing, Next: Portability, Prev: Top, Up: Top
+
+1 Contributing to GCC Development
+*********************************
+
+If you would like to help pretest GCC releases to assure they work well,
+current development sources are available by SVN (see
+`http://gcc.gnu.org/svn.html'). Source and binary snapshots are also
+available for FTP; see `http://gcc.gnu.org/snapshots.html'.
+
+ If you would like to work on improvements to GCC, please read the
+advice at these URLs:
+
+ `http://gcc.gnu.org/contribute.html'
+ `http://gcc.gnu.org/contributewhy.html'
+
+for information on how to make useful contributions and avoid
+duplication of effort. Suggested projects are listed at
+`http://gcc.gnu.org/projects/'.
+
+\1f
+File: gccint.info, Node: Portability, Next: Interface, Prev: Contributing, Up: Top
+
+2 GCC and Portability
+*********************
+
+GCC itself aims to be portable to any machine where `int' is at least a
+32-bit type. It aims to target machines with a flat (non-segmented)
+byte addressed data address space (the code address space can be
+separate). Target ABIs may have 8, 16, 32 or 64-bit `int' type. `char'
+can be wider than 8 bits.
+
+ GCC gets most of the information about the target machine from a
+machine description which gives an algebraic formula for each of the
+machine's instructions. This is a very clean way to describe the
+target. But when the compiler needs information that is difficult to
+express in this fashion, ad-hoc parameters have been defined for
+machine descriptions. The purpose of portability is to reduce the
+total work needed on the compiler; it was not of interest for its own
+sake.
+
+ GCC does not contain machine dependent code, but it does contain code
+that depends on machine parameters such as endianness (whether the most
+significant byte has the highest or lowest address of the bytes in a
+word) and the availability of autoincrement addressing. In the
+RTL-generation pass, it is often necessary to have multiple strategies
+for generating code for a particular kind of syntax tree, strategies
+that are usable for different combinations of parameters. Often, not
+all possible cases have been addressed, but only the common ones or
+only the ones that have been encountered. As a result, a new target
+may require additional strategies. You will know if this happens
+because the compiler will call `abort'. Fortunately, the new
+strategies can be added in a machine-independent fashion, and will
+affect only the target machines that need them.
+
+\1f
+File: gccint.info, Node: Interface, Next: Libgcc, Prev: Portability, Up: Top
+
+3 Interfacing to GCC Output
+***************************
+
+GCC is normally configured to use the same function calling convention
+normally in use on the target system. This is done with the
+machine-description macros described (*note Target Macros::).
+
+ However, returning of structure and union values is done differently on
+some target machines. As a result, functions compiled with PCC
+returning such types cannot be called from code compiled with GCC, and
+vice versa. This does not cause trouble often because few Unix library
+routines return structures or unions.
+
+ GCC code returns structures and unions that are 1, 2, 4 or 8 bytes
+long in the same registers used for `int' or `double' return values.
+(GCC typically allocates variables of such types in registers also.)
+Structures and unions of other sizes are returned by storing them into
+an address passed by the caller (usually in a register). The target
+hook `TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address.
+
+ By contrast, PCC on most target machines returns structures and unions
+of any size by copying the data into an area of static storage, and then
+returning the address of that storage as if it were a pointer value.
+The caller must copy the data from that memory area to the place where
+the value is wanted. This is slower than the method used by GCC, and
+fails to be reentrant.
+
+ On some target machines, such as RISC machines and the 80386, the
+standard system convention is to pass to the subroutine the address of
+where to return the value. On these machines, GCC has been configured
+to be compatible with the standard compiler, when this method is used.
+It may not be compatible for structures of 1, 2, 4 or 8 bytes.
+
+ GCC uses the system's standard convention for passing arguments. On
+some machines, the first few arguments are passed in registers; in
+others, all are passed on the stack. It would be possible to use
+registers for argument passing on any machine, and this would probably
+result in a significant speedup. But the result would be complete
+incompatibility with code that follows the standard convention. So this
+change is practical only if you are switching to GCC as the sole C
+compiler for the system. We may implement register argument passing on
+certain machines once we have a complete GNU system so that we can
+compile the libraries with GCC.
+
+ On some machines (particularly the SPARC), certain types of arguments
+are passed "by invisible reference". This means that the value is
+stored in memory, and the address of the memory location is passed to
+the subroutine.
+
+ If you use `longjmp', beware of automatic variables. ISO C says that
+automatic variables that are not declared `volatile' have undefined
+values after a `longjmp'. And this is all GCC promises to do, because
+it is very difficult to restore register variables correctly, and one
+of GCC's features is that it can put variables in registers without
+your asking it to.
+
+\1f
+File: gccint.info, Node: Libgcc, Next: Languages, Prev: Interface, Up: Top
+
+4 The GCC low-level runtime library
+***********************************
+
+GCC provides a low-level runtime library, `libgcc.a' or `libgcc_s.so.1'
+on some platforms. GCC generates calls to routines in this library
+automatically, whenever it needs to perform some operation that is too
+complicated to emit inline code for.
+
+ Most of the routines in `libgcc' handle arithmetic operations that the
+target processor cannot perform directly. This includes integer
+multiply and divide on some machines, and all floating-point and
+fixed-point operations on other machines. `libgcc' also includes
+routines for exception handling, and a handful of miscellaneous
+operations.
+
+ Some of these routines can be defined in mostly machine-independent C.
+Others must be hand-written in assembly language for each processor
+that needs them.
+
+ GCC will also generate calls to C library routines, such as `memcpy'
+and `memset', in some cases. The set of routines that GCC may possibly
+use is documented in *note Other Builtins: (gcc)Other Builtins.
+
+ These routines take arguments and return values of a specific machine
+mode, not a specific C type. *Note Machine Modes::, for an explanation
+of this concept. For illustrative purposes, in this chapter the
+floating point type `float' is assumed to correspond to `SFmode';
+`double' to `DFmode'; and `long double' to both `TFmode' and `XFmode'.
+Similarly, the integer types `int' and `unsigned int' correspond to
+`SImode'; `long' and `unsigned long' to `DImode'; and `long long' and
+`unsigned long long' to `TImode'.
+
+* Menu:
+
+* Integer library routines::
+* Soft float library routines::
+* Decimal float library routines::
+* Fixed-point fractional library routines::
+* Exception handling routines::
+* Miscellaneous routines::
+
+\1f
+File: gccint.info, Node: Integer library routines, Next: Soft float library routines, Up: Libgcc
+
+4.1 Routines for integer arithmetic
+===================================
+
+The integer arithmetic routines are used on platforms that don't provide
+hardware support for arithmetic operations on some modes.
+
+4.1.1 Arithmetic functions
+--------------------------
+
+ -- Runtime Function: int __ashlsi3 (int A, int B)
+ -- Runtime Function: long __ashldi3 (long A, int B)
+ -- Runtime Function: long long __ashlti3 (long long A, int B)
+ These functions return the result of shifting A left by B bits.
+
+ -- Runtime Function: int __ashrsi3 (int A, int B)
+ -- Runtime Function: long __ashrdi3 (long A, int B)
+ -- Runtime Function: long long __ashrti3 (long long A, int B)
+ These functions return the result of arithmetically shifting A
+ right by B bits.
+
+ -- Runtime Function: int __divsi3 (int A, int B)
+ -- Runtime Function: long __divdi3 (long A, long B)
+ -- Runtime Function: long long __divti3 (long long A, long long B)
+ These functions return the quotient of the signed division of A and
+ B.
+
+ -- Runtime Function: int __lshrsi3 (int A, int B)
+ -- Runtime Function: long __lshrdi3 (long A, int B)
+ -- Runtime Function: long long __lshrti3 (long long A, int B)
+ These functions return the result of logically shifting A right by
+ B bits.
+
+ -- Runtime Function: int __modsi3 (int A, int B)
+ -- Runtime Function: long __moddi3 (long A, long B)
+ -- Runtime Function: long long __modti3 (long long A, long long B)
+ These functions return the remainder of the signed division of A
+ and B.
+
+ -- Runtime Function: int __mulsi3 (int A, int B)
+ -- Runtime Function: long __muldi3 (long A, long B)
+ -- Runtime Function: long long __multi3 (long long A, long long B)
+ These functions return the product of A and B.
+
+ -- Runtime Function: long __negdi2 (long A)
+ -- Runtime Function: long long __negti2 (long long A)
+ These functions return the negation of A.
+
+ -- Runtime Function: unsigned int __udivsi3 (unsigned int A, unsigned
+ int B)
+ -- Runtime Function: unsigned long __udivdi3 (unsigned long A,
+ unsigned long B)
+ -- Runtime Function: unsigned long long __udivti3 (unsigned long long
+ A, unsigned long long B)
+ These functions return the quotient of the unsigned division of A
+ and B.
+
+ -- Runtime Function: unsigned long __udivmoddi3 (unsigned long A,
+ unsigned long B, unsigned long *C)
+ -- Runtime Function: unsigned long long __udivti3 (unsigned long long
+ A, unsigned long long B, unsigned long long *C)
+ These functions calculate both the quotient and remainder of the
+ unsigned division of A and B. The return value is the quotient,
+ and the remainder is placed in variable pointed to by C.
+
+ -- Runtime Function: unsigned int __umodsi3 (unsigned int A, unsigned
+ int B)
+ -- Runtime Function: unsigned long __umoddi3 (unsigned long A,
+ unsigned long B)
+ -- Runtime Function: unsigned long long __umodti3 (unsigned long long
+ A, unsigned long long B)
+ These functions return the remainder of the unsigned division of A
+ and B.
+
+4.1.2 Comparison functions
+--------------------------
+
+The following functions implement integral comparisons. These functions
+implement a low-level compare, upon which the higher level comparison
+operators (such as less than and greater than or equal to) can be
+constructed. The returned values lie in the range zero to two, to allow
+the high-level operators to be implemented by testing the returned
+result using either signed or unsigned comparison.
+
+ -- Runtime Function: int __cmpdi2 (long A, long B)
+ -- Runtime Function: int __cmpti2 (long long A, long long B)
+ These functions perform a signed comparison of A and B. If A is
+ less than B, they return 0; if A is greater than B, they return 2;
+ and if A and B are equal they return 1.
+
+ -- Runtime Function: int __ucmpdi2 (unsigned long A, unsigned long B)
+ -- Runtime Function: int __ucmpti2 (unsigned long long A, unsigned
+ long long B)
+ These functions perform an unsigned comparison of A and B. If A
+ is less than B, they return 0; if A is greater than B, they return
+ 2; and if A and B are equal they return 1.
+
+4.1.3 Trapping arithmetic functions
+-----------------------------------
+
+The following functions implement trapping arithmetic. These functions
+call the libc function `abort' upon signed arithmetic overflow.
+
+ -- Runtime Function: int __absvsi2 (int A)
+ -- Runtime Function: long __absvdi2 (long A)
+ These functions return the absolute value of A.
+
+ -- Runtime Function: int __addvsi3 (int A, int B)
+ -- Runtime Function: long __addvdi3 (long A, long B)
+ These functions return the sum of A and B; that is `A + B'.
+
+ -- Runtime Function: int __mulvsi3 (int A, int B)
+ -- Runtime Function: long __mulvdi3 (long A, long B)
+ The functions return the product of A and B; that is `A * B'.
+
+ -- Runtime Function: int __negvsi2 (int A)
+ -- Runtime Function: long __negvdi2 (long A)
+ These functions return the negation of A; that is `-A'.
+
+ -- Runtime Function: int __subvsi3 (int A, int B)
+ -- Runtime Function: long __subvdi3 (long A, long B)
+ These functions return the difference between B and A; that is `A
+ - B'.
+
+4.1.4 Bit operations
+--------------------
+
+ -- Runtime Function: int __clzsi2 (int A)
+ -- Runtime Function: int __clzdi2 (long A)
+ -- Runtime Function: int __clzti2 (long long A)
+ These functions return the number of leading 0-bits in A, starting
+ at the most significant bit position. If A is zero, the result is
+ undefined.
+
+ -- Runtime Function: int __ctzsi2 (int A)
+ -- Runtime Function: int __ctzdi2 (long A)
+ -- Runtime Function: int __ctzti2 (long long A)
+ These functions return the number of trailing 0-bits in A, starting
+ at the least significant bit position. If A is zero, the result is
+ undefined.
+
+ -- Runtime Function: int __ffsdi2 (long A)
+ -- Runtime Function: int __ffsti2 (long long A)
+ These functions return the index of the least significant 1-bit in
+ A, or the value zero if A is zero. The least significant bit is
+ index one.
+
+ -- Runtime Function: int __paritysi2 (int A)
+ -- Runtime Function: int __paritydi2 (long A)
+ -- Runtime Function: int __parityti2 (long long A)
+ These functions return the value zero if the number of bits set in
+ A is even, and the value one otherwise.
+
+ -- Runtime Function: int __popcountsi2 (int A)
+ -- Runtime Function: int __popcountdi2 (long A)
+ -- Runtime Function: int __popcountti2 (long long A)
+ These functions return the number of bits set in A.
+
+ -- Runtime Function: int32_t __bswapsi2 (int32_t A)
+ -- Runtime Function: int64_t __bswapdi2 (int64_t A)
+ These functions return the A byteswapped.
+
+\1f
+File: gccint.info, Node: Soft float library routines, Next: Decimal float library routines, Prev: Integer library routines, Up: Libgcc
+
+4.2 Routines for floating point emulation
+=========================================
+
+The software floating point library is used on machines which do not
+have hardware support for floating point. It is also used whenever
+`-msoft-float' is used to disable generation of floating point
+instructions. (Not all targets support this switch.)
+
+ For compatibility with other compilers, the floating point emulation
+routines can be renamed with the `DECLARE_LIBRARY_RENAMES' macro (*note
+Library Calls::). In this section, the default names are used.
+
+ Presently the library does not support `XFmode', which is used for
+`long double' on some architectures.
+
+4.2.1 Arithmetic functions
+--------------------------
+
+ -- Runtime Function: float __addsf3 (float A, float B)
+ -- Runtime Function: double __adddf3 (double A, double B)
+ -- Runtime Function: long double __addtf3 (long double A, long double
+ B)
+ -- Runtime Function: long double __addxf3 (long double A, long double
+ B)
+ These functions return the sum of A and B.
+
+ -- Runtime Function: float __subsf3 (float A, float B)
+ -- Runtime Function: double __subdf3 (double A, double B)
+ -- Runtime Function: long double __subtf3 (long double A, long double
+ B)
+ -- Runtime Function: long double __subxf3 (long double A, long double
+ B)
+ These functions return the difference between B and A; that is,
+ A - B.
+
+ -- Runtime Function: float __mulsf3 (float A, float B)
+ -- Runtime Function: double __muldf3 (double A, double B)
+ -- Runtime Function: long double __multf3 (long double A, long double
+ B)
+ -- Runtime Function: long double __mulxf3 (long double A, long double
+ B)
+ These functions return the product of A and B.
+
+ -- Runtime Function: float __divsf3 (float A, float B)
+ -- Runtime Function: double __divdf3 (double A, double B)
+ -- Runtime Function: long double __divtf3 (long double A, long double
+ B)
+ -- Runtime Function: long double __divxf3 (long double A, long double
+ B)
+ These functions return the quotient of A and B; that is, A / B.
+
+ -- Runtime Function: float __negsf2 (float A)
+ -- Runtime Function: double __negdf2 (double A)
+ -- Runtime Function: long double __negtf2 (long double A)
+ -- Runtime Function: long double __negxf2 (long double A)
+ These functions return the negation of A. They simply flip the
+ sign bit, so they can produce negative zero and negative NaN.
+
+4.2.2 Conversion functions
+--------------------------
+
+ -- Runtime Function: double __extendsfdf2 (float A)
+ -- Runtime Function: long double __extendsftf2 (float A)
+ -- Runtime Function: long double __extendsfxf2 (float A)
+ -- Runtime Function: long double __extenddftf2 (double A)
+ -- Runtime Function: long double __extenddfxf2 (double A)
+ These functions extend A to the wider mode of their return type.
+
+ -- Runtime Function: double __truncxfdf2 (long double A)
+ -- Runtime Function: double __trunctfdf2 (long double A)
+ -- Runtime Function: float __truncxfsf2 (long double A)
+ -- Runtime Function: float __trunctfsf2 (long double A)
+ -- Runtime Function: float __truncdfsf2 (double A)
+ These functions truncate A to the narrower mode of their return
+ type, rounding toward zero.
+
+ -- Runtime Function: int __fixsfsi (float A)
+ -- Runtime Function: int __fixdfsi (double A)
+ -- Runtime Function: int __fixtfsi (long double A)
+ -- Runtime Function: int __fixxfsi (long double A)
+ These functions convert A to a signed integer, rounding toward
+ zero.
+
+ -- Runtime Function: long __fixsfdi (float A)
+ -- Runtime Function: long __fixdfdi (double A)
+ -- Runtime Function: long __fixtfdi (long double A)
+ -- Runtime Function: long __fixxfdi (long double A)
+ These functions convert A to a signed long, rounding toward zero.
+
+ -- Runtime Function: long long __fixsfti (float A)
+ -- Runtime Function: long long __fixdfti (double A)
+ -- Runtime Function: long long __fixtfti (long double A)
+ -- Runtime Function: long long __fixxfti (long double A)
+ These functions convert A to a signed long long, rounding toward
+ zero.
+
+ -- Runtime Function: unsigned int __fixunssfsi (float A)
+ -- Runtime Function: unsigned int __fixunsdfsi (double A)
+ -- Runtime Function: unsigned int __fixunstfsi (long double A)
+ -- Runtime Function: unsigned int __fixunsxfsi (long double A)
+ These functions convert A to an unsigned integer, rounding toward
+ zero. Negative values all become zero.
+
+ -- Runtime Function: unsigned long __fixunssfdi (float A)
+ -- Runtime Function: unsigned long __fixunsdfdi (double A)
+ -- Runtime Function: unsigned long __fixunstfdi (long double A)
+ -- Runtime Function: unsigned long __fixunsxfdi (long double A)
+ These functions convert A to an unsigned long, rounding toward
+ zero. Negative values all become zero.
+
+ -- Runtime Function: unsigned long long __fixunssfti (float A)
+ -- Runtime Function: unsigned long long __fixunsdfti (double A)
+ -- Runtime Function: unsigned long long __fixunstfti (long double A)
+ -- Runtime Function: unsigned long long __fixunsxfti (long double A)
+ These functions convert A to an unsigned long long, rounding
+ toward zero. Negative values all become zero.
+
+ -- Runtime Function: float __floatsisf (int I)
+ -- Runtime Function: double __floatsidf (int I)
+ -- Runtime Function: long double __floatsitf (int I)
+ -- Runtime Function: long double __floatsixf (int I)
+ These functions convert I, a signed integer, to floating point.
+
+ -- Runtime Function: float __floatdisf (long I)
+ -- Runtime Function: double __floatdidf (long I)
+ -- Runtime Function: long double __floatditf (long I)
+ -- Runtime Function: long double __floatdixf (long I)
+ These functions convert I, a signed long, to floating point.
+
+ -- Runtime Function: float __floattisf (long long I)
+ -- Runtime Function: double __floattidf (long long I)
+ -- Runtime Function: long double __floattitf (long long I)
+ -- Runtime Function: long double __floattixf (long long I)
+ These functions convert I, a signed long long, to floating point.
+
+ -- Runtime Function: float __floatunsisf (unsigned int I)
+ -- Runtime Function: double __floatunsidf (unsigned int I)
+ -- Runtime Function: long double __floatunsitf (unsigned int I)
+ -- Runtime Function: long double __floatunsixf (unsigned int I)
+ These functions convert I, an unsigned integer, to floating point.
+
+ -- Runtime Function: float __floatundisf (unsigned long I)
+ -- Runtime Function: double __floatundidf (unsigned long I)
+ -- Runtime Function: long double __floatunditf (unsigned long I)
+ -- Runtime Function: long double __floatundixf (unsigned long I)
+ These functions convert I, an unsigned long, to floating point.
+
+ -- Runtime Function: float __floatuntisf (unsigned long long I)
+ -- Runtime Function: double __floatuntidf (unsigned long long I)
+ -- Runtime Function: long double __floatuntitf (unsigned long long I)
+ -- Runtime Function: long double __floatuntixf (unsigned long long I)
+ These functions convert I, an unsigned long long, to floating
+ point.
+
+4.2.3 Comparison functions
+--------------------------
+
+There are two sets of basic comparison functions.
+
+ -- Runtime Function: int __cmpsf2 (float A, float B)
+ -- Runtime Function: int __cmpdf2 (double A, double B)
+ -- Runtime Function: int __cmptf2 (long double A, long double B)
+ These functions calculate a <=> b. That is, if A is less than B,
+ they return -1; if A is greater than B, they return 1; and if A
+ and B are equal they return 0. If either argument is NaN they
+ return 1, but you should not rely on this; if NaN is a
+ possibility, use one of the higher-level comparison functions.
+
+ -- Runtime Function: int __unordsf2 (float A, float B)
+ -- Runtime Function: int __unorddf2 (double A, double B)
+ -- Runtime Function: int __unordtf2 (long double A, long double B)
+ These functions return a nonzero value if either argument is NaN,
+ otherwise 0.
+
+ There is also a complete group of higher level functions which
+correspond directly to comparison operators. They implement the ISO C
+semantics for floating-point comparisons, taking NaN into account. Pay
+careful attention to the return values defined for each set. Under the
+hood, all of these routines are implemented as
+
+ if (__unordXf2 (a, b))
+ return E;
+ return __cmpXf2 (a, b);
+
+where E is a constant chosen to give the proper behavior for NaN.
+Thus, the meaning of the return value is different for each set. Do
+not rely on this implementation; only the semantics documented below
+are guaranteed.
+
+ -- Runtime Function: int __eqsf2 (float A, float B)
+ -- Runtime Function: int __eqdf2 (double A, double B)
+ -- Runtime Function: int __eqtf2 (long double A, long double B)
+ These functions return zero if neither argument is NaN, and A and
+ B are equal.
+
+ -- Runtime Function: int __nesf2 (float A, float B)
+ -- Runtime Function: int __nedf2 (double A, double B)
+ -- Runtime Function: int __netf2 (long double A, long double B)
+ These functions return a nonzero value if either argument is NaN,
+ or if A and B are unequal.
+
+ -- Runtime Function: int __gesf2 (float A, float B)
+ -- Runtime Function: int __gedf2 (double A, double B)
+ -- Runtime Function: int __getf2 (long double A, long double B)
+ These functions return a value greater than or equal to zero if
+ neither argument is NaN, and A is greater than or equal to B.
+
+ -- Runtime Function: int __ltsf2 (float A, float B)
+ -- Runtime Function: int __ltdf2 (double A, double B)
+ -- Runtime Function: int __lttf2 (long double A, long double B)
+ These functions return a value less than zero if neither argument
+ is NaN, and A is strictly less than B.
+
+ -- Runtime Function: int __lesf2 (float A, float B)
+ -- Runtime Function: int __ledf2 (double A, double B)
+ -- Runtime Function: int __letf2 (long double A, long double B)
+ These functions return a value less than or equal to zero if
+ neither argument is NaN, and A is less than or equal to B.
+
+ -- Runtime Function: int __gtsf2 (float A, float B)
+ -- Runtime Function: int __gtdf2 (double A, double B)
+ -- Runtime Function: int __gttf2 (long double A, long double B)
+ These functions return a value greater than zero if neither
+ argument is NaN, and A is strictly greater than B.
+
+4.2.4 Other floating-point functions
+------------------------------------
+
+ -- Runtime Function: float __powisf2 (float A, int B)
+ -- Runtime Function: double __powidf2 (double A, int B)
+ -- Runtime Function: long double __powitf2 (long double A, int B)
+ -- Runtime Function: long double __powixf2 (long double A, int B)
+ These functions convert raise A to the power B.
+
+ -- Runtime Function: complex float __mulsc3 (float A, float B, float
+ C, float D)
+ -- Runtime Function: complex double __muldc3 (double A, double B,
+ double C, double D)
+ -- Runtime Function: complex long double __multc3 (long double A, long
+ double B, long double C, long double D)
+ -- Runtime Function: complex long double __mulxc3 (long double A, long
+ double B, long double C, long double D)
+ These functions return the product of A + iB and C + iD, following
+ the rules of C99 Annex G.
+
+ -- Runtime Function: complex float __divsc3 (float A, float B, float
+ C, float D)
+ -- Runtime Function: complex double __divdc3 (double A, double B,
+ double C, double D)
+ -- Runtime Function: complex long double __divtc3 (long double A, long
+ double B, long double C, long double D)
+ -- Runtime Function: complex long double __divxc3 (long double A, long
+ double B, long double C, long double D)
+ These functions return the quotient of A + iB and C + iD (i.e., (A
+ + iB) / (C + iD)), following the rules of C99 Annex G.
+
+\1f
+File: gccint.info, Node: Decimal float library routines, Next: Fixed-point fractional library routines, Prev: Soft float library routines, Up: Libgcc
+
+4.3 Routines for decimal floating point emulation
+=================================================
+
+The software decimal floating point library implements IEEE 754-2008
+decimal floating point arithmetic and is only activated on selected
+targets.
+
+ The software decimal floating point library supports either DPD
+(Densely Packed Decimal) or BID (Binary Integer Decimal) encoding as
+selected at configure time.
+
+4.3.1 Arithmetic functions
+--------------------------
+
+ -- Runtime Function: _Decimal32 __dpd_addsd3 (_Decimal32 A, _Decimal32
+ B)
+ -- Runtime Function: _Decimal32 __bid_addsd3 (_Decimal32 A, _Decimal32
+ B)
+ -- Runtime Function: _Decimal64 __dpd_adddd3 (_Decimal64 A, _Decimal64
+ B)
+ -- Runtime Function: _Decimal64 __bid_adddd3 (_Decimal64 A, _Decimal64
+ B)
+ -- Runtime Function: _Decimal128 __dpd_addtd3 (_Decimal128 A,
+ _Decimal128 B)
+ -- Runtime Function: _Decimal128 __bid_addtd3 (_Decimal128 A,
+ _Decimal128 B)
+ These functions return the sum of A and B.
+
+ -- Runtime Function: _Decimal32 __dpd_subsd3 (_Decimal32 A, _Decimal32
+ B)
+ -- Runtime Function: _Decimal32 __bid_subsd3 (_Decimal32 A, _Decimal32
+ B)
+ -- Runtime Function: _Decimal64 __dpd_subdd3 (_Decimal64 A, _Decimal64
+ B)
+ -- Runtime Function: _Decimal64 __bid_subdd3 (_Decimal64 A, _Decimal64
+ B)
+ -- Runtime Function: _Decimal128 __dpd_subtd3 (_Decimal128 A,
+ _Decimal128 B)
+ -- Runtime Function: _Decimal128 __bid_subtd3 (_Decimal128 A,
+ _Decimal128 B)
+ These functions return the difference between B and A; that is,
+ A - B.
+
+ -- Runtime Function: _Decimal32 __dpd_mulsd3 (_Decimal32 A, _Decimal32
+ B)
+ -- Runtime Function: _Decimal32 __bid_mulsd3 (_Decimal32 A, _Decimal32
+ B)
+ -- Runtime Function: _Decimal64 __dpd_muldd3 (_Decimal64 A, _Decimal64
+ B)
+ -- Runtime Function: _Decimal64 __bid_muldd3 (_Decimal64 A, _Decimal64
+ B)
+ -- Runtime Function: _Decimal128 __dpd_multd3 (_Decimal128 A,
+ _Decimal128 B)
+ -- Runtime Function: _Decimal128 __bid_multd3 (_Decimal128 A,
+ _Decimal128 B)
+ These functions return the product of A and B.
+
+ -- Runtime Function: _Decimal32 __dpd_divsd3 (_Decimal32 A, _Decimal32
+ B)
+ -- Runtime Function: _Decimal32 __bid_divsd3 (_Decimal32 A, _Decimal32
+ B)
+ -- Runtime Function: _Decimal64 __dpd_divdd3 (_Decimal64 A, _Decimal64
+ B)
+ -- Runtime Function: _Decimal64 __bid_divdd3 (_Decimal64 A, _Decimal64
+ B)
+ -- Runtime Function: _Decimal128 __dpd_divtd3 (_Decimal128 A,
+ _Decimal128 B)
+ -- Runtime Function: _Decimal128 __bid_divtd3 (_Decimal128 A,
+ _Decimal128 B)
+ These functions return the quotient of A and B; that is, A / B.
+
+ -- Runtime Function: _Decimal32 __dpd_negsd2 (_Decimal32 A)
+ -- Runtime Function: _Decimal32 __bid_negsd2 (_Decimal32 A)
+ -- Runtime Function: _Decimal64 __dpd_negdd2 (_Decimal64 A)
+ -- Runtime Function: _Decimal64 __bid_negdd2 (_Decimal64 A)
+ -- Runtime Function: _Decimal128 __dpd_negtd2 (_Decimal128 A)
+ -- Runtime Function: _Decimal128 __bid_negtd2 (_Decimal128 A)
+ These functions return the negation of A. They simply flip the
+ sign bit, so they can produce negative zero and negative NaN.
+
+4.3.2 Conversion functions
+--------------------------
+
+ -- Runtime Function: _Decimal64 __dpd_extendsddd2 (_Decimal32 A)
+ -- Runtime Function: _Decimal64 __bid_extendsddd2 (_Decimal32 A)
+ -- Runtime Function: _Decimal128 __dpd_extendsdtd2 (_Decimal32 A)
+ -- Runtime Function: _Decimal128 __bid_extendsdtd2 (_Decimal32 A)
+ -- Runtime Function: _Decimal128 __dpd_extendddtd2 (_Decimal64 A)
+ -- Runtime Function: _Decimal128 __bid_extendddtd2 (_Decimal64 A)
+ -- Runtime Function: _Decimal32 __dpd_truncddsd2 (_Decimal64 A)
+ -- Runtime Function: _Decimal32 __bid_truncddsd2 (_Decimal64 A)
+ -- Runtime Function: _Decimal32 __dpd_trunctdsd2 (_Decimal128 A)
+ -- Runtime Function: _Decimal32 __bid_trunctdsd2 (_Decimal128 A)
+ -- Runtime Function: _Decimal64 __dpd_trunctddd2 (_Decimal128 A)
+ -- Runtime Function: _Decimal64 __bid_trunctddd2 (_Decimal128 A)
+ These functions convert the value A from one decimal floating type
+ to another.
+
+ -- Runtime Function: _Decimal64 __dpd_extendsfdd (float A)
+ -- Runtime Function: _Decimal64 __bid_extendsfdd (float A)
+ -- Runtime Function: _Decimal128 __dpd_extendsftd (float A)
+ -- Runtime Function: _Decimal128 __bid_extendsftd (float A)
+ -- Runtime Function: _Decimal128 __dpd_extenddftd (double A)
+ -- Runtime Function: _Decimal128 __bid_extenddftd (double A)
+ -- Runtime Function: _Decimal128 __dpd_extendxftd (long double A)
+ -- Runtime Function: _Decimal128 __bid_extendxftd (long double A)
+ -- Runtime Function: _Decimal32 __dpd_truncdfsd (double A)
+ -- Runtime Function: _Decimal32 __bid_truncdfsd (double A)
+ -- Runtime Function: _Decimal32 __dpd_truncxfsd (long double A)
+ -- Runtime Function: _Decimal32 __bid_truncxfsd (long double A)
+ -- Runtime Function: _Decimal32 __dpd_trunctfsd (long double A)
+ -- Runtime Function: _Decimal32 __bid_trunctfsd (long double A)
+ -- Runtime Function: _Decimal64 __dpd_truncxfdd (long double A)
+ -- Runtime Function: _Decimal64 __bid_truncxfdd (long double A)
+ -- Runtime Function: _Decimal64 __dpd_trunctfdd (long double A)
+ -- Runtime Function: _Decimal64 __bid_trunctfdd (long double A)
+ These functions convert the value of A from a binary floating type
+ to a decimal floating type of a different size.
+
+ -- Runtime Function: float __dpd_truncddsf (_Decimal64 A)
+ -- Runtime Function: float __bid_truncddsf (_Decimal64 A)
+ -- Runtime Function: float __dpd_trunctdsf (_Decimal128 A)
+ -- Runtime Function: float __bid_trunctdsf (_Decimal128 A)
+ -- Runtime Function: double __dpd_extendsddf (_Decimal32 A)
+ -- Runtime Function: double __bid_extendsddf (_Decimal32 A)
+ -- Runtime Function: double __dpd_trunctddf (_Decimal128 A)
+ -- Runtime Function: double __bid_trunctddf (_Decimal128 A)
+ -- Runtime Function: long double __dpd_extendsdxf (_Decimal32 A)
+ -- Runtime Function: long double __bid_extendsdxf (_Decimal32 A)
+ -- Runtime Function: long double __dpd_extendddxf (_Decimal64 A)
+ -- Runtime Function: long double __bid_extendddxf (_Decimal64 A)
+ -- Runtime Function: long double __dpd_trunctdxf (_Decimal128 A)
+ -- Runtime Function: long double __bid_trunctdxf (_Decimal128 A)
+ -- Runtime Function: long double __dpd_extendsdtf (_Decimal32 A)
+ -- Runtime Function: long double __bid_extendsdtf (_Decimal32 A)
+ -- Runtime Function: long double __dpd_extendddtf (_Decimal64 A)
+ -- Runtime Function: long double __bid_extendddtf (_Decimal64 A)
+ These functions convert the value of A from a decimal floating type
+ to a binary floating type of a different size.
+
+ -- Runtime Function: _Decimal32 __dpd_extendsfsd (float A)
+ -- Runtime Function: _Decimal32 __bid_extendsfsd (float A)
+ -- Runtime Function: _Decimal64 __dpd_extenddfdd (double A)
+ -- Runtime Function: _Decimal64 __bid_extenddfdd (double A)
+ -- Runtime Function: _Decimal128 __dpd_extendtftd (long double A)
+ -- Runtime Function: _Decimal128 __bid_extendtftd (long double A)
+ -- Runtime Function: float __dpd_truncsdsf (_Decimal32 A)
+ -- Runtime Function: float __bid_truncsdsf (_Decimal32 A)
+ -- Runtime Function: double __dpd_truncdddf (_Decimal64 A)
+ -- Runtime Function: double __bid_truncdddf (_Decimal64 A)
+ -- Runtime Function: long double __dpd_trunctdtf (_Decimal128 A)
+ -- Runtime Function: long double __bid_trunctdtf (_Decimal128 A)
+ These functions convert the value of A between decimal and binary
+ floating types of the same size.
+
+ -- Runtime Function: int __dpd_fixsdsi (_Decimal32 A)
+ -- Runtime Function: int __bid_fixsdsi (_Decimal32 A)
+ -- Runtime Function: int __dpd_fixddsi (_Decimal64 A)
+ -- Runtime Function: int __bid_fixddsi (_Decimal64 A)
+ -- Runtime Function: int __dpd_fixtdsi (_Decimal128 A)
+ -- Runtime Function: int __bid_fixtdsi (_Decimal128 A)
+ These functions convert A to a signed integer.
+
+ -- Runtime Function: long __dpd_fixsddi (_Decimal32 A)
+ -- Runtime Function: long __bid_fixsddi (_Decimal32 A)
+ -- Runtime Function: long __dpd_fixdddi (_Decimal64 A)
+ -- Runtime Function: long __bid_fixdddi (_Decimal64 A)
+ -- Runtime Function: long __dpd_fixtddi (_Decimal128 A)
+ -- Runtime Function: long __bid_fixtddi (_Decimal128 A)
+ These functions convert A to a signed long.
+
+ -- Runtime Function: unsigned int __dpd_fixunssdsi (_Decimal32 A)
+ -- Runtime Function: unsigned int __bid_fixunssdsi (_Decimal32 A)
+ -- Runtime Function: unsigned int __dpd_fixunsddsi (_Decimal64 A)
+ -- Runtime Function: unsigned int __bid_fixunsddsi (_Decimal64 A)
+ -- Runtime Function: unsigned int __dpd_fixunstdsi (_Decimal128 A)
+ -- Runtime Function: unsigned int __bid_fixunstdsi (_Decimal128 A)
+ These functions convert A to an unsigned integer. Negative values
+ all become zero.
+
+ -- Runtime Function: unsigned long __dpd_fixunssddi (_Decimal32 A)
+ -- Runtime Function: unsigned long __bid_fixunssddi (_Decimal32 A)
+ -- Runtime Function: unsigned long __dpd_fixunsdddi (_Decimal64 A)
+ -- Runtime Function: unsigned long __bid_fixunsdddi (_Decimal64 A)
+ -- Runtime Function: unsigned long __dpd_fixunstddi (_Decimal128 A)
+ -- Runtime Function: unsigned long __bid_fixunstddi (_Decimal128 A)
+ These functions convert A to an unsigned long. Negative values
+ all become zero.
+
+ -- Runtime Function: _Decimal32 __dpd_floatsisd (int I)
+ -- Runtime Function: _Decimal32 __bid_floatsisd (int I)
+ -- Runtime Function: _Decimal64 __dpd_floatsidd (int I)
+ -- Runtime Function: _Decimal64 __bid_floatsidd (int I)
+ -- Runtime Function: _Decimal128 __dpd_floatsitd (int I)
+ -- Runtime Function: _Decimal128 __bid_floatsitd (int I)
+ These functions convert I, a signed integer, to decimal floating
+ point.
+
+ -- Runtime Function: _Decimal32 __dpd_floatdisd (long I)
+ -- Runtime Function: _Decimal32 __bid_floatdisd (long I)
+ -- Runtime Function: _Decimal64 __dpd_floatdidd (long I)
+ -- Runtime Function: _Decimal64 __bid_floatdidd (long I)
+ -- Runtime Function: _Decimal128 __dpd_floatditd (long I)
+ -- Runtime Function: _Decimal128 __bid_floatditd (long I)
+ These functions convert I, a signed long, to decimal floating
+ point.
+
+ -- Runtime Function: _Decimal32 __dpd_floatunssisd (unsigned int I)
+ -- Runtime Function: _Decimal32 __bid_floatunssisd (unsigned int I)
+ -- Runtime Function: _Decimal64 __dpd_floatunssidd (unsigned int I)
+ -- Runtime Function: _Decimal64 __bid_floatunssidd (unsigned int I)
+ -- Runtime Function: _Decimal128 __dpd_floatunssitd (unsigned int I)
+ -- Runtime Function: _Decimal128 __bid_floatunssitd (unsigned int I)
+ These functions convert I, an unsigned integer, to decimal
+ floating point.
+
+ -- Runtime Function: _Decimal32 __dpd_floatunsdisd (unsigned long I)
+ -- Runtime Function: _Decimal32 __bid_floatunsdisd (unsigned long I)
+ -- Runtime Function: _Decimal64 __dpd_floatunsdidd (unsigned long I)
+ -- Runtime Function: _Decimal64 __bid_floatunsdidd (unsigned long I)
+ -- Runtime Function: _Decimal128 __dpd_floatunsditd (unsigned long I)
+ -- Runtime Function: _Decimal128 __bid_floatunsditd (unsigned long I)
+ These functions convert I, an unsigned long, to decimal floating
+ point.
+
+4.3.3 Comparison functions
+--------------------------
+
+ -- Runtime Function: int __dpd_unordsd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __bid_unordsd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __dpd_unorddd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __bid_unorddd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __dpd_unordtd2 (_Decimal128 A, _Decimal128 B)
+ -- Runtime Function: int __bid_unordtd2 (_Decimal128 A, _Decimal128 B)
+ These functions return a nonzero value if either argument is NaN,
+ otherwise 0.
+
+ There is also a complete group of higher level functions which
+correspond directly to comparison operators. They implement the ISO C
+semantics for floating-point comparisons, taking NaN into account. Pay
+careful attention to the return values defined for each set. Under the
+hood, all of these routines are implemented as
+
+ if (__bid_unordXd2 (a, b))
+ return E;
+ return __bid_cmpXd2 (a, b);
+
+where E is a constant chosen to give the proper behavior for NaN.
+Thus, the meaning of the return value is different for each set. Do
+not rely on this implementation; only the semantics documented below
+are guaranteed.
+
+ -- Runtime Function: int __dpd_eqsd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __bid_eqsd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __dpd_eqdd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __bid_eqdd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __dpd_eqtd2 (_Decimal128 A, _Decimal128 B)
+ -- Runtime Function: int __bid_eqtd2 (_Decimal128 A, _Decimal128 B)
+ These functions return zero if neither argument is NaN, and A and
+ B are equal.
+
+ -- Runtime Function: int __dpd_nesd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __bid_nesd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __dpd_nedd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __bid_nedd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __dpd_netd2 (_Decimal128 A, _Decimal128 B)
+ -- Runtime Function: int __bid_netd2 (_Decimal128 A, _Decimal128 B)
+ These functions return a nonzero value if either argument is NaN,
+ or if A and B are unequal.
+
+ -- Runtime Function: int __dpd_gesd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __bid_gesd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __dpd_gedd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __bid_gedd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __dpd_getd2 (_Decimal128 A, _Decimal128 B)
+ -- Runtime Function: int __bid_getd2 (_Decimal128 A, _Decimal128 B)
+ These functions return a value greater than or equal to zero if
+ neither argument is NaN, and A is greater than or equal to B.
+
+ -- Runtime Function: int __dpd_ltsd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __bid_ltsd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __dpd_ltdd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __bid_ltdd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __dpd_lttd2 (_Decimal128 A, _Decimal128 B)
+ -- Runtime Function: int __bid_lttd2 (_Decimal128 A, _Decimal128 B)
+ These functions return a value less than zero if neither argument
+ is NaN, and A is strictly less than B.
+
+ -- Runtime Function: int __dpd_lesd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __bid_lesd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __dpd_ledd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __bid_ledd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __dpd_letd2 (_Decimal128 A, _Decimal128 B)
+ -- Runtime Function: int __bid_letd2 (_Decimal128 A, _Decimal128 B)
+ These functions return a value less than or equal to zero if
+ neither argument is NaN, and A is less than or equal to B.
+
+ -- Runtime Function: int __dpd_gtsd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __bid_gtsd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __dpd_gtdd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __bid_gtdd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __dpd_gttd2 (_Decimal128 A, _Decimal128 B)
+ -- Runtime Function: int __bid_gttd2 (_Decimal128 A, _Decimal128 B)
+ These functions return a value greater than zero if neither
+ argument is NaN, and A is strictly greater than B.
+
+\1f
+File: gccint.info, Node: Fixed-point fractional library routines, Next: Exception handling routines, Prev: Decimal float library routines, Up: Libgcc
+
+4.4 Routines for fixed-point fractional emulation
+=================================================
+
+The software fixed-point library implements fixed-point fractional
+arithmetic, and is only activated on selected targets.
+
+ For ease of comprehension `fract' is an alias for the `_Fract' type,
+`accum' an alias for `_Accum', and `sat' an alias for `_Sat'.
+
+ For illustrative purposes, in this section the fixed-point fractional
+type `short fract' is assumed to correspond to machine mode `QQmode';
+`unsigned short fract' to `UQQmode'; `fract' to `HQmode';
+`unsigned fract' to `UHQmode'; `long fract' to `SQmode';
+`unsigned long fract' to `USQmode'; `long long fract' to `DQmode'; and
+`unsigned long long fract' to `UDQmode'. Similarly the fixed-point
+accumulator type `short accum' corresponds to `HAmode';
+`unsigned short accum' to `UHAmode'; `accum' to `SAmode';
+`unsigned accum' to `USAmode'; `long accum' to `DAmode';
+`unsigned long accum' to `UDAmode'; `long long accum' to `TAmode'; and
+`unsigned long long accum' to `UTAmode'.
+
+4.4.1 Arithmetic functions
+--------------------------
+
+ -- Runtime Function: short fract __addqq3 (short fract A, short fract
+ B)
+ -- Runtime Function: fract __addhq3 (fract A, fract B)
+ -- Runtime Function: long fract __addsq3 (long fract A, long fract B)
+ -- Runtime Function: long long fract __adddq3 (long long fract A, long
+ long fract B)
+ -- Runtime Function: unsigned short fract __adduqq3 (unsigned short
+ fract A, unsigned short fract B)
+ -- Runtime Function: unsigned fract __adduhq3 (unsigned fract A,
+ unsigned fract B)
+ -- Runtime Function: unsigned long fract __addusq3 (unsigned long
+ fract A, unsigned long fract B)
+ -- Runtime Function: unsigned long long fract __addudq3 (unsigned long
+ long fract A, unsigned long long fract B)
+ -- Runtime Function: short accum __addha3 (short accum A, short accum
+ B)
+ -- Runtime Function: accum __addsa3 (accum A, accum B)
+ -- Runtime Function: long accum __addda3 (long accum A, long accum B)
+ -- Runtime Function: long long accum __addta3 (long long accum A, long
+ long accum B)
+ -- Runtime Function: unsigned short accum __adduha3 (unsigned short
+ accum A, unsigned short accum B)
+ -- Runtime Function: unsigned accum __addusa3 (unsigned accum A,
+ unsigned accum B)
+ -- Runtime Function: unsigned long accum __adduda3 (unsigned long
+ accum A, unsigned long accum B)
+ -- Runtime Function: unsigned long long accum __adduta3 (unsigned long
+ long accum A, unsigned long long accum B)
+ These functions return the sum of A and B.
+
+ -- Runtime Function: short fract __ssaddqq3 (short fract A, short
+ fract B)
+ -- Runtime Function: fract __ssaddhq3 (fract A, fract B)
+ -- Runtime Function: long fract __ssaddsq3 (long fract A, long fract B)
+ -- Runtime Function: long long fract __ssadddq3 (long long fract A,
+ long long fract B)
+ -- Runtime Function: short accum __ssaddha3 (short accum A, short
+ accum B)
+ -- Runtime Function: accum __ssaddsa3 (accum A, accum B)
+ -- Runtime Function: long accum __ssaddda3 (long accum A, long accum B)
+ -- Runtime Function: long long accum __ssaddta3 (long long accum A,
+ long long accum B)
+ These functions return the sum of A and B with signed saturation.
+
+ -- Runtime Function: unsigned short fract __usadduqq3 (unsigned short
+ fract A, unsigned short fract B)
+ -- Runtime Function: unsigned fract __usadduhq3 (unsigned fract A,
+ unsigned fract B)
+ -- Runtime Function: unsigned long fract __usaddusq3 (unsigned long
+ fract A, unsigned long fract B)
+ -- Runtime Function: unsigned long long fract __usaddudq3 (unsigned
+ long long fract A, unsigned long long fract B)
+ -- Runtime Function: unsigned short accum __usadduha3 (unsigned short
+ accum A, unsigned short accum B)
+ -- Runtime Function: unsigned accum __usaddusa3 (unsigned accum A,
+ unsigned accum B)
+ -- Runtime Function: unsigned long accum __usadduda3 (unsigned long
+ accum A, unsigned long accum B)
+ -- Runtime Function: unsigned long long accum __usadduta3 (unsigned
+ long long accum A, unsigned long long accum B)
+ These functions return the sum of A and B with unsigned saturation.
+
+ -- Runtime Function: short fract __subqq3 (short fract A, short fract
+ B)
+ -- Runtime Function: fract __subhq3 (fract A, fract B)
+ -- Runtime Function: long fract __subsq3 (long fract A, long fract B)
+ -- Runtime Function: long long fract __subdq3 (long long fract A, long
+ long fract B)
+ -- Runtime Function: unsigned short fract __subuqq3 (unsigned short
+ fract A, unsigned short fract B)
+ -- Runtime Function: unsigned fract __subuhq3 (unsigned fract A,
+ unsigned fract B)
+ -- Runtime Function: unsigned long fract __subusq3 (unsigned long
+ fract A, unsigned long fract B)
+ -- Runtime Function: unsigned long long fract __subudq3 (unsigned long
+ long fract A, unsigned long long fract B)
+ -- Runtime Function: short accum __subha3 (short accum A, short accum
+ B)
+ -- Runtime Function: accum __subsa3 (accum A, accum B)
+ -- Runtime Function: long accum __subda3 (long accum A, long accum B)
+ -- Runtime Function: long long accum __subta3 (long long accum A, long
+ long accum B)
+ -- Runtime Function: unsigned short accum __subuha3 (unsigned short
+ accum A, unsigned short accum B)
+ -- Runtime Function: unsigned accum __subusa3 (unsigned accum A,
+ unsigned accum B)
+ -- Runtime Function: unsigned long accum __subuda3 (unsigned long
+ accum A, unsigned long accum B)
+ -- Runtime Function: unsigned long long accum __subuta3 (unsigned long
+ long accum A, unsigned long long accum B)
+ These functions return the difference of A and B; that is, `A - B'.
+
+ -- Runtime Function: short fract __sssubqq3 (short fract A, short
+ fract B)
+ -- Runtime Function: fract __sssubhq3 (fract A, fract B)
+ -- Runtime Function: long fract __sssubsq3 (long fract A, long fract B)
+ -- Runtime Function: long long fract __sssubdq3 (long long fract A,
+ long long fract B)
+ -- Runtime Function: short accum __sssubha3 (short accum A, short
+ accum B)
+ -- Runtime Function: accum __sssubsa3 (accum A, accum B)
+ -- Runtime Function: long accum __sssubda3 (long accum A, long accum B)
+ -- Runtime Function: long long accum __sssubta3 (long long accum A,
+ long long accum B)
+ These functions return the difference of A and B with signed
+ saturation; that is, `A - B'.
+
+ -- Runtime Function: unsigned short fract __ussubuqq3 (unsigned short
+ fract A, unsigned short fract B)
+ -- Runtime Function: unsigned fract __ussubuhq3 (unsigned fract A,
+ unsigned fract B)
+ -- Runtime Function: unsigned long fract __ussubusq3 (unsigned long
+ fract A, unsigned long fract B)
+ -- Runtime Function: unsigned long long fract __ussubudq3 (unsigned
+ long long fract A, unsigned long long fract B)
+ -- Runtime Function: unsigned short accum __ussubuha3 (unsigned short
+ accum A, unsigned short accum B)
+ -- Runtime Function: unsigned accum __ussubusa3 (unsigned accum A,
+ unsigned accum B)
+ -- Runtime Function: unsigned long accum __ussubuda3 (unsigned long
+ accum A, unsigned long accum B)
+ -- Runtime Function: unsigned long long accum __ussubuta3 (unsigned
+ long long accum A, unsigned long long accum B)
+ These functions return the difference of A and B with unsigned
+ saturation; that is, `A - B'.
+
+ -- Runtime Function: short fract __mulqq3 (short fract A, short fract
+ B)
+ -- Runtime Function: fract __mulhq3 (fract A, fract B)
+ -- Runtime Function: long fract __mulsq3 (long fract A, long fract B)
+ -- Runtime Function: long long fract __muldq3 (long long fract A, long
+ long fract B)
+ -- Runtime Function: unsigned short fract __muluqq3 (unsigned short
+ fract A, unsigned short fract B)
+ -- Runtime Function: unsigned fract __muluhq3 (unsigned fract A,
+ unsigned fract B)
+ -- Runtime Function: unsigned long fract __mulusq3 (unsigned long
+ fract A, unsigned long fract B)
+ -- Runtime Function: unsigned long long fract __muludq3 (unsigned long
+ long fract A, unsigned long long fract B)
+ -- Runtime Function: short accum __mulha3 (short accum A, short accum
+ B)
+ -- Runtime Function: accum __mulsa3 (accum A, accum B)
+ -- Runtime Function: long accum __mulda3 (long accum A, long accum B)
+ -- Runtime Function: long long accum __multa3 (long long accum A, long
+ long accum B)
+ -- Runtime Function: unsigned short accum __muluha3 (unsigned short
+ accum A, unsigned short accum B)
+ -- Runtime Function: unsigned accum __mulusa3 (unsigned accum A,
+ unsigned accum B)
+ -- Runtime Function: unsigned long accum __muluda3 (unsigned long
+ accum A, unsigned long accum B)
+ -- Runtime Function: unsigned long long accum __muluta3 (unsigned long
+ long accum A, unsigned long long accum B)
+ These functions return the product of A and B.
+
+ -- Runtime Function: short fract __ssmulqq3 (short fract A, short
+ fract B)
+ -- Runtime Function: fract __ssmulhq3 (fract A, fract B)
+ -- Runtime Function: long fract __ssmulsq3 (long fract A, long fract B)
+ -- Runtime Function: long long fract __ssmuldq3 (long long fract A,
+ long long fract B)
+ -- Runtime Function: short accum __ssmulha3 (short accum A, short
+ accum B)
+ -- Runtime Function: accum __ssmulsa3 (accum A, accum B)
+ -- Runtime Function: long accum __ssmulda3 (long accum A, long accum B)
+ -- Runtime Function: long long accum __ssmulta3 (long long accum A,
+ long long accum B)
+ These functions return the product of A and B with signed
+ saturation.
+
+ -- Runtime Function: unsigned short fract __usmuluqq3 (unsigned short
+ fract A, unsigned short fract B)
+ -- Runtime Function: unsigned fract __usmuluhq3 (unsigned fract A,
+ unsigned fract B)
+ -- Runtime Function: unsigned long fract __usmulusq3 (unsigned long
+ fract A, unsigned long fract B)
+ -- Runtime Function: unsigned long long fract __usmuludq3 (unsigned
+ long long fract A, unsigned long long fract B)
+ -- Runtime Function: unsigned short accum __usmuluha3 (unsigned short
+ accum A, unsigned short accum B)
+ -- Runtime Function: unsigned accum __usmulusa3 (unsigned accum A,
+ unsigned accum B)
+ -- Runtime Function: unsigned long accum __usmuluda3 (unsigned long
+ accum A, unsigned long accum B)
+ -- Runtime Function: unsigned long long accum __usmuluta3 (unsigned
+ long long accum A, unsigned long long accum B)
+ These functions return the product of A and B with unsigned
+ saturation.
+
+ -- Runtime Function: short fract __divqq3 (short fract A, short fract
+ B)
+ -- Runtime Function: fract __divhq3 (fract A, fract B)
+ -- Runtime Function: long fract __divsq3 (long fract A, long fract B)
+ -- Runtime Function: long long fract __divdq3 (long long fract A, long
+ long fract B)
+ -- Runtime Function: short accum __divha3 (short accum A, short accum
+ B)
+ -- Runtime Function: accum __divsa3 (accum A, accum B)
+ -- Runtime Function: long accum __divda3 (long accum A, long accum B)
+ -- Runtime Function: long long accum __divta3 (long long accum A, long
+ long accum B)
+ These functions return the quotient of the signed division of A
+ and B.
+
+ -- Runtime Function: unsigned short fract __udivuqq3 (unsigned short
+ fract A, unsigned short fract B)
+ -- Runtime Function: unsigned fract __udivuhq3 (unsigned fract A,
+ unsigned fract B)
+ -- Runtime Function: unsigned long fract __udivusq3 (unsigned long
+ fract A, unsigned long fract B)
+ -- Runtime Function: unsigned long long fract __udivudq3 (unsigned
+ long long fract A, unsigned long long fract B)
+ -- Runtime Function: unsigned short accum __udivuha3 (unsigned short
+ accum A, unsigned short accum B)
+ -- Runtime Function: unsigned accum __udivusa3 (unsigned accum A,
+ unsigned accum B)
+ -- Runtime Function: unsigned long accum __udivuda3 (unsigned long
+ accum A, unsigned long accum B)
+ -- Runtime Function: unsigned long long accum __udivuta3 (unsigned
+ long long accum A, unsigned long long accum B)
+ These functions return the quotient of the unsigned division of A
+ and B.
+
+ -- Runtime Function: short fract __ssdivqq3 (short fract A, short
+ fract B)
+ -- Runtime Function: fract __ssdivhq3 (fract A, fract B)
+ -- Runtime Function: long fract __ssdivsq3 (long fract A, long fract B)
+ -- Runtime Function: long long fract __ssdivdq3 (long long fract A,
+ long long fract B)
+ -- Runtime Function: short accum __ssdivha3 (short accum A, short
+ accum B)
+ -- Runtime Function: accum __ssdivsa3 (accum A, accum B)
+ -- Runtime Function: long accum __ssdivda3 (long accum A, long accum B)
+ -- Runtime Function: long long accum __ssdivta3 (long long accum A,
+ long long accum B)
+ These functions return the quotient of the signed division of A
+ and B with signed saturation.
+
+ -- Runtime Function: unsigned short fract __usdivuqq3 (unsigned short
+ fract A, unsigned short fract B)
+ -- Runtime Function: unsigned fract __usdivuhq3 (unsigned fract A,
+ unsigned fract B)
+ -- Runtime Function: unsigned long fract __usdivusq3 (unsigned long
+ fract A, unsigned long fract B)
+ -- Runtime Function: unsigned long long fract __usdivudq3 (unsigned
+ long long fract A, unsigned long long fract B)
+ -- Runtime Function: unsigned short accum __usdivuha3 (unsigned short
+ accum A, unsigned short accum B)
+ -- Runtime Function: unsigned accum __usdivusa3 (unsigned accum A,
+ unsigned accum B)
+ -- Runtime Function: unsigned long accum __usdivuda3 (unsigned long
+ accum A, unsigned long accum B)
+ -- Runtime Function: unsigned long long accum __usdivuta3 (unsigned
+ long long accum A, unsigned long long accum B)
+ These functions return the quotient of the unsigned division of A
+ and B with unsigned saturation.
+
+ -- Runtime Function: short fract __negqq2 (short fract A)
+ -- Runtime Function: fract __neghq2 (fract A)
+ -- Runtime Function: long fract __negsq2 (long fract A)
+ -- Runtime Function: long long fract __negdq2 (long long fract A)
+ -- Runtime Function: unsigned short fract __neguqq2 (unsigned short
+ fract A)
+ -- Runtime Function: unsigned fract __neguhq2 (unsigned fract A)
+ -- Runtime Function: unsigned long fract __negusq2 (unsigned long
+ fract A)
+ -- Runtime Function: unsigned long long fract __negudq2 (unsigned long
+ long fract A)
+ -- Runtime Function: short accum __negha2 (short accum A)
+ -- Runtime Function: accum __negsa2 (accum A)
+ -- Runtime Function: long accum __negda2 (long accum A)
+ -- Runtime Function: long long accum __negta2 (long long accum A)
+ -- Runtime Function: unsigned short accum __neguha2 (unsigned short
+ accum A)
+ -- Runtime Function: unsigned accum __negusa2 (unsigned accum A)
+ -- Runtime Function: unsigned long accum __neguda2 (unsigned long
+ accum A)
+ -- Runtime Function: unsigned long long accum __neguta2 (unsigned long
+ long accum A)
+ These functions return the negation of A.
+
+ -- Runtime Function: short fract __ssnegqq2 (short fract A)
+ -- Runtime Function: fract __ssneghq2 (fract A)
+ -- Runtime Function: long fract __ssnegsq2 (long fract A)
+ -- Runtime Function: long long fract __ssnegdq2 (long long fract A)
+ -- Runtime Function: short accum __ssnegha2 (short accum A)
+ -- Runtime Function: accum __ssnegsa2 (accum A)
+ -- Runtime Function: long accum __ssnegda2 (long accum A)
+ -- Runtime Function: long long accum __ssnegta2 (long long accum A)
+ These functions return the negation of A with signed saturation.
+
+ -- Runtime Function: unsigned short fract __usneguqq2 (unsigned short
+ fract A)
+ -- Runtime Function: unsigned fract __usneguhq2 (unsigned fract A)
+ -- Runtime Function: unsigned long fract __usnegusq2 (unsigned long
+ fract A)
+ -- Runtime Function: unsigned long long fract __usnegudq2 (unsigned
+ long long fract A)
+ -- Runtime Function: unsigned short accum __usneguha2 (unsigned short
+ accum A)
+ -- Runtime Function: unsigned accum __usnegusa2 (unsigned accum A)
+ -- Runtime Function: unsigned long accum __usneguda2 (unsigned long
+ accum A)
+ -- Runtime Function: unsigned long long accum __usneguta2 (unsigned
+ long long accum A)
+ These functions return the negation of A with unsigned saturation.
+
+ -- Runtime Function: short fract __ashlqq3 (short fract A, int B)
+ -- Runtime Function: fract __ashlhq3 (fract A, int B)
+ -- Runtime Function: long fract __ashlsq3 (long fract A, int B)
+ -- Runtime Function: long long fract __ashldq3 (long long fract A, int
+ B)
+ -- Runtime Function: unsigned short fract __ashluqq3 (unsigned short
+ fract A, int B)
+ -- Runtime Function: unsigned fract __ashluhq3 (unsigned fract A, int
+ B)
+ -- Runtime Function: unsigned long fract __ashlusq3 (unsigned long
+ fract A, int B)
+ -- Runtime Function: unsigned long long fract __ashludq3 (unsigned
+ long long fract A, int B)
+ -- Runtime Function: short accum __ashlha3 (short accum A, int B)
+ -- Runtime Function: accum __ashlsa3 (accum A, int B)
+ -- Runtime Function: long accum __ashlda3 (long accum A, int B)
+ -- Runtime Function: long long accum __ashlta3 (long long accum A, int
+ B)
+ -- Runtime Function: unsigned short accum __ashluha3 (unsigned short
+ accum A, int B)
+ -- Runtime Function: unsigned accum __ashlusa3 (unsigned accum A, int
+ B)
+ -- Runtime Function: unsigned long accum __ashluda3 (unsigned long
+ accum A, int B)
+ -- Runtime Function: unsigned long long accum __ashluta3 (unsigned
+ long long accum A, int B)
+ These functions return the result of shifting A left by B bits.
+
+ -- Runtime Function: short fract __ashrqq3 (short fract A, int B)
+ -- Runtime Function: fract __ashrhq3 (fract A, int B)
+ -- Runtime Function: long fract __ashrsq3 (long fract A, int B)
+ -- Runtime Function: long long fract __ashrdq3 (long long fract A, int
+ B)
+ -- Runtime Function: short accum __ashrha3 (short accum A, int B)
+ -- Runtime Function: accum __ashrsa3 (accum A, int B)
+ -- Runtime Function: long accum __ashrda3 (long accum A, int B)
+ -- Runtime Function: long long accum __ashrta3 (long long accum A, int
+ B)
+ These functions return the result of arithmetically shifting A
+ right by B bits.
+
+ -- Runtime Function: unsigned short fract __lshruqq3 (unsigned short
+ fract A, int B)
+ -- Runtime Function: unsigned fract __lshruhq3 (unsigned fract A, int
+ B)
+ -- Runtime Function: unsigned long fract __lshrusq3 (unsigned long
+ fract A, int B)
+ -- Runtime Function: unsigned long long fract __lshrudq3 (unsigned
+ long long fract A, int B)
+ -- Runtime Function: unsigned short accum __lshruha3 (unsigned short
+ accum A, int B)
+ -- Runtime Function: unsigned accum __lshrusa3 (unsigned accum A, int
+ B)
+ -- Runtime Function: unsigned long accum __lshruda3 (unsigned long
+ accum A, int B)
+ -- Runtime Function: unsigned long long accum __lshruta3 (unsigned
+ long long accum A, int B)
+ These functions return the result of logically shifting A right by
+ B bits.
+
+ -- Runtime Function: fract __ssashlhq3 (fract A, int B)
+ -- Runtime Function: long fract __ssashlsq3 (long fract A, int B)
+ -- Runtime Function: long long fract __ssashldq3 (long long fract A,
+ int B)
+ -- Runtime Function: short accum __ssashlha3 (short accum A, int B)
+ -- Runtime Function: accum __ssashlsa3 (accum A, int B)
+ -- Runtime Function: long accum __ssashlda3 (long accum A, int B)
+ -- Runtime Function: long long accum __ssashlta3 (long long accum A,
+ int B)
+ These functions return the result of shifting A left by B bits
+ with signed saturation.
+
+ -- Runtime Function: unsigned short fract __usashluqq3 (unsigned short
+ fract A, int B)
+ -- Runtime Function: unsigned fract __usashluhq3 (unsigned fract A,
+ int B)
+ -- Runtime Function: unsigned long fract __usashlusq3 (unsigned long
+ fract A, int B)
+ -- Runtime Function: unsigned long long fract __usashludq3 (unsigned
+ long long fract A, int B)
+ -- Runtime Function: unsigned short accum __usashluha3 (unsigned short
+ accum A, int B)
+ -- Runtime Function: unsigned accum __usashlusa3 (unsigned accum A,
+ int B)
+ -- Runtime Function: unsigned long accum __usashluda3 (unsigned long
+ accum A, int B)
+ -- Runtime Function: unsigned long long accum __usashluta3 (unsigned
+ long long accum A, int B)
+ These functions return the result of shifting A left by B bits
+ with unsigned saturation.
+
+4.4.2 Comparison functions
+--------------------------
+
+The following functions implement fixed-point comparisons. These
+functions implement a low-level compare, upon which the higher level
+comparison operators (such as less than and greater than or equal to)
+can be constructed. The returned values lie in the range zero to two,
+to allow the high-level operators to be implemented by testing the
+returned result using either signed or unsigned comparison.
+
+ -- Runtime Function: int __cmpqq2 (short fract A, short fract B)
+ -- Runtime Function: int __cmphq2 (fract A, fract B)
+ -- Runtime Function: int __cmpsq2 (long fract A, long fract B)
+ -- Runtime Function: int __cmpdq2 (long long fract A, long long fract
+ B)
+ -- Runtime Function: int __cmpuqq2 (unsigned short fract A, unsigned
+ short fract B)
+ -- Runtime Function: int __cmpuhq2 (unsigned fract A, unsigned fract B)
+ -- Runtime Function: int __cmpusq2 (unsigned long fract A, unsigned
+ long fract B)
+ -- Runtime Function: int __cmpudq2 (unsigned long long fract A,
+ unsigned long long fract B)
+ -- Runtime Function: int __cmpha2 (short accum A, short accum B)
+ -- Runtime Function: int __cmpsa2 (accum A, accum B)
+ -- Runtime Function: int __cmpda2 (long accum A, long accum B)
+ -- Runtime Function: int __cmpta2 (long long accum A, long long accum
+ B)
+ -- Runtime Function: int __cmpuha2 (unsigned short accum A, unsigned
+ short accum B)
+ -- Runtime Function: int __cmpusa2 (unsigned accum A, unsigned accum B)
+ -- Runtime Function: int __cmpuda2 (unsigned long accum A, unsigned
+ long accum B)
+ -- Runtime Function: int __cmputa2 (unsigned long long accum A,
+ unsigned long long accum B)
+ These functions perform a signed or unsigned comparison of A and B
+ (depending on the selected machine mode). If A is less than B,
+ they return 0; if A is greater than B, they return 2; and if A and
+ B are equal they return 1.
+
+4.4.3 Conversion functions
+--------------------------
+
+ -- Runtime Function: fract __fractqqhq2 (short fract A)
+ -- Runtime Function: long fract __fractqqsq2 (short fract A)
+ -- Runtime Function: long long fract __fractqqdq2 (short fract A)
+ -- Runtime Function: short accum __fractqqha (short fract A)
+ -- Runtime Function: accum __fractqqsa (short fract A)
+ -- Runtime Function: long accum __fractqqda (short fract A)
+ -- Runtime Function: long long accum __fractqqta (short fract A)
+ -- Runtime Function: unsigned short fract __fractqquqq (short fract A)
+ -- Runtime Function: unsigned fract __fractqquhq (short fract A)
+ -- Runtime Function: unsigned long fract __fractqqusq (short fract A)
+ -- Runtime Function: unsigned long long fract __fractqqudq (short
+ fract A)
+ -- Runtime Function: unsigned short accum __fractqquha (short fract A)
+ -- Runtime Function: unsigned accum __fractqqusa (short fract A)
+ -- Runtime Function: unsigned long accum __fractqquda (short fract A)
+ -- Runtime Function: unsigned long long accum __fractqquta (short
+ fract A)
+ -- Runtime Function: signed char __fractqqqi (short fract A)
+ -- Runtime Function: short __fractqqhi (short fract A)
+ -- Runtime Function: int __fractqqsi (short fract A)
+ -- Runtime Function: long __fractqqdi (short fract A)
+ -- Runtime Function: long long __fractqqti (short fract A)
+ -- Runtime Function: float __fractqqsf (short fract A)
+ -- Runtime Function: double __fractqqdf (short fract A)
+ -- Runtime Function: short fract __fracthqqq2 (fract A)
+ -- Runtime Function: long fract __fracthqsq2 (fract A)
+ -- Runtime Function: long long fract __fracthqdq2 (fract A)
+ -- Runtime Function: short accum __fracthqha (fract A)
+ -- Runtime Function: accum __fracthqsa (fract A)
+ -- Runtime Function: long accum __fracthqda (fract A)
+ -- Runtime Function: long long accum __fracthqta (fract A)
+ -- Runtime Function: unsigned short fract __fracthquqq (fract A)
+ -- Runtime Function: unsigned fract __fracthquhq (fract A)
+ -- Runtime Function: unsigned long fract __fracthqusq (fract A)
+ -- Runtime Function: unsigned long long fract __fracthqudq (fract A)
+ -- Runtime Function: unsigned short accum __fracthquha (fract A)
+ -- Runtime Function: unsigned accum __fracthqusa (fract A)
+ -- Runtime Function: unsigned long accum __fracthquda (fract A)
+ -- Runtime Function: unsigned long long accum __fracthquta (fract A)
+ -- Runtime Function: signed char __fracthqqi (fract A)
+ -- Runtime Function: short __fracthqhi (fract A)
+ -- Runtime Function: int __fracthqsi (fract A)
+ -- Runtime Function: long __fracthqdi (fract A)
+ -- Runtime Function: long long __fracthqti (fract A)
+ -- Runtime Function: float __fracthqsf (fract A)
+ -- Runtime Function: double __fracthqdf (fract A)
+ -- Runtime Function: short fract __fractsqqq2 (long fract A)
+ -- Runtime Function: fract __fractsqhq2 (long fract A)
+ -- Runtime Function: long long fract __fractsqdq2 (long fract A)
+ -- Runtime Function: short accum __fractsqha (long fract A)
+ -- Runtime Function: accum __fractsqsa (long fract A)
+ -- Runtime Function: long accum __fractsqda (long fract A)
+ -- Runtime Function: long long accum __fractsqta (long fract A)
+ -- Runtime Function: unsigned short fract __fractsquqq (long fract A)
+ -- Runtime Function: unsigned fract __fractsquhq (long fract A)
+ -- Runtime Function: unsigned long fract __fractsqusq (long fract A)
+ -- Runtime Function: unsigned long long fract __fractsqudq (long fract
+ A)
+ -- Runtime Function: unsigned short accum __fractsquha (long fract A)
+ -- Runtime Function: unsigned accum __fractsqusa (long fract A)
+ -- Runtime Function: unsigned long accum __fractsquda (long fract A)
+ -- Runtime Function: unsigned long long accum __fractsquta (long fract
+ A)
+ -- Runtime Function: signed char __fractsqqi (long fract A)
+ -- Runtime Function: short __fractsqhi (long fract A)
+ -- Runtime Function: int __fractsqsi (long fract A)
+ -- Runtime Function: long __fractsqdi (long fract A)
+ -- Runtime Function: long long __fractsqti (long fract A)
+ -- Runtime Function: float __fractsqsf (long fract A)
+ -- Runtime Function: double __fractsqdf (long fract A)
+ -- Runtime Function: short fract __fractdqqq2 (long long fract A)
+ -- Runtime Function: fract __fractdqhq2 (long long fract A)
+ -- Runtime Function: long fract __fractdqsq2 (long long fract A)
+ -- Runtime Function: short accum __fractdqha (long long fract A)
+ -- Runtime Function: accum __fractdqsa (long long fract A)
+ -- Runtime Function: long accum __fractdqda (long long fract A)
+ -- Runtime Function: long long accum __fractdqta (long long fract A)
+ -- Runtime Function: unsigned short fract __fractdquqq (long long
+ fract A)
+ -- Runtime Function: unsigned fract __fractdquhq (long long fract A)
+ -- Runtime Function: unsigned long fract __fractdqusq (long long fract
+ A)
+ -- Runtime Function: unsigned long long fract __fractdqudq (long long
+ fract A)
+ -- Runtime Function: unsigned short accum __fractdquha (long long
+ fract A)
+ -- Runtime Function: unsigned accum __fractdqusa (long long fract A)
+ -- Runtime Function: unsigned long accum __fractdquda (long long fract
+ A)
+ -- Runtime Function: unsigned long long accum __fractdquta (long long
+ fract A)
+ -- Runtime Function: signed char __fractdqqi (long long fract A)
+ -- Runtime Function: short __fractdqhi (long long fract A)
+ -- Runtime Function: int __fractdqsi (long long fract A)
+ -- Runtime Function: long __fractdqdi (long long fract A)
+ -- Runtime Function: long long __fractdqti (long long fract A)
+ -- Runtime Function: float __fractdqsf (long long fract A)
+ -- Runtime Function: double __fractdqdf (long long fract A)
+ -- Runtime Function: short fract __fracthaqq (short accum A)
+ -- Runtime Function: fract __fracthahq (short accum A)
+ -- Runtime Function: long fract __fracthasq (short accum A)
+ -- Runtime Function: long long fract __fracthadq (short accum A)
+ -- Runtime Function: accum __fracthasa2 (short accum A)
+ -- Runtime Function: long accum __fracthada2 (short accum A)
+ -- Runtime Function: long long accum __fracthata2 (short accum A)
+ -- Runtime Function: unsigned short fract __fracthauqq (short accum A)
+ -- Runtime Function: unsigned fract __fracthauhq (short accum A)
+ -- Runtime Function: unsigned long fract __fracthausq (short accum A)
+ -- Runtime Function: unsigned long long fract __fracthaudq (short
+ accum A)
+ -- Runtime Function: unsigned short accum __fracthauha (short accum A)
+ -- Runtime Function: unsigned accum __fracthausa (short accum A)
+ -- Runtime Function: unsigned long accum __fracthauda (short accum A)
+ -- Runtime Function: unsigned long long accum __fracthauta (short
+ accum A)
+ -- Runtime Function: signed char __fracthaqi (short accum A)
+ -- Runtime Function: short __fracthahi (short accum A)
+ -- Runtime Function: int __fracthasi (short accum A)
+ -- Runtime Function: long __fracthadi (short accum A)
+ -- Runtime Function: long long __fracthati (short accum A)
+ -- Runtime Function: float __fracthasf (short accum A)
+ -- Runtime Function: double __fracthadf (short accum A)
+ -- Runtime Function: short fract __fractsaqq (accum A)
+ -- Runtime Function: fract __fractsahq (accum A)
+ -- Runtime Function: long fract __fractsasq (accum A)
+ -- Runtime Function: long long fract __fractsadq (accum A)
+ -- Runtime Function: short accum __fractsaha2 (accum A)
+ -- Runtime Function: long accum __fractsada2 (accum A)
+ -- Runtime Function: long long accum __fractsata2 (accum A)
+ -- Runtime Function: unsigned short fract __fractsauqq (accum A)
+ -- Runtime Function: unsigned fract __fractsauhq (accum A)
+ -- Runtime Function: unsigned long fract __fractsausq (accum A)
+ -- Runtime Function: unsigned long long fract __fractsaudq (accum A)
+ -- Runtime Function: unsigned short accum __fractsauha (accum A)
+ -- Runtime Function: unsigned accum __fractsausa (accum A)
+ -- Runtime Function: unsigned long accum __fractsauda (accum A)
+ -- Runtime Function: unsigned long long accum __fractsauta (accum A)
+ -- Runtime Function: signed char __fractsaqi (accum A)
+ -- Runtime Function: short __fractsahi (accum A)
+ -- Runtime Function: int __fractsasi (accum A)
+ -- Runtime Function: long __fractsadi (accum A)
+ -- Runtime Function: long long __fractsati (accum A)
+ -- Runtime Function: float __fractsasf (accum A)
+ -- Runtime Function: double __fractsadf (accum A)
+ -- Runtime Function: short fract __fractdaqq (long accum A)
+ -- Runtime Function: fract __fractdahq (long accum A)
+ -- Runtime Function: long fract __fractdasq (long accum A)
+ -- Runtime Function: long long fract __fractdadq (long accum A)
+ -- Runtime Function: short accum __fractdaha2 (long accum A)
+ -- Runtime Function: accum __fractdasa2 (long accum A)
+ -- Runtime Function: long long accum __fractdata2 (long accum A)
+ -- Runtime Function: unsigned short fract __fractdauqq (long accum A)
+ -- Runtime Function: unsigned fract __fractdauhq (long accum A)
+ -- Runtime Function: unsigned long fract __fractdausq (long accum A)
+ -- Runtime Function: unsigned long long fract __fractdaudq (long accum
+ A)
+ -- Runtime Function: unsigned short accum __fractdauha (long accum A)
+ -- Runtime Function: unsigned accum __fractdausa (long accum A)
+ -- Runtime Function: unsigned long accum __fractdauda (long accum A)
+ -- Runtime Function: unsigned long long accum __fractdauta (long accum
+ A)
+ -- Runtime Function: signed char __fractdaqi (long accum A)
+ -- Runtime Function: short __fractdahi (long accum A)
+ -- Runtime Function: int __fractdasi (long accum A)
+ -- Runtime Function: long __fractdadi (long accum A)
+ -- Runtime Function: long long __fractdati (long accum A)
+ -- Runtime Function: float __fractdasf (long accum A)
+ -- Runtime Function: double __fractdadf (long accum A)
+ -- Runtime Function: short fract __fracttaqq (long long accum A)
+ -- Runtime Function: fract __fracttahq (long long accum A)
+ -- Runtime Function: long fract __fracttasq (long long accum A)
+ -- Runtime Function: long long fract __fracttadq (long long accum A)
+ -- Runtime Function: short accum __fracttaha2 (long long accum A)
+ -- Runtime Function: accum __fracttasa2 (long long accum A)
+ -- Runtime Function: long accum __fracttada2 (long long accum A)
+ -- Runtime Function: unsigned short fract __fracttauqq (long long
+ accum A)
+ -- Runtime Function: unsigned fract __fracttauhq (long long accum A)
+ -- Runtime Function: unsigned long fract __fracttausq (long long accum
+ A)
+ -- Runtime Function: unsigned long long fract __fracttaudq (long long
+ accum A)
+ -- Runtime Function: unsigned short accum __fracttauha (long long
+ accum A)
+ -- Runtime Function: unsigned accum __fracttausa (long long accum A)
+ -- Runtime Function: unsigned long accum __fracttauda (long long accum
+ A)
+ -- Runtime Function: unsigned long long accum __fracttauta (long long
+ accum A)
+ -- Runtime Function: signed char __fracttaqi (long long accum A)
+ -- Runtime Function: short __fracttahi (long long accum A)
+ -- Runtime Function: int __fracttasi (long long accum A)
+ -- Runtime Function: long __fracttadi (long long accum A)
+ -- Runtime Function: long long __fracttati (long long accum A)
+ -- Runtime Function: float __fracttasf (long long accum A)
+ -- Runtime Function: double __fracttadf (long long accum A)
+ -- Runtime Function: short fract __fractuqqqq (unsigned short fract A)
+ -- Runtime Function: fract __fractuqqhq (unsigned short fract A)
+ -- Runtime Function: long fract __fractuqqsq (unsigned short fract A)
+ -- Runtime Function: long long fract __fractuqqdq (unsigned short
+ fract A)
+ -- Runtime Function: short accum __fractuqqha (unsigned short fract A)
+ -- Runtime Function: accum __fractuqqsa (unsigned short fract A)
+ -- Runtime Function: long accum __fractuqqda (unsigned short fract A)
+ -- Runtime Function: long long accum __fractuqqta (unsigned short
+ fract A)
+ -- Runtime Function: unsigned fract __fractuqquhq2 (unsigned short
+ fract A)
+ -- Runtime Function: unsigned long fract __fractuqqusq2 (unsigned
+ short fract A)
+ -- Runtime Function: unsigned long long fract __fractuqqudq2 (unsigned
+ short fract A)
+ -- Runtime Function: unsigned short accum __fractuqquha (unsigned
+ short fract A)
+ -- Runtime Function: unsigned accum __fractuqqusa (unsigned short
+ fract A)
+ -- Runtime Function: unsigned long accum __fractuqquda (unsigned short
+ fract A)
+ -- Runtime Function: unsigned long long accum __fractuqquta (unsigned
+ short fract A)
+ -- Runtime Function: signed char __fractuqqqi (unsigned short fract A)
+ -- Runtime Function: short __fractuqqhi (unsigned short fract A)
+ -- Runtime Function: int __fractuqqsi (unsigned short fract A)
+ -- Runtime Function: long __fractuqqdi (unsigned short fract A)
+ -- Runtime Function: long long __fractuqqti (unsigned short fract A)
+ -- Runtime Function: float __fractuqqsf (unsigned short fract A)
+ -- Runtime Function: double __fractuqqdf (unsigned short fract A)
+ -- Runtime Function: short fract __fractuhqqq (unsigned fract A)
+ -- Runtime Function: fract __fractuhqhq (unsigned fract A)
+ -- Runtime Function: long fract __fractuhqsq (unsigned fract A)
+ -- Runtime Function: long long fract __fractuhqdq (unsigned fract A)
+ -- Runtime Function: short accum __fractuhqha (unsigned fract A)
+ -- Runtime Function: accum __fractuhqsa (unsigned fract A)
+ -- Runtime Function: long accum __fractuhqda (unsigned fract A)
+ -- Runtime Function: long long accum __fractuhqta (unsigned fract A)
+ -- Runtime Function: unsigned short fract __fractuhquqq2 (unsigned
+ fract A)
+ -- Runtime Function: unsigned long fract __fractuhqusq2 (unsigned
+ fract A)
+ -- Runtime Function: unsigned long long fract __fractuhqudq2 (unsigned
+ fract A)
+ -- Runtime Function: unsigned short accum __fractuhquha (unsigned
+ fract A)
+ -- Runtime Function: unsigned accum __fractuhqusa (unsigned fract A)
+ -- Runtime Function: unsigned long accum __fractuhquda (unsigned fract
+ A)
+ -- Runtime Function: unsigned long long accum __fractuhquta (unsigned
+ fract A)
+ -- Runtime Function: signed char __fractuhqqi (unsigned fract A)
+ -- Runtime Function: short __fractuhqhi (unsigned fract A)
+ -- Runtime Function: int __fractuhqsi (unsigned fract A)
+ -- Runtime Function: long __fractuhqdi (unsigned fract A)
+ -- Runtime Function: long long __fractuhqti (unsigned fract A)
+ -- Runtime Function: float __fractuhqsf (unsigned fract A)
+ -- Runtime Function: double __fractuhqdf (unsigned fract A)
+ -- Runtime Function: short fract __fractusqqq (unsigned long fract A)
+ -- Runtime Function: fract __fractusqhq (unsigned long fract A)
+ -- Runtime Function: long fract __fractusqsq (unsigned long fract A)
+ -- Runtime Function: long long fract __fractusqdq (unsigned long fract
+ A)
+ -- Runtime Function: short accum __fractusqha (unsigned long fract A)
+ -- Runtime Function: accum __fractusqsa (unsigned long fract A)
+ -- Runtime Function: long accum __fractusqda (unsigned long fract A)
+ -- Runtime Function: long long accum __fractusqta (unsigned long fract
+ A)
+ -- Runtime Function: unsigned short fract __fractusquqq2 (unsigned
+ long fract A)
+ -- Runtime Function: unsigned fract __fractusquhq2 (unsigned long
+ fract A)
+ -- Runtime Function: unsigned long long fract __fractusqudq2 (unsigned
+ long fract A)
+ -- Runtime Function: unsigned short accum __fractusquha (unsigned long
+ fract A)
+ -- Runtime Function: unsigned accum __fractusqusa (unsigned long fract
+ A)
+ -- Runtime Function: unsigned long accum __fractusquda (unsigned long
+ fract A)
+ -- Runtime Function: unsigned long long accum __fractusquta (unsigned
+ long fract A)
+ -- Runtime Function: signed char __fractusqqi (unsigned long fract A)
+ -- Runtime Function: short __fractusqhi (unsigned long fract A)
+ -- Runtime Function: int __fractusqsi (unsigned long fract A)
+ -- Runtime Function: long __fractusqdi (unsigned long fract A)
+ -- Runtime Function: long long __fractusqti (unsigned long fract A)
+ -- Runtime Function: float __fractusqsf (unsigned long fract A)
+ -- Runtime Function: double __fractusqdf (unsigned long fract A)
+ -- Runtime Function: short fract __fractudqqq (unsigned long long
+ fract A)
+ -- Runtime Function: fract __fractudqhq (unsigned long long fract A)
+ -- Runtime Function: long fract __fractudqsq (unsigned long long fract
+ A)
+ -- Runtime Function: long long fract __fractudqdq (unsigned long long
+ fract A)
+ -- Runtime Function: short accum __fractudqha (unsigned long long
+ fract A)
+ -- Runtime Function: accum __fractudqsa (unsigned long long fract A)
+ -- Runtime Function: long accum __fractudqda (unsigned long long fract
+ A)
+ -- Runtime Function: long long accum __fractudqta (unsigned long long
+ fract A)
+ -- Runtime Function: unsigned short fract __fractudquqq2 (unsigned
+ long long fract A)
+ -- Runtime Function: unsigned fract __fractudquhq2 (unsigned long long
+ fract A)
+ -- Runtime Function: unsigned long fract __fractudqusq2 (unsigned long
+ long fract A)
+ -- Runtime Function: unsigned short accum __fractudquha (unsigned long
+ long fract A)
+ -- Runtime Function: unsigned accum __fractudqusa (unsigned long long
+ fract A)
+ -- Runtime Function: unsigned long accum __fractudquda (unsigned long
+ long fract A)
+ -- Runtime Function: unsigned long long accum __fractudquta (unsigned
+ long long fract A)
+ -- Runtime Function: signed char __fractudqqi (unsigned long long
+ fract A)
+ -- Runtime Function: short __fractudqhi (unsigned long long fract A)
+ -- Runtime Function: int __fractudqsi (unsigned long long fract A)
+ -- Runtime Function: long __fractudqdi (unsigned long long fract A)
+ -- Runtime Function: long long __fractudqti (unsigned long long fract
+ A)
+ -- Runtime Function: float __fractudqsf (unsigned long long fract A)
+ -- Runtime Function: double __fractudqdf (unsigned long long fract A)
+ -- Runtime Function: short fract __fractuhaqq (unsigned short accum A)
+ -- Runtime Function: fract __fractuhahq (unsigned short accum A)
+ -- Runtime Function: long fract __fractuhasq (unsigned short accum A)
+ -- Runtime Function: long long fract __fractuhadq (unsigned short
+ accum A)
+ -- Runtime Function: short accum __fractuhaha (unsigned short accum A)
+ -- Runtime Function: accum __fractuhasa (unsigned short accum A)
+ -- Runtime Function: long accum __fractuhada (unsigned short accum A)
+ -- Runtime Function: long long accum __fractuhata (unsigned short
+ accum A)
+ -- Runtime Function: unsigned short fract __fractuhauqq (unsigned
+ short accum A)
+ -- Runtime Function: unsigned fract __fractuhauhq (unsigned short
+ accum A)
+ -- Runtime Function: unsigned long fract __fractuhausq (unsigned short
+ accum A)
+ -- Runtime Function: unsigned long long fract __fractuhaudq (unsigned
+ short accum A)
+ -- Runtime Function: unsigned accum __fractuhausa2 (unsigned short
+ accum A)
+ -- Runtime Function: unsigned long accum __fractuhauda2 (unsigned
+ short accum A)
+ -- Runtime Function: unsigned long long accum __fractuhauta2 (unsigned
+ short accum A)
+ -- Runtime Function: signed char __fractuhaqi (unsigned short accum A)
+ -- Runtime Function: short __fractuhahi (unsigned short accum A)
+ -- Runtime Function: int __fractuhasi (unsigned short accum A)
+ -- Runtime Function: long __fractuhadi (unsigned short accum A)
+ -- Runtime Function: long long __fractuhati (unsigned short accum A)
+ -- Runtime Function: float __fractuhasf (unsigned short accum A)
+ -- Runtime Function: double __fractuhadf (unsigned short accum A)
+ -- Runtime Function: short fract __fractusaqq (unsigned accum A)
+ -- Runtime Function: fract __fractusahq (unsigned accum A)
+ -- Runtime Function: long fract __fractusasq (unsigned accum A)
+ -- Runtime Function: long long fract __fractusadq (unsigned accum A)
+ -- Runtime Function: short accum __fractusaha (unsigned accum A)
+ -- Runtime Function: accum __fractusasa (unsigned accum A)
+ -- Runtime Function: long accum __fractusada (unsigned accum A)
+ -- Runtime Function: long long accum __fractusata (unsigned accum A)
+ -- Runtime Function: unsigned short fract __fractusauqq (unsigned
+ accum A)
+ -- Runtime Function: unsigned fract __fractusauhq (unsigned accum A)
+ -- Runtime Function: unsigned long fract __fractusausq (unsigned accum
+ A)
+ -- Runtime Function: unsigned long long fract __fractusaudq (unsigned
+ accum A)
+ -- Runtime Function: unsigned short accum __fractusauha2 (unsigned
+ accum A)
+ -- Runtime Function: unsigned long accum __fractusauda2 (unsigned
+ accum A)
+ -- Runtime Function: unsigned long long accum __fractusauta2 (unsigned
+ accum A)
+ -- Runtime Function: signed char __fractusaqi (unsigned accum A)
+ -- Runtime Function: short __fractusahi (unsigned accum A)
+ -- Runtime Function: int __fractusasi (unsigned accum A)
+ -- Runtime Function: long __fractusadi (unsigned accum A)
+ -- Runtime Function: long long __fractusati (unsigned accum A)
+ -- Runtime Function: float __fractusasf (unsigned accum A)
+ -- Runtime Function: double __fractusadf (unsigned accum A)
+ -- Runtime Function: short fract __fractudaqq (unsigned long accum A)
+ -- Runtime Function: fract __fractudahq (unsigned long accum A)
+ -- Runtime Function: long fract __fractudasq (unsigned long accum A)
+ -- Runtime Function: long long fract __fractudadq (unsigned long accum
+ A)
+ -- Runtime Function: short accum __fractudaha (unsigned long accum A)
+ -- Runtime Function: accum __fractudasa (unsigned long accum A)
+ -- Runtime Function: long accum __fractudada (unsigned long accum A)
+ -- Runtime Function: long long accum __fractudata (unsigned long accum
+ A)
+ -- Runtime Function: unsigned short fract __fractudauqq (unsigned long
+ accum A)
+ -- Runtime Function: unsigned fract __fractudauhq (unsigned long accum
+ A)
+ -- Runtime Function: unsigned long fract __fractudausq (unsigned long
+ accum A)
+ -- Runtime Function: unsigned long long fract __fractudaudq (unsigned
+ long accum A)
+ -- Runtime Function: unsigned short accum __fractudauha2 (unsigned
+ long accum A)
+ -- Runtime Function: unsigned accum __fractudausa2 (unsigned long
+ accum A)
+ -- Runtime Function: unsigned long long accum __fractudauta2 (unsigned
+ long accum A)
+ -- Runtime Function: signed char __fractudaqi (unsigned long accum A)
+ -- Runtime Function: short __fractudahi (unsigned long accum A)
+ -- Runtime Function: int __fractudasi (unsigned long accum A)
+ -- Runtime Function: long __fractudadi (unsigned long accum A)
+ -- Runtime Function: long long __fractudati (unsigned long accum A)
+ -- Runtime Function: float __fractudasf (unsigned long accum A)
+ -- Runtime Function: double __fractudadf (unsigned long accum A)
+ -- Runtime Function: short fract __fractutaqq (unsigned long long
+ accum A)
+ -- Runtime Function: fract __fractutahq (unsigned long long accum A)
+ -- Runtime Function: long fract __fractutasq (unsigned long long accum
+ A)
+ -- Runtime Function: long long fract __fractutadq (unsigned long long
+ accum A)
+ -- Runtime Function: short accum __fractutaha (unsigned long long
+ accum A)
+ -- Runtime Function: accum __fractutasa (unsigned long long accum A)
+ -- Runtime Function: long accum __fractutada (unsigned long long accum
+ A)
+ -- Runtime Function: long long accum __fractutata (unsigned long long
+ accum A)
+ -- Runtime Function: unsigned short fract __fractutauqq (unsigned long
+ long accum A)
+ -- Runtime Function: unsigned fract __fractutauhq (unsigned long long
+ accum A)
+ -- Runtime Function: unsigned long fract __fractutausq (unsigned long
+ long accum A)
+ -- Runtime Function: unsigned long long fract __fractutaudq (unsigned
+ long long accum A)
+ -- Runtime Function: unsigned short accum __fractutauha2 (unsigned
+ long long accum A)
+ -- Runtime Function: unsigned accum __fractutausa2 (unsigned long long
+ accum A)
+ -- Runtime Function: unsigned long accum __fractutauda2 (unsigned long
+ long accum A)
+ -- Runtime Function: signed char __fractutaqi (unsigned long long
+ accum A)
+ -- Runtime Function: short __fractutahi (unsigned long long accum A)
+ -- Runtime Function: int __fractutasi (unsigned long long accum A)
+ -- Runtime Function: long __fractutadi (unsigned long long accum A)
+ -- Runtime Function: long long __fractutati (unsigned long long accum
+ A)
+ -- Runtime Function: float __fractutasf (unsigned long long accum A)
+ -- Runtime Function: double __fractutadf (unsigned long long accum A)
+ -- Runtime Function: short fract __fractqiqq (signed char A)
+ -- Runtime Function: fract __fractqihq (signed char A)
+ -- Runtime Function: long fract __fractqisq (signed char A)
+ -- Runtime Function: long long fract __fractqidq (signed char A)
+ -- Runtime Function: short accum __fractqiha (signed char A)
+ -- Runtime Function: accum __fractqisa (signed char A)
+ -- Runtime Function: long accum __fractqida (signed char A)
+ -- Runtime Function: long long accum __fractqita (signed char A)
+ -- Runtime Function: unsigned short fract __fractqiuqq (signed char A)
+ -- Runtime Function: unsigned fract __fractqiuhq (signed char A)
+ -- Runtime Function: unsigned long fract __fractqiusq (signed char A)
+ -- Runtime Function: unsigned long long fract __fractqiudq (signed
+ char A)
+ -- Runtime Function: unsigned short accum __fractqiuha (signed char A)
+ -- Runtime Function: unsigned accum __fractqiusa (signed char A)
+ -- Runtime Function: unsigned long accum __fractqiuda (signed char A)
+ -- Runtime Function: unsigned long long accum __fractqiuta (signed
+ char A)
+ -- Runtime Function: short fract __fracthiqq (short A)
+ -- Runtime Function: fract __fracthihq (short A)
+ -- Runtime Function: long fract __fracthisq (short A)
+ -- Runtime Function: long long fract __fracthidq (short A)
+ -- Runtime Function: short accum __fracthiha (short A)
+ -- Runtime Function: accum __fracthisa (short A)
+ -- Runtime Function: long accum __fracthida (short A)
+ -- Runtime Function: long long accum __fracthita (short A)
+ -- Runtime Function: unsigned short fract __fracthiuqq (short A)
+ -- Runtime Function: unsigned fract __fracthiuhq (short A)
+ -- Runtime Function: unsigned long fract __fracthiusq (short A)
+ -- Runtime Function: unsigned long long fract __fracthiudq (short A)
+ -- Runtime Function: unsigned short accum __fracthiuha (short A)
+ -- Runtime Function: unsigned accum __fracthiusa (short A)
+ -- Runtime Function: unsigned long accum __fracthiuda (short A)
+ -- Runtime Function: unsigned long long accum __fracthiuta (short A)
+ -- Runtime Function: short fract __fractsiqq (int A)
+ -- Runtime Function: fract __fractsihq (int A)
+ -- Runtime Function: long fract __fractsisq (int A)
+ -- Runtime Function: long long fract __fractsidq (int A)
+ -- Runtime Function: short accum __fractsiha (int A)
+ -- Runtime Function: accum __fractsisa (int A)
+ -- Runtime Function: long accum __fractsida (int A)
+ -- Runtime Function: long long accum __fractsita (int A)
+ -- Runtime Function: unsigned short fract __fractsiuqq (int A)
+ -- Runtime Function: unsigned fract __fractsiuhq (int A)
+ -- Runtime Function: unsigned long fract __fractsiusq (int A)
+ -- Runtime Function: unsigned long long fract __fractsiudq (int A)
+ -- Runtime Function: unsigned short accum __fractsiuha (int A)
+ -- Runtime Function: unsigned accum __fractsiusa (int A)
+ -- Runtime Function: unsigned long accum __fractsiuda (int A)
+ -- Runtime Function: unsigned long long accum __fractsiuta (int A)
+ -- Runtime Function: short fract __fractdiqq (long A)
+ -- Runtime Function: fract __fractdihq (long A)
+ -- Runtime Function: long fract __fractdisq (long A)
+ -- Runtime Function: long long fract __fractdidq (long A)
+ -- Runtime Function: short accum __fractdiha (long A)
+ -- Runtime Function: accum __fractdisa (long A)
+ -- Runtime Function: long accum __fractdida (long A)
+ -- Runtime Function: long long accum __fractdita (long A)
+ -- Runtime Function: unsigned short fract __fractdiuqq (long A)
+ -- Runtime Function: unsigned fract __fractdiuhq (long A)
+ -- Runtime Function: unsigned long fract __fractdiusq (long A)
+ -- Runtime Function: unsigned long long fract __fractdiudq (long A)
+ -- Runtime Function: unsigned short accum __fractdiuha (long A)
+ -- Runtime Function: unsigned accum __fractdiusa (long A)
+ -- Runtime Function: unsigned long accum __fractdiuda (long A)
+ -- Runtime Function: unsigned long long accum __fractdiuta (long A)
+ -- Runtime Function: short fract __fracttiqq (long long A)
+ -- Runtime Function: fract __fracttihq (long long A)
+ -- Runtime Function: long fract __fracttisq (long long A)
+ -- Runtime Function: long long fract __fracttidq (long long A)
+ -- Runtime Function: short accum __fracttiha (long long A)
+ -- Runtime Function: accum __fracttisa (long long A)
+ -- Runtime Function: long accum __fracttida (long long A)
+ -- Runtime Function: long long accum __fracttita (long long A)
+ -- Runtime Function: unsigned short fract __fracttiuqq (long long A)
+ -- Runtime Function: unsigned fract __fracttiuhq (long long A)
+ -- Runtime Function: unsigned long fract __fracttiusq (long long A)
+ -- Runtime Function: unsigned long long fract __fracttiudq (long long
+ A)
+ -- Runtime Function: unsigned short accum __fracttiuha (long long A)
+ -- Runtime Function: unsigned accum __fracttiusa (long long A)
+ -- Runtime Function: unsigned long accum __fracttiuda (long long A)
+ -- Runtime Function: unsigned long long accum __fracttiuta (long long
+ A)
+ -- Runtime Function: short fract __fractsfqq (float A)
+ -- Runtime Function: fract __fractsfhq (float A)
+ -- Runtime Function: long fract __fractsfsq (float A)
+ -- Runtime Function: long long fract __fractsfdq (float A)
+ -- Runtime Function: short accum __fractsfha (float A)
+ -- Runtime Function: accum __fractsfsa (float A)
+ -- Runtime Function: long accum __fractsfda (float A)
+ -- Runtime Function: long long accum __fractsfta (float A)
+ -- Runtime Function: unsigned short fract __fractsfuqq (float A)
+ -- Runtime Function: unsigned fract __fractsfuhq (float A)
+ -- Runtime Function: unsigned long fract __fractsfusq (float A)
+ -- Runtime Function: unsigned long long fract __fractsfudq (float A)
+ -- Runtime Function: unsigned short accum __fractsfuha (float A)
+ -- Runtime Function: unsigned accum __fractsfusa (float A)
+ -- Runtime Function: unsigned long accum __fractsfuda (float A)
+ -- Runtime Function: unsigned long long accum __fractsfuta (float A)
+ -- Runtime Function: short fract __fractdfqq (double A)
+ -- Runtime Function: fract __fractdfhq (double A)
+ -- Runtime Function: long fract __fractdfsq (double A)
+ -- Runtime Function: long long fract __fractdfdq (double A)
+ -- Runtime Function: short accum __fractdfha (double A)
+ -- Runtime Function: accum __fractdfsa (double A)
+ -- Runtime Function: long accum __fractdfda (double A)
+ -- Runtime Function: long long accum __fractdfta (double A)
+ -- Runtime Function: unsigned short fract __fractdfuqq (double A)
+ -- Runtime Function: unsigned fract __fractdfuhq (double A)
+ -- Runtime Function: unsigned long fract __fractdfusq (double A)
+ -- Runtime Function: unsigned long long fract __fractdfudq (double A)
+ -- Runtime Function: unsigned short accum __fractdfuha (double A)
+ -- Runtime Function: unsigned accum __fractdfusa (double A)
+ -- Runtime Function: unsigned long accum __fractdfuda (double A)
+ -- Runtime Function: unsigned long long accum __fractdfuta (double A)
+ These functions convert from fractional and signed non-fractionals
+ to fractionals and signed non-fractionals, without saturation.
+
+ -- Runtime Function: fract __satfractqqhq2 (short fract A)
+ -- Runtime Function: long fract __satfractqqsq2 (short fract A)
+ -- Runtime Function: long long fract __satfractqqdq2 (short fract A)
+ -- Runtime Function: short accum __satfractqqha (short fract A)
+ -- Runtime Function: accum __satfractqqsa (short fract A)
+ -- Runtime Function: long accum __satfractqqda (short fract A)
+ -- Runtime Function: long long accum __satfractqqta (short fract A)
+ -- Runtime Function: unsigned short fract __satfractqquqq (short fract
+ A)
+ -- Runtime Function: unsigned fract __satfractqquhq (short fract A)
+ -- Runtime Function: unsigned long fract __satfractqqusq (short fract
+ A)
+ -- Runtime Function: unsigned long long fract __satfractqqudq (short
+ fract A)
+ -- Runtime Function: unsigned short accum __satfractqquha (short fract
+ A)
+ -- Runtime Function: unsigned accum __satfractqqusa (short fract A)
+ -- Runtime Function: unsigned long accum __satfractqquda (short fract
+ A)
+ -- Runtime Function: unsigned long long accum __satfractqquta (short
+ fract A)
+ -- Runtime Function: short fract __satfracthqqq2 (fract A)
+ -- Runtime Function: long fract __satfracthqsq2 (fract A)
+ -- Runtime Function: long long fract __satfracthqdq2 (fract A)
+ -- Runtime Function: short accum __satfracthqha (fract A)
+ -- Runtime Function: accum __satfracthqsa (fract A)
+ -- Runtime Function: long accum __satfracthqda (fract A)
+ -- Runtime Function: long long accum __satfracthqta (fract A)
+ -- Runtime Function: unsigned short fract __satfracthquqq (fract A)
+ -- Runtime Function: unsigned fract __satfracthquhq (fract A)
+ -- Runtime Function: unsigned long fract __satfracthqusq (fract A)
+ -- Runtime Function: unsigned long long fract __satfracthqudq (fract A)
+ -- Runtime Function: unsigned short accum __satfracthquha (fract A)
+ -- Runtime Function: unsigned accum __satfracthqusa (fract A)
+ -- Runtime Function: unsigned long accum __satfracthquda (fract A)
+ -- Runtime Function: unsigned long long accum __satfracthquta (fract A)
+ -- Runtime Function: short fract __satfractsqqq2 (long fract A)
+ -- Runtime Function: fract __satfractsqhq2 (long fract A)
+ -- Runtime Function: long long fract __satfractsqdq2 (long fract A)
+ -- Runtime Function: short accum __satfractsqha (long fract A)
+ -- Runtime Function: accum __satfractsqsa (long fract A)
+ -- Runtime Function: long accum __satfractsqda (long fract A)
+ -- Runtime Function: long long accum __satfractsqta (long fract A)
+ -- Runtime Function: unsigned short fract __satfractsquqq (long fract
+ A)
+ -- Runtime Function: unsigned fract __satfractsquhq (long fract A)
+ -- Runtime Function: unsigned long fract __satfractsqusq (long fract A)
+ -- Runtime Function: unsigned long long fract __satfractsqudq (long
+ fract A)
+ -- Runtime Function: unsigned short accum __satfractsquha (long fract
+ A)
+ -- Runtime Function: unsigned accum __satfractsqusa (long fract A)
+ -- Runtime Function: unsigned long accum __satfractsquda (long fract A)
+ -- Runtime Function: unsigned long long accum __satfractsquta (long
+ fract A)
+ -- Runtime Function: short fract __satfractdqqq2 (long long fract A)
+ -- Runtime Function: fract __satfractdqhq2 (long long fract A)
+ -- Runtime Function: long fract __satfractdqsq2 (long long fract A)
+ -- Runtime Function: short accum __satfractdqha (long long fract A)
+ -- Runtime Function: accum __satfractdqsa (long long fract A)
+ -- Runtime Function: long accum __satfractdqda (long long fract A)
+ -- Runtime Function: long long accum __satfractdqta (long long fract A)
+ -- Runtime Function: unsigned short fract __satfractdquqq (long long
+ fract A)
+ -- Runtime Function: unsigned fract __satfractdquhq (long long fract A)
+ -- Runtime Function: unsigned long fract __satfractdqusq (long long
+ fract A)
+ -- Runtime Function: unsigned long long fract __satfractdqudq (long
+ long fract A)
+ -- Runtime Function: unsigned short accum __satfractdquha (long long
+ fract A)
+ -- Runtime Function: unsigned accum __satfractdqusa (long long fract A)
+ -- Runtime Function: unsigned long accum __satfractdquda (long long
+ fract A)
+ -- Runtime Function: unsigned long long accum __satfractdquta (long
+ long fract A)
+ -- Runtime Function: short fract __satfracthaqq (short accum A)
+ -- Runtime Function: fract __satfracthahq (short accum A)
+ -- Runtime Function: long fract __satfracthasq (short accum A)
+ -- Runtime Function: long long fract __satfracthadq (short accum A)
+ -- Runtime Function: accum __satfracthasa2 (short accum A)
+ -- Runtime Function: long accum __satfracthada2 (short accum A)
+ -- Runtime Function: long long accum __satfracthata2 (short accum A)
+ -- Runtime Function: unsigned short fract __satfracthauqq (short accum
+ A)
+ -- Runtime Function: unsigned fract __satfracthauhq (short accum A)
+ -- Runtime Function: unsigned long fract __satfracthausq (short accum
+ A)
+ -- Runtime Function: unsigned long long fract __satfracthaudq (short
+ accum A)
+ -- Runtime Function: unsigned short accum __satfracthauha (short accum
+ A)
+ -- Runtime Function: unsigned accum __satfracthausa (short accum A)
+ -- Runtime Function: unsigned long accum __satfracthauda (short accum
+ A)
+ -- Runtime Function: unsigned long long accum __satfracthauta (short
+ accum A)
+ -- Runtime Function: short fract __satfractsaqq (accum A)
+ -- Runtime Function: fract __satfractsahq (accum A)
+ -- Runtime Function: long fract __satfractsasq (accum A)
+ -- Runtime Function: long long fract __satfractsadq (accum A)
+ -- Runtime Function: short accum __satfractsaha2 (accum A)
+ -- Runtime Function: long accum __satfractsada2 (accum A)
+ -- Runtime Function: long long accum __satfractsata2 (accum A)
+ -- Runtime Function: unsigned short fract __satfractsauqq (accum A)
+ -- Runtime Function: unsigned fract __satfractsauhq (accum A)
+ -- Runtime Function: unsigned long fract __satfractsausq (accum A)
+ -- Runtime Function: unsigned long long fract __satfractsaudq (accum A)
+ -- Runtime Function: unsigned short accum __satfractsauha (accum A)
+ -- Runtime Function: unsigned accum __satfractsausa (accum A)
+ -- Runtime Function: unsigned long accum __satfractsauda (accum A)
+ -- Runtime Function: unsigned long long accum __satfractsauta (accum A)
+ -- Runtime Function: short fract __satfractdaqq (long accum A)
+ -- Runtime Function: fract __satfractdahq (long accum A)
+ -- Runtime Function: long fract __satfractdasq (long accum A)
+ -- Runtime Function: long long fract __satfractdadq (long accum A)
+ -- Runtime Function: short accum __satfractdaha2 (long accum A)
+ -- Runtime Function: accum __satfractdasa2 (long accum A)
+ -- Runtime Function: long long accum __satfractdata2 (long accum A)
+ -- Runtime Function: unsigned short fract __satfractdauqq (long accum
+ A)
+ -- Runtime Function: unsigned fract __satfractdauhq (long accum A)
+ -- Runtime Function: unsigned long fract __satfractdausq (long accum A)
+ -- Runtime Function: unsigned long long fract __satfractdaudq (long
+ accum A)
+ -- Runtime Function: unsigned short accum __satfractdauha (long accum
+ A)
+ -- Runtime Function: unsigned accum __satfractdausa (long accum A)
+ -- Runtime Function: unsigned long accum __satfractdauda (long accum A)
+ -- Runtime Function: unsigned long long accum __satfractdauta (long
+ accum A)
+ -- Runtime Function: short fract __satfracttaqq (long long accum A)
+ -- Runtime Function: fract __satfracttahq (long long accum A)
+ -- Runtime Function: long fract __satfracttasq (long long accum A)
+ -- Runtime Function: long long fract __satfracttadq (long long accum A)
+ -- Runtime Function: short accum __satfracttaha2 (long long accum A)
+ -- Runtime Function: accum __satfracttasa2 (long long accum A)
+ -- Runtime Function: long accum __satfracttada2 (long long accum A)
+ -- Runtime Function: unsigned short fract __satfracttauqq (long long
+ accum A)
+ -- Runtime Function: unsigned fract __satfracttauhq (long long accum A)
+ -- Runtime Function: unsigned long fract __satfracttausq (long long
+ accum A)
+ -- Runtime Function: unsigned long long fract __satfracttaudq (long
+ long accum A)
+ -- Runtime Function: unsigned short accum __satfracttauha (long long
+ accum A)
+ -- Runtime Function: unsigned accum __satfracttausa (long long accum A)
+ -- Runtime Function: unsigned long accum __satfracttauda (long long
+ accum A)
+ -- Runtime Function: unsigned long long accum __satfracttauta (long
+ long accum A)
+ -- Runtime Function: short fract __satfractuqqqq (unsigned short fract
+ A)
+ -- Runtime Function: fract __satfractuqqhq (unsigned short fract A)
+ -- Runtime Function: long fract __satfractuqqsq (unsigned short fract
+ A)
+ -- Runtime Function: long long fract __satfractuqqdq (unsigned short
+ fract A)
+ -- Runtime Function: short accum __satfractuqqha (unsigned short fract
+ A)
+ -- Runtime Function: accum __satfractuqqsa (unsigned short fract A)
+ -- Runtime Function: long accum __satfractuqqda (unsigned short fract
+ A)
+ -- Runtime Function: long long accum __satfractuqqta (unsigned short
+ fract A)
+ -- Runtime Function: unsigned fract __satfractuqquhq2 (unsigned short
+ fract A)
+ -- Runtime Function: unsigned long fract __satfractuqqusq2 (unsigned
+ short fract A)
+ -- Runtime Function: unsigned long long fract __satfractuqqudq2
+ (unsigned short fract A)
+ -- Runtime Function: unsigned short accum __satfractuqquha (unsigned
+ short fract A)
+ -- Runtime Function: unsigned accum __satfractuqqusa (unsigned short
+ fract A)
+ -- Runtime Function: unsigned long accum __satfractuqquda (unsigned
+ short fract A)
+ -- Runtime Function: unsigned long long accum __satfractuqquta
+ (unsigned short fract A)
+ -- Runtime Function: short fract __satfractuhqqq (unsigned fract A)
+ -- Runtime Function: fract __satfractuhqhq (unsigned fract A)
+ -- Runtime Function: long fract __satfractuhqsq (unsigned fract A)
+ -- Runtime Function: long long fract __satfractuhqdq (unsigned fract A)
+ -- Runtime Function: short accum __satfractuhqha (unsigned fract A)
+ -- Runtime Function: accum __satfractuhqsa (unsigned fract A)
+ -- Runtime Function: long accum __satfractuhqda (unsigned fract A)
+ -- Runtime Function: long long accum __satfractuhqta (unsigned fract A)
+ -- Runtime Function: unsigned short fract __satfractuhquqq2 (unsigned
+ fract A)
+ -- Runtime Function: unsigned long fract __satfractuhqusq2 (unsigned
+ fract A)
+ -- Runtime Function: unsigned long long fract __satfractuhqudq2
+ (unsigned fract A)
+ -- Runtime Function: unsigned short accum __satfractuhquha (unsigned
+ fract A)
+ -- Runtime Function: unsigned accum __satfractuhqusa (unsigned fract A)
+ -- Runtime Function: unsigned long accum __satfractuhquda (unsigned
+ fract A)
+ -- Runtime Function: unsigned long long accum __satfractuhquta
+ (unsigned fract A)
+ -- Runtime Function: short fract __satfractusqqq (unsigned long fract
+ A)
+ -- Runtime Function: fract __satfractusqhq (unsigned long fract A)
+ -- Runtime Function: long fract __satfractusqsq (unsigned long fract A)
+ -- Runtime Function: long long fract __satfractusqdq (unsigned long
+ fract A)
+ -- Runtime Function: short accum __satfractusqha (unsigned long fract
+ A)
+ -- Runtime Function: accum __satfractusqsa (unsigned long fract A)
+ -- Runtime Function: long accum __satfractusqda (unsigned long fract A)
+ -- Runtime Function: long long accum __satfractusqta (unsigned long
+ fract A)
+ -- Runtime Function: unsigned short fract __satfractusquqq2 (unsigned
+ long fract A)
+ -- Runtime Function: unsigned fract __satfractusquhq2 (unsigned long
+ fract A)
+ -- Runtime Function: unsigned long long fract __satfractusqudq2
+ (unsigned long fract A)
+ -- Runtime Function: unsigned short accum __satfractusquha (unsigned
+ long fract A)
+ -- Runtime Function: unsigned accum __satfractusqusa (unsigned long
+ fract A)
+ -- Runtime Function: unsigned long accum __satfractusquda (unsigned
+ long fract A)
+ -- Runtime Function: unsigned long long accum __satfractusquta
+ (unsigned long fract A)
+ -- Runtime Function: short fract __satfractudqqq (unsigned long long
+ fract A)
+ -- Runtime Function: fract __satfractudqhq (unsigned long long fract A)
+ -- Runtime Function: long fract __satfractudqsq (unsigned long long
+ fract A)
+ -- Runtime Function: long long fract __satfractudqdq (unsigned long
+ long fract A)
+ -- Runtime Function: short accum __satfractudqha (unsigned long long
+ fract A)
+ -- Runtime Function: accum __satfractudqsa (unsigned long long fract A)
+ -- Runtime Function: long accum __satfractudqda (unsigned long long
+ fract A)
+ -- Runtime Function: long long accum __satfractudqta (unsigned long
+ long fract A)
+ -- Runtime Function: unsigned short fract __satfractudquqq2 (unsigned
+ long long fract A)
+ -- Runtime Function: unsigned fract __satfractudquhq2 (unsigned long
+ long fract A)
+ -- Runtime Function: unsigned long fract __satfractudqusq2 (unsigned
+ long long fract A)
+ -- Runtime Function: unsigned short accum __satfractudquha (unsigned
+ long long fract A)
+ -- Runtime Function: unsigned accum __satfractudqusa (unsigned long
+ long fract A)
+ -- Runtime Function: unsigned long accum __satfractudquda (unsigned
+ long long fract A)
+ -- Runtime Function: unsigned long long accum __satfractudquta
+ (unsigned long long fract A)
+ -- Runtime Function: short fract __satfractuhaqq (unsigned short accum
+ A)
+ -- Runtime Function: fract __satfractuhahq (unsigned short accum A)
+ -- Runtime Function: long fract __satfractuhasq (unsigned short accum
+ A)
+ -- Runtime Function: long long fract __satfractuhadq (unsigned short
+ accum A)
+ -- Runtime Function: short accum __satfractuhaha (unsigned short accum
+ A)
+ -- Runtime Function: accum __satfractuhasa (unsigned short accum A)
+ -- Runtime Function: long accum __satfractuhada (unsigned short accum
+ A)
+ -- Runtime Function: long long accum __satfractuhata (unsigned short
+ accum A)
+ -- Runtime Function: unsigned short fract __satfractuhauqq (unsigned
+ short accum A)
+ -- Runtime Function: unsigned fract __satfractuhauhq (unsigned short
+ accum A)
+ -- Runtime Function: unsigned long fract __satfractuhausq (unsigned
+ short accum A)
+ -- Runtime Function: unsigned long long fract __satfractuhaudq
+ (unsigned short accum A)
+ -- Runtime Function: unsigned accum __satfractuhausa2 (unsigned short
+ accum A)
+ -- Runtime Function: unsigned long accum __satfractuhauda2 (unsigned
+ short accum A)
+ -- Runtime Function: unsigned long long accum __satfractuhauta2
+ (unsigned short accum A)
+ -- Runtime Function: short fract __satfractusaqq (unsigned accum A)
+ -- Runtime Function: fract __satfractusahq (unsigned accum A)
+ -- Runtime Function: long fract __satfractusasq (unsigned accum A)
+ -- Runtime Function: long long fract __satfractusadq (unsigned accum A)
+ -- Runtime Function: short accum __satfractusaha (unsigned accum A)
+ -- Runtime Function: accum __satfractusasa (unsigned accum A)
+ -- Runtime Function: long accum __satfractusada (unsigned accum A)
+ -- Runtime Function: long long accum __satfractusata (unsigned accum A)
+ -- Runtime Function: unsigned short fract __satfractusauqq (unsigned
+ accum A)
+ -- Runtime Function: unsigned fract __satfractusauhq (unsigned accum A)
+ -- Runtime Function: unsigned long fract __satfractusausq (unsigned
+ accum A)
+ -- Runtime Function: unsigned long long fract __satfractusaudq
+ (unsigned accum A)
+ -- Runtime Function: unsigned short accum __satfractusauha2 (unsigned
+ accum A)
+ -- Runtime Function: unsigned long accum __satfractusauda2 (unsigned
+ accum A)
+ -- Runtime Function: unsigned long long accum __satfractusauta2
+ (unsigned accum A)
+ -- Runtime Function: short fract __satfractudaqq (unsigned long accum
+ A)
+ -- Runtime Function: fract __satfractudahq (unsigned long accum A)
+ -- Runtime Function: long fract __satfractudasq (unsigned long accum A)
+ -- Runtime Function: long long fract __satfractudadq (unsigned long
+ accum A)
+ -- Runtime Function: short accum __satfractudaha (unsigned long accum
+ A)
+ -- Runtime Function: accum __satfractudasa (unsigned long accum A)
+ -- Runtime Function: long accum __satfractudada (unsigned long accum A)
+ -- Runtime Function: long long accum __satfractudata (unsigned long
+ accum A)
+ -- Runtime Function: unsigned short fract __satfractudauqq (unsigned
+ long accum A)
+ -- Runtime Function: unsigned fract __satfractudauhq (unsigned long
+ accum A)
+ -- Runtime Function: unsigned long fract __satfractudausq (unsigned
+ long accum A)
+ -- Runtime Function: unsigned long long fract __satfractudaudq
+ (unsigned long accum A)
+ -- Runtime Function: unsigned short accum __satfractudauha2 (unsigned
+ long accum A)
+ -- Runtime Function: unsigned accum __satfractudausa2 (unsigned long
+ accum A)
+ -- Runtime Function: unsigned long long accum __satfractudauta2
+ (unsigned long accum A)
+ -- Runtime Function: short fract __satfractutaqq (unsigned long long
+ accum A)
+ -- Runtime Function: fract __satfractutahq (unsigned long long accum A)
+ -- Runtime Function: long fract __satfractutasq (unsigned long long
+ accum A)
+ -- Runtime Function: long long fract __satfractutadq (unsigned long
+ long accum A)
+ -- Runtime Function: short accum __satfractutaha (unsigned long long
+ accum A)
+ -- Runtime Function: accum __satfractutasa (unsigned long long accum A)
+ -- Runtime Function: long accum __satfractutada (unsigned long long
+ accum A)
+ -- Runtime Function: long long accum __satfractutata (unsigned long
+ long accum A)
+ -- Runtime Function: unsigned short fract __satfractutauqq (unsigned
+ long long accum A)
+ -- Runtime Function: unsigned fract __satfractutauhq (unsigned long
+ long accum A)
+ -- Runtime Function: unsigned long fract __satfractutausq (unsigned
+ long long accum A)
+ -- Runtime Function: unsigned long long fract __satfractutaudq
+ (unsigned long long accum A)
+ -- Runtime Function: unsigned short accum __satfractutauha2 (unsigned
+ long long accum A)
+ -- Runtime Function: unsigned accum __satfractutausa2 (unsigned long
+ long accum A)
+ -- Runtime Function: unsigned long accum __satfractutauda2 (unsigned
+ long long accum A)
+ -- Runtime Function: short fract __satfractqiqq (signed char A)
+ -- Runtime Function: fract __satfractqihq (signed char A)
+ -- Runtime Function: long fract __satfractqisq (signed char A)
+ -- Runtime Function: long long fract __satfractqidq (signed char A)
+ -- Runtime Function: short accum __satfractqiha (signed char A)
+ -- Runtime Function: accum __satfractqisa (signed char A)
+ -- Runtime Function: long accum __satfractqida (signed char A)
+ -- Runtime Function: long long accum __satfractqita (signed char A)
+ -- Runtime Function: unsigned short fract __satfractqiuqq (signed char
+ A)
+ -- Runtime Function: unsigned fract __satfractqiuhq (signed char A)
+ -- Runtime Function: unsigned long fract __satfractqiusq (signed char
+ A)
+ -- Runtime Function: unsigned long long fract __satfractqiudq (signed
+ char A)
+ -- Runtime Function: unsigned short accum __satfractqiuha (signed char
+ A)
+ -- Runtime Function: unsigned accum __satfractqiusa (signed char A)
+ -- Runtime Function: unsigned long accum __satfractqiuda (signed char
+ A)
+ -- Runtime Function: unsigned long long accum __satfractqiuta (signed
+ char A)
+ -- Runtime Function: short fract __satfracthiqq (short A)
+ -- Runtime Function: fract __satfracthihq (short A)
+ -- Runtime Function: long fract __satfracthisq (short A)
+ -- Runtime Function: long long fract __satfracthidq (short A)
+ -- Runtime Function: short accum __satfracthiha (short A)
+ -- Runtime Function: accum __satfracthisa (short A)
+ -- Runtime Function: long accum __satfracthida (short A)
+ -- Runtime Function: long long accum __satfracthita (short A)
+ -- Runtime Function: unsigned short fract __satfracthiuqq (short A)
+ -- Runtime Function: unsigned fract __satfracthiuhq (short A)
+ -- Runtime Function: unsigned long fract __satfracthiusq (short A)
+ -- Runtime Function: unsigned long long fract __satfracthiudq (short A)
+ -- Runtime Function: unsigned short accum __satfracthiuha (short A)
+ -- Runtime Function: unsigned accum __satfracthiusa (short A)
+ -- Runtime Function: unsigned long accum __satfracthiuda (short A)
+ -- Runtime Function: unsigned long long accum __satfracthiuta (short A)
+ -- Runtime Function: short fract __satfractsiqq (int A)
+ -- Runtime Function: fract __satfractsihq (int A)
+ -- Runtime Function: long fract __satfractsisq (int A)
+ -- Runtime Function: long long fract __satfractsidq (int A)
+ -- Runtime Function: short accum __satfractsiha (int A)
+ -- Runtime Function: accum __satfractsisa (int A)
+ -- Runtime Function: long accum __satfractsida (int A)
+ -- Runtime Function: long long accum __satfractsita (int A)
+ -- Runtime Function: unsigned short fract __satfractsiuqq (int A)
+ -- Runtime Function: unsigned fract __satfractsiuhq (int A)
+ -- Runtime Function: unsigned long fract __satfractsiusq (int A)
+ -- Runtime Function: unsigned long long fract __satfractsiudq (int A)
+ -- Runtime Function: unsigned short accum __satfractsiuha (int A)
+ -- Runtime Function: unsigned accum __satfractsiusa (int A)
+ -- Runtime Function: unsigned long accum __satfractsiuda (int A)
+ -- Runtime Function: unsigned long long accum __satfractsiuta (int A)
+ -- Runtime Function: short fract __satfractdiqq (long A)
+ -- Runtime Function: fract __satfractdihq (long A)
+ -- Runtime Function: long fract __satfractdisq (long A)
+ -- Runtime Function: long long fract __satfractdidq (long A)
+ -- Runtime Function: short accum __satfractdiha (long A)
+ -- Runtime Function: accum __satfractdisa (long A)
+ -- Runtime Function: long accum __satfractdida (long A)
+ -- Runtime Function: long long accum __satfractdita (long A)
+ -- Runtime Function: unsigned short fract __satfractdiuqq (long A)
+ -- Runtime Function: unsigned fract __satfractdiuhq (long A)
+ -- Runtime Function: unsigned long fract __satfractdiusq (long A)
+ -- Runtime Function: unsigned long long fract __satfractdiudq (long A)
+ -- Runtime Function: unsigned short accum __satfractdiuha (long A)
+ -- Runtime Function: unsigned accum __satfractdiusa (long A)
+ -- Runtime Function: unsigned long accum __satfractdiuda (long A)
+ -- Runtime Function: unsigned long long accum __satfractdiuta (long A)
+ -- Runtime Function: short fract __satfracttiqq (long long A)
+ -- Runtime Function: fract __satfracttihq (long long A)
+ -- Runtime Function: long fract __satfracttisq (long long A)
+ -- Runtime Function: long long fract __satfracttidq (long long A)
+ -- Runtime Function: short accum __satfracttiha (long long A)
+ -- Runtime Function: accum __satfracttisa (long long A)
+ -- Runtime Function: long accum __satfracttida (long long A)
+ -- Runtime Function: long long accum __satfracttita (long long A)
+ -- Runtime Function: unsigned short fract __satfracttiuqq (long long A)
+ -- Runtime Function: unsigned fract __satfracttiuhq (long long A)
+ -- Runtime Function: unsigned long fract __satfracttiusq (long long A)
+ -- Runtime Function: unsigned long long fract __satfracttiudq (long
+ long A)
+ -- Runtime Function: unsigned short accum __satfracttiuha (long long A)
+ -- Runtime Function: unsigned accum __satfracttiusa (long long A)
+ -- Runtime Function: unsigned long accum __satfracttiuda (long long A)
+ -- Runtime Function: unsigned long long accum __satfracttiuta (long
+ long A)
+ -- Runtime Function: short fract __satfractsfqq (float A)
+ -- Runtime Function: fract __satfractsfhq (float A)
+ -- Runtime Function: long fract __satfractsfsq (float A)
+ -- Runtime Function: long long fract __satfractsfdq (float A)
+ -- Runtime Function: short accum __satfractsfha (float A)
+ -- Runtime Function: accum __satfractsfsa (float A)
+ -- Runtime Function: long accum __satfractsfda (float A)
+ -- Runtime Function: long long accum __satfractsfta (float A)
+ -- Runtime Function: unsigned short fract __satfractsfuqq (float A)
+ -- Runtime Function: unsigned fract __satfractsfuhq (float A)
+ -- Runtime Function: unsigned long fract __satfractsfusq (float A)
+ -- Runtime Function: unsigned long long fract __satfractsfudq (float A)
+ -- Runtime Function: unsigned short accum __satfractsfuha (float A)
+ -- Runtime Function: unsigned accum __satfractsfusa (float A)
+ -- Runtime Function: unsigned long accum __satfractsfuda (float A)
+ -- Runtime Function: unsigned long long accum __satfractsfuta (float A)
+ -- Runtime Function: short fract __satfractdfqq (double A)
+ -- Runtime Function: fract __satfractdfhq (double A)
+ -- Runtime Function: long fract __satfractdfsq (double A)
+ -- Runtime Function: long long fract __satfractdfdq (double A)
+ -- Runtime Function: short accum __satfractdfha (double A)
+ -- Runtime Function: accum __satfractdfsa (double A)
+ -- Runtime Function: long accum __satfractdfda (double A)
+ -- Runtime Function: long long accum __satfractdfta (double A)
+ -- Runtime Function: unsigned short fract __satfractdfuqq (double A)
+ -- Runtime Function: unsigned fract __satfractdfuhq (double A)
+ -- Runtime Function: unsigned long fract __satfractdfusq (double A)
+ -- Runtime Function: unsigned long long fract __satfractdfudq (double
+ A)
+ -- Runtime Function: unsigned short accum __satfractdfuha (double A)
+ -- Runtime Function: unsigned accum __satfractdfusa (double A)
+ -- Runtime Function: unsigned long accum __satfractdfuda (double A)
+ -- Runtime Function: unsigned long long accum __satfractdfuta (double
+ A)
+ The functions convert from fractional and signed non-fractionals to
+ fractionals, with saturation.
+
+ -- Runtime Function: unsigned char __fractunsqqqi (short fract A)
+ -- Runtime Function: unsigned short __fractunsqqhi (short fract A)
+ -- Runtime Function: unsigned int __fractunsqqsi (short fract A)
+ -- Runtime Function: unsigned long __fractunsqqdi (short fract A)
+ -- Runtime Function: unsigned long long __fractunsqqti (short fract A)
+ -- Runtime Function: unsigned char __fractunshqqi (fract A)
+ -- Runtime Function: unsigned short __fractunshqhi (fract A)
+ -- Runtime Function: unsigned int __fractunshqsi (fract A)
+ -- Runtime Function: unsigned long __fractunshqdi (fract A)
+ -- Runtime Function: unsigned long long __fractunshqti (fract A)
+ -- Runtime Function: unsigned char __fractunssqqi (long fract A)
+ -- Runtime Function: unsigned short __fractunssqhi (long fract A)
+ -- Runtime Function: unsigned int __fractunssqsi (long fract A)
+ -- Runtime Function: unsigned long __fractunssqdi (long fract A)
+ -- Runtime Function: unsigned long long __fractunssqti (long fract A)
+ -- Runtime Function: unsigned char __fractunsdqqi (long long fract A)
+ -- Runtime Function: unsigned short __fractunsdqhi (long long fract A)
+ -- Runtime Function: unsigned int __fractunsdqsi (long long fract A)
+ -- Runtime Function: unsigned long __fractunsdqdi (long long fract A)
+ -- Runtime Function: unsigned long long __fractunsdqti (long long
+ fract A)
+ -- Runtime Function: unsigned char __fractunshaqi (short accum A)
+ -- Runtime Function: unsigned short __fractunshahi (short accum A)
+ -- Runtime Function: unsigned int __fractunshasi (short accum A)
+ -- Runtime Function: unsigned long __fractunshadi (short accum A)
+ -- Runtime Function: unsigned long long __fractunshati (short accum A)
+ -- Runtime Function: unsigned char __fractunssaqi (accum A)
+ -- Runtime Function: unsigned short __fractunssahi (accum A)
+ -- Runtime Function: unsigned int __fractunssasi (accum A)
+ -- Runtime Function: unsigned long __fractunssadi (accum A)
+ -- Runtime Function: unsigned long long __fractunssati (accum A)
+ -- Runtime Function: unsigned char __fractunsdaqi (long accum A)
+ -- Runtime Function: unsigned short __fractunsdahi (long accum A)
+ -- Runtime Function: unsigned int __fractunsdasi (long accum A)
+ -- Runtime Function: unsigned long __fractunsdadi (long accum A)
+ -- Runtime Function: unsigned long long __fractunsdati (long accum A)
+ -- Runtime Function: unsigned char __fractunstaqi (long long accum A)
+ -- Runtime Function: unsigned short __fractunstahi (long long accum A)
+ -- Runtime Function: unsigned int __fractunstasi (long long accum A)
+ -- Runtime Function: unsigned long __fractunstadi (long long accum A)
+ -- Runtime Function: unsigned long long __fractunstati (long long
+ accum A)
+ -- Runtime Function: unsigned char __fractunsuqqqi (unsigned short
+ fract A)
+ -- Runtime Function: unsigned short __fractunsuqqhi (unsigned short
+ fract A)
+ -- Runtime Function: unsigned int __fractunsuqqsi (unsigned short
+ fract A)
+ -- Runtime Function: unsigned long __fractunsuqqdi (unsigned short
+ fract A)
+ -- Runtime Function: unsigned long long __fractunsuqqti (unsigned
+ short fract A)
+ -- Runtime Function: unsigned char __fractunsuhqqi (unsigned fract A)
+ -- Runtime Function: unsigned short __fractunsuhqhi (unsigned fract A)
+ -- Runtime Function: unsigned int __fractunsuhqsi (unsigned fract A)
+ -- Runtime Function: unsigned long __fractunsuhqdi (unsigned fract A)
+ -- Runtime Function: unsigned long long __fractunsuhqti (unsigned
+ fract A)
+ -- Runtime Function: unsigned char __fractunsusqqi (unsigned long
+ fract A)
+ -- Runtime Function: unsigned short __fractunsusqhi (unsigned long
+ fract A)
+ -- Runtime Function: unsigned int __fractunsusqsi (unsigned long fract
+ A)
+ -- Runtime Function: unsigned long __fractunsusqdi (unsigned long
+ fract A)
+ -- Runtime Function: unsigned long long __fractunsusqti (unsigned long
+ fract A)
+ -- Runtime Function: unsigned char __fractunsudqqi (unsigned long long
+ fract A)
+ -- Runtime Function: unsigned short __fractunsudqhi (unsigned long
+ long fract A)
+ -- Runtime Function: unsigned int __fractunsudqsi (unsigned long long
+ fract A)
+ -- Runtime Function: unsigned long __fractunsudqdi (unsigned long long
+ fract A)
+ -- Runtime Function: unsigned long long __fractunsudqti (unsigned long
+ long fract A)
+ -- Runtime Function: unsigned char __fractunsuhaqi (unsigned short
+ accum A)
+ -- Runtime Function: unsigned short __fractunsuhahi (unsigned short
+ accum A)
+ -- Runtime Function: unsigned int __fractunsuhasi (unsigned short
+ accum A)
+ -- Runtime Function: unsigned long __fractunsuhadi (unsigned short
+ accum A)
+ -- Runtime Function: unsigned long long __fractunsuhati (unsigned
+ short accum A)
+ -- Runtime Function: unsigned char __fractunsusaqi (unsigned accum A)
+ -- Runtime Function: unsigned short __fractunsusahi (unsigned accum A)
+ -- Runtime Function: unsigned int __fractunsusasi (unsigned accum A)
+ -- Runtime Function: unsigned long __fractunsusadi (unsigned accum A)
+ -- Runtime Function: unsigned long long __fractunsusati (unsigned
+ accum A)
+ -- Runtime Function: unsigned char __fractunsudaqi (unsigned long
+ accum A)
+ -- Runtime Function: unsigned short __fractunsudahi (unsigned long
+ accum A)
+ -- Runtime Function: unsigned int __fractunsudasi (unsigned long accum
+ A)
+ -- Runtime Function: unsigned long __fractunsudadi (unsigned long
+ accum A)
+ -- Runtime Function: unsigned long long __fractunsudati (unsigned long
+ accum A)
+ -- Runtime Function: unsigned char __fractunsutaqi (unsigned long long
+ accum A)
+ -- Runtime Function: unsigned short __fractunsutahi (unsigned long
+ long accum A)
+ -- Runtime Function: unsigned int __fractunsutasi (unsigned long long
+ accum A)
+ -- Runtime Function: unsigned long __fractunsutadi (unsigned long long
+ accum A)
+ -- Runtime Function: unsigned long long __fractunsutati (unsigned long
+ long accum A)
+ -- Runtime Function: short fract __fractunsqiqq (unsigned char A)
+ -- Runtime Function: fract __fractunsqihq (unsigned char A)
+ -- Runtime Function: long fract __fractunsqisq (unsigned char A)
+ -- Runtime Function: long long fract __fractunsqidq (unsigned char A)
+ -- Runtime Function: short accum __fractunsqiha (unsigned char A)
+ -- Runtime Function: accum __fractunsqisa (unsigned char A)
+ -- Runtime Function: long accum __fractunsqida (unsigned char A)
+ -- Runtime Function: long long accum __fractunsqita (unsigned char A)
+ -- Runtime Function: unsigned short fract __fractunsqiuqq (unsigned
+ char A)
+ -- Runtime Function: unsigned fract __fractunsqiuhq (unsigned char A)
+ -- Runtime Function: unsigned long fract __fractunsqiusq (unsigned
+ char A)
+ -- Runtime Function: unsigned long long fract __fractunsqiudq
+ (unsigned char A)
+ -- Runtime Function: unsigned short accum __fractunsqiuha (unsigned
+ char A)
+ -- Runtime Function: unsigned accum __fractunsqiusa (unsigned char A)
+ -- Runtime Function: unsigned long accum __fractunsqiuda (unsigned
+ char A)
+ -- Runtime Function: unsigned long long accum __fractunsqiuta
+ (unsigned char A)
+ -- Runtime Function: short fract __fractunshiqq (unsigned short A)
+ -- Runtime Function: fract __fractunshihq (unsigned short A)
+ -- Runtime Function: long fract __fractunshisq (unsigned short A)
+ -- Runtime Function: long long fract __fractunshidq (unsigned short A)
+ -- Runtime Function: short accum __fractunshiha (unsigned short A)
+ -- Runtime Function: accum __fractunshisa (unsigned short A)
+ -- Runtime Function: long accum __fractunshida (unsigned short A)
+ -- Runtime Function: long long accum __fractunshita (unsigned short A)
+ -- Runtime Function: unsigned short fract __fractunshiuqq (unsigned
+ short A)
+ -- Runtime Function: unsigned fract __fractunshiuhq (unsigned short A)
+ -- Runtime Function: unsigned long fract __fractunshiusq (unsigned
+ short A)
+ -- Runtime Function: unsigned long long fract __fractunshiudq
+ (unsigned short A)
+ -- Runtime Function: unsigned short accum __fractunshiuha (unsigned
+ short A)
+ -- Runtime Function: unsigned accum __fractunshiusa (unsigned short A)
+ -- Runtime Function: unsigned long accum __fractunshiuda (unsigned
+ short A)
+ -- Runtime Function: unsigned long long accum __fractunshiuta
+ (unsigned short A)
+ -- Runtime Function: short fract __fractunssiqq (unsigned int A)
+ -- Runtime Function: fract __fractunssihq (unsigned int A)
+ -- Runtime Function: long fract __fractunssisq (unsigned int A)
+ -- Runtime Function: long long fract __fractunssidq (unsigned int A)
+ -- Runtime Function: short accum __fractunssiha (unsigned int A)
+ -- Runtime Function: accum __fractunssisa (unsigned int A)
+ -- Runtime Function: long accum __fractunssida (unsigned int A)
+ -- Runtime Function: long long accum __fractunssita (unsigned int A)
+ -- Runtime Function: unsigned short fract __fractunssiuqq (unsigned
+ int A)
+ -- Runtime Function: unsigned fract __fractunssiuhq (unsigned int A)
+ -- Runtime Function: unsigned long fract __fractunssiusq (unsigned int
+ A)
+ -- Runtime Function: unsigned long long fract __fractunssiudq
+ (unsigned int A)
+ -- Runtime Function: unsigned short accum __fractunssiuha (unsigned
+ int A)
+ -- Runtime Function: unsigned accum __fractunssiusa (unsigned int A)
+ -- Runtime Function: unsigned long accum __fractunssiuda (unsigned int
+ A)
+ -- Runtime Function: unsigned long long accum __fractunssiuta
+ (unsigned int A)
+ -- Runtime Function: short fract __fractunsdiqq (unsigned long A)
+ -- Runtime Function: fract __fractunsdihq (unsigned long A)
+ -- Runtime Function: long fract __fractunsdisq (unsigned long A)
+ -- Runtime Function: long long fract __fractunsdidq (unsigned long A)
+ -- Runtime Function: short accum __fractunsdiha (unsigned long A)
+ -- Runtime Function: accum __fractunsdisa (unsigned long A)
+ -- Runtime Function: long accum __fractunsdida (unsigned long A)
+ -- Runtime Function: long long accum __fractunsdita (unsigned long A)
+ -- Runtime Function: unsigned short fract __fractunsdiuqq (unsigned
+ long A)
+ -- Runtime Function: unsigned fract __fractunsdiuhq (unsigned long A)
+ -- Runtime Function: unsigned long fract __fractunsdiusq (unsigned
+ long A)
+ -- Runtime Function: unsigned long long fract __fractunsdiudq
+ (unsigned long A)
+ -- Runtime Function: unsigned short accum __fractunsdiuha (unsigned
+ long A)
+ -- Runtime Function: unsigned accum __fractunsdiusa (unsigned long A)
+ -- Runtime Function: unsigned long accum __fractunsdiuda (unsigned
+ long A)
+ -- Runtime Function: unsigned long long accum __fractunsdiuta
+ (unsigned long A)
+ -- Runtime Function: short fract __fractunstiqq (unsigned long long A)
+ -- Runtime Function: fract __fractunstihq (unsigned long long A)
+ -- Runtime Function: long fract __fractunstisq (unsigned long long A)
+ -- Runtime Function: long long fract __fractunstidq (unsigned long
+ long A)
+ -- Runtime Function: short accum __fractunstiha (unsigned long long A)
+ -- Runtime Function: accum __fractunstisa (unsigned long long A)
+ -- Runtime Function: long accum __fractunstida (unsigned long long A)
+ -- Runtime Function: long long accum __fractunstita (unsigned long
+ long A)
+ -- Runtime Function: unsigned short fract __fractunstiuqq (unsigned
+ long long A)
+ -- Runtime Function: unsigned fract __fractunstiuhq (unsigned long
+ long A)
+ -- Runtime Function: unsigned long fract __fractunstiusq (unsigned
+ long long A)
+ -- Runtime Function: unsigned long long fract __fractunstiudq
+ (unsigned long long A)
+ -- Runtime Function: unsigned short accum __fractunstiuha (unsigned
+ long long A)
+ -- Runtime Function: unsigned accum __fractunstiusa (unsigned long
+ long A)
+ -- Runtime Function: unsigned long accum __fractunstiuda (unsigned
+ long long A)
+ -- Runtime Function: unsigned long long accum __fractunstiuta
+ (unsigned long long A)
+ These functions convert from fractionals to unsigned
+ non-fractionals; and from unsigned non-fractionals to fractionals,
+ without saturation.
+
+ -- Runtime Function: short fract __satfractunsqiqq (unsigned char A)
+ -- Runtime Function: fract __satfractunsqihq (unsigned char A)
+ -- Runtime Function: long fract __satfractunsqisq (unsigned char A)
+ -- Runtime Function: long long fract __satfractunsqidq (unsigned char
+ A)
+ -- Runtime Function: short accum __satfractunsqiha (unsigned char A)
+ -- Runtime Function: accum __satfractunsqisa (unsigned char A)
+ -- Runtime Function: long accum __satfractunsqida (unsigned char A)
+ -- Runtime Function: long long accum __satfractunsqita (unsigned char
+ A)
+ -- Runtime Function: unsigned short fract __satfractunsqiuqq (unsigned
+ char A)
+ -- Runtime Function: unsigned fract __satfractunsqiuhq (unsigned char
+ A)
+ -- Runtime Function: unsigned long fract __satfractunsqiusq (unsigned
+ char A)
+ -- Runtime Function: unsigned long long fract __satfractunsqiudq
+ (unsigned char A)
+ -- Runtime Function: unsigned short accum __satfractunsqiuha (unsigned
+ char A)
+ -- Runtime Function: unsigned accum __satfractunsqiusa (unsigned char
+ A)
+ -- Runtime Function: unsigned long accum __satfractunsqiuda (unsigned
+ char A)
+ -- Runtime Function: unsigned long long accum __satfractunsqiuta
+ (unsigned char A)
+ -- Runtime Function: short fract __satfractunshiqq (unsigned short A)
+ -- Runtime Function: fract __satfractunshihq (unsigned short A)
+ -- Runtime Function: long fract __satfractunshisq (unsigned short A)
+ -- Runtime Function: long long fract __satfractunshidq (unsigned short
+ A)
+ -- Runtime Function: short accum __satfractunshiha (unsigned short A)
+ -- Runtime Function: accum __satfractunshisa (unsigned short A)
+ -- Runtime Function: long accum __satfractunshida (unsigned short A)
+ -- Runtime Function: long long accum __satfractunshita (unsigned short
+ A)
+ -- Runtime Function: unsigned short fract __satfractunshiuqq (unsigned
+ short A)
+ -- Runtime Function: unsigned fract __satfractunshiuhq (unsigned short
+ A)
+ -- Runtime Function: unsigned long fract __satfractunshiusq (unsigned
+ short A)
+ -- Runtime Function: unsigned long long fract __satfractunshiudq
+ (unsigned short A)
+ -- Runtime Function: unsigned short accum __satfractunshiuha (unsigned
+ short A)
+ -- Runtime Function: unsigned accum __satfractunshiusa (unsigned short
+ A)
+ -- Runtime Function: unsigned long accum __satfractunshiuda (unsigned
+ short A)
+ -- Runtime Function: unsigned long long accum __satfractunshiuta
+ (unsigned short A)
+ -- Runtime Function: short fract __satfractunssiqq (unsigned int A)
+ -- Runtime Function: fract __satfractunssihq (unsigned int A)
+ -- Runtime Function: long fract __satfractunssisq (unsigned int A)
+ -- Runtime Function: long long fract __satfractunssidq (unsigned int A)
+ -- Runtime Function: short accum __satfractunssiha (unsigned int A)
+ -- Runtime Function: accum __satfractunssisa (unsigned int A)
+ -- Runtime Function: long accum __satfractunssida (unsigned int A)
+ -- Runtime Function: long long accum __satfractunssita (unsigned int A)
+ -- Runtime Function: unsigned short fract __satfractunssiuqq (unsigned
+ int A)
+ -- Runtime Function: unsigned fract __satfractunssiuhq (unsigned int A)
+ -- Runtime Function: unsigned long fract __satfractunssiusq (unsigned
+ int A)
+ -- Runtime Function: unsigned long long fract __satfractunssiudq
+ (unsigned int A)
+ -- Runtime Function: unsigned short accum __satfractunssiuha (unsigned
+ int A)
+ -- Runtime Function: unsigned accum __satfractunssiusa (unsigned int A)
+ -- Runtime Function: unsigned long accum __satfractunssiuda (unsigned
+ int A)
+ -- Runtime Function: unsigned long long accum __satfractunssiuta
+ (unsigned int A)
+ -- Runtime Function: short fract __satfractunsdiqq (unsigned long A)
+ -- Runtime Function: fract __satfractunsdihq (unsigned long A)
+ -- Runtime Function: long fract __satfractunsdisq (unsigned long A)
+ -- Runtime Function: long long fract __satfractunsdidq (unsigned long
+ A)
+ -- Runtime Function: short accum __satfractunsdiha (unsigned long A)
+ -- Runtime Function: accum __satfractunsdisa (unsigned long A)
+ -- Runtime Function: long accum __satfractunsdida (unsigned long A)
+ -- Runtime Function: long long accum __satfractunsdita (unsigned long
+ A)
+ -- Runtime Function: unsigned short fract __satfractunsdiuqq (unsigned
+ long A)
+ -- Runtime Function: unsigned fract __satfractunsdiuhq (unsigned long
+ A)
+ -- Runtime Function: unsigned long fract __satfractunsdiusq (unsigned
+ long A)
+ -- Runtime Function: unsigned long long fract __satfractunsdiudq
+ (unsigned long A)
+ -- Runtime Function: unsigned short accum __satfractunsdiuha (unsigned
+ long A)
+ -- Runtime Function: unsigned accum __satfractunsdiusa (unsigned long
+ A)
+ -- Runtime Function: unsigned long accum __satfractunsdiuda (unsigned
+ long A)
+ -- Runtime Function: unsigned long long accum __satfractunsdiuta
+ (unsigned long A)
+ -- Runtime Function: short fract __satfractunstiqq (unsigned long long
+ A)
+ -- Runtime Function: fract __satfractunstihq (unsigned long long A)
+ -- Runtime Function: long fract __satfractunstisq (unsigned long long
+ A)
+ -- Runtime Function: long long fract __satfractunstidq (unsigned long
+ long A)
+ -- Runtime Function: short accum __satfractunstiha (unsigned long long
+ A)
+ -- Runtime Function: accum __satfractunstisa (unsigned long long A)
+ -- Runtime Function: long accum __satfractunstida (unsigned long long
+ A)
+ -- Runtime Function: long long accum __satfractunstita (unsigned long
+ long A)
+ -- Runtime Function: unsigned short fract __satfractunstiuqq (unsigned
+ long long A)
+ -- Runtime Function: unsigned fract __satfractunstiuhq (unsigned long
+ long A)
+ -- Runtime Function: unsigned long fract __satfractunstiusq (unsigned
+ long long A)
+ -- Runtime Function: unsigned long long fract __satfractunstiudq
+ (unsigned long long A)
+ -- Runtime Function: unsigned short accum __satfractunstiuha (unsigned
+ long long A)
+ -- Runtime Function: unsigned accum __satfractunstiusa (unsigned long
+ long A)
+ -- Runtime Function: unsigned long accum __satfractunstiuda (unsigned
+ long long A)
+ -- Runtime Function: unsigned long long accum __satfractunstiuta
+ (unsigned long long A)
+ These functions convert from unsigned non-fractionals to
+ fractionals, with saturation.
+
+\1f
+File: gccint.info, Node: Exception handling routines, Next: Miscellaneous routines, Prev: Fixed-point fractional library routines, Up: Libgcc
+
+4.5 Language-independent routines for exception handling
+========================================================
+
+document me!
+
+ _Unwind_DeleteException
+ _Unwind_Find_FDE
+ _Unwind_ForcedUnwind
+ _Unwind_GetGR
+ _Unwind_GetIP
+ _Unwind_GetLanguageSpecificData
+ _Unwind_GetRegionStart
+ _Unwind_GetTextRelBase
+ _Unwind_GetDataRelBase
+ _Unwind_RaiseException
+ _Unwind_Resume
+ _Unwind_SetGR
+ _Unwind_SetIP
+ _Unwind_FindEnclosingFunction
+ _Unwind_SjLj_Register
+ _Unwind_SjLj_Unregister
+ _Unwind_SjLj_RaiseException
+ _Unwind_SjLj_ForcedUnwind
+ _Unwind_SjLj_Resume
+ __deregister_frame
+ __deregister_frame_info
+ __deregister_frame_info_bases
+ __register_frame
+ __register_frame_info
+ __register_frame_info_bases
+ __register_frame_info_table
+ __register_frame_info_table_bases
+ __register_frame_table
+
+\1f
+File: gccint.info, Node: Miscellaneous routines, Prev: Exception handling routines, Up: Libgcc
+
+4.6 Miscellaneous runtime library routines
+==========================================
+
+4.6.1 Cache control functions
+-----------------------------
+
+ -- Runtime Function: void __clear_cache (char *BEG, char *END)
+ This function clears the instruction cache between BEG and END.
+
+\1f
+File: gccint.info, Node: Languages, Next: Source Tree, Prev: Libgcc, Up: Top
+
+5 Language Front Ends in GCC
+****************************
+
+The interface to front ends for languages in GCC, and in particular the
+`tree' structure (*note Trees::), was initially designed for C, and
+many aspects of it are still somewhat biased towards C and C-like
+languages. It is, however, reasonably well suited to other procedural
+languages, and front ends for many such languages have been written for
+GCC.
+
+ Writing a compiler as a front end for GCC, rather than compiling
+directly to assembler or generating C code which is then compiled by
+GCC, has several advantages:
+
+ * GCC front ends benefit from the support for many different target
+ machines already present in GCC.
+
+ * GCC front ends benefit from all the optimizations in GCC. Some of
+ these, such as alias analysis, may work better when GCC is
+ compiling directly from source code then when it is compiling from
+ generated C code.
+
+ * Better debugging information is generated when compiling directly
+ from source code than when going via intermediate generated C code.
+
+ Because of the advantages of writing a compiler as a GCC front end,
+GCC front ends have also been created for languages very different from
+those for which GCC was designed, such as the declarative
+logic/functional language Mercury. For these reasons, it may also be
+useful to implement compilers created for specialized purposes (for
+example, as part of a research project) as GCC front ends.
+
+\1f
+File: gccint.info, Node: Source Tree, Next: Options, Prev: Languages, Up: Top
+
+6 Source Tree Structure and Build System
+****************************************
+
+This chapter describes the structure of the GCC source tree, and how
+GCC is built. The user documentation for building and installing GCC
+is in a separate manual (`http://gcc.gnu.org/install/'), with which it
+is presumed that you are familiar.
+
+* Menu:
+
+* Configure Terms:: Configuration terminology and history.
+* Top Level:: The top level source directory.
+* gcc Directory:: The `gcc' subdirectory.
+* Testsuites:: The GCC testsuites.
+
+\1f
+File: gccint.info, Node: Configure Terms, Next: Top Level, Up: Source Tree
+
+6.1 Configure Terms and History
+===============================
+
+The configure and build process has a long and colorful history, and can
+be confusing to anyone who doesn't know why things are the way they are.
+While there are other documents which describe the configuration process
+in detail, here are a few things that everyone working on GCC should
+know.
+
+ There are three system names that the build knows about: the machine
+you are building on ("build"), the machine that you are building for
+("host"), and the machine that GCC will produce code for ("target").
+When you configure GCC, you specify these with `--build=', `--host=',
+and `--target='.
+
+ Specifying the host without specifying the build should be avoided, as
+`configure' may (and once did) assume that the host you specify is also
+the build, which may not be true.
+
+ If build, host, and target are all the same, this is called a
+"native". If build and host are the same but target is different, this
+is called a "cross". If build, host, and target are all different this
+is called a "canadian" (for obscure reasons dealing with Canada's
+political party and the background of the person working on the build
+at that time). If host and target are the same, but build is
+different, you are using a cross-compiler to build a native for a
+different system. Some people call this a "host-x-host", "crossed
+native", or "cross-built native". If build and target are the same,
+but host is different, you are using a cross compiler to build a cross
+compiler that produces code for the machine you're building on. This
+is rare, so there is no common way of describing it. There is a
+proposal to call this a "crossback".
+
+ If build and host are the same, the GCC you are building will also be
+used to build the target libraries (like `libstdc++'). If build and
+host are different, you must have already built and installed a cross
+compiler that will be used to build the target libraries (if you
+configured with `--target=foo-bar', this compiler will be called
+`foo-bar-gcc').
+
+ In the case of target libraries, the machine you're building for is the
+machine you specified with `--target'. So, build is the machine you're
+building on (no change there), host is the machine you're building for
+(the target libraries are built for the target, so host is the target
+you specified), and target doesn't apply (because you're not building a
+compiler, you're building libraries). The configure/make process will
+adjust these variables as needed. It also sets `$with_cross_host' to
+the original `--host' value in case you need it.
+
+ The `libiberty' support library is built up to three times: once for
+the host, once for the target (even if they are the same), and once for
+the build if build and host are different. This allows it to be used
+by all programs which are generated in the course of the build process.
+
\1f
-Indirect:
-gccint.info-1: 1250
-gccint.info-2: 48415
-gccint.info-3: 91676
-gccint.info-4: 127912
-gccint.info-5: 173371
-gccint.info-6: 222790
-gccint.info-7: 261767
-gccint.info-8: 302440
-gccint.info-9: 343547
-gccint.info-10: 360144
-gccint.info-11: 406797
-gccint.info-12: 453949
-gccint.info-13: 489017
-gccint.info-14: 538134
-gccint.info-15: 587199
-gccint.info-16: 635215
-gccint.info-17: 675920
-gccint.info-18: 723825
-gccint.info-19: 768901
-gccint.info-20: 816265
-gccint.info-21: 865703
-gccint.info-22: 907964
-gccint.info-23: 934646
+File: gccint.info, Node: Top Level, Next: gcc Directory, Prev: Configure Terms, Up: Source Tree
+
+6.2 Top Level Source Directory
+==============================
+
+The top level source directory in a GCC distribution contains several
+files and directories that are shared with other software distributions
+such as that of GNU Binutils. It also contains several subdirectories
+that contain parts of GCC and its runtime libraries:
+
+`boehm-gc'
+ The Boehm conservative garbage collector, used as part of the Java
+ runtime library.
+
+`contrib'
+ Contributed scripts that may be found useful in conjunction with
+ GCC. One of these, `contrib/texi2pod.pl', is used to generate man
+ pages from Texinfo manuals as part of the GCC build process.
+
+`fastjar'
+ An implementation of the `jar' command, used with the Java front
+ end.
+
+`fixincludes'
+ The support for fixing system headers to work with GCC. See
+ `fixincludes/README' for more information. The headers fixed by
+ this mechanism are installed in `LIBSUBDIR/include-fixed'. Along
+ with those headers, `README-fixinc' is also installed, as
+ `LIBSUBDIR/include-fixed/README'.
+
+`gcc'
+ The main sources of GCC itself (except for runtime libraries),
+ including optimizers, support for different target architectures,
+ language front ends, and testsuites. *Note The `gcc'
+ Subdirectory: gcc Directory, for details.
+
+`include'
+ Headers for the `libiberty' library.
+
+`intl'
+ GNU `libintl', from GNU `gettext', for systems which do not
+ include it in libc.
+
+`libada'
+ The Ada runtime library.
+
+`libcpp'
+ The C preprocessor library.
+
+`libgfortran'
+ The Fortran runtime library.
+
+`libffi'
+ The `libffi' library, used as part of the Java runtime library.
+
+`libiberty'
+ The `libiberty' library, used for portability and for some
+ generally useful data structures and algorithms. *Note
+ Introduction: (libiberty)Top, for more information about this
+ library.
+
+`libjava'
+ The Java runtime library.
+
+`libmudflap'
+ The `libmudflap' library, used for instrumenting pointer and array
+ dereferencing operations.
+
+`libobjc'
+ The Objective-C and Objective-C++ runtime library.
+
+`libstdc++-v3'
+ The C++ runtime library.
+
+`maintainer-scripts'
+ Scripts used by the `gccadmin' account on `gcc.gnu.org'.
+
+`zlib'
+ The `zlib' compression library, used by the Java front end and as
+ part of the Java runtime library.
+
+ The build system in the top level directory, including how recursion
+into subdirectories works and how building runtime libraries for
+multilibs is handled, is documented in a separate manual, included with
+GNU Binutils. *Note GNU configure and build system: (configure)Top,
+for details.
+
+\1f
+File: gccint.info, Node: gcc Directory, Next: Testsuites, Prev: Top Level, Up: Source Tree
+
+6.3 The `gcc' Subdirectory
+==========================
+
+The `gcc' directory contains many files that are part of the C sources
+of GCC, other files used as part of the configuration and build
+process, and subdirectories including documentation and a testsuite.
+The files that are sources of GCC are documented in a separate chapter.
+*Note Passes and Files of the Compiler: Passes.
+
+* Menu:
+
+* Subdirectories:: Subdirectories of `gcc'.
+* Configuration:: The configuration process, and the files it uses.
+* Build:: The build system in the `gcc' directory.
+* Makefile:: Targets in `gcc/Makefile'.
+* Library Files:: Library source files and headers under `gcc/'.
+* Headers:: Headers installed by GCC.
+* Documentation:: Building documentation in GCC.
+* Front End:: Anatomy of a language front end.
+* Back End:: Anatomy of a target back end.
+
+\1f
+File: gccint.info, Node: Subdirectories, Next: Configuration, Up: gcc Directory
+
+6.3.1 Subdirectories of `gcc'
+-----------------------------
+
+The `gcc' directory contains the following subdirectories:
+
+`LANGUAGE'
+ Subdirectories for various languages. Directories containing a
+ file `config-lang.in' are language subdirectories. The contents of
+ the subdirectories `cp' (for C++), `objc' (for Objective-C) and
+ `objcp' (for Objective-C++) are documented in this manual (*note
+ Passes and Files of the Compiler: Passes.); those for other
+ languages are not. *Note Anatomy of a Language Front End: Front
+ End, for details of the files in these directories.
+
+`config'
+ Configuration files for supported architectures and operating
+ systems. *Note Anatomy of a Target Back End: Back End, for
+ details of the files in this directory.
+
+`doc'
+ Texinfo documentation for GCC, together with automatically
+ generated man pages and support for converting the installation
+ manual to HTML. *Note Documentation::.
+
+`ginclude'
+ System headers installed by GCC, mainly those required by the C
+ standard of freestanding implementations. *Note Headers Installed
+ by GCC: Headers, for details of when these and other headers are
+ installed.
+
+`po'
+ Message catalogs with translations of messages produced by GCC into
+ various languages, `LANGUAGE.po'. This directory also contains
+ `gcc.pot', the template for these message catalogues, `exgettext',
+ a wrapper around `gettext' to extract the messages from the GCC
+ sources and create `gcc.pot', which is run by `make gcc.pot', and
+ `EXCLUDES', a list of files from which messages should not be
+ extracted.
+
+`testsuite'
+ The GCC testsuites (except for those for runtime libraries).
+ *Note Testsuites::.
+
+\1f
+File: gccint.info, Node: Configuration, Next: Build, Prev: Subdirectories, Up: gcc Directory
+
+6.3.2 Configuration in the `gcc' Directory
+------------------------------------------
+
+The `gcc' directory is configured with an Autoconf-generated script
+`configure'. The `configure' script is generated from `configure.ac'
+and `aclocal.m4'. From the files `configure.ac' and `acconfig.h',
+Autoheader generates the file `config.in'. The file `cstamp-h.in' is
+used as a timestamp.
+
+* Menu:
+
+* Config Fragments:: Scripts used by `configure'.
+* System Config:: The `config.build', `config.host', and
+ `config.gcc' files.
+* Configuration Files:: Files created by running `configure'.
+
+\1f
+File: gccint.info, Node: Config Fragments, Next: System Config, Up: Configuration
+
+6.3.2.1 Scripts Used by `configure'
+...................................
+
+`configure' uses some other scripts to help in its work:
+
+ * The standard GNU `config.sub' and `config.guess' files, kept in
+ the top level directory, are used.
+
+ * The file `config.gcc' is used to handle configuration specific to
+ the particular target machine. The file `config.build' is used to
+ handle configuration specific to the particular build machine.
+ The file `config.host' is used to handle configuration specific to
+ the particular host machine. (In general, these should only be
+ used for features that cannot reasonably be tested in Autoconf
+ feature tests.) *Note The `config.build'; `config.host'; and
+ `config.gcc' Files: System Config, for details of the contents of
+ these files.
+
+ * Each language subdirectory has a file `LANGUAGE/config-lang.in'
+ that is used for front-end-specific configuration. *Note The
+ Front End `config-lang.in' File: Front End Config, for details of
+ this file.
+
+ * A helper script `configure.frag' is used as part of creating the
+ output of `configure'.
+
+\1f
+File: gccint.info, Node: System Config, Next: Configuration Files, Prev: Config Fragments, Up: Configuration
+
+6.3.2.2 The `config.build'; `config.host'; and `config.gcc' Files
+.................................................................
+
+The `config.build' file contains specific rules for particular systems
+which GCC is built on. This should be used as rarely as possible, as
+the behavior of the build system can always be detected by autoconf.
+
+ The `config.host' file contains specific rules for particular systems
+which GCC will run on. This is rarely needed.
+
+ The `config.gcc' file contains specific rules for particular systems
+which GCC will generate code for. This is usually needed.
+
+ Each file has a list of the shell variables it sets, with
+descriptions, at the top of the file.
+
+ FIXME: document the contents of these files, and what variables should
+be set to control build, host and target configuration.
+
+\1f
+File: gccint.info, Node: Configuration Files, Prev: System Config, Up: Configuration
+
+6.3.2.3 Files Created by `configure'
+....................................
+
+Here we spell out what files will be set up by `configure' in the `gcc'
+directory. Some other files are created as temporary files in the
+configuration process, and are not used in the subsequent build; these
+are not documented.
+
+ * `Makefile' is constructed from `Makefile.in', together with the
+ host and target fragments (*note Makefile Fragments: Fragments.)
+ `t-TARGET' and `x-HOST' from `config', if any, and language
+ Makefile fragments `LANGUAGE/Make-lang.in'.
+
+ * `auto-host.h' contains information about the host machine
+ determined by `configure'. If the host machine is different from
+ the build machine, then `auto-build.h' is also created, containing
+ such information about the build machine.
+
+ * `config.status' is a script that may be run to recreate the
+ current configuration.
+
+ * `configargs.h' is a header containing details of the arguments
+ passed to `configure' to configure GCC, and of the thread model
+ used.
+
+ * `cstamp-h' is used as a timestamp.
+
+ * `fixinc/Makefile' is constructed from `fixinc/Makefile.in'.
+
+ * `gccbug', a script for reporting bugs in GCC, is constructed from
+ `gccbug.in'.
+
+ * `intl/Makefile' is constructed from `intl/Makefile.in'.
+
+ * If a language `config-lang.in' file (*note The Front End
+ `config-lang.in' File: Front End Config.) sets `outputs', then the
+ files listed in `outputs' there are also generated.
+
+ The following configuration headers are created from the Makefile,
+using `mkconfig.sh', rather than directly by `configure'. `config.h',
+`bconfig.h' and `tconfig.h' all contain the `xm-MACHINE.h' header, if
+any, appropriate to the host, build and target machines respectively,
+the configuration headers for the target, and some definitions; for the
+host and build machines, these include the autoconfigured headers
+generated by `configure'. The other configuration headers are
+determined by `config.gcc'. They also contain the typedefs for `rtx',
+`rtvec' and `tree'.
+
+ * `config.h', for use in programs that run on the host machine.
+
+ * `bconfig.h', for use in programs that run on the build machine.
+
+ * `tconfig.h', for use in programs and libraries for the target
+ machine.
+
+ * `tm_p.h', which includes the header `MACHINE-protos.h' that
+ contains prototypes for functions in the target `.c' file. FIXME:
+ why is such a separate header necessary?
+
+\1f
+File: gccint.info, Node: Build, Next: Makefile, Prev: Configuration, Up: gcc Directory
+
+6.3.3 Build System in the `gcc' Directory
+-----------------------------------------
+
+FIXME: describe the build system, including what is built in what
+stages. Also list the various source files that are used in the build
+process but aren't source files of GCC itself and so aren't documented
+below (*note Passes::).
+
+\1f
+File: gccint.info, Node: Makefile, Next: Library Files, Prev: Build, Up: gcc Directory
+
+6.3.4 Makefile Targets
+----------------------
+
+These targets are available from the `gcc' directory:
+
+`all'
+ This is the default target. Depending on what your
+ build/host/target configuration is, it coordinates all the things
+ that need to be built.
+
+`doc'
+ Produce info-formatted documentation and man pages. Essentially it
+ calls `make man' and `make info'.
+
+`dvi'
+ Produce DVI-formatted documentation.
+
+`pdf'
+ Produce PDF-formatted documentation.
+
+`html'
+ Produce HTML-formatted documentation.
+
+`man'
+ Generate man pages.
+
+`info'
+ Generate info-formatted pages.
+
+`mostlyclean'
+ Delete the files made while building the compiler.
+
+`clean'
+ That, and all the other files built by `make all'.
+
+`distclean'
+ That, and all the files created by `configure'.
+
+`maintainer-clean'
+ Distclean plus any file that can be generated from other files.
+ Note that additional tools may be required beyond what is normally
+ needed to build gcc.
+
+`srcextra'
+ Generates files in the source directory that do not exist in CVS
+ but should go into a release tarball. One example is
+ `gcc/java/parse.c' which is generated from the CVS source file
+ `gcc/java/parse.y'.
+
+`srcinfo'
+`srcman'
+ Copies the info-formatted and manpage documentation into the source
+ directory usually for the purpose of generating a release tarball.
+
+`install'
+ Installs gcc.
+
+`uninstall'
+ Deletes installed files.
+
+`check'
+ Run the testsuite. This creates a `testsuite' subdirectory that
+ has various `.sum' and `.log' files containing the results of the
+ testing. You can run subsets with, for example, `make check-gcc'.
+ You can specify specific tests by setting RUNTESTFLAGS to be the
+ name of the `.exp' file, optionally followed by (for some tests)
+ an equals and a file wildcard, like:
+
+ make check-gcc RUNTESTFLAGS="execute.exp=19980413-*"
+
+ Note that running the testsuite may require additional tools be
+ installed, such as TCL or dejagnu.
+
+ The toplevel tree from which you start GCC compilation is not the GCC
+directory, but rather a complex Makefile that coordinates the various
+steps of the build, including bootstrapping the compiler and using the
+new compiler to build target libraries.
+
+ When GCC is configured for a native configuration, the default action
+for `make' is to do a full three-stage bootstrap. This means that GCC
+is built three times--once with the native compiler, once with the
+native-built compiler it just built, and once with the compiler it
+built the second time. In theory, the last two should produce the same
+results, which `make compare' can check. Each stage is configured
+separately and compiled into a separate directory, to minimize problems
+due to ABI incompatibilities between the native compiler and GCC.
+
+ If you do a change, rebuilding will also start from the first stage
+and "bubble" up the change through the three stages. Each stage is
+taken from its build directory (if it had been built previously),
+rebuilt, and copied to its subdirectory. This will allow you to, for
+example, continue a bootstrap after fixing a bug which causes the
+stage2 build to crash. It does not provide as good coverage of the
+compiler as bootstrapping from scratch, but it ensures that the new
+code is syntactically correct (e.g., that you did not use GCC extensions
+by mistake), and avoids spurious bootstrap comparison failures(1).
+
+ Other targets available from the top level include:
+
+`bootstrap-lean'
+ Like `bootstrap', except that the various stages are removed once
+ they're no longer needed. This saves disk space.
+
+`bootstrap2'
+`bootstrap2-lean'
+ Performs only the first two stages of bootstrap. Unlike a
+ three-stage bootstrap, this does not perform a comparison to test
+ that the compiler is running properly. Note that the disk space
+ required by a "lean" bootstrap is approximately independent of the
+ number of stages.
+
+`stageN-bubble (N = 1...4)'
+ Rebuild all the stages up to N, with the appropriate flags,
+ "bubbling" the changes as described above.
+
+`all-stageN (N = 1...4)'
+ Assuming that stage N has already been built, rebuild it with the
+ appropriate flags. This is rarely needed.
+
+`cleanstrap'
+ Remove everything (`make clean') and rebuilds (`make bootstrap').
+
+`compare'
+ Compares the results of stages 2 and 3. This ensures that the
+ compiler is running properly, since it should produce the same
+ object files regardless of how it itself was compiled.
+
+`profiledbootstrap'
+ Builds a compiler with profiling feedback information. For more
+ information, see *note Building with profile feedback:
+ (gccinstall)Building.
+
+`restrap'
+ Restart a bootstrap, so that everything that was not built with
+ the system compiler is rebuilt.
+
+`stageN-start (N = 1...4)'
+ For each package that is bootstrapped, rename directories so that,
+ for example, `gcc' points to the stageN GCC, compiled with the
+ stageN-1 GCC(2).
+
+ You will invoke this target if you need to test or debug the
+ stageN GCC. If you only need to execute GCC (but you need not run
+ `make' either to rebuild it or to run test suites), you should be
+ able to work directly in the `stageN-gcc' directory. This makes
+ it easier to debug multiple stages in parallel.
+
+`stage'
+ For each package that is bootstrapped, relocate its build directory
+ to indicate its stage. For example, if the `gcc' directory points
+ to the stage2 GCC, after invoking this target it will be renamed
+ to `stage2-gcc'.
+
+
+ If you wish to use non-default GCC flags when compiling the stage2 and
+stage3 compilers, set `BOOT_CFLAGS' on the command line when doing
+`make'.
+
+ Usually, the first stage only builds the languages that the compiler
+is written in: typically, C and maybe Ada. If you are debugging a
+miscompilation of a different stage2 front-end (for example, of the
+Fortran front-end), you may want to have front-ends for other languages
+in the first stage as well. To do so, set `STAGE1_LANGUAGES' on the
+command line when doing `make'.
+
+ For example, in the aforementioned scenario of debugging a Fortran
+front-end miscompilation caused by the stage1 compiler, you may need a
+command like
+
+ make stage2-bubble STAGE1_LANGUAGES=c,fortran
+
+ Alternatively, you can use per-language targets to build and test
+languages that are not enabled by default in stage1. For example,
+`make f951' will build a Fortran compiler even in the stage1 build
+directory.
+
+ ---------- Footnotes ----------
+
+ (1) Except if the compiler was buggy and miscompiled some of the files
+that were not modified. In this case, it's best to use `make restrap'.
+
+ (2) Customarily, the system compiler is also termed the `stage0' GCC.
+
+\1f
+File: gccint.info, Node: Library Files, Next: Headers, Prev: Makefile, Up: gcc Directory
+
+6.3.5 Library Source Files and Headers under the `gcc' Directory
+----------------------------------------------------------------
+
+FIXME: list here, with explanation, all the C source files and headers
+under the `gcc' directory that aren't built into the GCC executable but
+rather are part of runtime libraries and object files, such as
+`crtstuff.c' and `unwind-dw2.c'. *Note Headers Installed by GCC:
+Headers, for more information about the `ginclude' directory.
+
+\1f
+File: gccint.info, Node: Headers, Next: Documentation, Prev: Library Files, Up: gcc Directory
+
+6.3.6 Headers Installed by GCC
+------------------------------
+
+In general, GCC expects the system C library to provide most of the
+headers to be used with it. However, GCC will fix those headers if
+necessary to make them work with GCC, and will install some headers
+required of freestanding implementations. These headers are installed
+in `LIBSUBDIR/include'. Headers for non-C runtime libraries are also
+installed by GCC; these are not documented here. (FIXME: document them
+somewhere.)
+
+ Several of the headers GCC installs are in the `ginclude' directory.
+These headers, `iso646.h', `stdarg.h', `stdbool.h', and `stddef.h', are
+installed in `LIBSUBDIR/include', unless the target Makefile fragment
+(*note Target Fragment::) overrides this by setting `USER_H'.
+
+ In addition to these headers and those generated by fixing system
+headers to work with GCC, some other headers may also be installed in
+`LIBSUBDIR/include'. `config.gcc' may set `extra_headers'; this
+specifies additional headers under `config' to be installed on some
+systems.
+
+ GCC installs its own version of `<float.h>', from `ginclude/float.h'.
+This is done to cope with command-line options that change the
+representation of floating point numbers.
+
+ GCC also installs its own version of `<limits.h>'; this is generated
+from `glimits.h', together with `limitx.h' and `limity.h' if the system
+also has its own version of `<limits.h>'. (GCC provides its own header
+because it is required of ISO C freestanding implementations, but needs
+to include the system header from its own header as well because other
+standards such as POSIX specify additional values to be defined in
+`<limits.h>'.) The system's `<limits.h>' header is used via
+`LIBSUBDIR/include/syslimits.h', which is copied from `gsyslimits.h' if
+it does not need fixing to work with GCC; if it needs fixing,
+`syslimits.h' is the fixed copy.
+
+ GCC can also install `<tgmath.h>'. It will do this when `config.gcc'
+sets `use_gcc_tgmath' to `yes'.
+
+\1f
+File: gccint.info, Node: Documentation, Next: Front End, Prev: Headers, Up: gcc Directory
+
+6.3.7 Building Documentation
+----------------------------
+
+The main GCC documentation is in the form of manuals in Texinfo format.
+These are installed in Info format; DVI versions may be generated by
+`make dvi', PDF versions by `make pdf', and HTML versions by `make
+html'. In addition, some man pages are generated from the Texinfo
+manuals, there are some other text files with miscellaneous
+documentation, and runtime libraries have their own documentation
+outside the `gcc' directory. FIXME: document the documentation for
+runtime libraries somewhere.
+
+* Menu:
+
+* Texinfo Manuals:: GCC manuals in Texinfo format.
+* Man Page Generation:: Generating man pages from Texinfo manuals.
+* Miscellaneous Docs:: Miscellaneous text files with documentation.
+
+\1f
+File: gccint.info, Node: Texinfo Manuals, Next: Man Page Generation, Up: Documentation
+
+6.3.7.1 Texinfo Manuals
+.......................
+
+The manuals for GCC as a whole, and the C and C++ front ends, are in
+files `doc/*.texi'. Other front ends have their own manuals in files
+`LANGUAGE/*.texi'. Common files `doc/include/*.texi' are provided
+which may be included in multiple manuals; the following files are in
+`doc/include':
+
+`fdl.texi'
+ The GNU Free Documentation License.
+
+`funding.texi'
+ The section "Funding Free Software".
+
+`gcc-common.texi'
+ Common definitions for manuals.
+
+`gpl.texi'
+`gpl_v3.texi'
+ The GNU General Public License.
+
+`texinfo.tex'
+ A copy of `texinfo.tex' known to work with the GCC manuals.
+
+ DVI-formatted manuals are generated by `make dvi', which uses
+`texi2dvi' (via the Makefile macro `$(TEXI2DVI)'). PDF-formatted
+manuals are generated by `make pdf', which uses `texi2pdf' (via the
+Makefile macro `$(TEXI2PDF)'). HTML formatted manuals are generated by
+`make html'. Info manuals are generated by `make info' (which is run
+as part of a bootstrap); this generates the manuals in the source
+directory, using `makeinfo' via the Makefile macro `$(MAKEINFO)', and
+they are included in release distributions.
+
+ Manuals are also provided on the GCC web site, in both HTML and
+PostScript forms. This is done via the script
+`maintainer-scripts/update_web_docs'. Each manual to be provided
+online must be listed in the definition of `MANUALS' in that file; a
+file `NAME.texi' must only appear once in the source tree, and the
+output manual must have the same name as the source file. (However,
+other Texinfo files, included in manuals but not themselves the root
+files of manuals, may have names that appear more than once in the
+source tree.) The manual file `NAME.texi' should only include other
+files in its own directory or in `doc/include'. HTML manuals will be
+generated by `makeinfo --html', PostScript manuals by `texi2dvi' and
+`dvips', and PDF manuals by `texi2pdf'. All Texinfo files that are
+parts of manuals must be checked into SVN, even if they are generated
+files, for the generation of online manuals to work.
+
+ The installation manual, `doc/install.texi', is also provided on the
+GCC web site. The HTML version is generated by the script
+`doc/install.texi2html'.
+
+\1f
+File: gccint.info, Node: Man Page Generation, Next: Miscellaneous Docs, Prev: Texinfo Manuals, Up: Documentation
+
+6.3.7.2 Man Page Generation
+...........................
+
+Because of user demand, in addition to full Texinfo manuals, man pages
+are provided which contain extracts from those manuals. These man
+pages are generated from the Texinfo manuals using
+`contrib/texi2pod.pl' and `pod2man'. (The man page for `g++',
+`cp/g++.1', just contains a `.so' reference to `gcc.1', but all the
+other man pages are generated from Texinfo manuals.)
+
+ Because many systems may not have the necessary tools installed to
+generate the man pages, they are only generated if the `configure'
+script detects that recent enough tools are installed, and the
+Makefiles allow generating man pages to fail without aborting the
+build. Man pages are also included in release distributions. They are
+generated in the source directory.
+
+ Magic comments in Texinfo files starting `@c man' control what parts
+of a Texinfo file go into a man page. Only a subset of Texinfo is
+supported by `texi2pod.pl', and it may be necessary to add support for
+more Texinfo features to this script when generating new man pages. To
+improve the man page output, some special Texinfo macros are provided
+in `doc/include/gcc-common.texi' which `texi2pod.pl' understands:
+
+`@gcctabopt'
+ Use in the form `@table @gcctabopt' for tables of options, where
+ for printed output the effect of `@code' is better than that of
+ `@option' but for man page output a different effect is wanted.
+
+`@gccoptlist'
+ Use for summary lists of options in manuals.
+
+`@gol'
+ Use at the end of each line inside `@gccoptlist'. This is
+ necessary to avoid problems with differences in how the
+ `@gccoptlist' macro is handled by different Texinfo formatters.
+
+ FIXME: describe the `texi2pod.pl' input language and magic comments in
+more detail.
+
+\1f
+File: gccint.info, Node: Miscellaneous Docs, Prev: Man Page Generation, Up: Documentation
+
+6.3.7.3 Miscellaneous Documentation
+...................................
+
+In addition to the formal documentation that is installed by GCC, there
+are several other text files with miscellaneous documentation:
+
+`ABOUT-GCC-NLS'
+ Notes on GCC's Native Language Support. FIXME: this should be
+ part of this manual rather than a separate file.
+
+`ABOUT-NLS'
+ Notes on the Free Translation Project.
+
+`COPYING'
+ The GNU General Public License.
+
+`COPYING.LIB'
+ The GNU Lesser General Public License.
+
+`*ChangeLog*'
+`*/ChangeLog*'
+ Change log files for various parts of GCC.
+
+`LANGUAGES'
+ Details of a few changes to the GCC front-end interface. FIXME:
+ the information in this file should be part of general
+ documentation of the front-end interface in this manual.
+
+`ONEWS'
+ Information about new features in old versions of GCC. (For recent
+ versions, the information is on the GCC web site.)
+
+`README.Portability'
+ Information about portability issues when writing code in GCC.
+ FIXME: why isn't this part of this manual or of the GCC Coding
+ Conventions?
+
+ FIXME: document such files in subdirectories, at least `config', `cp',
+`objc', `testsuite'.
+
+\1f
+File: gccint.info, Node: Front End, Next: Back End, Prev: Documentation, Up: gcc Directory
+
+6.3.8 Anatomy of a Language Front End
+-------------------------------------
+
+A front end for a language in GCC has the following parts:
+
+ * A directory `LANGUAGE' under `gcc' containing source files for
+ that front end. *Note The Front End `LANGUAGE' Directory: Front
+ End Directory, for details.
+
+ * A mention of the language in the list of supported languages in
+ `gcc/doc/install.texi'.
+
+ * A mention of the name under which the language's runtime library is
+ recognized by `--enable-shared=PACKAGE' in the documentation of
+ that option in `gcc/doc/install.texi'.
+
+ * A mention of any special prerequisites for building the front end
+ in the documentation of prerequisites in `gcc/doc/install.texi'.
+
+ * Details of contributors to that front end in
+ `gcc/doc/contrib.texi'. If the details are in that front end's
+ own manual then there should be a link to that manual's list in
+ `contrib.texi'.
+
+ * Information about support for that language in
+ `gcc/doc/frontends.texi'.
+
+ * Information about standards for that language, and the front end's
+ support for them, in `gcc/doc/standards.texi'. This may be a link
+ to such information in the front end's own manual.
+
+ * Details of source file suffixes for that language and `-x LANG'
+ options supported, in `gcc/doc/invoke.texi'.
+
+ * Entries in `default_compilers' in `gcc.c' for source file suffixes
+ for that language.
+
+ * Preferably testsuites, which may be under `gcc/testsuite' or
+ runtime library directories. FIXME: document somewhere how to
+ write testsuite harnesses.
+
+ * Probably a runtime library for the language, outside the `gcc'
+ directory. FIXME: document this further.
+
+ * Details of the directories of any runtime libraries in
+ `gcc/doc/sourcebuild.texi'.
+
+ If the front end is added to the official GCC source repository, the
+following are also necessary:
+
+ * At least one Bugzilla component for bugs in that front end and
+ runtime libraries. This category needs to be mentioned in
+ `gcc/gccbug.in', as well as being added to the Bugzilla database.
+
+ * Normally, one or more maintainers of that front end listed in
+ `MAINTAINERS'.
+
+ * Mentions on the GCC web site in `index.html' and `frontends.html',
+ with any relevant links on `readings.html'. (Front ends that are
+ not an official part of GCC may also be listed on
+ `frontends.html', with relevant links.)
+
+ * A news item on `index.html', and possibly an announcement on the
+ <gcc-announce@gcc.gnu.org> mailing list.
+
+ * The front end's manuals should be mentioned in
+ `maintainer-scripts/update_web_docs' (*note Texinfo Manuals::) and
+ the online manuals should be linked to from
+ `onlinedocs/index.html'.
+
+ * Any old releases or CVS repositories of the front end, before its
+ inclusion in GCC, should be made available on the GCC FTP site
+ `ftp://gcc.gnu.org/pub/gcc/old-releases/'.
+
+ * The release and snapshot script `maintainer-scripts/gcc_release'
+ should be updated to generate appropriate tarballs for this front
+ end. The associated `maintainer-scripts/snapshot-README' and
+ `maintainer-scripts/snapshot-index.html' files should be updated
+ to list the tarballs and diffs for this front end.
+
+ * If this front end includes its own version files that include the
+ current date, `maintainer-scripts/update_version' should be
+ updated accordingly.
+
+* Menu:
+
+* Front End Directory:: The front end `LANGUAGE' directory.
+* Front End Config:: The front end `config-lang.in' file.
+
+\1f
+File: gccint.info, Node: Front End Directory, Next: Front End Config, Up: Front End
+
+6.3.8.1 The Front End `LANGUAGE' Directory
+..........................................
+
+A front end `LANGUAGE' directory contains the source files of that
+front end (but not of any runtime libraries, which should be outside
+the `gcc' directory). This includes documentation, and possibly some
+subsidiary programs build alongside the front end. Certain files are
+special and other parts of the compiler depend on their names:
+
+`config-lang.in'
+ This file is required in all language subdirectories. *Note The
+ Front End `config-lang.in' File: Front End Config, for details of
+ its contents
+
+`Make-lang.in'
+ This file is required in all language subdirectories. It contains
+ targets `LANG.HOOK' (where `LANG' is the setting of `language' in
+ `config-lang.in') for the following values of `HOOK', and any
+ other Makefile rules required to build those targets (which may if
+ necessary use other Makefiles specified in `outputs' in
+ `config-lang.in', although this is deprecated). It also adds any
+ testsuite targets that can use the standard rule in
+ `gcc/Makefile.in' to the variable `lang_checks'.
+
+ `all.cross'
+ `start.encap'
+ `rest.encap'
+ FIXME: exactly what goes in each of these targets?
+
+ `tags'
+ Build an `etags' `TAGS' file in the language subdirectory in
+ the source tree.
+
+ `info'
+ Build info documentation for the front end, in the build
+ directory. This target is only called by `make bootstrap' if
+ a suitable version of `makeinfo' is available, so does not
+ need to check for this, and should fail if an error occurs.
+
+ `dvi'
+ Build DVI documentation for the front end, in the build
+ directory. This should be done using `$(TEXI2DVI)', with
+ appropriate `-I' arguments pointing to directories of
+ included files.
+
+ `pdf'
+ Build PDF documentation for the front end, in the build
+ directory. This should be done using `$(TEXI2PDF)', with
+ appropriate `-I' arguments pointing to directories of
+ included files.
+
+ `html'
+ Build HTML documentation for the front end, in the build
+ directory.
+
+ `man'
+ Build generated man pages for the front end from Texinfo
+ manuals (*note Man Page Generation::), in the build
+ directory. This target is only called if the necessary tools
+ are available, but should ignore errors so as not to stop the
+ build if errors occur; man pages are optional and the tools
+ involved may be installed in a broken way.
+
+ `install-common'
+ Install everything that is part of the front end, apart from
+ the compiler executables listed in `compilers' in
+ `config-lang.in'.
+
+ `install-info'
+ Install info documentation for the front end, if it is
+ present in the source directory. This target should have
+ dependencies on info files that should be installed.
+
+ `install-man'
+ Install man pages for the front end. This target should
+ ignore errors.
+
+ `srcextra'
+ Copies its dependencies into the source directory. This
+ generally should be used for generated files such as Bison
+ output files which are not present in CVS, but should be
+ included in any release tarballs. This target will be
+ executed during a bootstrap if
+ `--enable-generated-files-in-srcdir' was specified as a
+ `configure' option.
+
+ `srcinfo'
+ `srcman'
+ Copies its dependencies into the source directory. These
+ targets will be executed during a bootstrap if
+ `--enable-generated-files-in-srcdir' was specified as a
+ `configure' option.
+
+ `uninstall'
+ Uninstall files installed by installing the compiler. This is
+ currently documented not to be supported, so the hook need
+ not do anything.
+
+ `mostlyclean'
+ `clean'
+ `distclean'
+ `maintainer-clean'
+ The language parts of the standard GNU `*clean' targets.
+ *Note Standard Targets for Users: (standards)Standard
+ Targets, for details of the standard targets. For GCC,
+ `maintainer-clean' should delete all generated files in the
+ source directory that are not checked into CVS, but should
+ not delete anything checked into CVS.
+
+ `Make-lang.in' must also define a variable `LANG_OBJS' to a list
+ of host object files that are used by that language.
+
+`lang.opt'
+ This file registers the set of switches that the front end accepts
+ on the command line, and their `--help' text. *Note Options::.
+
+`lang-specs.h'
+ This file provides entries for `default_compilers' in `gcc.c'
+ which override the default of giving an error that a compiler for
+ that language is not installed.
+
+`LANGUAGE-tree.def'
+ This file, which need not exist, defines any language-specific tree
+ codes.
+
+\1f
+File: gccint.info, Node: Front End Config, Prev: Front End Directory, Up: Front End
+
+6.3.8.2 The Front End `config-lang.in' File
+...........................................
+
+Each language subdirectory contains a `config-lang.in' file. In
+addition the main directory contains `c-config-lang.in', which contains
+limited information for the C language. This file is a shell script
+that may define some variables describing the language:
+
+`language'
+ This definition must be present, and gives the name of the language
+ for some purposes such as arguments to `--enable-languages'.
+
+`lang_requires'
+ If defined, this variable lists (space-separated) language front
+ ends other than C that this front end requires to be enabled (with
+ the names given being their `language' settings). For example, the
+ Java front end depends on the C++ front end, so sets
+ `lang_requires=c++'.
+
+`subdir_requires'
+ If defined, this variable lists (space-separated) front end
+ directories other than C that this front end requires to be
+ present. For example, the Objective-C++ front end uses source
+ files from the C++ and Objective-C front ends, so sets
+ `subdir_requires="cp objc"'.
+
+`target_libs'
+ If defined, this variable lists (space-separated) targets in the
+ top level `Makefile' to build the runtime libraries for this
+ language, such as `target-libobjc'.
+
+`lang_dirs'
+ If defined, this variable lists (space-separated) top level
+ directories (parallel to `gcc'), apart from the runtime libraries,
+ that should not be configured if this front end is not built.
+
+`build_by_default'
+ If defined to `no', this language front end is not built unless
+ enabled in a `--enable-languages' argument. Otherwise, front ends
+ are built by default, subject to any special logic in
+ `configure.ac' (as is present to disable the Ada front end if the
+ Ada compiler is not already installed).
+
+`boot_language'
+ If defined to `yes', this front end is built in stage 1 of the
+ bootstrap. This is only relevant to front ends written in their
+ own languages.
+
+`compilers'
+ If defined, a space-separated list of compiler executables that
+ will be run by the driver. The names here will each end with
+ `\$(exeext)'.
+
+`outputs'
+ If defined, a space-separated list of files that should be
+ generated by `configure' substituting values in them. This
+ mechanism can be used to create a file `LANGUAGE/Makefile' from
+ `LANGUAGE/Makefile.in', but this is deprecated, building
+ everything from the single `gcc/Makefile' is preferred.
+
+`gtfiles'
+ If defined, a space-separated list of files that should be scanned
+ by gengtype.c to generate the garbage collection tables and
+ routines for this language. This excludes the files that are
+ common to all front ends. *Note Type Information::.
+
+
+\1f
+File: gccint.info, Node: Back End, Prev: Front End, Up: gcc Directory
+
+6.3.9 Anatomy of a Target Back End
+----------------------------------
+
+A back end for a target architecture in GCC has the following parts:
+
+ * A directory `MACHINE' under `gcc/config', containing a machine
+ description `MACHINE.md' file (*note Machine Descriptions: Machine
+ Desc.), header files `MACHINE.h' and `MACHINE-protos.h' and a
+ source file `MACHINE.c' (*note Target Description Macros and
+ Functions: Target Macros.), possibly a target Makefile fragment
+ `t-MACHINE' (*note The Target Makefile Fragment: Target
+ Fragment.), and maybe some other files. The names of these files
+ may be changed from the defaults given by explicit specifications
+ in `config.gcc'.
+
+ * If necessary, a file `MACHINE-modes.def' in the `MACHINE'
+ directory, containing additional machine modes to represent
+ condition codes. *Note Condition Code::, for further details.
+
+ * An optional `MACHINE.opt' file in the `MACHINE' directory,
+ containing a list of target-specific options. You can also add
+ other option files using the `extra_options' variable in
+ `config.gcc'. *Note Options::.
+
+ * Entries in `config.gcc' (*note The `config.gcc' File: System
+ Config.) for the systems with this target architecture.
+
+ * Documentation in `gcc/doc/invoke.texi' for any command-line
+ options supported by this target (*note Run-time Target
+ Specification: Run-time Target.). This means both entries in the
+ summary table of options and details of the individual options.
+
+ * Documentation in `gcc/doc/extend.texi' for any target-specific
+ attributes supported (*note Defining target-specific uses of
+ `__attribute__': Target Attributes.), including where the same
+ attribute is already supported on some targets, which are
+ enumerated in the manual.
+
+ * Documentation in `gcc/doc/extend.texi' for any target-specific
+ pragmas supported.
+
+ * Documentation in `gcc/doc/extend.texi' of any target-specific
+ built-in functions supported.
+
+ * Documentation in `gcc/doc/extend.texi' of any target-specific
+ format checking styles supported.
+
+ * Documentation in `gcc/doc/md.texi' of any target-specific
+ constraint letters (*note Constraints for Particular Machines:
+ Machine Constraints.).
+
+ * A note in `gcc/doc/contrib.texi' under the person or people who
+ contributed the target support.
+
+ * Entries in `gcc/doc/install.texi' for all target triplets
+ supported with this target architecture, giving details of any
+ special notes about installation for this target, or saying that
+ there are no special notes if there are none.
+
+ * Possibly other support outside the `gcc' directory for runtime
+ libraries. FIXME: reference docs for this. The libstdc++ porting
+ manual needs to be installed as info for this to work, or to be a
+ chapter of this manual.
+
+ If the back end is added to the official GCC source repository, the
+following are also necessary:
+
+ * An entry for the target architecture in `readings.html' on the GCC
+ web site, with any relevant links.
+
+ * Details of the properties of the back end and target architecture
+ in `backends.html' on the GCC web site.
+
+ * A news item about the contribution of support for that target
+ architecture, in `index.html' on the GCC web site.
+
+ * Normally, one or more maintainers of that target listed in
+ `MAINTAINERS'. Some existing architectures may be unmaintained,
+ but it would be unusual to add support for a target that does not
+ have a maintainer when support is added.
+
+\1f
+File: gccint.info, Node: Testsuites, Prev: gcc Directory, Up: Source Tree
+
+6.4 Testsuites
+==============
+
+GCC contains several testsuites to help maintain compiler quality.
+Most of the runtime libraries and language front ends in GCC have
+testsuites. Currently only the C language testsuites are documented
+here; FIXME: document the others.
+
+* Menu:
+
+* Test Idioms:: Idioms used in testsuite code.
+* Test Directives:: Directives used within DejaGnu tests.
+* Ada Tests:: The Ada language testsuites.
+* C Tests:: The C language testsuites.
+* libgcj Tests:: The Java library testsuites.
+* gcov Testing:: Support for testing gcov.
+* profopt Testing:: Support for testing profile-directed optimizations.
+* compat Testing:: Support for testing binary compatibility.
+* Torture Tests:: Support for torture testing using multiple options.
+
+\1f
+File: gccint.info, Node: Test Idioms, Next: Test Directives, Up: Testsuites
+
+6.4.1 Idioms Used in Testsuite Code
+-----------------------------------
+
+In general, C testcases have a trailing `-N.c', starting with `-1.c',
+in case other testcases with similar names are added later. If the
+test is a test of some well-defined feature, it should have a name
+referring to that feature such as `FEATURE-1.c'. If it does not test a
+well-defined feature but just happens to exercise a bug somewhere in
+the compiler, and a bug report has been filed for this bug in the GCC
+bug database, `prBUG-NUMBER-1.c' is the appropriate form of name.
+Otherwise (for miscellaneous bugs not filed in the GCC bug database),
+and previously more generally, test cases are named after the date on
+which they were added. This allows people to tell at a glance whether
+a test failure is because of a recently found bug that has not yet been
+fixed, or whether it may be a regression, but does not give any other
+information about the bug or where discussion of it may be found. Some
+other language testsuites follow similar conventions.
+
+ In the `gcc.dg' testsuite, it is often necessary to test that an error
+is indeed a hard error and not just a warning--for example, where it is
+a constraint violation in the C standard, which must become an error
+with `-pedantic-errors'. The following idiom, where the first line
+shown is line LINE of the file and the line that generates the error,
+is used for this:
+
+ /* { dg-bogus "warning" "warning in place of error" } */
+ /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */
+
+ It may be necessary to check that an expression is an integer constant
+expression and has a certain value. To check that `E' has value `V',
+an idiom similar to the following is used:
+
+ char x[((E) == (V) ? 1 : -1)];
+
+ In `gcc.dg' tests, `__typeof__' is sometimes used to make assertions
+about the types of expressions. See, for example,
+`gcc.dg/c99-condexpr-1.c'. The more subtle uses depend on the exact
+rules for the types of conditional expressions in the C standard; see,
+for example, `gcc.dg/c99-intconst-1.c'.
+
+ It is useful to be able to test that optimizations are being made
+properly. This cannot be done in all cases, but it can be done where
+the optimization will lead to code being optimized away (for example,
+where flow analysis or alias analysis should show that certain code
+cannot be called) or to functions not being called because they have
+been expanded as built-in functions. Such tests go in
+`gcc.c-torture/execute'. Where code should be optimized away, a call
+to a nonexistent function such as `link_failure ()' may be inserted; a
+definition
+
+ #ifndef __OPTIMIZE__
+ void
+ link_failure (void)
+ {
+ abort ();
+ }
+ #endif
+
+will also be needed so that linking still succeeds when the test is run
+without optimization. When all calls to a built-in function should
+have been optimized and no calls to the non-built-in version of the
+function should remain, that function may be defined as `static' to
+call `abort ()' (although redeclaring a function as static may not work
+on all targets).
+
+ All testcases must be portable. Target-specific testcases must have
+appropriate code to avoid causing failures on unsupported systems;
+unfortunately, the mechanisms for this differ by directory.
+
+ FIXME: discuss non-C testsuites here.
+
+\1f
+File: gccint.info, Node: Test Directives, Next: Ada Tests, Prev: Test Idioms, Up: Testsuites
+
+6.4.2 Directives used within DejaGnu tests
+------------------------------------------
+
+Test directives appear within comments in a test source file and begin
+with `dg-'. Some of these are defined within DejaGnu and others are
+local to the GCC testsuite.
+
+ The order in which test directives appear in a test can be important:
+directives local to GCC sometimes override information used by the
+DejaGnu directives, which know nothing about the GCC directives, so the
+DejaGnu directives must precede GCC directives.
+
+ Several test directives include selectors which are usually preceded by
+the keyword `target' or `xfail'. A selector is: one or more target
+triplets, possibly including wildcard characters; a single
+effective-target keyword; or a logical expression. Depending on the
+context, the selector specifies whether a test is skipped and reported
+as unsupported or is expected to fail. Use `*-*-*' to match any target.
+Effective-target keywords are defined in `target-supports.exp' in the
+GCC testsuite.
+
+ A selector expression appears within curly braces and uses a single
+logical operator: one of `!', `&&', or `||'. An operand is another
+selector expression, an effective-target keyword, a single target
+triplet, or a list of target triplets within quotes or curly braces.
+For example:
+
+ { target { ! "hppa*-*-* ia64*-*-*" } }
+ { target { powerpc*-*-* && lp64 } }
+ { xfail { lp64 || vect_no_align } }
+
+`{ dg-do DO-WHAT-KEYWORD [{ target/xfail SELECTOR }] }'
+ DO-WHAT-KEYWORD specifies how the test is compiled and whether it
+ is executed. It is one of:
+
+ `preprocess'
+ Compile with `-E' to run only the preprocessor.
+
+ `compile'
+ Compile with `-S' to produce an assembly code file.
+
+ `assemble'
+ Compile with `-c' to produce a relocatable object file.
+
+ `link'
+ Compile, assemble, and link to produce an executable file.
+
+ `run'
+ Produce and run an executable file, which is expected to
+ return an exit code of 0.
+
+ The default is `compile'. That can be overridden for a set of
+ tests by redefining `dg-do-what-default' within the `.exp' file
+ for those tests.
+
+ If the directive includes the optional `{ target SELECTOR }' then
+ the test is skipped unless the target system is included in the
+ list of target triplets or matches the effective-target keyword.
+
+ If `do-what-keyword' is `run' and the directive includes the
+ optional `{ xfail SELECTOR }' and the selector is met then the
+ test is expected to fail. The `xfail' clause is ignored for other
+ values of `do-what-keyword'; those tests can use directive
+ `dg-xfail-if'.
+
+`{ dg-options OPTIONS [{ target SELECTOR }] }'
+ This DejaGnu directive provides a list of compiler options, to be
+ used if the target system matches SELECTOR, that replace the
+ default options used for this set of tests.
+
+`{ dg-add-options FEATURE ... }'
+ Add any compiler options that are needed to access certain
+ features. This directive does nothing on targets that enable the
+ features by default, or that don't provide them at all. It must
+ come after all `dg-options' directives.
+
+ The supported values of FEATURE are:
+ `c99_runtime'
+ The target's C99 runtime (both headers and libraries).
+
+ `mips16_attribute'
+ `mips16' function attributes. Only MIPS targets support this
+ feature, and only then in certain modes.
+
+`{ dg-timeout N [{target SELECTOR }] }'
+ Set the time limit for the compilation and for the execution of
+ the test to the specified number of seconds.
+
+`{ dg-timeout-factor X [{ target SELECTOR }] }'
+ Multiply the normal time limit for compilation and execution of
+ the test by the specified floating-point factor. The normal
+ timeout limit, in seconds, is found by searching the following in
+ order:
+
+ * the value defined by an earlier `dg-timeout' directive in the
+ test
+
+ * variable TOOL_TIMEOUT defined by the set of tests
+
+ * GCC,TIMEOUT set in the target board
+
+ * 300
+
+`{ dg-skip-if COMMENT { SELECTOR } { INCLUDE-OPTS } { EXCLUDE-OPTS } }'
+ Skip the test if the test system is included in SELECTOR and if
+ each of the options in INCLUDE-OPTS is in the set of options with
+ which the test would be compiled and if none of the options in
+ EXCLUDE-OPTS is in the set of options with which the test would be
+ compiled.
+
+ Use `"*"' for an empty INCLUDE-OPTS list and `""' for an empty
+ EXCLUDE-OPTS list.
+
+`{ dg-xfail-if COMMENT { SELECTOR } { INCLUDE-OPTS } { EXCLUDE-OPTS } }'
+ Expect the test to fail if the conditions (which are the same as
+ for `dg-skip-if') are met. This does not affect the execute step.
+
+`{ dg-xfail-run-if COMMENT { SELECTOR } { INCLUDE-OPTS } { EXCLUDE-OPTS } }'
+ Expect the execute step of a test to fail if the conditions (which
+ are the same as for `dg-skip-if') and `dg-xfail-if') are met.
+
+`{ dg-require-SUPPORT args }'
+ Skip the test if the target does not provide the required support;
+ see `gcc-dg.exp' in the GCC testsuite for the actual directives.
+ These directives must appear after any `dg-do' directive in the
+ test and before any `dg-additional-sources' directive. They
+ require at least one argument, which can be an empty string if the
+ specific procedure does not examine the argument.
+
+`{ dg-require-effective-target KEYWORD }'
+ Skip the test if the test target, including current multilib flags,
+ is not covered by the effective-target keyword. This directive
+ must appear after any `dg-do' directive in the test and before any
+ `dg-additional-sources' directive.
+
+`{ dg-shouldfail COMMENT { SELECTOR } { INCLUDE-OPTS } { EXCLUDE-OPTS } }'
+ Expect the test executable to return a nonzero exit status if the
+ conditions (which are the same as for `dg-skip-if') are met.
+
+`{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
+ This DejaGnu directive appears on a source line that is expected
+ to get an error message, or else specifies the source line
+ associated with the message. If there is no message for that line
+ or if the text of that message is not matched by REGEXP then the
+ check fails and COMMENT is included in the `FAIL' message. The
+ check does not look for the string `"error"' unless it is part of
+ REGEXP.
+
+`{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
+ This DejaGnu directive appears on a source line that is expected
+ to get a warning message, or else specifies the source line
+ associated with the message. If there is no message for that line
+ or if the text of that message is not matched by REGEXP then the
+ check fails and COMMENT is included in the `FAIL' message. The
+ check does not look for the string `"warning"' unless it is part
+ of REGEXP.
+
+`{ dg-message REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
+ The line is expected to get a message other than an error or
+ warning. If there is no message for that line or if the text of
+ that message is not matched by REGEXP then the check fails and
+ COMMENT is included in the `FAIL' message.
+
+`{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
+ This DejaGnu directive appears on a source line that should not
+ get a message matching REGEXP, or else specifies the source line
+ associated with the bogus message. It is usually used with `xfail'
+ to indicate that the message is a known problem for a particular
+ set of targets.
+
+`{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }'
+ This DejaGnu directive indicates that the test is expected to fail
+ due to compiler messages that are not handled by `dg-error',
+ `dg-warning' or `dg-bogus'. For this directive `xfail' has the
+ same effect as `target'.
+
+`{ dg-output REGEXP [{ target/xfail SELECTOR }] }'
+ This DejaGnu directive compares REGEXP to the combined output that
+ the test executable writes to `stdout' and `stderr'.
+
+`{ dg-prune-output REGEXP }'
+ Prune messages matching REGEXP from test output.
+
+`{ dg-additional-files "FILELIST" }'
+ Specify additional files, other than source files, that must be
+ copied to the system where the compiler runs.
+
+`{ dg-additional-sources "FILELIST" }'
+ Specify additional source files to appear in the compile line
+ following the main test file.
+
+`{ dg-final { LOCAL-DIRECTIVE } }'
+ This DejaGnu directive is placed within a comment anywhere in the
+ source file and is processed after the test has been compiled and
+ run. Multiple `dg-final' commands are processed in the order in
+ which they appear in the source file.
+
+ The GCC testsuite defines the following directives to be used
+ within `dg-final'.
+
+ `cleanup-coverage-files'
+ Removes coverage data files generated for this test.
+
+ `cleanup-repo-files'
+ Removes files generated for this test for `-frepo'.
+
+ `cleanup-rtl-dump SUFFIX'
+ Removes RTL dump files generated for this test.
+
+ `cleanup-tree-dump SUFFIX'
+ Removes tree dump files matching SUFFIX which were generated
+ for this test.
+
+ `cleanup-saved-temps'
+ Removes files for the current test which were kept for
+ `--save-temps'.
+
+ `scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]'
+ Passes if REGEXP matches text in FILENAME.
+
+ `scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]'
+ Passes if REGEXP does not match text in FILENAME.
+
+ `scan-hidden SYMBOL [{ target/xfail SELECTOR }]'
+ Passes if SYMBOL is defined as a hidden symbol in the test's
+ assembly output.
+
+ `scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]'
+ Passes if SYMBOL is not defined as a hidden symbol in the
+ test's assembly output.
+
+ `scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]'
+ Passes if REGEX is matched exactly NUM times in the test's
+ assembler output.
+
+ `scan-assembler REGEX [{ target/xfail SELECTOR }]'
+ Passes if REGEX matches text in the test's assembler output.
+
+ `scan-assembler-not REGEX [{ target/xfail SELECTOR }]'
+ Passes if REGEX does not match text in the test's assembler
+ output.
+
+ `scan-assembler-dem REGEX [{ target/xfail SELECTOR }]'
+ Passes if REGEX matches text in the test's demangled
+ assembler output.
+
+ `scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]'
+ Passes if REGEX does not match text in the test's demangled
+ assembler output.
+
+ `scan-tree-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]'
+ Passes if REGEX is found exactly NUM times in the dump file
+ with suffix SUFFIX.
+
+ `scan-tree-dump REGEX SUFFIX [{ target/xfail SELECTOR }]'
+ Passes if REGEX matches text in the dump file with suffix
+ SUFFIX.
+
+ `scan-tree-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]'
+ Passes if REGEX does not match text in the dump file with
+ suffix SUFFIX.
+
+ `scan-tree-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]'
+ Passes if REGEX matches demangled text in the dump file with
+ suffix SUFFIX.
+
+ `scan-tree-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]'
+ Passes if REGEX does not match demangled text in the dump
+ file with suffix SUFFIX.
+
+ `output-exists [{ target/xfail SELECTOR }]'
+ Passes if compiler output file exists.
+
+ `output-exists-not [{ target/xfail SELECTOR }]'
+ Passes if compiler output file does not exist.
+
+ `run-gcov SOURCEFILE'
+ Check line counts in `gcov' tests.
+
+ `run-gcov [branches] [calls] { OPTS SOURCEFILE }'
+ Check branch and/or call counts, in addition to line counts,
+ in `gcov' tests.
+
+\1f
+File: gccint.info, Node: Ada Tests, Next: C Tests, Prev: Test Directives, Up: Testsuites
+
+6.4.3 Ada Language Testsuites
+-----------------------------
+
+The Ada testsuite includes executable tests from the ACATS 2.5
+testsuite, publicly available at
+`http://www.adaic.org/compilers/acats/2.5'
+
+ These tests are integrated in the GCC testsuite in the
+`gcc/testsuite/ada/acats' directory, and enabled automatically when
+running `make check', assuming the Ada language has been enabled when
+configuring GCC.
+
+ You can also run the Ada testsuite independently, using `make
+check-ada', or run a subset of the tests by specifying which chapter to
+run, e.g.:
+
+ $ make check-ada CHAPTERS="c3 c9"
+
+ The tests are organized by directory, each directory corresponding to
+a chapter of the Ada Reference Manual. So for example, c9 corresponds
+to chapter 9, which deals with tasking features of the language.
+
+ There is also an extra chapter called `gcc' containing a template for
+creating new executable tests.
+
+ The tests are run using two `sh' scripts: `run_acats' and
+`run_all.sh'. To run the tests using a simulator or a cross target,
+see the small customization section at the top of `run_all.sh'.
+
+ These tests are run using the build tree: they can be run without doing
+a `make install'.
+
+\1f
+File: gccint.info, Node: C Tests, Next: libgcj Tests, Prev: Ada Tests, Up: Testsuites
+
+6.4.4 C Language Testsuites
+---------------------------
+
+GCC contains the following C language testsuites, in the
+`gcc/testsuite' directory:
+
+`gcc.dg'
+ This contains tests of particular features of the C compiler,
+ using the more modern `dg' harness. Correctness tests for various
+ compiler features should go here if possible.
+
+ Magic comments determine whether the file is preprocessed,
+ compiled, linked or run. In these tests, error and warning
+ message texts are compared against expected texts or regular
+ expressions given in comments. These tests are run with the
+ options `-ansi -pedantic' unless other options are given in the
+ test. Except as noted below they are not run with multiple
+ optimization options.
+
+`gcc.dg/compat'
+ This subdirectory contains tests for binary compatibility using
+ `compat.exp', which in turn uses the language-independent support
+ (*note Support for testing binary compatibility: compat Testing.).
+
+`gcc.dg/cpp'
+ This subdirectory contains tests of the preprocessor.
+
+`gcc.dg/debug'
+ This subdirectory contains tests for debug formats. Tests in this
+ subdirectory are run for each debug format that the compiler
+ supports.
+
+`gcc.dg/format'
+ This subdirectory contains tests of the `-Wformat' format
+ checking. Tests in this directory are run with and without
+ `-DWIDE'.
+
+`gcc.dg/noncompile'
+ This subdirectory contains tests of code that should not compile
+ and does not need any special compilation options. They are run
+ with multiple optimization options, since sometimes invalid code
+ crashes the compiler with optimization.
+
+`gcc.dg/special'
+ FIXME: describe this.
+
+`gcc.c-torture'
+ This contains particular code fragments which have historically
+ broken easily. These tests are run with multiple optimization
+ options, so tests for features which only break at some
+ optimization levels belong here. This also contains tests to
+ check that certain optimizations occur. It might be worthwhile to
+ separate the correctness tests cleanly from the code quality
+ tests, but it hasn't been done yet.
+
+`gcc.c-torture/compat'
+ FIXME: describe this.
+
+ This directory should probably not be used for new tests.
+
+`gcc.c-torture/compile'
+ This testsuite contains test cases that should compile, but do not
+ need to link or run. These test cases are compiled with several
+ different combinations of optimization options. All warnings are
+ disabled for these test cases, so this directory is not suitable if
+ you wish to test for the presence or absence of compiler warnings.
+ While special options can be set, and tests disabled on specific
+ platforms, by the use of `.x' files, mostly these test cases
+ should not contain platform dependencies. FIXME: discuss how
+ defines such as `NO_LABEL_VALUES' and `STACK_SIZE' are used.
+
+`gcc.c-torture/execute'
+ This testsuite contains test cases that should compile, link and
+ run; otherwise the same comments as for `gcc.c-torture/compile'
+ apply.
+
+`gcc.c-torture/execute/ieee'
+ This contains tests which are specific to IEEE floating point.
+
+`gcc.c-torture/unsorted'
+ FIXME: describe this.
+
+ This directory should probably not be used for new tests.
+
+`gcc.c-torture/misc-tests'
+ This directory contains C tests that require special handling.
+ Some of these tests have individual expect files, and others share
+ special-purpose expect files:
+
+ ``bprob*.c''
+ Test `-fbranch-probabilities' using `bprob.exp', which in
+ turn uses the generic, language-independent framework (*note
+ Support for testing profile-directed optimizations: profopt
+ Testing.).
+
+ ``dg-*.c''
+ Test the testsuite itself using `dg-test.exp'.
+
+ ``gcov*.c''
+ Test `gcov' output using `gcov.exp', which in turn uses the
+ language-independent support (*note Support for testing gcov:
+ gcov Testing.).
+
+ ``i386-pf-*.c''
+ Test i386-specific support for data prefetch using
+ `i386-prefetch.exp'.
+
+
+ FIXME: merge in `testsuite/README.gcc' and discuss the format of test
+cases and magic comments more.
+
+\1f
+File: gccint.info, Node: libgcj Tests, Next: gcov Testing, Prev: C Tests, Up: Testsuites
+
+6.4.5 The Java library testsuites.
+----------------------------------
+
+Runtime tests are executed via `make check' in the
+`TARGET/libjava/testsuite' directory in the build tree. Additional
+runtime tests can be checked into this testsuite.
+
+ Regression testing of the core packages in libgcj is also covered by
+the Mauve testsuite. The Mauve Project develops tests for the Java
+Class Libraries. These tests are run as part of libgcj testing by
+placing the Mauve tree within the libjava testsuite sources at
+`libjava/testsuite/libjava.mauve/mauve', or by specifying the location
+of that tree when invoking `make', as in `make MAUVEDIR=~/mauve check'.
+
+ To detect regressions, a mechanism in `mauve.exp' compares the
+failures for a test run against the list of expected failures in
+`libjava/testsuite/libjava.mauve/xfails' from the source hierarchy.
+Update this file when adding new failing tests to Mauve, or when fixing
+bugs in libgcj that had caused Mauve test failures.
+
+ We encourage developers to contribute test cases to Mauve.
+
+\1f
+File: gccint.info, Node: gcov Testing, Next: profopt Testing, Prev: libgcj Tests, Up: Testsuites
+
+6.4.6 Support for testing `gcov'
+--------------------------------
+
+Language-independent support for testing `gcov', and for checking that
+branch profiling produces expected values, is provided by the expect
+file `gcov.exp'. `gcov' tests also rely on procedures in `gcc.dg.exp'
+to compile and run the test program. A typical `gcov' test contains
+the following DejaGnu commands within comments:
+
+ { dg-options "-fprofile-arcs -ftest-coverage" }
+ { dg-do run { target native } }
+ { dg-final { run-gcov sourcefile } }
+
+ Checks of `gcov' output can include line counts, branch percentages,
+and call return percentages. All of these checks are requested via
+commands that appear in comments in the test's source file. Commands
+to check line counts are processed by default. Commands to check
+branch percentages and call return percentages are processed if the
+`run-gcov' command has arguments `branches' or `calls', respectively.
+For example, the following specifies checking both, as well as passing
+`-b' to `gcov':
+
+ { dg-final { run-gcov branches calls { -b sourcefile } } }
+
+ A line count command appears within a comment on the source line that
+is expected to get the specified count and has the form `count(CNT)'.
+A test should only check line counts for lines that will get the same
+count for any architecture.
+
+ Commands to check branch percentages (`branch') and call return
+percentages (`returns') are very similar to each other. A beginning
+command appears on or before the first of a range of lines that will
+report the percentage, and the ending command follows that range of
+lines. The beginning command can include a list of percentages, all of
+which are expected to be found within the range. A range is terminated
+by the next command of the same kind. A command `branch(end)' or
+`returns(end)' marks the end of a range without starting a new one.
+For example:
+
+ if (i > 10 && j > i && j < 20) /* branch(27 50 75) */
+ /* branch(end) */
+ foo (i, j);
+
+ For a call return percentage, the value specified is the percentage of
+calls reported to return. For a branch percentage, the value is either
+the expected percentage or 100 minus that value, since the direction of
+a branch can differ depending on the target or the optimization level.
+
+ Not all branches and calls need to be checked. A test should not
+check for branches that might be optimized away or replaced with
+predicated instructions. Don't check for calls inserted by the
+compiler or ones that might be inlined or optimized away.
+
+ A single test can check for combinations of line counts, branch
+percentages, and call return percentages. The command to check a line
+count must appear on the line that will report that count, but commands
+to check branch percentages and call return percentages can bracket the
+lines that report them.
+
+\1f
+File: gccint.info, Node: profopt Testing, Next: compat Testing, Prev: gcov Testing, Up: Testsuites
+
+6.4.7 Support for testing profile-directed optimizations
+--------------------------------------------------------
+
+The file `profopt.exp' provides language-independent support for
+checking correct execution of a test built with profile-directed
+optimization. This testing requires that a test program be built and
+executed twice. The first time it is compiled to generate profile
+data, and the second time it is compiled to use the data that was
+generated during the first execution. The second execution is to
+verify that the test produces the expected results.
+
+ To check that the optimization actually generated better code, a test
+can be built and run a third time with normal optimizations to verify
+that the performance is better with the profile-directed optimizations.
+`profopt.exp' has the beginnings of this kind of support.
+
+ `profopt.exp' provides generic support for profile-directed
+optimizations. Each set of tests that uses it provides information
+about a specific optimization:
+
+`tool'
+ tool being tested, e.g., `gcc'
+
+`profile_option'
+ options used to generate profile data
+
+`feedback_option'
+ options used to optimize using that profile data
+
+`prof_ext'
+ suffix of profile data files
+
+`PROFOPT_OPTIONS'
+ list of options with which to run each test, similar to the lists
+ for torture tests
+
+\1f
+File: gccint.info, Node: compat Testing, Next: Torture Tests, Prev: profopt Testing, Up: Testsuites
+
+6.4.8 Support for testing binary compatibility
+----------------------------------------------
+
+The file `compat.exp' provides language-independent support for binary
+compatibility testing. It supports testing interoperability of two
+compilers that follow the same ABI, or of multiple sets of compiler
+options that should not affect binary compatibility. It is intended to
+be used for testsuites that complement ABI testsuites.
+
+ A test supported by this framework has three parts, each in a separate
+source file: a main program and two pieces that interact with each
+other to split up the functionality being tested.
+
+`TESTNAME_main.SUFFIX'
+ Contains the main program, which calls a function in file
+ `TESTNAME_x.SUFFIX'.
+
+`TESTNAME_x.SUFFIX'
+ Contains at least one call to a function in `TESTNAME_y.SUFFIX'.
+
+`TESTNAME_y.SUFFIX'
+ Shares data with, or gets arguments from, `TESTNAME_x.SUFFIX'.
+
+ Within each test, the main program and one functional piece are
+compiled by the GCC under test. The other piece can be compiled by an
+alternate compiler. If no alternate compiler is specified, then all
+three source files are all compiled by the GCC under test. You can
+specify pairs of sets of compiler options. The first element of such a
+pair specifies options used with the GCC under test, and the second
+element of the pair specifies options used with the alternate compiler.
+Each test is compiled with each pair of options.
+
+ `compat.exp' defines default pairs of compiler options. These can be
+overridden by defining the environment variable `COMPAT_OPTIONS' as:
+
+ COMPAT_OPTIONS="[list [list {TST1} {ALT1}]
+ ...[list {TSTN} {ALTN}]]"
+
+ where TSTI and ALTI are lists of options, with TSTI used by the
+compiler under test and ALTI used by the alternate compiler. For
+example, with `[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]',
+the test is first built with `-g -O0' by the compiler under test and
+with `-O3' by the alternate compiler. The test is built a second time
+using `-fpic' by the compiler under test and `-fPIC -O2' by the
+alternate compiler.
+
+ An alternate compiler is specified by defining an environment variable
+to be the full pathname of an installed compiler; for C define
+`ALT_CC_UNDER_TEST', and for C++ define `ALT_CXX_UNDER_TEST'. These
+will be written to the `site.exp' file used by DejaGnu. The default is
+to build each test with the compiler under test using the first of each
+pair of compiler options from `COMPAT_OPTIONS'. When
+`ALT_CC_UNDER_TEST' or `ALT_CXX_UNDER_TEST' is `same', each test is
+built using the compiler under test but with combinations of the
+options from `COMPAT_OPTIONS'.
+
+ To run only the C++ compatibility suite using the compiler under test
+and another version of GCC using specific compiler options, do the
+following from `OBJDIR/gcc':
+
+ rm site.exp
+ make -k \
+ ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \
+ COMPAT_OPTIONS="lists as shown above" \
+ check-c++ \
+ RUNTESTFLAGS="compat.exp"
+
+ A test that fails when the source files are compiled with different
+compilers, but passes when the files are compiled with the same
+compiler, demonstrates incompatibility of the generated code or runtime
+support. A test that fails for the alternate compiler but passes for
+the compiler under test probably tests for a bug that was fixed in the
+compiler under test but is present in the alternate compiler.
+
+ The binary compatibility tests support a small number of test framework
+commands that appear within comments in a test file.
+
+`dg-require-*'
+ These commands can be used in `TESTNAME_main.SUFFIX' to skip the
+ test if specific support is not available on the target.
+
+`dg-options'
+ The specified options are used for compiling this particular source
+ file, appended to the options from `COMPAT_OPTIONS'. When this
+ command appears in `TESTNAME_main.SUFFIX' the options are also
+ used to link the test program.
+
+`dg-xfail-if'
+ This command can be used in a secondary source file to specify that
+ compilation is expected to fail for particular options on
+ particular targets.
+
+\1f
+File: gccint.info, Node: Torture Tests, Prev: compat Testing, Up: Testsuites
+
+6.4.9 Support for torture testing using multiple options
+--------------------------------------------------------
+
+Throughout the compiler testsuite there are several directories whose
+tests are run multiple times, each with a different set of options.
+These are known as torture tests.
+`gcc/testsuite/lib/torture-options.exp' defines procedures to set up
+these lists:
+
+`torture-init'
+ Initialize use of torture lists.
+
+`set-torture-options'
+ Set lists of torture options to use for tests with and without
+ loops. Optionally combine a set of torture options with a set of
+ other options, as is done with Objective-C runtime options.
+
+`torture-finish'
+ Finalize use of torture lists.
+
+ The `.exp' file for a set of tests that use torture options must
+include calls to these three procedures if:
+
+ * It calls `gcc-dg-runtest' and overrides DG_TORTURE_OPTIONS.
+
+ * It calls ${TOOL}`-torture' or ${TOOL}`-torture-execute', where
+ TOOL is `c', `fortran', or `objc'.
+
+ * It calls `dg-pch'.
+
+ It is not necessary for a `.exp' file that calls `gcc-dg-runtest' to
+call the torture procedures if the tests should use the list in
+DG_TORTURE_OPTIONS defined in `gcc-dg.exp'.
+
+ Most uses of torture options can override the default lists by defining
+TORTURE_OPTIONS or add to the default list by defining
+ADDITIONAL_TORTURE_OPTIONS. Define these in a `.dejagnurc' file or add
+them to the `site.exp' file; for example
+
+ set ADDITIONAL_TORTURE_OPTIONS [list \
+ { -O2 -ftree-loop-linear } \
+ { -O2 -fpeel-loops } ]
+
+\1f
+File: gccint.info, Node: Options, Next: Passes, Prev: Source Tree, Up: Top
+
+7 Option specification files
+****************************
+
+Most GCC command-line options are described by special option
+definition files, the names of which conventionally end in `.opt'.
+This chapter describes the format of these files.
+
+* Menu:
+
+* Option file format:: The general layout of the files
+* Option properties:: Supported option properties
+
+\1f
+File: gccint.info, Node: Option file format, Next: Option properties, Up: Options
+
+7.1 Option file format
+======================
+
+Option files are a simple list of records in which each field occupies
+its own line and in which the records themselves are separated by blank
+lines. Comments may appear on their own line anywhere within the file
+and are preceded by semicolons. Whitespace is allowed before the
+semicolon.
+
+ The files can contain the following types of record:
+
+ * A language definition record. These records have two fields: the
+ string `Language' and the name of the language. Once a language
+ has been declared in this way, it can be used as an option
+ property. *Note Option properties::.
+
+ * A target specific save record to save additional information. These
+ records have two fields: the string `TargetSave', and a
+ declaration type to go in the `cl_target_option' structure.
+
+ * An option definition record. These records have the following
+ fields:
+ 1. the name of the option, with the leading "-" removed
+
+ 2. a space-separated list of option properties (*note Option
+ properties::)
+
+ 3. the help text to use for `--help' (omitted if the second field
+ contains the `Undocumented' property).
+
+ By default, all options beginning with "f", "W" or "m" are
+ implicitly assumed to take a "no-" form. This form should not be
+ listed separately. If an option beginning with one of these
+ letters does not have a "no-" form, you can use the
+ `RejectNegative' property to reject it.
+
+ The help text is automatically line-wrapped before being displayed.
+ Normally the name of the option is printed on the left-hand side of
+ the output and the help text is printed on the right. However, if
+ the help text contains a tab character, the text to the left of
+ the tab is used instead of the option's name and the text to the
+ right of the tab forms the help text. This allows you to
+ elaborate on what type of argument the option takes.
+
+ * A target mask record. These records have one field of the form
+ `Mask(X)'. The options-processing script will automatically
+ allocate a bit in `target_flags' (*note Run-time Target::) for
+ each mask name X and set the macro `MASK_X' to the appropriate
+ bitmask. It will also declare a `TARGET_X' macro that has the
+ value 1 when bit `MASK_X' is set and 0 otherwise.
+
+ They are primarily intended to declare target masks that are not
+ associated with user options, either because these masks represent
+ internal switches or because the options are not available on all
+ configurations and yet the masks always need to be defined.
+
+\1f
+File: gccint.info, Node: Option properties, Prev: Option file format, Up: Options
+
+7.2 Option properties
+=====================
+
+The second field of an option record can specify the following
+properties:
+
+`Common'
+ The option is available for all languages and targets.
+
+`Target'
+ The option is available for all languages but is target-specific.
+
+`LANGUAGE'
+ The option is available when compiling for the given language.
+
+ It is possible to specify several different languages for the same
+ option. Each LANGUAGE must have been declared by an earlier
+ `Language' record. *Note Option file format::.
+
+`RejectNegative'
+ The option does not have a "no-" form. All options beginning with
+ "f", "W" or "m" are assumed to have a "no-" form unless this
+ property is used.
+
+`Negative(OTHERNAME)'
+ The option will turn off another option OTHERNAME, which is the
+ the option name with the leading "-" removed. This chain action
+ will propagate through the `Negative' property of the option to be
+ turned off.
+
+`Joined'
+`Separate'
+ The option takes a mandatory argument. `Joined' indicates that
+ the option and argument can be included in the same `argv' entry
+ (as with `-mflush-func=NAME', for example). `Separate' indicates
+ that the option and argument can be separate `argv' entries (as
+ with `-o'). An option is allowed to have both of these properties.
+
+`JoinedOrMissing'
+ The option takes an optional argument. If the argument is given,
+ it will be part of the same `argv' entry as the option itself.
+
+ This property cannot be used alongside `Joined' or `Separate'.
+
+`UInteger'
+ The option's argument is a non-negative integer. The option parser
+ will check and convert the argument before passing it to the
+ relevant option handler. `UInteger' should also be used on
+ options like `-falign-loops' where both `-falign-loops' and
+ `-falign-loops'=N are supported to make sure the saved options are
+ given a full integer.
+
+`Var(VAR)'
+ The state of this option should be stored in variable VAR. The
+ way that the state is stored depends on the type of option:
+
+ * If the option uses the `Mask' or `InverseMask' properties,
+ VAR is the integer variable that contains the mask.
+
+ * If the option is a normal on/off switch, VAR is an integer
+ variable that is nonzero when the option is enabled. The
+ options parser will set the variable to 1 when the positive
+ form of the option is used and 0 when the "no-" form is used.
+
+ * If the option takes an argument and has the `UInteger'
+ property, VAR is an integer variable that stores the value of
+ the argument.
+
+ * Otherwise, if the option takes an argument, VAR is a pointer
+ to the argument string. The pointer will be null if the
+ argument is optional and wasn't given.
+
+ The option-processing script will usually declare VAR in
+ `options.c' and leave it to be zero-initialized at start-up time.
+ You can modify this behavior using `VarExists' and `Init'.
+
+`Var(VAR, SET)'
+ The option controls an integer variable VAR and is active when VAR
+ equals SET. The option parser will set VAR to SET when the
+ positive form of the option is used and `!SET' when the "no-" form
+ is used.
+
+ VAR is declared in the same way as for the single-argument form
+ described above.
+
+`VarExists'
+ The variable specified by the `Var' property already exists. No
+ definition should be added to `options.c' in response to this
+ option record.
+
+ You should use this property only if the variable is declared
+ outside `options.c'.
+
+`Init(VALUE)'
+ The variable specified by the `Var' property should be statically
+ initialized to VALUE.
+
+`Mask(NAME)'
+ The option is associated with a bit in the `target_flags' variable
+ (*note Run-time Target::) and is active when that bit is set. You
+ may also specify `Var' to select a variable other than
+ `target_flags'.
+
+ The options-processing script will automatically allocate a unique
+ bit for the option. If the option is attached to `target_flags',
+ the script will set the macro `MASK_NAME' to the appropriate
+ bitmask. It will also declare a `TARGET_NAME' macro that has the
+ value 1 when the option is active and 0 otherwise. If you use
+ `Var' to attach the option to a different variable, the associated
+ macros are called `OPTION_MASK_NAME' and `OPTION_NAME'
+ respectively.
+
+ You can disable automatic bit allocation using `MaskExists'.
+
+`InverseMask(OTHERNAME)'
+`InverseMask(OTHERNAME, THISNAME)'
+ The option is the inverse of another option that has the
+ `Mask(OTHERNAME)' property. If THISNAME is given, the
+ options-processing script will declare a `TARGET_THISNAME' macro
+ that is 1 when the option is active and 0 otherwise.
+
+`MaskExists'
+ The mask specified by the `Mask' property already exists. No
+ `MASK' or `TARGET' definitions should be added to `options.h' in
+ response to this option record.
+
+ The main purpose of this property is to support synonymous options.
+ The first option should use `Mask(NAME)' and the others should use
+ `Mask(NAME) MaskExists'.
+
+`Report'
+ The state of the option should be printed by `-fverbose-asm'.
+
+`Undocumented'
+ The option is deliberately missing documentation and should not be
+ included in the `--help' output.
+
+`Condition(COND)'
+ The option should only be accepted if preprocessor condition COND
+ is true. Note that any C declarations associated with the option
+ will be present even if COND is false; COND simply controls
+ whether the option is accepted and whether it is printed in the
+ `--help' output.
+
+`Save'
+ Build the `cl_target_option' structure to hold a copy of the
+ option, add the functions `cl_target_option_save' and
+ `cl_target_option_restore' to save and restore the options.
+
+\1f
+File: gccint.info, Node: Passes, Next: Trees, Prev: Options, Up: Top
+
+8 Passes and Files of the Compiler
+**********************************
+
+This chapter is dedicated to giving an overview of the optimization and
+code generation passes of the compiler. In the process, it describes
+some of the language front end interface, though this description is no
+where near complete.
+
+* Menu:
+
+* Parsing pass:: The language front end turns text into bits.
+* Gimplification pass:: The bits are turned into something we can optimize.
+* Pass manager:: Sequencing the optimization passes.
+* Tree SSA passes:: Optimizations on a high-level representation.
+* RTL passes:: Optimizations on a low-level representation.
+
+\1f
+File: gccint.info, Node: Parsing pass, Next: Gimplification pass, Up: Passes
+
+8.1 Parsing pass
+================
+
+The language front end is invoked only once, via
+`lang_hooks.parse_file', to parse the entire input. The language front
+end may use any intermediate language representation deemed
+appropriate. The C front end uses GENERIC trees (CROSSREF), plus a
+double handful of language specific tree codes defined in
+`c-common.def'. The Fortran front end uses a completely different
+private representation.
+
+ At some point the front end must translate the representation used in
+the front end to a representation understood by the language-independent
+portions of the compiler. Current practice takes one of two forms.
+The C front end manually invokes the gimplifier (CROSSREF) on each
+function, and uses the gimplifier callbacks to convert the
+language-specific tree nodes directly to GIMPLE (CROSSREF) before
+passing the function off to be compiled. The Fortran front end
+converts from a private representation to GENERIC, which is later
+lowered to GIMPLE when the function is compiled. Which route to choose
+probably depends on how well GENERIC (plus extensions) can be made to
+match up with the source language and necessary parsing data structures.
+
+ BUG: Gimplification must occur before nested function lowering, and
+nested function lowering must be done by the front end before passing
+the data off to cgraph.
+
+ TODO: Cgraph should control nested function lowering. It would only
+be invoked when it is certain that the outer-most function is used.
+
+ TODO: Cgraph needs a gimplify_function callback. It should be invoked
+when (1) it is certain that the function is used, (2) warning flags
+specified by the user require some amount of compilation in order to
+honor, (3) the language indicates that semantic analysis is not
+complete until gimplification occurs. Hum... this sounds overly
+complicated. Perhaps we should just have the front end gimplify
+always; in most cases it's only one function call.
+
+ The front end needs to pass all function definitions and top level
+declarations off to the middle-end so that they can be compiled and
+emitted to the object file. For a simple procedural language, it is
+usually most convenient to do this as each top level declaration or
+definition is seen. There is also a distinction to be made between
+generating functional code and generating complete debug information.
+The only thing that is absolutely required for functional code is that
+function and data _definitions_ be passed to the middle-end. For
+complete debug information, function, data and type declarations should
+all be passed as well.
+
+ In any case, the front end needs each complete top-level function or
+data declaration, and each data definition should be passed to
+`rest_of_decl_compilation'. Each complete type definition should be
+passed to `rest_of_type_compilation'. Each function definition should
+be passed to `cgraph_finalize_function'.
+
+ TODO: I know rest_of_compilation currently has all sorts of RTL
+generation semantics. I plan to move all code generation bits (both
+Tree and RTL) to compile_function. Should we hide cgraph from the
+front ends and move back to rest_of_compilation as the official
+interface? Possibly we should rename all three interfaces such that
+the names match in some meaningful way and that is more descriptive
+than "rest_of".
+
+ The middle-end will, at its option, emit the function and data
+definitions immediately or queue them for later processing.
+
+\1f
+File: gccint.info, Node: Gimplification pass, Next: Pass manager, Prev: Parsing pass, Up: Passes
+
+8.2 Gimplification pass
+=======================
+
+"Gimplification" is a whimsical term for the process of converting the
+intermediate representation of a function into the GIMPLE language
+(CROSSREF). The term stuck, and so words like "gimplification",
+"gimplify", "gimplifier" and the like are sprinkled throughout this
+section of code.
+
+ While a front end may certainly choose to generate GIMPLE directly if
+it chooses, this can be a moderately complex process unless the
+intermediate language used by the front end is already fairly simple.
+Usually it is easier to generate GENERIC trees plus extensions and let
+the language-independent gimplifier do most of the work.
+
+ The main entry point to this pass is `gimplify_function_tree' located
+in `gimplify.c'. From here we process the entire function gimplifying
+each statement in turn. The main workhorse for this pass is
+`gimplify_expr'. Approximately everything passes through here at least
+once, and it is from here that we invoke the `lang_hooks.gimplify_expr'
+callback.
+
+ The callback should examine the expression in question and return
+`GS_UNHANDLED' if the expression is not a language specific construct
+that requires attention. Otherwise it should alter the expression in
+some way to such that forward progress is made toward producing valid
+GIMPLE. If the callback is certain that the transformation is complete
+and the expression is valid GIMPLE, it should return `GS_ALL_DONE'.
+Otherwise it should return `GS_OK', which will cause the expression to
+be processed again. If the callback encounters an error during the
+transformation (because the front end is relying on the gimplification
+process to finish semantic checks), it should return `GS_ERROR'.
+
+\1f
+File: gccint.info, Node: Pass manager, Next: Tree SSA passes, Prev: Gimplification pass, Up: Passes
+
+8.3 Pass manager
+================
+
+The pass manager is located in `passes.c', `tree-optimize.c' and
+`tree-pass.h'. Its job is to run all of the individual passes in the
+correct order, and take care of standard bookkeeping that applies to
+every pass.
+
+ The theory of operation is that each pass defines a structure that
+represents everything we need to know about that pass--when it should
+be run, how it should be run, what intermediate language form or
+on-the-side data structures it needs. We register the pass to be run
+in some particular order, and the pass manager arranges for everything
+to happen in the correct order.
+
+ The actuality doesn't completely live up to the theory at present.
+Command-line switches and `timevar_id_t' enumerations must still be
+defined elsewhere. The pass manager validates constraints but does not
+attempt to (re-)generate data structures or lower intermediate language
+form based on the requirements of the next pass. Nevertheless, what is
+present is useful, and a far sight better than nothing at all.
+
+ Each pass may have its own dump file (for GCC debugging purposes).
+Passes without any names, or with a name starting with a star, do not
+dump anything.
+
+ TODO: describe the global variables set up by the pass manager, and a
+brief description of how a new pass should use it. I need to look at
+what info RTL passes use first...
+
+\1f
+File: gccint.info, Node: Tree SSA passes, Next: RTL passes, Prev: Pass manager, Up: Passes
+
+8.4 Tree SSA passes
+===================
+
+The following briefly describes the Tree optimization passes that are
+run after gimplification and what source files they are located in.
+
+ * Remove useless statements
+
+ This pass is an extremely simple sweep across the gimple code in
+ which we identify obviously dead code and remove it. Here we do
+ things like simplify `if' statements with constant conditions,
+ remove exception handling constructs surrounding code that
+ obviously cannot throw, remove lexical bindings that contain no
+ variables, and other assorted simplistic cleanups. The idea is to
+ get rid of the obvious stuff quickly rather than wait until later
+ when it's more work to get rid of it. This pass is located in
+ `tree-cfg.c' and described by `pass_remove_useless_stmts'.
+
+ * Mudflap declaration registration
+
+ If mudflap (*note -fmudflap -fmudflapth -fmudflapir: (gcc)Optimize
+ Options.) is enabled, we generate code to register some variable
+ declarations with the mudflap runtime. Specifically, the runtime
+ tracks the lifetimes of those variable declarations that have
+ their addresses taken, or whose bounds are unknown at compile time
+ (`extern'). This pass generates new exception handling constructs
+ (`try'/`finally'), and so must run before those are lowered. In
+ addition, the pass enqueues declarations of static variables whose
+ lifetimes extend to the entire program. The pass is located in
+ `tree-mudflap.c' and is described by `pass_mudflap_1'.
+
+ * OpenMP lowering
+
+ If OpenMP generation (`-fopenmp') is enabled, this pass lowers
+ OpenMP constructs into GIMPLE.
+
+ Lowering of OpenMP constructs involves creating replacement
+ expressions for local variables that have been mapped using data
+ sharing clauses, exposing the control flow of most synchronization
+ directives and adding region markers to facilitate the creation of
+ the control flow graph. The pass is located in `omp-low.c' and is
+ described by `pass_lower_omp'.
+
+ * OpenMP expansion
+
+ If OpenMP generation (`-fopenmp') is enabled, this pass expands
+ parallel regions into their own functions to be invoked by the
+ thread library. The pass is located in `omp-low.c' and is
+ described by `pass_expand_omp'.
+
+ * Lower control flow
+
+ This pass flattens `if' statements (`COND_EXPR') and moves lexical
+ bindings (`BIND_EXPR') out of line. After this pass, all `if'
+ statements will have exactly two `goto' statements in its `then'
+ and `else' arms. Lexical binding information for each statement
+ will be found in `TREE_BLOCK' rather than being inferred from its
+ position under a `BIND_EXPR'. This pass is found in
+ `gimple-low.c' and is described by `pass_lower_cf'.
+
+ * Lower exception handling control flow
+
+ This pass decomposes high-level exception handling constructs
+ (`TRY_FINALLY_EXPR' and `TRY_CATCH_EXPR') into a form that
+ explicitly represents the control flow involved. After this pass,
+ `lookup_stmt_eh_region' will return a non-negative number for any
+ statement that may have EH control flow semantics; examine
+ `tree_can_throw_internal' or `tree_can_throw_external' for exact
+ semantics. Exact control flow may be extracted from
+ `foreach_reachable_handler'. The EH region nesting tree is defined
+ in `except.h' and built in `except.c'. The lowering pass itself
+ is in `tree-eh.c' and is described by `pass_lower_eh'.
+
+ * Build the control flow graph
+
+ This pass decomposes a function into basic blocks and creates all
+ of the edges that connect them. It is located in `tree-cfg.c' and
+ is described by `pass_build_cfg'.
+
+ * Find all referenced variables
+
+ This pass walks the entire function and collects an array of all
+ variables referenced in the function, `referenced_vars'. The
+ index at which a variable is found in the array is used as a UID
+ for the variable within this function. This data is needed by the
+ SSA rewriting routines. The pass is located in `tree-dfa.c' and
+ is described by `pass_referenced_vars'.
+
+ * Enter static single assignment form
+
+ This pass rewrites the function such that it is in SSA form. After
+ this pass, all `is_gimple_reg' variables will be referenced by
+ `SSA_NAME', and all occurrences of other variables will be
+ annotated with `VDEFS' and `VUSES'; PHI nodes will have been
+ inserted as necessary for each basic block. This pass is located
+ in `tree-ssa.c' and is described by `pass_build_ssa'.
+
+ * Warn for uninitialized variables
+
+ This pass scans the function for uses of `SSA_NAME's that are fed
+ by default definition. For non-parameter variables, such uses are
+ uninitialized. The pass is run twice, before and after
+ optimization (if turned on). In the first pass we only warn for
+ uses that are positively uninitialized; in the second pass we warn
+ for uses that are possibly uninitialized. The pass is located in
+ `tree-ssa.c' and is defined by `pass_early_warn_uninitialized' and
+ `pass_late_warn_uninitialized'.
+
+ * Dead code elimination
+
+ This pass scans the function for statements without side effects
+ whose result is unused. It does not do memory life analysis, so
+ any value that is stored in memory is considered used. The pass
+ is run multiple times throughout the optimization process. It is
+ located in `tree-ssa-dce.c' and is described by `pass_dce'.
+
+ * Dominator optimizations
+
+ This pass performs trivial dominator-based copy and constant
+ propagation, expression simplification, and jump threading. It is
+ run multiple times throughout the optimization process. It it
+ located in `tree-ssa-dom.c' and is described by `pass_dominator'.
+
+ * Forward propagation of single-use variables
+
+ This pass attempts to remove redundant computation by substituting
+ variables that are used once into the expression that uses them and
+ seeing if the result can be simplified. It is located in
+ `tree-ssa-forwprop.c' and is described by `pass_forwprop'.
+
+ * Copy Renaming
+
+ This pass attempts to change the name of compiler temporaries
+ involved in copy operations such that SSA->normal can coalesce the
+ copy away. When compiler temporaries are copies of user
+ variables, it also renames the compiler temporary to the user
+ variable resulting in better use of user symbols. It is located
+ in `tree-ssa-copyrename.c' and is described by `pass_copyrename'.
+
+ * PHI node optimizations
+
+ This pass recognizes forms of PHI inputs that can be represented as
+ conditional expressions and rewrites them into straight line code.
+ It is located in `tree-ssa-phiopt.c' and is described by
+ `pass_phiopt'.
+
+ * May-alias optimization
+
+ This pass performs a flow sensitive SSA-based points-to analysis.
+ The resulting may-alias, must-alias, and escape analysis
+ information is used to promote variables from in-memory
+ addressable objects to non-aliased variables that can be renamed
+ into SSA form. We also update the `VDEF'/`VUSE' memory tags for
+ non-renameable aggregates so that we get fewer false kills. The
+ pass is located in `tree-ssa-alias.c' and is described by
+ `pass_may_alias'.
+
+ Interprocedural points-to information is located in
+ `tree-ssa-structalias.c' and described by `pass_ipa_pta'.
+
+ * Profiling
+
+ This pass rewrites the function in order to collect runtime block
+ and value profiling data. Such data may be fed back into the
+ compiler on a subsequent run so as to allow optimization based on
+ expected execution frequencies. The pass is located in
+ `predict.c' and is described by `pass_profile'.
+
+ * Lower complex arithmetic
+
+ This pass rewrites complex arithmetic operations into their
+ component scalar arithmetic operations. The pass is located in
+ `tree-complex.c' and is described by `pass_lower_complex'.
+
+ * Scalar replacement of aggregates
+
+ This pass rewrites suitable non-aliased local aggregate variables
+ into a set of scalar variables. The resulting scalar variables are
+ rewritten into SSA form, which allows subsequent optimization
+ passes to do a significantly better job with them. The pass is
+ located in `tree-sra.c' and is described by `pass_sra'.
+
+ * Dead store elimination
+
+ This pass eliminates stores to memory that are subsequently
+ overwritten by another store, without any intervening loads. The
+ pass is located in `tree-ssa-dse.c' and is described by `pass_dse'.
+
+ * Tail recursion elimination
+
+ This pass transforms tail recursion into a loop. It is located in
+ `tree-tailcall.c' and is described by `pass_tail_recursion'.
+
+ * Forward store motion
+
+ This pass sinks stores and assignments down the flowgraph closer
+ to their use point. The pass is located in `tree-ssa-sink.c' and
+ is described by `pass_sink_code'.
+
+ * Partial redundancy elimination
+
+ This pass eliminates partially redundant computations, as well as
+ performing load motion. The pass is located in `tree-ssa-pre.c'
+ and is described by `pass_pre'.
+
+ Just before partial redundancy elimination, if
+ `-funsafe-math-optimizations' is on, GCC tries to convert
+ divisions to multiplications by the reciprocal. The pass is
+ located in `tree-ssa-math-opts.c' and is described by
+ `pass_cse_reciprocal'.
+
+ * Full redundancy elimination
+
+ This is a simpler form of PRE that only eliminates redundancies
+ that occur an all paths. It is located in `tree-ssa-pre.c' and
+ described by `pass_fre'.
+
+ * Loop optimization
+
+ The main driver of the pass is placed in `tree-ssa-loop.c' and
+ described by `pass_loop'.
+
+ The optimizations performed by this pass are:
+
+ Loop invariant motion. This pass moves only invariants that would
+ be hard to handle on RTL level (function calls, operations that
+ expand to nontrivial sequences of insns). With `-funswitch-loops'
+ it also moves operands of conditions that are invariant out of the
+ loop, so that we can use just trivial invariantness analysis in
+ loop unswitching. The pass also includes store motion. The pass
+ is implemented in `tree-ssa-loop-im.c'.
+
+ Canonical induction variable creation. This pass creates a simple
+ counter for number of iterations of the loop and replaces the exit
+ condition of the loop using it, in case when a complicated
+ analysis is necessary to determine the number of iterations.
+ Later optimizations then may determine the number easily. The
+ pass is implemented in `tree-ssa-loop-ivcanon.c'.
+
+ Induction variable optimizations. This pass performs standard
+ induction variable optimizations, including strength reduction,
+ induction variable merging and induction variable elimination.
+ The pass is implemented in `tree-ssa-loop-ivopts.c'.
+
+ Loop unswitching. This pass moves the conditional jumps that are
+ invariant out of the loops. To achieve this, a duplicate of the
+ loop is created for each possible outcome of conditional jump(s).
+ The pass is implemented in `tree-ssa-loop-unswitch.c'. This pass
+ should eventually replace the RTL level loop unswitching in
+ `loop-unswitch.c', but currently the RTL level pass is not
+ completely redundant yet due to deficiencies in tree level alias
+ analysis.
+
+ The optimizations also use various utility functions contained in
+ `tree-ssa-loop-manip.c', `cfgloop.c', `cfgloopanal.c' and
+ `cfgloopmanip.c'.
+
+ Vectorization. This pass transforms loops to operate on vector
+ types instead of scalar types. Data parallelism across loop
+ iterations is exploited to group data elements from consecutive
+ iterations into a vector and operate on them in parallel.
+ Depending on available target support the loop is conceptually
+ unrolled by a factor `VF' (vectorization factor), which is the
+ number of elements operated upon in parallel in each iteration,
+ and the `VF' copies of each scalar operation are fused to form a
+ vector operation. Additional loop transformations such as peeling
+ and versioning may take place to align the number of iterations,
+ and to align the memory accesses in the loop. The pass is
+ implemented in `tree-vectorizer.c' (the main driver and general
+ utilities), `tree-vect-analyze.c' and `tree-vect-transform.c'.
+ Analysis of data references is in `tree-data-ref.c'.
+
+ Autoparallelization. This pass splits the loop iteration space to
+ run into several threads. The pass is implemented in
+ `tree-parloops.c'.
+
+ * Tree level if-conversion for vectorizer
+
+ This pass applies if-conversion to simple loops to help vectorizer.
+ We identify if convertible loops, if-convert statements and merge
+ basic blocks in one big block. The idea is to present loop in such
+ form so that vectorizer can have one to one mapping between
+ statements and available vector operations. This patch
+ re-introduces COND_EXPR at GIMPLE level. This pass is located in
+ `tree-if-conv.c' and is described by `pass_if_conversion'.
+
+ * Conditional constant propagation
+
+ This pass relaxes a lattice of values in order to identify those
+ that must be constant even in the presence of conditional branches.
+ The pass is located in `tree-ssa-ccp.c' and is described by
+ `pass_ccp'.
+
+ A related pass that works on memory loads and stores, and not just
+ register values, is located in `tree-ssa-ccp.c' and described by
+ `pass_store_ccp'.
+
+ * Conditional copy propagation
+
+ This is similar to constant propagation but the lattice of values
+ is the "copy-of" relation. It eliminates redundant copies from the
+ code. The pass is located in `tree-ssa-copy.c' and described by
+ `pass_copy_prop'.
+
+ A related pass that works on memory copies, and not just register
+ copies, is located in `tree-ssa-copy.c' and described by
+ `pass_store_copy_prop'.
+
+ * Value range propagation
+
+ This transformation is similar to constant propagation but instead
+ of propagating single constant values, it propagates known value
+ ranges. The implementation is based on Patterson's range
+ propagation algorithm (Accurate Static Branch Prediction by Value
+ Range Propagation, J. R. C. Patterson, PLDI '95). In contrast to
+ Patterson's algorithm, this implementation does not propagate
+ branch probabilities nor it uses more than a single range per SSA
+ name. This means that the current implementation cannot be used
+ for branch prediction (though adapting it would not be difficult).
+ The pass is located in `tree-vrp.c' and is described by `pass_vrp'.
+
+ * Folding built-in functions
+
+ This pass simplifies built-in functions, as applicable, with
+ constant arguments or with inferable string lengths. It is
+ located in `tree-ssa-ccp.c' and is described by
+ `pass_fold_builtins'.
+
+ * Split critical edges
+
+ This pass identifies critical edges and inserts empty basic blocks
+ such that the edge is no longer critical. The pass is located in
+ `tree-cfg.c' and is described by `pass_split_crit_edges'.
+
+ * Control dependence dead code elimination
+
+ This pass is a stronger form of dead code elimination that can
+ eliminate unnecessary control flow statements. It is located in
+ `tree-ssa-dce.c' and is described by `pass_cd_dce'.
+
+ * Tail call elimination
+
+ This pass identifies function calls that may be rewritten into
+ jumps. No code transformation is actually applied here, but the
+ data and control flow problem is solved. The code transformation
+ requires target support, and so is delayed until RTL. In the
+ meantime `CALL_EXPR_TAILCALL' is set indicating the possibility.
+ The pass is located in `tree-tailcall.c' and is described by
+ `pass_tail_calls'. The RTL transformation is handled by
+ `fixup_tail_calls' in `calls.c'.
+
+ * Warn for function return without value
+
+ For non-void functions, this pass locates return statements that do
+ not specify a value and issues a warning. Such a statement may
+ have been injected by falling off the end of the function. This
+ pass is run last so that we have as much time as possible to prove
+ that the statement is not reachable. It is located in
+ `tree-cfg.c' and is described by `pass_warn_function_return'.
+
+ * Mudflap statement annotation
+
+ If mudflap is enabled, we rewrite some memory accesses with code to
+ validate that the memory access is correct. In particular,
+ expressions involving pointer dereferences (`INDIRECT_REF',
+ `ARRAY_REF', etc.) are replaced by code that checks the selected
+ address range against the mudflap runtime's database of valid
+ regions. This check includes an inline lookup into a
+ direct-mapped cache, based on shift/mask operations of the pointer
+ value, with a fallback function call into the runtime. The pass
+ is located in `tree-mudflap.c' and is described by
+ `pass_mudflap_2'.
+
+ * Leave static single assignment form
+
+ This pass rewrites the function such that it is in normal form. At
+ the same time, we eliminate as many single-use temporaries as
+ possible, so the intermediate language is no longer GIMPLE, but
+ GENERIC. The pass is located in `tree-outof-ssa.c' and is
+ described by `pass_del_ssa'.
+
+ * Merge PHI nodes that feed into one another
+
+ This is part of the CFG cleanup passes. It attempts to join PHI
+ nodes from a forwarder CFG block into another block with PHI
+ nodes. The pass is located in `tree-cfgcleanup.c' and is
+ described by `pass_merge_phi'.
+
+ * Return value optimization
+
+ If a function always returns the same local variable, and that
+ local variable is an aggregate type, then the variable is replaced
+ with the return value for the function (i.e., the function's
+ DECL_RESULT). This is equivalent to the C++ named return value
+ optimization applied to GIMPLE. The pass is located in
+ `tree-nrv.c' and is described by `pass_nrv'.
+
+ * Return slot optimization
+
+ If a function returns a memory object and is called as `var =
+ foo()', this pass tries to change the call so that the address of
+ `var' is sent to the caller to avoid an extra memory copy. This
+ pass is located in `tree-nrv.c' and is described by
+ `pass_return_slot'.
+
+ * Optimize calls to `__builtin_object_size'
+
+ This is a propagation pass similar to CCP that tries to remove
+ calls to `__builtin_object_size' when the size of the object can be
+ computed at compile-time. This pass is located in
+ `tree-object-size.c' and is described by `pass_object_sizes'.
+
+ * Loop invariant motion
+
+ This pass removes expensive loop-invariant computations out of
+ loops. The pass is located in `tree-ssa-loop.c' and described by
+ `pass_lim'.
+
+ * Loop nest optimizations
+
+ This is a family of loop transformations that works on loop nests.
+ It includes loop interchange, scaling, skewing and reversal and
+ they are all geared to the optimization of data locality in array
+ traversals and the removal of dependencies that hamper
+ optimizations such as loop parallelization and vectorization. The
+ pass is located in `tree-loop-linear.c' and described by
+ `pass_linear_transform'.
+
+ * Removal of empty loops
+
+ This pass removes loops with no code in them. The pass is located
+ in `tree-ssa-loop-ivcanon.c' and described by `pass_empty_loop'.
+
+ * Unrolling of small loops
+
+ This pass completely unrolls loops with few iterations. The pass
+ is located in `tree-ssa-loop-ivcanon.c' and described by
+ `pass_complete_unroll'.
+
+ * Predictive commoning
+
+ This pass makes the code reuse the computations from the previous
+ iterations of the loops, especially loads and stores to memory.
+ It does so by storing the values of these computations to a bank
+ of temporary variables that are rotated at the end of loop. To
+ avoid the need for this rotation, the loop is then unrolled and
+ the copies of the loop body are rewritten to use the appropriate
+ version of the temporary variable. This pass is located in
+ `tree-predcom.c' and described by `pass_predcom'.
+
+ * Array prefetching
+
+ This pass issues prefetch instructions for array references inside
+ loops. The pass is located in `tree-ssa-loop-prefetch.c' and
+ described by `pass_loop_prefetch'.
+
+ * Reassociation
+
+ This pass rewrites arithmetic expressions to enable optimizations
+ that operate on them, like redundancy elimination and
+ vectorization. The pass is located in `tree-ssa-reassoc.c' and
+ described by `pass_reassoc'.
+
+ * Optimization of `stdarg' functions
+
+ This pass tries to avoid the saving of register arguments into the
+ stack on entry to `stdarg' functions. If the function doesn't use
+ any `va_start' macros, no registers need to be saved. If
+ `va_start' macros are used, the `va_list' variables don't escape
+ the function, it is only necessary to save registers that will be
+ used in `va_arg' macros. For instance, if `va_arg' is only used
+ with integral types in the function, floating point registers
+ don't need to be saved. This pass is located in `tree-stdarg.c'
+ and described by `pass_stdarg'.
+
+
+\1f
+File: gccint.info, Node: RTL passes, Prev: Tree SSA passes, Up: Passes
+
+8.5 RTL passes
+==============
+
+The following briefly describes the RTL generation and optimization
+passes that are run after the Tree optimization passes.
+
+ * RTL generation
+
+ The source files for RTL generation include `stmt.c', `calls.c',
+ `expr.c', `explow.c', `expmed.c', `function.c', `optabs.c' and
+ `emit-rtl.c'. Also, the file `insn-emit.c', generated from the
+ machine description by the program `genemit', is used in this
+ pass. The header file `expr.h' is used for communication within
+ this pass.
+
+ The header files `insn-flags.h' and `insn-codes.h', generated from
+ the machine description by the programs `genflags' and `gencodes',
+ tell this pass which standard names are available for use and
+ which patterns correspond to them.
+
+ * Generation of exception landing pads
+
+ This pass generates the glue that handles communication between the
+ exception handling library routines and the exception handlers
+ within the function. Entry points in the function that are
+ invoked by the exception handling library are called "landing
+ pads". The code for this pass is located in `except.c'.
+
+ * Control flow graph cleanup
+
+ This pass removes unreachable code, simplifies jumps to next,
+ jumps to jump, jumps across jumps, etc. The pass is run multiple
+ times. For historical reasons, it is occasionally referred to as
+ the "jump optimization pass". The bulk of the code for this pass
+ is in `cfgcleanup.c', and there are support routines in `cfgrtl.c'
+ and `jump.c'.
+
+ * Forward propagation of single-def values
+
+ This pass attempts to remove redundant computation by substituting
+ variables that come from a single definition, and seeing if the
+ result can be simplified. It performs copy propagation and
+ addressing mode selection. The pass is run twice, with values
+ being propagated into loops only on the second run. The code is
+ located in `fwprop.c'.
+
+ * Common subexpression elimination
+
+ This pass removes redundant computation within basic blocks, and
+ optimizes addressing modes based on cost. The pass is run twice.
+ The code for this pass is located in `cse.c'.
+
+ * Global common subexpression elimination
+
+ This pass performs two different types of GCSE depending on
+ whether you are optimizing for size or not (LCM based GCSE tends
+ to increase code size for a gain in speed, while Morel-Renvoise
+ based GCSE does not). When optimizing for size, GCSE is done
+ using Morel-Renvoise Partial Redundancy Elimination, with the
+ exception that it does not try to move invariants out of
+ loops--that is left to the loop optimization pass. If MR PRE
+ GCSE is done, code hoisting (aka unification) is also done, as
+ well as load motion. If you are optimizing for speed, LCM (lazy
+ code motion) based GCSE is done. LCM is based on the work of
+ Knoop, Ruthing, and Steffen. LCM based GCSE also does loop
+ invariant code motion. We also perform load and store motion when
+ optimizing for speed. Regardless of which type of GCSE is used,
+ the GCSE pass also performs global constant and copy propagation.
+ The source file for this pass is `gcse.c', and the LCM routines
+ are in `lcm.c'.
+
+ * Loop optimization
+
+ This pass performs several loop related optimizations. The source
+ files `cfgloopanal.c' and `cfgloopmanip.c' contain generic loop
+ analysis and manipulation code. Initialization and finalization
+ of loop structures is handled by `loop-init.c'. A loop invariant
+ motion pass is implemented in `loop-invariant.c'. Basic block
+ level optimizations--unrolling, peeling and unswitching loops--
+ are implemented in `loop-unswitch.c' and `loop-unroll.c'.
+ Replacing of the exit condition of loops by special
+ machine-dependent instructions is handled by `loop-doloop.c'.
+
+ * Jump bypassing
+
+ This pass is an aggressive form of GCSE that transforms the control
+ flow graph of a function by propagating constants into conditional
+ branch instructions. The source file for this pass is `gcse.c'.
+
+ * If conversion
+
+ This pass attempts to replace conditional branches and surrounding
+ assignments with arithmetic, boolean value producing comparison
+ instructions, and conditional move instructions. In the very last
+ invocation after reload, it will generate predicated instructions
+ when supported by the target. The code is located in `ifcvt.c'.
+
+ * Web construction
+
+ This pass splits independent uses of each pseudo-register. This
+ can improve effect of the other transformation, such as CSE or
+ register allocation. The code for this pass is located in `web.c'.
+
+ * Instruction combination
+
+ This pass attempts to combine groups of two or three instructions
+ that are related by data flow into single instructions. It
+ combines the RTL expressions for the instructions by substitution,
+ simplifies the result using algebra, and then attempts to match
+ the result against the machine description. The code is located
+ in `combine.c'.
+
+ * Register movement
+
+ This pass looks for cases where matching constraints would force an
+ instruction to need a reload, and this reload would be a
+ register-to-register move. It then attempts to change the
+ registers used by the instruction to avoid the move instruction.
+ The code is located in `regmove.c'.
+
+ * Mode switching optimization
+
+ This pass looks for instructions that require the processor to be
+ in a specific "mode" and minimizes the number of mode changes
+ required to satisfy all users. What these modes are, and what
+ they apply to are completely target-specific. The code for this
+ pass is located in `mode-switching.c'.
+
+ * Modulo scheduling
+
+ This pass looks at innermost loops and reorders their instructions
+ by overlapping different iterations. Modulo scheduling is
+ performed immediately before instruction scheduling. The code for
+ this pass is located in `modulo-sched.c'.
+
+ * Instruction scheduling
+
+ This pass looks for instructions whose output will not be
+ available by the time that it is used in subsequent instructions.
+ Memory loads and floating point instructions often have this
+ behavior on RISC machines. It re-orders instructions within a
+ basic block to try to separate the definition and use of items
+ that otherwise would cause pipeline stalls. This pass is
+ performed twice, before and after register allocation. The code
+ for this pass is located in `haifa-sched.c', `sched-deps.c',
+ `sched-ebb.c', `sched-rgn.c' and `sched-vis.c'.
+
+ * Register allocation
+
+ These passes make sure that all occurrences of pseudo registers are
+ eliminated, either by allocating them to a hard register, replacing
+ them by an equivalent expression (e.g. a constant) or by placing
+ them on the stack. This is done in several subpasses:
+
+ * Register move optimizations. This pass makes some simple RTL
+ code transformations which improve the subsequent register
+ allocation. The source file is `regmove.c'.
+
+ * The integrated register allocator (IRA). It is called
+ integrated because coalescing, register live range splitting,
+ and hard register preferencing are done on-the-fly during
+ coloring. It also has better integration with the reload
+ pass. Pseudo-registers spilled by the allocator or the
+ reload have still a chance to get hard-registers if the
+ reload evicts some pseudo-registers from hard-registers. The
+ allocator helps to choose better pseudos for spilling based
+ on their live ranges and to coalesce stack slots allocated
+ for the spilled pseudo-registers. IRA is a regional register
+ allocator which is transformed into Chaitin-Briggs allocator
+ if there is one region. By default, IRA chooses regions using
+ register pressure but the user can force it to use one region
+ or regions corresponding to all loops.
+
+ Source files of the allocator are `ira.c', `ira-build.c',
+ `ira-costs.c', `ira-conflicts.c', `ira-color.c',
+ `ira-emit.c', `ira-lives', plus header files `ira.h' and
+ `ira-int.h' used for the communication between the allocator
+ and the rest of the compiler and between the IRA files.
+
+ * Reloading. This pass renumbers pseudo registers with the
+ hardware registers numbers they were allocated. Pseudo
+ registers that did not get hard registers are replaced with
+ stack slots. Then it finds instructions that are invalid
+ because a value has failed to end up in a register, or has
+ ended up in a register of the wrong kind. It fixes up these
+ instructions by reloading the problematical values
+ temporarily into registers. Additional instructions are
+ generated to do the copying.
+
+ The reload pass also optionally eliminates the frame pointer
+ and inserts instructions to save and restore call-clobbered
+ registers around calls.
+
+ Source files are `reload.c' and `reload1.c', plus the header
+ `reload.h' used for communication between them.
+
+ * Basic block reordering
+
+ This pass implements profile guided code positioning. If profile
+ information is not available, various types of static analysis are
+ performed to make the predictions normally coming from the profile
+ feedback (IE execution frequency, branch probability, etc). It is
+ implemented in the file `bb-reorder.c', and the various prediction
+ routines are in `predict.c'.
+
+ * Variable tracking
+
+ This pass computes where the variables are stored at each position
+ in code and generates notes describing the variable locations to
+ RTL code. The location lists are then generated according to these
+ notes to debug information if the debugging information format
+ supports location lists. The code is located in `var-tracking.c'.
+
+ * Delayed branch scheduling
+
+ This optional pass attempts to find instructions that can go into
+ the delay slots of other instructions, usually jumps and calls.
+ The code for this pass is located in `reorg.c'.
+
+ * Branch shortening
+
+ On many RISC machines, branch instructions have a limited range.
+ Thus, longer sequences of instructions must be used for long
+ branches. In this pass, the compiler figures out what how far
+ each instruction will be from each other instruction, and
+ therefore whether the usual instructions, or the longer sequences,
+ must be used for each branch. The code for this pass is located
+ in `final.c'.
+
+ * Register-to-stack conversion
+
+ Conversion from usage of some hard registers to usage of a register
+ stack may be done at this point. Currently, this is supported only
+ for the floating-point registers of the Intel 80387 coprocessor.
+ The code for this pass is located in `reg-stack.c'.
+
+ * Final
+
+ This pass outputs the assembler code for the function. The source
+ files are `final.c' plus `insn-output.c'; the latter is generated
+ automatically from the machine description by the tool `genoutput'.
+ The header file `conditions.h' is used for communication between
+ these files. If mudflap is enabled, the queue of deferred
+ declarations and any addressed constants (e.g., string literals)
+ is processed by `mudflap_finish_file' into a synthetic constructor
+ function containing calls into the mudflap runtime.
+
+ * Debugging information output
+
+ This is run after final because it must output the stack slot
+ offsets for pseudo registers that did not get hard registers.
+ Source files are `dbxout.c' for DBX symbol table format,
+ `sdbout.c' for SDB symbol table format, `dwarfout.c' for DWARF
+ symbol table format, files `dwarf2out.c' and `dwarf2asm.c' for
+ DWARF2 symbol table format, and `vmsdbgout.c' for VMS debug symbol
+ table format.
+
+
+\1f
+File: gccint.info, Node: Trees, Next: GENERIC, Prev: Passes, Up: Top
+
+9 Trees: The intermediate representation used by the C and C++ front ends
+*************************************************************************
+
+This chapter documents the internal representation used by GCC to
+represent C and C++ source programs. When presented with a C or C++
+source program, GCC parses the program, performs semantic analysis
+(including the generation of error messages), and then produces the
+internal representation described here. This representation contains a
+complete representation for the entire translation unit provided as
+input to the front end. This representation is then typically processed
+by a code-generator in order to produce machine code, but could also be
+used in the creation of source browsers, intelligent editors, automatic
+documentation generators, interpreters, and any other programs needing
+the ability to process C or C++ code.
+
+ This chapter explains the internal representation. In particular, it
+documents the internal representation for C and C++ source constructs,
+and the macros, functions, and variables that can be used to access
+these constructs. The C++ representation is largely a superset of the
+representation used in the C front end. There is only one construct
+used in C that does not appear in the C++ front end and that is the GNU
+"nested function" extension. Many of the macros documented here do not
+apply in C because the corresponding language constructs do not appear
+in C.
+
+ If you are developing a "back end", be it is a code-generator or some
+other tool, that uses this representation, you may occasionally find
+that you need to ask questions not easily answered by the functions and
+macros available here. If that situation occurs, it is quite likely
+that GCC already supports the functionality you desire, but that the
+interface is simply not documented here. In that case, you should ask
+the GCC maintainers (via mail to <gcc@gcc.gnu.org>) about documenting
+the functionality you require. Similarly, if you find yourself writing
+functions that do not deal directly with your back end, but instead
+might be useful to other people using the GCC front end, you should
+submit your patches for inclusion in GCC.
+
+* Menu:
+
+* Deficiencies:: Topics net yet covered in this document.
+* Tree overview:: All about `tree's.
+* Types:: Fundamental and aggregate types.
+* Scopes:: Namespaces and classes.
+* Functions:: Overloading, function bodies, and linkage.
+* Declarations:: Type declarations and variables.
+* Attributes:: Declaration and type attributes.
+* Expression trees:: From `typeid' to `throw'.
+
+\1f
+File: gccint.info, Node: Deficiencies, Next: Tree overview, Up: Trees
+
+9.1 Deficiencies
+================
+
+There are many places in which this document is incomplet and incorrekt.
+It is, as of yet, only _preliminary_ documentation.
+
+\1f
+File: gccint.info, Node: Tree overview, Next: Types, Prev: Deficiencies, Up: Trees
+
+9.2 Overview
+============
+
+The central data structure used by the internal representation is the
+`tree'. These nodes, while all of the C type `tree', are of many
+varieties. A `tree' is a pointer type, but the object to which it
+points may be of a variety of types. From this point forward, we will
+refer to trees in ordinary type, rather than in `this font', except
+when talking about the actual C type `tree'.
+
+ You can tell what kind of node a particular tree is by using the
+`TREE_CODE' macro. Many, many macros take trees as input and return
+trees as output. However, most macros require a certain kind of tree
+node as input. In other words, there is a type-system for trees, but
+it is not reflected in the C type-system.
+
+ For safety, it is useful to configure GCC with `--enable-checking'.
+Although this results in a significant performance penalty (since all
+tree types are checked at run-time), and is therefore inappropriate in a
+release version, it is extremely helpful during the development process.
+
+ Many macros behave as predicates. Many, although not all, of these
+predicates end in `_P'. Do not rely on the result type of these macros
+being of any particular type. You may, however, rely on the fact that
+the type can be compared to `0', so that statements like
+ if (TEST_P (t) && !TEST_P (y))
+ x = 1;
+ and
+ int i = (TEST_P (t) != 0);
+ are legal. Macros that return `int' values now may be changed to
+return `tree' values, or other pointers in the future. Even those that
+continue to return `int' may return multiple nonzero codes where
+previously they returned only zero and one. Therefore, you should not
+write code like
+ if (TEST_P (t) == 1)
+ as this code is not guaranteed to work correctly in the future.
+
+ You should not take the address of values returned by the macros or
+functions described here. In particular, no guarantee is given that the
+values are lvalues.
+
+ In general, the names of macros are all in uppercase, while the names
+of functions are entirely in lowercase. There are rare exceptions to
+this rule. You should assume that any macro or function whose name is
+made up entirely of uppercase letters may evaluate its arguments more
+than once. You may assume that a macro or function whose name is made
+up entirely of lowercase letters will evaluate its arguments only once.
+
+ The `error_mark_node' is a special tree. Its tree code is
+`ERROR_MARK', but since there is only ever one node with that code, the
+usual practice is to compare the tree against `error_mark_node'. (This
+test is just a test for pointer equality.) If an error has occurred
+during front-end processing the flag `errorcount' will be set. If the
+front end has encountered code it cannot handle, it will issue a
+message to the user and set `sorrycount'. When these flags are set,
+any macro or function which normally returns a tree of a particular
+kind may instead return the `error_mark_node'. Thus, if you intend to
+do any processing of erroneous code, you must be prepared to deal with
+the `error_mark_node'.
+
+ Occasionally, a particular tree slot (like an operand to an expression,
+or a particular field in a declaration) will be referred to as
+"reserved for the back end". These slots are used to store RTL when
+the tree is converted to RTL for use by the GCC back end. However, if
+that process is not taking place (e.g., if the front end is being hooked
+up to an intelligent editor), then those slots may be used by the back
+end presently in use.
+
+ If you encounter situations that do not match this documentation, such
+as tree nodes of types not mentioned here, or macros documented to
+return entities of a particular kind that instead return entities of
+some different kind, you have found a bug, either in the front end or in
+the documentation. Please report these bugs as you would any other bug.
+
+* Menu:
+
+* Macros and Functions::Macros and functions that can be used with all trees.
+* Identifiers:: The names of things.
+* Containers:: Lists and vectors.
+
+\1f
+File: gccint.info, Node: Macros and Functions, Next: Identifiers, Up: Tree overview
+
+9.2.1 Trees
+-----------
+
+This section is not here yet.
+
+\1f
+File: gccint.info, Node: Identifiers, Next: Containers, Prev: Macros and Functions, Up: Tree overview
+
+9.2.2 Identifiers
+-----------------
+
+An `IDENTIFIER_NODE' represents a slightly more general concept that
+the standard C or C++ concept of identifier. In particular, an
+`IDENTIFIER_NODE' may contain a `$', or other extraordinary characters.
+
+ There are never two distinct `IDENTIFIER_NODE's representing the same
+identifier. Therefore, you may use pointer equality to compare
+`IDENTIFIER_NODE's, rather than using a routine like `strcmp'.
+
+ You can use the following macros to access identifiers:
+`IDENTIFIER_POINTER'
+ The string represented by the identifier, represented as a
+ `char*'. This string is always `NUL'-terminated, and contains no
+ embedded `NUL' characters.
+
+`IDENTIFIER_LENGTH'
+ The length of the string returned by `IDENTIFIER_POINTER', not
+ including the trailing `NUL'. This value of `IDENTIFIER_LENGTH
+ (x)' is always the same as `strlen (IDENTIFIER_POINTER (x))'.
+
+`IDENTIFIER_OPNAME_P'
+ This predicate holds if the identifier represents the name of an
+ overloaded operator. In this case, you should not depend on the
+ contents of either the `IDENTIFIER_POINTER' or the
+ `IDENTIFIER_LENGTH'.
+
+`IDENTIFIER_TYPENAME_P'
+ This predicate holds if the identifier represents the name of a
+ user-defined conversion operator. In this case, the `TREE_TYPE' of
+ the `IDENTIFIER_NODE' holds the type to which the conversion
+ operator converts.
+
+
+\1f
+File: gccint.info, Node: Containers, Prev: Identifiers, Up: Tree overview
+
+9.2.3 Containers
+----------------
+
+Two common container data structures can be represented directly with
+tree nodes. A `TREE_LIST' is a singly linked list containing two trees
+per node. These are the `TREE_PURPOSE' and `TREE_VALUE' of each node.
+(Often, the `TREE_PURPOSE' contains some kind of tag, or additional
+information, while the `TREE_VALUE' contains the majority of the
+payload. In other cases, the `TREE_PURPOSE' is simply `NULL_TREE',
+while in still others both the `TREE_PURPOSE' and `TREE_VALUE' are of
+equal stature.) Given one `TREE_LIST' node, the next node is found by
+following the `TREE_CHAIN'. If the `TREE_CHAIN' is `NULL_TREE', then
+you have reached the end of the list.
+
+ A `TREE_VEC' is a simple vector. The `TREE_VEC_LENGTH' is an integer
+(not a tree) giving the number of nodes in the vector. The nodes
+themselves are accessed using the `TREE_VEC_ELT' macro, which takes two
+arguments. The first is the `TREE_VEC' in question; the second is an
+integer indicating which element in the vector is desired. The
+elements are indexed from zero.
+
+\1f
+File: gccint.info, Node: Types, Next: Scopes, Prev: Tree overview, Up: Trees
+
+9.3 Types
+=========
+
+All types have corresponding tree nodes. However, you should not assume
+that there is exactly one tree node corresponding to each type. There
+are often multiple nodes corresponding to the same type.
+
+ For the most part, different kinds of types have different tree codes.
+(For example, pointer types use a `POINTER_TYPE' code while arrays use
+an `ARRAY_TYPE' code.) However, pointers to member functions use the
+`RECORD_TYPE' code. Therefore, when writing a `switch' statement that
+depends on the code associated with a particular type, you should take
+care to handle pointers to member functions under the `RECORD_TYPE'
+case label.
+
+ In C++, an array type is not qualified; rather the type of the array
+elements is qualified. This situation is reflected in the intermediate
+representation. The macros described here will always examine the
+qualification of the underlying element type when applied to an array
+type. (If the element type is itself an array, then the recursion
+continues until a non-array type is found, and the qualification of this
+type is examined.) So, for example, `CP_TYPE_CONST_P' will hold of the
+type `const int ()[7]', denoting an array of seven `int's.
+
+ The following functions and macros deal with cv-qualification of types:
+`CP_TYPE_QUALS'
+ This macro returns the set of type qualifiers applied to this type.
+ This value is `TYPE_UNQUALIFIED' if no qualifiers have been
+ applied. The `TYPE_QUAL_CONST' bit is set if the type is
+ `const'-qualified. The `TYPE_QUAL_VOLATILE' bit is set if the
+ type is `volatile'-qualified. The `TYPE_QUAL_RESTRICT' bit is set
+ if the type is `restrict'-qualified.
+
+`CP_TYPE_CONST_P'
+ This macro holds if the type is `const'-qualified.
+
+`CP_TYPE_VOLATILE_P'
+ This macro holds if the type is `volatile'-qualified.
+
+`CP_TYPE_RESTRICT_P'
+ This macro holds if the type is `restrict'-qualified.
+
+`CP_TYPE_CONST_NON_VOLATILE_P'
+ This predicate holds for a type that is `const'-qualified, but
+ _not_ `volatile'-qualified; other cv-qualifiers are ignored as
+ well: only the `const'-ness is tested.
+
+`TYPE_MAIN_VARIANT'
+ This macro returns the unqualified version of a type. It may be
+ applied to an unqualified type, but it is not always the identity
+ function in that case.
+
+ A few other macros and functions are usable with all types:
+`TYPE_SIZE'
+ The number of bits required to represent the type, represented as
+ an `INTEGER_CST'. For an incomplete type, `TYPE_SIZE' will be
+ `NULL_TREE'.
+
+`TYPE_ALIGN'
+ The alignment of the type, in bits, represented as an `int'.
+
+`TYPE_NAME'
+ This macro returns a declaration (in the form of a `TYPE_DECL') for
+ the type. (Note this macro does _not_ return a `IDENTIFIER_NODE',
+ as you might expect, given its name!) You can look at the
+ `DECL_NAME' of the `TYPE_DECL' to obtain the actual name of the
+ type. The `TYPE_NAME' will be `NULL_TREE' for a type that is not
+ a built-in type, the result of a typedef, or a named class type.
+
+`CP_INTEGRAL_TYPE'
+ This predicate holds if the type is an integral type. Notice that
+ in C++, enumerations are _not_ integral types.
+
+`ARITHMETIC_TYPE_P'
+ This predicate holds if the type is an integral type (in the C++
+ sense) or a floating point type.
+
+`CLASS_TYPE_P'
+ This predicate holds for a class-type.
+
+`TYPE_BUILT_IN'
+ This predicate holds for a built-in type.
+
+`TYPE_PTRMEM_P'
+ This predicate holds if the type is a pointer to data member.
+
+`TYPE_PTR_P'
+ This predicate holds if the type is a pointer type, and the
+ pointee is not a data member.
+
+`TYPE_PTRFN_P'
+ This predicate holds for a pointer to function type.
+
+`TYPE_PTROB_P'
+ This predicate holds for a pointer to object type. Note however
+ that it does not hold for the generic pointer to object type `void
+ *'. You may use `TYPE_PTROBV_P' to test for a pointer to object
+ type as well as `void *'.
+
+`TYPE_CANONICAL'
+ This macro returns the "canonical" type for the given type node.
+ Canonical types are used to improve performance in the C++ and
+ Objective-C++ front ends by allowing efficient comparison between
+ two type nodes in `same_type_p': if the `TYPE_CANONICAL' values of
+ the types are equal, the types are equivalent; otherwise, the types
+ are not equivalent. The notion of equivalence for canonical types
+ is the same as the notion of type equivalence in the language
+ itself. For instance,
+
+ When `TYPE_CANONICAL' is `NULL_TREE', there is no canonical type
+ for the given type node. In this case, comparison between this
+ type and any other type requires the compiler to perform a deep,
+ "structural" comparison to see if the two type nodes have the same
+ form and properties.
+
+ The canonical type for a node is always the most fundamental type
+ in the equivalence class of types. For instance, `int' is its own
+ canonical type. A typedef `I' of `int' will have `int' as its
+ canonical type. Similarly, `I*' and a typedef `IP' (defined to
+ `I*') will has `int*' as their canonical type. When building a new
+ type node, be sure to set `TYPE_CANONICAL' to the appropriate
+ canonical type. If the new type is a compound type (built from
+ other types), and any of those other types require structural
+ equality, use `SET_TYPE_STRUCTURAL_EQUALITY' to ensure that the
+ new type also requires structural equality. Finally, if for some
+ reason you cannot guarantee that `TYPE_CANONICAL' will point to
+ the canonical type, use `SET_TYPE_STRUCTURAL_EQUALITY' to make
+ sure that the new type-and any type constructed based on
+ it-requires structural equality. If you suspect that the canonical
+ type system is miscomparing types, pass `--param
+ verify-canonical-types=1' to the compiler or configure with
+ `--enable-checking' to force the compiler to verify its
+ canonical-type comparisons against the structural comparisons; the
+ compiler will then print any warnings if the canonical types
+ miscompare.
+
+`TYPE_STRUCTURAL_EQUALITY_P'
+ This predicate holds when the node requires structural equality
+ checks, e.g., when `TYPE_CANONICAL' is `NULL_TREE'.
+
+`SET_TYPE_STRUCTURAL_EQUALITY'
+ This macro states that the type node it is given requires
+ structural equality checks, e.g., it sets `TYPE_CANONICAL' to
+ `NULL_TREE'.
+
+`same_type_p'
+ This predicate takes two types as input, and holds if they are the
+ same type. For example, if one type is a `typedef' for the other,
+ or both are `typedef's for the same type. This predicate also
+ holds if the two trees given as input are simply copies of one
+ another; i.e., there is no difference between them at the source
+ level, but, for whatever reason, a duplicate has been made in the
+ representation. You should never use `==' (pointer equality) to
+ compare types; always use `same_type_p' instead.
+
+ Detailed below are the various kinds of types, and the macros that can
+be used to access them. Although other kinds of types are used
+elsewhere in G++, the types described here are the only ones that you
+will encounter while examining the intermediate representation.
+
+`VOID_TYPE'
+ Used to represent the `void' type.
+
+`INTEGER_TYPE'
+ Used to represent the various integral types, including `char',
+ `short', `int', `long', and `long long'. This code is not used
+ for enumeration types, nor for the `bool' type. The
+ `TYPE_PRECISION' is the number of bits used in the representation,
+ represented as an `unsigned int'. (Note that in the general case
+ this is not the same value as `TYPE_SIZE'; suppose that there were
+ a 24-bit integer type, but that alignment requirements for the ABI
+ required 32-bit alignment. Then, `TYPE_SIZE' would be an
+ `INTEGER_CST' for 32, while `TYPE_PRECISION' would be 24.) The
+ integer type is unsigned if `TYPE_UNSIGNED' holds; otherwise, it
+ is signed.
+
+ The `TYPE_MIN_VALUE' is an `INTEGER_CST' for the smallest integer
+ that may be represented by this type. Similarly, the
+ `TYPE_MAX_VALUE' is an `INTEGER_CST' for the largest integer that
+ may be represented by this type.
+
+`REAL_TYPE'
+ Used to represent the `float', `double', and `long double' types.
+ The number of bits in the floating-point representation is given
+ by `TYPE_PRECISION', as in the `INTEGER_TYPE' case.
+
+`FIXED_POINT_TYPE'
+ Used to represent the `short _Fract', `_Fract', `long _Fract',
+ `long long _Fract', `short _Accum', `_Accum', `long _Accum', and
+ `long long _Accum' types. The number of bits in the fixed-point
+ representation is given by `TYPE_PRECISION', as in the
+ `INTEGER_TYPE' case. There may be padding bits, fractional bits
+ and integral bits. The number of fractional bits is given by
+ `TYPE_FBIT', and the number of integral bits is given by
+ `TYPE_IBIT'. The fixed-point type is unsigned if `TYPE_UNSIGNED'
+ holds; otherwise, it is signed. The fixed-point type is
+ saturating if `TYPE_SATURATING' holds; otherwise, it is not
+ saturating.
+
+`COMPLEX_TYPE'
+ Used to represent GCC built-in `__complex__' data types. The
+ `TREE_TYPE' is the type of the real and imaginary parts.
+
+`ENUMERAL_TYPE'
+ Used to represent an enumeration type. The `TYPE_PRECISION' gives
+ (as an `int'), the number of bits used to represent the type. If
+ there are no negative enumeration constants, `TYPE_UNSIGNED' will
+ hold. The minimum and maximum enumeration constants may be
+ obtained with `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE', respectively;
+ each of these macros returns an `INTEGER_CST'.
+
+ The actual enumeration constants themselves may be obtained by
+ looking at the `TYPE_VALUES'. This macro will return a
+ `TREE_LIST', containing the constants. The `TREE_PURPOSE' of each
+ node will be an `IDENTIFIER_NODE' giving the name of the constant;
+ the `TREE_VALUE' will be an `INTEGER_CST' giving the value
+ assigned to that constant. These constants will appear in the
+ order in which they were declared. The `TREE_TYPE' of each of
+ these constants will be the type of enumeration type itself.
+
+`BOOLEAN_TYPE'
+ Used to represent the `bool' type.
+
+`POINTER_TYPE'
+ Used to represent pointer types, and pointer to data member types.
+ The `TREE_TYPE' gives the type to which this type points. If the
+ type is a pointer to data member type, then `TYPE_PTRMEM_P' will
+ hold. For a pointer to data member type of the form `T X::*',
+ `TYPE_PTRMEM_CLASS_TYPE' will be the type `X', while
+ `TYPE_PTRMEM_POINTED_TO_TYPE' will be the type `T'.
+
+`REFERENCE_TYPE'
+ Used to represent reference types. The `TREE_TYPE' gives the type
+ to which this type refers.
+
+`FUNCTION_TYPE'
+ Used to represent the type of non-member functions and of static
+ member functions. The `TREE_TYPE' gives the return type of the
+ function. The `TYPE_ARG_TYPES' are a `TREE_LIST' of the argument
+ types. The `TREE_VALUE' of each node in this list is the type of
+ the corresponding argument; the `TREE_PURPOSE' is an expression
+ for the default argument value, if any. If the last node in the
+ list is `void_list_node' (a `TREE_LIST' node whose `TREE_VALUE' is
+ the `void_type_node'), then functions of this type do not take
+ variable arguments. Otherwise, they do take a variable number of
+ arguments.
+
+ Note that in C (but not in C++) a function declared like `void f()'
+ is an unprototyped function taking a variable number of arguments;
+ the `TYPE_ARG_TYPES' of such a function will be `NULL'.
+
+`METHOD_TYPE'
+ Used to represent the type of a non-static member function. Like a
+ `FUNCTION_TYPE', the return type is given by the `TREE_TYPE'. The
+ type of `*this', i.e., the class of which functions of this type
+ are a member, is given by the `TYPE_METHOD_BASETYPE'. The
+ `TYPE_ARG_TYPES' is the parameter list, as for a `FUNCTION_TYPE',
+ and includes the `this' argument.
+
+`ARRAY_TYPE'
+ Used to represent array types. The `TREE_TYPE' gives the type of
+ the elements in the array. If the array-bound is present in the
+ type, the `TYPE_DOMAIN' is an `INTEGER_TYPE' whose
+ `TYPE_MIN_VALUE' and `TYPE_MAX_VALUE' will be the lower and upper
+ bounds of the array, respectively. The `TYPE_MIN_VALUE' will
+ always be an `INTEGER_CST' for zero, while the `TYPE_MAX_VALUE'
+ will be one less than the number of elements in the array, i.e.,
+ the highest value which may be used to index an element in the
+ array.
+
+`RECORD_TYPE'
+ Used to represent `struct' and `class' types, as well as pointers
+ to member functions and similar constructs in other languages.
+ `TYPE_FIELDS' contains the items contained in this type, each of
+ which can be a `FIELD_DECL', `VAR_DECL', `CONST_DECL', or
+ `TYPE_DECL'. You may not make any assumptions about the ordering
+ of the fields in the type or whether one or more of them overlap.
+ If `TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member
+ type. In that case, the `TYPE_PTRMEMFUNC_FN_TYPE' is a
+ `POINTER_TYPE' pointing to a `METHOD_TYPE'. The `METHOD_TYPE' is
+ the type of a function pointed to by the pointer-to-member
+ function. If `TYPE_PTRMEMFUNC_P' does not hold, this type is a
+ class type. For more information, see *note Classes::.
+
+`UNION_TYPE'
+ Used to represent `union' types. Similar to `RECORD_TYPE' except
+ that all `FIELD_DECL' nodes in `TYPE_FIELD' start at bit position
+ zero.
+
+`QUAL_UNION_TYPE'
+ Used to represent part of a variant record in Ada. Similar to
+ `UNION_TYPE' except that each `FIELD_DECL' has a `DECL_QUALIFIER'
+ field, which contains a boolean expression that indicates whether
+ the field is present in the object. The type will only have one
+ field, so each field's `DECL_QUALIFIER' is only evaluated if none
+ of the expressions in the previous fields in `TYPE_FIELDS' are
+ nonzero. Normally these expressions will reference a field in the
+ outer object using a `PLACEHOLDER_EXPR'.
+
+`UNKNOWN_TYPE'
+ This node is used to represent a type the knowledge of which is
+ insufficient for a sound processing.
+
+`OFFSET_TYPE'
+ This node is used to represent a pointer-to-data member. For a
+ data member `X::m' the `TYPE_OFFSET_BASETYPE' is `X' and the
+ `TREE_TYPE' is the type of `m'.
+
+`TYPENAME_TYPE'
+ Used to represent a construct of the form `typename T::A'. The
+ `TYPE_CONTEXT' is `T'; the `TYPE_NAME' is an `IDENTIFIER_NODE' for
+ `A'. If the type is specified via a template-id, then
+ `TYPENAME_TYPE_FULLNAME' yields a `TEMPLATE_ID_EXPR'. The
+ `TREE_TYPE' is non-`NULL' if the node is implicitly generated in
+ support for the implicit typename extension; in which case the
+ `TREE_TYPE' is a type node for the base-class.
+
+`TYPEOF_TYPE'
+ Used to represent the `__typeof__' extension. The `TYPE_FIELDS'
+ is the expression the type of which is being represented.
+
+ There are variables whose values represent some of the basic types.
+These include:
+`void_type_node'
+ A node for `void'.
+
+`integer_type_node'
+ A node for `int'.
+
+`unsigned_type_node.'
+ A node for `unsigned int'.
+
+`char_type_node.'
+ A node for `char'.
+ It may sometimes be useful to compare one of these variables with a
+type in hand, using `same_type_p'.
+
+\1f
+File: gccint.info, Node: Scopes, Next: Functions, Prev: Types, Up: Trees
+
+9.4 Scopes
+==========
+
+The root of the entire intermediate representation is the variable
+`global_namespace'. This is the namespace specified with `::' in C++
+source code. All other namespaces, types, variables, functions, and so
+forth can be found starting with this namespace.
+
+ Besides namespaces, the other high-level scoping construct in C++ is
+the class. (Throughout this manual the term "class" is used to mean the
+types referred to in the ANSI/ISO C++ Standard as classes; these include
+types defined with the `class', `struct', and `union' keywords.)
+
+* Menu:
+
+* Namespaces:: Member functions, types, etc.
+* Classes:: Members, bases, friends, etc.
+
+\1f
+File: gccint.info, Node: Namespaces, Next: Classes, Up: Scopes
+
+9.4.1 Namespaces
+----------------
+
+A namespace is represented by a `NAMESPACE_DECL' node.
+
+ However, except for the fact that it is distinguished as the root of
+the representation, the global namespace is no different from any other
+namespace. Thus, in what follows, we describe namespaces generally,
+rather than the global namespace in particular.
+
+ The following macros and functions can be used on a `NAMESPACE_DECL':
+
+`DECL_NAME'
+ This macro is used to obtain the `IDENTIFIER_NODE' corresponding to
+ the unqualified name of the name of the namespace (*note
+ Identifiers::). The name of the global namespace is `::', even
+ though in C++ the global namespace is unnamed. However, you
+ should use comparison with `global_namespace', rather than
+ `DECL_NAME' to determine whether or not a namespace is the global
+ one. An unnamed namespace will have a `DECL_NAME' equal to
+ `anonymous_namespace_name'. Within a single translation unit, all
+ unnamed namespaces will have the same name.
+
+`DECL_CONTEXT'
+ This macro returns the enclosing namespace. The `DECL_CONTEXT' for
+ the `global_namespace' is `NULL_TREE'.
+
+`DECL_NAMESPACE_ALIAS'
+ If this declaration is for a namespace alias, then
+ `DECL_NAMESPACE_ALIAS' is the namespace for which this one is an
+ alias.
+
+ Do not attempt to use `cp_namespace_decls' for a namespace which is
+ an alias. Instead, follow `DECL_NAMESPACE_ALIAS' links until you
+ reach an ordinary, non-alias, namespace, and call
+ `cp_namespace_decls' there.
+
+`DECL_NAMESPACE_STD_P'
+ This predicate holds if the namespace is the special `::std'
+ namespace.
+
+`cp_namespace_decls'
+ This function will return the declarations contained in the
+ namespace, including types, overloaded functions, other
+ namespaces, and so forth. If there are no declarations, this
+ function will return `NULL_TREE'. The declarations are connected
+ through their `TREE_CHAIN' fields.
+
+ Although most entries on this list will be declarations,
+ `TREE_LIST' nodes may also appear. In this case, the `TREE_VALUE'
+ will be an `OVERLOAD'. The value of the `TREE_PURPOSE' is
+ unspecified; back ends should ignore this value. As with the
+ other kinds of declarations returned by `cp_namespace_decls', the
+ `TREE_CHAIN' will point to the next declaration in this list.
+
+ For more information on the kinds of declarations that can occur
+ on this list, *Note Declarations::. Some declarations will not
+ appear on this list. In particular, no `FIELD_DECL',
+ `LABEL_DECL', or `PARM_DECL' nodes will appear here.
+
+ This function cannot be used with namespaces that have
+ `DECL_NAMESPACE_ALIAS' set.
+
+
+\1f
+File: gccint.info, Node: Classes, Prev: Namespaces, Up: Scopes
+
+9.4.2 Classes
+-------------
+
+A class type is represented by either a `RECORD_TYPE' or a
+`UNION_TYPE'. A class declared with the `union' tag is represented by
+a `UNION_TYPE', while classes declared with either the `struct' or the
+`class' tag are represented by `RECORD_TYPE's. You can use the
+`CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular
+type is a `class' as opposed to a `struct'. This macro will be true
+only for classes declared with the `class' tag.
+
+ Almost all non-function members are available on the `TYPE_FIELDS'
+list. Given one member, the next can be found by following the
+`TREE_CHAIN'. You should not depend in any way on the order in which
+fields appear on this list. All nodes on this list will be `DECL'
+nodes. A `FIELD_DECL' is used to represent a non-static data member, a
+`VAR_DECL' is used to represent a static data member, and a `TYPE_DECL'
+is used to represent a type. Note that the `CONST_DECL' for an
+enumeration constant will appear on this list, if the enumeration type
+was declared in the class. (Of course, the `TYPE_DECL' for the
+enumeration type will appear here as well.) There are no entries for
+base classes on this list. In particular, there is no `FIELD_DECL' for
+the "base-class portion" of an object.
+
+ The `TYPE_VFIELD' is a compiler-generated field used to point to
+virtual function tables. It may or may not appear on the `TYPE_FIELDS'
+list. However, back ends should handle the `TYPE_VFIELD' just like all
+the entries on the `TYPE_FIELDS' list.
+
+ The function members are available on the `TYPE_METHODS' list. Again,
+subsequent members are found by following the `TREE_CHAIN' field. If a
+function is overloaded, each of the overloaded functions appears; no
+`OVERLOAD' nodes appear on the `TYPE_METHODS' list. Implicitly
+declared functions (including default constructors, copy constructors,
+assignment operators, and destructors) will appear on this list as well.
+
+ Every class has an associated "binfo", which can be obtained with
+`TYPE_BINFO'. Binfos are used to represent base-classes. The binfo
+given by `TYPE_BINFO' is the degenerate case, whereby every class is
+considered to be its own base-class. The base binfos for a particular
+binfo are held in a vector, whose length is obtained with
+`BINFO_N_BASE_BINFOS'. The base binfos themselves are obtained with
+`BINFO_BASE_BINFO' and `BINFO_BASE_ITERATE'. To add a new binfo, use
+`BINFO_BASE_APPEND'. The vector of base binfos can be obtained with
+`BINFO_BASE_BINFOS', but normally you do not need to use that. The
+class type associated with a binfo is given by `BINFO_TYPE'. It is not
+always the case that `BINFO_TYPE (TYPE_BINFO (x))', because of typedefs
+and qualified types. Neither is it the case that `TYPE_BINFO
+(BINFO_TYPE (y))' is the same binfo as `y'. The reason is that if `y'
+is a binfo representing a base-class `B' of a derived class `D', then
+`BINFO_TYPE (y)' will be `B', and `TYPE_BINFO (BINFO_TYPE (y))' will be
+`B' as its own base-class, rather than as a base-class of `D'.
+
+ The access to a base type can be found with `BINFO_BASE_ACCESS'. This
+will produce `access_public_node', `access_private_node' or
+`access_protected_node'. If bases are always public,
+`BINFO_BASE_ACCESSES' may be `NULL'.
+
+ `BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited
+virtually or not. The other flags, `BINFO_MARKED_P' and `BINFO_FLAG_1'
+to `BINFO_FLAG_6' can be used for language specific use.
+
+ The following macros can be used on a tree node representing a
+class-type.
+
+`LOCAL_CLASS_P'
+ This predicate holds if the class is local class _i.e._ declared
+ inside a function body.
+
+`TYPE_POLYMORPHIC_P'
+ This predicate holds if the class has at least one virtual function
+ (declared or inherited).
+
+`TYPE_HAS_DEFAULT_CONSTRUCTOR'
+ This predicate holds whenever its argument represents a class-type
+ with default constructor.
+
+`CLASSTYPE_HAS_MUTABLE'
+`TYPE_HAS_MUTABLE_P'
+ These predicates hold for a class-type having a mutable data
+ member.
+
+`CLASSTYPE_NON_POD_P'
+ This predicate holds only for class-types that are not PODs.
+
+`TYPE_HAS_NEW_OPERATOR'
+ This predicate holds for a class-type that defines `operator new'.
+
+`TYPE_HAS_ARRAY_NEW_OPERATOR'
+ This predicate holds for a class-type for which `operator new[]'
+ is defined.
+
+`TYPE_OVERLOADS_CALL_EXPR'
+ This predicate holds for class-type for which the function call
+ `operator()' is overloaded.
+
+`TYPE_OVERLOADS_ARRAY_REF'
+ This predicate holds for a class-type that overloads `operator[]'
+
+`TYPE_OVERLOADS_ARROW'
+ This predicate holds for a class-type for which `operator->' is
+ overloaded.
+
+
+\1f
+File: gccint.info, Node: Declarations, Next: Attributes, Prev: Functions, Up: Trees
+
+9.5 Declarations
+================
+
+This section covers the various kinds of declarations that appear in the
+internal representation, except for declarations of functions
+(represented by `FUNCTION_DECL' nodes), which are described in *note
+Functions::.
+
+* Menu:
+
+* Working with declarations:: Macros and functions that work on
+declarations.
+* Internal structure:: How declaration nodes are represented.
+
+\1f
+File: gccint.info, Node: Working with declarations, Next: Internal structure, Up: Declarations
+
+9.5.1 Working with declarations
+-------------------------------
+
+Some macros can be used with any kind of declaration. These include:
+`DECL_NAME'
+ This macro returns an `IDENTIFIER_NODE' giving the name of the
+ entity.
+
+`TREE_TYPE'
+ This macro returns the type of the entity declared.
+
+`TREE_FILENAME'
+ This macro returns the name of the file in which the entity was
+ declared, as a `char*'. For an entity declared implicitly by the
+ compiler (like `__builtin_memcpy'), this will be the string
+ `"<internal>"'.
+
+`TREE_LINENO'
+ This macro returns the line number at which the entity was
+ declared, as an `int'.
+
+`DECL_ARTIFICIAL'
+ This predicate holds if the declaration was implicitly generated
+ by the compiler. For example, this predicate will hold of an
+ implicitly declared member function, or of the `TYPE_DECL'
+ implicitly generated for a class type. Recall that in C++ code
+ like:
+ struct S {};
+ is roughly equivalent to C code like:
+ struct S {};
+ typedef struct S S;
+ The implicitly generated `typedef' declaration is represented by a
+ `TYPE_DECL' for which `DECL_ARTIFICIAL' holds.
+
+`DECL_NAMESPACE_SCOPE_P'
+ This predicate holds if the entity was declared at a namespace
+ scope.
+
+`DECL_CLASS_SCOPE_P'
+ This predicate holds if the entity was declared at a class scope.
+
+`DECL_FUNCTION_SCOPE_P'
+ This predicate holds if the entity was declared inside a function
+ body.
+
+
+ The various kinds of declarations include:
+`LABEL_DECL'
+ These nodes are used to represent labels in function bodies. For
+ more information, see *note Functions::. These nodes only appear
+ in block scopes.
+
+`CONST_DECL'
+ These nodes are used to represent enumeration constants. The
+ value of the constant is given by `DECL_INITIAL' which will be an
+ `INTEGER_CST' with the same type as the `TREE_TYPE' of the
+ `CONST_DECL', i.e., an `ENUMERAL_TYPE'.
+
+`RESULT_DECL'
+ These nodes represent the value returned by a function. When a
+ value is assigned to a `RESULT_DECL', that indicates that the
+ value should be returned, via bitwise copy, by the function. You
+ can use `DECL_SIZE' and `DECL_ALIGN' on a `RESULT_DECL', just as
+ with a `VAR_DECL'.
+
+`TYPE_DECL'
+ These nodes represent `typedef' declarations. The `TREE_TYPE' is
+ the type declared to have the name given by `DECL_NAME'. In some
+ cases, there is no associated name.
+
+`VAR_DECL'
+ These nodes represent variables with namespace or block scope, as
+ well as static data members. The `DECL_SIZE' and `DECL_ALIGN' are
+ analogous to `TYPE_SIZE' and `TYPE_ALIGN'. For a declaration, you
+ should always use the `DECL_SIZE' and `DECL_ALIGN' rather than the
+ `TYPE_SIZE' and `TYPE_ALIGN' given by the `TREE_TYPE', since
+ special attributes may have been applied to the variable to give
+ it a particular size and alignment. You may use the predicates
+ `DECL_THIS_STATIC' or `DECL_THIS_EXTERN' to test whether the
+ storage class specifiers `static' or `extern' were used to declare
+ a variable.
+
+ If this variable is initialized (but does not require a
+ constructor), the `DECL_INITIAL' will be an expression for the
+ initializer. The initializer should be evaluated, and a bitwise
+ copy into the variable performed. If the `DECL_INITIAL' is the
+ `error_mark_node', there is an initializer, but it is given by an
+ explicit statement later in the code; no bitwise copy is required.
+
+ GCC provides an extension that allows either automatic variables,
+ or global variables, to be placed in particular registers. This
+ extension is being used for a particular `VAR_DECL' if
+ `DECL_REGISTER' holds for the `VAR_DECL', and if
+ `DECL_ASSEMBLER_NAME' is not equal to `DECL_NAME'. In that case,
+ `DECL_ASSEMBLER_NAME' is the name of the register into which the
+ variable will be placed.
+
+`PARM_DECL'
+ Used to represent a parameter to a function. Treat these nodes
+ similarly to `VAR_DECL' nodes. These nodes only appear in the
+ `DECL_ARGUMENTS' for a `FUNCTION_DECL'.
+
+ The `DECL_ARG_TYPE' for a `PARM_DECL' is the type that will
+ actually be used when a value is passed to this function. It may
+ be a wider type than the `TREE_TYPE' of the parameter; for
+ example, the ordinary type might be `short' while the
+ `DECL_ARG_TYPE' is `int'.
+
+`FIELD_DECL'
+ These nodes represent non-static data members. The `DECL_SIZE' and
+ `DECL_ALIGN' behave as for `VAR_DECL' nodes. The position of the
+ field within the parent record is specified by a combination of
+ three attributes. `DECL_FIELD_OFFSET' is the position, counting
+ in bytes, of the `DECL_OFFSET_ALIGN'-bit sized word containing the
+ bit of the field closest to the beginning of the structure.
+ `DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the
+ field within this word; this may be nonzero even for fields that
+ are not bit-fields, since `DECL_OFFSET_ALIGN' may be greater than
+ the natural alignment of the field's type.
+
+ If `DECL_C_BIT_FIELD' holds, this field is a bit-field. In a
+ bit-field, `DECL_BIT_FIELD_TYPE' also contains the type that was
+ originally specified for it, while DECL_TYPE may be a modified
+ type with lesser precision, according to the size of the bit field.
+
+`NAMESPACE_DECL'
+ *Note Namespaces::.
+
+`TEMPLATE_DECL'
+ These nodes are used to represent class, function, and variable
+ (static data member) templates. The
+ `DECL_TEMPLATE_SPECIALIZATIONS' are a `TREE_LIST'. The
+ `TREE_VALUE' of each node in the list is a `TEMPLATE_DECL's or
+ `FUNCTION_DECL's representing specializations (including
+ instantiations) of this template. Back ends can safely ignore
+ `TEMPLATE_DECL's, but should examine `FUNCTION_DECL' nodes on the
+ specializations list just as they would ordinary `FUNCTION_DECL'
+ nodes.
+
+ For a class template, the `DECL_TEMPLATE_INSTANTIATIONS' list
+ contains the instantiations. The `TREE_VALUE' of each node is an
+ instantiation of the class. The `DECL_TEMPLATE_SPECIALIZATIONS'
+ contains partial specializations of the class.
+
+`USING_DECL'
+ Back ends can safely ignore these nodes.
+
+
+\1f
+File: gccint.info, Node: Internal structure, Prev: Working with declarations, Up: Declarations
+
+9.5.2 Internal structure
+------------------------
+
+`DECL' nodes are represented internally as a hierarchy of structures.
+
+* Menu:
+
+* Current structure hierarchy:: The current DECL node structure
+hierarchy.
+* Adding new DECL node types:: How to add a new DECL node to a
+frontend.
+
+\1f
+File: gccint.info, Node: Current structure hierarchy, Next: Adding new DECL node types, Up: Internal structure
+
+9.5.2.1 Current structure hierarchy
+...................................
+
+`struct tree_decl_minimal'
+ This is the minimal structure to inherit from in order for common
+ `DECL' macros to work. The fields it contains are a unique ID,
+ source location, context, and name.
+
+`struct tree_decl_common'
+ This structure inherits from `struct tree_decl_minimal'. It
+ contains fields that most `DECL' nodes need, such as a field to
+ store alignment, machine mode, size, and attributes.
+
+`struct tree_field_decl'
+ This structure inherits from `struct tree_decl_common'. It is
+ used to represent `FIELD_DECL'.
+
+`struct tree_label_decl'
+ This structure inherits from `struct tree_decl_common'. It is
+ used to represent `LABEL_DECL'.
+
+`struct tree_translation_unit_decl'
+ This structure inherits from `struct tree_decl_common'. It is
+ used to represent `TRANSLATION_UNIT_DECL'.
+
+`struct tree_decl_with_rtl'
+ This structure inherits from `struct tree_decl_common'. It
+ contains a field to store the low-level RTL associated with a
+ `DECL' node.
+
+`struct tree_result_decl'
+ This structure inherits from `struct tree_decl_with_rtl'. It is
+ used to represent `RESULT_DECL'.
+
+`struct tree_const_decl'
+ This structure inherits from `struct tree_decl_with_rtl'. It is
+ used to represent `CONST_DECL'.
+
+`struct tree_parm_decl'
+ This structure inherits from `struct tree_decl_with_rtl'. It is
+ used to represent `PARM_DECL'.
+
+`struct tree_decl_with_vis'
+ This structure inherits from `struct tree_decl_with_rtl'. It
+ contains fields necessary to store visibility information, as well
+ as a section name and assembler name.
+
+`struct tree_var_decl'
+ This structure inherits from `struct tree_decl_with_vis'. It is
+ used to represent `VAR_DECL'.
+
+`struct tree_function_decl'
+ This structure inherits from `struct tree_decl_with_vis'. It is
+ used to represent `FUNCTION_DECL'.
+
+
+\1f
+File: gccint.info, Node: Adding new DECL node types, Prev: Current structure hierarchy, Up: Internal structure
+
+9.5.2.2 Adding new DECL node types
+..................................
+
+Adding a new `DECL' tree consists of the following steps
+
+Add a new tree code for the `DECL' node
+ For language specific `DECL' nodes, there is a `.def' file in each
+ frontend directory where the tree code should be added. For
+ `DECL' nodes that are part of the middle-end, the code should be
+ added to `tree.def'.
+
+Create a new structure type for the `DECL' node
+ These structures should inherit from one of the existing
+ structures in the language hierarchy by using that structure as
+ the first member.
+
+ struct tree_foo_decl
+ {
+ struct tree_decl_with_vis common;
+ }
+
+ Would create a structure name `tree_foo_decl' that inherits from
+ `struct tree_decl_with_vis'.
+
+ For language specific `DECL' nodes, this new structure type should
+ go in the appropriate `.h' file. For `DECL' nodes that are part
+ of the middle-end, the structure type should go in `tree.h'.
+
+Add a member to the tree structure enumerator for the node
+ For garbage collection and dynamic checking purposes, each `DECL'
+ node structure type is required to have a unique enumerator value
+ specified with it. For language specific `DECL' nodes, this new
+ enumerator value should go in the appropriate `.def' file. For
+ `DECL' nodes that are part of the middle-end, the enumerator
+ values are specified in `treestruct.def'.
+
+Update `union tree_node'
+ In order to make your new structure type usable, it must be added
+ to `union tree_node'. For language specific `DECL' nodes, a new
+ entry should be added to the appropriate `.h' file of the form
+ struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl;
+ For `DECL' nodes that are part of the middle-end, the additional
+ member goes directly into `union tree_node' in `tree.h'.
+
+Update dynamic checking info
+ In order to be able to check whether accessing a named portion of
+ `union tree_node' is legal, and whether a certain `DECL' node
+ contains one of the enumerated `DECL' node structures in the
+ hierarchy, a simple lookup table is used. This lookup table needs
+ to be kept up to date with the tree structure hierarchy, or else
+ checking and containment macros will fail inappropriately.
+
+ For language specific `DECL' nodes, their is an `init_ts' function
+ in an appropriate `.c' file, which initializes the lookup table.
+ Code setting up the table for new `DECL' nodes should be added
+ there. For each `DECL' tree code and enumerator value
+ representing a member of the inheritance hierarchy, the table
+ should contain 1 if that tree code inherits (directly or
+ indirectly) from that member. Thus, a `FOO_DECL' node derived
+ from `struct decl_with_rtl', and enumerator value `TS_FOO_DECL',
+ would be set up as follows
+ tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1;
+ tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1;
+ tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1;
+ tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1;
+
+ For `DECL' nodes that are part of the middle-end, the setup code
+ goes into `tree.c'.
+
+Add macros to access any new fields and flags
+ Each added field or flag should have a macro that is used to access
+ it, that performs appropriate checking to ensure only the right
+ type of `DECL' nodes access the field.
+
+ These macros generally take the following form
+ #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname
+ However, if the structure is simply a base class for further
+ structures, something like the following should be used
+ #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT)
+ #define BASE_STRUCT_FIELDNAME(NODE) \
+ (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname
+
+
+\1f
+File: gccint.info, Node: Functions, Next: Declarations, Prev: Scopes, Up: Trees
+
+9.6 Functions
+=============
+
+A function is represented by a `FUNCTION_DECL' node. A set of
+overloaded functions is sometimes represented by a `OVERLOAD' node.
+
+ An `OVERLOAD' node is not a declaration, so none of the `DECL_' macros
+should be used on an `OVERLOAD'. An `OVERLOAD' node is similar to a
+`TREE_LIST'. Use `OVL_CURRENT' to get the function associated with an
+`OVERLOAD' node; use `OVL_NEXT' to get the next `OVERLOAD' node in the
+list of overloaded functions. The macros `OVL_CURRENT' and `OVL_NEXT'
+are actually polymorphic; you can use them to work with `FUNCTION_DECL'
+nodes as well as with overloads. In the case of a `FUNCTION_DECL',
+`OVL_CURRENT' will always return the function itself, and `OVL_NEXT'
+will always be `NULL_TREE'.
+
+ To determine the scope of a function, you can use the `DECL_CONTEXT'
+macro. This macro will return the class (either a `RECORD_TYPE' or a
+`UNION_TYPE') or namespace (a `NAMESPACE_DECL') of which the function
+is a member. For a virtual function, this macro returns the class in
+which the function was actually defined, not the base class in which
+the virtual declaration occurred.
+
+ If a friend function is defined in a class scope, the
+`DECL_FRIEND_CONTEXT' macro can be used to determine the class in which
+it was defined. For example, in
+ class C { friend void f() {} };
+ the `DECL_CONTEXT' for `f' will be the `global_namespace', but the
+`DECL_FRIEND_CONTEXT' will be the `RECORD_TYPE' for `C'.
+
+ In C, the `DECL_CONTEXT' for a function maybe another function. This
+representation indicates that the GNU nested function extension is in
+use. For details on the semantics of nested functions, see the GCC
+Manual. The nested function can refer to local variables in its
+containing function. Such references are not explicitly marked in the
+tree structure; back ends must look at the `DECL_CONTEXT' for the
+referenced `VAR_DECL'. If the `DECL_CONTEXT' for the referenced
+`VAR_DECL' is not the same as the function currently being processed,
+and neither `DECL_EXTERNAL' nor `TREE_STATIC' hold, then the reference
+is to a local variable in a containing function, and the back end must
+take appropriate action.
+
+* Menu:
+
+* Function Basics:: Function names, linkage, and so forth.
+* Function Bodies:: The statements that make up a function body.
+
+\1f
+File: gccint.info, Node: Function Basics, Next: Function Bodies, Up: Functions
+
+9.6.1 Function Basics
+---------------------
+
+The following macros and functions can be used on a `FUNCTION_DECL':
+`DECL_MAIN_P'
+ This predicate holds for a function that is the program entry point
+ `::code'.
+
+`DECL_NAME'
+ This macro returns the unqualified name of the function, as an
+ `IDENTIFIER_NODE'. For an instantiation of a function template,
+ the `DECL_NAME' is the unqualified name of the template, not
+ something like `f<int>'. The value of `DECL_NAME' is undefined
+ when used on a constructor, destructor, overloaded operator, or
+ type-conversion operator, or any function that is implicitly
+ generated by the compiler. See below for macros that can be used
+ to distinguish these cases.
+
+`DECL_ASSEMBLER_NAME'
+ This macro returns the mangled name of the function, also an
+ `IDENTIFIER_NODE'. This name does not contain leading underscores
+ on systems that prefix all identifiers with underscores. The
+ mangled name is computed in the same way on all platforms; if
+ special processing is required to deal with the object file format
+ used on a particular platform, it is the responsibility of the
+ back end to perform those modifications. (Of course, the back end
+ should not modify `DECL_ASSEMBLER_NAME' itself.)
+
+ Using `DECL_ASSEMBLER_NAME' will cause additional memory to be
+ allocated (for the mangled name of the entity) so it should be used
+ only when emitting assembly code. It should not be used within the
+ optimizers to determine whether or not two declarations are the
+ same, even though some of the existing optimizers do use it in
+ that way. These uses will be removed over time.
+
+`DECL_EXTERNAL'
+ This predicate holds if the function is undefined.
+
+`TREE_PUBLIC'
+ This predicate holds if the function has external linkage.
+
+`DECL_LOCAL_FUNCTION_P'
+ This predicate holds if the function was declared at block scope,
+ even though it has a global scope.
+
+`DECL_ANTICIPATED'
+ This predicate holds if the function is a built-in function but its
+ prototype is not yet explicitly declared.
+
+`DECL_EXTERN_C_FUNCTION_P'
+ This predicate holds if the function is declared as an ``extern
+ "C"'' function.
+
+`DECL_LINKONCE_P'
+ This macro holds if multiple copies of this function may be
+ emitted in various translation units. It is the responsibility of
+ the linker to merge the various copies. Template instantiations
+ are the most common example of functions for which
+ `DECL_LINKONCE_P' holds; G++ instantiates needed templates in all
+ translation units which require them, and then relies on the
+ linker to remove duplicate instantiations.
+
+ FIXME: This macro is not yet implemented.
+
+`DECL_FUNCTION_MEMBER_P'
+ This macro holds if the function is a member of a class, rather
+ than a member of a namespace.
+
+`DECL_STATIC_FUNCTION_P'
+ This predicate holds if the function a static member function.
+
+`DECL_NONSTATIC_MEMBER_FUNCTION_P'
+ This macro holds for a non-static member function.
+
+`DECL_CONST_MEMFUNC_P'
+ This predicate holds for a `const'-member function.
+
+`DECL_VOLATILE_MEMFUNC_P'
+ This predicate holds for a `volatile'-member function.
+
+`DECL_CONSTRUCTOR_P'
+ This macro holds if the function is a constructor.
+
+`DECL_NONCONVERTING_P'
+ This predicate holds if the constructor is a non-converting
+ constructor.
+
+`DECL_COMPLETE_CONSTRUCTOR_P'
+ This predicate holds for a function which is a constructor for an
+ object of a complete type.
+
+`DECL_BASE_CONSTRUCTOR_P'
+ This predicate holds for a function which is a constructor for a
+ base class sub-object.
+
+`DECL_COPY_CONSTRUCTOR_P'
+ This predicate holds for a function which is a copy-constructor.
+
+`DECL_DESTRUCTOR_P'
+ This macro holds if the function is a destructor.
+
+`DECL_COMPLETE_DESTRUCTOR_P'
+ This predicate holds if the function is the destructor for an
+ object a complete type.
+
+`DECL_OVERLOADED_OPERATOR_P'
+ This macro holds if the function is an overloaded operator.
+
+`DECL_CONV_FN_P'
+ This macro holds if the function is a type-conversion operator.
+
+`DECL_GLOBAL_CTOR_P'
+ This predicate holds if the function is a file-scope initialization
+ function.
+
+`DECL_GLOBAL_DTOR_P'
+ This predicate holds if the function is a file-scope finalization
+ function.
+
+`DECL_THUNK_P'
+ This predicate holds if the function is a thunk.
+
+ These functions represent stub code that adjusts the `this' pointer
+ and then jumps to another function. When the jumped-to function
+ returns, control is transferred directly to the caller, without
+ returning to the thunk. The first parameter to the thunk is
+ always the `this' pointer; the thunk should add `THUNK_DELTA' to
+ this value. (The `THUNK_DELTA' is an `int', not an `INTEGER_CST'.)
+
+ Then, if `THUNK_VCALL_OFFSET' (an `INTEGER_CST') is nonzero the
+ adjusted `this' pointer must be adjusted again. The complete
+ calculation is given by the following pseudo-code:
+
+ this += THUNK_DELTA
+ if (THUNK_VCALL_OFFSET)
+ this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET]
+
+ Finally, the thunk should jump to the location given by
+ `DECL_INITIAL'; this will always be an expression for the address
+ of a function.
+
+`DECL_NON_THUNK_FUNCTION_P'
+ This predicate holds if the function is _not_ a thunk function.
+
+`GLOBAL_INIT_PRIORITY'
+ If either `DECL_GLOBAL_CTOR_P' or `DECL_GLOBAL_DTOR_P' holds, then
+ this gives the initialization priority for the function. The
+ linker will arrange that all functions for which
+ `DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority
+ before `main' is called. When the program exits, all functions for
+ which `DECL_GLOBAL_DTOR_P' holds are run in the reverse order.
+
+`DECL_ARTIFICIAL'
+ This macro holds if the function was implicitly generated by the
+ compiler, rather than explicitly declared. In addition to
+ implicitly generated class member functions, this macro holds for
+ the special functions created to implement static initialization
+ and destruction, to compute run-time type information, and so
+ forth.
+
+`DECL_ARGUMENTS'
+ This macro returns the `PARM_DECL' for the first argument to the
+ function. Subsequent `PARM_DECL' nodes can be obtained by
+ following the `TREE_CHAIN' links.
+
+`DECL_RESULT'
+ This macro returns the `RESULT_DECL' for the function.
+
+`TREE_TYPE'
+ This macro returns the `FUNCTION_TYPE' or `METHOD_TYPE' for the
+ function.
+
+`TYPE_RAISES_EXCEPTIONS'
+ This macro returns the list of exceptions that a (member-)function
+ can raise. The returned list, if non `NULL', is comprised of nodes
+ whose `TREE_VALUE' represents a type.
+
+`TYPE_NOTHROW_P'
+ This predicate holds when the exception-specification of its
+ arguments is of the form ``()''.
+
+`DECL_ARRAY_DELETE_OPERATOR_P'
+ This predicate holds if the function an overloaded `operator
+ delete[]'.
+
+`DECL_FUNCTION_SPECIFIC_TARGET'
+ This macro returns a tree node that holds the target options that
+ are to be used to compile this particular function or `NULL_TREE'
+ if the function is to be compiled with the target options
+ specified on the command line.
+
+`DECL_FUNCTION_SPECIFIC_OPTIMIZATION'
+ This macro returns a tree node that holds the optimization options
+ that are to be used to compile this particular function or
+ `NULL_TREE' if the function is to be compiled with the
+ optimization options specified on the command line.
+
+\1f
+File: gccint.info, Node: Function Bodies, Prev: Function Basics, Up: Functions
+
+9.6.2 Function Bodies
+---------------------
+
+A function that has a definition in the current translation unit will
+have a non-`NULL' `DECL_INITIAL'. However, back ends should not make
+use of the particular value given by `DECL_INITIAL'.
+
+ The `DECL_SAVED_TREE' macro will give the complete body of the
+function.
+
+9.6.2.1 Statements
+..................
+
+There are tree nodes corresponding to all of the source-level statement
+constructs, used within the C and C++ frontends. These are enumerated
+here, together with a list of the various macros that can be used to
+obtain information about them. There are a few macros that can be used
+with all statements:
+
+`STMT_IS_FULL_EXPR_P'
+ In C++, statements normally constitute "full expressions";
+ temporaries created during a statement are destroyed when the
+ statement is complete. However, G++ sometimes represents
+ expressions by statements; these statements will not have
+ `STMT_IS_FULL_EXPR_P' set. Temporaries created during such
+ statements should be destroyed when the innermost enclosing
+ statement with `STMT_IS_FULL_EXPR_P' set is exited.
+
+
+ Here is the list of the various statement nodes, and the macros used to
+access them. This documentation describes the use of these nodes in
+non-template functions (including instantiations of template functions).
+In template functions, the same nodes are used, but sometimes in
+slightly different ways.
+
+ Many of the statements have substatements. For example, a `while'
+loop will have a body, which is itself a statement. If the substatement
+is `NULL_TREE', it is considered equivalent to a statement consisting
+of a single `;', i.e., an expression statement in which the expression
+has been omitted. A substatement may in fact be a list of statements,
+connected via their `TREE_CHAIN's. So, you should always process the
+statement tree by looping over substatements, like this:
+ void process_stmt (stmt)
+ tree stmt;
+ {
+ while (stmt)
+ {
+ switch (TREE_CODE (stmt))
+ {
+ case IF_STMT:
+ process_stmt (THEN_CLAUSE (stmt));
+ /* More processing here. */
+ break;
+
+ ...
+ }
+
+ stmt = TREE_CHAIN (stmt);
+ }
+ }
+ In other words, while the `then' clause of an `if' statement in C++
+can be only one statement (although that one statement may be a
+compound statement), the intermediate representation will sometimes use
+several statements chained together.
+
+`ASM_EXPR'
+ Used to represent an inline assembly statement. For an inline
+ assembly statement like:
+ asm ("mov x, y");
+ The `ASM_STRING' macro will return a `STRING_CST' node for `"mov
+ x, y"'. If the original statement made use of the
+ extended-assembly syntax, then `ASM_OUTPUTS', `ASM_INPUTS', and
+ `ASM_CLOBBERS' will be the outputs, inputs, and clobbers for the
+ statement, represented as `STRING_CST' nodes. The
+ extended-assembly syntax looks like:
+ asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
+ The first string is the `ASM_STRING', containing the instruction
+ template. The next two strings are the output and inputs,
+ respectively; this statement has no clobbers. As this example
+ indicates, "plain" assembly statements are merely a special case
+ of extended assembly statements; they have no cv-qualifiers,
+ outputs, inputs, or clobbers. All of the strings will be
+ `NUL'-terminated, and will contain no embedded `NUL'-characters.
+
+ If the assembly statement is declared `volatile', or if the
+ statement was not an extended assembly statement, and is therefore
+ implicitly volatile, then the predicate `ASM_VOLATILE_P' will hold
+ of the `ASM_EXPR'.
+
+`BREAK_STMT'
+ Used to represent a `break' statement. There are no additional
+ fields.
+
+`CASE_LABEL_EXPR'
+ Use to represent a `case' label, range of `case' labels, or a
+ `default' label. If `CASE_LOW' is `NULL_TREE', then this is a
+ `default' label. Otherwise, if `CASE_HIGH' is `NULL_TREE', then
+ this is an ordinary `case' label. In this case, `CASE_LOW' is an
+ expression giving the value of the label. Both `CASE_LOW' and
+ `CASE_HIGH' are `INTEGER_CST' nodes. These values will have the
+ same type as the condition expression in the switch statement.
+
+ Otherwise, if both `CASE_LOW' and `CASE_HIGH' are defined, the
+ statement is a range of case labels. Such statements originate
+ with the extension that allows users to write things of the form:
+ case 2 ... 5:
+ The first value will be `CASE_LOW', while the second will be
+ `CASE_HIGH'.
+
+`CLEANUP_STMT'
+ Used to represent an action that should take place upon exit from
+ the enclosing scope. Typically, these actions are calls to
+ destructors for local objects, but back ends cannot rely on this
+ fact. If these nodes are in fact representing such destructors,
+ `CLEANUP_DECL' will be the `VAR_DECL' destroyed. Otherwise,
+ `CLEANUP_DECL' will be `NULL_TREE'. In any case, the
+ `CLEANUP_EXPR' is the expression to execute. The cleanups
+ executed on exit from a scope should be run in the reverse order
+ of the order in which the associated `CLEANUP_STMT's were
+ encountered.
+
+`CONTINUE_STMT'
+ Used to represent a `continue' statement. There are no additional
+ fields.
+
+`CTOR_STMT'
+ Used to mark the beginning (if `CTOR_BEGIN_P' holds) or end (if
+ `CTOR_END_P' holds of the main body of a constructor. See also
+ `SUBOBJECT' for more information on how to use these nodes.
+
+`DECL_STMT'
+ Used to represent a local declaration. The `DECL_STMT_DECL' macro
+ can be used to obtain the entity declared. This declaration may
+ be a `LABEL_DECL', indicating that the label declared is a local
+ label. (As an extension, GCC allows the declaration of labels
+ with scope.) In C, this declaration may be a `FUNCTION_DECL',
+ indicating the use of the GCC nested function extension. For more
+ information, *note Functions::.
+
+`DO_STMT'
+ Used to represent a `do' loop. The body of the loop is given by
+ `DO_BODY' while the termination condition for the loop is given by
+ `DO_COND'. The condition for a `do'-statement is always an
+ expression.
+
+`EMPTY_CLASS_EXPR'
+ Used to represent a temporary object of a class with no data whose
+ address is never taken. (All such objects are interchangeable.)
+ The `TREE_TYPE' represents the type of the object.
+
+`EXPR_STMT'
+ Used to represent an expression statement. Use `EXPR_STMT_EXPR' to
+ obtain the expression.
+
+`FOR_STMT'
+ Used to represent a `for' statement. The `FOR_INIT_STMT' is the
+ initialization statement for the loop. The `FOR_COND' is the
+ termination condition. The `FOR_EXPR' is the expression executed
+ right before the `FOR_COND' on each loop iteration; often, this
+ expression increments a counter. The body of the loop is given by
+ `FOR_BODY'. Note that `FOR_INIT_STMT' and `FOR_BODY' return
+ statements, while `FOR_COND' and `FOR_EXPR' return expressions.
+
+`GOTO_EXPR'
+ Used to represent a `goto' statement. The `GOTO_DESTINATION' will
+ usually be a `LABEL_DECL'. However, if the "computed goto"
+ extension has been used, the `GOTO_DESTINATION' will be an
+ arbitrary expression indicating the destination. This expression
+ will always have pointer type.
+
+`HANDLER'
+ Used to represent a C++ `catch' block. The `HANDLER_TYPE' is the
+ type of exception that will be caught by this handler; it is equal
+ (by pointer equality) to `NULL' if this handler is for all types.
+ `HANDLER_PARMS' is the `DECL_STMT' for the catch parameter, and
+ `HANDLER_BODY' is the code for the block itself.
+
+`IF_STMT'
+ Used to represent an `if' statement. The `IF_COND' is the
+ expression.
+
+ If the condition is a `TREE_LIST', then the `TREE_PURPOSE' is a
+ statement (usually a `DECL_STMT'). Each time the condition is
+ evaluated, the statement should be executed. Then, the
+ `TREE_VALUE' should be used as the conditional expression itself.
+ This representation is used to handle C++ code like this:
+
+ if (int i = 7) ...
+
+ where there is a new local variable (or variables) declared within
+ the condition.
+
+ The `THEN_CLAUSE' represents the statement given by the `then'
+ condition, while the `ELSE_CLAUSE' represents the statement given
+ by the `else' condition.
+
+`LABEL_EXPR'
+ Used to represent a label. The `LABEL_DECL' declared by this
+ statement can be obtained with the `LABEL_EXPR_LABEL' macro. The
+ `IDENTIFIER_NODE' giving the name of the label can be obtained from
+ the `LABEL_DECL' with `DECL_NAME'.
+
+`RETURN_STMT'
+ Used to represent a `return' statement. The `RETURN_EXPR' is the
+ expression returned; it will be `NULL_TREE' if the statement was
+ just
+ return;
+
+`SUBOBJECT'
+ In a constructor, these nodes are used to mark the point at which a
+ subobject of `this' is fully constructed. If, after this point, an
+ exception is thrown before a `CTOR_STMT' with `CTOR_END_P' set is
+ encountered, the `SUBOBJECT_CLEANUP' must be executed. The
+ cleanups must be executed in the reverse order in which they
+ appear.
+
+`SWITCH_STMT'
+ Used to represent a `switch' statement. The `SWITCH_STMT_COND' is
+ the expression on which the switch is occurring. See the
+ documentation for an `IF_STMT' for more information on the
+ representation used for the condition. The `SWITCH_STMT_BODY' is
+ the body of the switch statement. The `SWITCH_STMT_TYPE' is the
+ original type of switch expression as given in the source, before
+ any compiler conversions.
+
+`TRY_BLOCK'
+ Used to represent a `try' block. The body of the try block is
+ given by `TRY_STMTS'. Each of the catch blocks is a `HANDLER'
+ node. The first handler is given by `TRY_HANDLERS'. Subsequent
+ handlers are obtained by following the `TREE_CHAIN' link from one
+ handler to the next. The body of the handler is given by
+ `HANDLER_BODY'.
+
+ If `CLEANUP_P' holds of the `TRY_BLOCK', then the `TRY_HANDLERS'
+ will not be a `HANDLER' node. Instead, it will be an expression
+ that should be executed if an exception is thrown in the try
+ block. It must rethrow the exception after executing that code.
+ And, if an exception is thrown while the expression is executing,
+ `terminate' must be called.
+
+`USING_STMT'
+ Used to represent a `using' directive. The namespace is given by
+ `USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node
+ is needed inside template functions, to implement using directives
+ during instantiation.
+
+`WHILE_STMT'
+ Used to represent a `while' loop. The `WHILE_COND' is the
+ termination condition for the loop. See the documentation for an
+ `IF_STMT' for more information on the representation used for the
+ condition.
+
+ The `WHILE_BODY' is the body of the loop.
+
+
+\1f
+File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: Trees
+
+9.7 Attributes in trees
+=======================
+
+Attributes, as specified using the `__attribute__' keyword, are
+represented internally as a `TREE_LIST'. The `TREE_PURPOSE' is the
+name of the attribute, as an `IDENTIFIER_NODE'. The `TREE_VALUE' is a
+`TREE_LIST' of the arguments of the attribute, if any, or `NULL_TREE'
+if there are no arguments; the arguments are stored as the `TREE_VALUE'
+of successive entries in the list, and may be identifiers or
+expressions. The `TREE_CHAIN' of the attribute is the next attribute
+in a list of attributes applying to the same declaration or type, or
+`NULL_TREE' if there are no further attributes in the list.
+
+ Attributes may be attached to declarations and to types; these
+attributes may be accessed with the following macros. All attributes
+are stored in this way, and many also cause other changes to the
+declaration or type or to other internal compiler data structures.
+
+ -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL)
+ This macro returns the attributes on the declaration DECL.
+
+ -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE)
+ This macro returns the attributes on the type TYPE.
+
+\1f
+File: gccint.info, Node: Expression trees, Prev: Attributes, Up: Trees
+
+9.8 Expressions
+===============
+
+The internal representation for expressions is for the most part quite
+straightforward. However, there are a few facts that one must bear in
+mind. In particular, the expression "tree" is actually a directed
+acyclic graph. (For example there may be many references to the integer
+constant zero throughout the source program; many of these will be
+represented by the same expression node.) You should not rely on
+certain kinds of node being shared, nor should you rely on certain
+kinds of nodes being unshared.
+
+ The following macros can be used with all expression nodes:
+
+`TREE_TYPE'
+ Returns the type of the expression. This value may not be
+ precisely the same type that would be given the expression in the
+ original program.
+
+ In what follows, some nodes that one might expect to always have type
+`bool' are documented to have either integral or boolean type. At some
+point in the future, the C front end may also make use of this same
+intermediate representation, and at this point these nodes will
+certainly have integral type. The previous sentence is not meant to
+imply that the C++ front end does not or will not give these nodes
+integral type.
+
+ Below, we list the various kinds of expression nodes. Except where
+noted otherwise, the operands to an expression are accessed using the
+`TREE_OPERAND' macro. For example, to access the first operand to a
+binary plus expression `expr', use:
+
+ TREE_OPERAND (expr, 0)
+ As this example indicates, the operands are zero-indexed.
+
+ All the expressions starting with `OMP_' represent directives and
+clauses used by the OpenMP API `http://www.openmp.org/'.
+
+ The table below begins with constants, moves on to unary expressions,
+then proceeds to binary expressions, and concludes with various other
+kinds of expressions:
+
+`INTEGER_CST'
+ These nodes represent integer constants. Note that the type of
+ these constants is obtained with `TREE_TYPE'; they are not always
+ of type `int'. In particular, `char' constants are represented
+ with `INTEGER_CST' nodes. The value of the integer constant `e' is
+ given by
+ ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT)
+ + TREE_INST_CST_LOW (e))
+ HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms.
+ Both `TREE_INT_CST_HIGH' and `TREE_INT_CST_LOW' return a
+ `HOST_WIDE_INT'. The value of an `INTEGER_CST' is interpreted as
+ a signed or unsigned quantity depending on the type of the
+ constant. In general, the expression given above will overflow,
+ so it should not be used to calculate the value of the constant.
+
+ The variable `integer_zero_node' is an integer constant with value
+ zero. Similarly, `integer_one_node' is an integer constant with
+ value one. The `size_zero_node' and `size_one_node' variables are
+ analogous, but have type `size_t' rather than `int'.
+
+ The function `tree_int_cst_lt' is a predicate which holds if its
+ first argument is less than its second. Both constants are
+ assumed to have the same signedness (i.e., either both should be
+ signed or both should be unsigned.) The full width of the
+ constant is used when doing the comparison; the usual rules about
+ promotions and conversions are ignored. Similarly,
+ `tree_int_cst_equal' holds if the two constants are equal. The
+ `tree_int_cst_sgn' function returns the sign of a constant. The
+ value is `1', `0', or `-1' according on whether the constant is
+ greater than, equal to, or less than zero. Again, the signedness
+ of the constant's type is taken into account; an unsigned constant
+ is never less than zero, no matter what its bit-pattern.
+
+`REAL_CST'
+ FIXME: Talk about how to obtain representations of this constant,
+ do comparisons, and so forth.
+
+`FIXED_CST'
+ These nodes represent fixed-point constants. The type of these
+ constants is obtained with `TREE_TYPE'. `TREE_FIXED_CST_PTR'
+ points to to struct fixed_value; `TREE_FIXED_CST' returns the
+ structure itself. Struct fixed_value contains `data' with the
+ size of two HOST_BITS_PER_WIDE_INT and `mode' as the associated
+ fixed-point machine mode for `data'.
+
+`COMPLEX_CST'
+ These nodes are used to represent complex number constants, that
+ is a `__complex__' whose parts are constant nodes. The
+ `TREE_REALPART' and `TREE_IMAGPART' return the real and the
+ imaginary parts respectively.
+
+`VECTOR_CST'
+ These nodes are used to represent vector constants, whose parts are
+ constant nodes. Each individual constant node is either an
+ integer or a double constant node. The first operand is a
+ `TREE_LIST' of the constant nodes and is accessed through
+ `TREE_VECTOR_CST_ELTS'.
+
+`STRING_CST'
+ These nodes represent string-constants. The `TREE_STRING_LENGTH'
+ returns the length of the string, as an `int'. The
+ `TREE_STRING_POINTER' is a `char*' containing the string itself.
+ The string may not be `NUL'-terminated, and it may contain
+ embedded `NUL' characters. Therefore, the `TREE_STRING_LENGTH'
+ includes the trailing `NUL' if it is present.
+
+ For wide string constants, the `TREE_STRING_LENGTH' is the number
+ of bytes in the string, and the `TREE_STRING_POINTER' points to an
+ array of the bytes of the string, as represented on the target
+ system (that is, as integers in the target endianness). Wide and
+ non-wide string constants are distinguished only by the `TREE_TYPE'
+ of the `STRING_CST'.
+
+ FIXME: The formats of string constants are not well-defined when
+ the target system bytes are not the same width as host system
+ bytes.
+
+`PTRMEM_CST'
+ These nodes are used to represent pointer-to-member constants. The
+ `PTRMEM_CST_CLASS' is the class type (either a `RECORD_TYPE' or
+ `UNION_TYPE' within which the pointer points), and the
+ `PTRMEM_CST_MEMBER' is the declaration for the pointed to object.
+ Note that the `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is in
+ general different from the `PTRMEM_CST_CLASS'. For example, given:
+ struct B { int i; };
+ struct D : public B {};
+ int D::*dp = &D::i;
+ The `PTRMEM_CST_CLASS' for `&D::i' is `D', even though the
+ `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is `B', since `B::i' is
+ a member of `B', not `D'.
+
+`VAR_DECL'
+ These nodes represent variables, including static data members.
+ For more information, *note Declarations::.
+
+`NEGATE_EXPR'
+ These nodes represent unary negation of the single operand, for
+ both integer and floating-point types. The type of negation can be
+ determined by looking at the type of the expression.
+
+ The behavior of this operation on signed arithmetic overflow is
+ controlled by the `flag_wrapv' and `flag_trapv' variables.
+
+`ABS_EXPR'
+ These nodes represent the absolute value of the single operand, for
+ both integer and floating-point types. This is typically used to
+ implement the `abs', `labs' and `llabs' builtins for integer
+ types, and the `fabs', `fabsf' and `fabsl' builtins for floating
+ point types. The type of abs operation can be determined by
+ looking at the type of the expression.
+
+ This node is not used for complex types. To represent the modulus
+ or complex abs of a complex value, use the `BUILT_IN_CABS',
+ `BUILT_IN_CABSF' or `BUILT_IN_CABSL' builtins, as used to
+ implement the C99 `cabs', `cabsf' and `cabsl' built-in functions.
+
+`BIT_NOT_EXPR'
+ These nodes represent bitwise complement, and will always have
+ integral type. The only operand is the value to be complemented.
+
+`TRUTH_NOT_EXPR'
+ These nodes represent logical negation, and will always have
+ integral (or boolean) type. The operand is the value being
+ negated. The type of the operand and that of the result are
+ always of `BOOLEAN_TYPE' or `INTEGER_TYPE'.
+
+`PREDECREMENT_EXPR'
+`PREINCREMENT_EXPR'
+`POSTDECREMENT_EXPR'
+`POSTINCREMENT_EXPR'
+ These nodes represent increment and decrement expressions. The
+ value of the single operand is computed, and the operand
+ incremented or decremented. In the case of `PREDECREMENT_EXPR' and
+ `PREINCREMENT_EXPR', the value of the expression is the value
+ resulting after the increment or decrement; in the case of
+ `POSTDECREMENT_EXPR' and `POSTINCREMENT_EXPR' is the value before
+ the increment or decrement occurs. The type of the operand, like
+ that of the result, will be either integral, boolean, or
+ floating-point.
+
+`ADDR_EXPR'
+ These nodes are used to represent the address of an object. (These
+ expressions will always have pointer or reference type.) The
+ operand may be another expression, or it may be a declaration.
+
+ As an extension, GCC allows users to take the address of a label.
+ In this case, the operand of the `ADDR_EXPR' will be a
+ `LABEL_DECL'. The type of such an expression is `void*'.
+
+ If the object addressed is not an lvalue, a temporary is created,
+ and the address of the temporary is used.
+
+`INDIRECT_REF'
+ These nodes are used to represent the object pointed to by a
+ pointer. The operand is the pointer being dereferenced; it will
+ always have pointer or reference type.
+
+`FIX_TRUNC_EXPR'
+ These nodes represent conversion of a floating-point value to an
+ integer. The single operand will have a floating-point type, while
+ the complete expression will have an integral (or boolean) type.
+ The operand is rounded towards zero.
+
+`FLOAT_EXPR'
+ These nodes represent conversion of an integral (or boolean) value
+ to a floating-point value. The single operand will have integral
+ type, while the complete expression will have a floating-point
+ type.
+
+ FIXME: How is the operand supposed to be rounded? Is this
+ dependent on `-mieee'?
+
+`COMPLEX_EXPR'
+ These nodes are used to represent complex numbers constructed from
+ two expressions of the same (integer or real) type. The first
+ operand is the real part and the second operand is the imaginary
+ part.
+
+`CONJ_EXPR'
+ These nodes represent the conjugate of their operand.
+
+`REALPART_EXPR'
+`IMAGPART_EXPR'
+ These nodes represent respectively the real and the imaginary parts
+ of complex numbers (their sole argument).
+
+`NON_LVALUE_EXPR'
+ These nodes indicate that their one and only operand is not an
+ lvalue. A back end can treat these identically to the single
+ operand.
+
+`NOP_EXPR'
+ These nodes are used to represent conversions that do not require
+ any code-generation. For example, conversion of a `char*' to an
+ `int*' does not require any code be generated; such a conversion is
+ represented by a `NOP_EXPR'. The single operand is the expression
+ to be converted. The conversion from a pointer to a reference is
+ also represented with a `NOP_EXPR'.
+
+`CONVERT_EXPR'
+ These nodes are similar to `NOP_EXPR's, but are used in those
+ situations where code may need to be generated. For example, if an
+ `int*' is converted to an `int' code may need to be generated on
+ some platforms. These nodes are never used for C++-specific
+ conversions, like conversions between pointers to different
+ classes in an inheritance hierarchy. Any adjustments that need to
+ be made in such cases are always indicated explicitly. Similarly,
+ a user-defined conversion is never represented by a
+ `CONVERT_EXPR'; instead, the function calls are made explicit.
+
+`FIXED_CONVERT_EXPR'
+ These nodes are used to represent conversions that involve
+ fixed-point values. For example, from a fixed-point value to
+ another fixed-point value, from an integer to a fixed-point value,
+ from a fixed-point value to an integer, from a floating-point
+ value to a fixed-point value, or from a fixed-point value to a
+ floating-point value.
+
+`THROW_EXPR'
+ These nodes represent `throw' expressions. The single operand is
+ an expression for the code that should be executed to throw the
+ exception. However, there is one implicit action not represented
+ in that expression; namely the call to `__throw'. This function
+ takes no arguments. If `setjmp'/`longjmp' exceptions are used, the
+ function `__sjthrow' is called instead. The normal GCC back end
+ uses the function `emit_throw' to generate this code; you can
+ examine this function to see what needs to be done.
+
+`LSHIFT_EXPR'
+`RSHIFT_EXPR'
+ These nodes represent left and right shifts, respectively. The
+ first operand is the value to shift; it will always be of integral
+ type. The second operand is an expression for the number of bits
+ by which to shift. Right shift should be treated as arithmetic,
+ i.e., the high-order bits should be zero-filled when the
+ expression has unsigned type and filled with the sign bit when the
+ expression has signed type. Note that the result is undefined if
+ the second operand is larger than or equal to the first operand's
+ type size.
+
+`BIT_IOR_EXPR'
+`BIT_XOR_EXPR'
+`BIT_AND_EXPR'
+ These nodes represent bitwise inclusive or, bitwise exclusive or,
+ and bitwise and, respectively. Both operands will always have
+ integral type.
+
+`TRUTH_ANDIF_EXPR'
+`TRUTH_ORIF_EXPR'
+ These nodes represent logical "and" and logical "or", respectively.
+ These operators are not strict; i.e., the second operand is
+ evaluated only if the value of the expression is not determined by
+ evaluation of the first operand. The type of the operands and
+ that of the result are always of `BOOLEAN_TYPE' or `INTEGER_TYPE'.
+
+`TRUTH_AND_EXPR'
+`TRUTH_OR_EXPR'
+`TRUTH_XOR_EXPR'
+ These nodes represent logical and, logical or, and logical
+ exclusive or. They are strict; both arguments are always
+ evaluated. There are no corresponding operators in C or C++, but
+ the front end will sometimes generate these expressions anyhow, if
+ it can tell that strictness does not matter. The type of the
+ operands and that of the result are always of `BOOLEAN_TYPE' or
+ `INTEGER_TYPE'.
+
+`POINTER_PLUS_EXPR'
+ This node represents pointer arithmetic. The first operand is
+ always a pointer/reference type. The second operand is always an
+ unsigned integer type compatible with sizetype. This is the only
+ binary arithmetic operand that can operate on pointer types.
+
+`PLUS_EXPR'
+`MINUS_EXPR'
+`MULT_EXPR'
+ These nodes represent various binary arithmetic operations.
+ Respectively, these operations are addition, subtraction (of the
+ second operand from the first) and multiplication. Their operands
+ may have either integral or floating type, but there will never be
+ case in which one operand is of floating type and the other is of
+ integral type.
+
+ The behavior of these operations on signed arithmetic overflow is
+ controlled by the `flag_wrapv' and `flag_trapv' variables.
+
+`RDIV_EXPR'
+ This node represents a floating point division operation.
+
+`TRUNC_DIV_EXPR'
+`FLOOR_DIV_EXPR'
+`CEIL_DIV_EXPR'
+`ROUND_DIV_EXPR'
+ These nodes represent integer division operations that return an
+ integer result. `TRUNC_DIV_EXPR' rounds towards zero,
+ `FLOOR_DIV_EXPR' rounds towards negative infinity, `CEIL_DIV_EXPR'
+ rounds towards positive infinity and `ROUND_DIV_EXPR' rounds to
+ the closest integer. Integer division in C and C++ is truncating,
+ i.e. `TRUNC_DIV_EXPR'.
+
+ The behavior of these operations on signed arithmetic overflow,
+ when dividing the minimum signed integer by minus one, is
+ controlled by the `flag_wrapv' and `flag_trapv' variables.
+
+`TRUNC_MOD_EXPR'
+`FLOOR_MOD_EXPR'
+`CEIL_MOD_EXPR'
+`ROUND_MOD_EXPR'
+ These nodes represent the integer remainder or modulus operation.
+ The integer modulus of two operands `a' and `b' is defined as `a -
+ (a/b)*b' where the division calculated using the corresponding
+ division operator. Hence for `TRUNC_MOD_EXPR' this definition
+ assumes division using truncation towards zero, i.e.
+ `TRUNC_DIV_EXPR'. Integer remainder in C and C++ uses truncating
+ division, i.e. `TRUNC_MOD_EXPR'.
+
+`EXACT_DIV_EXPR'
+ The `EXACT_DIV_EXPR' code is used to represent integer divisions
+ where the numerator is known to be an exact multiple of the
+ denominator. This allows the backend to choose between the faster
+ of `TRUNC_DIV_EXPR', `CEIL_DIV_EXPR' and `FLOOR_DIV_EXPR' for the
+ current target.
+
+`ARRAY_REF'
+ These nodes represent array accesses. The first operand is the
+ array; the second is the index. To calculate the address of the
+ memory accessed, you must scale the index by the size of the type
+ of the array elements. The type of these expressions must be the
+ type of a component of the array. The third and fourth operands
+ are used after gimplification to represent the lower bound and
+ component size but should not be used directly; call
+ `array_ref_low_bound' and `array_ref_element_size' instead.
+
+`ARRAY_RANGE_REF'
+ These nodes represent access to a range (or "slice") of an array.
+ The operands are the same as that for `ARRAY_REF' and have the same
+ meanings. The type of these expressions must be an array whose
+ component type is the same as that of the first operand. The
+ range of that array type determines the amount of data these
+ expressions access.
+
+`TARGET_MEM_REF'
+ These nodes represent memory accesses whose address directly map to
+ an addressing mode of the target architecture. The first argument
+ is `TMR_SYMBOL' and must be a `VAR_DECL' of an object with a fixed
+ address. The second argument is `TMR_BASE' and the third one is
+ `TMR_INDEX'. The fourth argument is `TMR_STEP' and must be an
+ `INTEGER_CST'. The fifth argument is `TMR_OFFSET' and must be an
+ `INTEGER_CST'. Any of the arguments may be NULL if the
+ appropriate component does not appear in the address. Address of
+ the `TARGET_MEM_REF' is determined in the following way.
+
+ &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET
+
+ The sixth argument is the reference to the original memory access,
+ which is preserved for the purposes of the RTL alias analysis.
+ The seventh argument is a tag representing the results of tree
+ level alias analysis.
+
+`LT_EXPR'
+`LE_EXPR'
+`GT_EXPR'
+`GE_EXPR'
+`EQ_EXPR'
+`NE_EXPR'
+ These nodes represent the less than, less than or equal to, greater
+ than, greater than or equal to, equal, and not equal comparison
+ operators. The first and second operand with either be both of
+ integral type or both of floating type. The result type of these
+ expressions will always be of integral or boolean type. These
+ operations return the result type's zero value for false, and the
+ result type's one value for true.
+
+ For floating point comparisons, if we honor IEEE NaNs and either
+ operand is NaN, then `NE_EXPR' always returns true and the
+ remaining operators always return false. On some targets,
+ comparisons against an IEEE NaN, other than equality and
+ inequality, may generate a floating point exception.
+
+`ORDERED_EXPR'
+`UNORDERED_EXPR'
+ These nodes represent non-trapping ordered and unordered comparison
+ operators. These operations take two floating point operands and
+ determine whether they are ordered or unordered relative to each
+ other. If either operand is an IEEE NaN, their comparison is
+ defined to be unordered, otherwise the comparison is defined to be
+ ordered. The result type of these expressions will always be of
+ integral or boolean type. These operations return the result
+ type's zero value for false, and the result type's one value for
+ true.
+
+`UNLT_EXPR'
+`UNLE_EXPR'
+`UNGT_EXPR'
+`UNGE_EXPR'
+`UNEQ_EXPR'
+`LTGT_EXPR'
+ These nodes represent the unordered comparison operators. These
+ operations take two floating point operands and determine whether
+ the operands are unordered or are less than, less than or equal to,
+ greater than, greater than or equal to, or equal respectively. For
+ example, `UNLT_EXPR' returns true if either operand is an IEEE NaN
+ or the first operand is less than the second. With the possible
+ exception of `LTGT_EXPR', all of these operations are guaranteed
+ not to generate a floating point exception. The result type of
+ these expressions will always be of integral or boolean type.
+ These operations return the result type's zero value for false,
+ and the result type's one value for true.
+
+`MODIFY_EXPR'
+ These nodes represent assignment. The left-hand side is the first
+ operand; the right-hand side is the second operand. The left-hand
+ side will be a `VAR_DECL', `INDIRECT_REF', `COMPONENT_REF', or
+ other lvalue.
+
+ These nodes are used to represent not only assignment with `=' but
+ also compound assignments (like `+='), by reduction to `='
+ assignment. In other words, the representation for `i += 3' looks
+ just like that for `i = i + 3'.
+
+`INIT_EXPR'
+ These nodes are just like `MODIFY_EXPR', but are used only when a
+ variable is initialized, rather than assigned to subsequently.
+ This means that we can assume that the target of the
+ initialization is not used in computing its own value; any
+ reference to the lhs in computing the rhs is undefined.
+
+`COMPONENT_REF'
+ These nodes represent non-static data member accesses. The first
+ operand is the object (rather than a pointer to it); the second
+ operand is the `FIELD_DECL' for the data member. The third
+ operand represents the byte offset of the field, but should not be
+ used directly; call `component_ref_field_offset' instead.
+
+`COMPOUND_EXPR'
+ These nodes represent comma-expressions. The first operand is an
+ expression whose value is computed and thrown away prior to the
+ evaluation of the second operand. The value of the entire
+ expression is the value of the second operand.
+
+`COND_EXPR'
+ These nodes represent `?:' expressions. The first operand is of
+ boolean or integral type. If it evaluates to a nonzero value, the
+ second operand should be evaluated, and returned as the value of
+ the expression. Otherwise, the third operand is evaluated, and
+ returned as the value of the expression.
+
+ The second operand must have the same type as the entire
+ expression, unless it unconditionally throws an exception or calls
+ a noreturn function, in which case it should have void type. The
+ same constraints apply to the third operand. This allows array
+ bounds checks to be represented conveniently as `(i >= 0 && i <
+ 10) ? i : abort()'.
+
+ As a GNU extension, the C language front-ends allow the second
+ operand of the `?:' operator may be omitted in the source. For
+ example, `x ? : 3' is equivalent to `x ? x : 3', assuming that `x'
+ is an expression without side-effects. In the tree
+ representation, however, the second operand is always present,
+ possibly protected by `SAVE_EXPR' if the first argument does cause
+ side-effects.
+
+`CALL_EXPR'
+ These nodes are used to represent calls to functions, including
+ non-static member functions. `CALL_EXPR's are implemented as
+ expression nodes with a variable number of operands. Rather than
+ using `TREE_OPERAND' to extract them, it is preferable to use the
+ specialized accessor macros and functions that operate
+ specifically on `CALL_EXPR' nodes.
+
+ `CALL_EXPR_FN' returns a pointer to the function to call; it is
+ always an expression whose type is a `POINTER_TYPE'.
+
+ The number of arguments to the call is returned by
+ `call_expr_nargs', while the arguments themselves can be accessed
+ with the `CALL_EXPR_ARG' macro. The arguments are zero-indexed
+ and numbered left-to-right. You can iterate over the arguments
+ using `FOR_EACH_CALL_EXPR_ARG', as in:
+
+ tree call, arg;
+ call_expr_arg_iterator iter;
+ FOR_EACH_CALL_EXPR_ARG (arg, iter, call)
+ /* arg is bound to successive arguments of call. */
+ ...;
+
+ For non-static member functions, there will be an operand
+ corresponding to the `this' pointer. There will always be
+ expressions corresponding to all of the arguments, even if the
+ function is declared with default arguments and some arguments are
+ not explicitly provided at the call sites.
+
+ `CALL_EXPR's also have a `CALL_EXPR_STATIC_CHAIN' operand that is
+ used to implement nested functions. This operand is otherwise
+ null.
+
+`STMT_EXPR'
+ These nodes are used to represent GCC's statement-expression
+ extension. The statement-expression extension allows code like
+ this:
+ int f() { return ({ int j; j = 3; j + 7; }); }
+ In other words, an sequence of statements may occur where a single
+ expression would normally appear. The `STMT_EXPR' node represents
+ such an expression. The `STMT_EXPR_STMT' gives the statement
+ contained in the expression. The value of the expression is the
+ value of the last sub-statement in the body. More precisely, the
+ value is the value computed by the last statement nested inside
+ `BIND_EXPR', `TRY_FINALLY_EXPR', or `TRY_CATCH_EXPR'. For
+ example, in:
+ ({ 3; })
+ the value is `3' while in:
+ ({ if (x) { 3; } })
+ there is no value. If the `STMT_EXPR' does not yield a value,
+ it's type will be `void'.
+
+`BIND_EXPR'
+ These nodes represent local blocks. The first operand is a list of
+ variables, connected via their `TREE_CHAIN' field. These will
+ never require cleanups. The scope of these variables is just the
+ body of the `BIND_EXPR'. The body of the `BIND_EXPR' is the
+ second operand.
+
+`LOOP_EXPR'
+ These nodes represent "infinite" loops. The `LOOP_EXPR_BODY'
+ represents the body of the loop. It should be executed forever,
+ unless an `EXIT_EXPR' is encountered.
+
+`EXIT_EXPR'
+ These nodes represent conditional exits from the nearest enclosing
+ `LOOP_EXPR'. The single operand is the condition; if it is
+ nonzero, then the loop should be exited. An `EXIT_EXPR' will only
+ appear within a `LOOP_EXPR'.
+
+`CLEANUP_POINT_EXPR'
+ These nodes represent full-expressions. The single operand is an
+ expression to evaluate. Any destructor calls engendered by the
+ creation of temporaries during the evaluation of that expression
+ should be performed immediately after the expression is evaluated.
+
+`CONSTRUCTOR'
+ These nodes represent the brace-enclosed initializers for a
+ structure or array. The first operand is reserved for use by the
+ back end. The second operand is a `TREE_LIST'. If the
+ `TREE_TYPE' of the `CONSTRUCTOR' is a `RECORD_TYPE' or
+ `UNION_TYPE', then the `TREE_PURPOSE' of each node in the
+ `TREE_LIST' will be a `FIELD_DECL' and the `TREE_VALUE' of each
+ node will be the expression used to initialize that field.
+
+ If the `TREE_TYPE' of the `CONSTRUCTOR' is an `ARRAY_TYPE', then
+ the `TREE_PURPOSE' of each element in the `TREE_LIST' will be an
+ `INTEGER_CST' or a `RANGE_EXPR' of two `INTEGER_CST's. A single
+ `INTEGER_CST' indicates which element of the array (indexed from
+ zero) is being assigned to. A `RANGE_EXPR' indicates an inclusive
+ range of elements to initialize. In both cases the `TREE_VALUE'
+ is the corresponding initializer. It is re-evaluated for each
+ element of a `RANGE_EXPR'. If the `TREE_PURPOSE' is `NULL_TREE',
+ then the initializer is for the next available array element.
+
+ In the front end, you should not depend on the fields appearing in
+ any particular order. However, in the middle end, fields must
+ appear in declaration order. You should not assume that all
+ fields will be represented. Unrepresented fields will be set to
+ zero.
+
+`COMPOUND_LITERAL_EXPR'
+ These nodes represent ISO C99 compound literals. The
+ `COMPOUND_LITERAL_EXPR_DECL_STMT' is a `DECL_STMT' containing an
+ anonymous `VAR_DECL' for the unnamed object represented by the
+ compound literal; the `DECL_INITIAL' of that `VAR_DECL' is a
+ `CONSTRUCTOR' representing the brace-enclosed list of initializers
+ in the compound literal. That anonymous `VAR_DECL' can also be
+ accessed directly by the `COMPOUND_LITERAL_EXPR_DECL' macro.
+
+`SAVE_EXPR'
+ A `SAVE_EXPR' represents an expression (possibly involving
+ side-effects) that is used more than once. The side-effects should
+ occur only the first time the expression is evaluated. Subsequent
+ uses should just reuse the computed value. The first operand to
+ the `SAVE_EXPR' is the expression to evaluate. The side-effects
+ should be executed where the `SAVE_EXPR' is first encountered in a
+ depth-first preorder traversal of the expression tree.
+
+`TARGET_EXPR'
+ A `TARGET_EXPR' represents a temporary object. The first operand
+ is a `VAR_DECL' for the temporary variable. The second operand is
+ the initializer for the temporary. The initializer is evaluated
+ and, if non-void, copied (bitwise) into the temporary. If the
+ initializer is void, that means that it will perform the
+ initialization itself.
+
+ Often, a `TARGET_EXPR' occurs on the right-hand side of an
+ assignment, or as the second operand to a comma-expression which is
+ itself the right-hand side of an assignment, etc. In this case,
+ we say that the `TARGET_EXPR' is "normal"; otherwise, we say it is
+ "orphaned". For a normal `TARGET_EXPR' the temporary variable
+ should be treated as an alias for the left-hand side of the
+ assignment, rather than as a new temporary variable.
+
+ The third operand to the `TARGET_EXPR', if present, is a
+ cleanup-expression (i.e., destructor call) for the temporary. If
+ this expression is orphaned, then this expression must be executed
+ when the statement containing this expression is complete. These
+ cleanups must always be executed in the order opposite to that in
+ which they were encountered. Note that if a temporary is created
+ on one branch of a conditional operator (i.e., in the second or
+ third operand to a `COND_EXPR'), the cleanup must be run only if
+ that branch is actually executed.
+
+ See `STMT_IS_FULL_EXPR_P' for more information about running these
+ cleanups.
+
+`AGGR_INIT_EXPR'
+ An `AGGR_INIT_EXPR' represents the initialization as the return
+ value of a function call, or as the result of a constructor. An
+ `AGGR_INIT_EXPR' will only appear as a full-expression, or as the
+ second operand of a `TARGET_EXPR'. `AGGR_INIT_EXPR's have a
+ representation similar to that of `CALL_EXPR's. You can use the
+ `AGGR_INIT_EXPR_FN' and `AGGR_INIT_EXPR_ARG' macros to access the
+ function to call and the arguments to pass.
+
+ If `AGGR_INIT_VIA_CTOR_P' holds of the `AGGR_INIT_EXPR', then the
+ initialization is via a constructor call. The address of the
+ `AGGR_INIT_EXPR_SLOT' operand, which is always a `VAR_DECL', is
+ taken, and this value replaces the first argument in the argument
+ list.
+
+ In either case, the expression is void.
+
+`VA_ARG_EXPR'
+ This node is used to implement support for the C/C++ variable
+ argument-list mechanism. It represents expressions like `va_arg
+ (ap, type)'. Its `TREE_TYPE' yields the tree representation for
+ `type' and its sole argument yields the representation for `ap'.
+
+`CHANGE_DYNAMIC_TYPE_EXPR'
+ Indicates the special aliasing required by C++ placement new. It
+ has two operands: a type and a location. It means that the
+ dynamic type of the location is changing to be the specified type.
+ The alias analysis code takes this into account when doing type
+ based alias analysis.
+
+`OMP_PARALLEL'
+ Represents `#pragma omp parallel [clause1 ... clauseN]'. It has
+ four operands:
+
+ Operand `OMP_PARALLEL_BODY' is valid while in GENERIC and High
+ GIMPLE forms. It contains the body of code to be executed by all
+ the threads. During GIMPLE lowering, this operand becomes `NULL'
+ and the body is emitted linearly after `OMP_PARALLEL'.
+
+ Operand `OMP_PARALLEL_CLAUSES' is the list of clauses associated
+ with the directive.
+
+ Operand `OMP_PARALLEL_FN' is created by `pass_lower_omp', it
+ contains the `FUNCTION_DECL' for the function that will contain
+ the body of the parallel region.
+
+ Operand `OMP_PARALLEL_DATA_ARG' is also created by
+ `pass_lower_omp'. If there are shared variables to be communicated
+ to the children threads, this operand will contain the `VAR_DECL'
+ that contains all the shared values and variables.
+
+`OMP_FOR'
+ Represents `#pragma omp for [clause1 ... clauseN]'. It has 5
+ operands:
+
+ Operand `OMP_FOR_BODY' contains the loop body.
+
+ Operand `OMP_FOR_CLAUSES' is the list of clauses associated with
+ the directive.
+
+ Operand `OMP_FOR_INIT' is the loop initialization code of the form
+ `VAR = N1'.
+
+ Operand `OMP_FOR_COND' is the loop conditional expression of the
+ form `VAR {<,>,<=,>=} N2'.
+
+ Operand `OMP_FOR_INCR' is the loop index increment of the form
+ `VAR {+=,-=} INCR'.
+
+ Operand `OMP_FOR_PRE_BODY' contains side-effect code from operands
+ `OMP_FOR_INIT', `OMP_FOR_COND' and `OMP_FOR_INC'. These
+ side-effects are part of the `OMP_FOR' block but must be evaluated
+ before the start of loop body.
+
+ The loop index variable `VAR' must be a signed integer variable,
+ which is implicitly private to each thread. Bounds `N1' and `N2'
+ and the increment expression `INCR' are required to be loop
+ invariant integer expressions that are evaluated without any
+ synchronization. The evaluation order, frequency of evaluation and
+ side-effects are unspecified by the standard.
+
+`OMP_SECTIONS'
+ Represents `#pragma omp sections [clause1 ... clauseN]'.
+
+ Operand `OMP_SECTIONS_BODY' contains the sections body, which in
+ turn contains a set of `OMP_SECTION' nodes for each of the
+ concurrent sections delimited by `#pragma omp section'.
+
+ Operand `OMP_SECTIONS_CLAUSES' is the list of clauses associated
+ with the directive.
+
+`OMP_SECTION'
+ Section delimiter for `OMP_SECTIONS'.
+
+`OMP_SINGLE'
+ Represents `#pragma omp single'.
+
+ Operand `OMP_SINGLE_BODY' contains the body of code to be executed
+ by a single thread.
+
+ Operand `OMP_SINGLE_CLAUSES' is the list of clauses associated
+ with the directive.
+
+`OMP_MASTER'
+ Represents `#pragma omp master'.
+
+ Operand `OMP_MASTER_BODY' contains the body of code to be executed
+ by the master thread.
+
+`OMP_ORDERED'
+ Represents `#pragma omp ordered'.
+
+ Operand `OMP_ORDERED_BODY' contains the body of code to be
+ executed in the sequential order dictated by the loop index
+ variable.
+
+`OMP_CRITICAL'
+ Represents `#pragma omp critical [name]'.
+
+ Operand `OMP_CRITICAL_BODY' is the critical section.
+
+ Operand `OMP_CRITICAL_NAME' is an optional identifier to label the
+ critical section.
+
+`OMP_RETURN'
+ This does not represent any OpenMP directive, it is an artificial
+ marker to indicate the end of the body of an OpenMP. It is used by
+ the flow graph (`tree-cfg.c') and OpenMP region building code
+ (`omp-low.c').
+
+`OMP_CONTINUE'
+ Similarly, this instruction does not represent an OpenMP
+ directive, it is used by `OMP_FOR' and `OMP_SECTIONS' to mark the
+ place where the code needs to loop to the next iteration (in the
+ case of `OMP_FOR') or the next section (in the case of
+ `OMP_SECTIONS').
+
+ In some cases, `OMP_CONTINUE' is placed right before `OMP_RETURN'.
+ But if there are cleanups that need to occur right after the
+ looping body, it will be emitted between `OMP_CONTINUE' and
+ `OMP_RETURN'.
+
+`OMP_ATOMIC'
+ Represents `#pragma omp atomic'.
+
+ Operand 0 is the address at which the atomic operation is to be
+ performed.
+
+ Operand 1 is the expression to evaluate. The gimplifier tries
+ three alternative code generation strategies. Whenever possible,
+ an atomic update built-in is used. If that fails, a
+ compare-and-swap loop is attempted. If that also fails, a regular
+ critical section around the expression is used.
+
+`OMP_CLAUSE'
+ Represents clauses associated with one of the `OMP_' directives.
+ Clauses are represented by separate sub-codes defined in `tree.h'.
+ Clauses codes can be one of: `OMP_CLAUSE_PRIVATE',
+ `OMP_CLAUSE_SHARED', `OMP_CLAUSE_FIRSTPRIVATE',
+ `OMP_CLAUSE_LASTPRIVATE', `OMP_CLAUSE_COPYIN',
+ `OMP_CLAUSE_COPYPRIVATE', `OMP_CLAUSE_IF',
+ `OMP_CLAUSE_NUM_THREADS', `OMP_CLAUSE_SCHEDULE',
+ `OMP_CLAUSE_NOWAIT', `OMP_CLAUSE_ORDERED', `OMP_CLAUSE_DEFAULT',
+ and `OMP_CLAUSE_REDUCTION'. Each code represents the
+ corresponding OpenMP clause.
+
+ Clauses associated with the same directive are chained together
+ via `OMP_CLAUSE_CHAIN'. Those clauses that accept a list of
+ variables are restricted to exactly one, accessed with
+ `OMP_CLAUSE_VAR'. Therefore, multiple variables under the same
+ clause `C' need to be represented as multiple `C' clauses chained
+ together. This facilitates adding new clauses during compilation.
+
+`VEC_LSHIFT_EXPR'
+
+`VEC_RSHIFT_EXPR'
+ These nodes represent whole vector left and right shifts,
+ respectively. The first operand is the vector to shift; it will
+ always be of vector type. The second operand is an expression for
+ the number of bits by which to shift. Note that the result is
+ undefined if the second operand is larger than or equal to the
+ first operand's type size.
+
+`VEC_WIDEN_MULT_HI_EXPR'
+
+`VEC_WIDEN_MULT_LO_EXPR'
+ These nodes represent widening vector multiplication of the high
+ and low parts of the two input vectors, respectively. Their
+ operands are vectors that contain the same number of elements
+ (`N') of the same integral type. The result is a vector that
+ contains half as many elements, of an integral type whose size is
+ twice as wide. In the case of `VEC_WIDEN_MULT_HI_EXPR' the high
+ `N/2' elements of the two vector are multiplied to produce the
+ vector of `N/2' products. In the case of `VEC_WIDEN_MULT_LO_EXPR'
+ the low `N/2' elements of the two vector are multiplied to produce
+ the vector of `N/2' products.
+
+`VEC_UNPACK_HI_EXPR'
+
+`VEC_UNPACK_LO_EXPR'
+ These nodes represent unpacking of the high and low parts of the
+ input vector, respectively. The single operand is a vector that
+ contains `N' elements of the same integral or floating point type.
+ The result is a vector that contains half as many elements, of an
+ integral or floating point type whose size is twice as wide. In
+ the case of `VEC_UNPACK_HI_EXPR' the high `N/2' elements of the
+ vector are extracted and widened (promoted). In the case of
+ `VEC_UNPACK_LO_EXPR' the low `N/2' elements of the vector are
+ extracted and widened (promoted).
+
+`VEC_UNPACK_FLOAT_HI_EXPR'
+
+`VEC_UNPACK_FLOAT_LO_EXPR'
+ These nodes represent unpacking of the high and low parts of the
+ input vector, where the values are converted from fixed point to
+ floating point. The single operand is a vector that contains `N'
+ elements of the same integral type. The result is a vector that
+ contains half as many elements of a floating point type whose size
+ is twice as wide. In the case of `VEC_UNPACK_HI_EXPR' the high
+ `N/2' elements of the vector are extracted, converted and widened.
+ In the case of `VEC_UNPACK_LO_EXPR' the low `N/2' elements of the
+ vector are extracted, converted and widened.
+
+`VEC_PACK_TRUNC_EXPR'
+ This node represents packing of truncated elements of the two
+ input vectors into the output vector. Input operands are vectors
+ that contain the same number of elements of the same integral or
+ floating point type. The result is a vector that contains twice
+ as many elements of an integral or floating point type whose size
+ is half as wide. The elements of the two vectors are demoted and
+ merged (concatenated) to form the output vector.
+
+`VEC_PACK_SAT_EXPR'
+ This node represents packing of elements of the two input vectors
+ into the output vector using saturation. Input operands are
+ vectors that contain the same number of elements of the same
+ integral type. The result is a vector that contains twice as many
+ elements of an integral type whose size is half as wide. The
+ elements of the two vectors are demoted and merged (concatenated)
+ to form the output vector.
+
+`VEC_PACK_FIX_TRUNC_EXPR'
+ This node represents packing of elements of the two input vectors
+ into the output vector, where the values are converted from
+ floating point to fixed point. Input operands are vectors that
+ contain the same number of elements of a floating point type. The
+ result is a vector that contains twice as many elements of an
+ integral type whose size is half as wide. The elements of the two
+ vectors are merged (concatenated) to form the output vector.
+
+`VEC_EXTRACT_EVEN_EXPR'
+
+`VEC_EXTRACT_ODD_EXPR'
+ These nodes represent extracting of the even/odd elements of the
+ two input vectors, respectively. Their operands and result are
+ vectors that contain the same number of elements of the same type.
+
+`VEC_INTERLEAVE_HIGH_EXPR'
+
+`VEC_INTERLEAVE_LOW_EXPR'
+ These nodes represent merging and interleaving of the high/low
+ elements of the two input vectors, respectively. The operands and
+ the result are vectors that contain the same number of elements
+ (`N') of the same type. In the case of
+ `VEC_INTERLEAVE_HIGH_EXPR', the high `N/2' elements of the first
+ input vector are interleaved with the high `N/2' elements of the
+ second input vector. In the case of `VEC_INTERLEAVE_LOW_EXPR', the
+ low `N/2' elements of the first input vector are interleaved with
+ the low `N/2' elements of the second input vector.
+
+
+\1f
+File: gccint.info, Node: RTL, Next: Control Flow, Prev: Tree SSA, Up: Top
+
+10 RTL Representation
+*********************
+
+The last part of the compiler work is done on a low-level intermediate
+representation called Register Transfer Language. In this language, the
+instructions to be output are described, pretty much one by one, in an
+algebraic form that describes what the instruction does.
+
+ RTL is inspired by Lisp lists. It has both an internal form, made up
+of structures that point at other structures, and a textual form that
+is used in the machine description and in printed debugging dumps. The
+textual form uses nested parentheses to indicate the pointers in the
+internal form.
+
+* Menu:
+
+* RTL Objects:: Expressions vs vectors vs strings vs integers.
+* RTL Classes:: Categories of RTL expression objects, and their structure.
+* Accessors:: Macros to access expression operands or vector elts.
+* Special Accessors:: Macros to access specific annotations on RTL.
+* Flags:: Other flags in an RTL expression.
+* Machine Modes:: Describing the size and format of a datum.
+* Constants:: Expressions with constant values.
+* Regs and Memory:: Expressions representing register contents or memory.
+* Arithmetic:: Expressions representing arithmetic on other expressions.
+* Comparisons:: Expressions representing comparison of expressions.
+* Bit-Fields:: Expressions representing bit-fields in memory or reg.
+* Vector Operations:: Expressions involving vector datatypes.
+* Conversions:: Extending, truncating, floating or fixing.
+* RTL Declarations:: Declaring volatility, constancy, etc.
+* Side Effects:: Expressions for storing in registers, etc.
+* Incdec:: Embedded side-effects for autoincrement addressing.
+* Assembler:: Representing `asm' with operands.
+* Insns:: Expression types for entire insns.
+* Calls:: RTL representation of function call insns.
+* Sharing:: Some expressions are unique; others *must* be copied.
+* Reading RTL:: Reading textual RTL from a file.
+
+\1f
+File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL
+
+10.1 RTL Object Types
+=====================
+
+RTL uses five kinds of objects: expressions, integers, wide integers,
+strings and vectors. Expressions are the most important ones. An RTL
+expression ("RTX", for short) is a C structure, but it is usually
+referred to with a pointer; a type that is given the typedef name `rtx'.
+
+ An integer is simply an `int'; their written form uses decimal digits.
+A wide integer is an integral object whose type is `HOST_WIDE_INT';
+their written form uses decimal digits.
+
+ A string is a sequence of characters. In core it is represented as a
+`char *' in usual C fashion, and it is written in C syntax as well.
+However, strings in RTL may never be null. If you write an empty
+string in a machine description, it is represented in core as a null
+pointer rather than as a pointer to a null character. In certain
+contexts, these null pointers instead of strings are valid. Within RTL
+code, strings are most commonly found inside `symbol_ref' expressions,
+but they appear in other contexts in the RTL expressions that make up
+machine descriptions.
+
+ In a machine description, strings are normally written with double
+quotes, as you would in C. However, strings in machine descriptions may
+extend over many lines, which is invalid C, and adjacent string
+constants are not concatenated as they are in C. Any string constant
+may be surrounded with a single set of parentheses. Sometimes this
+makes the machine description easier to read.
+
+ There is also a special syntax for strings, which can be useful when C
+code is embedded in a machine description. Wherever a string can
+appear, it is also valid to write a C-style brace block. The entire
+brace block, including the outermost pair of braces, is considered to be
+the string constant. Double quote characters inside the braces are not
+special. Therefore, if you write string constants in the C code, you
+need not escape each quote character with a backslash.
+
+ A vector contains an arbitrary number of pointers to expressions. The
+number of elements in the vector is explicitly present in the vector.
+The written form of a vector consists of square brackets (`[...]')
+surrounding the elements, in sequence and with whitespace separating
+them. Vectors of length zero are not created; null pointers are used
+instead.
+
+ Expressions are classified by "expression codes" (also called RTX
+codes). The expression code is a name defined in `rtl.def', which is
+also (in uppercase) a C enumeration constant. The possible expression
+codes and their meanings are machine-independent. The code of an RTX
+can be extracted with the macro `GET_CODE (X)' and altered with
+`PUT_CODE (X, NEWCODE)'.
+
+ The expression code determines how many operands the expression
+contains, and what kinds of objects they are. In RTL, unlike Lisp, you
+cannot tell by looking at an operand what kind of object it is.
+Instead, you must know from its context--from the expression code of
+the containing expression. For example, in an expression of code
+`subreg', the first operand is to be regarded as an expression and the
+second operand as an integer. In an expression of code `plus', there
+are two operands, both of which are to be regarded as expressions. In
+a `symbol_ref' expression, there is one operand, which is to be
+regarded as a string.
+
+ Expressions are written as parentheses containing the name of the
+expression type, its flags and machine mode if any, and then the
+operands of the expression (separated by spaces).
+
+ Expression code names in the `md' file are written in lowercase, but
+when they appear in C code they are written in uppercase. In this
+manual, they are shown as follows: `const_int'.
+
+ In a few contexts a null pointer is valid where an expression is
+normally wanted. The written form of this is `(nil)'.
+
+\1f
+File: gccint.info, Node: RTL Classes, Next: Accessors, Prev: RTL Objects, Up: RTL
+
+10.2 RTL Classes and Formats
+============================
+
+The various expression codes are divided into several "classes", which
+are represented by single characters. You can determine the class of
+an RTX code with the macro `GET_RTX_CLASS (CODE)'. Currently,
+`rtl.def' defines these classes:
+
+`RTX_OBJ'
+ An RTX code that represents an actual object, such as a register
+ (`REG') or a memory location (`MEM', `SYMBOL_REF'). `LO_SUM') is
+ also included; instead, `SUBREG' and `STRICT_LOW_PART' are not in
+ this class, but in class `x'.
+
+`RTX_CONST_OBJ'
+ An RTX code that represents a constant object. `HIGH' is also
+ included in this class.
+
+`RTX_COMPARE'
+ An RTX code for a non-symmetric comparison, such as `GEU' or `LT'.
+
+`RTX_COMM_COMPARE'
+ An RTX code for a symmetric (commutative) comparison, such as `EQ'
+ or `ORDERED'.
+
+`RTX_UNARY'
+ An RTX code for a unary arithmetic operation, such as `NEG',
+ `NOT', or `ABS'. This category also includes value extension
+ (sign or zero) and conversions between integer and floating point.
+
+`RTX_COMM_ARITH'
+ An RTX code for a commutative binary operation, such as `PLUS' or
+ `AND'. `NE' and `EQ' are comparisons, so they have class `<'.
+
+`RTX_BIN_ARITH'
+ An RTX code for a non-commutative binary operation, such as
+ `MINUS', `DIV', or `ASHIFTRT'.
+
+`RTX_BITFIELD_OPS'
+ An RTX code for a bit-field operation. Currently only
+ `ZERO_EXTRACT' and `SIGN_EXTRACT'. These have three inputs and
+ are lvalues (so they can be used for insertion as well). *Note
+ Bit-Fields::.
+
+`RTX_TERNARY'
+ An RTX code for other three input operations. Currently only
+ `IF_THEN_ELSE' and `VEC_MERGE'.
+
+`RTX_INSN'
+ An RTX code for an entire instruction: `INSN', `JUMP_INSN', and
+ `CALL_INSN'. *Note Insns::.
+
+`RTX_MATCH'
+ An RTX code for something that matches in insns, such as
+ `MATCH_DUP'. These only occur in machine descriptions.
+
+`RTX_AUTOINC'
+ An RTX code for an auto-increment addressing mode, such as
+ `POST_INC'.
+
+`RTX_EXTRA'
+ All other RTX codes. This category includes the remaining codes
+ used only in machine descriptions (`DEFINE_*', etc.). It also
+ includes all the codes describing side effects (`SET', `USE',
+ `CLOBBER', etc.) and the non-insns that may appear on an insn
+ chain, such as `NOTE', `BARRIER', and `CODE_LABEL'. `SUBREG' is
+ also part of this class.
+
+ For each expression code, `rtl.def' specifies the number of contained
+objects and their kinds using a sequence of characters called the
+"format" of the expression code. For example, the format of `subreg'
+is `ei'.
+
+ These are the most commonly used format characters:
+
+`e'
+ An expression (actually a pointer to an expression).
+
+`i'
+ An integer.
+
+`w'
+ A wide integer.
+
+`s'
+ A string.
+
+`E'
+ A vector of expressions.
+
+ A few other format characters are used occasionally:
+
+`u'
+ `u' is equivalent to `e' except that it is printed differently in
+ debugging dumps. It is used for pointers to insns.
+
+`n'
+ `n' is equivalent to `i' except that it is printed differently in
+ debugging dumps. It is used for the line number or code number of
+ a `note' insn.
+
+`S'
+ `S' indicates a string which is optional. In the RTL objects in
+ core, `S' is equivalent to `s', but when the object is read, from
+ an `md' file, the string value of this operand may be omitted. An
+ omitted string is taken to be the null string.
+
+`V'
+ `V' indicates a vector which is optional. In the RTL objects in
+ core, `V' is equivalent to `E', but when the object is read from
+ an `md' file, the vector value of this operand may be omitted. An
+ omitted vector is effectively the same as a vector of no elements.
+
+`B'
+ `B' indicates a pointer to basic block structure.
+
+`0'
+ `0' means a slot whose contents do not fit any normal category.
+ `0' slots are not printed at all in dumps, and are often used in
+ special ways by small parts of the compiler.
+
+ There are macros to get the number of operands and the format of an
+expression code:
+
+`GET_RTX_LENGTH (CODE)'
+ Number of operands of an RTX of code CODE.
+
+`GET_RTX_FORMAT (CODE)'
+ The format of an RTX of code CODE, as a C string.
+
+ Some classes of RTX codes always have the same format. For example, it
+is safe to assume that all comparison operations have format `ee'.
+
+`1'
+ All codes of this class have format `e'.
+
+`<'
+`c'
+`2'
+ All codes of these classes have format `ee'.
+
+`b'
+`3'
+ All codes of these classes have format `eee'.
+
+`i'
+ All codes of this class have formats that begin with `iuueiee'.
+ *Note Insns::. Note that not all RTL objects linked onto an insn
+ chain are of class `i'.
+
+`o'
+`m'
+`x'
+ You can make no assumptions about the format of these codes.
+
+\1f
+File: gccint.info, Node: Accessors, Next: Special Accessors, Prev: RTL Classes, Up: RTL
+
+10.3 Access to Operands
+=======================
+
+Operands of expressions are accessed using the macros `XEXP', `XINT',
+`XWINT' and `XSTR'. Each of these macros takes two arguments: an
+expression-pointer (RTX) and an operand number (counting from zero).
+Thus,
+
+ XEXP (X, 2)
+
+accesses operand 2 of expression X, as an expression.
+
+ XINT (X, 2)
+
+accesses the same operand as an integer. `XSTR', used in the same
+fashion, would access it as a string.
+
+ Any operand can be accessed as an integer, as an expression or as a
+string. You must choose the correct method of access for the kind of
+value actually stored in the operand. You would do this based on the
+expression code of the containing expression. That is also how you
+would know how many operands there are.
+
+ For example, if X is a `subreg' expression, you know that it has two
+operands which can be correctly accessed as `XEXP (X, 0)' and `XINT (X,
+1)'. If you did `XINT (X, 0)', you would get the address of the
+expression operand but cast as an integer; that might occasionally be
+useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP
+(X, 1)' would also compile without error, and would return the second,
+integer operand cast as an expression pointer, which would probably
+result in a crash when accessed. Nothing stops you from writing `XEXP
+(X, 28)' either, but this will access memory past the end of the
+expression with unpredictable results.
+
+ Access to operands which are vectors is more complicated. You can use
+the macro `XVEC' to get the vector-pointer itself, or the macros
+`XVECEXP' and `XVECLEN' to access the elements and length of a vector.
+
+`XVEC (EXP, IDX)'
+ Access the vector-pointer which is operand number IDX in EXP.
+
+`XVECLEN (EXP, IDX)'
+ Access the length (number of elements) in the vector which is in
+ operand number IDX in EXP. This value is an `int'.
+
+`XVECEXP (EXP, IDX, ELTNUM)'
+ Access element number ELTNUM in the vector which is in operand
+ number IDX in EXP. This value is an RTX.
+
+ It is up to you to make sure that ELTNUM is not negative and is
+ less than `XVECLEN (EXP, IDX)'.
+
+ All the macros defined in this section expand into lvalues and
+therefore can be used to assign the operands, lengths and vector
+elements as well as to access them.
+
+\1f
+File: gccint.info, Node: Special Accessors, Next: Flags, Prev: Accessors, Up: RTL
+
+10.4 Access to Special Operands
+===============================
+
+Some RTL nodes have special annotations associated with them.
+
+`MEM'
+
+ `MEM_ALIAS_SET (X)'
+ If 0, X is not in any alias set, and may alias anything.
+ Otherwise, X can only alias `MEM's in a conflicting alias
+ set. This value is set in a language-dependent manner in the
+ front-end, and should not be altered in the back-end. In
+ some front-ends, these numbers may correspond in some way to
+ types, or other language-level entities, but they need not,
+ and the back-end makes no such assumptions. These set
+ numbers are tested with `alias_sets_conflict_p'.
+
+ `MEM_EXPR (X)'
+ If this register is known to hold the value of some user-level
+ declaration, this is that tree node. It may also be a
+ `COMPONENT_REF', in which case this is some field reference,
+ and `TREE_OPERAND (X, 0)' contains the declaration, or
+ another `COMPONENT_REF', or null if there is no compile-time
+ object associated with the reference.
+
+ `MEM_OFFSET (X)'
+ The offset from the start of `MEM_EXPR' as a `CONST_INT' rtx.
+
+ `MEM_SIZE (X)'
+ The size in bytes of the memory reference as a `CONST_INT'
+ rtx. This is mostly relevant for `BLKmode' references as
+ otherwise the size is implied by the mode.
+
+ `MEM_ALIGN (X)'
+ The known alignment in bits of the memory reference.
+
+`REG'
+
+ `ORIGINAL_REGNO (X)'
+ This field holds the number the register "originally" had;
+ for a pseudo register turned into a hard reg this will hold
+ the old pseudo register number.
+
+ `REG_EXPR (X)'
+ If this register is known to hold the value of some user-level
+ declaration, this is that tree node.
+
+ `REG_OFFSET (X)'
+ If this register is known to hold the value of some user-level
+ declaration, this is the offset into that logical storage.
+
+`SYMBOL_REF'
+
+ `SYMBOL_REF_DECL (X)'
+ If the `symbol_ref' X was created for a `VAR_DECL' or a
+ `FUNCTION_DECL', that tree is recorded here. If this value is
+ null, then X was created by back end code generation routines,
+ and there is no associated front end symbol table entry.
+
+ `SYMBOL_REF_DECL' may also point to a tree of class `'c'',
+ that is, some sort of constant. In this case, the
+ `symbol_ref' is an entry in the per-file constant pool;
+ again, there is no associated front end symbol table entry.
+
+ `SYMBOL_REF_CONSTANT (X)'
+ If `CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant
+ pool entry for X. It is null otherwise.
+
+ `SYMBOL_REF_DATA (X)'
+ A field of opaque type used to store `SYMBOL_REF_DECL' or
+ `SYMBOL_REF_CONSTANT'.
+
+ `SYMBOL_REF_FLAGS (X)'
+ In a `symbol_ref', this is used to communicate various
+ predicates about the symbol. Some of these are common enough
+ to be computed by common code, some are specific to the
+ target. The common bits are:
+
+ `SYMBOL_FLAG_FUNCTION'
+ Set if the symbol refers to a function.
+
+ `SYMBOL_FLAG_LOCAL'
+ Set if the symbol is local to this "module". See
+ `TARGET_BINDS_LOCAL_P'.
+
+ `SYMBOL_FLAG_EXTERNAL'
+ Set if this symbol is not defined in this translation
+ unit. Note that this is not the inverse of
+ `SYMBOL_FLAG_LOCAL'.
+
+ `SYMBOL_FLAG_SMALL'
+ Set if the symbol is located in the small data section.
+ See `TARGET_IN_SMALL_DATA_P'.
+
+ `SYMBOL_REF_TLS_MODEL (X)'
+ This is a multi-bit field accessor that returns the
+ `tls_model' to be used for a thread-local storage
+ symbol. It returns zero for non-thread-local symbols.
+
+ `SYMBOL_FLAG_HAS_BLOCK_INFO'
+ Set if the symbol has `SYMBOL_REF_BLOCK' and
+ `SYMBOL_REF_BLOCK_OFFSET' fields.
+
+ `SYMBOL_FLAG_ANCHOR'
+ Set if the symbol is used as a section anchor. "Section
+ anchors" are symbols that have a known position within
+ an `object_block' and that can be used to access nearby
+ members of that block. They are used to implement
+ `-fsection-anchors'.
+
+ If this flag is set, then `SYMBOL_FLAG_HAS_BLOCK_INFO'
+ will be too.
+
+ Bits beginning with `SYMBOL_FLAG_MACH_DEP' are available for
+ the target's use.
+
+`SYMBOL_REF_BLOCK (X)'
+ If `SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the `object_block'
+ structure to which the symbol belongs, or `NULL' if it has not
+ been assigned a block.
+
+`SYMBOL_REF_BLOCK_OFFSET (X)'
+ If `SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from
+ the first object in `SYMBOL_REF_BLOCK (X)'. The value is negative
+ if X has not yet been assigned to a block, or it has not been
+ given an offset within that block.
+
+\1f
+File: gccint.info, Node: Flags, Next: Machine Modes, Prev: Special Accessors, Up: RTL
+
+10.5 Flags in an RTL Expression
+===============================
+
+RTL expressions contain several flags (one-bit bit-fields) that are
+used in certain types of expression. Most often they are accessed with
+the following macros, which expand into lvalues.
+
+`CONSTANT_POOL_ADDRESS_P (X)'
+ Nonzero in a `symbol_ref' if it refers to part of the current
+ function's constant pool. For most targets these addresses are in
+ a `.rodata' section entirely separate from the function, but for
+ some targets the addresses are close to the beginning of the
+ function. In either case GCC assumes these addresses can be
+ addressed directly, perhaps with the help of base registers.
+ Stored in the `unchanging' field and printed as `/u'.
+
+`RTL_CONST_CALL_P (X)'
+ In a `call_insn' indicates that the insn represents a call to a
+ const function. Stored in the `unchanging' field and printed as
+ `/u'.
+
+`RTL_PURE_CALL_P (X)'
+ In a `call_insn' indicates that the insn represents a call to a
+ pure function. Stored in the `return_val' field and printed as
+ `/i'.
+
+`RTL_CONST_OR_PURE_CALL_P (X)'
+ In a `call_insn', true if `RTL_CONST_CALL_P' or `RTL_PURE_CALL_P'
+ is true.
+
+`RTL_LOOPING_CONST_OR_PURE_CALL_P (X)'
+ In a `call_insn' indicates that the insn represents a possibly
+ infinite looping call to a const or pure function. Stored in the
+ `call' field and printed as `/c'. Only true if one of
+ `RTL_CONST_CALL_P' or `RTL_PURE_CALL_P' is true.
+
+`INSN_ANNULLED_BRANCH_P (X)'
+ In a `jump_insn', `call_insn', or `insn' indicates that the branch
+ is an annulling one. See the discussion under `sequence' below.
+ Stored in the `unchanging' field and printed as `/u'.
+
+`INSN_DELETED_P (X)'
+ In an `insn', `call_insn', `jump_insn', `code_label', `barrier',
+ or `note', nonzero if the insn has been deleted. Stored in the
+ `volatil' field and printed as `/v'.
+
+`INSN_FROM_TARGET_P (X)'
+ In an `insn' or `jump_insn' or `call_insn' in a delay slot of a
+ branch, indicates that the insn is from the target of the branch.
+ If the branch insn has `INSN_ANNULLED_BRANCH_P' set, this insn
+ will only be executed if the branch is taken. For annulled
+ branches with `INSN_FROM_TARGET_P' clear, the insn will be
+ executed only if the branch is not taken. When
+ `INSN_ANNULLED_BRANCH_P' is not set, this insn will always be
+ executed. Stored in the `in_struct' field and printed as `/s'.
+
+`LABEL_PRESERVE_P (X)'
+ In a `code_label' or `note', indicates that the label is
+ referenced by code or data not visible to the RTL of a given
+ function. Labels referenced by a non-local goto will have this
+ bit set. Stored in the `in_struct' field and printed as `/s'.
+
+`LABEL_REF_NONLOCAL_P (X)'
+ In `label_ref' and `reg_label' expressions, nonzero if this is a
+ reference to a non-local label. Stored in the `volatil' field and
+ printed as `/v'.
+
+`MEM_IN_STRUCT_P (X)'
+ In `mem' expressions, nonzero for reference to an entire structure,
+ union or array, or to a component of one. Zero for references to a
+ scalar variable or through a pointer to a scalar. If both this
+ flag and `MEM_SCALAR_P' are clear, then we don't know whether this
+ `mem' is in a structure or not. Both flags should never be
+ simultaneously set. Stored in the `in_struct' field and printed
+ as `/s'.
+
+`MEM_KEEP_ALIAS_SET_P (X)'
+ In `mem' expressions, 1 if we should keep the alias set for this
+ mem unchanged when we access a component. Set to 1, for example,
+ when we are already in a non-addressable component of an aggregate.
+ Stored in the `jump' field and printed as `/j'.
+
+`MEM_SCALAR_P (X)'
+ In `mem' expressions, nonzero for reference to a scalar known not
+ to be a member of a structure, union, or array. Zero for such
+ references and for indirections through pointers, even pointers
+ pointing to scalar types. If both this flag and `MEM_IN_STRUCT_P'
+ are clear, then we don't know whether this `mem' is in a structure
+ or not. Both flags should never be simultaneously set. Stored in
+ the `return_val' field and printed as `/i'.
+
+`MEM_VOLATILE_P (X)'
+ In `mem', `asm_operands', and `asm_input' expressions, nonzero for
+ volatile memory references. Stored in the `volatil' field and
+ printed as `/v'.
+
+`MEM_NOTRAP_P (X)'
+ In `mem', nonzero for memory references that will not trap.
+ Stored in the `call' field and printed as `/c'.
+
+`MEM_POINTER (X)'
+ Nonzero in a `mem' if the memory reference holds a pointer.
+ Stored in the `frame_related' field and printed as `/f'.
+
+`REG_FUNCTION_VALUE_P (X)'
+ Nonzero in a `reg' if it is the place in which this function's
+ value is going to be returned. (This happens only in a hard
+ register.) Stored in the `return_val' field and printed as `/i'.
+
+`REG_POINTER (X)'
+ Nonzero in a `reg' if the register holds a pointer. Stored in the
+ `frame_related' field and printed as `/f'.
+
+`REG_USERVAR_P (X)'
+ In a `reg', nonzero if it corresponds to a variable present in the
+ user's source code. Zero for temporaries generated internally by
+ the compiler. Stored in the `volatil' field and printed as `/v'.
+
+ The same hard register may be used also for collecting the values
+ of functions called by this one, but `REG_FUNCTION_VALUE_P' is zero
+ in this kind of use.
+
+`RTX_FRAME_RELATED_P (X)'
+ Nonzero in an `insn', `call_insn', `jump_insn', `barrier', or
+ `set' which is part of a function prologue and sets the stack
+ pointer, sets the frame pointer, or saves a register. This flag
+ should also be set on an instruction that sets up a temporary
+ register to use in place of the frame pointer. Stored in the
+ `frame_related' field and printed as `/f'.
+
+ In particular, on RISC targets where there are limits on the sizes
+ of immediate constants, it is sometimes impossible to reach the
+ register save area directly from the stack pointer. In that case,
+ a temporary register is used that is near enough to the register
+ save area, and the Canonical Frame Address, i.e., DWARF2's logical
+ frame pointer, register must (temporarily) be changed to be this
+ temporary register. So, the instruction that sets this temporary
+ register must be marked as `RTX_FRAME_RELATED_P'.
+
+ If the marked instruction is overly complex (defined in terms of
+ what `dwarf2out_frame_debug_expr' can handle), you will also have
+ to create a `REG_FRAME_RELATED_EXPR' note and attach it to the
+ instruction. This note should contain a simple expression of the
+ computation performed by this instruction, i.e., one that
+ `dwarf2out_frame_debug_expr' can handle.
+
+ This flag is required for exception handling support on targets
+ with RTL prologues.
+
+`MEM_READONLY_P (X)'
+ Nonzero in a `mem', if the memory is statically allocated and
+ read-only.
+
+ Read-only in this context means never modified during the lifetime
+ of the program, not necessarily in ROM or in write-disabled pages.
+ A common example of the later is a shared library's global offset
+ table. This table is initialized by the runtime loader, so the
+ memory is technically writable, but after control is transfered
+ from the runtime loader to the application, this memory will never
+ be subsequently modified.
+
+ Stored in the `unchanging' field and printed as `/u'.
+
+`SCHED_GROUP_P (X)'
+ During instruction scheduling, in an `insn', `call_insn' or
+ `jump_insn', indicates that the previous insn must be scheduled
+ together with this insn. This is used to ensure that certain
+ groups of instructions will not be split up by the instruction
+ scheduling pass, for example, `use' insns before a `call_insn' may
+ not be separated from the `call_insn'. Stored in the `in_struct'
+ field and printed as `/s'.
+
+`SET_IS_RETURN_P (X)'
+ For a `set', nonzero if it is for a return. Stored in the `jump'
+ field and printed as `/j'.
+
+`SIBLING_CALL_P (X)'
+ For a `call_insn', nonzero if the insn is a sibling call. Stored
+ in the `jump' field and printed as `/j'.
+
+`STRING_POOL_ADDRESS_P (X)'
+ For a `symbol_ref' expression, nonzero if it addresses this
+ function's string constant pool. Stored in the `frame_related'
+ field and printed as `/f'.
+
+`SUBREG_PROMOTED_UNSIGNED_P (X)'
+ Returns a value greater then zero for a `subreg' that has
+ `SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is
+ kept zero-extended, zero if it is kept sign-extended, and less
+ then zero if it is extended some other way via the `ptr_extend'
+ instruction. Stored in the `unchanging' field and `volatil'
+ field, printed as `/u' and `/v'. This macro may only be used to
+ get the value it may not be used to change the value. Use
+ `SUBREG_PROMOTED_UNSIGNED_SET' to change the value.
+
+`SUBREG_PROMOTED_UNSIGNED_SET (X)'
+ Set the `unchanging' and `volatil' fields in a `subreg' to reflect
+ zero, sign, or other extension. If `volatil' is zero, then
+ `unchanging' as nonzero means zero extension and as zero means
+ sign extension. If `volatil' is nonzero then some other type of
+ extension was done via the `ptr_extend' instruction.
+
+`SUBREG_PROMOTED_VAR_P (X)'
+ Nonzero in a `subreg' if it was made when accessing an object that
+ was promoted to a wider mode in accord with the `PROMOTED_MODE'
+ machine description macro (*note Storage Layout::). In this case,
+ the mode of the `subreg' is the declared mode of the object and
+ the mode of `SUBREG_REG' is the mode of the register that holds
+ the object. Promoted variables are always either sign- or
+ zero-extended to the wider mode on every assignment. Stored in
+ the `in_struct' field and printed as `/s'.
+
+`SYMBOL_REF_USED (X)'
+ In a `symbol_ref', indicates that X has been used. This is
+ normally only used to ensure that X is only declared external
+ once. Stored in the `used' field.
+
+`SYMBOL_REF_WEAK (X)'
+ In a `symbol_ref', indicates that X has been declared weak.
+ Stored in the `return_val' field and printed as `/i'.
+
+`SYMBOL_REF_FLAG (X)'
+ In a `symbol_ref', this is used as a flag for machine-specific
+ purposes. Stored in the `volatil' field and printed as `/v'.
+
+ Most uses of `SYMBOL_REF_FLAG' are historic and may be subsumed by
+ `SYMBOL_REF_FLAGS'. Certainly use of `SYMBOL_REF_FLAGS' is
+ mandatory if the target requires more than one bit of storage.
+
+ These are the fields to which the above macros refer:
+
+`call'
+ In a `mem', 1 means that the memory reference will not trap.
+
+ In a `call', 1 means that this pure or const call may possibly
+ infinite loop.
+
+ In an RTL dump, this flag is represented as `/c'.
+
+`frame_related'
+ In an `insn' or `set' expression, 1 means that it is part of a
+ function prologue and sets the stack pointer, sets the frame
+ pointer, saves a register, or sets up a temporary register to use
+ in place of the frame pointer.
+
+ In `reg' expressions, 1 means that the register holds a pointer.
+
+ In `mem' expressions, 1 means that the memory reference holds a
+ pointer.
+
+ In `symbol_ref' expressions, 1 means that the reference addresses
+ this function's string constant pool.
+
+ In an RTL dump, this flag is represented as `/f'.
+
+`in_struct'
+ In `mem' expressions, it is 1 if the memory datum referred to is
+ all or part of a structure or array; 0 if it is (or might be) a
+ scalar variable. A reference through a C pointer has 0 because
+ the pointer might point to a scalar variable. This information
+ allows the compiler to determine something about possible cases of
+ aliasing.
+
+ In `reg' expressions, it is 1 if the register has its entire life
+ contained within the test expression of some loop.
+
+ In `subreg' expressions, 1 means that the `subreg' is accessing an
+ object that has had its mode promoted from a wider mode.
+
+ In `label_ref' expressions, 1 means that the referenced label is
+ outside the innermost loop containing the insn in which the
+ `label_ref' was found.
+
+ In `code_label' expressions, it is 1 if the label may never be
+ deleted. This is used for labels which are the target of
+ non-local gotos. Such a label that would have been deleted is
+ replaced with a `note' of type `NOTE_INSN_DELETED_LABEL'.
+
+ In an `insn' during dead-code elimination, 1 means that the insn is
+ dead code.
+
+ In an `insn' or `jump_insn' during reorg for an insn in the delay
+ slot of a branch, 1 means that this insn is from the target of the
+ branch.
+
+ In an `insn' during instruction scheduling, 1 means that this insn
+ must be scheduled as part of a group together with the previous
+ insn.
+
+ In an RTL dump, this flag is represented as `/s'.
+
+`return_val'
+ In `reg' expressions, 1 means the register contains the value to
+ be returned by the current function. On machines that pass
+ parameters in registers, the same register number may be used for
+ parameters as well, but this flag is not set on such uses.
+
+ In `mem' expressions, 1 means the memory reference is to a scalar
+ known not to be a member of a structure, union, or array.
+
+ In `symbol_ref' expressions, 1 means the referenced symbol is weak.
+
+ In `call' expressions, 1 means the call is pure.
+
+ In an RTL dump, this flag is represented as `/i'.
+
+`jump'
+ In a `mem' expression, 1 means we should keep the alias set for
+ this mem unchanged when we access a component.
+
+ In a `set', 1 means it is for a return.
+
+ In a `call_insn', 1 means it is a sibling call.
+
+ In an RTL dump, this flag is represented as `/j'.
+
+`unchanging'
+ In `reg' and `mem' expressions, 1 means that the value of the
+ expression never changes.
+
+ In `subreg' expressions, it is 1 if the `subreg' references an
+ unsigned object whose mode has been promoted to a wider mode.
+
+ In an `insn' or `jump_insn' in the delay slot of a branch
+ instruction, 1 means an annulling branch should be used.
+
+ In a `symbol_ref' expression, 1 means that this symbol addresses
+ something in the per-function constant pool.
+
+ In a `call_insn' 1 means that this instruction is a call to a const
+ function.
+
+ In an RTL dump, this flag is represented as `/u'.
+
+`used'
+ This flag is used directly (without an access macro) at the end of
+ RTL generation for a function, to count the number of times an
+ expression appears in insns. Expressions that appear more than
+ once are copied, according to the rules for shared structure
+ (*note Sharing::).
+
+ For a `reg', it is used directly (without an access macro) by the
+ leaf register renumbering code to ensure that each register is only
+ renumbered once.
+
+ In a `symbol_ref', it indicates that an external declaration for
+ the symbol has already been written.
+
+`volatil'
+ In a `mem', `asm_operands', or `asm_input' expression, it is 1 if
+ the memory reference is volatile. Volatile memory references may
+ not be deleted, reordered or combined.
+
+ In a `symbol_ref' expression, it is used for machine-specific
+ purposes.
+
+ In a `reg' expression, it is 1 if the value is a user-level
+ variable. 0 indicates an internal compiler temporary.
+
+ In an `insn', 1 means the insn has been deleted.
+
+ In `label_ref' and `reg_label' expressions, 1 means a reference to
+ a non-local label.
+
+ In an RTL dump, this flag is represented as `/v'.
+
+\1f
+File: gccint.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL
+
+10.6 Machine Modes
+==================
+
+A machine mode describes a size of data object and the representation
+used for it. In the C code, machine modes are represented by an
+enumeration type, `enum machine_mode', defined in `machmode.def'. Each
+RTL expression has room for a machine mode and so do certain kinds of
+tree expressions (declarations and types, to be precise).
+
+ In debugging dumps and machine descriptions, the machine mode of an RTL
+expression is written after the expression code with a colon to separate
+them. The letters `mode' which appear at the end of each machine mode
+name are omitted. For example, `(reg:SI 38)' is a `reg' expression
+with machine mode `SImode'. If the mode is `VOIDmode', it is not
+written at all.
+
+ Here is a table of machine modes. The term "byte" below refers to an
+object of `BITS_PER_UNIT' bits (*note Storage Layout::).
+
+`BImode'
+ "Bit" mode represents a single bit, for predicate registers.
+
+`QImode'
+ "Quarter-Integer" mode represents a single byte treated as an
+ integer.
+
+`HImode'
+ "Half-Integer" mode represents a two-byte integer.
+
+`PSImode'
+ "Partial Single Integer" mode represents an integer which occupies
+ four bytes but which doesn't really use all four. On some
+ machines, this is the right mode to use for pointers.
+
+`SImode'
+ "Single Integer" mode represents a four-byte integer.
+
+`PDImode'
+ "Partial Double Integer" mode represents an integer which occupies
+ eight bytes but which doesn't really use all eight. On some
+ machines, this is the right mode to use for certain pointers.
+
+`DImode'
+ "Double Integer" mode represents an eight-byte integer.
+
+`TImode'
+ "Tetra Integer" (?) mode represents a sixteen-byte integer.
+
+`OImode'
+ "Octa Integer" (?) mode represents a thirty-two-byte integer.
+
+`QFmode'
+ "Quarter-Floating" mode represents a quarter-precision (single
+ byte) floating point number.
+
+`HFmode'
+ "Half-Floating" mode represents a half-precision (two byte)
+ floating point number.
+
+`TQFmode'
+ "Three-Quarter-Floating" (?) mode represents a
+ three-quarter-precision (three byte) floating point number.
+
+`SFmode'
+ "Single Floating" mode represents a four byte floating point
+ number. In the common case, of a processor with IEEE arithmetic
+ and 8-bit bytes, this is a single-precision IEEE floating point
+ number; it can also be used for double-precision (on processors
+ with 16-bit bytes) and single-precision VAX and IBM types.
+
+`DFmode'
+ "Double Floating" mode represents an eight byte floating point
+ number. In the common case, of a processor with IEEE arithmetic
+ and 8-bit bytes, this is a double-precision IEEE floating point
+ number.
+
+`XFmode'
+ "Extended Floating" mode represents an IEEE extended floating point
+ number. This mode only has 80 meaningful bits (ten bytes). Some
+ processors require such numbers to be padded to twelve bytes,
+ others to sixteen; this mode is used for either.
+
+`SDmode'
+ "Single Decimal Floating" mode represents a four byte decimal
+ floating point number (as distinct from conventional binary
+ floating point).
+
+`DDmode'
+ "Double Decimal Floating" mode represents an eight byte decimal
+ floating point number.
+
+`TDmode'
+ "Tetra Decimal Floating" mode represents a sixteen byte decimal
+ floating point number all 128 of whose bits are meaningful.
+
+`TFmode'
+ "Tetra Floating" mode represents a sixteen byte floating point
+ number all 128 of whose bits are meaningful. One common use is the
+ IEEE quad-precision format.
+
+`QQmode'
+ "Quarter-Fractional" mode represents a single byte treated as a
+ signed fractional number. The default format is "s.7".
+
+`HQmode'
+ "Half-Fractional" mode represents a two-byte signed fractional
+ number. The default format is "s.15".
+
+`SQmode'
+ "Single Fractional" mode represents a four-byte signed fractional
+ number. The default format is "s.31".
+
+`DQmode'
+ "Double Fractional" mode represents an eight-byte signed
+ fractional number. The default format is "s.63".
+
+`TQmode'
+ "Tetra Fractional" mode represents a sixteen-byte signed
+ fractional number. The default format is "s.127".
+
+`UQQmode'
+ "Unsigned Quarter-Fractional" mode represents a single byte
+ treated as an unsigned fractional number. The default format is
+ ".8".
+
+`UHQmode'
+ "Unsigned Half-Fractional" mode represents a two-byte unsigned
+ fractional number. The default format is ".16".
+
+`USQmode'
+ "Unsigned Single Fractional" mode represents a four-byte unsigned
+ fractional number. The default format is ".32".
+
+`UDQmode'
+ "Unsigned Double Fractional" mode represents an eight-byte unsigned
+ fractional number. The default format is ".64".
+
+`UTQmode'
+ "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned
+ fractional number. The default format is ".128".
+
+`HAmode'
+ "Half-Accumulator" mode represents a two-byte signed accumulator.
+ The default format is "s8.7".
+
+`SAmode'
+ "Single Accumulator" mode represents a four-byte signed
+ accumulator. The default format is "s16.15".
+
+`DAmode'
+ "Double Accumulator" mode represents an eight-byte signed
+ accumulator. The default format is "s32.31".
+
+`TAmode'
+ "Tetra Accumulator" mode represents a sixteen-byte signed
+ accumulator. The default format is "s64.63".
+
+`UHAmode'
+ "Unsigned Half-Accumulator" mode represents a two-byte unsigned
+ accumulator. The default format is "8.8".
+
+`USAmode'
+ "Unsigned Single Accumulator" mode represents a four-byte unsigned
+ accumulator. The default format is "16.16".
+
+`UDAmode'
+ "Unsigned Double Accumulator" mode represents an eight-byte
+ unsigned accumulator. The default format is "32.32".
+
+`UTAmode'
+ "Unsigned Tetra Accumulator" mode represents a sixteen-byte
+ unsigned accumulator. The default format is "64.64".
+
+`CCmode'
+ "Condition Code" mode represents the value of a condition code,
+ which is a machine-specific set of bits used to represent the
+ result of a comparison operation. Other machine-specific modes
+ may also be used for the condition code. These modes are not used
+ on machines that use `cc0' (see *note Condition Code::).
+
+`BLKmode'
+ "Block" mode represents values that are aggregates to which none of
+ the other modes apply. In RTL, only memory references can have
+ this mode, and only if they appear in string-move or vector
+ instructions. On machines which have no such instructions,
+ `BLKmode' will not appear in RTL.
+
+`VOIDmode'
+ Void mode means the absence of a mode or an unspecified mode. For
+ example, RTL expressions of code `const_int' have mode `VOIDmode'
+ because they can be taken to have whatever mode the context
+ requires. In debugging dumps of RTL, `VOIDmode' is expressed by
+ the absence of any mode.
+
+`QCmode, HCmode, SCmode, DCmode, XCmode, TCmode'
+ These modes stand for a complex number represented as a pair of
+ floating point values. The floating point values are in `QFmode',
+ `HFmode', `SFmode', `DFmode', `XFmode', and `TFmode', respectively.
+
+`CQImode, CHImode, CSImode, CDImode, CTImode, COImode'
+ These modes stand for a complex number represented as a pair of
+ integer values. The integer values are in `QImode', `HImode',
+ `SImode', `DImode', `TImode', and `OImode', respectively.
+
+ The machine description defines `Pmode' as a C macro which expands
+into the machine mode used for addresses. Normally this is the mode
+whose size is `BITS_PER_WORD', `SImode' on 32-bit machines.
+
+ The only modes which a machine description must support are `QImode',
+and the modes corresponding to `BITS_PER_WORD', `FLOAT_TYPE_SIZE' and
+`DOUBLE_TYPE_SIZE'. The compiler will attempt to use `DImode' for
+8-byte structures and unions, but this can be prevented by overriding
+the definition of `MAX_FIXED_MODE_SIZE'. Alternatively, you can have
+the compiler use `TImode' for 16-byte structures and unions. Likewise,
+you can arrange for the C type `short int' to avoid using `HImode'.
+
+ Very few explicit references to machine modes remain in the compiler
+and these few references will soon be removed. Instead, the machine
+modes are divided into mode classes. These are represented by the
+enumeration type `enum mode_class' defined in `machmode.h'. The
+possible mode classes are:
+
+`MODE_INT'
+ Integer modes. By default these are `BImode', `QImode', `HImode',
+ `SImode', `DImode', `TImode', and `OImode'.
+
+`MODE_PARTIAL_INT'
+ The "partial integer" modes, `PQImode', `PHImode', `PSImode' and
+ `PDImode'.
+
+`MODE_FLOAT'
+ Floating point modes. By default these are `QFmode', `HFmode',
+ `TQFmode', `SFmode', `DFmode', `XFmode' and `TFmode'.
+
+`MODE_DECIMAL_FLOAT'
+ Decimal floating point modes. By default these are `SDmode',
+ `DDmode' and `TDmode'.
+
+`MODE_FRACT'
+ Signed fractional modes. By default these are `QQmode', `HQmode',
+ `SQmode', `DQmode' and `TQmode'.
+
+`MODE_UFRACT'
+ Unsigned fractional modes. By default these are `UQQmode',
+ `UHQmode', `USQmode', `UDQmode' and `UTQmode'.
+
+`MODE_ACCUM'
+ Signed accumulator modes. By default these are `HAmode',
+ `SAmode', `DAmode' and `TAmode'.
+
+`MODE_UACCUM'
+ Unsigned accumulator modes. By default these are `UHAmode',
+ `USAmode', `UDAmode' and `UTAmode'.
+
+`MODE_COMPLEX_INT'
+ Complex integer modes. (These are not currently implemented).
+
+`MODE_COMPLEX_FLOAT'
+ Complex floating point modes. By default these are `QCmode',
+ `HCmode', `SCmode', `DCmode', `XCmode', and `TCmode'.
+
+`MODE_FUNCTION'
+ Algol or Pascal function variables including a static chain.
+ (These are not currently implemented).
+
+`MODE_CC'
+ Modes representing condition code values. These are `CCmode' plus
+ any `CC_MODE' modes listed in the `MACHINE-modes.def'. *Note Jump
+ Patterns::, also see *note Condition Code::.
+
+`MODE_RANDOM'
+ This is a catchall mode class for modes which don't fit into the
+ above classes. Currently `VOIDmode' and `BLKmode' are in
+ `MODE_RANDOM'.
+
+ Here are some C macros that relate to machine modes:
+
+`GET_MODE (X)'
+ Returns the machine mode of the RTX X.
+
+`PUT_MODE (X, NEWMODE)'
+ Alters the machine mode of the RTX X to be NEWMODE.
+
+`NUM_MACHINE_MODES'
+ Stands for the number of machine modes available on the target
+ machine. This is one greater than the largest numeric value of any
+ machine mode.
+
+`GET_MODE_NAME (M)'
+ Returns the name of mode M as a string.
+
+`GET_MODE_CLASS (M)'
+ Returns the mode class of mode M.
+
+`GET_MODE_WIDER_MODE (M)'
+ Returns the next wider natural mode. For example, the expression
+ `GET_MODE_WIDER_MODE (QImode)' returns `HImode'.
+
+`GET_MODE_SIZE (M)'
+ Returns the size in bytes of a datum of mode M.
+
+`GET_MODE_BITSIZE (M)'
+ Returns the size in bits of a datum of mode M.
+
+`GET_MODE_IBIT (M)'
+ Returns the number of integral bits of a datum of fixed-point mode
+ M.
+
+`GET_MODE_FBIT (M)'
+ Returns the number of fractional bits of a datum of fixed-point
+ mode M.
+
+`GET_MODE_MASK (M)'
+ Returns a bitmask containing 1 for all bits in a word that fit
+ within mode M. This macro can only be used for modes whose
+ bitsize is less than or equal to `HOST_BITS_PER_INT'.
+
+`GET_MODE_ALIGNMENT (M)'
+ Return the required alignment, in bits, for an object of mode M.
+
+`GET_MODE_UNIT_SIZE (M)'
+ Returns the size in bytes of the subunits of a datum of mode M.
+ This is the same as `GET_MODE_SIZE' except in the case of complex
+ modes. For them, the unit size is the size of the real or
+ imaginary part.
+
+`GET_MODE_NUNITS (M)'
+ Returns the number of units contained in a mode, i.e.,
+ `GET_MODE_SIZE' divided by `GET_MODE_UNIT_SIZE'.
+
+`GET_CLASS_NARROWEST_MODE (C)'
+ Returns the narrowest mode in mode class C.
+
+ The global variables `byte_mode' and `word_mode' contain modes whose
+classes are `MODE_INT' and whose bitsizes are either `BITS_PER_UNIT' or
+`BITS_PER_WORD', respectively. On 32-bit machines, these are `QImode'
+and `SImode', respectively.
+
+\1f
+File: gccint.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL
+
+10.7 Constant Expression Types
+==============================
+
+The simplest RTL expressions are those that represent constant values.
+
+`(const_int I)'
+ This type of expression represents the integer value I. I is
+ customarily accessed with the macro `INTVAL' as in `INTVAL (EXP)',
+ which is equivalent to `XWINT (EXP, 0)'.
+
+ Constants generated for modes with fewer bits than `HOST_WIDE_INT'
+ must be sign extended to full width (e.g., with `gen_int_mode').
+
+ There is only one expression object for the integer value zero; it
+ is the value of the variable `const0_rtx'. Likewise, the only
+ expression for integer value one is found in `const1_rtx', the only
+ expression for integer value two is found in `const2_rtx', and the
+ only expression for integer value negative one is found in
+ `constm1_rtx'. Any attempt to create an expression of code
+ `const_int' and value zero, one, two or negative one will return
+ `const0_rtx', `const1_rtx', `const2_rtx' or `constm1_rtx' as
+ appropriate.
+
+ Similarly, there is only one object for the integer whose value is
+ `STORE_FLAG_VALUE'. It is found in `const_true_rtx'. If
+ `STORE_FLAG_VALUE' is one, `const_true_rtx' and `const1_rtx' will
+ point to the same object. If `STORE_FLAG_VALUE' is -1,
+ `const_true_rtx' and `constm1_rtx' will point to the same object.
+
+`(const_double:M I0 I1 ...)'
+ Represents either a floating-point constant of mode M or an
+ integer constant too large to fit into `HOST_BITS_PER_WIDE_INT'
+ bits but small enough to fit within twice that number of bits (GCC
+ does not provide a mechanism to represent even larger constants).
+ In the latter case, M will be `VOIDmode'.
+
+ If M is `VOIDmode', the bits of the value are stored in I0 and I1.
+ I0 is customarily accessed with the macro `CONST_DOUBLE_LOW' and
+ I1 with `CONST_DOUBLE_HIGH'.
+
+ If the constant is floating point (regardless of its precision),
+ then the number of integers used to store the value depends on the
+ size of `REAL_VALUE_TYPE' (*note Floating Point::). The integers
+ represent a floating point number, but not precisely in the target
+ machine's or host machine's floating point format. To convert
+ them to the precise bit pattern used by the target machine, use
+ the macro `REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data
+ Output::).
+
+`(const_fixed:M ...)'
+ Represents a fixed-point constant of mode M. The operand is a
+ data structure of type `struct fixed_value' and is accessed with
+ the macro `CONST_FIXED_VALUE'. The high part of data is accessed
+ with `CONST_FIXED_VALUE_HIGH'; the low part is accessed with
+ `CONST_FIXED_VALUE_LOW'.
+
+`(const_vector:M [X0 X1 ...])'
+ Represents a vector constant. The square brackets stand for the
+ vector containing the constant elements. X0, X1 and so on are the
+ `const_int', `const_double' or `const_fixed' elements.
+
+ The number of units in a `const_vector' is obtained with the macro
+ `CONST_VECTOR_NUNITS' as in `CONST_VECTOR_NUNITS (V)'.
+
+ Individual elements in a vector constant are accessed with the
+ macro `CONST_VECTOR_ELT' as in `CONST_VECTOR_ELT (V, N)' where V
+ is the vector constant and N is the element desired.
+
+`(const_string STR)'
+ Represents a constant string with value STR. Currently this is
+ used only for insn attributes (*note Insn Attributes::) since
+ constant strings in C are placed in memory.
+
+`(symbol_ref:MODE SYMBOL)'
+ Represents the value of an assembler label for data. SYMBOL is a
+ string that describes the name of the assembler label. If it
+ starts with a `*', the label is the rest of SYMBOL not including
+ the `*'. Otherwise, the label is SYMBOL, usually prefixed with
+ `_'.
+
+ The `symbol_ref' contains a mode, which is usually `Pmode'.
+ Usually that is the only mode for which a symbol is directly valid.
+
+`(label_ref:MODE LABEL)'
+ Represents the value of an assembler label for code. It contains
+ one operand, an expression, which must be a `code_label' or a
+ `note' of type `NOTE_INSN_DELETED_LABEL' that appears in the
+ instruction sequence to identify the place where the label should
+ go.
+
+ The reason for using a distinct expression type for code label
+ references is so that jump optimization can distinguish them.
+
+ The `label_ref' contains a mode, which is usually `Pmode'.
+ Usually that is the only mode for which a label is directly valid.
+
+`(const:M EXP)'
+ Represents a constant that is the result of an assembly-time
+ arithmetic computation. The operand, EXP, is an expression that
+ contains only constants (`const_int', `symbol_ref' and `label_ref'
+ expressions) combined with `plus' and `minus'. However, not all
+ combinations are valid, since the assembler cannot do arbitrary
+ arithmetic on relocatable symbols.
+
+ M should be `Pmode'.
+
+`(high:M EXP)'
+ Represents the high-order bits of EXP, usually a `symbol_ref'.
+ The number of bits is machine-dependent and is normally the number
+ of bits specified in an instruction that initializes the high
+ order bits of a register. It is used with `lo_sum' to represent
+ the typical two-instruction sequence used in RISC machines to
+ reference a global memory location.
+
+ M should be `Pmode'.
+
+ The macro `CONST0_RTX (MODE)' refers to an expression with value 0 in
+mode MODE. If mode MODE is of mode class `MODE_INT', it returns
+`const0_rtx'. If mode MODE is of mode class `MODE_FLOAT', it returns a
+`CONST_DOUBLE' expression in mode MODE. Otherwise, it returns a
+`CONST_VECTOR' expression in mode MODE. Similarly, the macro
+`CONST1_RTX (MODE)' refers to an expression with value 1 in mode MODE
+and similarly for `CONST2_RTX'. The `CONST1_RTX' and `CONST2_RTX'
+macros are undefined for vector modes.
+
+\1f
+File: gccint.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL
+
+10.8 Registers and Memory
+=========================
+
+Here are the RTL expression types for describing access to machine
+registers and to main memory.
+
+`(reg:M N)'
+ For small values of the integer N (those that are less than
+ `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine
+ register number N: a "hard register". For larger values of N, it
+ stands for a temporary value or "pseudo register". The compiler's
+ strategy is to generate code assuming an unlimited number of such
+ pseudo registers, and later convert them into hard registers or
+ into memory references.
+
+ M is the machine mode of the reference. It is necessary because
+ machines can generally refer to each register in more than one
+ mode. For example, a register may contain a full word but there
+ may be instructions to refer to it as a half word or as a single
+ byte, as well as instructions to refer to it as a floating point
+ number of various precisions.
+
+ Even for a register that the machine can access in only one mode,
+ the mode must always be specified.
+
+ The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine
+ description, since the number of hard registers on the machine is
+ an invariant characteristic of the machine. Note, however, that
+ not all of the machine registers must be general registers. All
+ the machine registers that can be used for storage of data are
+ given hard register numbers, even those that can be used only in
+ certain instructions or can hold only certain types of data.
+
+ A hard register may be accessed in various modes throughout one
+ function, but each pseudo register is given a natural mode and is
+ accessed only in that mode. When it is necessary to describe an
+ access to a pseudo register using a nonnatural mode, a `subreg'
+ expression is used.
+
+ A `reg' expression with a machine mode that specifies more than
+ one word of data may actually stand for several consecutive
+ registers. If in addition the register number specifies a
+ hardware register, then it actually represents several consecutive
+ hardware registers starting with the specified one.
+
+ Each pseudo register number used in a function's RTL code is
+ represented by a unique `reg' expression.
+
+ Some pseudo register numbers, those within the range of
+ `FIRST_VIRTUAL_REGISTER' to `LAST_VIRTUAL_REGISTER' only appear
+ during the RTL generation phase and are eliminated before the
+ optimization phases. These represent locations in the stack frame
+ that cannot be determined until RTL generation for the function
+ has been completed. The following virtual register numbers are
+ defined:
+
+ `VIRTUAL_INCOMING_ARGS_REGNUM'
+ This points to the first word of the incoming arguments
+ passed on the stack. Normally these arguments are placed
+ there by the caller, but the callee may have pushed some
+ arguments that were previously passed in registers.
+
+ When RTL generation is complete, this virtual register is
+ replaced by the sum of the register given by
+ `ARG_POINTER_REGNUM' and the value of `FIRST_PARM_OFFSET'.
+
+ `VIRTUAL_STACK_VARS_REGNUM'
+ If `FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this
+ points to immediately above the first variable on the stack.
+ Otherwise, it points to the first variable on the stack.
+
+ `VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the
+ register given by `FRAME_POINTER_REGNUM' and the value
+ `STARTING_FRAME_OFFSET'.
+
+ `VIRTUAL_STACK_DYNAMIC_REGNUM'
+ This points to the location of dynamically allocated memory
+ on the stack immediately after the stack pointer has been
+ adjusted by the amount of memory desired.
+
+ This virtual register is replaced by the sum of the register
+ given by `STACK_POINTER_REGNUM' and the value
+ `STACK_DYNAMIC_OFFSET'.
+
+ `VIRTUAL_OUTGOING_ARGS_REGNUM'
+ This points to the location in the stack at which outgoing
+ arguments should be written when the stack is pre-pushed
+ (arguments pushed using push insns should always use
+ `STACK_POINTER_REGNUM').
+
+ This virtual register is replaced by the sum of the register
+ given by `STACK_POINTER_REGNUM' and the value
+ `STACK_POINTER_OFFSET'.
+
+`(subreg:M1 REG:M2 BYTENUM)'
+ `subreg' expressions are used to refer to a register in a machine
+ mode other than its natural one, or to refer to one register of a
+ multi-part `reg' that actually refers to several registers.
+
+ Each pseudo register has a natural mode. If it is necessary to
+ operate on it in a different mode, the register must be enclosed
+ in a `subreg'.
+
+ There are currently three supported types for the first operand of
+ a `subreg':
+ * pseudo registers This is the most common case. Most
+ `subreg's have pseudo `reg's as their first operand.
+
+ * mem `subreg's of `mem' were common in earlier versions of GCC
+ and are still supported. During the reload pass these are
+ replaced by plain `mem's. On machines that do not do
+ instruction scheduling, use of `subreg's of `mem' are still
+ used, but this is no longer recommended. Such `subreg's are
+ considered to be `register_operand's rather than
+ `memory_operand's before and during reload. Because of this,
+ the scheduling passes cannot properly schedule instructions
+ with `subreg's of `mem', so for machines that do scheduling,
+ `subreg's of `mem' should never be used. To support this,
+ the combine and recog passes have explicit code to inhibit
+ the creation of `subreg's of `mem' when `INSN_SCHEDULING' is
+ defined.
+
+ The use of `subreg's of `mem' after the reload pass is an area
+ that is not well understood and should be avoided. There is
+ still some code in the compiler to support this, but this
+ code has possibly rotted. This use of `subreg's is
+ discouraged and will most likely not be supported in the
+ future.
+
+ * hard registers It is seldom necessary to wrap hard registers
+ in `subreg's; such registers would normally reduce to a
+ single `reg' rtx. This use of `subreg's is discouraged and
+ may not be supported in the future.
+
+
+ `subreg's of `subreg's are not supported. Using
+ `simplify_gen_subreg' is the recommended way to avoid this problem.
+
+ `subreg's come in two distinct flavors, each having its own usage
+ and rules:
+
+ Paradoxical subregs
+ When M1 is strictly wider than M2, the `subreg' expression is
+ called "paradoxical". The canonical test for this class of
+ `subreg' is:
+
+ GET_MODE_SIZE (M1) > GET_MODE_SIZE (M2)
+
+ Paradoxical `subreg's can be used as both lvalues and rvalues.
+ When used as an lvalue, the low-order bits of the source value
+ are stored in REG and the high-order bits are discarded.
+ When used as an rvalue, the low-order bits of the `subreg' are
+ taken from REG while the high-order bits may or may not be
+ defined.
+
+ The high-order bits of rvalues are in the following
+ circumstances:
+
+ * `subreg's of `mem' When M2 is smaller than a word, the
+ macro `LOAD_EXTEND_OP', can control how the high-order
+ bits are defined.
+
+ * `subreg' of `reg's The upper bits are defined when
+ `SUBREG_PROMOTED_VAR_P' is true.
+ `SUBREG_PROMOTED_UNSIGNED_P' describes what the upper
+ bits hold. Such subregs usually represent local
+ variables, register variables and parameter pseudo
+ variables that have been promoted to a wider mode.
+
+
+ BYTENUM is always zero for a paradoxical `subreg', even on
+ big-endian targets.
+
+ For example, the paradoxical `subreg':
+
+ (set (subreg:SI (reg:HI X) 0) Y)
+
+ stores the lower 2 bytes of Y in X and discards the upper 2
+ bytes. A subsequent:
+
+ (set Z (subreg:SI (reg:HI X) 0))
+
+ would set the lower two bytes of Z to Y and set the upper two
+ bytes to an unknown value assuming `SUBREG_PROMOTED_VAR_P' is
+ false.
+
+ Normal subregs
+ When M1 is at least as narrow as M2 the `subreg' expression
+ is called "normal".
+
+ Normal `subreg's restrict consideration to certain bits of
+ REG. There are two cases. If M1 is smaller than a word, the
+ `subreg' refers to the least-significant part (or "lowpart")
+ of one word of REG. If M1 is word-sized or greater, the
+ `subreg' refers to one or more complete words.
+
+ When used as an lvalue, `subreg' is a word-based accessor.
+ Storing to a `subreg' modifies all the words of REG that
+ overlap the `subreg', but it leaves the other words of REG
+ alone.
+
+ When storing to a normal `subreg' that is smaller than a word,
+ the other bits of the referenced word are usually left in an
+ undefined state. This laxity makes it easier to generate
+ efficient code for such instructions. To represent an
+ instruction that preserves all the bits outside of those in
+ the `subreg', use `strict_low_part' or `zero_extract' around
+ the `subreg'.
+
+ BYTENUM must identify the offset of the first byte of the
+ `subreg' from the start of REG, assuming that REG is laid out
+ in memory order. The memory order of bytes is defined by two
+ target macros, `WORDS_BIG_ENDIAN' and `BYTES_BIG_ENDIAN':
+
+ * `WORDS_BIG_ENDIAN', if set to 1, says that byte number
+ zero is part of the most significant word; otherwise, it
+ is part of the least significant word.
+
+ * `BYTES_BIG_ENDIAN', if set to 1, says that byte number
+ zero is the most significant byte within a word;
+ otherwise, it is the least significant byte within a
+ word.
+
+ On a few targets, `FLOAT_WORDS_BIG_ENDIAN' disagrees with
+ `WORDS_BIG_ENDIAN'. However, most parts of the compiler treat
+ floating point values as if they had the same endianness as
+ integer values. This works because they handle them solely
+ as a collection of integer values, with no particular
+ numerical value. Only real.c and the runtime libraries care
+ about `FLOAT_WORDS_BIG_ENDIAN'.
+
+ Thus,
+
+ (subreg:HI (reg:SI X) 2)
+
+ on a `BYTES_BIG_ENDIAN', `UNITS_PER_WORD == 4' target is the
+ same as
+
+ (subreg:HI (reg:SI X) 0)
+
+ on a little-endian, `UNITS_PER_WORD == 4' target. Both
+ `subreg's access the lower two bytes of register X.
+
+
+ A `MODE_PARTIAL_INT' mode behaves as if it were as wide as the
+ corresponding `MODE_INT' mode, except that it has an unknown
+ number of undefined bits. For example:
+
+ (subreg:PSI (reg:SI 0) 0)
+
+ accesses the whole of `(reg:SI 0)', but the exact relationship
+ between the `PSImode' value and the `SImode' value is not defined.
+ If we assume `UNITS_PER_WORD <= 4', then the following two
+ `subreg's:
+
+ (subreg:PSI (reg:DI 0) 0)
+ (subreg:PSI (reg:DI 0) 4)
+
+ represent independent 4-byte accesses to the two halves of
+ `(reg:DI 0)'. Both `subreg's have an unknown number of undefined
+ bits.
+
+ If `UNITS_PER_WORD <= 2' then these two `subreg's:
+
+ (subreg:HI (reg:PSI 0) 0)
+ (subreg:HI (reg:PSI 0) 2)
+
+ represent independent 2-byte accesses that together span the whole
+ of `(reg:PSI 0)'. Storing to the first `subreg' does not affect
+ the value of the second, and vice versa. `(reg:PSI 0)' has an
+ unknown number of undefined bits, so the assignment:
+
+ (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4))
+
+ does not guarantee that `(subreg:HI (reg:PSI 0) 0)' has the value
+ `(reg:HI 4)'.
+
+ The rules above apply to both pseudo REGs and hard REGs. If the
+ semantics are not correct for particular combinations of M1, M2
+ and hard REG, the target-specific code must ensure that those
+ combinations are never used. For example:
+
+ CANNOT_CHANGE_MODE_CLASS (M2, M1, CLASS)
+
+ must be true for every class CLASS that includes REG.
+
+ The first operand of a `subreg' expression is customarily accessed
+ with the `SUBREG_REG' macro and the second operand is customarily
+ accessed with the `SUBREG_BYTE' macro.
+
+ It has been several years since a platform in which
+ `BYTES_BIG_ENDIAN' not equal to `WORDS_BIG_ENDIAN' has been
+ tested. Anyone wishing to support such a platform in the future
+ may be confronted with code rot.
+
+`(scratch:M)'
+ This represents a scratch register that will be required for the
+ execution of a single instruction and not used subsequently. It is
+ converted into a `reg' by either the local register allocator or
+ the reload pass.
+
+ `scratch' is usually present inside a `clobber' operation (*note
+ Side Effects::).
+
+`(cc0)'
+ This refers to the machine's condition code register. It has no
+ operands and may not have a machine mode. There are two ways to
+ use it:
+
+ * To stand for a complete set of condition code flags. This is
+ best on most machines, where each comparison sets the entire
+ series of flags.
+
+ With this technique, `(cc0)' may be validly used in only two
+ contexts: as the destination of an assignment (in test and
+ compare instructions) and in comparison operators comparing
+ against zero (`const_int' with value zero; that is to say,
+ `const0_rtx').
+
+ * To stand for a single flag that is the result of a single
+ condition. This is useful on machines that have only a
+ single flag bit, and in which comparison instructions must
+ specify the condition to test.
+
+ With this technique, `(cc0)' may be validly used in only two
+ contexts: as the destination of an assignment (in test and
+ compare instructions) where the source is a comparison
+ operator, and as the first operand of `if_then_else' (in a
+ conditional branch).
+
+ There is only one expression object of code `cc0'; it is the value
+ of the variable `cc0_rtx'. Any attempt to create an expression of
+ code `cc0' will return `cc0_rtx'.
+
+ Instructions can set the condition code implicitly. On many
+ machines, nearly all instructions set the condition code based on
+ the value that they compute or store. It is not necessary to
+ record these actions explicitly in the RTL because the machine
+ description includes a prescription for recognizing the
+ instructions that do so (by means of the macro
+ `NOTICE_UPDATE_CC'). *Note Condition Code::. Only instructions
+ whose sole purpose is to set the condition code, and instructions
+ that use the condition code, need mention `(cc0)'.
+
+ On some machines, the condition code register is given a register
+ number and a `reg' is used instead of `(cc0)'. This is usually the
+ preferable approach if only a small subset of instructions modify
+ the condition code. Other machines store condition codes in
+ general registers; in such cases a pseudo register should be used.
+
+ Some machines, such as the SPARC and RS/6000, have two sets of
+ arithmetic instructions, one that sets and one that does not set
+ the condition code. This is best handled by normally generating
+ the instruction that does not set the condition code, and making a
+ pattern that both performs the arithmetic and sets the condition
+ code register (which would not be `(cc0)' in this case). For
+ examples, search for `addcc' and `andcc' in `sparc.md'.
+
+`(pc)'
+ This represents the machine's program counter. It has no operands
+ and may not have a machine mode. `(pc)' may be validly used only
+ in certain specific contexts in jump instructions.
+
+ There is only one expression object of code `pc'; it is the value
+ of the variable `pc_rtx'. Any attempt to create an expression of
+ code `pc' will return `pc_rtx'.
+
+ All instructions that do not jump alter the program counter
+ implicitly by incrementing it, but there is no need to mention
+ this in the RTL.
+
+`(mem:M ADDR ALIAS)'
+ This RTX represents a reference to main memory at an address
+ represented by the expression ADDR. M specifies how large a unit
+ of memory is accessed. ALIAS specifies an alias set for the
+ reference. In general two items are in different alias sets if
+ they cannot reference the same memory address.
+
+ The construct `(mem:BLK (scratch))' is considered to alias all
+ other memories. Thus it may be used as a memory barrier in
+ epilogue stack deallocation patterns.
+
+`(concatM RTX RTX)'
+ This RTX represents the concatenation of two other RTXs. This is
+ used for complex values. It should only appear in the RTL
+ attached to declarations and during RTL generation. It should not
+ appear in the ordinary insn chain.
+
+`(concatnM [RTX ...])'
+ This RTX represents the concatenation of all the RTX to make a
+ single value. Like `concat', this should only appear in
+ declarations, and not in the insn chain.
+
+\1f
+File: gccint.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL
+
+10.9 RTL Expressions for Arithmetic
+===================================
+
+Unless otherwise specified, all the operands of arithmetic expressions
+must be valid for mode M. An operand is valid for mode M if it has
+mode M, or if it is a `const_int' or `const_double' and M is a mode of
+class `MODE_INT'.
+
+ For commutative binary operations, constants should be placed in the
+second operand.
+
+`(plus:M X Y)'
+`(ss_plus:M X Y)'
+`(us_plus:M X Y)'
+ These three expressions all represent the sum of the values
+ represented by X and Y carried out in machine mode M. They differ
+ in their behavior on overflow of integer modes. `plus' wraps
+ round modulo the width of M; `ss_plus' saturates at the maximum
+ signed value representable in M; `us_plus' saturates at the
+ maximum unsigned value.
+
+`(lo_sum:M X Y)'
+ This expression represents the sum of X and the low-order bits of
+ Y. It is used with `high' (*note Constants::) to represent the
+ typical two-instruction sequence used in RISC machines to
+ reference a global memory location.
+
+ The number of low order bits is machine-dependent but is normally
+ the number of bits in a `Pmode' item minus the number of bits set
+ by `high'.
+
+ M should be `Pmode'.
+
+`(minus:M X Y)'
+`(ss_minus:M X Y)'
+`(us_minus:M X Y)'
+ These three expressions represent the result of subtracting Y from
+ X, carried out in mode M. Behavior on overflow is the same as for
+ the three variants of `plus' (see above).
+
+`(compare:M X Y)'
+ Represents the result of subtracting Y from X for purposes of
+ comparison. The result is computed without overflow, as if with
+ infinite precision.
+
+ Of course, machines can't really subtract with infinite precision.
+ However, they can pretend to do so when only the sign of the
+ result will be used, which is the case when the result is stored
+ in the condition code. And that is the _only_ way this kind of
+ expression may validly be used: as a value to be stored in the
+ condition codes, either `(cc0)' or a register. *Note
+ Comparisons::.
+
+ The mode M is not related to the modes of X and Y, but instead is
+ the mode of the condition code value. If `(cc0)' is used, it is
+ `VOIDmode'. Otherwise it is some mode in class `MODE_CC', often
+ `CCmode'. *Note Condition Code::. If M is `VOIDmode' or
+ `CCmode', the operation returns sufficient information (in an
+ unspecified format) so that any comparison operator can be applied
+ to the result of the `COMPARE' operation. For other modes in
+ class `MODE_CC', the operation only returns a subset of this
+ information.
+
+ Normally, X and Y must have the same mode. Otherwise, `compare'
+ is valid only if the mode of X is in class `MODE_INT' and Y is a
+ `const_int' or `const_double' with mode `VOIDmode'. The mode of X
+ determines what mode the comparison is to be done in; thus it must
+ not be `VOIDmode'.
+
+ If one of the operands is a constant, it should be placed in the
+ second operand and the comparison code adjusted as appropriate.
+
+ A `compare' specifying two `VOIDmode' constants is not valid since
+ there is no way to know in what mode the comparison is to be
+ performed; the comparison must either be folded during the
+ compilation or the first operand must be loaded into a register
+ while its mode is still known.
+
+`(neg:M X)'
+`(ss_neg:M X)'
+`(us_neg:M X)'
+ These two expressions represent the negation (subtraction from
+ zero) of the value represented by X, carried out in mode M. They
+ differ in the behavior on overflow of integer modes. In the case
+ of `neg', the negation of the operand may be a number not
+ representable in mode M, in which case it is truncated to M.
+ `ss_neg' and `us_neg' ensure that an out-of-bounds result
+ saturates to the maximum or minimum signed or unsigned value.
+
+`(mult:M X Y)'
+`(ss_mult:M X Y)'
+`(us_mult:M X Y)'
+ Represents the signed product of the values represented by X and Y
+ carried out in machine mode M. `ss_mult' and `us_mult' ensure
+ that an out-of-bounds result saturates to the maximum or minimum
+ signed or unsigned value.
+
+ Some machines support a multiplication that generates a product
+ wider than the operands. Write the pattern for this as
+
+ (mult:M (sign_extend:M X) (sign_extend:M Y))
+
+ where M is wider than the modes of X and Y, which need not be the
+ same.
+
+ For unsigned widening multiplication, use the same idiom, but with
+ `zero_extend' instead of `sign_extend'.
+
+`(div:M X Y)'
+`(ss_div:M X Y)'
+ Represents the quotient in signed division of X by Y, carried out
+ in machine mode M. If M is a floating point mode, it represents
+ the exact quotient; otherwise, the integerized quotient. `ss_div'
+ ensures that an out-of-bounds result saturates to the maximum or
+ minimum signed value.
+
+ Some machines have division instructions in which the operands and
+ quotient widths are not all the same; you should represent such
+ instructions using `truncate' and `sign_extend' as in,
+
+ (truncate:M1 (div:M2 X (sign_extend:M2 Y)))
+
+`(udiv:M X Y)'
+`(us_div:M X Y)'
+ Like `div' but represents unsigned division. `us_div' ensures
+ that an out-of-bounds result saturates to the maximum or minimum
+ unsigned value.
+
+`(mod:M X Y)'
+`(umod:M X Y)'
+ Like `div' and `udiv' but represent the remainder instead of the
+ quotient.
+
+`(smin:M X Y)'
+`(smax:M X Y)'
+ Represents the smaller (for `smin') or larger (for `smax') of X
+ and Y, interpreted as signed values in mode M. When used with
+ floating point, if both operands are zeros, or if either operand
+ is `NaN', then it is unspecified which of the two operands is
+ returned as the result.
+
+`(umin:M X Y)'
+`(umax:M X Y)'
+ Like `smin' and `smax', but the values are interpreted as unsigned
+ integers.
+
+`(not:M X)'
+ Represents the bitwise complement of the value represented by X,
+ carried out in mode M, which must be a fixed-point machine mode.
+
+`(and:M X Y)'
+ Represents the bitwise logical-and of the values represented by X
+ and Y, carried out in machine mode M, which must be a fixed-point
+ machine mode.
+
+`(ior:M X Y)'
+ Represents the bitwise inclusive-or of the values represented by X
+ and Y, carried out in machine mode M, which must be a fixed-point
+ mode.
+
+`(xor:M X Y)'
+ Represents the bitwise exclusive-or of the values represented by X
+ and Y, carried out in machine mode M, which must be a fixed-point
+ mode.
+
+`(ashift:M X C)'
+`(ss_ashift:M X C)'
+`(us_ashift:M X C)'
+ These three expressions represent the result of arithmetically
+ shifting X left by C places. They differ in their behavior on
+ overflow of integer modes. An `ashift' operation is a plain shift
+ with no special behavior in case of a change in the sign bit;
+ `ss_ashift' and `us_ashift' saturates to the minimum or maximum
+ representable value if any of the bits shifted out differs from
+ the final sign bit.
+
+ X have mode M, a fixed-point machine mode. C be a fixed-point
+ mode or be a constant with mode `VOIDmode'; which mode is
+ determined by the mode called for in the machine description entry
+ for the left-shift instruction. For example, on the VAX, the mode
+ of C is `QImode' regardless of M.
+
+`(lshiftrt:M X C)'
+`(ashiftrt:M X C)'
+ Like `ashift' but for right shift. Unlike the case for left shift,
+ these two operations are distinct.
+
+`(rotate:M X C)'
+`(rotatert:M X C)'
+ Similar but represent left and right rotate. If C is a constant,
+ use `rotate'.
+
+`(abs:M X)'
+ Represents the absolute value of X, computed in mode M.
+
+`(sqrt:M X)'
+ Represents the square root of X, computed in mode M. Most often M
+ will be a floating point mode.
+
+`(ffs:M X)'
+ Represents one plus the index of the least significant 1-bit in X,
+ represented as an integer of mode M. (The value is zero if X is
+ zero.) The mode of X need not be M; depending on the target
+ machine, various mode combinations may be valid.
+
+`(clz:M X)'
+ Represents the number of leading 0-bits in X, represented as an
+ integer of mode M, starting at the most significant bit position.
+ If X is zero, the value is determined by
+ `CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Note that this is one
+ of the few expressions that is not invariant under widening. The
+ mode of X will usually be an integer mode.
+
+`(ctz:M X)'
+ Represents the number of trailing 0-bits in X, represented as an
+ integer of mode M, starting at the least significant bit position.
+ If X is zero, the value is determined by
+ `CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::). Except for this case,
+ `ctz(x)' is equivalent to `ffs(X) - 1'. The mode of X will
+ usually be an integer mode.
+
+`(popcount:M X)'
+ Represents the number of 1-bits in X, represented as an integer of
+ mode M. The mode of X will usually be an integer mode.
+
+`(parity:M X)'
+ Represents the number of 1-bits modulo 2 in X, represented as an
+ integer of mode M. The mode of X will usually be an integer mode.
+
+`(bswap:M X)'
+ Represents the value X with the order of bytes reversed, carried
+ out in mode M, which must be a fixed-point machine mode.
+
+\1f
+File: gccint.info, Node: Comparisons, Next: Bit-Fields, Prev: Arithmetic, Up: RTL
+
+10.10 Comparison Operations
+===========================
+
+Comparison operators test a relation on two operands and are considered
+to represent a machine-dependent nonzero value described by, but not
+necessarily equal to, `STORE_FLAG_VALUE' (*note Misc::) if the relation
+holds, or zero if it does not, for comparison operators whose results
+have a `MODE_INT' mode, `FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the
+relation holds, or zero if it does not, for comparison operators that
+return floating-point values, and a vector of either
+`VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of
+zeros if it does not, for comparison operators that return vector
+results. The mode of the comparison operation is independent of the
+mode of the data being compared. If the comparison operation is being
+tested (e.g., the first operand of an `if_then_else'), the mode must be
+`VOIDmode'.
+
+ There are two ways that comparison operations may be used. The
+comparison operators may be used to compare the condition codes `(cc0)'
+against zero, as in `(eq (cc0) (const_int 0))'. Such a construct
+actually refers to the result of the preceding instruction in which the
+condition codes were set. The instruction setting the condition code
+must be adjacent to the instruction using the condition code; only
+`note' insns may separate them.
+
+ Alternatively, a comparison operation may directly compare two data
+objects. The mode of the comparison is determined by the operands; they
+must both be valid for a common machine mode. A comparison with both
+operands constant would be invalid as the machine mode could not be
+deduced from it, but such a comparison should never exist in RTL due to
+constant folding.
+
+ In the example above, if `(cc0)' were last set to `(compare X Y)', the
+comparison operation is identical to `(eq X Y)'. Usually only one style
+of comparisons is supported on a particular machine, but the combine
+pass will try to merge the operations to produce the `eq' shown in case
+it exists in the context of the particular insn involved.
+
+ Inequality comparisons come in two flavors, signed and unsigned. Thus,
+there are distinct expression codes `gt' and `gtu' for signed and
+unsigned greater-than. These can produce different results for the same
+pair of integer values: for example, 1 is signed greater-than -1 but not
+unsigned greater-than, because -1 when regarded as unsigned is actually
+`0xffffffff' which is greater than 1.
+
+ The signed comparisons are also used for floating point values.
+Floating point comparisons are distinguished by the machine modes of
+the operands.
+
+`(eq:M X Y)'
+ `STORE_FLAG_VALUE' if the values represented by X and Y are equal,
+ otherwise 0.
+
+`(ne:M X Y)'
+ `STORE_FLAG_VALUE' if the values represented by X and Y are not
+ equal, otherwise 0.
+
+`(gt:M X Y)'
+ `STORE_FLAG_VALUE' if the X is greater than Y. If they are
+ fixed-point, the comparison is done in a signed sense.
+
+`(gtu:M X Y)'
+ Like `gt' but does unsigned comparison, on fixed-point numbers
+ only.
+
+`(lt:M X Y)'
+`(ltu:M X Y)'
+ Like `gt' and `gtu' but test for "less than".
+
+`(ge:M X Y)'
+`(geu:M X Y)'
+ Like `gt' and `gtu' but test for "greater than or equal".
+
+`(le:M X Y)'
+`(leu:M X Y)'
+ Like `gt' and `gtu' but test for "less than or equal".
+
+`(if_then_else COND THEN ELSE)'
+ This is not a comparison operation but is listed here because it is
+ always used in conjunction with a comparison operation. To be
+ precise, COND is a comparison expression. This expression
+ represents a choice, according to COND, between the value
+ represented by THEN and the one represented by ELSE.
+
+ On most machines, `if_then_else' expressions are valid only to
+ express conditional jumps.
+
+`(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)'
+ Similar to `if_then_else', but more general. Each of TEST1,
+ TEST2, ... is performed in turn. The result of this expression is
+ the VALUE corresponding to the first nonzero test, or DEFAULT if
+ none of the tests are nonzero expressions.
+
+ This is currently not valid for instruction patterns and is
+ supported only for insn attributes. *Note Insn Attributes::.
+
+\1f
+File: gccint.info, Node: Bit-Fields, Next: Vector Operations, Prev: Comparisons, Up: RTL
+
+10.11 Bit-Fields
+================
+
+Special expression codes exist to represent bit-field instructions.
+
+`(sign_extract:M LOC SIZE POS)'
+ This represents a reference to a sign-extended bit-field contained
+ or starting in LOC (a memory or register reference). The bit-field
+ is SIZE bits wide and starts at bit POS. The compilation option
+ `BITS_BIG_ENDIAN' says which end of the memory unit POS counts
+ from.
+
+ If LOC is in memory, its mode must be a single-byte integer mode.
+ If LOC is in a register, the mode to use is specified by the
+ operand of the `insv' or `extv' pattern (*note Standard Names::)
+ and is usually a full-word integer mode, which is the default if
+ none is specified.
+
+ The mode of POS is machine-specific and is also specified in the
+ `insv' or `extv' pattern.
+
+ The mode M is the same as the mode that would be used for LOC if
+ it were a register.
+
+ A `sign_extract' can not appear as an lvalue, or part thereof, in
+ RTL.
+
+`(zero_extract:M LOC SIZE POS)'
+ Like `sign_extract' but refers to an unsigned or zero-extended
+ bit-field. The same sequence of bits are extracted, but they are
+ filled to an entire word with zeros instead of by sign-extension.
+
+ Unlike `sign_extract', this type of expressions can be lvalues in
+ RTL; they may appear on the left side of an assignment, indicating
+ insertion of a value into the specified bit-field.
+
+\1f
+File: gccint.info, Node: Vector Operations, Next: Conversions, Prev: Bit-Fields, Up: RTL
+
+10.12 Vector Operations
+=======================
+
+All normal RTL expressions can be used with vector modes; they are
+interpreted as operating on each part of the vector independently.
+Additionally, there are a few new expressions to describe specific
+vector operations.
+
+`(vec_merge:M VEC1 VEC2 ITEMS)'
+ This describes a merge operation between two vectors. The result
+ is a vector of mode M; its elements are selected from either VEC1
+ or VEC2. Which elements are selected is described by ITEMS, which
+ is a bit mask represented by a `const_int'; a zero bit indicates
+ the corresponding element in the result vector is taken from VEC2
+ while a set bit indicates it is taken from VEC1.
+
+`(vec_select:M VEC1 SELECTION)'
+ This describes an operation that selects parts of a vector. VEC1
+ is the source vector, SELECTION is a `parallel' that contains a
+ `const_int' for each of the subparts of the result vector, giving
+ the number of the source subpart that should be stored into it.
+
+`(vec_concat:M VEC1 VEC2)'
+ Describes a vector concat operation. The result is a
+ concatenation of the vectors VEC1 and VEC2; its length is the sum
+ of the lengths of the two inputs.
+
+`(vec_duplicate:M VEC)'
+ This operation converts a small vector into a larger one by
+ duplicating the input values. The output vector mode must have
+ the same submodes as the input vector mode, and the number of
+ output parts must be an integer multiple of the number of input
+ parts.
+
+
+\1f
+File: gccint.info, Node: Conversions, Next: RTL Declarations, Prev: Vector Operations, Up: RTL
+
+10.13 Conversions
+=================
+
+All conversions between machine modes must be represented by explicit
+conversion operations. For example, an expression which is the sum of
+a byte and a full word cannot be written as `(plus:SI (reg:QI 34)
+(reg:SI 80))' because the `plus' operation requires two operands of the
+same machine mode. Therefore, the byte-sized operand is enclosed in a
+conversion operation, as in
+
+ (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80))
+
+ The conversion operation is not a mere placeholder, because there may
+be more than one way of converting from a given starting mode to the
+desired final mode. The conversion operation code says how to do it.
+
+ For all conversion operations, X must not be `VOIDmode' because the
+mode in which to do the conversion would not be known. The conversion
+must either be done at compile-time or X must be placed into a register.
+
+`(sign_extend:M X)'
+ Represents the result of sign-extending the value X to machine
+ mode M. M must be a fixed-point mode and X a fixed-point value of
+ a mode narrower than M.
+
+`(zero_extend:M X)'
+ Represents the result of zero-extending the value X to machine
+ mode M. M must be a fixed-point mode and X a fixed-point value of
+ a mode narrower than M.
+
+`(float_extend:M X)'
+ Represents the result of extending the value X to machine mode M.
+ M must be a floating point mode and X a floating point value of a
+ mode narrower than M.
+
+`(truncate:M X)'
+ Represents the result of truncating the value X to machine mode M.
+ M must be a fixed-point mode and X a fixed-point value of a mode
+ wider than M.
+
+`(ss_truncate:M X)'
+ Represents the result of truncating the value X to machine mode M,
+ using signed saturation in the case of overflow. Both M and the
+ mode of X must be fixed-point modes.
+
+`(us_truncate:M X)'
+ Represents the result of truncating the value X to machine mode M,
+ using unsigned saturation in the case of overflow. Both M and the
+ mode of X must be fixed-point modes.
+
+`(float_truncate:M X)'
+ Represents the result of truncating the value X to machine mode M.
+ M must be a floating point mode and X a floating point value of a
+ mode wider than M.
+
+`(float:M X)'
+ Represents the result of converting fixed point value X, regarded
+ as signed, to floating point mode M.
+
+`(unsigned_float:M X)'
+ Represents the result of converting fixed point value X, regarded
+ as unsigned, to floating point mode M.
+
+`(fix:M X)'
+ When M is a floating-point mode, represents the result of
+ converting floating point value X (valid for mode M) to an
+ integer, still represented in floating point mode M, by rounding
+ towards zero.
+
+ When M is a fixed-point mode, represents the result of converting
+ floating point value X to mode M, regarded as signed. How
+ rounding is done is not specified, so this operation may be used
+ validly in compiling C code only for integer-valued operands.
+
+`(unsigned_fix:M X)'
+ Represents the result of converting floating point value X to
+ fixed point mode M, regarded as unsigned. How rounding is done is
+ not specified.
+
+`(fract_convert:M X)'
+ Represents the result of converting fixed-point value X to
+ fixed-point mode M, signed integer value X to fixed-point mode M,
+ floating-point value X to fixed-point mode M, fixed-point value X
+ to integer mode M regarded as signed, or fixed-point value X to
+ floating-point mode M. When overflows or underflows happen, the
+ results are undefined.
+
+`(sat_fract:M X)'
+ Represents the result of converting fixed-point value X to
+ fixed-point mode M, signed integer value X to fixed-point mode M,
+ or floating-point value X to fixed-point mode M. When overflows
+ or underflows happen, the results are saturated to the maximum or
+ the minimum.
+
+`(unsigned_fract_convert:M X)'
+ Represents the result of converting fixed-point value X to integer
+ mode M regarded as unsigned, or unsigned integer value X to
+ fixed-point mode M. When overflows or underflows happen, the
+ results are undefined.
+
+`(unsigned_sat_fract:M X)'
+ Represents the result of converting unsigned integer value X to
+ fixed-point mode M. When overflows or underflows happen, the
+ results are saturated to the maximum or the minimum.
+
+\1f
+File: gccint.info, Node: RTL Declarations, Next: Side Effects, Prev: Conversions, Up: RTL
+
+10.14 Declarations
+==================
+
+Declaration expression codes do not represent arithmetic operations but
+rather state assertions about their operands.
+
+`(strict_low_part (subreg:M (reg:N R) 0))'
+ This expression code is used in only one context: as the
+ destination operand of a `set' expression. In addition, the
+ operand of this expression must be a non-paradoxical `subreg'
+ expression.
+
+ The presence of `strict_low_part' says that the part of the
+ register which is meaningful in mode N, but is not part of mode M,
+ is not to be altered. Normally, an assignment to such a subreg is
+ allowed to have undefined effects on the rest of the register when
+ M is less than a word.
+
+\1f
+File: gccint.info, Node: Side Effects, Next: Incdec, Prev: RTL Declarations, Up: RTL
+
+10.15 Side Effect Expressions
+=============================
+
+The expression codes described so far represent values, not actions.
+But machine instructions never produce values; they are meaningful only
+for their side effects on the state of the machine. Special expression
+codes are used to represent side effects.
+
+ The body of an instruction is always one of these side effect codes;
+the codes described above, which represent values, appear only as the
+operands of these.
+
+`(set LVAL X)'
+ Represents the action of storing the value of X into the place
+ represented by LVAL. LVAL must be an expression representing a
+ place that can be stored in: `reg' (or `subreg', `strict_low_part'
+ or `zero_extract'), `mem', `pc', `parallel', or `cc0'.
+
+ If LVAL is a `reg', `subreg' or `mem', it has a machine mode; then
+ X must be valid for that mode.
+
+ If LVAL is a `reg' whose machine mode is less than the full width
+ of the register, then it means that the part of the register
+ specified by the machine mode is given the specified value and the
+ rest of the register receives an undefined value. Likewise, if
+ LVAL is a `subreg' whose machine mode is narrower than the mode of
+ the register, the rest of the register can be changed in an
+ undefined way.
+
+ If LVAL is a `strict_low_part' of a subreg, then the part of the
+ register specified by the machine mode of the `subreg' is given
+ the value X and the rest of the register is not changed.
+
+ If LVAL is a `zero_extract', then the referenced part of the
+ bit-field (a memory or register reference) specified by the
+ `zero_extract' is given the value X and the rest of the bit-field
+ is not changed. Note that `sign_extract' can not appear in LVAL.
+
+ If LVAL is `(cc0)', it has no machine mode, and X may be either a
+ `compare' expression or a value that may have any mode. The
+ latter case represents a "test" instruction. The expression `(set
+ (cc0) (reg:M N))' is equivalent to `(set (cc0) (compare (reg:M N)
+ (const_int 0)))'. Use the former expression to save space during
+ the compilation.
+
+ If LVAL is a `parallel', it is used to represent the case of a
+ function returning a structure in multiple registers. Each element
+ of the `parallel' is an `expr_list' whose first operand is a `reg'
+ and whose second operand is a `const_int' representing the offset
+ (in bytes) into the structure at which the data in that register
+ corresponds. The first element may be null to indicate that the
+ structure is also passed partly in memory.
+
+ If LVAL is `(pc)', we have a jump instruction, and the
+ possibilities for X are very limited. It may be a `label_ref'
+ expression (unconditional jump). It may be an `if_then_else'
+ (conditional jump), in which case either the second or the third
+ operand must be `(pc)' (for the case which does not jump) and the
+ other of the two must be a `label_ref' (for the case which does
+ jump). X may also be a `mem' or `(plus:SI (pc) Y)', where Y may
+ be a `reg' or a `mem'; these unusual patterns are used to
+ represent jumps through branch tables.
+
+ If LVAL is neither `(cc0)' nor `(pc)', the mode of LVAL must not
+ be `VOIDmode' and the mode of X must be valid for the mode of LVAL.
+
+ LVAL is customarily accessed with the `SET_DEST' macro and X with
+ the `SET_SRC' macro.
+
+`(return)'
+ As the sole expression in a pattern, represents a return from the
+ current function, on machines where this can be done with one
+ instruction, such as VAXen. On machines where a multi-instruction
+ "epilogue" must be executed in order to return from the function,
+ returning is done by jumping to a label which precedes the
+ epilogue, and the `return' expression code is never used.
+
+ Inside an `if_then_else' expression, represents the value to be
+ placed in `pc' to return to the caller.
+
+ Note that an insn pattern of `(return)' is logically equivalent to
+ `(set (pc) (return))', but the latter form is never used.
+
+`(call FUNCTION NARGS)'
+ Represents a function call. FUNCTION is a `mem' expression whose
+ address is the address of the function to be called. NARGS is an
+ expression which can be used for two purposes: on some machines it
+ represents the number of bytes of stack argument; on others, it
+ represents the number of argument registers.
+
+ Each machine has a standard machine mode which FUNCTION must have.
+ The machine description defines macro `FUNCTION_MODE' to expand
+ into the requisite mode name. The purpose of this mode is to
+ specify what kind of addressing is allowed, on machines where the
+ allowed kinds of addressing depend on the machine mode being
+ addressed.
+
+`(clobber X)'
+ Represents the storing or possible storing of an unpredictable,
+ undescribed value into X, which must be a `reg', `scratch',
+ `parallel' or `mem' expression.
+
+ One place this is used is in string instructions that store
+ standard values into particular hard registers. It may not be
+ worth the trouble to describe the values that are stored, but it
+ is essential to inform the compiler that the registers will be
+ altered, lest it attempt to keep data in them across the string
+ instruction.
+
+ If X is `(mem:BLK (const_int 0))' or `(mem:BLK (scratch))', it
+ means that all memory locations must be presumed clobbered. If X
+ is a `parallel', it has the same meaning as a `parallel' in a
+ `set' expression.
+
+ Note that the machine description classifies certain hard
+ registers as "call-clobbered". All function call instructions are
+ assumed by default to clobber these registers, so there is no need
+ to use `clobber' expressions to indicate this fact. Also, each
+ function call is assumed to have the potential to alter any memory
+ location, unless the function is declared `const'.
+
+ If the last group of expressions in a `parallel' are each a
+ `clobber' expression whose arguments are `reg' or `match_scratch'
+ (*note RTL Template::) expressions, the combiner phase can add the
+ appropriate `clobber' expressions to an insn it has constructed
+ when doing so will cause a pattern to be matched.
+
+ This feature can be used, for example, on a machine that whose
+ multiply and add instructions don't use an MQ register but which
+ has an add-accumulate instruction that does clobber the MQ
+ register. Similarly, a combined instruction might require a
+ temporary register while the constituent instructions might not.
+
+ When a `clobber' expression for a register appears inside a
+ `parallel' with other side effects, the register allocator
+ guarantees that the register is unoccupied both before and after
+ that insn if it is a hard register clobber. For pseudo-register
+ clobber, the register allocator and the reload pass do not assign
+ the same hard register to the clobber and the input operands if
+ there is an insn alternative containing the `&' constraint (*note
+ Modifiers::) for the clobber and the hard register is in register
+ classes of the clobber in the alternative. You can clobber either
+ a specific hard register, a pseudo register, or a `scratch'
+ expression; in the latter two cases, GCC will allocate a hard
+ register that is available there for use as a temporary.
+
+ For instructions that require a temporary register, you should use
+ `scratch' instead of a pseudo-register because this will allow the
+ combiner phase to add the `clobber' when required. You do this by
+ coding (`clobber' (`match_scratch' ...)). If you do clobber a
+ pseudo register, use one which appears nowhere else--generate a
+ new one each time. Otherwise, you may confuse CSE.
+
+ There is one other known use for clobbering a pseudo register in a
+ `parallel': when one of the input operands of the insn is also
+ clobbered by the insn. In this case, using the same pseudo
+ register in the clobber and elsewhere in the insn produces the
+ expected results.
+
+`(use X)'
+ Represents the use of the value of X. It indicates that the value
+ in X at this point in the program is needed, even though it may
+ not be apparent why this is so. Therefore, the compiler will not
+ attempt to delete previous instructions whose only effect is to
+ store a value in X. X must be a `reg' expression.
+
+ In some situations, it may be tempting to add a `use' of a
+ register in a `parallel' to describe a situation where the value
+ of a special register will modify the behavior of the instruction.
+ An hypothetical example might be a pattern for an addition that can
+ either wrap around or use saturating addition depending on the
+ value of a special control register:
+
+ (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3)
+ (reg:SI 4)] 0))
+ (use (reg:SI 1))])
+
+ This will not work, several of the optimizers only look at
+ expressions locally; it is very likely that if you have multiple
+ insns with identical inputs to the `unspec', they will be
+ optimized away even if register 1 changes in between.
+
+ This means that `use' can _only_ be used to describe that the
+ register is live. You should think twice before adding `use'
+ statements, more often you will want to use `unspec' instead. The
+ `use' RTX is most commonly useful to describe that a fixed
+ register is implicitly used in an insn. It is also safe to use in
+ patterns where the compiler knows for other reasons that the result
+ of the whole pattern is variable, such as `movmemM' or `call'
+ patterns.
+
+ During the reload phase, an insn that has a `use' as pattern can
+ carry a reg_equal note. These `use' insns will be deleted before
+ the reload phase exits.
+
+ During the delayed branch scheduling phase, X may be an insn.
+ This indicates that X previously was located at this place in the
+ code and its data dependencies need to be taken into account.
+ These `use' insns will be deleted before the delayed branch
+ scheduling phase exits.
+
+`(parallel [X0 X1 ...])'
+ Represents several side effects performed in parallel. The square
+ brackets stand for a vector; the operand of `parallel' is a vector
+ of expressions. X0, X1 and so on are individual side effect
+ expressions--expressions of code `set', `call', `return',
+ `clobber' or `use'.
+
+ "In parallel" means that first all the values used in the
+ individual side-effects are computed, and second all the actual
+ side-effects are performed. For example,
+
+ (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
+ (set (mem:SI (reg:SI 1)) (reg:SI 1))])
+
+ says unambiguously that the values of hard register 1 and the
+ memory location addressed by it are interchanged. In both places
+ where `(reg:SI 1)' appears as a memory address it refers to the
+ value in register 1 _before_ the execution of the insn.
+
+ It follows that it is _incorrect_ to use `parallel' and expect the
+ result of one `set' to be available for the next one. For
+ example, people sometimes attempt to represent a jump-if-zero
+ instruction this way:
+
+ (parallel [(set (cc0) (reg:SI 34))
+ (set (pc) (if_then_else
+ (eq (cc0) (const_int 0))
+ (label_ref ...)
+ (pc)))])
+
+ But this is incorrect, because it says that the jump condition
+ depends on the condition code value _before_ this instruction, not
+ on the new value that is set by this instruction.
+
+ Peephole optimization, which takes place together with final
+ assembly code output, can produce insns whose patterns consist of
+ a `parallel' whose elements are the operands needed to output the
+ resulting assembler code--often `reg', `mem' or constant
+ expressions. This would not be well-formed RTL at any other stage
+ in compilation, but it is ok then because no further optimization
+ remains to be done. However, the definition of the macro
+ `NOTICE_UPDATE_CC', if any, must deal with such insns if you
+ define any peephole optimizations.
+
+`(cond_exec [COND EXPR])'
+ Represents a conditionally executed expression. The EXPR is
+ executed only if the COND is nonzero. The COND expression must
+ not have side-effects, but the EXPR may very well have
+ side-effects.
+
+`(sequence [INSNS ...])'
+ Represents a sequence of insns. Each of the INSNS that appears in
+ the vector is suitable for appearing in the chain of insns, so it
+ must be an `insn', `jump_insn', `call_insn', `code_label',
+ `barrier' or `note'.
+
+ A `sequence' RTX is never placed in an actual insn during RTL
+ generation. It represents the sequence of insns that result from a
+ `define_expand' _before_ those insns are passed to `emit_insn' to
+ insert them in the chain of insns. When actually inserted, the
+ individual sub-insns are separated out and the `sequence' is
+ forgotten.
+
+ After delay-slot scheduling is completed, an insn and all the
+ insns that reside in its delay slots are grouped together into a
+ `sequence'. The insn requiring the delay slot is the first insn
+ in the vector; subsequent insns are to be placed in the delay slot.
+
+ `INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to
+ indicate that a branch insn should be used that will conditionally
+ annul the effect of the insns in the delay slots. In such a case,
+ `INSN_FROM_TARGET_P' indicates that the insn is from the target of
+ the branch and should be executed only if the branch is taken;
+ otherwise the insn should be executed only if the branch is not
+ taken. *Note Delay Slots::.
+
+ These expression codes appear in place of a side effect, as the body of
+an insn, though strictly speaking they do not always describe side
+effects as such:
+
+`(asm_input S)'
+ Represents literal assembler code as described by the string S.
+
+`(unspec [OPERANDS ...] INDEX)'
+`(unspec_volatile [OPERANDS ...] INDEX)'
+ Represents a machine-specific operation on OPERANDS. INDEX
+ selects between multiple machine-specific operations.
+ `unspec_volatile' is used for volatile operations and operations
+ that may trap; `unspec' is used for other operations.
+
+ These codes may appear inside a `pattern' of an insn, inside a
+ `parallel', or inside an expression.
+
+`(addr_vec:M [LR0 LR1 ...])'
+ Represents a table of jump addresses. The vector elements LR0,
+ etc., are `label_ref' expressions. The mode M specifies how much
+ space is given to each address; normally M would be `Pmode'.
+
+`(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)'
+ Represents a table of jump addresses expressed as offsets from
+ BASE. The vector elements LR0, etc., are `label_ref' expressions
+ and so is BASE. The mode M specifies how much space is given to
+ each address-difference. MIN and MAX are set up by branch
+ shortening and hold a label with a minimum and a maximum address,
+ respectively. FLAGS indicates the relative position of BASE, MIN
+ and MAX to the containing insn and of MIN and MAX to BASE. See
+ rtl.def for details.
+
+`(prefetch:M ADDR RW LOCALITY)'
+ Represents prefetch of memory at address ADDR. Operand RW is 1 if
+ the prefetch is for data to be written, 0 otherwise; targets that
+ do not support write prefetches should treat this as a normal
+ prefetch. Operand LOCALITY specifies the amount of temporal
+ locality; 0 if there is none or 1, 2, or 3 for increasing levels
+ of temporal locality; targets that do not support locality hints
+ should ignore this.
+
+ This insn is used to minimize cache-miss latency by moving data
+ into a cache before it is accessed. It should use only
+ non-faulting data prefetch instructions.
+
+\1f
+File: gccint.info, Node: Incdec, Next: Assembler, Prev: Side Effects, Up: RTL
+
+10.16 Embedded Side-Effects on Addresses
+========================================
+
+Six special side-effect expression codes appear as memory addresses.
+
+`(pre_dec:M X)'
+ Represents the side effect of decrementing X by a standard amount
+ and represents also the value that X has after being decremented.
+ X must be a `reg' or `mem', but most machines allow only a `reg'.
+ M must be the machine mode for pointers on the machine in use.
+ The amount X is decremented by is the length in bytes of the
+ machine mode of the containing memory reference of which this
+ expression serves as the address. Here is an example of its use:
+
+ (mem:DF (pre_dec:SI (reg:SI 39)))
+
+ This says to decrement pseudo register 39 by the length of a
+ `DFmode' value and use the result to address a `DFmode' value.
+
+`(pre_inc:M X)'
+ Similar, but specifies incrementing X instead of decrementing it.
+
+`(post_dec:M X)'
+ Represents the same side effect as `pre_dec' but a different
+ value. The value represented here is the value X has before being
+ decremented.
+
+`(post_inc:M X)'
+ Similar, but specifies incrementing X instead of decrementing it.
+
+`(post_modify:M X Y)'
+ Represents the side effect of setting X to Y and represents X
+ before X is modified. X must be a `reg' or `mem', but most
+ machines allow only a `reg'. M must be the machine mode for
+ pointers on the machine in use.
+
+ The expression Y must be one of three forms: `(plus:M X Z)',
+ `(minus:M X Z)', or `(plus:M X I)', where Z is an index register
+ and I is a constant.
+
+ Here is an example of its use:
+
+ (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42)
+ (reg:SI 48))))
+
+ This says to modify pseudo register 42 by adding the contents of
+ pseudo register 48 to it, after the use of what ever 42 points to.
+
+`(pre_modify:M X EXPR)'
+ Similar except side effects happen before the use.
+
+ These embedded side effect expressions must be used with care.
+Instruction patterns may not use them. Until the `flow' pass of the
+compiler, they may occur only to represent pushes onto the stack. The
+`flow' pass finds cases where registers are incremented or decremented
+in one instruction and used as an address shortly before or after;
+these cases are then transformed to use pre- or post-increment or
+-decrement.
+
+ If a register used as the operand of these expressions is used in
+another address in an insn, the original value of the register is used.
+Uses of the register outside of an address are not permitted within the
+same insn as a use in an embedded side effect expression because such
+insns behave differently on different machines and hence must be treated
+as ambiguous and disallowed.
+
+ An instruction that can be represented with an embedded side effect
+could also be represented using `parallel' containing an additional
+`set' to describe how the address register is altered. This is not
+done because machines that allow these operations at all typically
+allow them wherever a memory address is called for. Describing them as
+additional parallel stores would require doubling the number of entries
+in the machine description.
+
+\1f
+File: gccint.info, Node: Assembler, Next: Insns, Prev: Incdec, Up: RTL
+
+10.17 Assembler Instructions as Expressions
+===========================================
+
+The RTX code `asm_operands' represents a value produced by a
+user-specified assembler instruction. It is used to represent an `asm'
+statement with arguments. An `asm' statement with a single output
+operand, like this:
+
+ asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z));
+
+is represented using a single `asm_operands' RTX which represents the
+value that is stored in `outputvar':
+
+ (set RTX-FOR-OUTPUTVAR
+ (asm_operands "foo %1,%2,%0" "a" 0
+ [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z]
+ [(asm_input:M1 "g")
+ (asm_input:M2 "di")]))
+
+Here the operands of the `asm_operands' RTX are the assembler template
+string, the output-operand's constraint, the index-number of the output
+operand among the output operands specified, a vector of input operand
+RTX's, and a vector of input-operand modes and constraints. The mode
+M1 is the mode of the sum `x+y'; M2 is that of `*z'.
+
+ When an `asm' statement has multiple output values, its insn has
+several such `set' RTX's inside of a `parallel'. Each `set' contains a
+`asm_operands'; all of these share the same assembler template and
+vectors, but each contains the constraint for the respective output
+operand. They are also distinguished by the output-operand index
+number, which is 0, 1, ... for successive output operands.
+
+\1f
+File: gccint.info, Node: Insns, Next: Calls, Prev: Assembler, Up: RTL
+
+10.18 Insns
+===========
+
+The RTL representation of the code for a function is a doubly-linked
+chain of objects called "insns". Insns are expressions with special
+codes that are used for no other purpose. Some insns are actual
+instructions; others represent dispatch tables for `switch' statements;
+others represent labels to jump to or various sorts of declarative
+information.
+
+ In addition to its own specific data, each insn must have a unique
+id-number that distinguishes it from all other insns in the current
+function (after delayed branch scheduling, copies of an insn with the
+same id-number may be present in multiple places in a function, but
+these copies will always be identical and will only appear inside a
+`sequence'), and chain pointers to the preceding and following insns.
+These three fields occupy the same position in every insn, independent
+of the expression code of the insn. They could be accessed with `XEXP'
+and `XINT', but instead three special macros are always used:
+
+`INSN_UID (I)'
+ Accesses the unique id of insn I.
+
+`PREV_INSN (I)'
+ Accesses the chain pointer to the insn preceding I. If I is the
+ first insn, this is a null pointer.
+
+`NEXT_INSN (I)'
+ Accesses the chain pointer to the insn following I. If I is the
+ last insn, this is a null pointer.
+
+ The first insn in the chain is obtained by calling `get_insns'; the
+last insn is the result of calling `get_last_insn'. Within the chain
+delimited by these insns, the `NEXT_INSN' and `PREV_INSN' pointers must
+always correspond: if INSN is not the first insn,
+
+ NEXT_INSN (PREV_INSN (INSN)) == INSN
+
+is always true and if INSN is not the last insn,
+
+ PREV_INSN (NEXT_INSN (INSN)) == INSN
+
+is always true.
+
+ After delay slot scheduling, some of the insns in the chain might be
+`sequence' expressions, which contain a vector of insns. The value of
+`NEXT_INSN' in all but the last of these insns is the next insn in the
+vector; the value of `NEXT_INSN' of the last insn in the vector is the
+same as the value of `NEXT_INSN' for the `sequence' in which it is
+contained. Similar rules apply for `PREV_INSN'.
+
+ This means that the above invariants are not necessarily true for insns
+inside `sequence' expressions. Specifically, if INSN is the first insn
+in a `sequence', `NEXT_INSN (PREV_INSN (INSN))' is the insn containing
+the `sequence' expression, as is the value of `PREV_INSN (NEXT_INSN
+(INSN))' if INSN is the last insn in the `sequence' expression. You
+can use these expressions to find the containing `sequence' expression.
+
+ Every insn has one of the following six expression codes:
+
+`insn'
+ The expression code `insn' is used for instructions that do not
+ jump and do not do function calls. `sequence' expressions are
+ always contained in insns with code `insn' even if one of those
+ insns should jump or do function calls.
+
+ Insns with code `insn' have four additional fields beyond the three
+ mandatory ones listed above. These four are described in a table
+ below.
+
+`jump_insn'
+ The expression code `jump_insn' is used for instructions that may
+ jump (or, more generally, may contain `label_ref' expressions to
+ which `pc' can be set in that instruction). If there is an
+ instruction to return from the current function, it is recorded as
+ a `jump_insn'.
+
+ `jump_insn' insns have the same extra fields as `insn' insns,
+ accessed in the same way and in addition contain a field
+ `JUMP_LABEL' which is defined once jump optimization has completed.
+
+ For simple conditional and unconditional jumps, this field contains
+ the `code_label' to which this insn will (possibly conditionally)
+ branch. In a more complex jump, `JUMP_LABEL' records one of the
+ labels that the insn refers to; other jump target labels are
+ recorded as `REG_LABEL_TARGET' notes. The exception is `addr_vec'
+ and `addr_diff_vec', where `JUMP_LABEL' is `NULL_RTX' and the only
+ way to find the labels is to scan the entire body of the insn.
+
+ Return insns count as jumps, but since they do not refer to any
+ labels, their `JUMP_LABEL' is `NULL_RTX'.
+
+`call_insn'
+ The expression code `call_insn' is used for instructions that may
+ do function calls. It is important to distinguish these
+ instructions because they imply that certain registers and memory
+ locations may be altered unpredictably.
+
+ `call_insn' insns have the same extra fields as `insn' insns,
+ accessed in the same way and in addition contain a field
+ `CALL_INSN_FUNCTION_USAGE', which contains a list (chain of
+ `expr_list' expressions) containing `use' and `clobber'
+ expressions that denote hard registers and `MEM's used or
+ clobbered by the called function.
+
+ A `MEM' generally points to a stack slots in which arguments passed
+ to the libcall by reference (*note TARGET_PASS_BY_REFERENCE:
+ Register Arguments.) are stored. If the argument is caller-copied
+ (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot
+ will be mentioned in `CLOBBER' and `USE' entries; if it's
+ callee-copied, only a `USE' will appear, and the `MEM' may point
+ to addresses that are not stack slots.
+
+ `CLOBBER'ed registers in this list augment registers specified in
+ `CALL_USED_REGISTERS' (*note Register Basics::).
+
+`code_label'
+ A `code_label' insn represents a label that a jump insn can jump
+ to. It contains two special fields of data in addition to the
+ three standard ones. `CODE_LABEL_NUMBER' is used to hold the
+ "label number", a number that identifies this label uniquely among
+ all the labels in the compilation (not just in the current
+ function). Ultimately, the label is represented in the assembler
+ output as an assembler label, usually of the form `LN' where N is
+ the label number.
+
+ When a `code_label' appears in an RTL expression, it normally
+ appears within a `label_ref' which represents the address of the
+ label, as a number.
+
+ Besides as a `code_label', a label can also be represented as a
+ `note' of type `NOTE_INSN_DELETED_LABEL'.
+
+ The field `LABEL_NUSES' is only defined once the jump optimization
+ phase is completed. It contains the number of times this label is
+ referenced in the current function.
+
+ The field `LABEL_KIND' differentiates four different types of
+ labels: `LABEL_NORMAL', `LABEL_STATIC_ENTRY',
+ `LABEL_GLOBAL_ENTRY', and `LABEL_WEAK_ENTRY'. The only labels
+ that do not have type `LABEL_NORMAL' are "alternate entry points"
+ to the current function. These may be static (visible only in the
+ containing translation unit), global (exposed to all translation
+ units), or weak (global, but can be overridden by another symbol
+ with the same name).
+
+ Much of the compiler treats all four kinds of label identically.
+ Some of it needs to know whether or not a label is an alternate
+ entry point; for this purpose, the macro `LABEL_ALT_ENTRY_P' is
+ provided. It is equivalent to testing whether `LABEL_KIND (label)
+ == LABEL_NORMAL'. The only place that cares about the distinction
+ between static, global, and weak alternate entry points, besides
+ the front-end code that creates them, is the function
+ `output_alternate_entry_point', in `final.c'.
+
+ To set the kind of a label, use the `SET_LABEL_KIND' macro.
+
+`barrier'
+ Barriers are placed in the instruction stream when control cannot
+ flow past them. They are placed after unconditional jump
+ instructions to indicate that the jumps are unconditional and
+ after calls to `volatile' functions, which do not return (e.g.,
+ `exit'). They contain no information beyond the three standard
+ fields.
+
+`note'
+ `note' insns are used to represent additional debugging and
+ declarative information. They contain two nonstandard fields, an
+ integer which is accessed with the macro `NOTE_LINE_NUMBER' and a
+ string accessed with `NOTE_SOURCE_FILE'.
+
+ If `NOTE_LINE_NUMBER' is positive, the note represents the
+ position of a source line and `NOTE_SOURCE_FILE' is the source
+ file name that the line came from. These notes control generation
+ of line number data in the assembler output.
+
+ Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a
+ code with one of the following values (and `NOTE_SOURCE_FILE' must
+ contain a null pointer):
+
+ `NOTE_INSN_DELETED'
+ Such a note is completely ignorable. Some passes of the
+ compiler delete insns by altering them into notes of this
+ kind.
+
+ `NOTE_INSN_DELETED_LABEL'
+ This marks what used to be a `code_label', but was not used
+ for other purposes than taking its address and was
+ transformed to mark that no code jumps to it.
+
+ `NOTE_INSN_BLOCK_BEG'
+ `NOTE_INSN_BLOCK_END'
+ These types of notes indicate the position of the beginning
+ and end of a level of scoping of variable names. They
+ control the output of debugging information.
+
+ `NOTE_INSN_EH_REGION_BEG'
+ `NOTE_INSN_EH_REGION_END'
+ These types of notes indicate the position of the beginning
+ and end of a level of scoping for exception handling.
+ `NOTE_BLOCK_NUMBER' identifies which `CODE_LABEL' or `note'
+ of type `NOTE_INSN_DELETED_LABEL' is associated with the
+ given region.
+
+ `NOTE_INSN_LOOP_BEG'
+ `NOTE_INSN_LOOP_END'
+ These types of notes indicate the position of the beginning
+ and end of a `while' or `for' loop. They enable the loop
+ optimizer to find loops quickly.
+
+ `NOTE_INSN_LOOP_CONT'
+ Appears at the place in a loop that `continue' statements
+ jump to.
+
+ `NOTE_INSN_LOOP_VTOP'
+ This note indicates the place in a loop where the exit test
+ begins for those loops in which the exit test has been
+ duplicated. This position becomes another virtual start of
+ the loop when considering loop invariants.
+
+ `NOTE_INSN_FUNCTION_BEG'
+ Appears at the start of the function body, after the function
+ prologue.
+
+
+ These codes are printed symbolically when they appear in debugging
+ dumps.
+
+ The machine mode of an insn is normally `VOIDmode', but some phases
+use the mode for various purposes.
+
+ The common subexpression elimination pass sets the mode of an insn to
+`QImode' when it is the first insn in a block that has already been
+processed.
+
+ The second Haifa scheduling pass, for targets that can multiple issue,
+sets the mode of an insn to `TImode' when it is believed that the
+instruction begins an issue group. That is, when the instruction
+cannot issue simultaneously with the previous. This may be relied on
+by later passes, in particular machine-dependent reorg.
+
+ Here is a table of the extra fields of `insn', `jump_insn' and
+`call_insn' insns:
+
+`PATTERN (I)'
+ An expression for the side effect performed by this insn. This
+ must be one of the following codes: `set', `call', `use',
+ `clobber', `return', `asm_input', `asm_output', `addr_vec',
+ `addr_diff_vec', `trap_if', `unspec', `unspec_volatile',
+ `parallel', `cond_exec', or `sequence'. If it is a `parallel',
+ each element of the `parallel' must be one these codes, except that
+ `parallel' expressions cannot be nested and `addr_vec' and
+ `addr_diff_vec' are not permitted inside a `parallel' expression.
+
+`INSN_CODE (I)'
+ An integer that says which pattern in the machine description
+ matches this insn, or -1 if the matching has not yet been
+ attempted.
+
+ Such matching is never attempted and this field remains -1 on an
+ insn whose pattern consists of a single `use', `clobber',
+ `asm_input', `addr_vec' or `addr_diff_vec' expression.
+
+ Matching is also never attempted on insns that result from an `asm'
+ statement. These contain at least one `asm_operands' expression.
+ The function `asm_noperands' returns a non-negative value for such
+ insns.
+
+ In the debugging output, this field is printed as a number
+ followed by a symbolic representation that locates the pattern in
+ the `md' file as some small positive or negative offset from a
+ named pattern.
+
+`LOG_LINKS (I)'
+ A list (chain of `insn_list' expressions) giving information about
+ dependencies between instructions within a basic block. Neither a
+ jump nor a label may come between the related insns. These are
+ only used by the schedulers and by combine. This is a deprecated
+ data structure. Def-use and use-def chains are now preferred.
+
+`REG_NOTES (I)'
+ A list (chain of `expr_list' and `insn_list' expressions) giving
+ miscellaneous information about the insn. It is often information
+ pertaining to the registers used in this insn.
+
+ The `LOG_LINKS' field of an insn is a chain of `insn_list'
+expressions. Each of these has two operands: the first is an insn, and
+the second is another `insn_list' expression (the next one in the
+chain). The last `insn_list' in the chain has a null pointer as second
+operand. The significant thing about the chain is which insns appear
+in it (as first operands of `insn_list' expressions). Their order is
+not significant.
+
+ This list is originally set up by the flow analysis pass; it is a null
+pointer until then. Flow only adds links for those data dependencies
+which can be used for instruction combination. For each insn, the flow
+analysis pass adds a link to insns which store into registers values
+that are used for the first time in this insn.
+
+ The `REG_NOTES' field of an insn is a chain similar to the `LOG_LINKS'
+field but it includes `expr_list' expressions in addition to
+`insn_list' expressions. There are several kinds of register notes,
+which are distinguished by the machine mode, which in a register note
+is really understood as being an `enum reg_note'. The first operand OP
+of the note is data whose meaning depends on the kind of note.
+
+ The macro `REG_NOTE_KIND (X)' returns the kind of register note. Its
+counterpart, the macro `PUT_REG_NOTE_KIND (X, NEWKIND)' sets the
+register note type of X to be NEWKIND.
+
+ Register notes are of three classes: They may say something about an
+input to an insn, they may say something about an output of an insn, or
+they may create a linkage between two insns. There are also a set of
+values that are only used in `LOG_LINKS'.
+
+ These register notes annotate inputs to an insn:
+
+`REG_DEAD'
+ The value in OP dies in this insn; that is to say, altering the
+ value immediately after this insn would not affect the future
+ behavior of the program.
+
+ It does not follow that the register OP has no useful value after
+ this insn since OP is not necessarily modified by this insn.
+ Rather, no subsequent instruction uses the contents of OP.
+
+`REG_UNUSED'
+ The register OP being set by this insn will not be used in a
+ subsequent insn. This differs from a `REG_DEAD' note, which
+ indicates that the value in an input will not be used subsequently.
+ These two notes are independent; both may be present for the same
+ register.
+
+`REG_INC'
+ The register OP is incremented (or decremented; at this level
+ there is no distinction) by an embedded side effect inside this
+ insn. This means it appears in a `post_inc', `pre_inc',
+ `post_dec' or `pre_dec' expression.
+
+`REG_NONNEG'
+ The register OP is known to have a nonnegative value when this
+ insn is reached. This is used so that decrement and branch until
+ zero instructions, such as the m68k dbra, can be matched.
+
+ The `REG_NONNEG' note is added to insns only if the machine
+ description has a `decrement_and_branch_until_zero' pattern.
+
+`REG_LABEL_OPERAND'
+ This insn uses OP, a `code_label' or a `note' of type
+ `NOTE_INSN_DELETED_LABEL', but is not a `jump_insn', or it is a
+ `jump_insn' that refers to the operand as an ordinary operand.
+ The label may still eventually be a jump target, but if so in an
+ indirect jump in a subsequent insn. The presence of this note
+ allows jump optimization to be aware that OP is, in fact, being
+ used, and flow optimization to build an accurate flow graph.
+
+`REG_LABEL_TARGET'
+ This insn is a `jump_insn' but not a `addr_vec' or
+ `addr_diff_vec'. It uses OP, a `code_label' as a direct or
+ indirect jump target. Its purpose is similar to that of
+ `REG_LABEL_OPERAND'. This note is only present if the insn has
+ multiple targets; the last label in the insn (in the highest
+ numbered insn-field) goes into the `JUMP_LABEL' field and does not
+ have a `REG_LABEL_TARGET' note. *Note JUMP_LABEL: Insns.
+
+`REG_CROSSING_JUMP'
+ This insn is an branching instruction (either an unconditional
+ jump or an indirect jump) which crosses between hot and cold
+ sections, which could potentially be very far apart in the
+ executable. The presence of this note indicates to other
+ optimizations that this branching instruction should not be
+ "collapsed" into a simpler branching construct. It is used when
+ the optimization to partition basic blocks into hot and cold
+ sections is turned on.
+
+`REG_SETJMP'
+ Appears attached to each `CALL_INSN' to `setjmp' or a related
+ function.
+
+ The following notes describe attributes of outputs of an insn:
+
+`REG_EQUIV'
+`REG_EQUAL'
+ This note is only valid on an insn that sets only one register and
+ indicates that that register will be equal to OP at run time; the
+ scope of this equivalence differs between the two types of notes.
+ The value which the insn explicitly copies into the register may
+ look different from OP, but they will be equal at run time. If the
+ output of the single `set' is a `strict_low_part' expression, the
+ note refers to the register that is contained in `SUBREG_REG' of
+ the `subreg' expression.
+
+ For `REG_EQUIV', the register is equivalent to OP throughout the
+ entire function, and could validly be replaced in all its
+ occurrences by OP. ("Validly" here refers to the data flow of the
+ program; simple replacement may make some insns invalid.) For
+ example, when a constant is loaded into a register that is never
+ assigned any other value, this kind of note is used.
+
+ When a parameter is copied into a pseudo-register at entry to a
+ function, a note of this kind records that the register is
+ equivalent to the stack slot where the parameter was passed.
+ Although in this case the register may be set by other insns, it
+ is still valid to replace the register by the stack slot
+ throughout the function.
+
+ A `REG_EQUIV' note is also used on an instruction which copies a
+ register parameter into a pseudo-register at entry to a function,
+ if there is a stack slot where that parameter could be stored.
+ Although other insns may set the pseudo-register, it is valid for
+ the compiler to replace the pseudo-register by stack slot
+ throughout the function, provided the compiler ensures that the
+ stack slot is properly initialized by making the replacement in
+ the initial copy instruction as well. This is used on machines
+ for which the calling convention allocates stack space for
+ register parameters. See `REG_PARM_STACK_SPACE' in *note Stack
+ Arguments::.
+
+ In the case of `REG_EQUAL', the register that is set by this insn
+ will be equal to OP at run time at the end of this insn but not
+ necessarily elsewhere in the function. In this case, OP is
+ typically an arithmetic expression. For example, when a sequence
+ of insns such as a library call is used to perform an arithmetic
+ operation, this kind of note is attached to the insn that produces
+ or copies the final value.
+
+ These two notes are used in different ways by the compiler passes.
+ `REG_EQUAL' is used by passes prior to register allocation (such as
+ common subexpression elimination and loop optimization) to tell
+ them how to think of that value. `REG_EQUIV' notes are used by
+ register allocation to indicate that there is an available
+ substitute expression (either a constant or a `mem' expression for
+ the location of a parameter on the stack) that may be used in
+ place of a register if insufficient registers are available.
+
+ Except for stack homes for parameters, which are indicated by a
+ `REG_EQUIV' note and are not useful to the early optimization
+ passes and pseudo registers that are equivalent to a memory
+ location throughout their entire life, which is not detected until
+ later in the compilation, all equivalences are initially indicated
+ by an attached `REG_EQUAL' note. In the early stages of register
+ allocation, a `REG_EQUAL' note is changed into a `REG_EQUIV' note
+ if OP is a constant and the insn represents the only set of its
+ destination register.
+
+ Thus, compiler passes prior to register allocation need only check
+ for `REG_EQUAL' notes and passes subsequent to register allocation
+ need only check for `REG_EQUIV' notes.
+
+ These notes describe linkages between insns. They occur in pairs: one
+insn has one of a pair of notes that points to a second insn, which has
+the inverse note pointing back to the first insn.
+
+`REG_CC_SETTER'
+`REG_CC_USER'
+ On machines that use `cc0', the insns which set and use `cc0' set
+ and use `cc0' are adjacent. However, when branch delay slot
+ filling is done, this may no longer be true. In this case a
+ `REG_CC_USER' note will be placed on the insn setting `cc0' to
+ point to the insn using `cc0' and a `REG_CC_SETTER' note will be
+ placed on the insn using `cc0' to point to the insn setting `cc0'.
+
+ These values are only used in the `LOG_LINKS' field, and indicate the
+type of dependency that each link represents. Links which indicate a
+data dependence (a read after write dependence) do not use any code,
+they simply have mode `VOIDmode', and are printed without any
+descriptive text.
+
+`REG_DEP_TRUE'
+ This indicates a true dependence (a read after write dependence).
+
+`REG_DEP_OUTPUT'
+ This indicates an output dependence (a write after write
+ dependence).
+
+`REG_DEP_ANTI'
+ This indicates an anti dependence (a write after read dependence).
+
+
+ These notes describe information gathered from gcov profile data. They
+are stored in the `REG_NOTES' field of an insn as an `expr_list'.
+
+`REG_BR_PROB'
+ This is used to specify the ratio of branches to non-branches of a
+ branch insn according to the profile data. The value is stored as
+ a value between 0 and REG_BR_PROB_BASE; larger values indicate a
+ higher probability that the branch will be taken.
+
+`REG_BR_PRED'
+ These notes are found in JUMP insns after delayed branch scheduling
+ has taken place. They indicate both the direction and the
+ likelihood of the JUMP. The format is a bitmask of ATTR_FLAG_*
+ values.
+
+`REG_FRAME_RELATED_EXPR'
+ This is used on an RTX_FRAME_RELATED_P insn wherein the attached
+ expression is used in place of the actual insn pattern. This is
+ done in cases where the pattern is either complex or misleading.
+
+ For convenience, the machine mode in an `insn_list' or `expr_list' is
+printed using these symbolic codes in debugging dumps.
+
+ The only difference between the expression codes `insn_list' and
+`expr_list' is that the first operand of an `insn_list' is assumed to
+be an insn and is printed in debugging dumps as the insn's unique id;
+the first operand of an `expr_list' is printed in the ordinary way as
+an expression.
+
+\1f
+File: gccint.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL
+
+10.19 RTL Representation of Function-Call Insns
+===============================================
+
+Insns that call subroutines have the RTL expression code `call_insn'.
+These insns must satisfy special rules, and their bodies must use a
+special RTL expression code, `call'.
+
+ A `call' expression has two operands, as follows:
+
+ (call (mem:FM ADDR) NBYTES)
+
+Here NBYTES is an operand that represents the number of bytes of
+argument data being passed to the subroutine, FM is a machine mode
+(which must equal as the definition of the `FUNCTION_MODE' macro in the
+machine description) and ADDR represents the address of the subroutine.
+
+ For a subroutine that returns no value, the `call' expression as shown
+above is the entire body of the insn, except that the insn might also
+contain `use' or `clobber' expressions.
+
+ For a subroutine that returns a value whose mode is not `BLKmode', the
+value is returned in a hard register. If this register's number is R,
+then the body of the call insn looks like this:
+
+ (set (reg:M R)
+ (call (mem:FM ADDR) NBYTES))
+
+This RTL expression makes it clear (to the optimizer passes) that the
+appropriate register receives a useful value in this insn.
+
+ When a subroutine returns a `BLKmode' value, it is handled by passing
+to the subroutine the address of a place to store the value. So the
+call insn itself does not "return" any value, and it has the same RTL
+form as a call that returns nothing.
+
+ On some machines, the call instruction itself clobbers some register,
+for example to contain the return address. `call_insn' insns on these
+machines should have a body which is a `parallel' that contains both
+the `call' expression and `clobber' expressions that indicate which
+registers are destroyed. Similarly, if the call instruction requires
+some register other than the stack pointer that is not explicitly
+mentioned in its RTL, a `use' subexpression should mention that
+register.
+
+ Functions that are called are assumed to modify all registers listed in
+the configuration macro `CALL_USED_REGISTERS' (*note Register Basics::)
+and, with the exception of `const' functions and library calls, to
+modify all of memory.
+
+ Insns containing just `use' expressions directly precede the
+`call_insn' insn to indicate which registers contain inputs to the
+function. Similarly, if registers other than those in
+`CALL_USED_REGISTERS' are clobbered by the called function, insns
+containing a single `clobber' follow immediately after the call to
+indicate which registers.
+
+\1f
+File: gccint.info, Node: Sharing, Next: Reading RTL, Prev: Calls, Up: RTL
+
+10.20 Structure Sharing Assumptions
+===================================
+
+The compiler assumes that certain kinds of RTL expressions are unique;
+there do not exist two distinct objects representing the same value.
+In other cases, it makes an opposite assumption: that no RTL expression
+object of a certain kind appears in more than one place in the
+containing structure.
+
+ These assumptions refer to a single function; except for the RTL
+objects that describe global variables and external functions, and a
+few standard objects such as small integer constants, no RTL objects
+are common to two functions.
+
+ * Each pseudo-register has only a single `reg' object to represent
+ it, and therefore only a single machine mode.
+
+ * For any symbolic label, there is only one `symbol_ref' object
+ referring to it.
+
+ * All `const_int' expressions with equal values are shared.
+
+ * There is only one `pc' expression.
+
+ * There is only one `cc0' expression.
+
+ * There is only one `const_double' expression with value 0 for each
+ floating point mode. Likewise for values 1 and 2.
+
+ * There is only one `const_vector' expression with value 0 for each
+ vector mode, be it an integer or a double constant vector.
+
+ * No `label_ref' or `scratch' appears in more than one place in the
+ RTL structure; in other words, it is safe to do a tree-walk of all
+ the insns in the function and assume that each time a `label_ref'
+ or `scratch' is seen it is distinct from all others that are seen.
+
+ * Only one `mem' object is normally created for each static variable
+ or stack slot, so these objects are frequently shared in all the
+ places they appear. However, separate but equal objects for these
+ variables are occasionally made.
+
+ * When a single `asm' statement has multiple output operands, a
+ distinct `asm_operands' expression is made for each output operand.
+ However, these all share the vector which contains the sequence of
+ input operands. This sharing is used later on to test whether two
+ `asm_operands' expressions come from the same statement, so all
+ optimizations must carefully preserve the sharing if they copy the
+ vector at all.
+
+ * No RTL object appears in more than one place in the RTL structure
+ except as described above. Many passes of the compiler rely on
+ this by assuming that they can modify RTL objects in place without
+ unwanted side-effects on other insns.
+
+ * During initial RTL generation, shared structure is freely
+ introduced. After all the RTL for a function has been generated,
+ all shared structure is copied by `unshare_all_rtl' in
+ `emit-rtl.c', after which the above rules are guaranteed to be
+ followed.
+
+ * During the combiner pass, shared structure within an insn can exist
+ temporarily. However, the shared structure is copied before the
+ combiner is finished with the insn. This is done by calling
+ `copy_rtx_if_shared', which is a subroutine of `unshare_all_rtl'.
+
+\1f
+File: gccint.info, Node: Reading RTL, Prev: Sharing, Up: RTL
+
+10.21 Reading RTL
+=================
+
+To read an RTL object from a file, call `read_rtx'. It takes one
+argument, a stdio stream, and returns a single RTL object. This routine
+is defined in `read-rtl.c'. It is not available in the compiler
+itself, only the various programs that generate the compiler back end
+from the machine description.
+
+ People frequently have the idea of using RTL stored as text in a file
+as an interface between a language front end and the bulk of GCC. This
+idea is not feasible.
+
+ GCC was designed to use RTL internally only. Correct RTL for a given
+program is very dependent on the particular target machine. And the RTL
+does not contain all the information about the program.
+
+ The proper way to interface GCC to a new language front end is with
+the "tree" data structure, described in the files `tree.h' and
+`tree.def'. The documentation for this structure (*note Trees::) is
+incomplete.
+
+\1f
+File: gccint.info, Node: GENERIC, Next: GIMPLE, Prev: Trees, Up: Top
+
+11 GENERIC
+**********
+
+The purpose of GENERIC is simply to provide a language-independent way
+of representing an entire function in trees. To this end, it was
+necessary to add a few new tree codes to the back end, but most
+everything was already there. If you can express it with the codes in
+`gcc/tree.def', it's GENERIC.
+
+ Early on, there was a great deal of debate about how to think about
+statements in a tree IL. In GENERIC, a statement is defined as any
+expression whose value, if any, is ignored. A statement will always
+have `TREE_SIDE_EFFECTS' set (or it will be discarded), but a
+non-statement expression may also have side effects. A `CALL_EXPR',
+for instance.
+
+ It would be possible for some local optimizations to work on the
+GENERIC form of a function; indeed, the adapted tree inliner works fine
+on GENERIC, but the current compiler performs inlining after lowering
+to GIMPLE (a restricted form described in the next section). Indeed,
+currently the frontends perform this lowering before handing off to
+`tree_rest_of_compilation', but this seems inelegant.
+
+ If necessary, a front end can use some language-dependent tree codes
+in its GENERIC representation, so long as it provides a hook for
+converting them to GIMPLE and doesn't expect them to work with any
+(hypothetical) optimizers that run before the conversion to GIMPLE. The
+intermediate representation used while parsing C and C++ looks very
+little like GENERIC, but the C and C++ gimplifier hooks are perfectly
+happy to take it as input and spit out GIMPLE.
+
+* Menu:
+
+* Statements::
+
+\1f
+File: gccint.info, Node: Statements, Up: GENERIC
+
+11.1 Statements
+===============
+
+Most statements in GIMPLE are assignment statements, represented by
+`GIMPLE_ASSIGN'. No other C expressions can appear at statement level;
+a reference to a volatile object is converted into a `GIMPLE_ASSIGN'.
+
+ There are also several varieties of complex statements.
+
+* Menu:
+
+* Blocks::
+* Statement Sequences::
+* Empty Statements::
+* Jumps::
+* Cleanups::
+
+\1f
+File: gccint.info, Node: Blocks, Next: Statement Sequences, Up: Statements
+
+11.1.1 Blocks
+-------------
+
+Block scopes and the variables they declare in GENERIC are expressed
+using the `BIND_EXPR' code, which in previous versions of GCC was
+primarily used for the C statement-expression extension.
+
+ Variables in a block are collected into `BIND_EXPR_VARS' in
+declaration order. Any runtime initialization is moved out of
+`DECL_INITIAL' and into a statement in the controlled block. When
+gimplifying from C or C++, this initialization replaces the `DECL_STMT'.
+
+ Variable-length arrays (VLAs) complicate this process, as their size
+often refers to variables initialized earlier in the block. To handle
+this, we currently split the block at that point, and move the VLA into
+a new, inner `BIND_EXPR'. This strategy may change in the future.
+
+ A C++ program will usually contain more `BIND_EXPR's than there are
+syntactic blocks in the source code, since several C++ constructs have
+implicit scopes associated with them. On the other hand, although the
+C++ front end uses pseudo-scopes to handle cleanups for objects with
+destructors, these don't translate into the GIMPLE form; multiple
+declarations at the same level use the same `BIND_EXPR'.
+
+\1f
+File: gccint.info, Node: Statement Sequences, Next: Empty Statements, Prev: Blocks, Up: Statements
+
+11.1.2 Statement Sequences
+--------------------------
+
+Multiple statements at the same nesting level are collected into a
+`STATEMENT_LIST'. Statement lists are modified and traversed using the
+interface in `tree-iterator.h'.
+
+\1f
+File: gccint.info, Node: Empty Statements, Next: Jumps, Prev: Statement Sequences, Up: Statements
+
+11.1.3 Empty Statements
+-----------------------
+
+Whenever possible, statements with no effect are discarded. But if
+they are nested within another construct which cannot be discarded for
+some reason, they are instead replaced with an empty statement,
+generated by `build_empty_stmt'. Initially, all empty statements were
+shared, after the pattern of the Java front end, but this caused a lot
+of trouble in practice.
+
+ An empty statement is represented as `(void)0'.
+
+\1f
+File: gccint.info, Node: Jumps, Next: Cleanups, Prev: Empty Statements, Up: Statements
+
+11.1.4 Jumps
+------------
+
+Other jumps are expressed by either `GOTO_EXPR' or `RETURN_EXPR'.
+
+ The operand of a `GOTO_EXPR' must be either a label or a variable
+containing the address to jump to.
+
+ The operand of a `RETURN_EXPR' is either `NULL_TREE', `RESULT_DECL',
+or a `MODIFY_EXPR' which sets the return value. It would be nice to
+move the `MODIFY_EXPR' into a separate statement, but the special
+return semantics in `expand_return' make that difficult. It may still
+happen in the future, perhaps by moving most of that logic into
+`expand_assignment'.
+
+\1f
+File: gccint.info, Node: Cleanups, Prev: Jumps, Up: Statements
+
+11.1.5 Cleanups
+---------------
+
+Destructors for local C++ objects and similar dynamic cleanups are
+represented in GIMPLE by a `TRY_FINALLY_EXPR'. `TRY_FINALLY_EXPR' has
+two operands, both of which are a sequence of statements to execute.
+The first sequence is executed. When it completes the second sequence
+is executed.
+
+ The first sequence may complete in the following ways:
+
+ 1. Execute the last statement in the sequence and fall off the end.
+
+ 2. Execute a goto statement (`GOTO_EXPR') to an ordinary label
+ outside the sequence.
+
+ 3. Execute a return statement (`RETURN_EXPR').
+
+ 4. Throw an exception. This is currently not explicitly represented
+ in GIMPLE.
+
+
+ The second sequence is not executed if the first sequence completes by
+calling `setjmp' or `exit' or any other function that does not return.
+The second sequence is also not executed if the first sequence
+completes via a non-local goto or a computed goto (in general the
+compiler does not know whether such a goto statement exits the first
+sequence or not, so we assume that it doesn't).
+
+ After the second sequence is executed, if it completes normally by
+falling off the end, execution continues wherever the first sequence
+would have continued, by falling off the end, or doing a goto, etc.
+
+ `TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs
+to appear on every edge out of the controlled block; this reduces the
+freedom to move code across these edges. Therefore, the EH lowering
+pass which runs before most of the optimization passes eliminates these
+expressions by explicitly adding the cleanup to each edge. Rethrowing
+the exception is represented using `RESX_EXPR'.
+
+\1f
+File: gccint.info, Node: GIMPLE, Next: Tree SSA, Prev: GENERIC, Up: Top
+
+12 GIMPLE
+*********
+
+GIMPLE is a three-address representation derived from GENERIC by
+breaking down GENERIC expressions into tuples of no more than 3
+operands (with some exceptions like function calls). GIMPLE was
+heavily influenced by the SIMPLE IL used by the McCAT compiler project
+at McGill University, though we have made some different choices. For
+one thing, SIMPLE doesn't support `goto'.
+
+ Temporaries are introduced to hold intermediate values needed to
+compute complex expressions. Additionally, all the control structures
+used in GENERIC are lowered into conditional jumps, lexical scopes are
+removed and exception regions are converted into an on the side
+exception region tree.
+
+ The compiler pass which converts GENERIC into GIMPLE is referred to as
+the `gimplifier'. The gimplifier works recursively, generating GIMPLE
+tuples out of the original GENERIC expressions.
+
+ One of the early implementation strategies used for the GIMPLE
+representation was to use the same internal data structures used by
+front ends to represent parse trees. This simplified implementation
+because we could leverage existing functionality and interfaces.
+However, GIMPLE is a much more restrictive representation than abstract
+syntax trees (AST), therefore it does not require the full structural
+complexity provided by the main tree data structure.
+
+ The GENERIC representation of a function is stored in the
+`DECL_SAVED_TREE' field of the associated `FUNCTION_DECL' tree node.
+It is converted to GIMPLE by a call to `gimplify_function_tree'.
+
+ If a front end wants to include language-specific tree codes in the
+tree representation which it provides to the back end, it must provide a
+definition of `LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the
+front end trees to GIMPLE. Usually such a hook will involve much of
+the same code for expanding front end trees to RTL. This function can
+return fully lowered GIMPLE, or it can return GENERIC trees and let the
+main gimplifier lower them the rest of the way; this is often simpler.
+GIMPLE that is not fully lowered is known as "High GIMPLE" and consists
+of the IL before the pass `pass_lower_cf'. High GIMPLE contains some
+container statements like lexical scopes (represented by `GIMPLE_BIND')
+and nested expressions (e.g., `GIMPLE_TRY'), while "Low GIMPLE" exposes
+all of the implicit jumps for control and exception expressions
+directly in the IL and EH region trees.
+
+ The C and C++ front ends currently convert directly from front end
+trees to GIMPLE, and hand that off to the back end rather than first
+converting to GENERIC. Their gimplifier hooks know about all the
+`_STMT' nodes and how to convert them to GENERIC forms. There was some
+work done on a genericization pass which would run first, but the
+existence of `STMT_EXPR' meant that in order to convert all of the C
+statements into GENERIC equivalents would involve walking the entire
+tree anyway, so it was simpler to lower all the way. This might change
+in the future if someone writes an optimization pass which would work
+better with higher-level trees, but currently the optimizers all expect
+GIMPLE.
+
+ You can request to dump a C-like representation of the GIMPLE form
+with the flag `-fdump-tree-gimple'.
+
+* Menu:
+
+* Tuple representation::
+* GIMPLE instruction set::
+* GIMPLE Exception Handling::
+* Temporaries::
+* Operands::
+* Manipulating GIMPLE statements::
+* Tuple specific accessors::
+* GIMPLE sequences::
+* Sequence iterators::
+* Adding a new GIMPLE statement code::
+* Statement and operand traversals::
+
+\1f
+File: gccint.info, Node: Tuple representation, Next: GIMPLE instruction set, Up: GIMPLE
+
+12.1 Tuple representation
+=========================
+
+GIMPLE instructions are tuples of variable size divided in two groups:
+a header describing the instruction and its locations, and a variable
+length body with all the operands. Tuples are organized into a
+hierarchy with 3 main classes of tuples.
+
+12.1.1 `gimple_statement_base' (gsbase)
+---------------------------------------
+
+This is the root of the hierarchy, it holds basic information needed by
+most GIMPLE statements. There are some fields that may not be relevant
+to every GIMPLE statement, but those were moved into the base structure
+to take advantage of holes left by other fields (thus making the
+structure more compact). The structure takes 4 words (32 bytes) on 64
+bit hosts:
+
+Field Size (bits)
+`code' 8
+`subcode' 16
+`no_warning' 1
+`visited' 1
+`nontemporal_move' 1
+`plf' 2
+`modified' 1
+`has_volatile_ops' 1
+`references_memory_p' 1
+`uid' 32
+`location' 32
+`num_ops' 32
+`bb' 64
+`block' 63
+Total size 32 bytes
+
+ * `code' Main identifier for a GIMPLE instruction.
+
+ * `subcode' Used to distinguish different variants of the same basic
+ instruction or provide flags applicable to a given code. The
+ `subcode' flags field has different uses depending on the code of
+ the instruction, but mostly it distinguishes instructions of the
+ same family. The most prominent use of this field is in
+ assignments, where subcode indicates the operation done on the RHS
+ of the assignment. For example, a = b + c is encoded as
+ `GIMPLE_ASSIGN <PLUS_EXPR, a, b, c>'.
+
+ * `no_warning' Bitflag to indicate whether a warning has already
+ been issued on this statement.
+
+ * `visited' General purpose "visited" marker. Set and cleared by
+ each pass when needed.
+
+ * `nontemporal_move' Bitflag used in assignments that represent
+ non-temporal moves. Although this bitflag is only used in
+ assignments, it was moved into the base to take advantage of the
+ bit holes left by the previous fields.
+
+ * `plf' Pass Local Flags. This 2-bit mask can be used as general
+ purpose markers by any pass. Passes are responsible for clearing
+ and setting these two flags accordingly.
+
+ * `modified' Bitflag to indicate whether the statement has been
+ modified. Used mainly by the operand scanner to determine when to
+ re-scan a statement for operands.
+
+ * `has_volatile_ops' Bitflag to indicate whether this statement
+ contains operands that have been marked volatile.
+
+ * `references_memory_p' Bitflag to indicate whether this statement
+ contains memory references (i.e., its operands are either global
+ variables, or pointer dereferences or anything that must reside in
+ memory).
+
+ * `uid' This is an unsigned integer used by passes that want to
+ assign IDs to every statement. These IDs must be assigned and used
+ by each pass.
+
+ * `location' This is a `location_t' identifier to specify source code
+ location for this statement. It is inherited from the front end.
+
+ * `num_ops' Number of operands that this statement has. This
+ specifies the size of the operand vector embedded in the tuple.
+ Only used in some tuples, but it is declared in the base tuple to
+ take advantage of the 32-bit hole left by the previous fields.
+
+ * `bb' Basic block holding the instruction.
+
+ * `block' Lexical block holding this statement. Also used for debug
+ information generation.
+
+12.1.2 `gimple_statement_with_ops'
+----------------------------------
+
+This tuple is actually split in two: `gimple_statement_with_ops_base'
+and `gimple_statement_with_ops'. This is needed to accommodate the way
+the operand vector is allocated. The operand vector is defined to be an
+array of 1 element. So, to allocate a dynamic number of operands, the
+memory allocator (`gimple_alloc') simply allocates enough memory to
+hold the structure itself plus `N - 1' operands which run "off the end"
+of the structure. For example, to allocate space for a tuple with 3
+operands, `gimple_alloc' reserves `sizeof (struct
+gimple_statement_with_ops) + 2 * sizeof (tree)' bytes.
+
+ On the other hand, several fields in this tuple need to be shared with
+the `gimple_statement_with_memory_ops' tuple. So, these common fields
+are placed in `gimple_statement_with_ops_base' which is then inherited
+from the other two tuples.
+
+`gsbase' 256
+`addresses_taken' 64
+`def_ops' 64
+`use_ops' 64
+`op' `num_ops' * 64
+Total size 56 + 8 * `num_ops' bytes
+
+ * `gsbase' Inherited from `struct gimple_statement_base'.
+
+ * `addresses_taken' Bitmap holding the UIDs of all the `VAR_DECL's
+ whose addresses are taken by this statement. For example, a
+ statement of the form `p = &b' will have the UID for symbol `b' in
+ this set.
+
+ * `def_ops' Array of pointers into the operand array indicating all
+ the slots that contain a variable written-to by the statement.
+ This array is also used for immediate use chaining. Note that it
+ would be possible to not rely on this array, but the changes
+ required to implement this are pretty invasive.
+
+ * `use_ops' Similar to `def_ops' but for variables read by the
+ statement.
+
+ * `op' Array of trees with `num_ops' slots.
+
+12.1.3 `gimple_statement_with_memory_ops'
+-----------------------------------------
+
+This tuple is essentially identical to `gimple_statement_with_ops',
+except that it contains 4 additional fields to hold vectors related
+memory stores and loads. Similar to the previous case, the structure
+is split in two to accommodate for the operand vector
+(`gimple_statement_with_memory_ops_base' and
+`gimple_statement_with_memory_ops').
+
+Field Size (bits)
+`gsbase' 256
+`addresses_taken' 64
+`def_ops' 64
+`use_ops' 64
+`vdef_ops' 64
+`vuse_ops' 64
+`stores' 64
+`loads' 64
+`op' `num_ops' * 64
+Total size 88 + 8 * `num_ops' bytes
+
+ * `vdef_ops' Similar to `def_ops' but for `VDEF' operators. There is
+ one entry per memory symbol written by this statement. This is
+ used to maintain the memory SSA use-def and def-def chains.
+
+ * `vuse_ops' Similar to `use_ops' but for `VUSE' operators. There is
+ one entry per memory symbol loaded by this statement. This is used
+ to maintain the memory SSA use-def chains.
+
+ * `stores' Bitset with all the UIDs for the symbols written-to by the
+ statement. This is different than `vdef_ops' in that all the
+ affected symbols are mentioned in this set. If memory
+ partitioning is enabled, the `vdef_ops' vector will refer to memory
+ partitions. Furthermore, no SSA information is stored in this set.
+
+ * `loads' Similar to `stores', but for memory loads. (Note that there
+ is some amount of redundancy here, it should be possible to reduce
+ memory utilization further by removing these sets).
+
+ All the other tuples are defined in terms of these three basic ones.
+Each tuple will add some fields. The main gimple type is defined to be
+the union of all these structures (`GTY' markers elided for clarity):
+
+ union gimple_statement_d
+ {
+ struct gimple_statement_base gsbase;
+ struct gimple_statement_with_ops gsops;
+ struct gimple_statement_with_memory_ops gsmem;
+ struct gimple_statement_omp omp;
+ struct gimple_statement_bind gimple_bind;
+ struct gimple_statement_catch gimple_catch;
+ struct gimple_statement_eh_filter gimple_eh_filter;
+ struct gimple_statement_phi gimple_phi;
+ struct gimple_statement_resx gimple_resx;
+ struct gimple_statement_try gimple_try;
+ struct gimple_statement_wce gimple_wce;
+ struct gimple_statement_asm gimple_asm;
+ struct gimple_statement_omp_critical gimple_omp_critical;
+ struct gimple_statement_omp_for gimple_omp_for;
+ struct gimple_statement_omp_parallel gimple_omp_parallel;
+ struct gimple_statement_omp_task gimple_omp_task;
+ struct gimple_statement_omp_sections gimple_omp_sections;
+ struct gimple_statement_omp_single gimple_omp_single;
+ struct gimple_statement_omp_continue gimple_omp_continue;
+ struct gimple_statement_omp_atomic_load gimple_omp_atomic_load;
+ struct gimple_statement_omp_atomic_store gimple_omp_atomic_store;
+ };
+
+\1f
+File: gccint.info, Node: GIMPLE instruction set, Next: GIMPLE Exception Handling, Prev: Tuple representation, Up: GIMPLE
+
+12.2 GIMPLE instruction set
+===========================
+
+The following table briefly describes the GIMPLE instruction set.
+
+Instruction High GIMPLE Low GIMPLE
+`GIMPLE_ASM' x x
+`GIMPLE_ASSIGN' x x
+`GIMPLE_BIND' x
+`GIMPLE_CALL' x x
+`GIMPLE_CATCH' x
+`GIMPLE_CHANGE_DYNAMIC_TYPE' x x
+`GIMPLE_COND' x x
+`GIMPLE_EH_FILTER' x
+`GIMPLE_GOTO' x x
+`GIMPLE_LABEL' x x
+`GIMPLE_NOP' x x
+`GIMPLE_OMP_ATOMIC_LOAD' x x
+`GIMPLE_OMP_ATOMIC_STORE' x x
+`GIMPLE_OMP_CONTINUE' x x
+`GIMPLE_OMP_CRITICAL' x x
+`GIMPLE_OMP_FOR' x x
+`GIMPLE_OMP_MASTER' x x
+`GIMPLE_OMP_ORDERED' x x
+`GIMPLE_OMP_PARALLEL' x x
+`GIMPLE_OMP_RETURN' x x
+`GIMPLE_OMP_SECTION' x x
+`GIMPLE_OMP_SECTIONS' x x
+`GIMPLE_OMP_SECTIONS_SWITCH' x x
+`GIMPLE_OMP_SINGLE' x x
+`GIMPLE_PHI' x
+`GIMPLE_RESX' x
+`GIMPLE_RETURN' x x
+`GIMPLE_SWITCH' x x
+`GIMPLE_TRY' x
+
+\1f
+File: gccint.info, Node: GIMPLE Exception Handling, Next: Temporaries, Prev: GIMPLE instruction set, Up: GIMPLE
+
+12.3 Exception Handling
+=======================
+
+Other exception handling constructs are represented using
+`GIMPLE_TRY_CATCH'. `GIMPLE_TRY_CATCH' has two operands. The first
+operand is a sequence of statements to execute. If executing these
+statements does not throw an exception, then the second operand is
+ignored. Otherwise, if an exception is thrown, then the second operand
+of the `GIMPLE_TRY_CATCH' is checked. The second operand may have the
+following forms:
+
+ 1. A sequence of statements to execute. When an exception occurs,
+ these statements are executed, and then the exception is rethrown.
+
+ 2. A sequence of `GIMPLE_CATCH' statements. Each `GIMPLE_CATCH' has
+ a list of applicable exception types and handler code. If the
+ thrown exception matches one of the caught types, the associated
+ handler code is executed. If the handler code falls off the
+ bottom, execution continues after the original `GIMPLE_TRY_CATCH'.
+
+ 3. An `GIMPLE_EH_FILTER' statement. This has a list of permitted
+ exception types, and code to handle a match failure. If the
+ thrown exception does not match one of the allowed types, the
+ associated match failure code is executed. If the thrown exception
+ does match, it continues unwinding the stack looking for the next
+ handler.
+
+
+ Currently throwing an exception is not directly represented in GIMPLE,
+since it is implemented by calling a function. At some point in the
+future we will want to add some way to express that the call will throw
+an exception of a known type.
+
+ Just before running the optimizers, the compiler lowers the high-level
+EH constructs above into a set of `goto's, magic labels, and EH
+regions. Continuing to unwind at the end of a cleanup is represented
+with a `GIMPLE_RESX'.
+
+\1f
+File: gccint.info, Node: Temporaries, Next: Operands, Prev: GIMPLE Exception Handling, Up: GIMPLE
+
+12.4 Temporaries
+================
+
+When gimplification encounters a subexpression that is too complex, it
+creates a new temporary variable to hold the value of the
+subexpression, and adds a new statement to initialize it before the
+current statement. These special temporaries are known as `expression
+temporaries', and are allocated using `get_formal_tmp_var'. The
+compiler tries to always evaluate identical expressions into the same
+temporary, to simplify elimination of redundant calculations.
+
+ We can only use expression temporaries when we know that it will not
+be reevaluated before its value is used, and that it will not be
+otherwise modified(1). Other temporaries can be allocated using
+`get_initialized_tmp_var' or `create_tmp_var'.
+
+ Currently, an expression like `a = b + 5' is not reduced any further.
+We tried converting it to something like
+ T1 = b + 5;
+ a = T1;
+ but this bloated the representation for minimal benefit. However, a
+variable which must live in memory cannot appear in an expression; its
+value is explicitly loaded into a temporary first. Similarly, storing
+the value of an expression to a memory variable goes through a
+temporary.
+
+ ---------- Footnotes ----------
+
+ (1) These restrictions are derived from those in Morgan 4.8.
+
+\1f
+File: gccint.info, Node: Operands, Next: Manipulating GIMPLE statements, Prev: Temporaries, Up: GIMPLE
+
+12.5 Operands
+=============
+
+In general, expressions in GIMPLE consist of an operation and the
+appropriate number of simple operands; these operands must either be a
+GIMPLE rvalue (`is_gimple_val'), i.e. a constant or a register
+variable. More complex operands are factored out into temporaries, so
+that
+ a = b + c + d
+ becomes
+ T1 = b + c;
+ a = T1 + d;
+
+ The same rule holds for arguments to a `GIMPLE_CALL'.
+
+ The target of an assignment is usually a variable, but can also be an
+`INDIRECT_REF' or a compound lvalue as described below.
+
+* Menu:
+
+* Compound Expressions::
+* Compound Lvalues::
+* Conditional Expressions::
+* Logical Operators::
+
+\1f
+File: gccint.info, Node: Compound Expressions, Next: Compound Lvalues, Up: Operands
+
+12.5.1 Compound Expressions
+---------------------------
+
+The left-hand side of a C comma expression is simply moved into a
+separate statement.
+
+\1f
+File: gccint.info, Node: Compound Lvalues, Next: Conditional Expressions, Prev: Compound Expressions, Up: Operands
+
+12.5.2 Compound Lvalues
+-----------------------
+
+Currently compound lvalues involving array and structure field
+references are not broken down; an expression like `a.b[2] = 42' is not
+reduced any further (though complex array subscripts are). This
+restriction is a workaround for limitations in later optimizers; if we
+were to convert this to
+
+ T1 = &a.b;
+ T1[2] = 42;
+
+ alias analysis would not remember that the reference to `T1[2]' came
+by way of `a.b', so it would think that the assignment could alias
+another member of `a'; this broke `struct-alias-1.c'. Future optimizer
+improvements may make this limitation unnecessary.
+
+\1f
+File: gccint.info, Node: Conditional Expressions, Next: Logical Operators, Prev: Compound Lvalues, Up: Operands
+
+12.5.3 Conditional Expressions
+------------------------------
+
+A C `?:' expression is converted into an `if' statement with each
+branch assigning to the same temporary. So,
+
+ a = b ? c : d;
+ becomes
+ if (b == 1)
+ T1 = c;
+ else
+ T1 = d;
+ a = T1;
+
+ The GIMPLE level if-conversion pass re-introduces `?:' expression, if
+appropriate. It is used to vectorize loops with conditions using vector
+conditional operations.
+
+ Note that in GIMPLE, `if' statements are represented using
+`GIMPLE_COND', as described below.
+
+\1f
+File: gccint.info, Node: Logical Operators, Prev: Conditional Expressions, Up: Operands
+
+12.5.4 Logical Operators
+------------------------
+
+Except when they appear in the condition operand of a `GIMPLE_COND',
+logical `and' and `or' operators are simplified as follows: `a = b &&
+c' becomes
+
+ T1 = (bool)b;
+ if (T1 == true)
+ T1 = (bool)c;
+ a = T1;
+
+ Note that `T1' in this example cannot be an expression temporary,
+because it has two different assignments.
+
+12.5.5 Manipulating operands
+----------------------------
+
+All gimple operands are of type `tree'. But only certain types of
+trees are allowed to be used as operand tuples. Basic validation is
+controlled by the function `get_gimple_rhs_class', which given a tree
+code, returns an `enum' with the following values of type `enum
+gimple_rhs_class'
+
+ * `GIMPLE_INVALID_RHS' The tree cannot be used as a GIMPLE operand.
+
+ * `GIMPLE_BINARY_RHS' The tree is a valid GIMPLE binary operation.
+
+ * `GIMPLE_UNARY_RHS' The tree is a valid GIMPLE unary operation.
+
+ * `GIMPLE_SINGLE_RHS' The tree is a single object, that cannot be
+ split into simpler operands (for instance, `SSA_NAME', `VAR_DECL',
+ `COMPONENT_REF', etc).
+
+ This operand class also acts as an escape hatch for tree nodes
+ that may be flattened out into the operand vector, but would need
+ more than two slots on the RHS. For instance, a `COND_EXPR'
+ expression of the form `(a op b) ? x : y' could be flattened out
+ on the operand vector using 4 slots, but it would also require
+ additional processing to distinguish `c = a op b' from `c = a op b
+ ? x : y'. Something similar occurs with `ASSERT_EXPR'. In time,
+ these special case tree expressions should be flattened into the
+ operand vector.
+
+ For tree nodes in the categories `GIMPLE_BINARY_RHS' and
+`GIMPLE_UNARY_RHS', they cannot be stored inside tuples directly. They
+first need to be flattened and separated into individual components.
+For instance, given the GENERIC expression
+
+ a = b + c
+
+ its tree representation is:
+
+ MODIFY_EXPR <VAR_DECL <a>, PLUS_EXPR <VAR_DECL <b>, VAR_DECL <c>>>
+
+ In this case, the GIMPLE form for this statement is logically
+identical to its GENERIC form but in GIMPLE, the `PLUS_EXPR' on the RHS
+of the assignment is not represented as a tree, instead the two
+operands are taken out of the `PLUS_EXPR' sub-tree and flattened into
+the GIMPLE tuple as follows:
+
+ GIMPLE_ASSIGN <PLUS_EXPR, VAR_DECL <a>, VAR_DECL <b>, VAR_DECL <c>>
+
+12.5.6 Operand vector allocation
+--------------------------------
+
+The operand vector is stored at the bottom of the three tuple
+structures that accept operands. This means, that depending on the code
+of a given statement, its operand vector will be at different offsets
+from the base of the structure. To access tuple operands use the
+following accessors
+
+ -- GIMPLE function: unsigned gimple_num_ops (gimple g)
+ Returns the number of operands in statement G.
+
+ -- GIMPLE function: tree gimple_op (gimple g, unsigned i)
+ Returns operand `I' from statement `G'.
+
+ -- GIMPLE function: tree *gimple_ops (gimple g)
+ Returns a pointer into the operand vector for statement `G'. This
+ is computed using an internal table called `gimple_ops_offset_'[].
+ This table is indexed by the gimple code of `G'.
+
+ When the compiler is built, this table is filled-in using the
+ sizes of the structures used by each statement code defined in
+ gimple.def. Since the operand vector is at the bottom of the
+ structure, for a gimple code `C' the offset is computed as sizeof
+ (struct-of `C') - sizeof (tree).
+
+ This mechanism adds one memory indirection to every access when
+ using `gimple_op'(), if this becomes a bottleneck, a pass can
+ choose to memoize the result from `gimple_ops'() and use that to
+ access the operands.
+
+12.5.7 Operand validation
+-------------------------
+
+When adding a new operand to a gimple statement, the operand will be
+validated according to what each tuple accepts in its operand vector.
+These predicates are called by the `gimple_<name>_set_...()'. Each
+tuple will use one of the following predicates (Note, this list is not
+exhaustive):
+
+ -- GIMPLE function: is_gimple_operand (tree t)
+ This is the most permissive of the predicates. It essentially
+ checks whether t has a `gimple_rhs_class' of `GIMPLE_SINGLE_RHS'.
+
+ -- GIMPLE function: is_gimple_val (tree t)
+ Returns true if t is a "GIMPLE value", which are all the
+ non-addressable stack variables (variables for which
+ `is_gimple_reg' returns true) and constants (expressions for which
+ `is_gimple_min_invariant' returns true).
+
+ -- GIMPLE function: is_gimple_addressable (tree t)
+ Returns true if t is a symbol or memory reference whose address
+ can be taken.
+
+ -- GIMPLE function: is_gimple_asm_val (tree t)
+ Similar to `is_gimple_val' but it also accepts hard registers.
+
+ -- GIMPLE function: is_gimple_call_addr (tree t)
+ Return true if t is a valid expression to use as the function
+ called by a `GIMPLE_CALL'.
+
+ -- GIMPLE function: is_gimple_constant (tree t)
+ Return true if t is a valid gimple constant.
+
+ -- GIMPLE function: is_gimple_min_invariant (tree t)
+ Return true if t is a valid minimal invariant. This is different
+ from constants, in that the specific value of t may not be known
+ at compile time, but it is known that it doesn't change (e.g., the
+ address of a function local variable).
+
+ -- GIMPLE function: is_gimple_min_invariant_address (tree t)
+ Return true if t is an `ADDR_EXPR' that does not change once the
+ program is running.
+
+12.5.8 Statement validation
+---------------------------
+
+ -- GIMPLE function: is_gimple_assign (gimple g)
+ Return true if the code of g is `GIMPLE_ASSIGN'.
+
+ -- GIMPLE function: is_gimple_call (gimple g)
+ Return true if the code of g is `GIMPLE_CALL'
+
+ -- GIMPLE function: gimple_assign_cast_p (gimple g)
+ Return true if g is a `GIMPLE_ASSIGN' that performs a type cast
+ operation
+
+\1f
+File: gccint.info, Node: Manipulating GIMPLE statements, Next: Tuple specific accessors, Prev: Operands, Up: GIMPLE
+
+12.6 Manipulating GIMPLE statements
+===================================
+
+This section documents all the functions available to handle each of
+the GIMPLE instructions.
+
+12.6.1 Common accessors
+-----------------------
+
+The following are common accessors for gimple statements.
+
+ -- GIMPLE function: enum gimple_code gimple_code (gimple g)
+ Return the code for statement `G'.
+
+ -- GIMPLE function: basic_block gimple_bb (gimple g)
+ Return the basic block to which statement `G' belongs to.
+
+ -- GIMPLE function: tree gimple_block (gimple g)
+ Return the lexical scope block holding statement `G'.
+
+ -- GIMPLE function: tree gimple_expr_type (gimple stmt)
+ Return the type of the main expression computed by `STMT'. Return
+ `void_type_node' if `STMT' computes nothing. This will only return
+ something meaningful for `GIMPLE_ASSIGN', `GIMPLE_COND' and
+ `GIMPLE_CALL'. For all other tuple codes, it will return
+ `void_type_node'.
+
+ -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt)
+ Return the tree code for the expression computed by `STMT'. This
+ is only meaningful for `GIMPLE_CALL', `GIMPLE_ASSIGN' and
+ `GIMPLE_COND'. If `STMT' is `GIMPLE_CALL', it will return
+ `CALL_EXPR'. For `GIMPLE_COND', it returns the code of the
+ comparison predicate. For `GIMPLE_ASSIGN' it returns the code of
+ the operation performed by the `RHS' of the assignment.
+
+ -- GIMPLE function: void gimple_set_block (gimple g, tree block)
+ Set the lexical scope block of `G' to `BLOCK'.
+
+ -- GIMPLE function: location_t gimple_locus (gimple g)
+ Return locus information for statement `G'.
+
+ -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus)
+ Set locus information for statement `G'.
+
+ -- GIMPLE function: bool gimple_locus_empty_p (gimple g)
+ Return true if `G' does not have locus information.
+
+ -- GIMPLE function: bool gimple_no_warning_p (gimple stmt)
+ Return true if no warnings should be emitted for statement `STMT'.
+
+ -- GIMPLE function: void gimple_set_visited (gimple stmt, bool
+ visited_p)
+ Set the visited status on statement `STMT' to `VISITED_P'.
+
+ -- GIMPLE function: bool gimple_visited_p (gimple stmt)
+ Return the visited status on statement `STMT'.
+
+ -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask
+ plf, bool val_p)
+ Set pass local flag `PLF' on statement `STMT' to `VAL_P'.
+
+ -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum
+ plf_mask plf)
+ Return the value of pass local flag `PLF' on statement `STMT'.
+
+ -- GIMPLE function: bool gimple_has_ops (gimple g)
+ Return true if statement `G' has register or memory operands.
+
+ -- GIMPLE function: bool gimple_has_mem_ops (gimple g)
+ Return true if statement `G' has memory operands.
+
+ -- GIMPLE function: unsigned gimple_num_ops (gimple g)
+ Return the number of operands for statement `G'.
+
+ -- GIMPLE function: tree *gimple_ops (gimple g)
+ Return the array of operands for statement `G'.
+
+ -- GIMPLE function: tree gimple_op (gimple g, unsigned i)
+ Return operand `I' for statement `G'.
+
+ -- GIMPLE function: tree *gimple_op_ptr (gimple g, unsigned i)
+ Return a pointer to operand `I' for statement `G'.
+
+ -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op)
+ Set operand `I' of statement `G' to `OP'.
+
+ -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt)
+ Return the set of symbols that have had their address taken by
+ `STMT'.
+
+ -- GIMPLE function: struct def_optype_d *gimple_def_ops (gimple g)
+ Return the set of `DEF' operands for statement `G'.
+
+ -- GIMPLE function: void gimple_set_def_ops (gimple g, struct
+ def_optype_d *def)
+ Set `DEF' to be the set of `DEF' operands for statement `G'.
+
+ -- GIMPLE function: struct use_optype_d *gimple_use_ops (gimple g)
+ Return the set of `USE' operands for statement `G'.
+
+ -- GIMPLE function: void gimple_set_use_ops (gimple g, struct
+ use_optype_d *use)
+ Set `USE' to be the set of `USE' operands for statement `G'.
+
+ -- GIMPLE function: struct voptype_d *gimple_vuse_ops (gimple g)
+ Return the set of `VUSE' operands for statement `G'.
+
+ -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct
+ voptype_d *ops)
+ Set `OPS' to be the set of `VUSE' operands for statement `G'.
+
+ -- GIMPLE function: struct voptype_d *gimple_vdef_ops (gimple g)
+ Return the set of `VDEF' operands for statement `G'.
+
+ -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct
+ voptype_d *ops)
+ Set `OPS' to be the set of `VDEF' operands for statement `G'.
+
+ -- GIMPLE function: bitmap gimple_loaded_syms (gimple g)
+ Return the set of symbols loaded by statement `G'. Each element of
+ the set is the `DECL_UID' of the corresponding symbol.
+
+ -- GIMPLE function: bitmap gimple_stored_syms (gimple g)
+ Return the set of symbols stored by statement `G'. Each element of
+ the set is the `DECL_UID' of the corresponding symbol.
+
+ -- GIMPLE function: bool gimple_modified_p (gimple g)
+ Return true if statement `G' has operands and the modified field
+ has been set.
+
+ -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt)
+ Return true if statement `STMT' contains volatile operands.
+
+ -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt,
+ bool volatilep)
+ Return true if statement `STMT' contains volatile operands.
+
+ -- GIMPLE function: void update_stmt (gimple s)
+ Mark statement `S' as modified, and update it.
+
+ -- GIMPLE function: void update_stmt_if_modified (gimple s)
+ Update statement `S' if it has been marked modified.
+
+ -- GIMPLE function: gimple gimple_copy (gimple stmt)
+ Return a deep copy of statement `STMT'.
+
+\1f
+File: gccint.info, Node: Tuple specific accessors, Next: GIMPLE sequences, Prev: Manipulating GIMPLE statements, Up: GIMPLE
+
+12.7 Tuple specific accessors
+=============================
+
+* Menu:
+
+* `GIMPLE_ASM'::
+* `GIMPLE_ASSIGN'::
+* `GIMPLE_BIND'::
+* `GIMPLE_CALL'::
+* `GIMPLE_CATCH'::
+* `GIMPLE_CHANGE_DYNAMIC_TYPE'::
+* `GIMPLE_COND'::
+* `GIMPLE_EH_FILTER'::
+* `GIMPLE_LABEL'::
+* `GIMPLE_NOP'::
+* `GIMPLE_OMP_ATOMIC_LOAD'::
+* `GIMPLE_OMP_ATOMIC_STORE'::
+* `GIMPLE_OMP_CONTINUE'::
+* `GIMPLE_OMP_CRITICAL'::
+* `GIMPLE_OMP_FOR'::
+* `GIMPLE_OMP_MASTER'::
+* `GIMPLE_OMP_ORDERED'::
+* `GIMPLE_OMP_PARALLEL'::
+* `GIMPLE_OMP_RETURN'::
+* `GIMPLE_OMP_SECTION'::
+* `GIMPLE_OMP_SECTIONS'::
+* `GIMPLE_OMP_SINGLE'::
+* `GIMPLE_PHI'::
+* `GIMPLE_RESX'::
+* `GIMPLE_RETURN'::
+* `GIMPLE_SWITCH'::
+* `GIMPLE_TRY'::
+* `GIMPLE_WITH_CLEANUP_EXPR'::
+
+\1f
+File: gccint.info, Node: `GIMPLE_ASM', Next: `GIMPLE_ASSIGN', Up: Tuple specific accessors
+
+12.7.1 `GIMPLE_ASM'
+-------------------
+
+ -- GIMPLE function: gimple gimple_build_asm (const char *string,
+ ninputs, noutputs, nclobbers, ...)
+ Build a `GIMPLE_ASM' statement. This statement is used for
+ building in-line assembly constructs. `STRING' is the assembly
+ code. `NINPUT' is the number of register inputs. `NOUTPUT' is the
+ number of register outputs. `NCLOBBERS' is the number of clobbered
+ registers. The rest of the arguments trees for each input,
+ output, and clobbered registers.
+
+ -- GIMPLE function: gimple gimple_build_asm_vec (const char *,
+ VEC(tree,gc) *, VEC(tree,gc) *, VEC(tree,gc) *)
+ Identical to gimple_build_asm, but the arguments are passed in
+ VECs.
+
+ -- GIMPLE function: gimple_asm_ninputs (gimple g)
+ Return the number of input operands for `GIMPLE_ASM' `G'.
+
+ -- GIMPLE function: gimple_asm_noutputs (gimple g)
+ Return the number of output operands for `GIMPLE_ASM' `G'.
+
+ -- GIMPLE function: gimple_asm_nclobbers (gimple g)
+ Return the number of clobber operands for `GIMPLE_ASM' `G'.
+
+ -- GIMPLE function: tree gimple_asm_input_op (gimple g, unsigned index)
+ Return input operand `INDEX' of `GIMPLE_ASM' `G'.
+
+ -- GIMPLE function: void gimple_asm_set_input_op (gimple g, unsigned
+ index, tree in_op)
+ Set `IN_OP' to be input operand `INDEX' in `GIMPLE_ASM' `G'.
+
+ -- GIMPLE function: tree gimple_asm_output_op (gimple g, unsigned
+ index)
+ Return output operand `INDEX' of `GIMPLE_ASM' `G'.
+
+ -- GIMPLE function: void gimple_asm_set_output_op (gimple g, unsigned
+ index, tree out_op)
+ Set `OUT_OP' to be output operand `INDEX' in `GIMPLE_ASM' `G'.
+
+ -- GIMPLE function: tree gimple_asm_clobber_op (gimple g, unsigned
+ index)
+ Return clobber operand `INDEX' of `GIMPLE_ASM' `G'.
+
+ -- GIMPLE function: void gimple_asm_set_clobber_op (gimple g, unsigned
+ index, tree clobber_op)
+ Set `CLOBBER_OP' to be clobber operand `INDEX' in `GIMPLE_ASM' `G'.
+
+ -- GIMPLE function: const char *gimple_asm_string (gimple g)
+ Return the string representing the assembly instruction in
+ `GIMPLE_ASM' `G'.
+
+ -- GIMPLE function: bool gimple_asm_volatile_p (gimple g)
+ Return true if `G' is an asm statement marked volatile.
+
+ -- GIMPLE function: void gimple_asm_set_volatile (gimple g)
+ Mark asm statement `G' as volatile.
+
+ -- GIMPLE function: void gimple_asm_clear_volatile (gimple g)
+ Remove volatile marker from asm statement `G'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_ASSIGN', Next: `GIMPLE_BIND', Prev: `GIMPLE_ASM', Up: Tuple specific accessors
+
+12.7.2 `GIMPLE_ASSIGN'
+----------------------
+
+ -- GIMPLE function: gimple gimple_build_assign (tree lhs, tree rhs)
+ Build a `GIMPLE_ASSIGN' statement. The left-hand side is an lvalue
+ passed in lhs. The right-hand side can be either a unary or
+ binary tree expression. The expression tree rhs will be flattened
+ and its operands assigned to the corresponding operand slots in
+ the new statement. This function is useful when you already have
+ a tree expression that you want to convert into a tuple. However,
+ try to avoid building expression trees for the sole purpose of
+ calling this function. If you already have the operands in
+ separate trees, it is better to use `gimple_build_assign_with_ops'.
+
+ -- GIMPLE function: gimple gimplify_assign (tree dst, tree src,
+ gimple_seq *seq_p)
+ Build a new `GIMPLE_ASSIGN' tuple and append it to the end of
+ `*SEQ_P'.
+
+ `DST'/`SRC' are the destination and source respectively. You can pass
+ungimplified trees in `DST' or `SRC', in which case they will be
+converted to a gimple operand if necessary.
+
+ This function returns the newly created `GIMPLE_ASSIGN' tuple.
+
+ -- GIMPLE function: gimple gimple_build_assign_with_ops (enum
+ tree_code subcode, tree lhs, tree op1, tree op2)
+ This function is similar to `gimple_build_assign', but is used to
+ build a `GIMPLE_ASSIGN' statement when the operands of the
+ right-hand side of the assignment are already split into different
+ operands.
+
+ The left-hand side is an lvalue passed in lhs. Subcode is the
+ `tree_code' for the right-hand side of the assignment. Op1 and op2
+ are the operands. If op2 is null, subcode must be a `tree_code'
+ for a unary expression.
+
+ -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g)
+ Return the code of the expression computed on the `RHS' of
+ assignment statement `G'.
+
+ -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class
+ (gimple g)
+ Return the gimple rhs class of the code for the expression
+ computed on the rhs of assignment statement `G'. This will never
+ return `GIMPLE_INVALID_RHS'.
+
+ -- GIMPLE function: tree gimple_assign_lhs (gimple g)
+ Return the `LHS' of assignment statement `G'.
+
+ -- GIMPLE function: tree *gimple_assign_lhs_ptr (gimple g)
+ Return a pointer to the `LHS' of assignment statement `G'.
+
+ -- GIMPLE function: tree gimple_assign_rhs1 (gimple g)
+ Return the first operand on the `RHS' of assignment statement `G'.
+
+ -- GIMPLE function: tree *gimple_assign_rhs1_ptr (gimple g)
+ Return the address of the first operand on the `RHS' of assignment
+ statement `G'.
+
+ -- GIMPLE function: tree gimple_assign_rhs2 (gimple g)
+ Return the second operand on the `RHS' of assignment statement `G'.
+
+ -- GIMPLE function: tree *gimple_assign_rhs2_ptr (gimple g)
+ Return the address of the second operand on the `RHS' of assignment
+ statement `G'.
+
+ -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs)
+ Set `LHS' to be the `LHS' operand of assignment statement `G'.
+
+ -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs)
+ Set `RHS' to be the first operand on the `RHS' of assignment
+ statement `G'.
+
+ -- GIMPLE function: tree gimple_assign_rhs2 (gimple g)
+ Return the second operand on the `RHS' of assignment statement `G'.
+
+ -- GIMPLE function: tree *gimple_assign_rhs2_ptr (gimple g)
+ Return a pointer to the second operand on the `RHS' of assignment
+ statement `G'.
+
+ -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs)
+ Set `RHS' to be the second operand on the `RHS' of assignment
+ statement `G'.
+
+ -- GIMPLE function: bool gimple_assign_cast_p (gimple s)
+ Return true if `S' is an type-cast assignment.
+
+\1f
+File: gccint.info, Node: `GIMPLE_BIND', Next: `GIMPLE_CALL', Prev: `GIMPLE_ASSIGN', Up: Tuple specific accessors
+
+12.7.3 `GIMPLE_BIND'
+--------------------
+
+ -- GIMPLE function: gimple gimple_build_bind (tree vars, gimple_seq
+ body)
+ Build a `GIMPLE_BIND' statement with a list of variables in `VARS'
+ and a body of statements in sequence `BODY'.
+
+ -- GIMPLE function: tree gimple_bind_vars (gimple g)
+ Return the variables declared in the `GIMPLE_BIND' statement `G'.
+
+ -- GIMPLE function: void gimple_bind_set_vars (gimple g, tree vars)
+ Set `VARS' to be the set of variables declared in the `GIMPLE_BIND'
+ statement `G'.
+
+ -- GIMPLE function: void gimple_bind_append_vars (gimple g, tree vars)
+ Append `VARS' to the set of variables declared in the `GIMPLE_BIND'
+ statement `G'.
+
+ -- GIMPLE function: gimple_seq gimple_bind_body (gimple g)
+ Return the GIMPLE sequence contained in the `GIMPLE_BIND' statement
+ `G'.
+
+ -- GIMPLE function: void gimple_bind_set_body (gimple g, gimple_seq
+ seq)
+ Set `SEQ' to be sequence contained in the `GIMPLE_BIND' statement
+ `G'.
+
+ -- GIMPLE function: void gimple_bind_add_stmt (gimple gs, gimple stmt)
+ Append a statement to the end of a `GIMPLE_BIND''s body.
+
+ -- GIMPLE function: void gimple_bind_add_seq (gimple gs, gimple_seq
+ seq)
+ Append a sequence of statements to the end of a `GIMPLE_BIND''s
+ body.
+
+ -- GIMPLE function: tree gimple_bind_block (gimple g)
+ Return the `TREE_BLOCK' node associated with `GIMPLE_BIND'
+ statement `G'. This is analogous to the `BIND_EXPR_BLOCK' field in
+ trees.
+
+ -- GIMPLE function: void gimple_bind_set_block (gimple g, tree block)
+ Set `BLOCK' to be the `TREE_BLOCK' node associated with
+ `GIMPLE_BIND' statement `G'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_CALL', Next: `GIMPLE_CATCH', Prev: `GIMPLE_BIND', Up: Tuple specific accessors
+
+12.7.4 `GIMPLE_CALL'
+--------------------
+
+ -- GIMPLE function: gimple gimple_build_call (tree fn, unsigned nargs,
+ ...)
+ Build a `GIMPLE_CALL' statement to function `FN'. The argument
+ `FN' must be either a `FUNCTION_DECL' or a gimple call address as
+ determined by `is_gimple_call_addr'. `NARGS' are the number of
+ arguments. The rest of the arguments follow the argument `NARGS',
+ and must be trees that are valid as rvalues in gimple (i.e., each
+ operand is validated with `is_gimple_operand').
+
+ -- GIMPLE function: gimple gimple_build_call_from_tree (tree call_expr)
+ Build a `GIMPLE_CALL' from a `CALL_EXPR' node. The arguments and
+ the function are taken from the expression directly. This routine
+ assumes that `call_expr' is already in GIMPLE form. That is, its
+ operands are GIMPLE values and the function call needs no further
+ simplification. All the call flags in `call_expr' are copied over
+ to the new `GIMPLE_CALL'.
+
+ -- GIMPLE function: gimple gimple_build_call_vec (tree fn, `VEC'(tree,
+ heap) *args)
+ Identical to `gimple_build_call' but the arguments are stored in a
+ `VEC'().
+
+ -- GIMPLE function: tree gimple_call_lhs (gimple g)
+ Return the `LHS' of call statement `G'.
+
+ -- GIMPLE function: tree *gimple_call_lhs_ptr (gimple g)
+ Return a pointer to the `LHS' of call statement `G'.
+
+ -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs)
+ Set `LHS' to be the `LHS' operand of call statement `G'.
+
+ -- GIMPLE function: tree gimple_call_fn (gimple g)
+ Return the tree node representing the function called by call
+ statement `G'.
+
+ -- GIMPLE function: void gimple_call_set_fn (gimple g, tree fn)
+ Set `FN' to be the function called by call statement `G'. This has
+ to be a gimple value specifying the address of the called function.
+
+ -- GIMPLE function: tree gimple_call_fndecl (gimple g)
+ If a given `GIMPLE_CALL''s callee is a `FUNCTION_DECL', return it.
+ Otherwise return `NULL'. This function is analogous to
+ `get_callee_fndecl' in `GENERIC'.
+
+ -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl)
+ Set the called function to `FNDECL'.
+
+ -- GIMPLE function: tree gimple_call_return_type (gimple g)
+ Return the type returned by call statement `G'.
+
+ -- GIMPLE function: tree gimple_call_chain (gimple g)
+ Return the static chain for call statement `G'.
+
+ -- GIMPLE function: void gimple_call_set_chain (gimple g, tree chain)
+ Set `CHAIN' to be the static chain for call statement `G'.
+
+ -- GIMPLE function: gimple_call_num_args (gimple g)
+ Return the number of arguments used by call statement `G'.
+
+ -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index)
+ Return the argument at position `INDEX' for call statement `G'.
+ The first argument is 0.
+
+ -- GIMPLE function: tree *gimple_call_arg_ptr (gimple g, unsigned
+ index)
+ Return a pointer to the argument at position `INDEX' for call
+ statement `G'.
+
+ -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned
+ index, tree arg)
+ Set `ARG' to be the argument at position `INDEX' for call statement
+ `G'.
+
+ -- GIMPLE function: void gimple_call_set_tail (gimple s)
+ Mark call statement `S' as being a tail call (i.e., a call just
+ before the exit of a function). These calls are candidate for tail
+ call optimization.
+
+ -- GIMPLE function: bool gimple_call_tail_p (gimple s)
+ Return true if `GIMPLE_CALL' `S' is marked as a tail call.
+
+ -- GIMPLE function: void gimple_call_mark_uninlinable (gimple s)
+ Mark `GIMPLE_CALL' `S' as being uninlinable.
+
+ -- GIMPLE function: bool gimple_call_cannot_inline_p (gimple s)
+ Return true if `GIMPLE_CALL' `S' cannot be inlined.
+
+ -- GIMPLE function: bool gimple_call_noreturn_p (gimple s)
+ Return true if `S' is a noreturn call.
+
+ -- GIMPLE function: gimple gimple_call_copy_skip_args (gimple stmt,
+ bitmap args_to_skip)
+ Build a `GIMPLE_CALL' identical to `STMT' but skipping the
+ arguments in the positions marked by the set `ARGS_TO_SKIP'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_CATCH', Next: `GIMPLE_CHANGE_DYNAMIC_TYPE', Prev: `GIMPLE_CALL', Up: Tuple specific accessors
+
+12.7.5 `GIMPLE_CATCH'
+---------------------
+
+ -- GIMPLE function: gimple gimple_build_catch (tree types, gimple_seq
+ handler)
+ Build a `GIMPLE_CATCH' statement. `TYPES' are the tree types this
+ catch handles. `HANDLER' is a sequence of statements with the code
+ for the handler.
+
+ -- GIMPLE function: tree gimple_catch_types (gimple g)
+ Return the types handled by `GIMPLE_CATCH' statement `G'.
+
+ -- GIMPLE function: tree *gimple_catch_types_ptr (gimple g)
+ Return a pointer to the types handled by `GIMPLE_CATCH' statement
+ `G'.
+
+ -- GIMPLE function: gimple_seq gimple_catch_handler (gimple g)
+ Return the GIMPLE sequence representing the body of the handler of
+ `GIMPLE_CATCH' statement `G'.
+
+ -- GIMPLE function: void gimple_catch_set_types (gimple g, tree t)
+ Set `T' to be the set of types handled by `GIMPLE_CATCH' `G'.
+
+ -- GIMPLE function: void gimple_catch_set_handler (gimple g,
+ gimple_seq handler)
+ Set `HANDLER' to be the body of `GIMPLE_CATCH' `G'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_CHANGE_DYNAMIC_TYPE', Next: `GIMPLE_COND', Prev: `GIMPLE_CATCH', Up: Tuple specific accessors
+
+12.7.6 `GIMPLE_CHANGE_DYNAMIC_TYPE'
+-----------------------------------
+
+ -- GIMPLE function: gimple gimple_build_cdt (tree type, tree ptr)
+ Build a `GIMPLE_CHANGE_DYNAMIC_TYPE' statement. `TYPE' is the new
+ type for the location `PTR'.
+
+ -- GIMPLE function: tree gimple_cdt_new_type (gimple g)
+ Return the new type set by `GIMPLE_CHANGE_DYNAMIC_TYPE' statement
+ `G'.
+
+ -- GIMPLE function: tree *gimple_cdt_new_type_ptr (gimple g)
+ Return a pointer to the new type set by
+ `GIMPLE_CHANGE_DYNAMIC_TYPE' statement `G'.
+
+ -- GIMPLE function: void gimple_cdt_set_new_type (gimple g, tree
+ new_type)
+ Set `NEW_TYPE' to be the type returned by
+ `GIMPLE_CHANGE_DYNAMIC_TYPE' statement `G'.
+
+ -- GIMPLE function: tree gimple_cdt_location (gimple g)
+ Return the location affected by `GIMPLE_CHANGE_DYNAMIC_TYPE'
+ statement `G'.
+
+ -- GIMPLE function: tree *gimple_cdt_location_ptr (gimple g)
+ Return a pointer to the location affected by
+ `GIMPLE_CHANGE_DYNAMIC_TYPE' statement `G'.
+
+ -- GIMPLE function: void gimple_cdt_set_location (gimple g, tree ptr)
+ Set `PTR' to be the location affected by
+ `GIMPLE_CHANGE_DYNAMIC_TYPE' statement `G'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_COND', Next: `GIMPLE_EH_FILTER', Prev: `GIMPLE_CHANGE_DYNAMIC_TYPE', Up: Tuple specific accessors
+
+12.7.7 `GIMPLE_COND'
+--------------------
+
+ -- GIMPLE function: gimple gimple_build_cond (enum tree_code
+ pred_code, tree lhs, tree rhs, tree t_label, tree f_label)
+ Build a `GIMPLE_COND' statement. `A' `GIMPLE_COND' statement
+ compares `LHS' and `RHS' and if the condition in `PRED_CODE' is
+ true, jump to the label in `t_label', otherwise jump to the label
+ in `f_label'. `PRED_CODE' are relational operator tree codes like
+ `EQ_EXPR', `LT_EXPR', `LE_EXPR', `NE_EXPR', etc.
+
+ -- GIMPLE function: gimple gimple_build_cond_from_tree (tree cond,
+ tree t_label, tree f_label)
+ Build a `GIMPLE_COND' statement from the conditional expression
+ tree `COND'. `T_LABEL' and `F_LABEL' are as in
+ `gimple_build_cond'.
+
+ -- GIMPLE function: enum tree_code gimple_cond_code (gimple g)
+ Return the code of the predicate computed by conditional statement
+ `G'.
+
+ -- GIMPLE function: void gimple_cond_set_code (gimple g, enum
+ tree_code code)
+ Set `CODE' to be the predicate code for the conditional statement
+ `G'.
+
+ -- GIMPLE function: tree gimple_cond_lhs (gimple g)
+ Return the `LHS' of the predicate computed by conditional statement
+ `G'.
+
+ -- GIMPLE function: void gimple_cond_set_lhs (gimple g, tree lhs)
+ Set `LHS' to be the `LHS' operand of the predicate computed by
+ conditional statement `G'.
+
+ -- GIMPLE function: tree gimple_cond_rhs (gimple g)
+ Return the `RHS' operand of the predicate computed by conditional
+ `G'.
+
+ -- GIMPLE function: void gimple_cond_set_rhs (gimple g, tree rhs)
+ Set `RHS' to be the `RHS' operand of the predicate computed by
+ conditional statement `G'.
+
+ -- GIMPLE function: tree gimple_cond_true_label (gimple g)
+ Return the label used by conditional statement `G' when its
+ predicate evaluates to true.
+
+ -- GIMPLE function: void gimple_cond_set_true_label (gimple g, tree
+ label)
+ Set `LABEL' to be the label used by conditional statement `G' when
+ its predicate evaluates to true.
+
+ -- GIMPLE function: void gimple_cond_set_false_label (gimple g, tree
+ label)
+ Set `LABEL' to be the label used by conditional statement `G' when
+ its predicate evaluates to false.
+
+ -- GIMPLE function: tree gimple_cond_false_label (gimple g)
+ Return the label used by conditional statement `G' when its
+ predicate evaluates to false.
+
+ -- GIMPLE function: void gimple_cond_make_false (gimple g)
+ Set the conditional `COND_STMT' to be of the form 'if (1 == 0)'.
+
+ -- GIMPLE function: void gimple_cond_make_true (gimple g)
+ Set the conditional `COND_STMT' to be of the form 'if (1 == 1)'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_EH_FILTER', Next: `GIMPLE_LABEL', Prev: `GIMPLE_COND', Up: Tuple specific accessors
+
+12.7.8 `GIMPLE_EH_FILTER'
+-------------------------
+
+ -- GIMPLE function: gimple gimple_build_eh_filter (tree types,
+ gimple_seq failure)
+ Build a `GIMPLE_EH_FILTER' statement. `TYPES' are the filter's
+ types. `FAILURE' is a sequence with the filter's failure action.
+
+ -- GIMPLE function: tree gimple_eh_filter_types (gimple g)
+ Return the types handled by `GIMPLE_EH_FILTER' statement `G'.
+
+ -- GIMPLE function: tree *gimple_eh_filter_types_ptr (gimple g)
+ Return a pointer to the types handled by `GIMPLE_EH_FILTER'
+ statement `G'.
+
+ -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g)
+ Return the sequence of statement to execute when `GIMPLE_EH_FILTER'
+ statement fails.
+
+ -- GIMPLE function: void gimple_eh_filter_set_types (gimple g, tree
+ types)
+ Set `TYPES' to be the set of types handled by `GIMPLE_EH_FILTER'
+ `G'.
+
+ -- GIMPLE function: void gimple_eh_filter_set_failure (gimple g,
+ gimple_seq failure)
+ Set `FAILURE' to be the sequence of statements to execute on
+ failure for `GIMPLE_EH_FILTER' `G'.
+
+ -- GIMPLE function: bool gimple_eh_filter_must_not_throw (gimple g)
+ Return the `EH_FILTER_MUST_NOT_THROW' flag.
+
+ -- GIMPLE function: void gimple_eh_filter_set_must_not_throw (gimple
+ g, bool mntp)
+ Set the `EH_FILTER_MUST_NOT_THROW' flag.
+
+\1f
+File: gccint.info, Node: `GIMPLE_LABEL', Next: `GIMPLE_NOP', Prev: `GIMPLE_EH_FILTER', Up: Tuple specific accessors
+
+12.7.9 `GIMPLE_LABEL'
+---------------------
+
+ -- GIMPLE function: gimple gimple_build_label (tree label)
+ Build a `GIMPLE_LABEL' statement with corresponding to the tree
+ label, `LABEL'.
+
+ -- GIMPLE function: tree gimple_label_label (gimple g)
+ Return the `LABEL_DECL' node used by `GIMPLE_LABEL' statement `G'.
+
+ -- GIMPLE function: void gimple_label_set_label (gimple g, tree label)
+ Set `LABEL' to be the `LABEL_DECL' node used by `GIMPLE_LABEL'
+ statement `G'.
+
+ -- GIMPLE function: gimple gimple_build_goto (tree dest)
+ Build a `GIMPLE_GOTO' statement to label `DEST'.
+
+ -- GIMPLE function: tree gimple_goto_dest (gimple g)
+ Return the destination of the unconditional jump `G'.
+
+ -- GIMPLE function: void gimple_goto_set_dest (gimple g, tree dest)
+ Set `DEST' to be the destination of the unconditional jump `G'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_NOP', Next: `GIMPLE_OMP_ATOMIC_LOAD', Prev: `GIMPLE_LABEL', Up: Tuple specific accessors
+
+12.7.10 `GIMPLE_NOP'
+--------------------
+
+ -- GIMPLE function: gimple gimple_build_nop (void)
+ Build a `GIMPLE_NOP' statement.
+
+ -- GIMPLE function: bool gimple_nop_p (gimple g)
+ Returns `TRUE' if statement `G' is a `GIMPLE_NOP'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_OMP_ATOMIC_LOAD', Next: `GIMPLE_OMP_ATOMIC_STORE', Prev: `GIMPLE_NOP', Up: Tuple specific accessors
+
+12.7.11 `GIMPLE_OMP_ATOMIC_LOAD'
+--------------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_atomic_load (tree lhs,
+ tree rhs)
+ Build a `GIMPLE_OMP_ATOMIC_LOAD' statement. `LHS' is the left-hand
+ side of the assignment. `RHS' is the right-hand side of the
+ assignment.
+
+ -- GIMPLE function: void gimple_omp_atomic_load_set_lhs (gimple g,
+ tree lhs)
+ Set the `LHS' of an atomic load.
+
+ -- GIMPLE function: tree gimple_omp_atomic_load_lhs (gimple g)
+ Get the `LHS' of an atomic load.
+
+ -- GIMPLE function: void gimple_omp_atomic_load_set_rhs (gimple g,
+ tree rhs)
+ Set the `RHS' of an atomic set.
+
+ -- GIMPLE function: tree gimple_omp_atomic_load_rhs (gimple g)
+ Get the `RHS' of an atomic set.
+
+\1f
+File: gccint.info, Node: `GIMPLE_OMP_ATOMIC_STORE', Next: `GIMPLE_OMP_CONTINUE', Prev: `GIMPLE_OMP_ATOMIC_LOAD', Up: Tuple specific accessors
+
+12.7.12 `GIMPLE_OMP_ATOMIC_STORE'
+---------------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_atomic_store (tree val)
+ Build a `GIMPLE_OMP_ATOMIC_STORE' statement. `VAL' is the value to
+ be stored.
+
+ -- GIMPLE function: void gimple_omp_atomic_store_set_val (gimple g,
+ tree val)
+ Set the value being stored in an atomic store.
+
+ -- GIMPLE function: tree gimple_omp_atomic_store_val (gimple g)
+ Return the value being stored in an atomic store.
+
+\1f
+File: gccint.info, Node: `GIMPLE_OMP_CONTINUE', Next: `GIMPLE_OMP_CRITICAL', Prev: `GIMPLE_OMP_ATOMIC_STORE', Up: Tuple specific accessors
+
+12.7.13 `GIMPLE_OMP_CONTINUE'
+-----------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_continue (tree
+ control_def, tree control_use)
+ Build a `GIMPLE_OMP_CONTINUE' statement. `CONTROL_DEF' is the
+ definition of the control variable. `CONTROL_USE' is the use of
+ the control variable.
+
+ -- GIMPLE function: tree gimple_omp_continue_control_def (gimple s)
+ Return the definition of the control variable on a
+ `GIMPLE_OMP_CONTINUE' in `S'.
+
+ -- GIMPLE function: tree gimple_omp_continue_control_def_ptr (gimple s)
+ Same as above, but return the pointer.
+
+ -- GIMPLE function: tree gimple_omp_continue_set_control_def (gimple s)
+ Set the control variable definition for a `GIMPLE_OMP_CONTINUE'
+ statement in `S'.
+
+ -- GIMPLE function: tree gimple_omp_continue_control_use (gimple s)
+ Return the use of the control variable on a `GIMPLE_OMP_CONTINUE'
+ in `S'.
+
+ -- GIMPLE function: tree gimple_omp_continue_control_use_ptr (gimple s)
+ Same as above, but return the pointer.
+
+ -- GIMPLE function: tree gimple_omp_continue_set_control_use (gimple s)
+ Set the control variable use for a `GIMPLE_OMP_CONTINUE' statement
+ in `S'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_OMP_CRITICAL', Next: `GIMPLE_OMP_FOR', Prev: `GIMPLE_OMP_CONTINUE', Up: Tuple specific accessors
+
+12.7.14 `GIMPLE_OMP_CRITICAL'
+-----------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_critical (gimple_seq body,
+ tree name)
+ Build a `GIMPLE_OMP_CRITICAL' statement. `BODY' is the sequence of
+ statements for which only one thread can execute. `NAME' is an
+ optional identifier for this critical block.
+
+ -- GIMPLE function: tree gimple_omp_critical_name (gimple g)
+ Return the name associated with `OMP_CRITICAL' statement `G'.
+
+ -- GIMPLE function: tree *gimple_omp_critical_name_ptr (gimple g)
+ Return a pointer to the name associated with `OMP' critical
+ statement `G'.
+
+ -- GIMPLE function: void gimple_omp_critical_set_name (gimple g, tree
+ name)
+ Set `NAME' to be the name associated with `OMP' critical statement
+ `G'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_OMP_FOR', Next: `GIMPLE_OMP_MASTER', Prev: `GIMPLE_OMP_CRITICAL', Up: Tuple specific accessors
+
+12.7.15 `GIMPLE_OMP_FOR'
+------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_for (gimple_seq body, tree
+ clauses, tree index, tree initial, tree final, tree incr,
+ gimple_seq pre_body, enum tree_code omp_for_cond)
+ Build a `GIMPLE_OMP_FOR' statement. `BODY' is sequence of
+ statements inside the for loop. `CLAUSES', are any of the `OMP'
+ loop construct's clauses: private, firstprivate, lastprivate,
+ reductions, ordered, schedule, and nowait. `PRE_BODY' is the
+ sequence of statements that are loop invariant. `INDEX' is the
+ index variable. `INITIAL' is the initial value of `INDEX'.
+ `FINAL' is final value of `INDEX'. OMP_FOR_COND is the predicate
+ used to compare `INDEX' and `FINAL'. `INCR' is the increment
+ expression.
+
+ -- GIMPLE function: tree gimple_omp_for_clauses (gimple g)
+ Return the clauses associated with `OMP_FOR' `G'.
+
+ -- GIMPLE function: tree *gimple_omp_for_clauses_ptr (gimple g)
+ Return a pointer to the `OMP_FOR' `G'.
+
+ -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree
+ clauses)
+ Set `CLAUSES' to be the list of clauses associated with `OMP_FOR'
+ `G'.
+
+ -- GIMPLE function: tree gimple_omp_for_index (gimple g)
+ Return the index variable for `OMP_FOR' `G'.
+
+ -- GIMPLE function: tree *gimple_omp_for_index_ptr (gimple g)
+ Return a pointer to the index variable for `OMP_FOR' `G'.
+
+ -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree
+ index)
+ Set `INDEX' to be the index variable for `OMP_FOR' `G'.
+
+ -- GIMPLE function: tree gimple_omp_for_initial (gimple g)
+ Return the initial value for `OMP_FOR' `G'.
+
+ -- GIMPLE function: tree *gimple_omp_for_initial_ptr (gimple g)
+ Return a pointer to the initial value for `OMP_FOR' `G'.
+
+ -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree
+ initial)
+ Set `INITIAL' to be the initial value for `OMP_FOR' `G'.
+
+ -- GIMPLE function: tree gimple_omp_for_final (gimple g)
+ Return the final value for `OMP_FOR' `G'.
+
+ -- GIMPLE function: tree *gimple_omp_for_final_ptr (gimple g)
+ turn a pointer to the final value for `OMP_FOR' `G'.
+
+ -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree
+ final)
+ Set `FINAL' to be the final value for `OMP_FOR' `G'.
+
+ -- GIMPLE function: tree gimple_omp_for_incr (gimple g)
+ Return the increment value for `OMP_FOR' `G'.
+
+ -- GIMPLE function: tree *gimple_omp_for_incr_ptr (gimple g)
+ Return a pointer to the increment value for `OMP_FOR' `G'.
+
+ -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr)
+ Set `INCR' to be the increment value for `OMP_FOR' `G'.
+
+ -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g)
+ Return the sequence of statements to execute before the `OMP_FOR'
+ statement `G' starts.
+
+ -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g,
+ gimple_seq pre_body)
+ Set `PRE_BODY' to be the sequence of statements to execute before
+ the `OMP_FOR' statement `G' starts.
+
+ -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum
+ tree_code cond)
+ Set `COND' to be the condition code for `OMP_FOR' `G'.
+
+ -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g)
+ Return the condition code associated with `OMP_FOR' `G'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_OMP_MASTER', Next: `GIMPLE_OMP_ORDERED', Prev: `GIMPLE_OMP_FOR', Up: Tuple specific accessors
+
+12.7.16 `GIMPLE_OMP_MASTER'
+---------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body)
+ Build a `GIMPLE_OMP_MASTER' statement. `BODY' is the sequence of
+ statements to be executed by just the master.
+
+\1f
+File: gccint.info, Node: `GIMPLE_OMP_ORDERED', Next: `GIMPLE_OMP_PARALLEL', Prev: `GIMPLE_OMP_MASTER', Up: Tuple specific accessors
+
+12.7.17 `GIMPLE_OMP_ORDERED'
+----------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body)
+ Build a `GIMPLE_OMP_ORDERED' statement.
+
+ `BODY' is the sequence of statements inside a loop that will executed
+in sequence.
+
+\1f
+File: gccint.info, Node: `GIMPLE_OMP_PARALLEL', Next: `GIMPLE_OMP_RETURN', Prev: `GIMPLE_OMP_ORDERED', Up: Tuple specific accessors
+
+12.7.18 `GIMPLE_OMP_PARALLEL'
+-----------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_parallel (gimple_seq body,
+ tree clauses, tree child_fn, tree data_arg)
+ Build a `GIMPLE_OMP_PARALLEL' statement.
+
+ `BODY' is sequence of statements which are executed in parallel.
+`CLAUSES', are the `OMP' parallel construct's clauses. `CHILD_FN' is
+the function created for the parallel threads to execute. `DATA_ARG'
+are the shared data argument(s).
+
+ -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g)
+ Return true if `OMP' parallel statement `G' has the
+ `GF_OMP_PARALLEL_COMBINED' flag set.
+
+ -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g)
+ Set the `GF_OMP_PARALLEL_COMBINED' field in `OMP' parallel
+ statement `G'.
+
+ -- GIMPLE function: gimple_seq gimple_omp_body (gimple g)
+ Return the body for the `OMP' statement `G'.
+
+ -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq
+ body)
+ Set `BODY' to be the body for the `OMP' statement `G'.
+
+ -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g)
+ Return the clauses associated with `OMP_PARALLEL' `G'.
+
+ -- GIMPLE function: tree *gimple_omp_parallel_clauses_ptr (gimple g)
+ Return a pointer to the clauses associated with `OMP_PARALLEL' `G'.
+
+ -- GIMPLE function: void gimple_omp_parallel_set_clauses (gimple g,
+ tree clauses)
+ Set `CLAUSES' to be the list of clauses associated with
+ `OMP_PARALLEL' `G'.
+
+ -- GIMPLE function: tree gimple_omp_parallel_child_fn (gimple g)
+ Return the child function used to hold the body of `OMP_PARALLEL'
+ `G'.
+
+ -- GIMPLE function: tree *gimple_omp_parallel_child_fn_ptr (gimple g)
+ Return a pointer to the child function used to hold the body of
+ `OMP_PARALLEL' `G'.
+
+ -- GIMPLE function: void gimple_omp_parallel_set_child_fn (gimple g,
+ tree child_fn)
+ Set `CHILD_FN' to be the child function for `OMP_PARALLEL' `G'.
+
+ -- GIMPLE function: tree gimple_omp_parallel_data_arg (gimple g)
+ Return the artificial argument used to send variables and values
+ from the parent to the children threads in `OMP_PARALLEL' `G'.
+
+ -- GIMPLE function: tree *gimple_omp_parallel_data_arg_ptr (gimple g)
+ Return a pointer to the data argument for `OMP_PARALLEL' `G'.
+
+ -- GIMPLE function: void gimple_omp_parallel_set_data_arg (gimple g,
+ tree data_arg)
+ Set `DATA_ARG' to be the data argument for `OMP_PARALLEL' `G'.
+
+ -- GIMPLE function: bool is_gimple_omp (gimple stmt)
+ Returns true when the gimple statement `STMT' is any of the OpenMP
+ types.
+
+\1f
+File: gccint.info, Node: `GIMPLE_OMP_RETURN', Next: `GIMPLE_OMP_SECTION', Prev: `GIMPLE_OMP_PARALLEL', Up: Tuple specific accessors
+
+12.7.19 `GIMPLE_OMP_RETURN'
+---------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p)
+ Build a `GIMPLE_OMP_RETURN' statement. `WAIT_P' is true if this is
+ a non-waiting return.
+
+ -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s)
+ Set the nowait flag on `GIMPLE_OMP_RETURN' statement `S'.
+
+ -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g)
+ Return true if `OMP' return statement `G' has the
+ `GF_OMP_RETURN_NOWAIT' flag set.
+
+\1f
+File: gccint.info, Node: `GIMPLE_OMP_SECTION', Next: `GIMPLE_OMP_SECTIONS', Prev: `GIMPLE_OMP_RETURN', Up: Tuple specific accessors
+
+12.7.20 `GIMPLE_OMP_SECTION'
+----------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body)
+ Build a `GIMPLE_OMP_SECTION' statement for a sections statement.
+
+ `BODY' is the sequence of statements in the section.
+
+ -- GIMPLE function: bool gimple_omp_section_last_p (gimple g)
+ Return true if `OMP' section statement `G' has the
+ `GF_OMP_SECTION_LAST' flag set.
+
+ -- GIMPLE function: void gimple_omp_section_set_last (gimple g)
+ Set the `GF_OMP_SECTION_LAST' flag on `G'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_OMP_SECTIONS', Next: `GIMPLE_OMP_SINGLE', Prev: `GIMPLE_OMP_SECTION', Up: Tuple specific accessors
+
+12.7.21 `GIMPLE_OMP_SECTIONS'
+-----------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_sections (gimple_seq body,
+ tree clauses)
+ Build a `GIMPLE_OMP_SECTIONS' statement. `BODY' is a sequence of
+ section statements. `CLAUSES' are any of the `OMP' sections
+ construct's clauses: private, firstprivate, lastprivate,
+ reduction, and nowait.
+
+ -- GIMPLE function: gimple gimple_build_omp_sections_switch (void)
+ Build a `GIMPLE_OMP_SECTIONS_SWITCH' statement.
+
+ -- GIMPLE function: tree gimple_omp_sections_control (gimple g)
+ Return the control variable associated with the
+ `GIMPLE_OMP_SECTIONS' in `G'.
+
+ -- GIMPLE function: tree *gimple_omp_sections_control_ptr (gimple g)
+ Return a pointer to the clauses associated with the
+ `GIMPLE_OMP_SECTIONS' in `G'.
+
+ -- GIMPLE function: void gimple_omp_sections_set_control (gimple g,
+ tree control)
+ Set `CONTROL' to be the set of clauses associated with the
+ `GIMPLE_OMP_SECTIONS' in `G'.
+
+ -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g)
+ Return the clauses associated with `OMP_SECTIONS' `G'.
+
+ -- GIMPLE function: tree *gimple_omp_sections_clauses_ptr (gimple g)
+ Return a pointer to the clauses associated with `OMP_SECTIONS' `G'.
+
+ -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g,
+ tree clauses)
+ Set `CLAUSES' to be the set of clauses associated with
+ `OMP_SECTIONS' `G'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_OMP_SINGLE', Next: `GIMPLE_PHI', Prev: `GIMPLE_OMP_SECTIONS', Up: Tuple specific accessors
+
+12.7.22 `GIMPLE_OMP_SINGLE'
+---------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_single (gimple_seq body,
+ tree clauses)
+ Build a `GIMPLE_OMP_SINGLE' statement. `BODY' is the sequence of
+ statements that will be executed once. `CLAUSES' are any of the
+ `OMP' single construct's clauses: private, firstprivate,
+ copyprivate, nowait.
+
+ -- GIMPLE function: tree gimple_omp_single_clauses (gimple g)
+ Return the clauses associated with `OMP_SINGLE' `G'.
+
+ -- GIMPLE function: tree *gimple_omp_single_clauses_ptr (gimple g)
+ Return a pointer to the clauses associated with `OMP_SINGLE' `G'.
+
+ -- GIMPLE function: void gimple_omp_single_set_clauses (gimple g, tree
+ clauses)
+ Set `CLAUSES' to be the clauses associated with `OMP_SINGLE' `G'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_PHI', Next: `GIMPLE_RESX', Prev: `GIMPLE_OMP_SINGLE', Up: Tuple specific accessors
+
+12.7.23 `GIMPLE_PHI'
+--------------------
+
+ -- GIMPLE function: gimple make_phi_node (tree var, int len)
+ Build a `PHI' node with len argument slots for variable var.
+
+ -- GIMPLE function: unsigned gimple_phi_capacity (gimple g)
+ Return the maximum number of arguments supported by `GIMPLE_PHI'
+ `G'.
+
+ -- GIMPLE function: unsigned gimple_phi_num_args (gimple g)
+ Return the number of arguments in `GIMPLE_PHI' `G'. This must
+ always be exactly the number of incoming edges for the basic block
+ holding `G'.
+
+ -- GIMPLE function: tree gimple_phi_result (gimple g)
+ Return the `SSA' name created by `GIMPLE_PHI' `G'.
+
+ -- GIMPLE function: tree *gimple_phi_result_ptr (gimple g)
+ Return a pointer to the `SSA' name created by `GIMPLE_PHI' `G'.
+
+ -- GIMPLE function: void gimple_phi_set_result (gimple g, tree result)
+ Set `RESULT' to be the `SSA' name created by `GIMPLE_PHI' `G'.
+
+ -- GIMPLE function: struct phi_arg_d *gimple_phi_arg (gimple g, index)
+ Return the `PHI' argument corresponding to incoming edge `INDEX'
+ for `GIMPLE_PHI' `G'.
+
+ -- GIMPLE function: void gimple_phi_set_arg (gimple g, index, struct
+ phi_arg_d * phiarg)
+ Set `PHIARG' to be the argument corresponding to incoming edge
+ `INDEX' for `GIMPLE_PHI' `G'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_RESX', Next: `GIMPLE_RETURN', Prev: `GIMPLE_PHI', Up: Tuple specific accessors
+
+12.7.24 `GIMPLE_RESX'
+---------------------
+
+ -- GIMPLE function: gimple gimple_build_resx (int region)
+ Build a `GIMPLE_RESX' statement which is a statement. This
+ statement is a placeholder for _Unwind_Resume before we know if a
+ function call or a branch is needed. `REGION' is the exception
+ region from which control is flowing.
+
+ -- GIMPLE function: int gimple_resx_region (gimple g)
+ Return the region number for `GIMPLE_RESX' `G'.
+
+ -- GIMPLE function: void gimple_resx_set_region (gimple g, int region)
+ Set `REGION' to be the region number for `GIMPLE_RESX' `G'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_RETURN', Next: `GIMPLE_SWITCH', Prev: `GIMPLE_RESX', Up: Tuple specific accessors
+
+12.7.25 `GIMPLE_RETURN'
+-----------------------
+
+ -- GIMPLE function: gimple gimple_build_return (tree retval)
+ Build a `GIMPLE_RETURN' statement whose return value is retval.
+
+ -- GIMPLE function: tree gimple_return_retval (gimple g)
+ Return the return value for `GIMPLE_RETURN' `G'.
+
+ -- GIMPLE function: void gimple_return_set_retval (gimple g, tree
+ retval)
+ Set `RETVAL' to be the return value for `GIMPLE_RETURN' `G'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_SWITCH', Next: `GIMPLE_TRY', Prev: `GIMPLE_RETURN', Up: Tuple specific accessors
+
+12.7.26 `GIMPLE_SWITCH'
+-----------------------
+
+ -- GIMPLE function: gimple gimple_build_switch ( nlabels, tree index,
+ tree default_label, ...)
+ Build a `GIMPLE_SWITCH' statement. `NLABELS' are the number of
+ labels excluding the default label. The default label is passed
+ in `DEFAULT_LABEL'. The rest of the arguments are trees
+ representing the labels. Each label is a tree of code
+ `CASE_LABEL_EXPR'.
+
+ -- GIMPLE function: gimple gimple_build_switch_vec (tree index, tree
+ default_label, `VEC'(tree,heap) *args)
+ This function is an alternate way of building `GIMPLE_SWITCH'
+ statements. `INDEX' and `DEFAULT_LABEL' are as in
+ gimple_build_switch. `ARGS' is a vector of `CASE_LABEL_EXPR' trees
+ that contain the labels.
+
+ -- GIMPLE function: unsigned gimple_switch_num_labels (gimple g)
+ Return the number of labels associated with the switch statement
+ `G'.
+
+ -- GIMPLE function: void gimple_switch_set_num_labels (gimple g,
+ unsigned nlabels)
+ Set `NLABELS' to be the number of labels for the switch statement
+ `G'.
+
+ -- GIMPLE function: tree gimple_switch_index (gimple g)
+ Return the index variable used by the switch statement `G'.
+
+ -- GIMPLE function: void gimple_switch_set_index (gimple g, tree index)
+ Set `INDEX' to be the index variable for switch statement `G'.
+
+ -- GIMPLE function: tree gimple_switch_label (gimple g, unsigned index)
+ Return the label numbered `INDEX'. The default label is 0, followed
+ by any labels in a switch statement.
+
+ -- GIMPLE function: void gimple_switch_set_label (gimple g, unsigned
+ index, tree label)
+ Set the label number `INDEX' to `LABEL'. 0 is always the default
+ label.
+
+ -- GIMPLE function: tree gimple_switch_default_label (gimple g)
+ Return the default label for a switch statement.
+
+ -- GIMPLE function: void gimple_switch_set_default_label (gimple g,
+ tree label)
+ Set the default label for a switch statement.
+
+\1f
+File: gccint.info, Node: `GIMPLE_TRY', Next: `GIMPLE_WITH_CLEANUP_EXPR', Prev: `GIMPLE_SWITCH', Up: Tuple specific accessors
+
+12.7.27 `GIMPLE_TRY'
+--------------------
+
+ -- GIMPLE function: gimple gimple_build_try (gimple_seq eval,
+ gimple_seq cleanup, unsigned int kind)
+ Build a `GIMPLE_TRY' statement. `EVAL' is a sequence with the
+ expression to evaluate. `CLEANUP' is a sequence of statements to
+ run at clean-up time. `KIND' is the enumeration value
+ `GIMPLE_TRY_CATCH' if this statement denotes a try/catch construct
+ or `GIMPLE_TRY_FINALLY' if this statement denotes a try/finally
+ construct.
+
+ -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g)
+ Return the kind of try block represented by `GIMPLE_TRY' `G'. This
+ is either `GIMPLE_TRY_CATCH' or `GIMPLE_TRY_FINALLY'.
+
+ -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g)
+ Return the `GIMPLE_TRY_CATCH_IS_CLEANUP' flag.
+
+ -- GIMPLE function: gimple_seq gimple_try_eval (gimple g)
+ Return the sequence of statements used as the body for `GIMPLE_TRY'
+ `G'.
+
+ -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g)
+ Return the sequence of statements used as the cleanup body for
+ `GIMPLE_TRY' `G'.
+
+ -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g,
+ bool catch_is_cleanup)
+ Set the `GIMPLE_TRY_CATCH_IS_CLEANUP' flag.
+
+ -- GIMPLE function: void gimple_try_set_eval (gimple g, gimple_seq
+ eval)
+ Set `EVAL' to be the sequence of statements to use as the body for
+ `GIMPLE_TRY' `G'.
+
+ -- GIMPLE function: void gimple_try_set_cleanup (gimple g, gimple_seq
+ cleanup)
+ Set `CLEANUP' to be the sequence of statements to use as the
+ cleanup body for `GIMPLE_TRY' `G'.
+
+\1f
+File: gccint.info, Node: `GIMPLE_WITH_CLEANUP_EXPR', Prev: `GIMPLE_TRY', Up: Tuple specific accessors
+
+12.7.28 `GIMPLE_WITH_CLEANUP_EXPR'
+----------------------------------
+
+ -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup)
+ Build a `GIMPLE_WITH_CLEANUP_EXPR' statement. `CLEANUP' is the
+ clean-up expression.
+
+ -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g)
+ Return the cleanup sequence for cleanup statement `G'.
+
+ -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq
+ cleanup)
+ Set `CLEANUP' to be the cleanup sequence for `G'.
+
+ -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g)
+ Return the `CLEANUP_EH_ONLY' flag for a `WCE' tuple.
+
+ -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g,
+ bool eh_only_p)
+ Set the `CLEANUP_EH_ONLY' flag for a `WCE' tuple.
+
+\1f
+File: gccint.info, Node: GIMPLE sequences, Next: Sequence iterators, Prev: Tuple specific accessors, Up: GIMPLE
+
+12.8 GIMPLE sequences
+=====================
+
+GIMPLE sequences are the tuple equivalent of `STATEMENT_LIST''s used in
+`GENERIC'. They are used to chain statements together, and when used
+in conjunction with sequence iterators, provide a framework for
+iterating through statements.
+
+ GIMPLE sequences are of type struct `gimple_sequence', but are more
+commonly passed by reference to functions dealing with sequences. The
+type for a sequence pointer is `gimple_seq' which is the same as struct
+`gimple_sequence' *. When declaring a local sequence, you can define a
+local variable of type struct `gimple_sequence'. When declaring a
+sequence allocated on the garbage collected heap, use the function
+`gimple_seq_alloc' documented below.
+
+ There are convenience functions for iterating through sequences in the
+section entitled Sequence Iterators.
+
+ Below is a list of functions to manipulate and query sequences.
+
+ -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple
+ g)
+ Link a gimple statement to the end of the sequence *`SEQ' if `G' is
+ not `NULL'. If *`SEQ' is `NULL', allocate a sequence before
+ linking.
+
+ -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest,
+ gimple_seq src)
+ Append sequence `SRC' to the end of sequence *`DEST' if `SRC' is
+ not `NULL'. If *`DEST' is `NULL', allocate a new sequence before
+ appending.
+
+ -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src)
+ Perform a deep copy of sequence `SRC' and return the result.
+
+ -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq)
+ Reverse the order of the statements in the sequence `SEQ'. Return
+ `SEQ'.
+
+ -- GIMPLE function: gimple gimple_seq_first (gimple_seq s)
+ Return the first statement in sequence `S'.
+
+ -- GIMPLE function: gimple gimple_seq_last (gimple_seq s)
+ Return the last statement in sequence `S'.
+
+ -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple
+ last)
+ Set the last statement in sequence `S' to the statement in `LAST'.
+
+ -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple
+ first)
+ Set the first statement in sequence `S' to the statement in
+ `FIRST'.
+
+ -- GIMPLE function: void gimple_seq_init (gimple_seq s)
+ Initialize sequence `S' to an empty sequence.
+
+ -- GIMPLE function: gimple_seq gimple_seq_alloc (void)
+ Allocate a new sequence in the garbage collected store and return
+ it.
+
+ -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq
+ src)
+ Copy the sequence `SRC' into the sequence `DEST'.
+
+ -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s)
+ Return true if the sequence `S' is empty.
+
+ -- GIMPLE function: gimple_seq bb_seq (basic_block bb)
+ Returns the sequence of statements in `BB'.
+
+ -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq)
+ Sets the sequence of statements in `BB' to `SEQ'.
+
+ -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq)
+ Determine whether `SEQ' contains exactly one statement.
+
+\1f
+File: gccint.info, Node: Sequence iterators, Next: Adding a new GIMPLE statement code, Prev: GIMPLE sequences, Up: GIMPLE
+
+12.9 Sequence iterators
+=======================
+
+Sequence iterators are convenience constructs for iterating through
+statements in a sequence. Given a sequence `SEQ', here is a typical
+use of gimple sequence iterators:
+
+ gimple_stmt_iterator gsi;
+
+ for (gsi = gsi_start (seq); !gsi_end_p (gsi); gsi_next (&gsi))
+ {
+ gimple g = gsi_stmt (gsi);
+ /* Do something with gimple statement `G'. */
+ }
+
+ Backward iterations are possible:
+
+ for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi))
+
+ Forward and backward iterations on basic blocks are possible with
+`gsi_start_bb' and `gsi_last_bb'.
+
+ In the documentation below we sometimes refer to enum
+`gsi_iterator_update'. The valid options for this enumeration are:
+
+ * `GSI_NEW_STMT' Only valid when a single statement is added. Move
+ the iterator to it.
+
+ * `GSI_SAME_STMT' Leave the iterator at the same statement.
+
+ * `GSI_CONTINUE_LINKING' Move iterator to whatever position is
+ suitable for linking other statements in the same direction.
+
+ Below is a list of the functions used to manipulate and use statement
+iterators.
+
+ -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq)
+ Return a new iterator pointing to the sequence `SEQ''s first
+ statement. If `SEQ' is empty, the iterator's basic block is
+ `NULL'. Use `gsi_start_bb' instead when the iterator needs to
+ always have the correct basic block set.
+
+ -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb)
+ Return a new iterator pointing to the first statement in basic
+ block `BB'.
+
+ -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq)
+ Return a new iterator initially pointing to the last statement of
+ sequence `SEQ'. If `SEQ' is empty, the iterator's basic block is
+ `NULL'. Use `gsi_last_bb' instead when the iterator needs to
+ always have the correct basic block set.
+
+ -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb)
+ Return a new iterator pointing to the last statement in basic
+ block `BB'.
+
+ -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i)
+ Return `TRUE' if at the end of `I'.
+
+ -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i)
+ Return `TRUE' if we're one statement before the end of `I'.
+
+ -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i)
+ Advance the iterator to the next gimple statement.
+
+ -- GIMPLE function: void gsi_prev (gimple_stmt_iterator *i)
+ Advance the iterator to the previous gimple statement.
+
+ -- GIMPLE function: gimple gsi_stmt (gimple_stmt_iterator i)
+ Return the current stmt.
+
+ -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block
+ bb)
+ Return a block statement iterator that points to the first
+ non-label statement in block `BB'.
+
+ -- GIMPLE function: gimple *gsi_stmt_ptr (gimple_stmt_iterator *i)
+ Return a pointer to the current stmt.
+
+ -- GIMPLE function: basic_block gsi_bb (gimple_stmt_iterator i)
+ Return the basic block associated with this iterator.
+
+ -- GIMPLE function: gimple_seq gsi_seq (gimple_stmt_iterator i)
+ Return the sequence associated with this iterator.
+
+ -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool
+ remove_eh_info)
+ Remove the current stmt from the sequence. The iterator is
+ updated to point to the next statement. When `REMOVE_EH_INFO' is
+ true we remove the statement pointed to by iterator `I' from the
+ `EH' tables. Otherwise we do not modify the `EH' tables.
+ Generally, `REMOVE_EH_INFO' should be true when the statement is
+ going to be removed from the `IL' and not reinserted elsewhere.
+
+ -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i,
+ gimple_seq seq, enum gsi_iterator_update mode)
+ Links the sequence of statements `SEQ' before the statement pointed
+ by iterator `I'. `MODE' indicates what to do with the iterator
+ after insertion (see `enum gsi_iterator_update' above).
+
+ -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i,
+ gimple g, enum gsi_iterator_update mode)
+ Links statement `G' before the statement pointed-to by iterator
+ `I'. Updates iterator `I' according to `MODE'.
+
+ -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i,
+ gimple_seq seq, enum gsi_iterator_update mode)
+ Links sequence `SEQ' after the statement pointed-to by iterator
+ `I'. `MODE' is as in `gsi_insert_after'.
+
+ -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i,
+ gimple g, enum gsi_iterator_update mode)
+ Links statement `G' after the statement pointed-to by iterator `I'.
+ `MODE' is as in `gsi_insert_after'.
+
+ -- GIMPLE function: gimple_seq gsi_split_seq_after
+ (gimple_stmt_iterator i)
+ Move all statements in the sequence after `I' to a new sequence.
+ Return this new sequence.
+
+ -- GIMPLE function: gimple_seq gsi_split_seq_before
+ (gimple_stmt_iterator *i)
+ Move all statements in the sequence before `I' to a new sequence.
+ Return this new sequence.
+
+ -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple
+ stmt, bool update_eh_info)
+ Replace the statement pointed-to by `I' to `STMT'. If
+ `UPDATE_EH_INFO' is true, the exception handling information of
+ the original statement is moved to the new statement.
+
+ -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i,
+ gimple stmt, enum gsi_iterator_update mode)
+ Insert statement `STMT' before the statement pointed-to by iterator
+ `I', update `STMT''s basic block and scan it for new operands.
+ `MODE' specifies how to update iterator `I' after insertion (see
+ enum `gsi_iterator_update').
+
+ -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator
+ *i, gimple_seq seq, enum gsi_iterator_update mode)
+ Like `gsi_insert_before', but for all the statements in `SEQ'.
+
+ -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i,
+ gimple stmt, enum gsi_iterator_update mode)
+ Insert statement `STMT' after the statement pointed-to by iterator
+ `I', update `STMT''s basic block and scan it for new operands.
+ `MODE' specifies how to update iterator `I' after insertion (see
+ enum `gsi_iterator_update').
+
+ -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator
+ *i, gimple_seq seq, enum gsi_iterator_update mode)
+ Like `gsi_insert_after', but for all the statements in `SEQ'.
+
+ -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt)
+ Finds iterator for `STMT'.
+
+ -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from,
+ gimple_stmt_iterator *to)
+ Move the statement at `FROM' so it comes right after the statement
+ at `TO'.
+
+ -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from,
+ gimple_stmt_iterator *to)
+ Move the statement at `FROM' so it comes right before the statement
+ at `TO'.
+
+ -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator
+ *from, basic_block bb)
+ Move the statement at `FROM' to the end of basic block `BB'.
+
+ -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt)
+ Add `STMT' to the pending list of edge `E'. No actual insertion is
+ made until a call to `gsi_commit_edge_inserts'() is made.
+
+ -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq
+ seq)
+ Add the sequence of statements in `SEQ' to the pending list of edge
+ `E'. No actual insertion is made until a call to
+ `gsi_commit_edge_inserts'() is made.
+
+ -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e,
+ gimple stmt)
+ Similar to `gsi_insert_on_edge'+`gsi_commit_edge_inserts'. If a
+ new block has to be created, it is returned.
+
+ -- GIMPLE function: void gsi_commit_one_edge_insert (edge e,
+ basic_block *new_bb)
+ Commit insertions pending at edge `E'. If a new block is created,
+ set `NEW_BB' to this block, otherwise set it to `NULL'.
+
+ -- GIMPLE function: void gsi_commit_edge_inserts (void)
+ This routine will commit all pending edge insertions, creating any
+ new basic blocks which are necessary.
+
+\1f
+File: gccint.info, Node: Adding a new GIMPLE statement code, Next: Statement and operand traversals, Prev: Sequence iterators, Up: GIMPLE
+
+12.10 Adding a new GIMPLE statement code
+========================================
+
+The first step in adding a new GIMPLE statement code, is modifying the
+file `gimple.def', which contains all the GIMPLE codes. Then you must
+add a corresponding structure, and an entry in `union
+gimple_statement_d', both of which are located in `gimple.h'. This in
+turn, will require you to add a corresponding `GTY' tag in
+`gsstruct.def', and code to handle this tag in `gss_for_code' which is
+located in `gimple.c'.
+
+ In order for the garbage collector to know the size of the structure
+you created in `gimple.h', you need to add a case to handle your new
+GIMPLE statement in `gimple_size' which is located in `gimple.c'.
+
+ You will probably want to create a function to build the new gimple
+statement in `gimple.c'. The function should be called
+`gimple_build_<`NEW_TUPLE_NAME'>', and should return the new tuple of
+type gimple.
+
+ If your new statement requires accessors for any members or operands
+it may have, put simple inline accessors in `gimple.h' and any
+non-trivial accessors in `gimple.c' with a corresponding prototype in
+`gimple.h'.
+
+\1f
+File: gccint.info, Node: Statement and operand traversals, Prev: Adding a new GIMPLE statement code, Up: GIMPLE
+
+12.11 Statement and operand traversals
+======================================
+
+There are two functions available for walking statements and sequences:
+`walk_gimple_stmt' and `walk_gimple_seq', accordingly, and a third
+function for walking the operands in a statement: `walk_gimple_op'.
+
+ -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi,
+ walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct
+ walk_stmt_info *wi)
+ This function is used to walk the current statement in `GSI',
+ optionally using traversal state stored in `WI'. If `WI' is
+ `NULL', no state is kept during the traversal.
+
+ The callback `CALLBACK_STMT' is called. If `CALLBACK_STMT' returns
+ true, it means that the callback function has handled all the
+ operands of the statement and it is not necessary to walk its
+ operands.
+
+ If `CALLBACK_STMT' is `NULL' or it returns false, `CALLBACK_OP' is
+ called on each operand of the statement via `walk_gimple_op'. If
+ `walk_gimple_op' returns non-`NULL' for any operand, the remaining
+ operands are not scanned.
+
+ The return value is that returned by the last call to
+ `walk_gimple_op', or `NULL_TREE' if no `CALLBACK_OP' is specified.
+
+ -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn
+ callback_op, struct walk_stmt_info *wi)
+ Use this function to walk the operands of statement `STMT'. Every
+ operand is walked via `walk_tree' with optional state information
+ in `WI'.
+
+ `CALLBACK_OP' is called on each operand of `STMT' via `walk_tree'.
+ Additional parameters to `walk_tree' must be stored in `WI'. For
+ each operand `OP', `walk_tree' is called as:
+
+ walk_tree (&`OP', `CALLBACK_OP', `WI', `WI'- `PSET')
+
+ If `CALLBACK_OP' returns non-`NULL' for an operand, the remaining
+ operands are not scanned. The return value is that returned by
+ the last call to `walk_tree', or `NULL_TREE' if no `CALLBACK_OP' is
+ specified.
+
+ -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn
+ callback_stmt, walk_tree_fn callback_op, struct
+ walk_stmt_info *wi)
+ This function walks all the statements in the sequence `SEQ'
+ calling `walk_gimple_stmt' on each one. `WI' is as in
+ `walk_gimple_stmt'. If `walk_gimple_stmt' returns non-`NULL', the
+ walk is stopped and the value returned. Otherwise, all the
+ statements are walked and `NULL_TREE' returned.
+
+\1f
+File: gccint.info, Node: Tree SSA, Next: RTL, Prev: GIMPLE, Up: Top
+
+13 Analysis and Optimization of GIMPLE tuples
+*********************************************
+
+GCC uses three main intermediate languages to represent the program
+during compilation: GENERIC, GIMPLE and RTL. GENERIC is a
+language-independent representation generated by each front end. It is
+used to serve as an interface between the parser and optimizer.
+GENERIC is a common representation that is able to represent programs
+written in all the languages supported by GCC.
+
+ GIMPLE and RTL are used to optimize the program. GIMPLE is used for
+target and language independent optimizations (e.g., inlining, constant
+propagation, tail call elimination, redundancy elimination, etc). Much
+like GENERIC, GIMPLE is a language independent, tree based
+representation. However, it differs from GENERIC in that the GIMPLE
+grammar is more restrictive: expressions contain no more than 3
+operands (except function calls), it has no control flow structures and
+expressions with side-effects are only allowed on the right hand side
+of assignments. See the chapter describing GENERIC and GIMPLE for more
+details.
+
+ This chapter describes the data structures and functions used in the
+GIMPLE optimizers (also known as "tree optimizers" or "middle end").
+In particular, it focuses on all the macros, data structures, functions
+and programming constructs needed to implement optimization passes for
+GIMPLE.
+
+* Menu:
+
+* Annotations:: Attributes for variables.
+* SSA Operands:: SSA names referenced by GIMPLE statements.
+* SSA:: Static Single Assignment representation.
+* Alias analysis:: Representing aliased loads and stores.
+
+\1f
+File: gccint.info, Node: Annotations, Next: SSA Operands, Up: Tree SSA
+
+13.1 Annotations
+================
+
+The optimizers need to associate attributes with variables during the
+optimization process. For instance, we need to know whether a variable
+has aliases. All these attributes are stored in data structures called
+annotations which are then linked to the field `ann' in `struct
+tree_common'.
+
+ Presently, we define annotations for variables (`var_ann_t').
+Annotations are defined and documented in `tree-flow.h'.
+
+\1f
+File: gccint.info, Node: SSA Operands, Next: SSA, Prev: Annotations, Up: Tree SSA
+
+13.2 SSA Operands
+=================
+
+Almost every GIMPLE statement will contain a reference to a variable or
+memory location. Since statements come in different shapes and sizes,
+their operands are going to be located at various spots inside the
+statement's tree. To facilitate access to the statement's operands,
+they are organized into lists associated inside each statement's
+annotation. Each element in an operand list is a pointer to a
+`VAR_DECL', `PARM_DECL' or `SSA_NAME' tree node. This provides a very
+convenient way of examining and replacing operands.
+
+ Data flow analysis and optimization is done on all tree nodes
+representing variables. Any node for which `SSA_VAR_P' returns nonzero
+is considered when scanning statement operands. However, not all
+`SSA_VAR_P' variables are processed in the same way. For the purposes
+of optimization, we need to distinguish between references to local
+scalar variables and references to globals, statics, structures,
+arrays, aliased variables, etc. The reason is simple, the compiler can
+gather complete data flow information for a local scalar. On the other
+hand, a global variable may be modified by a function call, it may not
+be possible to keep track of all the elements of an array or the fields
+of a structure, etc.
+
+ The operand scanner gathers two kinds of operands: "real" and
+"virtual". An operand for which `is_gimple_reg' returns true is
+considered real, otherwise it is a virtual operand. We also
+distinguish between uses and definitions. An operand is used if its
+value is loaded by the statement (e.g., the operand at the RHS of an
+assignment). If the statement assigns a new value to the operand, the
+operand is considered a definition (e.g., the operand at the LHS of an
+assignment).
+
+ Virtual and real operands also have very different data flow
+properties. Real operands are unambiguous references to the full
+object that they represent. For instance, given
+
+ {
+ int a, b;
+ a = b
+ }
+
+ Since `a' and `b' are non-aliased locals, the statement `a = b' will
+have one real definition and one real use because variable `b' is
+completely modified with the contents of variable `a'. Real definition
+are also known as "killing definitions". Similarly, the use of `a'
+reads all its bits.
+
+ In contrast, virtual operands are used with variables that can have a
+partial or ambiguous reference. This includes structures, arrays,
+globals, and aliased variables. In these cases, we have two types of
+definitions. For globals, structures, and arrays, we can determine from
+a statement whether a variable of these types has a killing definition.
+If the variable does, then the statement is marked as having a "must
+definition" of that variable. However, if a statement is only defining
+a part of the variable (i.e. a field in a structure), or if we know
+that a statement might define the variable but we cannot say for sure,
+then we mark that statement as having a "may definition". For
+instance, given
+
+ {
+ int a, b, *p;
+
+ if (...)
+ p = &a;
+ else
+ p = &b;
+ *p = 5;
+ return *p;
+ }
+
+ The assignment `*p = 5' may be a definition of `a' or `b'. If we
+cannot determine statically where `p' is pointing to at the time of the
+store operation, we create virtual definitions to mark that statement
+as a potential definition site for `a' and `b'. Memory loads are
+similarly marked with virtual use operands. Virtual operands are shown
+in tree dumps right before the statement that contains them. To
+request a tree dump with virtual operands, use the `-vops' option to
+`-fdump-tree':
+
+ {
+ int a, b, *p;
+
+ if (...)
+ p = &a;
+ else
+ p = &b;
+ # a = VDEF <a>
+ # b = VDEF <b>
+ *p = 5;
+
+ # VUSE <a>
+ # VUSE <b>
+ return *p;
+ }
+
+ Notice that `VDEF' operands have two copies of the referenced
+variable. This indicates that this is not a killing definition of that
+variable. In this case we refer to it as a "may definition" or
+"aliased store". The presence of the second copy of the variable in
+the `VDEF' operand will become important when the function is converted
+into SSA form. This will be used to link all the non-killing
+definitions to prevent optimizations from making incorrect assumptions
+about them.
+
+ Operands are updated as soon as the statement is finished via a call
+to `update_stmt'. If statement elements are changed via `SET_USE' or
+`SET_DEF', then no further action is required (i.e., those macros take
+care of updating the statement). If changes are made by manipulating
+the statement's tree directly, then a call must be made to
+`update_stmt' when complete. Calling one of the `bsi_insert' routines
+or `bsi_replace' performs an implicit call to `update_stmt'.
+
+13.2.1 Operand Iterators And Access Routines
+--------------------------------------------
+
+Operands are collected by `tree-ssa-operands.c'. They are stored
+inside each statement's annotation and can be accessed through either
+the operand iterators or an access routine.
+
+ The following access routines are available for examining operands:
+
+ 1. `SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return
+ NULL unless there is exactly one operand matching the specified
+ flags. If there is exactly one operand, the operand is returned
+ as either a `tree', `def_operand_p', or `use_operand_p'.
+
+ tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags);
+ use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES);
+ def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS);
+
+ 2. `ZERO_SSA_OPERANDS': This macro returns true if there are no
+ operands matching the specified flags.
+
+ if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS))
+ return;
+
+ 3. `NUM_SSA_OPERANDS': This macro Returns the number of operands
+ matching 'flags'. This actually executes a loop to perform the
+ count, so only use this if it is really needed.
+
+ int count = NUM_SSA_OPERANDS (stmt, flags)
+
+ If you wish to iterate over some or all operands, use the
+`FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator. For example, to print
+all the operands for a statement:
+
+ void
+ print_ops (tree stmt)
+ {
+ ssa_op_iter;
+ tree var;
+
+ FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS)
+ print_generic_expr (stderr, var, TDF_SLIM);
+ }
+
+ How to choose the appropriate iterator:
+
+ 1. Determine whether you are need to see the operand pointers, or
+ just the trees, and choose the appropriate macro:
+
+ Need Macro:
+ ---- -------
+ use_operand_p FOR_EACH_SSA_USE_OPERAND
+ def_operand_p FOR_EACH_SSA_DEF_OPERAND
+ tree FOR_EACH_SSA_TREE_OPERAND
+
+ 2. You need to declare a variable of the type you are interested in,
+ and an ssa_op_iter structure which serves as the loop controlling
+ variable.
+
+ 3. Determine which operands you wish to use, and specify the flags of
+ those you are interested in. They are documented in
+ `tree-ssa-operands.h':
+
+ #define SSA_OP_USE 0x01 /* Real USE operands. */
+ #define SSA_OP_DEF 0x02 /* Real DEF operands. */
+ #define SSA_OP_VUSE 0x04 /* VUSE operands. */
+ #define SSA_OP_VMAYUSE 0x08 /* USE portion of VDEFS. */
+ #define SSA_OP_VDEF 0x10 /* DEF portion of VDEFS. */
+
+ /* These are commonly grouped operand flags. */
+ #define SSA_OP_VIRTUAL_USES (SSA_OP_VUSE | SSA_OP_VMAYUSE)
+ #define SSA_OP_VIRTUAL_DEFS (SSA_OP_VDEF)
+ #define SSA_OP_ALL_USES (SSA_OP_VIRTUAL_USES | SSA_OP_USE)
+ #define SSA_OP_ALL_DEFS (SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF)
+ #define SSA_OP_ALL_OPERANDS (SSA_OP_ALL_USES | SSA_OP_ALL_DEFS)
+
+ So if you want to look at the use pointers for all the `USE' and
+`VUSE' operands, you would do something like:
+
+ use_operand_p use_p;
+ ssa_op_iter iter;
+
+ FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE))
+ {
+ process_use_ptr (use_p);
+ }
+
+ The `TREE' macro is basically the same as the `USE' and `DEF' macros,
+only with the use or def dereferenced via `USE_FROM_PTR (use_p)' and
+`DEF_FROM_PTR (def_p)'. Since we aren't using operand pointers, use
+and defs flags can be mixed.
+
+ tree var;
+ ssa_op_iter iter;
+
+ FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE)
+ {
+ print_generic_expr (stderr, var, TDF_SLIM);
+ }
+
+ `VDEF's are broken into two flags, one for the `DEF' portion
+(`SSA_OP_VDEF') and one for the USE portion (`SSA_OP_VMAYUSE'). If all
+you want to look at are the `VDEF's together, there is a fourth
+iterator macro for this, which returns both a def_operand_p and a
+use_operand_p for each `VDEF' in the statement. Note that you don't
+need any flags for this one.
+
+ use_operand_p use_p;
+ def_operand_p def_p;
+ ssa_op_iter iter;
+
+ FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter)
+ {
+ my_code;
+ }
+
+ There are many examples in the code as well, as well as the
+documentation in `tree-ssa-operands.h'.
+
+ There are also a couple of variants on the stmt iterators regarding PHI
+nodes.
+
+ `FOR_EACH_PHI_ARG' Works exactly like `FOR_EACH_SSA_USE_OPERAND',
+except it works over `PHI' arguments instead of statement operands.
+
+ /* Look at every virtual PHI use. */
+ FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES)
+ {
+ my_code;
+ }
+
+ /* Look at every real PHI use. */
+ FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES)
+ my_code;
+
+ /* Look at every PHI use. */
+ FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES)
+ my_code;
+
+ `FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like
+`FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a
+statement or a `PHI' node. These should be used when it is appropriate
+but they are not quite as efficient as the individual `FOR_EACH_PHI'
+and `FOR_EACH_SSA' routines.
+
+ FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags)
+ {
+ my_code;
+ }
+
+ FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags)
+ {
+ my_code;
+ }
+
+13.2.2 Immediate Uses
+---------------------
+
+Immediate use information is now always available. Using the immediate
+use iterators, you may examine every use of any `SSA_NAME'. For
+instance, to change each use of `ssa_var' to `ssa_var2' and call
+fold_stmt on each stmt after that is done:
+
+ use_operand_p imm_use_p;
+ imm_use_iterator iterator;
+ tree ssa_var, stmt;
+
+
+ FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var)
+ {
+ FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator)
+ SET_USE (imm_use_p, ssa_var_2);
+ fold_stmt (stmt);
+ }
+
+ There are 2 iterators which can be used. `FOR_EACH_IMM_USE_FAST' is
+used when the immediate uses are not changed, i.e., you are looking at
+the uses, but not setting them.
+
+ If they do get changed, then care must be taken that things are not
+changed under the iterators, so use the `FOR_EACH_IMM_USE_STMT' and
+`FOR_EACH_IMM_USE_ON_STMT' iterators. They attempt to preserve the
+sanity of the use list by moving all the uses for a statement into a
+controlled position, and then iterating over those uses. Then the
+optimization can manipulate the stmt when all the uses have been
+processed. This is a little slower than the FAST version since it adds
+a placeholder element and must sort through the list a bit for each
+statement. This placeholder element must be also be removed if the
+loop is terminated early. The macro `BREAK_FROM_IMM_USE_SAFE' is
+provided to do this :
+
+ FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var)
+ {
+ if (stmt == last_stmt)
+ BREAK_FROM_SAFE_IMM_USE (iter);
+
+ FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator)
+ SET_USE (imm_use_p, ssa_var_2);
+ fold_stmt (stmt);
+ }
+
+ There are checks in `verify_ssa' which verify that the immediate use
+list is up to date, as well as checking that an optimization didn't
+break from the loop without using this macro. It is safe to simply
+'break'; from a `FOR_EACH_IMM_USE_FAST' traverse.
+
+ Some useful functions and macros:
+ 1. `has_zero_uses (ssa_var)' : Returns true if there are no uses of
+ `ssa_var'.
+
+ 2. `has_single_use (ssa_var)' : Returns true if there is only a
+ single use of `ssa_var'.
+
+ 3. `single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' :
+ Returns true if there is only a single use of `ssa_var', and also
+ returns the use pointer and statement it occurs in, in the second
+ and third parameters.
+
+ 4. `num_imm_uses (ssa_var)' : Returns the number of immediate uses of
+ `ssa_var'. It is better not to use this if possible since it simply
+ utilizes a loop to count the uses.
+
+ 5. `PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a `PHI'
+ node, return the index number for the use. An assert is triggered
+ if the use isn't located in a `PHI' node.
+
+ 6. `USE_STMT (use_p)' : Return the statement a use occurs in.
+
+ Note that uses are not put into an immediate use list until their
+statement is actually inserted into the instruction stream via a
+`bsi_*' routine.
+
+ It is also still possible to utilize lazy updating of statements, but
+this should be used only when absolutely required. Both alias analysis
+and the dominator optimizations currently do this.
+
+ When lazy updating is being used, the immediate use information is out
+of date and cannot be used reliably. Lazy updating is achieved by
+simply marking statements modified via calls to `mark_stmt_modified'
+instead of `update_stmt'. When lazy updating is no longer required,
+all the modified statements must have `update_stmt' called in order to
+bring them up to date. This must be done before the optimization is
+finished, or `verify_ssa' will trigger an abort.
+
+ This is done with a simple loop over the instruction stream:
+ block_stmt_iterator bsi;
+ basic_block bb;
+ FOR_EACH_BB (bb)
+ {
+ for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
+ update_stmt_if_modified (bsi_stmt (bsi));
+ }
+
+\1f
+File: gccint.info, Node: SSA, Next: Alias analysis, Prev: SSA Operands, Up: Tree SSA
+
+13.3 Static Single Assignment
+=============================
+
+Most of the tree optimizers rely on the data flow information provided
+by the Static Single Assignment (SSA) form. We implement the SSA form
+as described in `R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K.
+Zadeck. Efficiently Computing Static Single Assignment Form and the
+Control Dependence Graph. ACM Transactions on Programming Languages
+and Systems, 13(4):451-490, October 1991'.
+
+ The SSA form is based on the premise that program variables are
+assigned in exactly one location in the program. Multiple assignments
+to the same variable create new versions of that variable. Naturally,
+actual programs are seldom in SSA form initially because variables tend
+to be assigned multiple times. The compiler modifies the program
+representation so that every time a variable is assigned in the code, a
+new version of the variable is created. Different versions of the same
+variable are distinguished by subscripting the variable name with its
+version number. Variables used in the right-hand side of expressions
+are renamed so that their version number matches that of the most
+recent assignment.
+
+ We represent variable versions using `SSA_NAME' nodes. The renaming
+process in `tree-ssa.c' wraps every real and virtual operand with an
+`SSA_NAME' node which contains the version number and the statement
+that created the `SSA_NAME'. Only definitions and virtual definitions
+may create new `SSA_NAME' nodes.
+
+ Sometimes, flow of control makes it impossible to determine the most
+recent version of a variable. In these cases, the compiler inserts an
+artificial definition for that variable called "PHI function" or "PHI
+node". This new definition merges all the incoming versions of the
+variable to create a new name for it. For instance,
+
+ if (...)
+ a_1 = 5;
+ else if (...)
+ a_2 = 2;
+ else
+ a_3 = 13;
+
+ # a_4 = PHI <a_1, a_2, a_3>
+ return a_4;
+
+ Since it is not possible to determine which of the three branches will
+be taken at runtime, we don't know which of `a_1', `a_2' or `a_3' to
+use at the return statement. So, the SSA renamer creates a new version
+`a_4' which is assigned the result of "merging" `a_1', `a_2' and `a_3'.
+Hence, PHI nodes mean "one of these operands. I don't know which".
+
+ The following macros can be used to examine PHI nodes
+
+ -- Macro: PHI_RESULT (PHI)
+ Returns the `SSA_NAME' created by PHI node PHI (i.e., PHI's LHS).
+
+ -- Macro: PHI_NUM_ARGS (PHI)
+ Returns the number of arguments in PHI. This number is exactly
+ the number of incoming edges to the basic block holding PHI.
+
+ -- Macro: PHI_ARG_ELT (PHI, I)
+ Returns a tuple representing the Ith argument of PHI. Each
+ element of this tuple contains an `SSA_NAME' VAR and the incoming
+ edge through which VAR flows.
+
+ -- Macro: PHI_ARG_EDGE (PHI, I)
+ Returns the incoming edge for the Ith argument of PHI.
+
+ -- Macro: PHI_ARG_DEF (PHI, I)
+ Returns the `SSA_NAME' for the Ith argument of PHI.
+
+13.3.1 Preserving the SSA form
+------------------------------
+
+Some optimization passes make changes to the function that invalidate
+the SSA property. This can happen when a pass has added new symbols or
+changed the program so that variables that were previously aliased
+aren't anymore. Whenever something like this happens, the affected
+symbols must be renamed into SSA form again. Transformations that emit
+new code or replicate existing statements will also need to update the
+SSA form.
+
+ Since GCC implements two different SSA forms for register and virtual
+variables, keeping the SSA form up to date depends on whether you are
+updating register or virtual names. In both cases, the general idea
+behind incremental SSA updates is similar: when new SSA names are
+created, they typically are meant to replace other existing names in
+the program.
+
+ For instance, given the following code:
+
+ 1 L0:
+ 2 x_1 = PHI (0, x_5)
+ 3 if (x_1 < 10)
+ 4 if (x_1 > 7)
+ 5 y_2 = 0
+ 6 else
+ 7 y_3 = x_1 + x_7
+ 8 endif
+ 9 x_5 = x_1 + 1
+ 10 goto L0;
+ 11 endif
+
+ Suppose that we insert new names `x_10' and `x_11' (lines `4' and `8').
+
+ 1 L0:
+ 2 x_1 = PHI (0, x_5)
+ 3 if (x_1 < 10)
+ 4 x_10 = ...
+ 5 if (x_1 > 7)
+ 6 y_2 = 0
+ 7 else
+ 8 x_11 = ...
+ 9 y_3 = x_1 + x_7
+ 10 endif
+ 11 x_5 = x_1 + 1
+ 12 goto L0;
+ 13 endif
+
+ We want to replace all the uses of `x_1' with the new definitions of
+`x_10' and `x_11'. Note that the only uses that should be replaced are
+those at lines `5', `9' and `11'. Also, the use of `x_7' at line `9'
+should _not_ be replaced (this is why we cannot just mark symbol `x' for
+renaming).
+
+ Additionally, we may need to insert a PHI node at line `11' because
+that is a merge point for `x_10' and `x_11'. So the use of `x_1' at
+line `11' will be replaced with the new PHI node. The insertion of PHI
+nodes is optional. They are not strictly necessary to preserve the SSA
+form, and depending on what the caller inserted, they may not even be
+useful for the optimizers.
+
+ Updating the SSA form is a two step process. First, the pass has to
+identify which names need to be updated and/or which symbols need to be
+renamed into SSA form for the first time. When new names are
+introduced to replace existing names in the program, the mapping
+between the old and the new names are registered by calling
+`register_new_name_mapping' (note that if your pass creates new code by
+duplicating basic blocks, the call to `tree_duplicate_bb' will set up
+the necessary mappings automatically). On the other hand, if your pass
+exposes a new symbol that should be put in SSA form for the first time,
+the new symbol should be registered with `mark_sym_for_renaming'.
+
+ After the replacement mappings have been registered and new symbols
+marked for renaming, a call to `update_ssa' makes the registered
+changes. This can be done with an explicit call or by creating `TODO'
+flags in the `tree_opt_pass' structure for your pass. There are
+several `TODO' flags that control the behavior of `update_ssa':
+
+ * `TODO_update_ssa'. Update the SSA form inserting PHI nodes for
+ newly exposed symbols and virtual names marked for updating. When
+ updating real names, only insert PHI nodes for a real name `O_j'
+ in blocks reached by all the new and old definitions for `O_j'.
+ If the iterated dominance frontier for `O_j' is not pruned, we may
+ end up inserting PHI nodes in blocks that have one or more edges
+ with no incoming definition for `O_j'. This would lead to
+ uninitialized warnings for `O_j''s symbol.
+
+ * `TODO_update_ssa_no_phi'. Update the SSA form without inserting
+ any new PHI nodes at all. This is used by passes that have either
+ inserted all the PHI nodes themselves or passes that need only to
+ patch use-def and def-def chains for virtuals (e.g., DCE).
+
+ * `TODO_update_ssa_full_phi'. Insert PHI nodes everywhere they are
+ needed. No pruning of the IDF is done. This is used by passes
+ that need the PHI nodes for `O_j' even if it means that some
+ arguments will come from the default definition of `O_j''s symbol
+ (e.g., `pass_linear_transform').
+
+ WARNING: If you need to use this flag, chances are that your pass
+ may be doing something wrong. Inserting PHI nodes for an old name
+ where not all edges carry a new replacement may lead to silent
+ codegen errors or spurious uninitialized warnings.
+
+ * `TODO_update_ssa_only_virtuals'. Passes that update the SSA form
+ on their own may want to delegate the updating of virtual names to
+ the generic updater. Since FUD chains are easier to maintain,
+ this simplifies the work they need to do. NOTE: If this flag is
+ used, any OLD->NEW mappings for real names are explicitly
+ destroyed and only the symbols marked for renaming are processed.
+
+13.3.2 Preserving the virtual SSA form
+--------------------------------------
+
+The virtual SSA form is harder to preserve than the non-virtual SSA form
+mainly because the set of virtual operands for a statement may change at
+what some would consider unexpected times. In general, statement
+modifications should be bracketed between calls to `push_stmt_changes'
+and `pop_stmt_changes'. For example,
+
+ munge_stmt (tree stmt)
+ {
+ push_stmt_changes (&stmt);
+ ... rewrite STMT ...
+ pop_stmt_changes (&stmt);
+ }
+
+ The call to `push_stmt_changes' saves the current state of the
+statement operands and the call to `pop_stmt_changes' compares the
+saved state with the current one and does the appropriate symbol
+marking for the SSA renamer.
+
+ It is possible to modify several statements at a time, provided that
+`push_stmt_changes' and `pop_stmt_changes' are called in LIFO order, as
+when processing a stack of statements.
+
+ Additionally, if the pass discovers that it did not need to make
+changes to the statement after calling `push_stmt_changes', it can
+simply discard the topmost change buffer by calling
+`discard_stmt_changes'. This will avoid the expensive operand re-scan
+operation and the buffer comparison that determines if symbols need to
+be marked for renaming.
+
+13.3.3 Examining `SSA_NAME' nodes
+---------------------------------
+
+The following macros can be used to examine `SSA_NAME' nodes
+
+ -- Macro: SSA_NAME_DEF_STMT (VAR)
+ Returns the statement S that creates the `SSA_NAME' VAR. If S is
+ an empty statement (i.e., `IS_EMPTY_STMT (S)' returns `true'), it
+ means that the first reference to this variable is a USE or a VUSE.
+
+ -- Macro: SSA_NAME_VERSION (VAR)
+ Returns the version number of the `SSA_NAME' object VAR.
+
+13.3.4 Walking use-def chains
+-----------------------------
+
+ -- Tree SSA function: void walk_use_def_chains (VAR, FN, DATA)
+ Walks use-def chains starting at the `SSA_NAME' node VAR. Calls
+ function FN at each reaching definition found. Function FN takes
+ three arguments: VAR, its defining statement (DEF_STMT) and a
+ generic pointer to whatever state information that FN may want to
+ maintain (DATA). Function FN is able to stop the walk by
+ returning `true', otherwise in order to continue the walk, FN
+ should return `false'.
+
+ Note, that if DEF_STMT is a `PHI' node, the semantics are slightly
+ different. For each argument ARG of the PHI node, this function
+ will:
+
+ 1. Walk the use-def chains for ARG.
+
+ 2. Call `FN (ARG, PHI, DATA)'.
+
+ Note how the first argument to FN is no longer the original
+ variable VAR, but the PHI argument currently being examined. If
+ FN wants to get at VAR, it should call `PHI_RESULT' (PHI).
+
+13.3.5 Walking the dominator tree
+---------------------------------
+
+ -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB)
+ This function walks the dominator tree for the current CFG calling
+ a set of callback functions defined in STRUCT DOM_WALK_DATA in
+ `domwalk.h'. The call back functions you need to define give you
+ hooks to execute custom code at various points during traversal:
+
+ 1. Once to initialize any local data needed while processing BB
+ and its children. This local data is pushed into an internal
+ stack which is automatically pushed and popped as the walker
+ traverses the dominator tree.
+
+ 2. Once before traversing all the statements in the BB.
+
+ 3. Once for every statement inside BB.
+
+ 4. Once after traversing all the statements and before recursing
+ into BB's dominator children.
+
+ 5. It then recurses into all the dominator children of BB.
+
+ 6. After recursing into all the dominator children of BB it can,
+ optionally, traverse every statement in BB again (i.e.,
+ repeating steps 2 and 3).
+
+ 7. Once after walking the statements in BB and BB's dominator
+ children. At this stage, the block local data stack is
+ popped.
+
+\1f
+File: gccint.info, Node: Alias analysis, Prev: SSA, Up: Tree SSA
+
+13.4 Alias analysis
+===================
+
+Alias analysis proceeds in 4 main phases:
+
+ 1. Structural alias analysis.
+
+ This phase walks the types for structure variables, and determines
+ which of the fields can overlap using offset and size of each
+ field. For each field, a "subvariable" called a "Structure field
+ tag" (SFT) is created, which represents that field as a separate
+ variable. All accesses that could possibly overlap with a given
+ field will have virtual operands for the SFT of that field.
+
+ struct foo
+ {
+ int a;
+ int b;
+ }
+ struct foo temp;
+ int bar (void)
+ {
+ int tmp1, tmp2, tmp3;
+ SFT.0_2 = VDEF <SFT.0_1>
+ temp.a = 5;
+ SFT.1_4 = VDEF <SFT.1_3>
+ temp.b = 6;
+
+ VUSE <SFT.1_4>
+ tmp1_5 = temp.b;
+ VUSE <SFT.0_2>
+ tmp2_6 = temp.a;
+
+ tmp3_7 = tmp1_5 + tmp2_6;
+ return tmp3_7;
+ }
+
+ If you copy the symbol tag for a variable for some reason, you
+ probably also want to copy the subvariables for that variable.
+
+ 2. Points-to and escape analysis.
+
+ This phase walks the use-def chains in the SSA web looking for
+ three things:
+
+ * Assignments of the form `P_i = &VAR'
+
+ * Assignments of the form P_i = malloc()
+
+ * Pointers and ADDR_EXPR that escape the current function.
+
+ The concept of `escaping' is the same one used in the Java world.
+ When a pointer or an ADDR_EXPR escapes, it means that it has been
+ exposed outside of the current function. So, assignment to global
+ variables, function arguments and returning a pointer are all
+ escape sites.
+
+ This is where we are currently limited. Since not everything is
+ renamed into SSA, we lose track of escape properties when a
+ pointer is stashed inside a field in a structure, for instance.
+ In those cases, we are assuming that the pointer does escape.
+
+ We use escape analysis to determine whether a variable is
+ call-clobbered. Simply put, if an ADDR_EXPR escapes, then the
+ variable is call-clobbered. If a pointer P_i escapes, then all
+ the variables pointed-to by P_i (and its memory tag) also escape.
+
+ 3. Compute flow-sensitive aliases
+
+ We have two classes of memory tags. Memory tags associated with
+ the pointed-to data type of the pointers in the program. These
+ tags are called "symbol memory tag" (SMT). The other class are
+ those associated with SSA_NAMEs, called "name memory tag" (NMT).
+ The basic idea is that when adding operands for an INDIRECT_REF
+ *P_i, we will first check whether P_i has a name tag, if it does
+ we use it, because that will have more precise aliasing
+ information. Otherwise, we use the standard symbol tag.
+
+ In this phase, we go through all the pointers we found in
+ points-to analysis and create alias sets for the name memory tags
+ associated with each pointer P_i. If P_i escapes, we mark
+ call-clobbered the variables it points to and its tag.
+
+ 4. Compute flow-insensitive aliases
+
+ This pass will compare the alias set of every symbol memory tag and
+ every addressable variable found in the program. Given a symbol
+ memory tag SMT and an addressable variable V. If the alias sets
+ of SMT and V conflict (as computed by may_alias_p), then V is
+ marked as an alias tag and added to the alias set of SMT.
+
+ Every language that wishes to perform language-specific alias
+ analysis should define a function that computes, given a `tree'
+ node, an alias set for the node. Nodes in different alias sets
+ are not allowed to alias. For an example, see the C front-end
+ function `c_get_alias_set'.
+
+ For instance, consider the following function:
+
+ foo (int i)
+ {
+ int *p, *q, a, b;
+
+ if (i > 10)
+ p = &a;
+ else
+ q = &b;
+
+ *p = 3;
+ *q = 5;
+ a = b + 2;
+ return *p;
+ }
+
+ After aliasing analysis has finished, the symbol memory tag for
+pointer `p' will have two aliases, namely variables `a' and `b'. Every
+time pointer `p' is dereferenced, we want to mark the operation as a
+potential reference to `a' and `b'.
+
+ foo (int i)
+ {
+ int *p, a, b;
+
+ if (i_2 > 10)
+ p_4 = &a;
+ else
+ p_6 = &b;
+ # p_1 = PHI <p_4(1), p_6(2)>;
+
+ # a_7 = VDEF <a_3>;
+ # b_8 = VDEF <b_5>;
+ *p_1 = 3;
+
+ # a_9 = VDEF <a_7>
+ # VUSE <b_8>
+ a_9 = b_8 + 2;
+
+ # VUSE <a_9>;
+ # VUSE <b_8>;
+ return *p_1;
+ }
+
+ In certain cases, the list of may aliases for a pointer may grow too
+large. This may cause an explosion in the number of virtual operands
+inserted in the code. Resulting in increased memory consumption and
+compilation time.
+
+ When the number of virtual operands needed to represent aliased loads
+and stores grows too large (configurable with `--param
+max-aliased-vops'), alias sets are grouped to avoid severe compile-time
+slow downs and memory consumption. The alias grouping heuristic
+proceeds as follows:
+
+ 1. Sort the list of pointers in decreasing number of contributed
+ virtual operands.
+
+ 2. Take the first pointer from the list and reverse the role of the
+ memory tag and its aliases. Usually, whenever an aliased variable
+ Vi is found to alias with a memory tag T, we add Vi to the
+ may-aliases set for T. Meaning that after alias analysis, we will
+ have:
+
+ may-aliases(T) = { V1, V2, V3, ..., Vn }
+
+ This means that every statement that references T, will get `n'
+ virtual operands for each of the Vi tags. But, when alias
+ grouping is enabled, we make T an alias tag and add it to the
+ alias set of all the Vi variables:
+
+ may-aliases(V1) = { T }
+ may-aliases(V2) = { T }
+ ...
+ may-aliases(Vn) = { T }
+
+ This has two effects: (a) statements referencing T will only get a
+ single virtual operand, and, (b) all the variables Vi will now
+ appear to alias each other. So, we lose alias precision to
+ improve compile time. But, in theory, a program with such a high
+ level of aliasing should not be very optimizable in the first
+ place.
+
+ 3. Since variables may be in the alias set of more than one memory
+ tag, the grouping done in step (2) needs to be extended to all the
+ memory tags that have a non-empty intersection with the
+ may-aliases set of tag T. For instance, if we originally had
+ these may-aliases sets:
+
+ may-aliases(T) = { V1, V2, V3 }
+ may-aliases(R) = { V2, V4 }
+
+ In step (2) we would have reverted the aliases for T as:
+
+ may-aliases(V1) = { T }
+ may-aliases(V2) = { T }
+ may-aliases(V3) = { T }
+
+ But note that now V2 is no longer aliased with R. We could add R
+ to may-aliases(V2), but we are in the process of grouping aliases
+ to reduce virtual operands so what we do is add V4 to the grouping
+ to obtain:
+
+ may-aliases(V1) = { T }
+ may-aliases(V2) = { T }
+ may-aliases(V3) = { T }
+ may-aliases(V4) = { T }
+
+ 4. If the total number of virtual operands due to aliasing is still
+ above the threshold set by max-alias-vops, go back to (2).
+
+\1f
+File: gccint.info, Node: Loop Analysis and Representation, Next: Machine Desc, Prev: Control Flow, Up: Top
+
+14 Analysis and Representation of Loops
+***************************************
+
+GCC provides extensive infrastructure for work with natural loops, i.e.,
+strongly connected components of CFG with only one entry block. This
+chapter describes representation of loops in GCC, both on GIMPLE and in
+RTL, as well as the interfaces to loop-related analyses (induction
+variable analysis and number of iterations analysis).
+
+* Menu:
+
+* Loop representation:: Representation and analysis of loops.
+* Loop querying:: Getting information about loops.
+* Loop manipulation:: Loop manipulation functions.
+* LCSSA:: Loop-closed SSA form.
+* Scalar evolutions:: Induction variables on GIMPLE.
+* loop-iv:: Induction variables on RTL.
+* Number of iterations:: Number of iterations analysis.
+* Dependency analysis:: Data dependency analysis.
+* Lambda:: Linear loop transformations framework.
+* Omega:: A solver for linear programming problems.
+
+\1f
+File: gccint.info, Node: Loop representation, Next: Loop querying, Up: Loop Analysis and Representation
+
+14.1 Loop representation
+========================
+
+This chapter describes the representation of loops in GCC, and functions
+that can be used to build, modify and analyze this representation. Most
+of the interfaces and data structures are declared in `cfgloop.h'. At
+the moment, loop structures are analyzed and this information is
+updated only by the optimization passes that deal with loops, but some
+efforts are being made to make it available throughout most of the
+optimization passes.
+
+ In general, a natural loop has one entry block (header) and possibly
+several back edges (latches) leading to the header from the inside of
+the loop. Loops with several latches may appear if several loops share
+a single header, or if there is a branching in the middle of the loop.
+The representation of loops in GCC however allows only loops with a
+single latch. During loop analysis, headers of such loops are split and
+forwarder blocks are created in order to disambiguate their structures.
+Heuristic based on profile information and structure of the induction
+variables in the loops is used to determine whether the latches
+correspond to sub-loops or to control flow in a single loop. This means
+that the analysis sometimes changes the CFG, and if you run it in the
+middle of an optimization pass, you must be able to deal with the new
+blocks. You may avoid CFG changes by passing
+`LOOPS_MAY_HAVE_MULTIPLE_LATCHES' flag to the loop discovery, note
+however that most other loop manipulation functions will not work
+correctly for loops with multiple latch edges (the functions that only
+query membership of blocks to loops and subloop relationships, or
+enumerate and test loop exits, can be expected to work).
+
+ Body of the loop is the set of blocks that are dominated by its header,
+and reachable from its latch against the direction of edges in CFG. The
+loops are organized in a containment hierarchy (tree) such that all the
+loops immediately contained inside loop L are the children of L in the
+tree. This tree is represented by the `struct loops' structure. The
+root of this tree is a fake loop that contains all blocks in the
+function. Each of the loops is represented in a `struct loop'
+structure. Each loop is assigned an index (`num' field of the `struct
+loop' structure), and the pointer to the loop is stored in the
+corresponding field of the `larray' vector in the loops structure. The
+indices do not have to be continuous, there may be empty (`NULL')
+entries in the `larray' created by deleting loops. Also, there is no
+guarantee on the relative order of a loop and its subloops in the
+numbering. The index of a loop never changes.
+
+ The entries of the `larray' field should not be accessed directly.
+The function `get_loop' returns the loop description for a loop with
+the given index. `number_of_loops' function returns number of loops in
+the function. To traverse all loops, use `FOR_EACH_LOOP' macro. The
+`flags' argument of the macro is used to determine the direction of
+traversal and the set of loops visited. Each loop is guaranteed to be
+visited exactly once, regardless of the changes to the loop tree, and
+the loops may be removed during the traversal. The newly created loops
+are never traversed, if they need to be visited, this must be done
+separately after their creation. The `FOR_EACH_LOOP' macro allocates
+temporary variables. If the `FOR_EACH_LOOP' loop were ended using
+break or goto, they would not be released; `FOR_EACH_LOOP_BREAK' macro
+must be used instead.
+
+ Each basic block contains the reference to the innermost loop it
+belongs to (`loop_father'). For this reason, it is only possible to
+have one `struct loops' structure initialized at the same time for each
+CFG. The global variable `current_loops' contains the `struct loops'
+structure. Many of the loop manipulation functions assume that
+dominance information is up-to-date.
+
+ The loops are analyzed through `loop_optimizer_init' function. The
+argument of this function is a set of flags represented in an integer
+bitmask. These flags specify what other properties of the loop
+structures should be calculated/enforced and preserved later:
+
+ * `LOOPS_MAY_HAVE_MULTIPLE_LATCHES': If this flag is set, no changes
+ to CFG will be performed in the loop analysis, in particular,
+ loops with multiple latch edges will not be disambiguated. If a
+ loop has multiple latches, its latch block is set to NULL. Most of
+ the loop manipulation functions will not work for loops in this
+ shape. No other flags that require CFG changes can be passed to
+ loop_optimizer_init.
+
+ * `LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a
+ way that each loop has only one entry edge, and additionally, the
+ source block of this entry edge has only one successor. This
+ creates a natural place where the code can be moved out of the
+ loop, and ensures that the entry edge of the loop leads from its
+ immediate super-loop.
+
+ * `LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force
+ the latch block of each loop to have only one successor. This
+ ensures that the latch of the loop does not belong to any of its
+ sub-loops, and makes manipulation with the loops significantly
+ easier. Most of the loop manipulation functions assume that the
+ loops are in this shape. Note that with this flag, the "normal"
+ loop without any control flow inside and with one exit consists of
+ two basic blocks.
+
+ * `LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in
+ the strongly connected components that are not natural loops (have
+ more than one entry block) are marked with `BB_IRREDUCIBLE_LOOP'
+ and `EDGE_IRREDUCIBLE_LOOP' flags. The flag is not set for blocks
+ and edges that belong to natural loops that are in such an
+ irreducible region (but it is set for the entry and exit edges of
+ such a loop, if they lead to/from this region).
+
+ * `LOOPS_HAVE_RECORDED_EXITS': The lists of exits are recorded and
+ updated for each loop. This makes some functions (e.g.,
+ `get_loop_exit_edges') more efficient. Some functions (e.g.,
+ `single_exit') can be used only if the lists of exits are recorded.
+
+ These properties may also be computed/enforced later, using functions
+`create_preheaders', `force_single_succ_latches',
+`mark_irreducible_loops' and `record_loop_exits'.
+
+ The memory occupied by the loops structures should be freed with
+`loop_optimizer_finalize' function.
+
+ The CFG manipulation functions in general do not update loop
+structures. Specialized versions that additionally do so are provided
+for the most common tasks. On GIMPLE, `cleanup_tree_cfg_loop' function
+can be used to cleanup CFG while updating the loops structures if
+`current_loops' is set.
+
+\1f
+File: gccint.info, Node: Loop querying, Next: Loop manipulation, Prev: Loop representation, Up: Loop Analysis and Representation
+
+14.2 Loop querying
+==================
+
+The functions to query the information about loops are declared in
+`cfgloop.h'. Some of the information can be taken directly from the
+structures. `loop_father' field of each basic block contains the
+innermost loop to that the block belongs. The most useful fields of
+loop structure (that are kept up-to-date at all times) are:
+
+ * `header', `latch': Header and latch basic blocks of the loop.
+
+ * `num_nodes': Number of basic blocks in the loop (including the
+ basic blocks of the sub-loops).
+
+ * `depth': The depth of the loop in the loops tree, i.e., the number
+ of super-loops of the loop.
+
+ * `outer', `inner', `next': The super-loop, the first sub-loop, and
+ the sibling of the loop in the loops tree.
+
+ There are other fields in the loop structures, many of them used only
+by some of the passes, or not updated during CFG changes; in general,
+they should not be accessed directly.
+
+ The most important functions to query loop structures are:
+
+ * `flow_loops_dump': Dumps the information about loops to a file.
+
+ * `verify_loop_structure': Checks consistency of the loop structures.
+
+ * `loop_latch_edge': Returns the latch edge of a loop.
+
+ * `loop_preheader_edge': If loops have preheaders, returns the
+ preheader edge of a loop.
+
+ * `flow_loop_nested_p': Tests whether loop is a sub-loop of another
+ loop.
+
+ * `flow_bb_inside_loop_p': Tests whether a basic block belongs to a
+ loop (including its sub-loops).
+
+ * `find_common_loop': Finds the common super-loop of two loops.
+
+ * `superloop_at_depth': Returns the super-loop of a loop with the
+ given depth.
+
+ * `tree_num_loop_insns', `num_loop_insns': Estimates the number of
+ insns in the loop, on GIMPLE and on RTL.
+
+ * `loop_exit_edge_p': Tests whether edge is an exit from a loop.
+
+ * `mark_loop_exit_edges': Marks all exit edges of all loops with
+ `EDGE_LOOP_EXIT' flag.
+
+ * `get_loop_body', `get_loop_body_in_dom_order',
+ `get_loop_body_in_bfs_order': Enumerates the basic blocks in the
+ loop in depth-first search order in reversed CFG, ordered by
+ dominance relation, and breath-first search order, respectively.
+
+ * `single_exit': Returns the single exit edge of the loop, or `NULL'
+ if the loop has more than one exit. You can only use this
+ function if LOOPS_HAVE_MARKED_SINGLE_EXITS property is used.
+
+ * `get_loop_exit_edges': Enumerates the exit edges of a loop.
+
+ * `just_once_each_iteration_p': Returns true if the basic block is
+ executed exactly once during each iteration of a loop (that is, it
+ does not belong to a sub-loop, and it dominates the latch of the
+ loop).
+
+\1f
+File: gccint.info, Node: Loop manipulation, Next: LCSSA, Prev: Loop querying, Up: Loop Analysis and Representation
+
+14.3 Loop manipulation
+======================
+
+The loops tree can be manipulated using the following functions:
+
+ * `flow_loop_tree_node_add': Adds a node to the tree.
+
+ * `flow_loop_tree_node_remove': Removes a node from the tree.
+
+ * `add_bb_to_loop': Adds a basic block to a loop.
+
+ * `remove_bb_from_loops': Removes a basic block from loops.
+
+ Most low-level CFG functions update loops automatically. The following
+functions handle some more complicated cases of CFG manipulations:
+
+ * `remove_path': Removes an edge and all blocks it dominates.
+
+ * `split_loop_exit_edge': Splits exit edge of the loop, ensuring
+ that PHI node arguments remain in the loop (this ensures that
+ loop-closed SSA form is preserved). Only useful on GIMPLE.
+
+ Finally, there are some higher-level loop transformations implemented.
+While some of them are written so that they should work on non-innermost
+loops, they are mostly untested in that case, and at the moment, they
+are only reliable for the innermost loops:
+
+ * `create_iv': Creates a new induction variable. Only works on
+ GIMPLE. `standard_iv_increment_position' can be used to find a
+ suitable place for the iv increment.
+
+ * `duplicate_loop_to_header_edge',
+ `tree_duplicate_loop_to_header_edge': These functions (on RTL and
+ on GIMPLE) duplicate the body of the loop prescribed number of
+ times on one of the edges entering loop header, thus performing
+ either loop unrolling or loop peeling. `can_duplicate_loop_p'
+ (`can_unroll_loop_p' on GIMPLE) must be true for the duplicated
+ loop.
+
+ * `loop_version', `tree_ssa_loop_version': These function create a
+ copy of a loop, and a branch before them that selects one of them
+ depending on the prescribed condition. This is useful for
+ optimizations that need to verify some assumptions in runtime (one
+ of the copies of the loop is usually left unchanged, while the
+ other one is transformed in some way).
+
+ * `tree_unroll_loop': Unrolls the loop, including peeling the extra
+ iterations to make the number of iterations divisible by unroll
+ factor, updating the exit condition, and removing the exits that
+ now cannot be taken. Works only on GIMPLE.
+
+\1f
+File: gccint.info, Node: LCSSA, Next: Scalar evolutions, Prev: Loop manipulation, Up: Loop Analysis and Representation
+
+14.4 Loop-closed SSA form
+=========================
+
+Throughout the loop optimizations on tree level, one extra condition is
+enforced on the SSA form: No SSA name is used outside of the loop in
+that it is defined. The SSA form satisfying this condition is called
+"loop-closed SSA form" - LCSSA. To enforce LCSSA, PHI nodes must be
+created at the exits of the loops for the SSA names that are used
+outside of them. Only the real operands (not virtual SSA names) are
+held in LCSSA, in order to save memory.
+
+ There are various benefits of LCSSA:
+
+ * Many optimizations (value range analysis, final value replacement)
+ are interested in the values that are defined in the loop and used
+ outside of it, i.e., exactly those for that we create new PHI
+ nodes.
+
+ * In induction variable analysis, it is not necessary to specify the
+ loop in that the analysis should be performed - the scalar
+ evolution analysis always returns the results with respect to the
+ loop in that the SSA name is defined.
+
+ * It makes updating of SSA form during loop transformations simpler.
+ Without LCSSA, operations like loop unrolling may force creation
+ of PHI nodes arbitrarily far from the loop, while in LCSSA, the
+ SSA form can be updated locally. However, since we only keep real
+ operands in LCSSA, we cannot use this advantage (we could have
+ local updating of real operands, but it is not much more efficient
+ than to use generic SSA form updating for it as well; the amount
+ of changes to SSA is the same).
+
+ However, it also means LCSSA must be updated. This is usually
+straightforward, unless you create a new value in loop and use it
+outside, or unless you manipulate loop exit edges (functions are
+provided to make these manipulations simple).
+`rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA,
+and `verify_loop_closed_ssa' to check that the invariant of LCSSA is
+preserved.
+
+\1f
+File: gccint.info, Node: Scalar evolutions, Next: loop-iv, Prev: LCSSA, Up: Loop Analysis and Representation
+
+14.5 Scalar evolutions
+======================
+
+Scalar evolutions (SCEV) are used to represent results of induction
+variable analysis on GIMPLE. They enable us to represent variables with
+complicated behavior in a simple and consistent way (we only use it to
+express values of polynomial induction variables, but it is possible to
+extend it). The interfaces to SCEV analysis are declared in
+`tree-scalar-evolution.h'. To use scalar evolutions analysis,
+`scev_initialize' must be used. To stop using SCEV, `scev_finalize'
+should be used. SCEV analysis caches results in order to save time and
+memory. This cache however is made invalid by most of the loop
+transformations, including removal of code. If such a transformation
+is performed, `scev_reset' must be called to clean the caches.
+
+ Given an SSA name, its behavior in loops can be analyzed using the
+`analyze_scalar_evolution' function. The returned SCEV however does
+not have to be fully analyzed and it may contain references to other
+SSA names defined in the loop. To resolve these (potentially
+recursive) references, `instantiate_parameters' or `resolve_mixers'
+functions must be used. `instantiate_parameters' is useful when you
+use the results of SCEV only for some analysis, and when you work with
+whole nest of loops at once. It will try replacing all SSA names by
+their SCEV in all loops, including the super-loops of the current loop,
+thus providing a complete information about the behavior of the
+variable in the loop nest. `resolve_mixers' is useful if you work with
+only one loop at a time, and if you possibly need to create code based
+on the value of the induction variable. It will only resolve the SSA
+names defined in the current loop, leaving the SSA names defined
+outside unchanged, even if their evolution in the outer loops is known.
+
+ The SCEV is a normal tree expression, except for the fact that it may
+contain several special tree nodes. One of them is `SCEV_NOT_KNOWN',
+used for SSA names whose value cannot be expressed. The other one is
+`POLYNOMIAL_CHREC'. Polynomial chrec has three arguments - base, step
+and loop (both base and step may contain further polynomial chrecs).
+Type of the expression and of base and step must be the same. A
+variable has evolution `POLYNOMIAL_CHREC(base, step, loop)' if it is
+(in the specified loop) equivalent to `x_1' in the following example
+
+ while (...)
+ {
+ x_1 = phi (base, x_2);
+ x_2 = x_1 + step;
+ }
+
+ Note that this includes the language restrictions on the operations.
+For example, if we compile C code and `x' has signed type, then the
+overflow in addition would cause undefined behavior, and we may assume
+that this does not happen. Hence, the value with this SCEV cannot
+overflow (which restricts the number of iterations of such a loop).
+
+ In many cases, one wants to restrict the attention just to affine
+induction variables. In this case, the extra expressive power of SCEV
+is not useful, and may complicate the optimizations. In this case,
+`simple_iv' function may be used to analyze a value - the result is a
+loop-invariant base and step.
+
+\1f
+File: gccint.info, Node: loop-iv, Next: Number of iterations, Prev: Scalar evolutions, Up: Loop Analysis and Representation
+
+14.6 IV analysis on RTL
+=======================
+
+The induction variable on RTL is simple and only allows analysis of
+affine induction variables, and only in one loop at once. The interface
+is declared in `cfgloop.h'. Before analyzing induction variables in a
+loop L, `iv_analysis_loop_init' function must be called on L. After
+the analysis (possibly calling `iv_analysis_loop_init' for several
+loops) is finished, `iv_analysis_done' should be called. The following
+functions can be used to access the results of the analysis:
+
+ * `iv_analyze': Analyzes a single register used in the given insn.
+ If no use of the register in this insn is found, the following
+ insns are scanned, so that this function can be called on the insn
+ returned by get_condition.
+
+ * `iv_analyze_result': Analyzes result of the assignment in the
+ given insn.
+
+ * `iv_analyze_expr': Analyzes a more complicated expression. All
+ its operands are analyzed by `iv_analyze', and hence they must be
+ used in the specified insn or one of the following insns.
+
+ The description of the induction variable is provided in `struct
+rtx_iv'. In order to handle subregs, the representation is a bit
+complicated; if the value of the `extend' field is not `UNKNOWN', the
+value of the induction variable in the i-th iteration is
+
+ delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)),
+
+ with the following exception: if `first_special' is true, then the
+value in the first iteration (when `i' is zero) is `delta + mult *
+base'. However, if `extend' is equal to `UNKNOWN', then
+`first_special' must be false, `delta' 0, `mult' 1 and the value in the
+i-th iteration is
+
+ subreg_{mode} (base + i * step)
+
+ The function `get_iv_value' can be used to perform these calculations.
+
+\1f
+File: gccint.info, Node: Number of iterations, Next: Dependency analysis, Prev: loop-iv, Up: Loop Analysis and Representation
+
+14.7 Number of iterations analysis
+==================================
+
+Both on GIMPLE and on RTL, there are functions available to determine
+the number of iterations of a loop, with a similar interface. The
+number of iterations of a loop in GCC is defined as the number of
+executions of the loop latch. In many cases, it is not possible to
+determine the number of iterations unconditionally - the determined
+number is correct only if some assumptions are satisfied. The analysis
+tries to verify these conditions using the information contained in the
+program; if it fails, the conditions are returned together with the
+result. The following information and conditions are provided by the
+analysis:
+
+ * `assumptions': If this condition is false, the rest of the
+ information is invalid.
+
+ * `noloop_assumptions' on RTL, `may_be_zero' on GIMPLE: If this
+ condition is true, the loop exits in the first iteration.
+
+ * `infinite': If this condition is true, the loop is infinite. This
+ condition is only available on RTL. On GIMPLE, conditions for
+ finiteness of the loop are included in `assumptions'.
+
+ * `niter_expr' on RTL, `niter' on GIMPLE: The expression that gives
+ number of iterations. The number of iterations is defined as the
+ number of executions of the loop latch.
+
+ Both on GIMPLE and on RTL, it necessary for the induction variable
+analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL).
+On GIMPLE, the results are stored to `struct tree_niter_desc'
+structure. Number of iterations before the loop is exited through a
+given exit can be determined using `number_of_iterations_exit'
+function. On RTL, the results are returned in `struct niter_desc'
+structure. The corresponding function is named `check_simple_exit'.
+There are also functions that pass through all the exits of a loop and
+try to find one with easy to determine number of iterations -
+`find_loop_niter' on GIMPLE and `find_simple_exit' on RTL. Finally,
+there are functions that provide the same information, but additionally
+cache it, so that repeated calls to number of iterations are not so
+costly - `number_of_latch_executions' on GIMPLE and
+`get_simple_loop_desc' on RTL.
+
+ Note that some of these functions may behave slightly differently than
+others - some of them return only the expression for the number of
+iterations, and fail if there are some assumptions. The function
+`number_of_latch_executions' works only for single-exit loops. The
+function `number_of_cond_exit_executions' can be used to determine
+number of executions of the exit condition of a single-exit loop (i.e.,
+the `number_of_latch_executions' increased by one).
+
+\1f
+File: gccint.info, Node: Dependency analysis, Next: Lambda, Prev: Number of iterations, Up: Loop Analysis and Representation
+
+14.8 Data Dependency Analysis
+=============================
+
+The code for the data dependence analysis can be found in
+`tree-data-ref.c' and its interface and data structures are described
+in `tree-data-ref.h'. The function that computes the data dependences
+for all the array and pointer references for a given loop is
+`compute_data_dependences_for_loop'. This function is currently used
+by the linear loop transform and the vectorization passes. Before
+calling this function, one has to allocate two vectors: a first vector
+will contain the set of data references that are contained in the
+analyzed loop body, and the second vector will contain the dependence
+relations between the data references. Thus if the vector of data
+references is of size `n', the vector containing the dependence
+relations will contain `n*n' elements. However if the analyzed loop
+contains side effects, such as calls that potentially can interfere
+with the data references in the current analyzed loop, the analysis
+stops while scanning the loop body for data references, and inserts a
+single `chrec_dont_know' in the dependence relation array.
+
+ The data references are discovered in a particular order during the
+scanning of the loop body: the loop body is analyzed in execution order,
+and the data references of each statement are pushed at the end of the
+data reference array. Two data references syntactically occur in the
+program in the same order as in the array of data references. This
+syntactic order is important in some classical data dependence tests,
+and mapping this order to the elements of this array avoids costly
+queries to the loop body representation.
+
+ Three types of data references are currently handled: ARRAY_REF,
+INDIRECT_REF and COMPONENT_REF. The data structure for the data
+reference is `data_reference', where `data_reference_p' is a name of a
+pointer to the data reference structure. The structure contains the
+following elements:
+
+ * `base_object_info': Provides information about the base object of
+ the data reference and its access functions. These access functions
+ represent the evolution of the data reference in the loop relative
+ to its base, in keeping with the classical meaning of the data
+ reference access function for the support of arrays. For example,
+ for a reference `a.b[i][j]', the base object is `a.b' and the
+ access functions, one for each array subscript, are: `{i_init, +
+ i_step}_1, {j_init, +, j_step}_2'.
+
+ * `first_location_in_loop': Provides information about the first
+ location accessed by the data reference in the loop and about the
+ access function used to represent evolution relative to this
+ location. This data is used to support pointers, and is not used
+ for arrays (for which we have base objects). Pointer accesses are
+ represented as a one-dimensional access that starts from the first
+ location accessed in the loop. For example:
+
+ for1 i
+ for2 j
+ *((int *)p + i + j) = a[i][j];
+
+ The access function of the pointer access is `{0, + 4B}_for2'
+ relative to `p + i'. The access functions of the array are
+ `{i_init, + i_step}_for1' and `{j_init, +, j_step}_for2' relative
+ to `a'.
+
+ Usually, the object the pointer refers to is either unknown, or we
+ can't prove that the access is confined to the boundaries of a
+ certain object.
+
+ Two data references can be compared only if at least one of these
+ two representations has all its fields filled for both data
+ references.
+
+ The current strategy for data dependence tests is as follows: If
+ both `a' and `b' are represented as arrays, compare
+ `a.base_object' and `b.base_object'; if they are equal, apply
+ dependence tests (use access functions based on base_objects).
+ Else if both `a' and `b' are represented as pointers, compare
+ `a.first_location' and `b.first_location'; if they are equal,
+ apply dependence tests (use access functions based on first
+ location). However, if `a' and `b' are represented differently,
+ only try to prove that the bases are definitely different.
+
+ * Aliasing information.
+
+ * Alignment information.
+
+ The structure describing the relation between two data references is
+`data_dependence_relation' and the shorter name for a pointer to such a
+structure is `ddr_p'. This structure contains:
+
+ * a pointer to each data reference,
+
+ * a tree node `are_dependent' that is set to `chrec_known' if the
+ analysis has proved that there is no dependence between these two
+ data references, `chrec_dont_know' if the analysis was not able to
+ determine any useful result and potentially there could exist a
+ dependence between these data references, and `are_dependent' is
+ set to `NULL_TREE' if there exist a dependence relation between the
+ data references, and the description of this dependence relation is
+ given in the `subscripts', `dir_vects', and `dist_vects' arrays,
+
+ * a boolean that determines whether the dependence relation can be
+ represented by a classical distance vector,
+
+ * an array `subscripts' that contains a description of each
+ subscript of the data references. Given two array accesses a
+ subscript is the tuple composed of the access functions for a given
+ dimension. For example, given `A[f1][f2][f3]' and
+ `B[g1][g2][g3]', there are three subscripts: `(f1, g1), (f2, g2),
+ (f3, g3)'.
+
+ * two arrays `dir_vects' and `dist_vects' that contain classical
+ representations of the data dependences under the form of
+ direction and distance dependence vectors,
+
+ * an array of loops `loop_nest' that contains the loops to which the
+ distance and direction vectors refer to.
+
+ Several functions for pretty printing the information extracted by the
+data dependence analysis are available: `dump_ddrs' prints with a
+maximum verbosity the details of a data dependence relations array,
+`dump_dist_dir_vectors' prints only the classical distance and
+direction vectors for a data dependence relations array, and
+`dump_data_references' prints the details of the data references
+contained in a data reference array.
+
+\1f
+File: gccint.info, Node: Lambda, Next: Omega, Prev: Dependency analysis, Up: Loop Analysis and Representation
+
+14.9 Linear loop transformations framework
+==========================================
+
+Lambda is a framework that allows transformations of loops using
+non-singular matrix based transformations of the iteration space and
+loop bounds. This allows compositions of skewing, scaling, interchange,
+and reversal transformations. These transformations are often used to
+improve cache behavior or remove inner loop dependencies to allow
+parallelization and vectorization to take place.
+
+ To perform these transformations, Lambda requires that the loopnest be
+converted into a internal form that can be matrix transformed easily.
+To do this conversion, the function `gcc_loopnest_to_lambda_loopnest'
+is provided. If the loop cannot be transformed using lambda, this
+function will return NULL.
+
+ Once a `lambda_loopnest' is obtained from the conversion function, it
+can be transformed by using `lambda_loopnest_transform', which takes a
+transformation matrix to apply. Note that it is up to the caller to
+verify that the transformation matrix is legal to apply to the loop
+(dependence respecting, etc). Lambda simply applies whatever matrix it
+is told to provide. It can be extended to make legal matrices out of
+any non-singular matrix, but this is not currently implemented.
+Legality of a matrix for a given loopnest can be verified using
+`lambda_transform_legal_p'.
+
+ Given a transformed loopnest, conversion back into gcc IR is done by
+`lambda_loopnest_to_gcc_loopnest'. This function will modify the loops
+so that they match the transformed loopnest.
+
+\1f
+File: gccint.info, Node: Omega, Prev: Lambda, Up: Loop Analysis and Representation
+
+14.10 Omega a solver for linear programming problems
+====================================================
+
+The data dependence analysis contains several solvers triggered
+sequentially from the less complex ones to the more sophisticated. For
+ensuring the consistency of the results of these solvers, a data
+dependence check pass has been implemented based on two different
+solvers. The second method that has been integrated to GCC is based on
+the Omega dependence solver, written in the 1990's by William Pugh and
+David Wonnacott. Data dependence tests can be formulated using a
+subset of the Presburger arithmetics that can be translated to linear
+constraint systems. These linear constraint systems can then be solved
+using the Omega solver.
+
+ The Omega solver is using Fourier-Motzkin's algorithm for variable
+elimination: a linear constraint system containing `n' variables is
+reduced to a linear constraint system with `n-1' variables. The Omega
+solver can also be used for solving other problems that can be
+expressed under the form of a system of linear equalities and
+inequalities. The Omega solver is known to have an exponential worst
+case, also known under the name of "omega nightmare" in the literature,
+but in practice, the omega test is known to be efficient for the common
+data dependence tests.
+
+ The interface used by the Omega solver for describing the linear
+programming problems is described in `omega.h', and the solver is
+`omega_solve_problem'.
+
+\1f
+File: gccint.info, Node: Control Flow, Next: Loop Analysis and Representation, Prev: RTL, Up: Top
+
+15 Control Flow Graph
+*********************
+
+A control flow graph (CFG) is a data structure built on top of the
+intermediate code representation (the RTL or `tree' instruction stream)
+abstracting the control flow behavior of a function that is being
+compiled. The CFG is a directed graph where the vertices represent
+basic blocks and edges represent possible transfer of control flow from
+one basic block to another. The data structures used to represent the
+control flow graph are defined in `basic-block.h'.
+
+* Menu:
+
+* Basic Blocks:: The definition and representation of basic blocks.
+* Edges:: Types of edges and their representation.
+* Profile information:: Representation of frequencies and probabilities.
+* Maintaining the CFG:: Keeping the control flow graph and up to date.
+* Liveness information:: Using and maintaining liveness information.
+
+\1f
+File: gccint.info, Node: Basic Blocks, Next: Edges, Up: Control Flow
+
+15.1 Basic Blocks
+=================
+
+A basic block is a straight-line sequence of code with only one entry
+point and only one exit. In GCC, basic blocks are represented using
+the `basic_block' data type.
+
+ Two pointer members of the `basic_block' structure are the pointers
+`next_bb' and `prev_bb'. These are used to keep doubly linked chain of
+basic blocks in the same order as the underlying instruction stream.
+The chain of basic blocks is updated transparently by the provided API
+for manipulating the CFG. The macro `FOR_EACH_BB' can be used to visit
+all the basic blocks in lexicographical order. Dominator traversals
+are also possible using `walk_dominator_tree'. Given two basic blocks
+A and B, block A dominates block B if A is _always_ executed before B.
+
+ The `BASIC_BLOCK' array contains all basic blocks in an unspecified
+order. Each `basic_block' structure has a field that holds a unique
+integer identifier `index' that is the index of the block in the
+`BASIC_BLOCK' array. The total number of basic blocks in the function
+is `n_basic_blocks'. Both the basic block indices and the total number
+of basic blocks may vary during the compilation process, as passes
+reorder, create, duplicate, and destroy basic blocks. The index for
+any block should never be greater than `last_basic_block'.
+
+ Special basic blocks represent possible entry and exit points of a
+function. These blocks are called `ENTRY_BLOCK_PTR' and
+`EXIT_BLOCK_PTR'. These blocks do not contain any code, and are not
+elements of the `BASIC_BLOCK' array. Therefore they have been assigned
+unique, negative index numbers.
+
+ Each `basic_block' also contains pointers to the first instruction
+(the "head") and the last instruction (the "tail") or "end" of the
+instruction stream contained in a basic block. In fact, since the
+`basic_block' data type is used to represent blocks in both major
+intermediate representations of GCC (`tree' and RTL), there are
+pointers to the head and end of a basic block for both representations.
+
+ For RTL, these pointers are `rtx head, end'. In the RTL function
+representation, the head pointer always points either to a
+`NOTE_INSN_BASIC_BLOCK' or to a `CODE_LABEL', if present. In the RTL
+representation of a function, the instruction stream contains not only
+the "real" instructions, but also "notes". Any function that moves or
+duplicates the basic blocks needs to take care of updating of these
+notes. Many of these notes expect that the instruction stream consists
+of linear regions, making such updates difficult. The
+`NOTE_INSN_BASIC_BLOCK' note is the only kind of note that may appear
+in the instruction stream contained in a basic block. The instruction
+stream of a basic block always follows a `NOTE_INSN_BASIC_BLOCK', but
+zero or more `CODE_LABEL' nodes can precede the block note. A basic
+block ends by control flow instruction or last instruction before
+following `CODE_LABEL' or `NOTE_INSN_BASIC_BLOCK'. A `CODE_LABEL'
+cannot appear in the instruction stream of a basic block.
+
+ In addition to notes, the jump table vectors are also represented as
+"pseudo-instructions" inside the insn stream. These vectors never
+appear in the basic block and should always be placed just after the
+table jump instructions referencing them. After removing the
+table-jump it is often difficult to eliminate the code computing the
+address and referencing the vector, so cleaning up these vectors is
+postponed until after liveness analysis. Thus the jump table vectors
+may appear in the insn stream unreferenced and without any purpose.
+Before any edge is made "fall-thru", the existence of such construct in
+the way needs to be checked by calling `can_fallthru' function.
+
+ For the `tree' representation, the head and end of the basic block are
+being pointed to by the `stmt_list' field, but this special `tree'
+should never be referenced directly. Instead, at the tree level
+abstract containers and iterators are used to access statements and
+expressions in basic blocks. These iterators are called "block
+statement iterators" (BSIs). Grep for `^bsi' in the various `tree-*'
+files. The following snippet will pretty-print all the statements of
+the program in the GIMPLE representation.
+
+ FOR_EACH_BB (bb)
+ {
+ block_stmt_iterator si;
+
+ for (si = bsi_start (bb); !bsi_end_p (si); bsi_next (&si))
+ {
+ tree stmt = bsi_stmt (si);
+ print_generic_stmt (stderr, stmt, 0);
+ }
+ }
+
+\1f
+File: gccint.info, Node: Edges, Next: Profile information, Prev: Basic Blocks, Up: Control Flow
+
+15.2 Edges
+==========
+
+Edges represent possible control flow transfers from the end of some
+basic block A to the head of another basic block B. We say that A is a
+predecessor of B, and B is a successor of A. Edges are represented in
+GCC with the `edge' data type. Each `edge' acts as a link between two
+basic blocks: the `src' member of an edge points to the predecessor
+basic block of the `dest' basic block. The members `preds' and `succs'
+of the `basic_block' data type point to type-safe vectors of edges to
+the predecessors and successors of the block.
+
+ When walking the edges in an edge vector, "edge iterators" should be
+used. Edge iterators are constructed using the `edge_iterator' data
+structure and several methods are available to operate on them:
+
+`ei_start'
+ This function initializes an `edge_iterator' that points to the
+ first edge in a vector of edges.
+
+`ei_last'
+ This function initializes an `edge_iterator' that points to the
+ last edge in a vector of edges.
+
+`ei_end_p'
+ This predicate is `true' if an `edge_iterator' represents the last
+ edge in an edge vector.
+
+`ei_one_before_end_p'
+ This predicate is `true' if an `edge_iterator' represents the
+ second last edge in an edge vector.
+
+`ei_next'
+ This function takes a pointer to an `edge_iterator' and makes it
+ point to the next edge in the sequence.
+
+`ei_prev'
+ This function takes a pointer to an `edge_iterator' and makes it
+ point to the previous edge in the sequence.
+
+`ei_edge'
+ This function returns the `edge' currently pointed to by an
+ `edge_iterator'.
+
+`ei_safe_safe'
+ This function returns the `edge' currently pointed to by an
+ `edge_iterator', but returns `NULL' if the iterator is pointing at
+ the end of the sequence. This function has been provided for
+ existing code makes the assumption that a `NULL' edge indicates
+ the end of the sequence.
+
+
+ The convenience macro `FOR_EACH_EDGE' can be used to visit all of the
+edges in a sequence of predecessor or successor edges. It must not be
+used when an element might be removed during the traversal, otherwise
+elements will be missed. Here is an example of how to use the macro:
+
+ edge e;
+ edge_iterator ei;
+
+ FOR_EACH_EDGE (e, ei, bb->succs)
+ {
+ if (e->flags & EDGE_FALLTHRU)
+ break;
+ }
+
+ There are various reasons why control flow may transfer from one block
+to another. One possibility is that some instruction, for example a
+`CODE_LABEL', in a linearized instruction stream just always starts a
+new basic block. In this case a "fall-thru" edge links the basic block
+to the first following basic block. But there are several other
+reasons why edges may be created. The `flags' field of the `edge' data
+type is used to store information about the type of edge we are dealing
+with. Each edge is of one of the following types:
+
+_jump_
+ No type flags are set for edges corresponding to jump instructions.
+ These edges are used for unconditional or conditional jumps and in
+ RTL also for table jumps. They are the easiest to manipulate as
+ they may be freely redirected when the flow graph is not in SSA
+ form.
+
+_fall-thru_
+ Fall-thru edges are present in case where the basic block may
+ continue execution to the following one without branching. These
+ edges have the `EDGE_FALLTHRU' flag set. Unlike other types of
+ edges, these edges must come into the basic block immediately
+ following in the instruction stream. The function
+ `force_nonfallthru' is available to insert an unconditional jump
+ in the case that redirection is needed. Note that this may
+ require creation of a new basic block.
+
+_exception handling_
+ Exception handling edges represent possible control transfers from
+ a trapping instruction to an exception handler. The definition of
+ "trapping" varies. In C++, only function calls can throw, but for
+ Java, exceptions like division by zero or segmentation fault are
+ defined and thus each instruction possibly throwing this kind of
+ exception needs to be handled as control flow instruction.
+ Exception edges have the `EDGE_ABNORMAL' and `EDGE_EH' flags set.
+
+ When updating the instruction stream it is easy to change possibly
+ trapping instruction to non-trapping, by simply removing the
+ exception edge. The opposite conversion is difficult, but should
+ not happen anyway. The edges can be eliminated via
+ `purge_dead_edges' call.
+
+ In the RTL representation, the destination of an exception edge is
+ specified by `REG_EH_REGION' note attached to the insn. In case
+ of a trapping call the `EDGE_ABNORMAL_CALL' flag is set too. In
+ the `tree' representation, this extra flag is not set.
+
+ In the RTL representation, the predicate `may_trap_p' may be used
+ to check whether instruction still may trap or not. For the tree
+ representation, the `tree_could_trap_p' predicate is available,
+ but this predicate only checks for possible memory traps, as in
+ dereferencing an invalid pointer location.
+
+_sibling calls_
+ Sibling calls or tail calls terminate the function in a
+ non-standard way and thus an edge to the exit must be present.
+ `EDGE_SIBCALL' and `EDGE_ABNORMAL' are set in such case. These
+ edges only exist in the RTL representation.
+
+_computed jumps_
+ Computed jumps contain edges to all labels in the function
+ referenced from the code. All those edges have `EDGE_ABNORMAL'
+ flag set. The edges used to represent computed jumps often cause
+ compile time performance problems, since functions consisting of
+ many taken labels and many computed jumps may have _very_ dense
+ flow graphs, so these edges need to be handled with special care.
+ During the earlier stages of the compilation process, GCC tries to
+ avoid such dense flow graphs by factoring computed jumps. For
+ example, given the following series of jumps,
+
+ goto *x;
+ [ ... ]
+
+ goto *x;
+ [ ... ]
+
+ goto *x;
+ [ ... ]
+
+ factoring the computed jumps results in the following code sequence
+ which has a much simpler flow graph:
+
+ goto y;
+ [ ... ]
+
+ goto y;
+ [ ... ]
+
+ goto y;
+ [ ... ]
+
+ y:
+ goto *x;
+
+ However, the classic problem with this transformation is that it
+ has a runtime cost in there resulting code: An extra jump.
+ Therefore, the computed jumps are un-factored in the later passes
+ of the compiler. Be aware of that when you work on passes in that
+ area. There have been numerous examples already where the compile
+ time for code with unfactored computed jumps caused some serious
+ headaches.
+
+_nonlocal goto handlers_
+ GCC allows nested functions to return into caller using a `goto'
+ to a label passed to as an argument to the callee. The labels
+ passed to nested functions contain special code to cleanup after
+ function call. Such sections of code are referred to as "nonlocal
+ goto receivers". If a function contains such nonlocal goto
+ receivers, an edge from the call to the label is created with the
+ `EDGE_ABNORMAL' and `EDGE_ABNORMAL_CALL' flags set.
+
+_function entry points_
+ By definition, execution of function starts at basic block 0, so
+ there is always an edge from the `ENTRY_BLOCK_PTR' to basic block
+ 0. There is no `tree' representation for alternate entry points at
+ this moment. In RTL, alternate entry points are specified by
+ `CODE_LABEL' with `LABEL_ALTERNATE_NAME' defined. This feature is
+ currently used for multiple entry point prologues and is limited
+ to post-reload passes only. This can be used by back-ends to emit
+ alternate prologues for functions called from different contexts.
+ In future full support for multiple entry functions defined by
+ Fortran 90 needs to be implemented.
+
+_function exits_
+ In the pre-reload representation a function terminates after the
+ last instruction in the insn chain and no explicit return
+ instructions are used. This corresponds to the fall-thru edge
+ into exit block. After reload, optimal RTL epilogues are used
+ that use explicit (conditional) return instructions that are
+ represented by edges with no flags set.
+
+
+\1f
+File: gccint.info, Node: Profile information, Next: Maintaining the CFG, Prev: Edges, Up: Control Flow
+
+15.3 Profile information
+========================
+
+In many cases a compiler must make a choice whether to trade speed in
+one part of code for speed in another, or to trade code size for code
+speed. In such cases it is useful to know information about how often
+some given block will be executed. That is the purpose for maintaining
+profile within the flow graph. GCC can handle profile information
+obtained through "profile feedback", but it can also estimate branch
+probabilities based on statics and heuristics.
+
+ The feedback based profile is produced by compiling the program with
+instrumentation, executing it on a train run and reading the numbers of
+executions of basic blocks and edges back to the compiler while
+re-compiling the program to produce the final executable. This method
+provides very accurate information about where a program spends most of
+its time on the train run. Whether it matches the average run of
+course depends on the choice of train data set, but several studies
+have shown that the behavior of a program usually changes just
+marginally over different data sets.
+
+ When profile feedback is not available, the compiler may be asked to
+attempt to predict the behavior of each branch in the program using a
+set of heuristics (see `predict.def' for details) and compute estimated
+frequencies of each basic block by propagating the probabilities over
+the graph.
+
+ Each `basic_block' contains two integer fields to represent profile
+information: `frequency' and `count'. The `frequency' is an estimation
+how often is basic block executed within a function. It is represented
+as an integer scaled in the range from 0 to `BB_FREQ_BASE'. The most
+frequently executed basic block in function is initially set to
+`BB_FREQ_BASE' and the rest of frequencies are scaled accordingly.
+During optimization, the frequency of the most frequent basic block can
+both decrease (for instance by loop unrolling) or grow (for instance by
+cross-jumping optimization), so scaling sometimes has to be performed
+multiple times.
+
+ The `count' contains hard-counted numbers of execution measured during
+training runs and is nonzero only when profile feedback is available.
+This value is represented as the host's widest integer (typically a 64
+bit integer) of the special type `gcov_type'.
+
+ Most optimization passes can use only the frequency information of a
+basic block, but a few passes may want to know hard execution counts.
+The frequencies should always match the counts after scaling, however
+during updating of the profile information numerical error may
+accumulate into quite large errors.
+
+ Each edge also contains a branch probability field: an integer in the
+range from 0 to `REG_BR_PROB_BASE'. It represents probability of
+passing control from the end of the `src' basic block to the `dest'
+basic block, i.e. the probability that control will flow along this
+edge. The `EDGE_FREQUENCY' macro is available to compute how
+frequently a given edge is taken. There is a `count' field for each
+edge as well, representing same information as for a basic block.
+
+ The basic block frequencies are not represented in the instruction
+stream, but in the RTL representation the edge frequencies are
+represented for conditional jumps (via the `REG_BR_PROB' macro) since
+they are used when instructions are output to the assembly file and the
+flow graph is no longer maintained.
+
+ The probability that control flow arrives via a given edge to its
+destination basic block is called "reverse probability" and is not
+directly represented, but it may be easily computed from frequencies of
+basic blocks.
+
+ Updating profile information is a delicate task that can unfortunately
+not be easily integrated with the CFG manipulation API. Many of the
+functions and hooks to modify the CFG, such as
+`redirect_edge_and_branch', do not have enough information to easily
+update the profile, so updating it is in the majority of cases left up
+to the caller. It is difficult to uncover bugs in the profile updating
+code, because they manifest themselves only by producing worse code,
+and checking profile consistency is not possible because of numeric
+error accumulation. Hence special attention needs to be given to this
+issue in each pass that modifies the CFG.
+
+ It is important to point out that `REG_BR_PROB_BASE' and
+`BB_FREQ_BASE' are both set low enough to be possible to compute second
+power of any frequency or probability in the flow graph, it is not
+possible to even square the `count' field, as modern CPUs are fast
+enough to execute $2^32$ operations quickly.
+
+\1f
+File: gccint.info, Node: Maintaining the CFG, Next: Liveness information, Prev: Profile information, Up: Control Flow
+
+15.4 Maintaining the CFG
+========================
+
+An important task of each compiler pass is to keep both the control
+flow graph and all profile information up-to-date. Reconstruction of
+the control flow graph after each pass is not an option, since it may be
+very expensive and lost profile information cannot be reconstructed at
+all.
+
+ GCC has two major intermediate representations, and both use the
+`basic_block' and `edge' data types to represent control flow. Both
+representations share as much of the CFG maintenance code as possible.
+For each representation, a set of "hooks" is defined so that each
+representation can provide its own implementation of CFG manipulation
+routines when necessary. These hooks are defined in `cfghooks.h'.
+There are hooks for almost all common CFG manipulations, including
+block splitting and merging, edge redirection and creating and deleting
+basic blocks. These hooks should provide everything you need to
+maintain and manipulate the CFG in both the RTL and `tree'
+representation.
+
+ At the moment, the basic block boundaries are maintained transparently
+when modifying instructions, so there rarely is a need to move them
+manually (such as in case someone wants to output instruction outside
+basic block explicitly). Often the CFG may be better viewed as
+integral part of instruction chain, than structure built on the top of
+it. However, in principle the control flow graph for the `tree'
+representation is _not_ an integral part of the representation, in that
+a function tree may be expanded without first building a flow graph
+for the `tree' representation at all. This happens when compiling
+without any `tree' optimization enabled. When the `tree' optimizations
+are enabled and the instruction stream is rewritten in SSA form, the
+CFG is very tightly coupled with the instruction stream. In
+particular, statement insertion and removal has to be done with care.
+In fact, the whole `tree' representation can not be easily used or
+maintained without proper maintenance of the CFG simultaneously.
+
+ In the RTL representation, each instruction has a `BLOCK_FOR_INSN'
+value that represents pointer to the basic block that contains the
+instruction. In the `tree' representation, the function `bb_for_stmt'
+returns a pointer to the basic block containing the queried statement.
+
+ When changes need to be applied to a function in its `tree'
+representation, "block statement iterators" should be used. These
+iterators provide an integrated abstraction of the flow graph and the
+instruction stream. Block statement iterators are constructed using
+the `block_stmt_iterator' data structure and several modifier are
+available, including the following:
+
+`bsi_start'
+ This function initializes a `block_stmt_iterator' that points to
+ the first non-empty statement in a basic block.
+
+`bsi_last'
+ This function initializes a `block_stmt_iterator' that points to
+ the last statement in a basic block.
+
+`bsi_end_p'
+ This predicate is `true' if a `block_stmt_iterator' represents the
+ end of a basic block.
+
+`bsi_next'
+ This function takes a `block_stmt_iterator' and makes it point to
+ its successor.
+
+`bsi_prev'
+ This function takes a `block_stmt_iterator' and makes it point to
+ its predecessor.
+
+`bsi_insert_after'
+ This function inserts a statement after the `block_stmt_iterator'
+ passed in. The final parameter determines whether the statement
+ iterator is updated to point to the newly inserted statement, or
+ left pointing to the original statement.
+
+`bsi_insert_before'
+ This function inserts a statement before the `block_stmt_iterator'
+ passed in. The final parameter determines whether the statement
+ iterator is updated to point to the newly inserted statement, or
+ left pointing to the original statement.
+
+`bsi_remove'
+ This function removes the `block_stmt_iterator' passed in and
+ rechains the remaining statements in a basic block, if any.
+
+ In the RTL representation, the macros `BB_HEAD' and `BB_END' may be
+used to get the head and end `rtx' of a basic block. No abstract
+iterators are defined for traversing the insn chain, but you can just
+use `NEXT_INSN' and `PREV_INSN' instead. See *Note Insns::.
+
+ Usually a code manipulating pass simplifies the instruction stream and
+the flow of control, possibly eliminating some edges. This may for
+example happen when a conditional jump is replaced with an
+unconditional jump, but also when simplifying possibly trapping
+instruction to non-trapping while compiling Java. Updating of edges is
+not transparent and each optimization pass is required to do so
+manually. However only few cases occur in practice. The pass may call
+`purge_dead_edges' on a given basic block to remove superfluous edges,
+if any.
+
+ Another common scenario is redirection of branch instructions, but
+this is best modeled as redirection of edges in the control flow graph
+and thus use of `redirect_edge_and_branch' is preferred over more low
+level functions, such as `redirect_jump' that operate on RTL chain
+only. The CFG hooks defined in `cfghooks.h' should provide the
+complete API required for manipulating and maintaining the CFG.
+
+ It is also possible that a pass has to insert control flow instruction
+into the middle of a basic block, thus creating an entry point in the
+middle of the basic block, which is impossible by definition: The block
+must be split to make sure it only has one entry point, i.e. the head
+of the basic block. The CFG hook `split_block' may be used when an
+instruction in the middle of a basic block has to become the target of
+a jump or branch instruction.
+
+ For a global optimizer, a common operation is to split edges in the
+flow graph and insert instructions on them. In the RTL representation,
+this can be easily done using the `insert_insn_on_edge' function that
+emits an instruction "on the edge", caching it for a later
+`commit_edge_insertions' call that will take care of moving the
+inserted instructions off the edge into the instruction stream
+contained in a basic block. This includes the creation of new basic
+blocks where needed. In the `tree' representation, the equivalent
+functions are `bsi_insert_on_edge' which inserts a block statement
+iterator on an edge, and `bsi_commit_edge_inserts' which flushes the
+instruction to actual instruction stream.
+
+ While debugging the optimization pass, an `verify_flow_info' function
+may be useful to find bugs in the control flow graph updating code.
+
+ Note that at present, the representation of control flow in the `tree'
+representation is discarded before expanding to RTL. Long term the CFG
+should be maintained and "expanded" to the RTL representation along
+with the function `tree' itself.
+
+\1f
+File: gccint.info, Node: Liveness information, Prev: Maintaining the CFG, Up: Control Flow
+
+15.5 Liveness information
+=========================
+
+Liveness information is useful to determine whether some register is
+"live" at given point of program, i.e. that it contains a value that
+may be used at a later point in the program. This information is used,
+for instance, during register allocation, as the pseudo registers only
+need to be assigned to a unique hard register or to a stack slot if
+they are live. The hard registers and stack slots may be freely reused
+for other values when a register is dead.
+
+ Liveness information is available in the back end starting with
+`pass_df_initialize' and ending with `pass_df_finish'. Three flavors
+of live analysis are available: With `LR', it is possible to determine
+at any point `P' in the function if the register may be used on some
+path from `P' to the end of the function. With `UR', it is possible to
+determine if there is a path from the beginning of the function to `P'
+that defines the variable. `LIVE' is the intersection of the `LR' and
+`UR' and a variable is live at `P' if there is both an assignment that
+reaches it from the beginning of the function and a uses that can be
+reached on some path from `P' to the end of the function.
+
+ In general `LIVE' is the most useful of the three. The macros
+`DF_[LR,UR,LIVE]_[IN,OUT]' can be used to access this information. The
+macros take a basic block number and return a bitmap that is indexed by
+the register number. This information is only guaranteed to be up to
+date after calls are made to `df_analyze'. See the file `df-core.c'
+for details on using the dataflow.
+
+ The liveness information is stored partly in the RTL instruction stream
+and partly in the flow graph. Local information is stored in the
+instruction stream: Each instruction may contain `REG_DEAD' notes
+representing that the value of a given register is no longer needed, or
+`REG_UNUSED' notes representing that the value computed by the
+instruction is never used. The second is useful for instructions
+computing multiple values at once.
+
+\1f
+File: gccint.info, Node: Machine Desc, Next: Target Macros, Prev: Loop Analysis and Representation, Up: Top
+
+16 Machine Descriptions
+***********************
+
+A machine description has two parts: a file of instruction patterns
+(`.md' file) and a C header file of macro definitions.
+
+ The `.md' file for a target machine contains a pattern for each
+instruction that the target machine supports (or at least each
+instruction that is worth telling the compiler about). It may also
+contain comments. A semicolon causes the rest of the line to be a
+comment, unless the semicolon is inside a quoted string.
+
+ See the next chapter for information on the C header file.
+
+* Menu:
+
+* Overview:: How the machine description is used.
+* Patterns:: How to write instruction patterns.
+* Example:: An explained example of a `define_insn' pattern.
+* RTL Template:: The RTL template defines what insns match a pattern.
+* Output Template:: The output template says how to make assembler code
+ from such an insn.
+* Output Statement:: For more generality, write C code to output
+ the assembler code.
+* Predicates:: Controlling what kinds of operands can be used
+ for an insn.
+* Constraints:: Fine-tuning operand selection.
+* Standard Names:: Names mark patterns to use for code generation.
+* Pattern Ordering:: When the order of patterns makes a difference.
+* Dependent Patterns:: Having one pattern may make you need another.
+* Jump Patterns:: Special considerations for patterns for jump insns.
+* Looping Patterns:: How to define patterns for special looping insns.
+* Insn Canonicalizations::Canonicalization of Instructions
+* Expander Definitions::Generating a sequence of several RTL insns
+ for a standard operation.
+* Insn Splitting:: Splitting Instructions into Multiple Instructions.
+* Including Patterns:: Including Patterns in Machine Descriptions.
+* Peephole Definitions::Defining machine-specific peephole optimizations.
+* Insn Attributes:: Specifying the value of attributes for generated insns.
+* Conditional Execution::Generating `define_insn' patterns for
+ predication.
+* Constant Definitions::Defining symbolic constants that can be used in the
+ md file.
+* Iterators:: Using iterators to generate patterns from a template.
+
+\1f
+File: gccint.info, Node: Overview, Next: Patterns, Up: Machine Desc
+
+16.1 Overview of How the Machine Description is Used
+====================================================
+
+There are three main conversions that happen in the compiler:
+
+ 1. The front end reads the source code and builds a parse tree.
+
+ 2. The parse tree is used to generate an RTL insn list based on named
+ instruction patterns.
+
+ 3. The insn list is matched against the RTL templates to produce
+ assembler code.
+
+
+ For the generate pass, only the names of the insns matter, from either
+a named `define_insn' or a `define_expand'. The compiler will choose
+the pattern with the right name and apply the operands according to the
+documentation later in this chapter, without regard for the RTL
+template or operand constraints. Note that the names the compiler looks
+for are hard-coded in the compiler--it will ignore unnamed patterns and
+patterns with names it doesn't know about, but if you don't provide a
+named pattern it needs, it will abort.
+
+ If a `define_insn' is used, the template given is inserted into the
+insn list. If a `define_expand' is used, one of three things happens,
+based on the condition logic. The condition logic may manually create
+new insns for the insn list, say via `emit_insn()', and invoke `DONE'.
+For certain named patterns, it may invoke `FAIL' to tell the compiler
+to use an alternate way of performing that task. If it invokes neither
+`DONE' nor `FAIL', the template given in the pattern is inserted, as if
+the `define_expand' were a `define_insn'.
+
+ Once the insn list is generated, various optimization passes convert,
+replace, and rearrange the insns in the insn list. This is where the
+`define_split' and `define_peephole' patterns get used, for example.
+
+ Finally, the insn list's RTL is matched up with the RTL templates in
+the `define_insn' patterns, and those patterns are used to emit the
+final assembly code. For this purpose, each named `define_insn' acts
+like it's unnamed, since the names are ignored.
+
+\1f
+File: gccint.info, Node: Patterns, Next: Example, Prev: Overview, Up: Machine Desc
+
+16.2 Everything about Instruction Patterns
+==========================================
+
+Each instruction pattern contains an incomplete RTL expression, with
+pieces to be filled in later, operand constraints that restrict how the
+pieces can be filled in, and an output pattern or C code to generate
+the assembler output, all wrapped up in a `define_insn' expression.
+
+ A `define_insn' is an RTL expression containing four or five operands:
+
+ 1. An optional name. The presence of a name indicate that this
+ instruction pattern can perform a certain standard job for the
+ RTL-generation pass of the compiler. This pass knows certain
+ names and will use the instruction patterns with those names, if
+ the names are defined in the machine description.
+
+ The absence of a name is indicated by writing an empty string
+ where the name should go. Nameless instruction patterns are never
+ used for generating RTL code, but they may permit several simpler
+ insns to be combined later on.
+
+ Names that are not thus known and used in RTL-generation have no
+ effect; they are equivalent to no name at all.
+
+ For the purpose of debugging the compiler, you may also specify a
+ name beginning with the `*' character. Such a name is used only
+ for identifying the instruction in RTL dumps; it is entirely
+ equivalent to having a nameless pattern for all other purposes.
+
+ 2. The "RTL template" (*note RTL Template::) is a vector of incomplete
+ RTL expressions which show what the instruction should look like.
+ It is incomplete because it may contain `match_operand',
+ `match_operator', and `match_dup' expressions that stand for
+ operands of the instruction.
+
+ If the vector has only one element, that element is the template
+ for the instruction pattern. If the vector has multiple elements,
+ then the instruction pattern is a `parallel' expression containing
+ the elements described.
+
+ 3. A condition. This is a string which contains a C expression that
+ is the final test to decide whether an insn body matches this
+ pattern.
+
+ For a named pattern, the condition (if present) may not depend on
+ the data in the insn being matched, but only the
+ target-machine-type flags. The compiler needs to test these
+ conditions during initialization in order to learn exactly which
+ named instructions are available in a particular run.
+
+ For nameless patterns, the condition is applied only when matching
+ an individual insn, and only after the insn has matched the
+ pattern's recognition template. The insn's operands may be found
+ in the vector `operands'. For an insn where the condition has
+ once matched, it can't be used to control register allocation, for
+ example by excluding certain hard registers or hard register
+ combinations.
+
+ 4. The "output template": a string that says how to output matching
+ insns as assembler code. `%' in this string specifies where to
+ substitute the value of an operand. *Note Output Template::.
+
+ When simple substitution isn't general enough, you can specify a
+ piece of C code to compute the output. *Note Output Statement::.
+
+ 5. Optionally, a vector containing the values of attributes for insns
+ matching this pattern. *Note Insn Attributes::.
+
+\1f
+File: gccint.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc
+
+16.3 Example of `define_insn'
+=============================
+
+Here is an actual example of an instruction pattern, for the
+68000/68020.
+
+ (define_insn "tstsi"
+ [(set (cc0)
+ (match_operand:SI 0 "general_operand" "rm"))]
+ ""
+ "*
+ {
+ if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
+ return \"tstl %0\";
+ return \"cmpl #0,%0\";
+ }")
+
+This can also be written using braced strings:
+
+ (define_insn "tstsi"
+ [(set (cc0)
+ (match_operand:SI 0 "general_operand" "rm"))]
+ ""
+ {
+ if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
+ return "tstl %0";
+ return "cmpl #0,%0";
+ })
+
+ This is an instruction that sets the condition codes based on the
+value of a general operand. It has no condition, so any insn whose RTL
+description has the form shown may be handled according to this
+pattern. The name `tstsi' means "test a `SImode' value" and tells the
+RTL generation pass that, when it is necessary to test such a value, an
+insn to do so can be constructed using this pattern.
+
+ The output control string is a piece of C code which chooses which
+output template to return based on the kind of operand and the specific
+type of CPU for which code is being generated.
+
+ `"rm"' is an operand constraint. Its meaning is explained below.
+
+\1f
+File: gccint.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc
+
+16.4 RTL Template
+=================
+
+The RTL template is used to define which insns match the particular
+pattern and how to find their operands. For named patterns, the RTL
+template also says how to construct an insn from specified operands.
+
+ Construction involves substituting specified operands into a copy of
+the template. Matching involves determining the values that serve as
+the operands in the insn being matched. Both of these activities are
+controlled by special expression types that direct matching and
+substitution of the operands.
+
+`(match_operand:M N PREDICATE CONSTRAINT)'
+ This expression is a placeholder for operand number N of the insn.
+ When constructing an insn, operand number N will be substituted at
+ this point. When matching an insn, whatever appears at this
+ position in the insn will be taken as operand number N; but it
+ must satisfy PREDICATE or this instruction pattern will not match
+ at all.
+
+ Operand numbers must be chosen consecutively counting from zero in
+ each instruction pattern. There may be only one `match_operand'
+ expression in the pattern for each operand number. Usually
+ operands are numbered in the order of appearance in `match_operand'
+ expressions. In the case of a `define_expand', any operand numbers
+ used only in `match_dup' expressions have higher values than all
+ other operand numbers.
+
+ PREDICATE is a string that is the name of a function that accepts
+ two arguments, an expression and a machine mode. *Note
+ Predicates::. During matching, the function will be called with
+ the putative operand as the expression and M as the mode argument
+ (if M is not specified, `VOIDmode' will be used, which normally
+ causes PREDICATE to accept any mode). If it returns zero, this
+ instruction pattern fails to match. PREDICATE may be an empty
+ string; then it means no test is to be done on the operand, so
+ anything which occurs in this position is valid.
+
+ Most of the time, PREDICATE will reject modes other than M--but
+ not always. For example, the predicate `address_operand' uses M
+ as the mode of memory ref that the address should be valid for.
+ Many predicates accept `const_int' nodes even though their mode is
+ `VOIDmode'.
+
+ CONSTRAINT controls reloading and the choice of the best register
+ class to use for a value, as explained later (*note Constraints::).
+ If the constraint would be an empty string, it can be omitted.
+
+ People are often unclear on the difference between the constraint
+ and the predicate. The predicate helps decide whether a given
+ insn matches the pattern. The constraint plays no role in this
+ decision; instead, it controls various decisions in the case of an
+ insn which does match.
+
+`(match_scratch:M N CONSTRAINT)'
+ This expression is also a placeholder for operand number N and
+ indicates that operand must be a `scratch' or `reg' expression.
+
+ When matching patterns, this is equivalent to
+
+ (match_operand:M N "scratch_operand" PRED)
+
+ but, when generating RTL, it produces a (`scratch':M) expression.
+
+ If the last few expressions in a `parallel' are `clobber'
+ expressions whose operands are either a hard register or
+ `match_scratch', the combiner can add or delete them when
+ necessary. *Note Side Effects::.
+
+`(match_dup N)'
+ This expression is also a placeholder for operand number N. It is
+ used when the operand needs to appear more than once in the insn.
+
+ In construction, `match_dup' acts just like `match_operand': the
+ operand is substituted into the insn being constructed. But in
+ matching, `match_dup' behaves differently. It assumes that operand
+ number N has already been determined by a `match_operand'
+ appearing earlier in the recognition template, and it matches only
+ an identical-looking expression.
+
+ Note that `match_dup' should not be used to tell the compiler that
+ a particular register is being used for two operands (example:
+ `add' that adds one register to another; the second register is
+ both an input operand and the output operand). Use a matching
+ constraint (*note Simple Constraints::) for those. `match_dup' is
+ for the cases where one operand is used in two places in the
+ template, such as an instruction that computes both a quotient and
+ a remainder, where the opcode takes two input operands but the RTL
+ template has to refer to each of those twice; once for the
+ quotient pattern and once for the remainder pattern.
+
+`(match_operator:M N PREDICATE [OPERANDS...])'
+ This pattern is a kind of placeholder for a variable RTL expression
+ code.
+
+ When constructing an insn, it stands for an RTL expression whose
+ expression code is taken from that of operand N, and whose
+ operands are constructed from the patterns OPERANDS.
+
+ When matching an expression, it matches an expression if the
+ function PREDICATE returns nonzero on that expression _and_ the
+ patterns OPERANDS match the operands of the expression.
+
+ Suppose that the function `commutative_operator' is defined as
+ follows, to match any expression whose operator is one of the
+ commutative arithmetic operators of RTL and whose mode is MODE:
+
+ int
+ commutative_integer_operator (x, mode)
+ rtx x;
+ enum machine_mode mode;
+ {
+ enum rtx_code code = GET_CODE (x);
+ if (GET_MODE (x) != mode)
+ return 0;
+ return (GET_RTX_CLASS (code) == RTX_COMM_ARITH
+ || code == EQ || code == NE);
+ }
+
+ Then the following pattern will match any RTL expression consisting
+ of a commutative operator applied to two general operands:
+
+ (match_operator:SI 3 "commutative_operator"
+ [(match_operand:SI 1 "general_operand" "g")
+ (match_operand:SI 2 "general_operand" "g")])
+
+ Here the vector `[OPERANDS...]' contains two patterns because the
+ expressions to be matched all contain two operands.
+
+ When this pattern does match, the two operands of the commutative
+ operator are recorded as operands 1 and 2 of the insn. (This is
+ done by the two instances of `match_operand'.) Operand 3 of the
+ insn will be the entire commutative expression: use `GET_CODE
+ (operands[3])' to see which commutative operator was used.
+
+ The machine mode M of `match_operator' works like that of
+ `match_operand': it is passed as the second argument to the
+ predicate function, and that function is solely responsible for
+ deciding whether the expression to be matched "has" that mode.
+
+ When constructing an insn, argument 3 of the gen-function will
+ specify the operation (i.e. the expression code) for the
+ expression to be made. It should be an RTL expression, whose
+ expression code is copied into a new expression whose operands are
+ arguments 1 and 2 of the gen-function. The subexpressions of
+ argument 3 are not used; only its expression code matters.
+
+ When `match_operator' is used in a pattern for matching an insn,
+ it usually best if the operand number of the `match_operator' is
+ higher than that of the actual operands of the insn. This improves
+ register allocation because the register allocator often looks at
+ operands 1 and 2 of insns to see if it can do register tying.
+
+ There is no way to specify constraints in `match_operator'. The
+ operand of the insn which corresponds to the `match_operator'
+ never has any constraints because it is never reloaded as a whole.
+ However, if parts of its OPERANDS are matched by `match_operand'
+ patterns, those parts may have constraints of their own.
+
+`(match_op_dup:M N[OPERANDS...])'
+ Like `match_dup', except that it applies to operators instead of
+ operands. When constructing an insn, operand number N will be
+ substituted at this point. But in matching, `match_op_dup' behaves
+ differently. It assumes that operand number N has already been
+ determined by a `match_operator' appearing earlier in the
+ recognition template, and it matches only an identical-looking
+ expression.
+
+`(match_parallel N PREDICATE [SUBPAT...])'
+ This pattern is a placeholder for an insn that consists of a
+ `parallel' expression with a variable number of elements. This
+ expression should only appear at the top level of an insn pattern.
+
+ When constructing an insn, operand number N will be substituted at
+ this point. When matching an insn, it matches if the body of the
+ insn is a `parallel' expression with at least as many elements as
+ the vector of SUBPAT expressions in the `match_parallel', if each
+ SUBPAT matches the corresponding element of the `parallel', _and_
+ the function PREDICATE returns nonzero on the `parallel' that is
+ the body of the insn. It is the responsibility of the predicate
+ to validate elements of the `parallel' beyond those listed in the
+ `match_parallel'.
+
+ A typical use of `match_parallel' is to match load and store
+ multiple expressions, which can contain a variable number of
+ elements in a `parallel'. For example,
+
+ (define_insn ""
+ [(match_parallel 0 "load_multiple_operation"
+ [(set (match_operand:SI 1 "gpc_reg_operand" "=r")
+ (match_operand:SI 2 "memory_operand" "m"))
+ (use (reg:SI 179))
+ (clobber (reg:SI 179))])]
+ ""
+ "loadm 0,0,%1,%2")
+
+ This example comes from `a29k.md'. The function
+ `load_multiple_operation' is defined in `a29k.c' and checks that
+ subsequent elements in the `parallel' are the same as the `set' in
+ the pattern, except that they are referencing subsequent registers
+ and memory locations.
+
+ An insn that matches this pattern might look like:
+
+ (parallel
+ [(set (reg:SI 20) (mem:SI (reg:SI 100)))
+ (use (reg:SI 179))
+ (clobber (reg:SI 179))
+ (set (reg:SI 21)
+ (mem:SI (plus:SI (reg:SI 100)
+ (const_int 4))))
+ (set (reg:SI 22)
+ (mem:SI (plus:SI (reg:SI 100)
+ (const_int 8))))])
+
+`(match_par_dup N [SUBPAT...])'
+ Like `match_op_dup', but for `match_parallel' instead of
+ `match_operator'.
+
+
+\1f
+File: gccint.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc
+
+16.5 Output Templates and Operand Substitution
+==============================================
+
+The "output template" is a string which specifies how to output the
+assembler code for an instruction pattern. Most of the template is a
+fixed string which is output literally. The character `%' is used to
+specify where to substitute an operand; it can also be used to identify
+places where different variants of the assembler require different
+syntax.
+
+ In the simplest case, a `%' followed by a digit N says to output
+operand N at that point in the string.
+
+ `%' followed by a letter and a digit says to output an operand in an
+alternate fashion. Four letters have standard, built-in meanings
+described below. The machine description macro `PRINT_OPERAND' can
+define additional letters with nonstandard meanings.
+
+ `%cDIGIT' can be used to substitute an operand that is a constant
+value without the syntax that normally indicates an immediate operand.
+
+ `%nDIGIT' is like `%cDIGIT' except that the value of the constant is
+negated before printing.
+
+ `%aDIGIT' can be used to substitute an operand as if it were a memory
+reference, with the actual operand treated as the address. This may be
+useful when outputting a "load address" instruction, because often the
+assembler syntax for such an instruction requires you to write the
+operand as if it were a memory reference.
+
+ `%lDIGIT' is used to substitute a `label_ref' into a jump instruction.
+
+ `%=' outputs a number which is unique to each instruction in the
+entire compilation. This is useful for making local labels to be
+referred to more than once in a single template that generates multiple
+assembler instructions.
+
+ `%' followed by a punctuation character specifies a substitution that
+does not use an operand. Only one case is standard: `%%' outputs a `%'
+into the assembler code. Other nonstandard cases can be defined in the
+`PRINT_OPERAND' macro. You must also define which punctuation
+characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro.
+
+ The template may generate multiple assembler instructions. Write the
+text for the instructions, with `\;' between them.
+
+ When the RTL contains two operands which are required by constraint to
+match each other, the output template must refer only to the
+lower-numbered operand. Matching operands are not always identical,
+and the rest of the compiler arranges to put the proper RTL expression
+for printing into the lower-numbered operand.
+
+ One use of nonstandard letters or punctuation following `%' is to
+distinguish between different assembler languages for the same machine;
+for example, Motorola syntax versus MIT syntax for the 68000. Motorola
+syntax requires periods in most opcode names, while MIT syntax does
+not. For example, the opcode `movel' in MIT syntax is `move.l' in
+Motorola syntax. The same file of patterns is used for both kinds of
+output syntax, but the character sequence `%.' is used in each place
+where Motorola syntax wants a period. The `PRINT_OPERAND' macro for
+Motorola syntax defines the sequence to output a period; the macro for
+MIT syntax defines it to do nothing.
+
+ As a special case, a template consisting of the single character `#'
+instructs the compiler to first split the insn, and then output the
+resulting instructions separately. This helps eliminate redundancy in
+the output templates. If you have a `define_insn' that needs to emit
+multiple assembler instructions, and there is an matching `define_split'
+already defined, then you can simply use `#' as the output template
+instead of writing an output template that emits the multiple assembler
+instructions.
+
+ If the macro `ASSEMBLER_DIALECT' is defined, you can use construct of
+the form `{option0|option1|option2}' in the templates. These describe
+multiple variants of assembler language syntax. *Note Instruction
+Output::.
+
+\1f
+File: gccint.info, Node: Output Statement, Next: Predicates, Prev: Output Template, Up: Machine Desc
+
+16.6 C Statements for Assembler Output
+======================================
+
+Often a single fixed template string cannot produce correct and
+efficient assembler code for all the cases that are recognized by a
+single instruction pattern. For example, the opcodes may depend on the
+kinds of operands; or some unfortunate combinations of operands may
+require extra machine instructions.
+
+ If the output control string starts with a `@', then it is actually a
+series of templates, each on a separate line. (Blank lines and leading
+spaces and tabs are ignored.) The templates correspond to the
+pattern's constraint alternatives (*note Multi-Alternative::). For
+example, if a target machine has a two-address add instruction `addr'
+to add into a register and another `addm' to add a register to memory,
+you might write this pattern:
+
+ (define_insn "addsi3"
+ [(set (match_operand:SI 0 "general_operand" "=r,m")
+ (plus:SI (match_operand:SI 1 "general_operand" "0,0")
+ (match_operand:SI 2 "general_operand" "g,r")))]
+ ""
+ "@
+ addr %2,%0
+ addm %2,%0")
+
+ If the output control string starts with a `*', then it is not an
+output template but rather a piece of C program that should compute a
+template. It should execute a `return' statement to return the
+template-string you want. Most such templates use C string literals,
+which require doublequote characters to delimit them. To include these
+doublequote characters in the string, prefix each one with `\'.
+
+ If the output control string is written as a brace block instead of a
+double-quoted string, it is automatically assumed to be C code. In that
+case, it is not necessary to put in a leading asterisk, or to escape the
+doublequotes surrounding C string literals.
+
+ The operands may be found in the array `operands', whose C data type
+is `rtx []'.
+
+ It is very common to select different ways of generating assembler code
+based on whether an immediate operand is within a certain range. Be
+careful when doing this, because the result of `INTVAL' is an integer
+on the host machine. If the host machine has more bits in an `int'
+than the target machine has in the mode in which the constant will be
+used, then some of the bits you get from `INTVAL' will be superfluous.
+For proper results, you must carefully disregard the values of those
+bits.
+
+ It is possible to output an assembler instruction and then go on to
+output or compute more of them, using the subroutine `output_asm_insn'.
+This receives two arguments: a template-string and a vector of
+operands. The vector may be `operands', or it may be another array of
+`rtx' that you declare locally and initialize yourself.
+
+ When an insn pattern has multiple alternatives in its constraints,
+often the appearance of the assembler code is determined mostly by
+which alternative was matched. When this is so, the C code can test
+the variable `which_alternative', which is the ordinal number of the
+alternative that was actually satisfied (0 for the first, 1 for the
+second alternative, etc.).
+
+ For example, suppose there are two opcodes for storing zero, `clrreg'
+for registers and `clrmem' for memory locations. Here is how a pattern
+could use `which_alternative' to choose between them:
+
+ (define_insn ""
+ [(set (match_operand:SI 0 "general_operand" "=r,m")
+ (const_int 0))]
+ ""
+ {
+ return (which_alternative == 0
+ ? "clrreg %0" : "clrmem %0");
+ })
+
+ The example above, where the assembler code to generate was _solely_
+determined by the alternative, could also have been specified as
+follows, having the output control string start with a `@':
+
+ (define_insn ""
+ [(set (match_operand:SI 0 "general_operand" "=r,m")
+ (const_int 0))]
+ ""
+ "@
+ clrreg %0
+ clrmem %0")
+
+\1f
+File: gccint.info, Node: Predicates, Next: Constraints, Prev: Output Statement, Up: Machine Desc
+
+16.7 Predicates
+===============
+
+A predicate determines whether a `match_operand' or `match_operator'
+expression matches, and therefore whether the surrounding instruction
+pattern will be used for that combination of operands. GCC has a
+number of machine-independent predicates, and you can define
+machine-specific predicates as needed. By convention, predicates used
+with `match_operand' have names that end in `_operand', and those used
+with `match_operator' have names that end in `_operator'.
+
+ All predicates are Boolean functions (in the mathematical sense) of
+two arguments: the RTL expression that is being considered at that
+position in the instruction pattern, and the machine mode that the
+`match_operand' or `match_operator' specifies. In this section, the
+first argument is called OP and the second argument MODE. Predicates
+can be called from C as ordinary two-argument functions; this can be
+useful in output templates or other machine-specific code.
+
+ Operand predicates can allow operands that are not actually acceptable
+to the hardware, as long as the constraints give reload the ability to
+fix them up (*note Constraints::). However, GCC will usually generate
+better code if the predicates specify the requirements of the machine
+instructions as closely as possible. Reload cannot fix up operands
+that must be constants ("immediate operands"); you must use a predicate
+that allows only constants, or else enforce the requirement in the
+extra condition.
+
+ Most predicates handle their MODE argument in a uniform manner. If
+MODE is `VOIDmode' (unspecified), then OP can have any mode. If MODE
+is anything else, then OP must have the same mode, unless OP is a
+`CONST_INT' or integer `CONST_DOUBLE'. These RTL expressions always
+have `VOIDmode', so it would be counterproductive to check that their
+mode matches. Instead, predicates that accept `CONST_INT' and/or
+integer `CONST_DOUBLE' check that the value stored in the constant will
+fit in the requested mode.
+
+ Predicates with this behavior are called "normal". `genrecog' can
+optimize the instruction recognizer based on knowledge of how normal
+predicates treat modes. It can also diagnose certain kinds of common
+errors in the use of normal predicates; for instance, it is almost
+always an error to use a normal predicate without specifying a mode.
+
+ Predicates that do something different with their MODE argument are
+called "special". The generic predicates `address_operand' and
+`pmode_register_operand' are special predicates. `genrecog' does not
+do any optimizations or diagnosis when special predicates are used.
+
+* Menu:
+
+* Machine-Independent Predicates:: Predicates available to all back ends.
+* Defining Predicates:: How to write machine-specific predicate
+ functions.
+
+\1f
+File: gccint.info, Node: Machine-Independent Predicates, Next: Defining Predicates, Up: Predicates
+
+16.7.1 Machine-Independent Predicates
+-------------------------------------
+
+These are the generic predicates available to all back ends. They are
+defined in `recog.c'. The first category of predicates allow only
+constant, or "immediate", operands.
+
+ -- Function: immediate_operand
+ This predicate allows any sort of constant that fits in MODE. It
+ is an appropriate choice for instructions that take operands that
+ must be constant.
+
+ -- Function: const_int_operand
+ This predicate allows any `CONST_INT' expression that fits in
+ MODE. It is an appropriate choice for an immediate operand that
+ does not allow a symbol or label.
+
+ -- Function: const_double_operand
+ This predicate accepts any `CONST_DOUBLE' expression that has
+ exactly MODE. If MODE is `VOIDmode', it will also accept
+ `CONST_INT'. It is intended for immediate floating point
+ constants.
+
+The second category of predicates allow only some kind of machine
+register.
+
+ -- Function: register_operand
+ This predicate allows any `REG' or `SUBREG' expression that is
+ valid for MODE. It is often suitable for arithmetic instruction
+ operands on a RISC machine.
+
+ -- Function: pmode_register_operand
+ This is a slight variant on `register_operand' which works around
+ a limitation in the machine-description reader.
+
+ (match_operand N "pmode_register_operand" CONSTRAINT)
+
+ means exactly what
+
+ (match_operand:P N "register_operand" CONSTRAINT)
+
+ would mean, if the machine-description reader accepted `:P' mode
+ suffixes. Unfortunately, it cannot, because `Pmode' is an alias
+ for some other mode, and might vary with machine-specific options.
+ *Note Misc::.
+
+ -- Function: scratch_operand
+ This predicate allows hard registers and `SCRATCH' expressions,
+ but not pseudo-registers. It is used internally by
+ `match_scratch'; it should not be used directly.
+
+The third category of predicates allow only some kind of memory
+reference.
+
+ -- Function: memory_operand
+ This predicate allows any valid reference to a quantity of mode
+ MODE in memory, as determined by the weak form of
+ `GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::).
+
+ -- Function: address_operand
+ This predicate is a little unusual; it allows any operand that is a
+ valid expression for the _address_ of a quantity of mode MODE,
+ again determined by the weak form of `GO_IF_LEGITIMATE_ADDRESS'.
+ To first order, if `(mem:MODE (EXP))' is acceptable to
+ `memory_operand', then EXP is acceptable to `address_operand'.
+ Note that EXP does not necessarily have the mode MODE.
+
+ -- Function: indirect_operand
+ This is a stricter form of `memory_operand' which allows only
+ memory references with a `general_operand' as the address
+ expression. New uses of this predicate are discouraged, because
+ `general_operand' is very permissive, so it's hard to tell what an
+ `indirect_operand' does or does not allow. If a target has
+ different requirements for memory operands for different
+ instructions, it is better to define target-specific predicates
+ which enforce the hardware's requirements explicitly.
+
+ -- Function: push_operand
+ This predicate allows a memory reference suitable for pushing a
+ value onto the stack. This will be a `MEM' which refers to
+ `stack_pointer_rtx', with a side-effect in its address expression
+ (*note Incdec::); which one is determined by the `STACK_PUSH_CODE'
+ macro (*note Frame Layout::).
+
+ -- Function: pop_operand
+ This predicate allows a memory reference suitable for popping a
+ value off the stack. Again, this will be a `MEM' referring to
+ `stack_pointer_rtx', with a side-effect in its address expression.
+ However, this time `STACK_POP_CODE' is expected.
+
+The fourth category of predicates allow some combination of the above
+operands.
+
+ -- Function: nonmemory_operand
+ This predicate allows any immediate or register operand valid for
+ MODE.
+
+ -- Function: nonimmediate_operand
+ This predicate allows any register or memory operand valid for
+ MODE.
+
+ -- Function: general_operand
+ This predicate allows any immediate, register, or memory operand
+ valid for MODE.
+
+Finally, there is one generic operator predicate.
+
+ -- Function: comparison_operator
+ This predicate matches any expression which performs an arithmetic
+ comparison in MODE; that is, `COMPARISON_P' is true for the
+ expression code.
+
+\1f
+File: gccint.info, Node: Defining Predicates, Prev: Machine-Independent Predicates, Up: Predicates
+
+16.7.2 Defining Machine-Specific Predicates
+-------------------------------------------
+
+Many machines have requirements for their operands that cannot be
+expressed precisely using the generic predicates. You can define
+additional predicates using `define_predicate' and
+`define_special_predicate' expressions. These expressions have three
+operands:
+
+ * The name of the predicate, as it will be referred to in
+ `match_operand' or `match_operator' expressions.
+
+ * An RTL expression which evaluates to true if the predicate allows
+ the operand OP, false if it does not. This expression can only use
+ the following RTL codes:
+
+ `MATCH_OPERAND'
+ When written inside a predicate expression, a `MATCH_OPERAND'
+ expression evaluates to true if the predicate it names would
+ allow OP. The operand number and constraint are ignored.
+ Due to limitations in `genrecog', you can only refer to
+ generic predicates and predicates that have already been
+ defined.
+
+ `MATCH_CODE'
+ This expression evaluates to true if OP or a specified
+ subexpression of OP has one of a given list of RTX codes.
+
+ The first operand of this expression is a string constant
+ containing a comma-separated list of RTX code names (in lower
+ case). These are the codes for which the `MATCH_CODE' will
+ be true.
+
+ The second operand is a string constant which indicates what
+ subexpression of OP to examine. If it is absent or the empty
+ string, OP itself is examined. Otherwise, the string constant
+ must be a sequence of digits and/or lowercase letters. Each
+ character indicates a subexpression to extract from the
+ current expression; for the first character this is OP, for
+ the second and subsequent characters it is the result of the
+ previous character. A digit N extracts `XEXP (E, N)'; a
+ letter L extracts `XVECEXP (E, 0, N)' where N is the
+ alphabetic ordinal of L (0 for `a', 1 for 'b', and so on).
+ The `MATCH_CODE' then examines the RTX code of the
+ subexpression extracted by the complete string. It is not
+ possible to extract components of an `rtvec' that is not at
+ position 0 within its RTX object.
+
+ `MATCH_TEST'
+ This expression has one operand, a string constant containing
+ a C expression. The predicate's arguments, OP and MODE, are
+ available with those names in the C expression. The
+ `MATCH_TEST' evaluates to true if the C expression evaluates
+ to a nonzero value. `MATCH_TEST' expressions must not have
+ side effects.
+
+ `AND'
+ `IOR'
+ `NOT'
+ `IF_THEN_ELSE'
+ The basic `MATCH_' expressions can be combined using these
+ logical operators, which have the semantics of the C operators
+ `&&', `||', `!', and `? :' respectively. As in Common Lisp,
+ you may give an `AND' or `IOR' expression an arbitrary number
+ of arguments; this has exactly the same effect as writing a
+ chain of two-argument `AND' or `IOR' expressions.
+
+ * An optional block of C code, which should execute `return true' if
+ the predicate is found to match and `return false' if it does not.
+ It must not have any side effects. The predicate arguments, OP
+ and MODE, are available with those names.
+
+ If a code block is present in a predicate definition, then the RTL
+ expression must evaluate to true _and_ the code block must execute
+ `return true' for the predicate to allow the operand. The RTL
+ expression is evaluated first; do not re-check anything in the
+ code block that was checked in the RTL expression.
+
+ The program `genrecog' scans `define_predicate' and
+`define_special_predicate' expressions to determine which RTX codes are
+possibly allowed. You should always make this explicit in the RTL
+predicate expression, using `MATCH_OPERAND' and `MATCH_CODE'.
+
+ Here is an example of a simple predicate definition, from the IA64
+machine description:
+
+ ;; True if OP is a `SYMBOL_REF' which refers to the sdata section.
+ (define_predicate "small_addr_symbolic_operand"
+ (and (match_code "symbol_ref")
+ (match_test "SYMBOL_REF_SMALL_ADDR_P (op)")))
+
+And here is another, showing the use of the C block.
+
+ ;; True if OP is a register operand that is (or could be) a GR reg.
+ (define_predicate "gr_register_operand"
+ (match_operand 0 "register_operand")
+ {
+ unsigned int regno;
+ if (GET_CODE (op) == SUBREG)
+ op = SUBREG_REG (op);
+
+ regno = REGNO (op);
+ return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno));
+ })
+
+ Predicates written with `define_predicate' automatically include a
+test that MODE is `VOIDmode', or OP has the same mode as MODE, or OP is
+a `CONST_INT' or `CONST_DOUBLE'. They do _not_ check specifically for
+integer `CONST_DOUBLE', nor do they test that the value of either kind
+of constant fits in the requested mode. This is because
+target-specific predicates that take constants usually have to do more
+stringent value checks anyway. If you need the exact same treatment of
+`CONST_INT' or `CONST_DOUBLE' that the generic predicates provide, use
+a `MATCH_OPERAND' subexpression to call `const_int_operand',
+`const_double_operand', or `immediate_operand'.
+
+ Predicates written with `define_special_predicate' do not get any
+automatic mode checks, and are treated as having special mode handling
+by `genrecog'.
+
+ The program `genpreds' is responsible for generating code to test
+predicates. It also writes a header file containing function
+declarations for all machine-specific predicates. It is not necessary
+to declare these predicates in `CPU-protos.h'.
+
+\1f
+File: gccint.info, Node: Constraints, Next: Standard Names, Prev: Predicates, Up: Machine Desc
+
+16.8 Operand Constraints
+========================
+
+Each `match_operand' in an instruction pattern can specify constraints
+for the operands allowed. The constraints allow you to fine-tune
+matching within the set of operands allowed by the predicate.
+
+ Constraints can say whether an operand may be in a register, and which
+kinds of register; whether the operand can be a memory reference, and
+which kinds of address; whether the operand may be an immediate
+constant, and which possible values it may have. Constraints can also
+require two operands to match.
+
+* Menu:
+
+* Simple Constraints:: Basic use of constraints.
+* Multi-Alternative:: When an insn has two alternative constraint-patterns.
+* Class Preferences:: Constraints guide which hard register to put things in.
+* Modifiers:: More precise control over effects of constraints.
+* Disable Insn Alternatives:: Disable insn alternatives using the `enabled' attribute.
+* Machine Constraints:: Existing constraints for some particular machines.
+* Define Constraints:: How to define machine-specific constraints.
+* C Constraint Interface:: How to test constraints from C code.
+
+\1f
+File: gccint.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints
+
+16.8.1 Simple Constraints
+-------------------------
+
+The simplest kind of constraint is a string full of letters, each of
+which describes one kind of operand that is permitted. Here are the
+letters that are allowed:
+
+whitespace
+ Whitespace characters are ignored and can be inserted at any
+ position except the first. This enables each alternative for
+ different operands to be visually aligned in the machine
+ description even if they have different number of constraints and
+ modifiers.
+
+`m'
+ A memory operand is allowed, with any kind of address that the
+ machine supports in general. Note that the letter used for the
+ general memory constraint can be re-defined by a back end using
+ the `TARGET_MEM_CONSTRAINT' macro.
+
+`o'
+ A memory operand is allowed, but only if the address is
+ "offsettable". This means that adding a small integer (actually,
+ the width in bytes of the operand, as determined by its machine
+ mode) may be added to the address and the result is also a valid
+ memory address.
+
+ For example, an address which is constant is offsettable; so is an
+ address that is the sum of a register and a constant (as long as a
+ slightly larger constant is also within the range of
+ address-offsets supported by the machine); but an autoincrement or
+ autodecrement address is not offsettable. More complicated
+ indirect/indexed addresses may or may not be offsettable depending
+ on the other addressing modes that the machine supports.
+
+ Note that in an output operand which can be matched by another
+ operand, the constraint letter `o' is valid only when accompanied
+ by both `<' (if the target machine has predecrement addressing)
+ and `>' (if the target machine has preincrement addressing).
+
+`V'
+ A memory operand that is not offsettable. In other words,
+ anything that would fit the `m' constraint but not the `o'
+ constraint.
+
+`<'
+ A memory operand with autodecrement addressing (either
+ predecrement or postdecrement) is allowed.
+
+`>'
+ A memory operand with autoincrement addressing (either
+ preincrement or postincrement) is allowed.
+
+`r'
+ A register operand is allowed provided that it is in a general
+ register.
+
+`i'
+ An immediate integer operand (one with constant value) is allowed.
+ This includes symbolic constants whose values will be known only at
+ assembly time or later.
+
+`n'
+ An immediate integer operand with a known numeric value is allowed.
+ Many systems cannot support assembly-time constants for operands
+ less than a word wide. Constraints for these operands should use
+ `n' rather than `i'.
+
+`I', `J', `K', ... `P'
+ Other letters in the range `I' through `P' may be defined in a
+ machine-dependent fashion to permit immediate integer operands with
+ explicit integer values in specified ranges. For example, on the
+ 68000, `I' is defined to stand for the range of values 1 to 8.
+ This is the range permitted as a shift count in the shift
+ instructions.
+
+`E'
+ An immediate floating operand (expression code `const_double') is
+ allowed, but only if the target floating point format is the same
+ as that of the host machine (on which the compiler is running).
+
+`F'
+ An immediate floating operand (expression code `const_double' or
+ `const_vector') is allowed.
+
+`G', `H'
+ `G' and `H' may be defined in a machine-dependent fashion to
+ permit immediate floating operands in particular ranges of values.
+
+`s'
+ An immediate integer operand whose value is not an explicit
+ integer is allowed.
+
+ This might appear strange; if an insn allows a constant operand
+ with a value not known at compile time, it certainly must allow
+ any known value. So why use `s' instead of `i'? Sometimes it
+ allows better code to be generated.
+
+ For example, on the 68000 in a fullword instruction it is possible
+ to use an immediate operand; but if the immediate value is between
+ -128 and 127, better code results from loading the value into a
+ register and using the register. This is because the load into
+ the register can be done with a `moveq' instruction. We arrange
+ for this to happen by defining the letter `K' to mean "any integer
+ outside the range -128 to 127", and then specifying `Ks' in the
+ operand constraints.
+
+`g'
+ Any register, memory or immediate integer operand is allowed,
+ except for registers that are not general registers.
+
+`X'
+ Any operand whatsoever is allowed, even if it does not satisfy
+ `general_operand'. This is normally used in the constraint of a
+ `match_scratch' when certain alternatives will not actually
+ require a scratch register.
+
+`0', `1', `2', ... `9'
+ An operand that matches the specified operand number is allowed.
+ If a digit is used together with letters within the same
+ alternative, the digit should come last.
+
+ This number is allowed to be more than a single digit. If multiple
+ digits are encountered consecutively, they are interpreted as a
+ single decimal integer. There is scant chance for ambiguity,
+ since to-date it has never been desirable that `10' be interpreted
+ as matching either operand 1 _or_ operand 0. Should this be
+ desired, one can use multiple alternatives instead.
+
+ This is called a "matching constraint" and what it really means is
+ that the assembler has only a single operand that fills two roles
+ considered separate in the RTL insn. For example, an add insn has
+ two input operands and one output operand in the RTL, but on most
+ CISC machines an add instruction really has only two operands, one
+ of them an input-output operand:
+
+ addl #35,r12
+
+ Matching constraints are used in these circumstances. More
+ precisely, the two operands that match must include one input-only
+ operand and one output-only operand. Moreover, the digit must be a
+ smaller number than the number of the operand that uses it in the
+ constraint.
+
+ For operands to match in a particular case usually means that they
+ are identical-looking RTL expressions. But in a few special cases
+ specific kinds of dissimilarity are allowed. For example, `*x' as
+ an input operand will match `*x++' as an output operand. For
+ proper results in such cases, the output template should always
+ use the output-operand's number when printing the operand.
+
+`p'
+ An operand that is a valid memory address is allowed. This is for
+ "load address" and "push address" instructions.
+
+ `p' in the constraint must be accompanied by `address_operand' as
+ the predicate in the `match_operand'. This predicate interprets
+ the mode specified in the `match_operand' as the mode of the memory
+ reference for which the address would be valid.
+
+OTHER-LETTERS
+ Other letters can be defined in machine-dependent fashion to stand
+ for particular classes of registers or other arbitrary operand
+ types. `d', `a' and `f' are defined on the 68000/68020 to stand
+ for data, address and floating point registers.
+
+ In order to have valid assembler code, each operand must satisfy its
+constraint. But a failure to do so does not prevent the pattern from
+applying to an insn. Instead, it directs the compiler to modify the
+code so that the constraint will be satisfied. Usually this is done by
+copying an operand into a register.
+
+ Contrast, therefore, the two instruction patterns that follow:
+
+ (define_insn ""
+ [(set (match_operand:SI 0 "general_operand" "=r")
+ (plus:SI (match_dup 0)
+ (match_operand:SI 1 "general_operand" "r")))]
+ ""
+ "...")
+
+which has two operands, one of which must appear in two places, and
+
+ (define_insn ""
+ [(set (match_operand:SI 0 "general_operand" "=r")
+ (plus:SI (match_operand:SI 1 "general_operand" "0")
+ (match_operand:SI 2 "general_operand" "r")))]
+ ""
+ "...")
+
+which has three operands, two of which are required by a constraint to
+be identical. If we are considering an insn of the form
+
+ (insn N PREV NEXT
+ (set (reg:SI 3)
+ (plus:SI (reg:SI 6) (reg:SI 109)))
+ ...)
+
+the first pattern would not apply at all, because this insn does not
+contain two identical subexpressions in the right place. The pattern
+would say, "That does not look like an add instruction; try other
+patterns". The second pattern would say, "Yes, that's an add
+instruction, but there is something wrong with it". It would direct
+the reload pass of the compiler to generate additional insns to make
+the constraint true. The results might look like this:
+
+ (insn N2 PREV N
+ (set (reg:SI 3) (reg:SI 6))
+ ...)
+
+ (insn N N2 NEXT
+ (set (reg:SI 3)
+ (plus:SI (reg:SI 3) (reg:SI 109)))
+ ...)
+
+ It is up to you to make sure that each operand, in each pattern, has
+constraints that can handle any RTL expression that could be present for
+that operand. (When multiple alternatives are in use, each pattern
+must, for each possible combination of operand expressions, have at
+least one alternative which can handle that combination of operands.)
+The constraints don't need to _allow_ any possible operand--when this is
+the case, they do not constrain--but they must at least point the way to
+reloading any possible operand so that it will fit.
+
+ * If the constraint accepts whatever operands the predicate permits,
+ there is no problem: reloading is never necessary for this operand.
+
+ For example, an operand whose constraints permit everything except
+ registers is safe provided its predicate rejects registers.
+
+ An operand whose predicate accepts only constant values is safe
+ provided its constraints include the letter `i'. If any possible
+ constant value is accepted, then nothing less than `i' will do; if
+ the predicate is more selective, then the constraints may also be
+ more selective.
+
+ * Any operand expression can be reloaded by copying it into a
+ register. So if an operand's constraints allow some kind of
+ register, it is certain to be safe. It need not permit all
+ classes of registers; the compiler knows how to copy a register
+ into another register of the proper class in order to make an
+ instruction valid.
+
+ * A nonoffsettable memory reference can be reloaded by copying the
+ address into a register. So if the constraint uses the letter
+ `o', all memory references are taken care of.
+
+ * A constant operand can be reloaded by allocating space in memory to
+ hold it as preinitialized data. Then the memory reference can be
+ used in place of the constant. So if the constraint uses the
+ letters `o' or `m', constant operands are not a problem.
+
+ * If the constraint permits a constant and a pseudo register used in
+ an insn was not allocated to a hard register and is equivalent to
+ a constant, the register will be replaced with the constant. If
+ the predicate does not permit a constant and the insn is
+ re-recognized for some reason, the compiler will crash. Thus the
+ predicate must always recognize any objects allowed by the
+ constraint.
+
+ If the operand's predicate can recognize registers, but the constraint
+does not permit them, it can make the compiler crash. When this
+operand happens to be a register, the reload pass will be stymied,
+because it does not know how to copy a register temporarily into memory.
+
+ If the predicate accepts a unary operator, the constraint applies to
+the operand. For example, the MIPS processor at ISA level 3 supports an
+instruction which adds two registers in `SImode' to produce a `DImode'
+result, but only if the registers are correctly sign extended. This
+predicate for the input operands accepts a `sign_extend' of an `SImode'
+register. Write the constraint to indicate the type of register that
+is required for the operand of the `sign_extend'.
+
+\1f
+File: gccint.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints
+
+16.8.2 Multiple Alternative Constraints
+---------------------------------------
+
+Sometimes a single instruction has multiple alternative sets of possible
+operands. For example, on the 68000, a logical-or instruction can
+combine register or an immediate value into memory, or it can combine
+any kind of operand into a register; but it cannot combine one memory
+location into another.
+
+ These constraints are represented as multiple alternatives. An
+alternative can be described by a series of letters for each operand.
+The overall constraint for an operand is made from the letters for this
+operand from the first alternative, a comma, the letters for this
+operand from the second alternative, a comma, and so on until the last
+alternative. Here is how it is done for fullword logical-or on the
+68000:
+
+ (define_insn "iorsi3"
+ [(set (match_operand:SI 0 "general_operand" "=m,d")
+ (ior:SI (match_operand:SI 1 "general_operand" "%0,0")
+ (match_operand:SI 2 "general_operand" "dKs,dmKs")))]
+ ...)
+
+ The first alternative has `m' (memory) for operand 0, `0' for operand
+1 (meaning it must match operand 0), and `dKs' for operand 2. The
+second alternative has `d' (data register) for operand 0, `0' for
+operand 1, and `dmKs' for operand 2. The `=' and `%' in the
+constraints apply to all the alternatives; their meaning is explained
+in the next section (*note Class Preferences::).
+
+ If all the operands fit any one alternative, the instruction is valid.
+Otherwise, for each alternative, the compiler counts how many
+instructions must be added to copy the operands so that that
+alternative applies. The alternative requiring the least copying is
+chosen. If two alternatives need the same amount of copying, the one
+that comes first is chosen. These choices can be altered with the `?'
+and `!' characters:
+
+`?'
+ Disparage slightly the alternative that the `?' appears in, as a
+ choice when no alternative applies exactly. The compiler regards
+ this alternative as one unit more costly for each `?' that appears
+ in it.
+
+`!'
+ Disparage severely the alternative that the `!' appears in. This
+ alternative can still be used if it fits without reloading, but if
+ reloading is needed, some other alternative will be used.
+
+ When an insn pattern has multiple alternatives in its constraints,
+often the appearance of the assembler code is determined mostly by which
+alternative was matched. When this is so, the C code for writing the
+assembler code can use the variable `which_alternative', which is the
+ordinal number of the alternative that was actually satisfied (0 for
+the first, 1 for the second alternative, etc.). *Note Output
+Statement::.
+
+\1f
+File: gccint.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints
+
+16.8.3 Register Class Preferences
+---------------------------------
+
+The operand constraints have another function: they enable the compiler
+to decide which kind of hardware register a pseudo register is best
+allocated to. The compiler examines the constraints that apply to the
+insns that use the pseudo register, looking for the machine-dependent
+letters such as `d' and `a' that specify classes of registers. The
+pseudo register is put in whichever class gets the most "votes". The
+constraint letters `g' and `r' also vote: they vote in favor of a
+general register. The machine description says which registers are
+considered general.
+
+ Of course, on some machines all registers are equivalent, and no
+register classes are defined. Then none of this complexity is relevant.
+
+\1f
+File: gccint.info, Node: Modifiers, Next: Disable Insn Alternatives, Prev: Class Preferences, Up: Constraints
+
+16.8.4 Constraint Modifier Characters
+-------------------------------------
+
+Here are constraint modifier characters.
+
+`='
+ Means that this operand is write-only for this instruction: the
+ previous value is discarded and replaced by output data.
+
+`+'
+ Means that this operand is both read and written by the
+ instruction.
+
+ When the compiler fixes up the operands to satisfy the constraints,
+ it needs to know which operands are inputs to the instruction and
+ which are outputs from it. `=' identifies an output; `+'
+ identifies an operand that is both input and output; all other
+ operands are assumed to be input only.
+
+ If you specify `=' or `+' in a constraint, you put it in the first
+ character of the constraint string.
+
+`&'
+ Means (in a particular alternative) that this operand is an
+ "earlyclobber" operand, which is modified before the instruction is
+ finished using the input operands. Therefore, this operand may
+ not lie in a register that is used as an input operand or as part
+ of any memory address.
+
+ `&' applies only to the alternative in which it is written. In
+ constraints with multiple alternatives, sometimes one alternative
+ requires `&' while others do not. See, for example, the `movdf'
+ insn of the 68000.
+
+ An input operand can be tied to an earlyclobber operand if its only
+ use as an input occurs before the early result is written. Adding
+ alternatives of this form often allows GCC to produce better code
+ when only some of the inputs can be affected by the earlyclobber.
+ See, for example, the `mulsi3' insn of the ARM.
+
+ `&' does not obviate the need to write `='.
+
+`%'
+ Declares the instruction to be commutative for this operand and the
+ following operand. This means that the compiler may interchange
+ the two operands if that is the cheapest way to make all operands
+ fit the constraints. This is often used in patterns for addition
+ instructions that really have only two operands: the result must
+ go in one of the arguments. Here for example, is how the 68000
+ halfword-add instruction is defined:
+
+ (define_insn "addhi3"
+ [(set (match_operand:HI 0 "general_operand" "=m,r")
+ (plus:HI (match_operand:HI 1 "general_operand" "%0,0")
+ (match_operand:HI 2 "general_operand" "di,g")))]
+ ...)
+ GCC can only handle one commutative pair in an asm; if you use
+ more, the compiler may fail. Note that you need not use the
+ modifier if the two alternatives are strictly identical; this
+ would only waste time in the reload pass. The modifier is not
+ operational after register allocation, so the result of
+ `define_peephole2' and `define_split's performed after reload
+ cannot rely on `%' to make the intended insn match.
+
+`#'
+ Says that all following characters, up to the next comma, are to be
+ ignored as a constraint. They are significant only for choosing
+ register preferences.
+
+`*'
+ Says that the following character should be ignored when choosing
+ register preferences. `*' has no effect on the meaning of the
+ constraint as a constraint, and no effect on reloading.
+
+ Here is an example: the 68000 has an instruction to sign-extend a
+ halfword in a data register, and can also sign-extend a value by
+ copying it into an address register. While either kind of
+ register is acceptable, the constraints on an address-register
+ destination are less strict, so it is best if register allocation
+ makes an address register its goal. Therefore, `*' is used so
+ that the `d' constraint letter (for data register) is ignored when
+ computing register preferences.
+
+ (define_insn "extendhisi2"
+ [(set (match_operand:SI 0 "general_operand" "=*d,a")
+ (sign_extend:SI
+ (match_operand:HI 1 "general_operand" "0,g")))]
+ ...)
+
+\1f
+File: gccint.info, Node: Machine Constraints, Next: Define Constraints, Prev: Disable Insn Alternatives, Up: Constraints
+
+16.8.5 Constraints for Particular Machines
+------------------------------------------
+
+Whenever possible, you should use the general-purpose constraint letters
+in `asm' arguments, since they will convey meaning more readily to
+people reading your code. Failing that, use the constraint letters
+that usually have very similar meanings across architectures. The most
+commonly used constraints are `m' and `r' (for memory and
+general-purpose registers respectively; *note Simple Constraints::), and
+`I', usually the letter indicating the most common immediate-constant
+format.
+
+ Each architecture defines additional constraints. These constraints
+are used by the compiler itself for instruction generation, as well as
+for `asm' statements; therefore, some of the constraints are not
+particularly useful for `asm'. Here is a summary of some of the
+machine-dependent constraints available on some particular machines; it
+includes both constraints that are useful for `asm' and constraints
+that aren't. The compiler source file mentioned in the table heading
+for each architecture is the definitive reference for the meanings of
+that architecture's constraints.
+
+_ARM family--`config/arm/arm.h'_
+
+ `f'
+ Floating-point register
+
+ `w'
+ VFP floating-point register
+
+ `F'
+ One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0,
+ 4.0, 5.0 or 10.0
+
+ `G'
+ Floating-point constant that would satisfy the constraint `F'
+ if it were negated
+
+ `I'
+ Integer that is valid as an immediate operand in a data
+ processing instruction. That is, an integer in the range 0
+ to 255 rotated by a multiple of 2
+
+ `J'
+ Integer in the range -4095 to 4095
+
+ `K'
+ Integer that satisfies constraint `I' when inverted (ones
+ complement)
+
+ `L'
+ Integer that satisfies constraint `I' when negated (twos
+ complement)
+
+ `M'
+ Integer in the range 0 to 32
+
+ `Q'
+ A memory reference where the exact address is in a single
+ register (``m'' is preferable for `asm' statements)
+
+ `R'
+ An item in the constant pool
+
+ `S'
+ A symbol in the text segment of the current file
+
+ `Uv'
+ A memory reference suitable for VFP load/store insns
+ (reg+constant offset)
+
+ `Uy'
+ A memory reference suitable for iWMMXt load/store
+ instructions.
+
+ `Uq'
+ A memory reference suitable for the ARMv4 ldrsb instruction.
+
+_AVR family--`config/avr/constraints.md'_
+
+ `l'
+ Registers from r0 to r15
+
+ `a'
+ Registers from r16 to r23
+
+ `d'
+ Registers from r16 to r31
+
+ `w'
+ Registers from r24 to r31. These registers can be used in
+ `adiw' command
+
+ `e'
+ Pointer register (r26-r31)
+
+ `b'
+ Base pointer register (r28-r31)
+
+ `q'
+ Stack pointer register (SPH:SPL)
+
+ `t'
+ Temporary register r0
+
+ `x'
+ Register pair X (r27:r26)
+
+ `y'
+ Register pair Y (r29:r28)
+
+ `z'
+ Register pair Z (r31:r30)
+
+ `I'
+ Constant greater than -1, less than 64
+
+ `J'
+ Constant greater than -64, less than 1
+
+ `K'
+ Constant integer 2
+
+ `L'
+ Constant integer 0
+
+ `M'
+ Constant that fits in 8 bits
+
+ `N'
+ Constant integer -1
+
+ `O'
+ Constant integer 8, 16, or 24
+
+ `P'
+ Constant integer 1
+
+ `G'
+ A floating point constant 0.0
+
+ `R'
+ Integer constant in the range -6 ... 5.
+
+ `Q'
+ A memory address based on Y or Z pointer with displacement.
+
+_CRX Architecture--`config/crx/crx.h'_
+
+ `b'
+ Registers from r0 to r14 (registers without stack pointer)
+
+ `l'
+ Register r16 (64-bit accumulator lo register)
+
+ `h'
+ Register r17 (64-bit accumulator hi register)
+
+ `k'
+ Register pair r16-r17. (64-bit accumulator lo-hi pair)
+
+ `I'
+ Constant that fits in 3 bits
+
+ `J'
+ Constant that fits in 4 bits
+
+ `K'
+ Constant that fits in 5 bits
+
+ `L'
+ Constant that is one of -1, 4, -4, 7, 8, 12, 16, 20, 32, 48
+
+ `G'
+ Floating point constant that is legal for store immediate
+
+_Hewlett-Packard PA-RISC--`config/pa/pa.h'_
+
+ `a'
+ General register 1
+
+ `f'
+ Floating point register
+
+ `q'
+ Shift amount register
+
+ `x'
+ Floating point register (deprecated)
+
+ `y'
+ Upper floating point register (32-bit), floating point
+ register (64-bit)
+
+ `Z'
+ Any register
+
+ `I'
+ Signed 11-bit integer constant
+
+ `J'
+ Signed 14-bit integer constant
+
+ `K'
+ Integer constant that can be deposited with a `zdepi'
+ instruction
+
+ `L'
+ Signed 5-bit integer constant
+
+ `M'
+ Integer constant 0
+
+ `N'
+ Integer constant that can be loaded with a `ldil' instruction
+
+ `O'
+ Integer constant whose value plus one is a power of 2
+
+ `P'
+ Integer constant that can be used for `and' operations in
+ `depi' and `extru' instructions
+
+ `S'
+ Integer constant 31
+
+ `U'
+ Integer constant 63
+
+ `G'
+ Floating-point constant 0.0
+
+ `A'
+ A `lo_sum' data-linkage-table memory operand
+
+ `Q'
+ A memory operand that can be used as the destination operand
+ of an integer store instruction
+
+ `R'
+ A scaled or unscaled indexed memory operand
+
+ `T'
+ A memory operand for floating-point loads and stores
+
+ `W'
+ A register indirect memory operand
+
+_picoChip family--`picochip.h'_
+
+ `k'
+ Stack register.
+
+ `f'
+ Pointer register. A register which can be used to access
+ memory without supplying an offset. Any other register can
+ be used to access memory, but will need a constant offset.
+ In the case of the offset being zero, it is more efficient to
+ use a pointer register, since this reduces code size.
+
+ `t'
+ A twin register. A register which may be paired with an
+ adjacent register to create a 32-bit register.
+
+ `a'
+ Any absolute memory address (e.g., symbolic constant, symbolic
+ constant + offset).
+
+ `I'
+ 4-bit signed integer.
+
+ `J'
+ 4-bit unsigned integer.
+
+ `K'
+ 8-bit signed integer.
+
+ `M'
+ Any constant whose absolute value is no greater than 4-bits.
+
+ `N'
+ 10-bit signed integer
+
+ `O'
+ 16-bit signed integer.
+
+
+_PowerPC and IBM RS6000--`config/rs6000/rs6000.h'_
+
+ `b'
+ Address base register
+
+ `f'
+ Floating point register
+
+ `v'
+ Vector register
+
+ `h'
+ `MQ', `CTR', or `LINK' register
+
+ `q'
+ `MQ' register
+
+ `c'
+ `CTR' register
+
+ `l'
+ `LINK' register
+
+ `x'
+ `CR' register (condition register) number 0
+
+ `y'
+ `CR' register (condition register)
+
+ `z'
+ `FPMEM' stack memory for FPR-GPR transfers
+
+ `I'
+ Signed 16-bit constant
+
+ `J'
+ Unsigned 16-bit constant shifted left 16 bits (use `L'
+ instead for `SImode' constants)
+
+ `K'
+ Unsigned 16-bit constant
+
+ `L'
+ Signed 16-bit constant shifted left 16 bits
+
+ `M'
+ Constant larger than 31
+
+ `N'
+ Exact power of 2
+
+ `O'
+ Zero
+
+ `P'
+ Constant whose negation is a signed 16-bit constant
+
+ `G'
+ Floating point constant that can be loaded into a register
+ with one instruction per word
+
+ `H'
+ Integer/Floating point constant that can be loaded into a
+ register using three instructions
+
+ `Q'
+ Memory operand that is an offset from a register (`m' is
+ preferable for `asm' statements)
+
+ `Z'
+ Memory operand that is an indexed or indirect from a register
+ (`m' is preferable for `asm' statements)
+
+ `R'
+ AIX TOC entry
+
+ `a'
+ Address operand that is an indexed or indirect from a
+ register (`p' is preferable for `asm' statements)
+
+ `S'
+ Constant suitable as a 64-bit mask operand
+
+ `T'
+ Constant suitable as a 32-bit mask operand
+
+ `U'
+ System V Release 4 small data area reference
+
+ `t'
+ AND masks that can be performed by two rldic{l, r}
+ instructions
+
+ `W'
+ Vector constant that does not require memory
+
+
+_Intel 386--`config/i386/constraints.md'_
+
+ `R'
+ Legacy register--the eight integer registers available on all
+ i386 processors (`a', `b', `c', `d', `si', `di', `bp', `sp').
+
+ `q'
+ Any register accessible as `Rl'. In 32-bit mode, `a', `b',
+ `c', and `d'; in 64-bit mode, any integer register.
+
+ `Q'
+ Any register accessible as `Rh': `a', `b', `c', and `d'.
+
+ `l'
+ Any register that can be used as the index in a base+index
+ memory access: that is, any general register except the stack
+ pointer.
+
+ `a'
+ The `a' register.
+
+ `b'
+ The `b' register.
+
+ `c'
+ The `c' register.
+
+ `d'
+ The `d' register.
+
+ `S'
+ The `si' register.
+
+ `D'
+ The `di' register.
+
+ `A'
+ The `a' and `d' registers, as a pair (for instructions that
+ return half the result in one and half in the other).
+
+ `f'
+ Any 80387 floating-point (stack) register.
+
+ `t'
+ Top of 80387 floating-point stack (`%st(0)').
+
+ `u'
+ Second from top of 80387 floating-point stack (`%st(1)').
+
+ `y'
+ Any MMX register.
+
+ `x'
+ Any SSE register.
+
+ `Yz'
+ First SSE register (`%xmm0').
+
+ `Y2'
+ Any SSE register, when SSE2 is enabled.
+
+ `Yi'
+ Any SSE register, when SSE2 and inter-unit moves are enabled.
+
+ `Ym'
+ Any MMX register, when inter-unit moves are enabled.
+
+ `I'
+ Integer constant in the range 0 ... 31, for 32-bit shifts.
+
+ `J'
+ Integer constant in the range 0 ... 63, for 64-bit shifts.
+
+ `K'
+ Signed 8-bit integer constant.
+
+ `L'
+ `0xFF' or `0xFFFF', for andsi as a zero-extending move.
+
+ `M'
+ 0, 1, 2, or 3 (shifts for the `lea' instruction).
+
+ `N'
+ Unsigned 8-bit integer constant (for `in' and `out'
+ instructions).
+
+ `O'
+ Integer constant in the range 0 ... 127, for 128-bit shifts.
+
+ `G'
+ Standard 80387 floating point constant.
+
+ `C'
+ Standard SSE floating point constant.
+
+ `e'
+ 32-bit signed integer constant, or a symbolic reference known
+ to fit that range (for immediate operands in sign-extending
+ x86-64 instructions).
+
+ `Z'
+ 32-bit unsigned integer constant, or a symbolic reference
+ known to fit that range (for immediate operands in
+ zero-extending x86-64 instructions).
+
+
+_Intel IA-64--`config/ia64/ia64.h'_
+
+ `a'
+ General register `r0' to `r3' for `addl' instruction
+
+ `b'
+ Branch register
+
+ `c'
+ Predicate register (`c' as in "conditional")
+
+ `d'
+ Application register residing in M-unit
+
+ `e'
+ Application register residing in I-unit
+
+ `f'
+ Floating-point register
+
+ `m'
+ Memory operand. Remember that `m' allows postincrement and
+ postdecrement which require printing with `%Pn' on IA-64.
+ Use `S' to disallow postincrement and postdecrement.
+
+ `G'
+ Floating-point constant 0.0 or 1.0
+
+ `I'
+ 14-bit signed integer constant
+
+ `J'
+ 22-bit signed integer constant
+
+ `K'
+ 8-bit signed integer constant for logical instructions
+
+ `L'
+ 8-bit adjusted signed integer constant for compare pseudo-ops
+
+ `M'
+ 6-bit unsigned integer constant for shift counts
+
+ `N'
+ 9-bit signed integer constant for load and store
+ postincrements
+
+ `O'
+ The constant zero
+
+ `P'
+ 0 or -1 for `dep' instruction
+
+ `Q'
+ Non-volatile memory for floating-point loads and stores
+
+ `R'
+ Integer constant in the range 1 to 4 for `shladd' instruction
+
+ `S'
+ Memory operand except postincrement and postdecrement
+
+_FRV--`config/frv/frv.h'_
+
+ `a'
+ Register in the class `ACC_REGS' (`acc0' to `acc7').
+
+ `b'
+ Register in the class `EVEN_ACC_REGS' (`acc0' to `acc7').
+
+ `c'
+ Register in the class `CC_REGS' (`fcc0' to `fcc3' and `icc0'
+ to `icc3').
+
+ `d'
+ Register in the class `GPR_REGS' (`gr0' to `gr63').
+
+ `e'
+ Register in the class `EVEN_REGS' (`gr0' to `gr63'). Odd
+ registers are excluded not in the class but through the use
+ of a machine mode larger than 4 bytes.
+
+ `f'
+ Register in the class `FPR_REGS' (`fr0' to `fr63').
+
+ `h'
+ Register in the class `FEVEN_REGS' (`fr0' to `fr63'). Odd
+ registers are excluded not in the class but through the use
+ of a machine mode larger than 4 bytes.
+
+ `l'
+ Register in the class `LR_REG' (the `lr' register).
+
+ `q'
+ Register in the class `QUAD_REGS' (`gr2' to `gr63').
+ Register numbers not divisible by 4 are excluded not in the
+ class but through the use of a machine mode larger than 8
+ bytes.
+
+ `t'
+ Register in the class `ICC_REGS' (`icc0' to `icc3').
+
+ `u'
+ Register in the class `FCC_REGS' (`fcc0' to `fcc3').
+
+ `v'
+ Register in the class `ICR_REGS' (`cc4' to `cc7').
+
+ `w'
+ Register in the class `FCR_REGS' (`cc0' to `cc3').
+
+ `x'
+ Register in the class `QUAD_FPR_REGS' (`fr0' to `fr63').
+ Register numbers not divisible by 4 are excluded not in the
+ class but through the use of a machine mode larger than 8
+ bytes.
+
+ `z'
+ Register in the class `SPR_REGS' (`lcr' and `lr').
+
+ `A'
+ Register in the class `QUAD_ACC_REGS' (`acc0' to `acc7').
+
+ `B'
+ Register in the class `ACCG_REGS' (`accg0' to `accg7').
+
+ `C'
+ Register in the class `CR_REGS' (`cc0' to `cc7').
+
+ `G'
+ Floating point constant zero
+
+ `I'
+ 6-bit signed integer constant
+
+ `J'
+ 10-bit signed integer constant
+
+ `L'
+ 16-bit signed integer constant
+
+ `M'
+ 16-bit unsigned integer constant
+
+ `N'
+ 12-bit signed integer constant that is negative--i.e. in the
+ range of -2048 to -1
+
+ `O'
+ Constant zero
+
+ `P'
+ 12-bit signed integer constant that is greater than
+ zero--i.e. in the range of 1 to 2047.
+
+
+_Blackfin family--`config/bfin/constraints.md'_
+
+ `a'
+ P register
+
+ `d'
+ D register
+
+ `z'
+ A call clobbered P register.
+
+ `qN'
+ A single register. If N is in the range 0 to 7, the
+ corresponding D register. If it is `A', then the register P0.
+
+ `D'
+ Even-numbered D register
+
+ `W'
+ Odd-numbered D register
+
+ `e'
+ Accumulator register.
+
+ `A'
+ Even-numbered accumulator register.
+
+ `B'
+ Odd-numbered accumulator register.
+
+ `b'
+ I register
+
+ `v'
+ B register
+
+ `f'
+ M register
+
+ `c'
+ Registers used for circular buffering, i.e. I, B, or L
+ registers.
+
+ `C'
+ The CC register.
+
+ `t'
+ LT0 or LT1.
+
+ `k'
+ LC0 or LC1.
+
+ `u'
+ LB0 or LB1.
+
+ `x'
+ Any D, P, B, M, I or L register.
+
+ `y'
+ Additional registers typically used only in prologues and
+ epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and
+ USP.
+
+ `w'
+ Any register except accumulators or CC.
+
+ `Ksh'
+ Signed 16 bit integer (in the range -32768 to 32767)
+
+ `Kuh'
+ Unsigned 16 bit integer (in the range 0 to 65535)
+
+ `Ks7'
+ Signed 7 bit integer (in the range -64 to 63)
+
+ `Ku7'
+ Unsigned 7 bit integer (in the range 0 to 127)
+
+ `Ku5'
+ Unsigned 5 bit integer (in the range 0 to 31)
+
+ `Ks4'
+ Signed 4 bit integer (in the range -8 to 7)
+
+ `Ks3'
+ Signed 3 bit integer (in the range -3 to 4)
+
+ `Ku3'
+ Unsigned 3 bit integer (in the range 0 to 7)
+
+ `PN'
+ Constant N, where N is a single-digit constant in the range 0
+ to 4.
+
+ `PA'
+ An integer equal to one of the MACFLAG_XXX constants that is
+ suitable for use with either accumulator.
+
+ `PB'
+ An integer equal to one of the MACFLAG_XXX constants that is
+ suitable for use only with accumulator A1.
+
+ `M1'
+ Constant 255.
+
+ `M2'
+ Constant 65535.
+
+ `J'
+ An integer constant with exactly a single bit set.
+
+ `L'
+ An integer constant with all bits set except exactly one.
+
+ `H'
+
+ `Q'
+ Any SYMBOL_REF.
+
+_M32C--`config/m32c/m32c.c'_
+
+ `Rsp'
+ `Rfb'
+ `Rsb'
+ `$sp', `$fb', `$sb'.
+
+ `Rcr'
+ Any control register, when they're 16 bits wide (nothing if
+ control registers are 24 bits wide)
+
+ `Rcl'
+ Any control register, when they're 24 bits wide.
+
+ `R0w'
+ `R1w'
+ `R2w'
+ `R3w'
+ $r0, $r1, $r2, $r3.
+
+ `R02'
+ $r0 or $r2, or $r2r0 for 32 bit values.
+
+ `R13'
+ $r1 or $r3, or $r3r1 for 32 bit values.
+
+ `Rdi'
+ A register that can hold a 64 bit value.
+
+ `Rhl'
+ $r0 or $r1 (registers with addressable high/low bytes)
+
+ `R23'
+ $r2 or $r3
+
+ `Raa'
+ Address registers
+
+ `Raw'
+ Address registers when they're 16 bits wide.
+
+ `Ral'
+ Address registers when they're 24 bits wide.
+
+ `Rqi'
+ Registers that can hold QI values.
+
+ `Rad'
+ Registers that can be used with displacements ($a0, $a1, $sb).
+
+ `Rsi'
+ Registers that can hold 32 bit values.
+
+ `Rhi'
+ Registers that can hold 16 bit values.
+
+ `Rhc'
+ Registers chat can hold 16 bit values, including all control
+ registers.
+
+ `Rra'
+ $r0 through R1, plus $a0 and $a1.
+
+ `Rfl'
+ The flags register.
+
+ `Rmm'
+ The memory-based pseudo-registers $mem0 through $mem15.
+
+ `Rpi'
+ Registers that can hold pointers (16 bit registers for r8c,
+ m16c; 24 bit registers for m32cm, m32c).
+
+ `Rpa'
+ Matches multiple registers in a PARALLEL to form a larger
+ register. Used to match function return values.
+
+ `Is3'
+ -8 ... 7
+
+ `IS1'
+ -128 ... 127
+
+ `IS2'
+ -32768 ... 32767
+
+ `IU2'
+ 0 ... 65535
+
+ `In4'
+ -8 ... -1 or 1 ... 8
+
+ `In5'
+ -16 ... -1 or 1 ... 16
+
+ `In6'
+ -32 ... -1 or 1 ... 32
+
+ `IM2'
+ -65536 ... -1
+
+ `Ilb'
+ An 8 bit value with exactly one bit set.
+
+ `Ilw'
+ A 16 bit value with exactly one bit set.
+
+ `Sd'
+ The common src/dest memory addressing modes.
+
+ `Sa'
+ Memory addressed using $a0 or $a1.
+
+ `Si'
+ Memory addressed with immediate addresses.
+
+ `Ss'
+ Memory addressed using the stack pointer ($sp).
+
+ `Sf'
+ Memory addressed using the frame base register ($fb).
+
+ `Ss'
+ Memory addressed using the small base register ($sb).
+
+ `S1'
+ $r1h
+
+_MIPS--`config/mips/constraints.md'_
+
+ `d'
+ An address register. This is equivalent to `r' unless
+ generating MIPS16 code.
+
+ `f'
+ A floating-point register (if available).
+
+ `h'
+ Formerly the `hi' register. This constraint is no longer
+ supported.
+
+ `l'
+ The `lo' register. Use this register to store values that are
+ no bigger than a word.
+
+ `x'
+ The concatenated `hi' and `lo' registers. Use this register
+ to store doubleword values.
+
+ `c'
+ A register suitable for use in an indirect jump. This will
+ always be `$25' for `-mabicalls'.
+
+ `v'
+ Register `$3'. Do not use this constraint in new code; it is
+ retained only for compatibility with glibc.
+
+ `y'
+ Equivalent to `r'; retained for backwards compatibility.
+
+ `z'
+ A floating-point condition code register.
+
+ `I'
+ A signed 16-bit constant (for arithmetic instructions).
+
+ `J'
+ Integer zero.
+
+ `K'
+ An unsigned 16-bit constant (for logic instructions).
+
+ `L'
+ A signed 32-bit constant in which the lower 16 bits are zero.
+ Such constants can be loaded using `lui'.
+
+ `M'
+ A constant that cannot be loaded using `lui', `addiu' or
+ `ori'.
+
+ `N'
+ A constant in the range -65535 to -1 (inclusive).
+
+ `O'
+ A signed 15-bit constant.
+
+ `P'
+ A constant in the range 1 to 65535 (inclusive).
+
+ `G'
+ Floating-point zero.
+
+ `R'
+ An address that can be used in a non-macro load or store.
+
+_Motorola 680x0--`config/m68k/constraints.md'_
+
+ `a'
+ Address register
+
+ `d'
+ Data register
+
+ `f'
+ 68881 floating-point register, if available
+
+ `I'
+ Integer in the range 1 to 8
+
+ `J'
+ 16-bit signed number
+
+ `K'
+ Signed number whose magnitude is greater than 0x80
+
+ `L'
+ Integer in the range -8 to -1
+
+ `M'
+ Signed number whose magnitude is greater than 0x100
+
+ `N'
+ Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate
+
+ `O'
+ 16 (for rotate using swap)
+
+ `P'
+ Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate
+
+ `R'
+ Numbers that mov3q can handle
+
+ `G'
+ Floating point constant that is not a 68881 constant
+
+ `S'
+ Operands that satisfy 'm' when -mpcrel is in effect
+
+ `T'
+ Operands that satisfy 's' when -mpcrel is not in effect
+
+ `Q'
+ Address register indirect addressing mode
+
+ `U'
+ Register offset addressing
+
+ `W'
+ const_call_operand
+
+ `Cs'
+ symbol_ref or const
+
+ `Ci'
+ const_int
+
+ `C0'
+ const_int 0
+
+ `Cj'
+ Range of signed numbers that don't fit in 16 bits
+
+ `Cmvq'
+ Integers valid for mvq
+
+ `Capsw'
+ Integers valid for a moveq followed by a swap
+
+ `Cmvz'
+ Integers valid for mvz
+
+ `Cmvs'
+ Integers valid for mvs
+
+ `Ap'
+ push_operand
+
+ `Ac'
+ Non-register operands allowed in clr
+
+
+_Motorola 68HC11 & 68HC12 families--`config/m68hc11/m68hc11.h'_
+
+ `a'
+ Register `a'
+
+ `b'
+ Register `b'
+
+ `d'
+ Register `d'
+
+ `q'
+ An 8-bit register
+
+ `t'
+ Temporary soft register _.tmp
+
+ `u'
+ A soft register _.d1 to _.d31
+
+ `w'
+ Stack pointer register
+
+ `x'
+ Register `x'
+
+ `y'
+ Register `y'
+
+ `z'
+ Pseudo register `z' (replaced by `x' or `y' at the end)
+
+ `A'
+ An address register: x, y or z
+
+ `B'
+ An address register: x or y
+
+ `D'
+ Register pair (x:d) to form a 32-bit value
+
+ `L'
+ Constants in the range -65536 to 65535
+
+ `M'
+ Constants whose 16-bit low part is zero
+
+ `N'
+ Constant integer 1 or -1
+
+ `O'
+ Constant integer 16
+
+ `P'
+ Constants in the range -8 to 2
+
+
+_SPARC--`config/sparc/sparc.h'_
+
+ `f'
+ Floating-point register on the SPARC-V8 architecture and
+ lower floating-point register on the SPARC-V9 architecture.
+
+ `e'
+ Floating-point register. It is equivalent to `f' on the
+ SPARC-V8 architecture and contains both lower and upper
+ floating-point registers on the SPARC-V9 architecture.
+
+ `c'
+ Floating-point condition code register.
+
+ `d'
+ Lower floating-point register. It is only valid on the
+ SPARC-V9 architecture when the Visual Instruction Set is
+ available.
+
+ `b'
+ Floating-point register. It is only valid on the SPARC-V9
+ architecture when the Visual Instruction Set is available.
+
+ `h'
+ 64-bit global or out register for the SPARC-V8+ architecture.
+
+ `D'
+ A vector constant
+
+ `I'
+ Signed 13-bit constant
+
+ `J'
+ Zero
+
+ `K'
+ 32-bit constant with the low 12 bits clear (a constant that
+ can be loaded with the `sethi' instruction)
+
+ `L'
+ A constant in the range supported by `movcc' instructions
+
+ `M'
+ A constant in the range supported by `movrcc' instructions
+
+ `N'
+ Same as `K', except that it verifies that bits that are not
+ in the lower 32-bit range are all zero. Must be used instead
+ of `K' for modes wider than `SImode'
+
+ `O'
+ The constant 4096
+
+ `G'
+ Floating-point zero
+
+ `H'
+ Signed 13-bit constant, sign-extended to 32 or 64 bits
+
+ `Q'
+ Floating-point constant whose integral representation can be
+ moved into an integer register using a single sethi
+ instruction
+
+ `R'
+ Floating-point constant whose integral representation can be
+ moved into an integer register using a single mov instruction
+
+ `S'
+ Floating-point constant whose integral representation can be
+ moved into an integer register using a high/lo_sum
+ instruction sequence
+
+ `T'
+ Memory address aligned to an 8-byte boundary
+
+ `U'
+ Even register
+
+ `W'
+ Memory address for `e' constraint registers
+
+ `Y'
+ Vector zero
+
+
+_SPU--`config/spu/spu.h'_
+
+ `a'
+ An immediate which can be loaded with the il/ila/ilh/ilhu
+ instructions. const_int is treated as a 64 bit value.
+
+ `c'
+ An immediate for and/xor/or instructions. const_int is
+ treated as a 64 bit value.
+
+ `d'
+ An immediate for the `iohl' instruction. const_int is
+ treated as a 64 bit value.
+
+ `f'
+ An immediate which can be loaded with `fsmbi'.
+
+ `A'
+ An immediate which can be loaded with the il/ila/ilh/ilhu
+ instructions. const_int is treated as a 32 bit value.
+
+ `B'
+ An immediate for most arithmetic instructions. const_int is
+ treated as a 32 bit value.
+
+ `C'
+ An immediate for and/xor/or instructions. const_int is
+ treated as a 32 bit value.
+
+ `D'
+ An immediate for the `iohl' instruction. const_int is
+ treated as a 32 bit value.
+
+ `I'
+ A constant in the range [-64, 63] for shift/rotate
+ instructions.
+
+ `J'
+ An unsigned 7-bit constant for conversion/nop/channel
+ instructions.
+
+ `K'
+ A signed 10-bit constant for most arithmetic instructions.
+
+ `M'
+ A signed 16 bit immediate for `stop'.
+
+ `N'
+ An unsigned 16-bit constant for `iohl' and `fsmbi'.
+
+ `O'
+ An unsigned 7-bit constant whose 3 least significant bits are
+ 0.
+
+ `P'
+ An unsigned 3-bit constant for 16-byte rotates and shifts
+
+ `R'
+ Call operand, reg, for indirect calls
+
+ `S'
+ Call operand, symbol, for relative calls.
+
+ `T'
+ Call operand, const_int, for absolute calls.
+
+ `U'
+ An immediate which can be loaded with the il/ila/ilh/ilhu
+ instructions. const_int is sign extended to 128 bit.
+
+ `W'
+ An immediate for shift and rotate instructions. const_int is
+ treated as a 32 bit value.
+
+ `Y'
+ An immediate for and/xor/or instructions. const_int is sign
+ extended as a 128 bit.
+
+ `Z'
+ An immediate for the `iohl' instruction. const_int is sign
+ extended to 128 bit.
+
+
+_S/390 and zSeries--`config/s390/s390.h'_
+
+ `a'
+ Address register (general purpose register except r0)
+
+ `c'
+ Condition code register
+
+ `d'
+ Data register (arbitrary general purpose register)
+
+ `f'
+ Floating-point register
+
+ `I'
+ Unsigned 8-bit constant (0-255)
+
+ `J'
+ Unsigned 12-bit constant (0-4095)
+
+ `K'
+ Signed 16-bit constant (-32768-32767)
+
+ `L'
+ Value appropriate as displacement.
+ `(0..4095)'
+ for short displacement
+
+ `(-524288..524287)'
+ for long displacement
+
+ `M'
+ Constant integer with a value of 0x7fffffff.
+
+ `N'
+ Multiple letter constraint followed by 4 parameter letters.
+ `0..9:'
+ number of the part counting from most to least
+ significant
+
+ `H,Q:'
+ mode of the part
+
+ `D,S,H:'
+ mode of the containing operand
+
+ `0,F:'
+ value of the other parts (F--all bits set)
+ The constraint matches if the specified part of a constant
+ has a value different from its other parts.
+
+ `Q'
+ Memory reference without index register and with short
+ displacement.
+
+ `R'
+ Memory reference with index register and short displacement.
+
+ `S'
+ Memory reference without index register but with long
+ displacement.
+
+ `T'
+ Memory reference with index register and long displacement.
+
+ `U'
+ Pointer with short displacement.
+
+ `W'
+ Pointer with long displacement.
+
+ `Y'
+ Shift count operand.
+
+
+_Score family--`config/score/score.h'_
+
+ `d'
+ Registers from r0 to r32.
+
+ `e'
+ Registers from r0 to r16.
+
+ `t'
+ r8--r11 or r22--r27 registers.
+
+ `h'
+ hi register.
+
+ `l'
+ lo register.
+
+ `x'
+ hi + lo register.
+
+ `q'
+ cnt register.
+
+ `y'
+ lcb register.
+
+ `z'
+ scb register.
+
+ `a'
+ cnt + lcb + scb register.
+
+ `c'
+ cr0--cr15 register.
+
+ `b'
+ cp1 registers.
+
+ `f'
+ cp2 registers.
+
+ `i'
+ cp3 registers.
+
+ `j'
+ cp1 + cp2 + cp3 registers.
+
+ `I'
+ High 16-bit constant (32-bit constant with 16 LSBs zero).
+
+ `J'
+ Unsigned 5 bit integer (in the range 0 to 31).
+
+ `K'
+ Unsigned 16 bit integer (in the range 0 to 65535).
+
+ `L'
+ Signed 16 bit integer (in the range -32768 to 32767).
+
+ `M'
+ Unsigned 14 bit integer (in the range 0 to 16383).
+
+ `N'
+ Signed 14 bit integer (in the range -8192 to 8191).
+
+ `Z'
+ Any SYMBOL_REF.
+
+_Xstormy16--`config/stormy16/stormy16.h'_
+
+ `a'
+ Register r0.
+
+ `b'
+ Register r1.
+
+ `c'
+ Register r2.
+
+ `d'
+ Register r8.
+
+ `e'
+ Registers r0 through r7.
+
+ `t'
+ Registers r0 and r1.
+
+ `y'
+ The carry register.
+
+ `z'
+ Registers r8 and r9.
+
+ `I'
+ A constant between 0 and 3 inclusive.
+
+ `J'
+ A constant that has exactly one bit set.
+
+ `K'
+ A constant that has exactly one bit clear.
+
+ `L'
+ A constant between 0 and 255 inclusive.
+
+ `M'
+ A constant between -255 and 0 inclusive.
+
+ `N'
+ A constant between -3 and 0 inclusive.
+
+ `O'
+ A constant between 1 and 4 inclusive.
+
+ `P'
+ A constant between -4 and -1 inclusive.
+
+ `Q'
+ A memory reference that is a stack push.
+
+ `R'
+ A memory reference that is a stack pop.
+
+ `S'
+ A memory reference that refers to a constant address of known
+ value.
+
+ `T'
+ The register indicated by Rx (not implemented yet).
+
+ `U'
+ A constant that is not between 2 and 15 inclusive.
+
+ `Z'
+ The constant 0.
+
+
+_Xtensa--`config/xtensa/constraints.md'_
+
+ `a'
+ General-purpose 32-bit register
+
+ `b'
+ One-bit boolean register
+
+ `A'
+ MAC16 40-bit accumulator register
+
+ `I'
+ Signed 12-bit integer constant, for use in MOVI instructions
+
+ `J'
+ Signed 8-bit integer constant, for use in ADDI instructions
+
+ `K'
+ Integer constant valid for BccI instructions
+
+ `L'
+ Unsigned constant valid for BccUI instructions
+
+
+
+\1f
+File: gccint.info, Node: Disable Insn Alternatives, Next: Machine Constraints, Prev: Modifiers, Up: Constraints
+
+16.8.6 Disable insn alternatives using the `enabled' attribute
+--------------------------------------------------------------
+
+The `enabled' insn attribute may be used to disable certain insn
+alternatives for machine-specific reasons. This is useful when adding
+new instructions to an existing pattern which are only available for
+certain cpu architecture levels as specified with the `-march=' option.
+
+ If an insn alternative is disabled, then it will never be used. The
+compiler treats the constraints for the disabled alternative as
+unsatisfiable.
+
+ In order to make use of the `enabled' attribute a back end has to add
+in the machine description files:
+
+ 1. A definition of the `enabled' insn attribute. The attribute is
+ defined as usual using the `define_attr' command. This definition
+ should be based on other insn attributes and/or target flags. The
+ `enabled' attribute is a numeric attribute and should evaluate to
+ `(const_int 1)' for an enabled alternative and to `(const_int 0)'
+ otherwise.
+
+ 2. A definition of another insn attribute used to describe for what
+ reason an insn alternative might be available or not. E.g.
+ `cpu_facility' as in the example below.
+
+ 3. An assignment for the second attribute to each insn definition
+ combining instructions which are not all available under the same
+ circumstances. (Note: It obviously only makes sense for
+ definitions with more than one alternative. Otherwise the insn
+ pattern should be disabled or enabled using the insn condition.)
+
+ E.g. the following two patterns could easily be merged using the
+`enabled' attribute:
+
+
+ (define_insn "*movdi_old"
+ [(set (match_operand:DI 0 "register_operand" "=d")
+ (match_operand:DI 1 "register_operand" " d"))]
+ "!TARGET_NEW"
+ "lgr %0,%1")
+
+ (define_insn "*movdi_new"
+ [(set (match_operand:DI 0 "register_operand" "=d,f,d")
+ (match_operand:DI 1 "register_operand" " d,d,f"))]
+ "TARGET_NEW"
+ "@
+ lgr %0,%1
+ ldgr %0,%1
+ lgdr %0,%1")
+
+ to:
+
+
+ (define_insn "*movdi_combined"
+ [(set (match_operand:DI 0 "register_operand" "=d,f,d")
+ (match_operand:DI 1 "register_operand" " d,d,f"))]
+ ""
+ "@
+ lgr %0,%1
+ ldgr %0,%1
+ lgdr %0,%1"
+ [(set_attr "cpu_facility" "*,new,new")])
+
+ with the `enabled' attribute defined like this:
+
+
+ (define_attr "cpu_facility" "standard,new" (const_string "standard"))
+
+ (define_attr "enabled" ""
+ (cond [(eq_attr "cpu_facility" "standard") (const_int 1)
+ (and (eq_attr "cpu_facility" "new")
+ (ne (symbol_ref "TARGET_NEW") (const_int 0)))
+ (const_int 1)]
+ (const_int 0)))
+
+\1f
+File: gccint.info, Node: Define Constraints, Next: C Constraint Interface, Prev: Machine Constraints, Up: Constraints
+
+16.8.7 Defining Machine-Specific Constraints
+--------------------------------------------
+
+Machine-specific constraints fall into two categories: register and
+non-register constraints. Within the latter category, constraints
+which allow subsets of all possible memory or address operands should
+be specially marked, to give `reload' more information.
+
+ Machine-specific constraints can be given names of arbitrary length,
+but they must be entirely composed of letters, digits, underscores
+(`_'), and angle brackets (`< >'). Like C identifiers, they must begin
+with a letter or underscore.
+
+ In order to avoid ambiguity in operand constraint strings, no
+constraint can have a name that begins with any other constraint's
+name. For example, if `x' is defined as a constraint name, `xy' may
+not be, and vice versa. As a consequence of this rule, no constraint
+may begin with one of the generic constraint letters: `E F V X g i m n
+o p r s'.
+
+ Register constraints correspond directly to register classes. *Note
+Register Classes::. There is thus not much flexibility in their
+definitions.
+
+ -- MD Expression: define_register_constraint name regclass docstring
+ All three arguments are string constants. NAME is the name of the
+ constraint, as it will appear in `match_operand' expressions. If
+ NAME is a multi-letter constraint its length shall be the same for
+ all constraints starting with the same letter. REGCLASS can be
+ either the name of the corresponding register class (*note
+ Register Classes::), or a C expression which evaluates to the
+ appropriate register class. If it is an expression, it must have
+ no side effects, and it cannot look at the operand. The usual use
+ of expressions is to map some register constraints to `NO_REGS'
+ when the register class is not available on a given
+ subarchitecture.
+
+ DOCSTRING is a sentence documenting the meaning of the constraint.
+ Docstrings are explained further below.
+
+ Non-register constraints are more like predicates: the constraint
+definition gives a Boolean expression which indicates whether the
+constraint matches.
+
+ -- MD Expression: define_constraint name docstring exp
+ The NAME and DOCSTRING arguments are the same as for
+ `define_register_constraint', but note that the docstring comes
+ immediately after the name for these expressions. EXP is an RTL
+ expression, obeying the same rules as the RTL expressions in
+ predicate definitions. *Note Defining Predicates::, for details.
+ If it evaluates true, the constraint matches; if it evaluates
+ false, it doesn't. Constraint expressions should indicate which
+ RTL codes they might match, just like predicate expressions.
+
+ `match_test' C expressions have access to the following variables:
+
+ OP
+ The RTL object defining the operand.
+
+ MODE
+ The machine mode of OP.
+
+ IVAL
+ `INTVAL (OP)', if OP is a `const_int'.
+
+ HVAL
+ `CONST_DOUBLE_HIGH (OP)', if OP is an integer `const_double'.
+
+ LVAL
+ `CONST_DOUBLE_LOW (OP)', if OP is an integer `const_double'.
+
+ RVAL
+ `CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point
+ `const_double'.
+
+ The *VAL variables should only be used once another piece of the
+ expression has verified that OP is the appropriate kind of RTL
+ object.
+
+ Most non-register constraints should be defined with
+`define_constraint'. The remaining two definition expressions are only
+appropriate for constraints that should be handled specially by
+`reload' if they fail to match.
+
+ -- MD Expression: define_memory_constraint name docstring exp
+ Use this expression for constraints that match a subset of all
+ memory operands: that is, `reload' can make them match by
+ converting the operand to the form `(mem (reg X))', where X is a
+ base register (from the register class specified by
+ `BASE_REG_CLASS', *note Register Classes::).
+
+ For example, on the S/390, some instructions do not accept
+ arbitrary memory references, but only those that do not make use
+ of an index register. The constraint letter `Q' is defined to
+ represent a memory address of this type. If `Q' is defined with
+ `define_memory_constraint', a `Q' constraint can handle any memory
+ operand, because `reload' knows it can simply copy the memory
+ address into a base register if required. This is analogous to
+ the way a `o' constraint can handle any memory operand.
+
+ The syntax and semantics are otherwise identical to
+ `define_constraint'.
+
+ -- MD Expression: define_address_constraint name docstring exp
+ Use this expression for constraints that match a subset of all
+ address operands: that is, `reload' can make the constraint match
+ by converting the operand to the form `(reg X)', again with X a
+ base register.
+
+ Constraints defined with `define_address_constraint' can only be
+ used with the `address_operand' predicate, or machine-specific
+ predicates that work the same way. They are treated analogously to
+ the generic `p' constraint.
+
+ The syntax and semantics are otherwise identical to
+ `define_constraint'.
+
+ For historical reasons, names beginning with the letters `G H' are
+reserved for constraints that match only `const_double's, and names
+beginning with the letters `I J K L M N O P' are reserved for
+constraints that match only `const_int's. This may change in the
+future. For the time being, constraints with these names must be
+written in a stylized form, so that `genpreds' can tell you did it
+correctly:
+
+ (define_constraint "[GHIJKLMNOP]..."
+ "DOC..."
+ (and (match_code "const_int") ; `const_double' for G/H
+ CONDITION...)) ; usually a `match_test'
+
+ It is fine to use names beginning with other letters for constraints
+that match `const_double's or `const_int's.
+
+ Each docstring in a constraint definition should be one or more
+complete sentences, marked up in Texinfo format. _They are currently
+unused._ In the future they will be copied into the GCC manual, in
+*note Machine Constraints::, replacing the hand-maintained tables
+currently found in that section. Also, in the future the compiler may
+use this to give more helpful diagnostics when poor choice of `asm'
+constraints causes a reload failure.
+
+ If you put the pseudo-Texinfo directive `@internal' at the beginning
+of a docstring, then (in the future) it will appear only in the
+internals manual's version of the machine-specific constraint tables.
+Use this for constraints that should not appear in `asm' statements.
+
+\1f
+File: gccint.info, Node: C Constraint Interface, Prev: Define Constraints, Up: Constraints
+
+16.8.8 Testing constraints from C
+---------------------------------
+
+It is occasionally useful to test a constraint from C code rather than
+implicitly via the constraint string in a `match_operand'. The
+generated file `tm_p.h' declares a few interfaces for working with
+machine-specific constraints. None of these interfaces work with the
+generic constraints described in *note Simple Constraints::. This may
+change in the future.
+
+ *Warning:* `tm_p.h' may declare other functions that operate on
+constraints, besides the ones documented here. Do not use those
+functions from machine-dependent code. They exist to implement the old
+constraint interface that machine-independent components of the
+compiler still expect. They will change or disappear in the future.
+
+ Some valid constraint names are not valid C identifiers, so there is a
+mangling scheme for referring to them from C. Constraint names that do
+not contain angle brackets or underscores are left unchanged.
+Underscores are doubled, each `<' is replaced with `_l', and each `>'
+with `_g'. Here are some examples:
+
+ *Original* *Mangled*
+ `x' `x'
+ `P42x' `P42x'
+ `P4_x' `P4__x'
+ `P4>x' `P4_gx'
+ `P4>>' `P4_g_g'
+ `P4_g>' `P4__g_g'
+
+ Throughout this section, the variable C is either a constraint in the
+abstract sense, or a constant from `enum constraint_num'; the variable
+M is a mangled constraint name (usually as part of a larger identifier).
+
+ -- Enum: constraint_num
+ For each machine-specific constraint, there is a corresponding
+ enumeration constant: `CONSTRAINT_' plus the mangled name of the
+ constraint. Functions that take an `enum constraint_num' as an
+ argument expect one of these constants.
+
+ Machine-independent constraints do not have associated constants.
+ This may change in the future.
+
+ -- Function: inline bool satisfies_constraint_M (rtx EXP)
+ For each machine-specific, non-register constraint M, there is one
+ of these functions; it returns `true' if EXP satisfies the
+ constraint. These functions are only visible if `rtl.h' was
+ included before `tm_p.h'.
+
+ -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num
+ C)
+ Like the `satisfies_constraint_M' functions, but the constraint to
+ test is given as an argument, C. If C specifies a register
+ constraint, this function will always return `false'.
+
+ -- Function: enum reg_class regclass_for_constraint (enum
+ constraint_num C)
+ Returns the register class associated with C. If C is not a
+ register constraint, or those registers are not available for the
+ currently selected subtarget, returns `NO_REGS'.
+
+ Here is an example use of `satisfies_constraint_M'. In peephole
+optimizations (*note Peephole Definitions::), operand constraint
+strings are ignored, so if there are relevant constraints, they must be
+tested in the C condition. In the example, the optimization is applied
+if operand 2 does _not_ satisfy the `K' constraint. (This is a
+simplified version of a peephole definition from the i386 machine
+description.)
+
+ (define_peephole2
+ [(match_scratch:SI 3 "r")
+ (set (match_operand:SI 0 "register_operand" "")
+ (mult:SI (match_operand:SI 1 "memory_operand" "")
+ (match_operand:SI 2 "immediate_operand" "")))]
+
+ "!satisfies_constraint_K (operands[2])"
+
+ [(set (match_dup 3) (match_dup 1))
+ (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))]
+
+ "")
+
+\1f
+File: gccint.info, Node: Standard Names, Next: Pattern Ordering, Prev: Constraints, Up: Machine Desc
+
+16.9 Standard Pattern Names For Generation
+==========================================
+
+Here is a table of the instruction names that are meaningful in the RTL
+generation pass of the compiler. Giving one of these names to an
+instruction pattern tells the RTL generation pass that it can use the
+pattern to accomplish a certain task.
+
+`movM'
+ Here M stands for a two-letter machine mode name, in lowercase.
+ This instruction pattern moves data with that machine mode from
+ operand 1 to operand 0. For example, `movsi' moves full-word data.
+
+ If operand 0 is a `subreg' with mode M of a register whose own
+ mode is wider than M, the effect of this instruction is to store
+ the specified value in the part of the register that corresponds
+ to mode M. Bits outside of M, but which are within the same
+ target word as the `subreg' are undefined. Bits which are outside
+ the target word are left unchanged.
+
+ This class of patterns is special in several ways. First of all,
+ each of these names up to and including full word size _must_ be
+ defined, because there is no other way to copy a datum from one
+ place to another. If there are patterns accepting operands in
+ larger modes, `movM' must be defined for integer modes of those
+ sizes.
+
+ Second, these patterns are not used solely in the RTL generation
+ pass. Even the reload pass can generate move insns to copy values
+ from stack slots into temporary registers. When it does so, one
+ of the operands is a hard register and the other is an operand
+ that can need to be reloaded into a register.
+
+ Therefore, when given such a pair of operands, the pattern must
+ generate RTL which needs no reloading and needs no temporary
+ registers--no registers other than the operands. For example, if
+ you support the pattern with a `define_expand', then in such a
+ case the `define_expand' mustn't call `force_reg' or any other such
+ function which might generate new pseudo registers.
+
+ This requirement exists even for subword modes on a RISC machine
+ where fetching those modes from memory normally requires several
+ insns and some temporary registers.
+
+ During reload a memory reference with an invalid address may be
+ passed as an operand. Such an address will be replaced with a
+ valid address later in the reload pass. In this case, nothing may
+ be done with the address except to use it as it stands. If it is
+ copied, it will not be replaced with a valid address. No attempt
+ should be made to make such an address into a valid address and no
+ routine (such as `change_address') that will do so may be called.
+ Note that `general_operand' will fail when applied to such an
+ address.
+
+ The global variable `reload_in_progress' (which must be explicitly
+ declared if required) can be used to determine whether such special
+ handling is required.
+
+ The variety of operands that have reloads depends on the rest of
+ the machine description, but typically on a RISC machine these can
+ only be pseudo registers that did not get hard registers, while on
+ other machines explicit memory references will get optional
+ reloads.
+
+ If a scratch register is required to move an object to or from
+ memory, it can be allocated using `gen_reg_rtx' prior to life
+ analysis.
+
+ If there are cases which need scratch registers during or after
+ reload, you must provide an appropriate secondary_reload target
+ hook.
+
+ The macro `can_create_pseudo_p' can be used to determine if it is
+ unsafe to create new pseudo registers. If this variable is
+ nonzero, then it is unsafe to call `gen_reg_rtx' to allocate a new
+ pseudo.
+
+ The constraints on a `movM' must permit moving any hard register
+ to any other hard register provided that `HARD_REGNO_MODE_OK'
+ permits mode M in both registers and `REGISTER_MOVE_COST' applied
+ to their classes returns a value of 2.
+
+ It is obligatory to support floating point `movM' instructions
+ into and out of any registers that can hold fixed point values,
+ because unions and structures (which have modes `SImode' or
+ `DImode') can be in those registers and they may have floating
+ point members.
+
+ There may also be a need to support fixed point `movM'
+ instructions in and out of floating point registers.
+ Unfortunately, I have forgotten why this was so, and I don't know
+ whether it is still true. If `HARD_REGNO_MODE_OK' rejects fixed
+ point values in floating point registers, then the constraints of
+ the fixed point `movM' instructions must be designed to avoid ever
+ trying to reload into a floating point register.
+
+`reload_inM'
+`reload_outM'
+ These named patterns have been obsoleted by the target hook
+ `secondary_reload'.
+
+ Like `movM', but used when a scratch register is required to move
+ between operand 0 and operand 1. Operand 2 describes the scratch
+ register. See the discussion of the `SECONDARY_RELOAD_CLASS'
+ macro in *note Register Classes::.
+
+ There are special restrictions on the form of the `match_operand's
+ used in these patterns. First, only the predicate for the reload
+ operand is examined, i.e., `reload_in' examines operand 1, but not
+ the predicates for operand 0 or 2. Second, there may be only one
+ alternative in the constraints. Third, only a single register
+ class letter may be used for the constraint; subsequent constraint
+ letters are ignored. As a special exception, an empty constraint
+ string matches the `ALL_REGS' register class. This may relieve
+ ports of the burden of defining an `ALL_REGS' constraint letter
+ just for these patterns.
+
+`movstrictM'
+ Like `movM' except that if operand 0 is a `subreg' with mode M of
+ a register whose natural mode is wider, the `movstrictM'
+ instruction is guaranteed not to alter any of the register except
+ the part which belongs to mode M.
+
+`movmisalignM'
+ This variant of a move pattern is designed to load or store a value
+ from a memory address that is not naturally aligned for its mode.
+ For a store, the memory will be in operand 0; for a load, the
+ memory will be in operand 1. The other operand is guaranteed not
+ to be a memory, so that it's easy to tell whether this is a load
+ or store.
+
+ This pattern is used by the autovectorizer, and when expanding a
+ `MISALIGNED_INDIRECT_REF' expression.
+
+`load_multiple'
+ Load several consecutive memory locations into consecutive
+ registers. Operand 0 is the first of the consecutive registers,
+ operand 1 is the first memory location, and operand 2 is a
+ constant: the number of consecutive registers.
+
+ Define this only if the target machine really has such an
+ instruction; do not define this if the most efficient way of
+ loading consecutive registers from memory is to do them one at a
+ time.
+
+ On some machines, there are restrictions as to which consecutive
+ registers can be stored into memory, such as particular starting or
+ ending register numbers or only a range of valid counts. For those
+ machines, use a `define_expand' (*note Expander Definitions::) and
+ make the pattern fail if the restrictions are not met.
+
+ Write the generated insn as a `parallel' with elements being a
+ `set' of one register from the appropriate memory location (you may
+ also need `use' or `clobber' elements). Use a `match_parallel'
+ (*note RTL Template::) to recognize the insn. See `rs6000.md' for
+ examples of the use of this insn pattern.
+
+`store_multiple'
+ Similar to `load_multiple', but store several consecutive registers
+ into consecutive memory locations. Operand 0 is the first of the
+ consecutive memory locations, operand 1 is the first register, and
+ operand 2 is a constant: the number of consecutive registers.
+
+`vec_setM'
+ Set given field in the vector value. Operand 0 is the vector to
+ modify, operand 1 is new value of field and operand 2 specify the
+ field index.
+
+`vec_extractM'
+ Extract given field from the vector value. Operand 1 is the
+ vector, operand 2 specify field index and operand 0 place to store
+ value into.
+
+`vec_extract_evenM'
+ Extract even elements from the input vectors (operand 1 and
+ operand 2). The even elements of operand 2 are concatenated to
+ the even elements of operand 1 in their original order. The result
+ is stored in operand 0. The output and input vectors should have
+ the same modes.
+
+`vec_extract_oddM'
+ Extract odd elements from the input vectors (operand 1 and operand
+ 2). The odd elements of operand 2 are concatenated to the odd
+ elements of operand 1 in their original order. The result is
+ stored in operand 0. The output and input vectors should have the
+ same modes.
+
+`vec_interleave_highM'
+ Merge high elements of the two input vectors into the output
+ vector. The output and input vectors should have the same modes
+ (`N' elements). The high `N/2' elements of the first input vector
+ are interleaved with the high `N/2' elements of the second input
+ vector.
+
+`vec_interleave_lowM'
+ Merge low elements of the two input vectors into the output
+ vector. The output and input vectors should have the same modes
+ (`N' elements). The low `N/2' elements of the first input vector
+ are interleaved with the low `N/2' elements of the second input
+ vector.
+
+`vec_initM'
+ Initialize the vector to given values. Operand 0 is the vector to
+ initialize and operand 1 is parallel containing values for
+ individual fields.
+
+`pushM1'
+ Output a push instruction. Operand 0 is value to push. Used only
+ when `PUSH_ROUNDING' is defined. For historical reason, this
+ pattern may be missing and in such case an `mov' expander is used
+ instead, with a `MEM' expression forming the push operation. The
+ `mov' expander method is deprecated.
+
+`addM3'
+ Add operand 2 and operand 1, storing the result in operand 0. All
+ operands must have mode M. This can be used even on two-address
+ machines, by means of constraints requiring operands 1 and 0 to be
+ the same location.
+
+`ssaddM3', `usaddM3'
+
+`subM3', `sssubM3', `ussubM3'
+
+`mulM3', `ssmulM3', `usmulM3'
+`divM3', `ssdivM3'
+`udivM3', `usdivM3'
+`modM3', `umodM3'
+`uminM3', `umaxM3'
+`andM3', `iorM3', `xorM3'
+ Similar, for other arithmetic operations.
+
+`sminM3', `smaxM3'
+ Signed minimum and maximum operations. When used with floating
+ point, if both operands are zeros, or if either operand is `NaN',
+ then it is unspecified which of the two operands is returned as
+ the result.
+
+`reduc_smin_M', `reduc_smax_M'
+ Find the signed minimum/maximum of the elements of a vector. The
+ vector is operand 1, and the scalar result is stored in the least
+ significant bits of operand 0 (also a vector). The output and
+ input vector should have the same modes.
+
+`reduc_umin_M', `reduc_umax_M'
+ Find the unsigned minimum/maximum of the elements of a vector. The
+ vector is operand 1, and the scalar result is stored in the least
+ significant bits of operand 0 (also a vector). The output and
+ input vector should have the same modes.
+
+`reduc_splus_M'
+ Compute the sum of the signed elements of a vector. The vector is
+ operand 1, and the scalar result is stored in the least
+ significant bits of operand 0 (also a vector). The output and
+ input vector should have the same modes.
+
+`reduc_uplus_M'
+ Compute the sum of the unsigned elements of a vector. The vector
+ is operand 1, and the scalar result is stored in the least
+ significant bits of operand 0 (also a vector). The output and
+ input vector should have the same modes.
+
+`sdot_prodM'
+
+`udot_prodM'
+ Compute the sum of the products of two signed/unsigned elements.
+ Operand 1 and operand 2 are of the same mode. Their product, which
+ is of a wider mode, is computed and added to operand 3. Operand 3
+ is of a mode equal or wider than the mode of the product. The
+ result is placed in operand 0, which is of the same mode as
+ operand 3.
+
+`ssum_widenM3'
+
+`usum_widenM3'
+ Operands 0 and 2 are of the same mode, which is wider than the
+ mode of operand 1. Add operand 1 to operand 2 and place the
+ widened result in operand 0. (This is used express accumulation of
+ elements into an accumulator of a wider mode.)
+
+`vec_shl_M', `vec_shr_M'
+ Whole vector left/right shift in bits. Operand 1 is a vector to
+ be shifted. Operand 2 is an integer shift amount in bits.
+ Operand 0 is where the resulting shifted vector is stored. The
+ output and input vectors should have the same modes.
+
+`vec_pack_trunc_M'
+ Narrow (demote) and merge the elements of two vectors. Operands 1
+ and 2 are vectors of the same mode having N integral or floating
+ point elements of size S. Operand 0 is the resulting vector in
+ which 2*N elements of size N/2 are concatenated after narrowing
+ them down using truncation.
+
+`vec_pack_ssat_M', `vec_pack_usat_M'
+ Narrow (demote) and merge the elements of two vectors. Operands 1
+ and 2 are vectors of the same mode having N integral elements of
+ size S. Operand 0 is the resulting vector in which the elements
+ of the two input vectors are concatenated after narrowing them
+ down using signed/unsigned saturating arithmetic.
+
+`vec_pack_sfix_trunc_M', `vec_pack_ufix_trunc_M'
+ Narrow, convert to signed/unsigned integral type and merge the
+ elements of two vectors. Operands 1 and 2 are vectors of the same
+ mode having N floating point elements of size S. Operand 0 is the
+ resulting vector in which 2*N elements of size N/2 are
+ concatenated.
+
+`vec_unpacks_hi_M', `vec_unpacks_lo_M'
+ Extract and widen (promote) the high/low part of a vector of signed
+ integral or floating point elements. The input vector (operand 1)
+ has N elements of size S. Widen (promote) the high/low elements
+ of the vector using signed or floating point extension and place
+ the resulting N/2 values of size 2*S in the output vector (operand
+ 0).
+
+`vec_unpacku_hi_M', `vec_unpacku_lo_M'
+ Extract and widen (promote) the high/low part of a vector of
+ unsigned integral elements. The input vector (operand 1) has N
+ elements of size S. Widen (promote) the high/low elements of the
+ vector using zero extension and place the resulting N/2 values of
+ size 2*S in the output vector (operand 0).
+
+`vec_unpacks_float_hi_M', `vec_unpacks_float_lo_M'
+`vec_unpacku_float_hi_M', `vec_unpacku_float_lo_M'
+ Extract, convert to floating point type and widen the high/low
+ part of a vector of signed/unsigned integral elements. The input
+ vector (operand 1) has N elements of size S. Convert the high/low
+ elements of the vector using floating point conversion and place
+ the resulting N/2 values of size 2*S in the output vector (operand
+ 0).
+
+`vec_widen_umult_hi_M', `vec_widen_umult_lo_M'
+`vec_widen_smult_hi_M', `vec_widen_smult_lo_M'
+ Signed/Unsigned widening multiplication. The two inputs (operands
+ 1 and 2) are vectors with N signed/unsigned elements of size S.
+ Multiply the high/low elements of the two vectors, and put the N/2
+ products of size 2*S in the output vector (operand 0).
+
+`mulhisi3'
+ Multiply operands 1 and 2, which have mode `HImode', and store a
+ `SImode' product in operand 0.
+
+`mulqihi3', `mulsidi3'
+ Similar widening-multiplication instructions of other widths.
+
+`umulqihi3', `umulhisi3', `umulsidi3'
+ Similar widening-multiplication instructions that do unsigned
+ multiplication.
+
+`usmulqihi3', `usmulhisi3', `usmulsidi3'
+ Similar widening-multiplication instructions that interpret the
+ first operand as unsigned and the second operand as signed, then
+ do a signed multiplication.
+
+`smulM3_highpart'
+ Perform a signed multiplication of operands 1 and 2, which have
+ mode M, and store the most significant half of the product in
+ operand 0. The least significant half of the product is discarded.
+
+`umulM3_highpart'
+ Similar, but the multiplication is unsigned.
+
+`maddMN4'
+ Multiply operands 1 and 2, sign-extend them to mode N, add operand
+ 3, and store the result in operand 0. Operands 1 and 2 have mode
+ M and operands 0 and 3 have mode N. Both modes must be integer or
+ fixed-point modes and N must be twice the size of M.
+
+ In other words, `maddMN4' is like `mulMN3' except that it also
+ adds operand 3.
+
+ These instructions are not allowed to `FAIL'.
+
+`umaddMN4'
+ Like `maddMN4', but zero-extend the multiplication operands
+ instead of sign-extending them.
+
+`ssmaddMN4'
+ Like `maddMN4', but all involved operations must be
+ signed-saturating.
+
+`usmaddMN4'
+ Like `umaddMN4', but all involved operations must be
+ unsigned-saturating.
+
+`msubMN4'
+ Multiply operands 1 and 2, sign-extend them to mode N, subtract the
+ result from operand 3, and store the result in operand 0.
+ Operands 1 and 2 have mode M and operands 0 and 3 have mode N.
+ Both modes must be integer or fixed-point modes and N must be twice
+ the size of M.
+
+ In other words, `msubMN4' is like `mulMN3' except that it also
+ subtracts the result from operand 3.
+
+ These instructions are not allowed to `FAIL'.
+
+`umsubMN4'
+ Like `msubMN4', but zero-extend the multiplication operands
+ instead of sign-extending them.
+
+`ssmsubMN4'
+ Like `msubMN4', but all involved operations must be
+ signed-saturating.
+
+`usmsubMN4'
+ Like `umsubMN4', but all involved operations must be
+ unsigned-saturating.
+
+`divmodM4'
+ Signed division that produces both a quotient and a remainder.
+ Operand 1 is divided by operand 2 to produce a quotient stored in
+ operand 0 and a remainder stored in operand 3.
+
+ For machines with an instruction that produces both a quotient and
+ a remainder, provide a pattern for `divmodM4' but do not provide
+ patterns for `divM3' and `modM3'. This allows optimization in the
+ relatively common case when both the quotient and remainder are
+ computed.
+
+ If an instruction that just produces a quotient or just a remainder
+ exists and is more efficient than the instruction that produces
+ both, write the output routine of `divmodM4' to call
+ `find_reg_note' and look for a `REG_UNUSED' note on the quotient
+ or remainder and generate the appropriate instruction.
+
+`udivmodM4'
+ Similar, but does unsigned division.
+
+`ashlM3', `ssashlM3', `usashlM3'
+ Arithmetic-shift operand 1 left by a number of bits specified by
+ operand 2, and store the result in operand 0. Here M is the mode
+ of operand 0 and operand 1; operand 2's mode is specified by the
+ instruction pattern, and the compiler will convert the operand to
+ that mode before generating the instruction. The meaning of
+ out-of-range shift counts can optionally be specified by
+ `TARGET_SHIFT_TRUNCATION_MASK'. *Note
+ TARGET_SHIFT_TRUNCATION_MASK::. Operand 2 is always a scalar type.
+
+`ashrM3', `lshrM3', `rotlM3', `rotrM3'
+ Other shift and rotate instructions, analogous to the `ashlM3'
+ instructions. Operand 2 is always a scalar type.
+
+`vashlM3', `vashrM3', `vlshrM3', `vrotlM3', `vrotrM3'
+ Vector shift and rotate instructions that take vectors as operand 2
+ instead of a scalar type.
+
+`negM2', `ssnegM2', `usnegM2'
+ Negate operand 1 and store the result in operand 0.
+
+`absM2'
+ Store the absolute value of operand 1 into operand 0.
+
+`sqrtM2'
+ Store the square root of operand 1 into operand 0.
+
+ The `sqrt' built-in function of C always uses the mode which
+ corresponds to the C data type `double' and the `sqrtf' built-in
+ function uses the mode which corresponds to the C data type
+ `float'.
+
+`fmodM3'
+ Store the remainder of dividing operand 1 by operand 2 into
+ operand 0, rounded towards zero to an integer.
+
+ The `fmod' built-in function of C always uses the mode which
+ corresponds to the C data type `double' and the `fmodf' built-in
+ function uses the mode which corresponds to the C data type
+ `float'.
+
+`remainderM3'
+ Store the remainder of dividing operand 1 by operand 2 into
+ operand 0, rounded to the nearest integer.
+
+ The `remainder' built-in function of C always uses the mode which
+ corresponds to the C data type `double' and the `remainderf'
+ built-in function uses the mode which corresponds to the C data
+ type `float'.
+
+`cosM2'
+ Store the cosine of operand 1 into operand 0.
+
+ The `cos' built-in function of C always uses the mode which
+ corresponds to the C data type `double' and the `cosf' built-in
+ function uses the mode which corresponds to the C data type
+ `float'.
+
+`sinM2'
+ Store the sine of operand 1 into operand 0.
+
+ The `sin' built-in function of C always uses the mode which
+ corresponds to the C data type `double' and the `sinf' built-in
+ function uses the mode which corresponds to the C data type
+ `float'.
+
+`expM2'
+ Store the exponential of operand 1 into operand 0.
+
+ The `exp' built-in function of C always uses the mode which
+ corresponds to the C data type `double' and the `expf' built-in
+ function uses the mode which corresponds to the C data type
+ `float'.
+
+`logM2'
+ Store the natural logarithm of operand 1 into operand 0.
+
+ The `log' built-in function of C always uses the mode which
+ corresponds to the C data type `double' and the `logf' built-in
+ function uses the mode which corresponds to the C data type
+ `float'.
+
+`powM3'
+ Store the value of operand 1 raised to the exponent operand 2 into
+ operand 0.
+
+ The `pow' built-in function of C always uses the mode which
+ corresponds to the C data type `double' and the `powf' built-in
+ function uses the mode which corresponds to the C data type
+ `float'.
+
+`atan2M3'
+ Store the arc tangent (inverse tangent) of operand 1 divided by
+ operand 2 into operand 0, using the signs of both arguments to
+ determine the quadrant of the result.
+
+ The `atan2' built-in function of C always uses the mode which
+ corresponds to the C data type `double' and the `atan2f' built-in
+ function uses the mode which corresponds to the C data type
+ `float'.
+
+`floorM2'
+ Store the largest integral value not greater than argument.
+
+ The `floor' built-in function of C always uses the mode which
+ corresponds to the C data type `double' and the `floorf' built-in
+ function uses the mode which corresponds to the C data type
+ `float'.
+
+`btruncM2'
+ Store the argument rounded to integer towards zero.
+
+ The `trunc' built-in function of C always uses the mode which
+ corresponds to the C data type `double' and the `truncf' built-in
+ function uses the mode which corresponds to the C data type
+ `float'.
+
+`roundM2'
+ Store the argument rounded to integer away from zero.
+
+ The `round' built-in function of C always uses the mode which
+ corresponds to the C data type `double' and the `roundf' built-in
+ function uses the mode which corresponds to the C data type
+ `float'.
+
+`ceilM2'
+ Store the argument rounded to integer away from zero.
+
+ The `ceil' built-in function of C always uses the mode which
+ corresponds to the C data type `double' and the `ceilf' built-in
+ function uses the mode which corresponds to the C data type
+ `float'.
+
+`nearbyintM2'
+ Store the argument rounded according to the default rounding mode
+
+ The `nearbyint' built-in function of C always uses the mode which
+ corresponds to the C data type `double' and the `nearbyintf'
+ built-in function uses the mode which corresponds to the C data
+ type `float'.
+
+`rintM2'
+ Store the argument rounded according to the default rounding mode
+ and raise the inexact exception when the result differs in value
+ from the argument
+
+ The `rint' built-in function of C always uses the mode which
+ corresponds to the C data type `double' and the `rintf' built-in
+ function uses the mode which corresponds to the C data type
+ `float'.
+
+`lrintMN2'
+ Convert operand 1 (valid for floating point mode M) to fixed point
+ mode N as a signed number according to the current rounding mode
+ and store in operand 0 (which has mode N).
+
+`lroundM2'
+ Convert operand 1 (valid for floating point mode M) to fixed point
+ mode N as a signed number rounding to nearest and away from zero
+ and store in operand 0 (which has mode N).
+
+`lfloorM2'
+ Convert operand 1 (valid for floating point mode M) to fixed point
+ mode N as a signed number rounding down and store in operand 0
+ (which has mode N).
+
+`lceilM2'
+ Convert operand 1 (valid for floating point mode M) to fixed point
+ mode N as a signed number rounding up and store in operand 0
+ (which has mode N).
+
+`copysignM3'
+ Store a value with the magnitude of operand 1 and the sign of
+ operand 2 into operand 0.
+
+ The `copysign' built-in function of C always uses the mode which
+ corresponds to the C data type `double' and the `copysignf'
+ built-in function uses the mode which corresponds to the C data
+ type `float'.
+
+`ffsM2'
+ Store into operand 0 one plus the index of the least significant
+ 1-bit of operand 1. If operand 1 is zero, store zero. M is the
+ mode of operand 0; operand 1's mode is specified by the instruction
+ pattern, and the compiler will convert the operand to that mode
+ before generating the instruction.
+
+ The `ffs' built-in function of C always uses the mode which
+ corresponds to the C data type `int'.
+
+`clzM2'
+ Store into operand 0 the number of leading 0-bits in X, starting
+ at the most significant bit position. If X is 0, the
+ `CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the
+ result is undefined or has a useful value. M is the mode of
+ operand 0; operand 1's mode is specified by the instruction
+ pattern, and the compiler will convert the operand to that mode
+ before generating the instruction.
+
+`ctzM2'
+ Store into operand 0 the number of trailing 0-bits in X, starting
+ at the least significant bit position. If X is 0, the
+ `CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the
+ result is undefined or has a useful value. M is the mode of
+ operand 0; operand 1's mode is specified by the instruction
+ pattern, and the compiler will convert the operand to that mode
+ before generating the instruction.
+
+`popcountM2'
+ Store into operand 0 the number of 1-bits in X. M is the mode of
+ operand 0; operand 1's mode is specified by the instruction
+ pattern, and the compiler will convert the operand to that mode
+ before generating the instruction.
+
+`parityM2'
+ Store into operand 0 the parity of X, i.e. the number of 1-bits in
+ X modulo 2. M is the mode of operand 0; operand 1's mode is
+ specified by the instruction pattern, and the compiler will convert
+ the operand to that mode before generating the instruction.
+
+`one_cmplM2'
+ Store the bitwise-complement of operand 1 into operand 0.
+
+`cmpM'
+ Compare operand 0 and operand 1, and set the condition codes. The
+ RTL pattern should look like this:
+
+ (set (cc0) (compare (match_operand:M 0 ...)
+ (match_operand:M 1 ...)))
+
+`tstM'
+ Compare operand 0 against zero, and set the condition codes. The
+ RTL pattern should look like this:
+
+ (set (cc0) (match_operand:M 0 ...))
+
+ `tstM' patterns should not be defined for machines that do not use
+ `(cc0)'. Doing so would confuse the optimizer since it would no
+ longer be clear which `set' operations were comparisons. The
+ `cmpM' patterns should be used instead.
+
+`movmemM'
+ Block move instruction. The destination and source blocks of
+ memory are the first two operands, and both are `mem:BLK's with an
+ address in mode `Pmode'.
+
+ The number of bytes to move is the third operand, in mode M.
+ Usually, you specify `word_mode' for M. However, if you can
+ generate better code knowing the range of valid lengths is smaller
+ than those representable in a full word, you should provide a
+ pattern with a mode corresponding to the range of values you can
+ handle efficiently (e.g., `QImode' for values in the range 0-127;
+ note we avoid numbers that appear negative) and also a pattern
+ with `word_mode'.
+
+ The fourth operand is the known shared alignment of the source and
+ destination, in the form of a `const_int' rtx. Thus, if the
+ compiler knows that both source and destination are word-aligned,
+ it may provide the value 4 for this operand.
+
+ Optional operands 5 and 6 specify expected alignment and size of
+ block respectively. The expected alignment differs from alignment
+ in operand 4 in a way that the blocks are not required to be
+ aligned according to it in all cases. This expected alignment is
+ also in bytes, just like operand 4. Expected size, when unknown,
+ is set to `(const_int -1)'.
+
+ Descriptions of multiple `movmemM' patterns can only be beneficial
+ if the patterns for smaller modes have fewer restrictions on their
+ first, second and fourth operands. Note that the mode M in
+ `movmemM' does not impose any restriction on the mode of
+ individually moved data units in the block.
+
+ These patterns need not give special consideration to the
+ possibility that the source and destination strings might overlap.
+
+`movstr'
+ String copy instruction, with `stpcpy' semantics. Operand 0 is an
+ output operand in mode `Pmode'. The addresses of the destination
+ and source strings are operands 1 and 2, and both are `mem:BLK's
+ with addresses in mode `Pmode'. The execution of the expansion of
+ this pattern should store in operand 0 the address in which the
+ `NUL' terminator was stored in the destination string.
+
+`setmemM'
+ Block set instruction. The destination string is the first
+ operand, given as a `mem:BLK' whose address is in mode `Pmode'.
+ The number of bytes to set is the second operand, in mode M. The
+ value to initialize the memory with is the third operand. Targets
+ that only support the clearing of memory should reject any value
+ that is not the constant 0. See `movmemM' for a discussion of the
+ choice of mode.
+
+ The fourth operand is the known alignment of the destination, in
+ the form of a `const_int' rtx. Thus, if the compiler knows that
+ the destination is word-aligned, it may provide the value 4 for
+ this operand.
+
+ Optional operands 5 and 6 specify expected alignment and size of
+ block respectively. The expected alignment differs from alignment
+ in operand 4 in a way that the blocks are not required to be
+ aligned according to it in all cases. This expected alignment is
+ also in bytes, just like operand 4. Expected size, when unknown,
+ is set to `(const_int -1)'.
+
+ The use for multiple `setmemM' is as for `movmemM'.
+
+`cmpstrnM'
+ String compare instruction, with five operands. Operand 0 is the
+ output; it has mode M. The remaining four operands are like the
+ operands of `movmemM'. The two memory blocks specified are
+ compared byte by byte in lexicographic order starting at the
+ beginning of each string. The instruction is not allowed to
+ prefetch more than one byte at a time since either string may end
+ in the first byte and reading past that may access an invalid page
+ or segment and cause a fault. The effect of the instruction is to
+ store a value in operand 0 whose sign indicates the result of the
+ comparison.
+
+`cmpstrM'
+ String compare instruction, without known maximum length. Operand
+ 0 is the output; it has mode M. The second and third operand are
+ the blocks of memory to be compared; both are `mem:BLK' with an
+ address in mode `Pmode'.
+
+ The fourth operand is the known shared alignment of the source and
+ destination, in the form of a `const_int' rtx. Thus, if the
+ compiler knows that both source and destination are word-aligned,
+ it may provide the value 4 for this operand.
+
+ The two memory blocks specified are compared byte by byte in
+ lexicographic order starting at the beginning of each string. The
+ instruction is not allowed to prefetch more than one byte at a
+ time since either string may end in the first byte and reading
+ past that may access an invalid page or segment and cause a fault.
+ The effect of the instruction is to store a value in operand 0
+ whose sign indicates the result of the comparison.
+
+`cmpmemM'
+ Block compare instruction, with five operands like the operands of
+ `cmpstrM'. The two memory blocks specified are compared byte by
+ byte in lexicographic order starting at the beginning of each
+ block. Unlike `cmpstrM' the instruction can prefetch any bytes in
+ the two memory blocks. The effect of the instruction is to store
+ a value in operand 0 whose sign indicates the result of the
+ comparison.
+
+`strlenM'
+ Compute the length of a string, with three operands. Operand 0 is
+ the result (of mode M), operand 1 is a `mem' referring to the
+ first character of the string, operand 2 is the character to
+ search for (normally zero), and operand 3 is a constant describing
+ the known alignment of the beginning of the string.
+
+`floatMN2'
+ Convert signed integer operand 1 (valid for fixed point mode M) to
+ floating point mode N and store in operand 0 (which has mode N).
+
+`floatunsMN2'
+ Convert unsigned integer operand 1 (valid for fixed point mode M)
+ to floating point mode N and store in operand 0 (which has mode N).
+
+`fixMN2'
+ Convert operand 1 (valid for floating point mode M) to fixed point
+ mode N as a signed number and store in operand 0 (which has mode
+ N). This instruction's result is defined only when the value of
+ operand 1 is an integer.
+
+ If the machine description defines this pattern, it also needs to
+ define the `ftrunc' pattern.
+
+`fixunsMN2'
+ Convert operand 1 (valid for floating point mode M) to fixed point
+ mode N as an unsigned number and store in operand 0 (which has
+ mode N). This instruction's result is defined only when the value
+ of operand 1 is an integer.
+
+`ftruncM2'
+ Convert operand 1 (valid for floating point mode M) to an integer
+ value, still represented in floating point mode M, and store it in
+ operand 0 (valid for floating point mode M).
+
+`fix_truncMN2'
+ Like `fixMN2' but works for any floating point value of mode M by
+ converting the value to an integer.
+
+`fixuns_truncMN2'
+ Like `fixunsMN2' but works for any floating point value of mode M
+ by converting the value to an integer.
+
+`truncMN2'
+ Truncate operand 1 (valid for mode M) to mode N and store in
+ operand 0 (which has mode N). Both modes must be fixed point or
+ both floating point.
+
+`extendMN2'
+ Sign-extend operand 1 (valid for mode M) to mode N and store in
+ operand 0 (which has mode N). Both modes must be fixed point or
+ both floating point.
+
+`zero_extendMN2'
+ Zero-extend operand 1 (valid for mode M) to mode N and store in
+ operand 0 (which has mode N). Both modes must be fixed point.
+
+`fractMN2'
+ Convert operand 1 of mode M to mode N and store in operand 0
+ (which has mode N). Mode M and mode N could be fixed-point to
+ fixed-point, signed integer to fixed-point, fixed-point to signed
+ integer, floating-point to fixed-point, or fixed-point to
+ floating-point. When overflows or underflows happen, the results
+ are undefined.
+
+`satfractMN2'
+ Convert operand 1 of mode M to mode N and store in operand 0
+ (which has mode N). Mode M and mode N could be fixed-point to
+ fixed-point, signed integer to fixed-point, or floating-point to
+ fixed-point. When overflows or underflows happen, the instruction
+ saturates the results to the maximum or the minimum.
+
+`fractunsMN2'
+ Convert operand 1 of mode M to mode N and store in operand 0
+ (which has mode N). Mode M and mode N could be unsigned integer
+ to fixed-point, or fixed-point to unsigned integer. When
+ overflows or underflows happen, the results are undefined.
+
+`satfractunsMN2'
+ Convert unsigned integer operand 1 of mode M to fixed-point mode N
+ and store in operand 0 (which has mode N). When overflows or
+ underflows happen, the instruction saturates the results to the
+ maximum or the minimum.
+
+`extv'
+ Extract a bit-field from operand 1 (a register or memory operand),
+ where operand 2 specifies the width in bits and operand 3 the
+ starting bit, and store it in operand 0. Operand 0 must have mode
+ `word_mode'. Operand 1 may have mode `byte_mode' or `word_mode';
+ often `word_mode' is allowed only for registers. Operands 2 and 3
+ must be valid for `word_mode'.
+
+ The RTL generation pass generates this instruction only with
+ constants for operands 2 and 3 and the constant is never zero for
+ operand 2.
+
+ The bit-field value is sign-extended to a full word integer before
+ it is stored in operand 0.
+
+`extzv'
+ Like `extv' except that the bit-field value is zero-extended.
+
+`insv'
+ Store operand 3 (which must be valid for `word_mode') into a
+ bit-field in operand 0, where operand 1 specifies the width in
+ bits and operand 2 the starting bit. Operand 0 may have mode
+ `byte_mode' or `word_mode'; often `word_mode' is allowed only for
+ registers. Operands 1 and 2 must be valid for `word_mode'.
+
+ The RTL generation pass generates this instruction only with
+ constants for operands 1 and 2 and the constant is never zero for
+ operand 1.
+
+`movMODEcc'
+ Conditionally move operand 2 or operand 3 into operand 0 according
+ to the comparison in operand 1. If the comparison is true,
+ operand 2 is moved into operand 0, otherwise operand 3 is moved.
+
+ The mode of the operands being compared need not be the same as
+ the operands being moved. Some machines, sparc64 for example,
+ have instructions that conditionally move an integer value based
+ on the floating point condition codes and vice versa.
+
+ If the machine does not have conditional move instructions, do not
+ define these patterns.
+
+`addMODEcc'
+ Similar to `movMODEcc' but for conditional addition. Conditionally
+ move operand 2 or (operands 2 + operand 3) into operand 0
+ according to the comparison in operand 1. If the comparison is
+ true, operand 2 is moved into operand 0, otherwise (operand 2 +
+ operand 3) is moved.
+
+`sCOND'
+ Store zero or nonzero in the operand according to the condition
+ codes. Value stored is nonzero iff the condition COND is true.
+ COND is the name of a comparison operation expression code, such
+ as `eq', `lt' or `leu'.
+
+ You specify the mode that the operand must have when you write the
+ `match_operand' expression. The compiler automatically sees which
+ mode you have used and supplies an operand of that mode.
+
+ The value stored for a true condition must have 1 as its low bit,
+ or else must be negative. Otherwise the instruction is not
+ suitable and you should omit it from the machine description. You
+ describe to the compiler exactly which value is stored by defining
+ the macro `STORE_FLAG_VALUE' (*note Misc::). If a description
+ cannot be found that can be used for all the `sCOND' patterns, you
+ should omit those operations from the machine description.
+
+ These operations may fail, but should do so only in relatively
+ uncommon cases; if they would fail for common cases involving
+ integer comparisons, it is best to omit these patterns.
+
+ If these operations are omitted, the compiler will usually
+ generate code that copies the constant one to the target and
+ branches around an assignment of zero to the target. If this code
+ is more efficient than the potential instructions used for the
+ `sCOND' pattern followed by those required to convert the result
+ into a 1 or a zero in `SImode', you should omit the `sCOND'
+ operations from the machine description.
+
+`bCOND'
+ Conditional branch instruction. Operand 0 is a `label_ref' that
+ refers to the label to jump to. Jump if the condition codes meet
+ condition COND.
+
+ Some machines do not follow the model assumed here where a
+ comparison instruction is followed by a conditional branch
+ instruction. In that case, the `cmpM' (and `tstM') patterns should
+ simply store the operands away and generate all the required insns
+ in a `define_expand' (*note Expander Definitions::) for the
+ conditional branch operations. All calls to expand `bCOND'
+ patterns are immediately preceded by calls to expand either a
+ `cmpM' pattern or a `tstM' pattern.
+
+ Machines that use a pseudo register for the condition code value,
+ or where the mode used for the comparison depends on the condition
+ being tested, should also use the above mechanism. *Note Jump
+ Patterns::.
+
+ The above discussion also applies to the `movMODEcc' and `sCOND'
+ patterns.
+
+`cbranchMODE4'
+ Conditional branch instruction combined with a compare instruction.
+ Operand 0 is a comparison operator. Operand 1 and operand 2 are
+ the first and second operands of the comparison, respectively.
+ Operand 3 is a `label_ref' that refers to the label to jump to.
+
+`jump'
+ A jump inside a function; an unconditional branch. Operand 0 is
+ the `label_ref' of the label to jump to. This pattern name is
+ mandatory on all machines.
+
+`call'
+ Subroutine call instruction returning no value. Operand 0 is the
+ function to call; operand 1 is the number of bytes of arguments
+ pushed as a `const_int'; operand 2 is the number of registers used
+ as operands.
+
+ On most machines, operand 2 is not actually stored into the RTL
+ pattern. It is supplied for the sake of some RISC machines which
+ need to put this information into the assembler code; they can put
+ it in the RTL instead of operand 1.
+
+ Operand 0 should be a `mem' RTX whose address is the address of the
+ function. Note, however, that this address can be a `symbol_ref'
+ expression even if it would not be a legitimate memory address on
+ the target machine. If it is also not a valid argument for a call
+ instruction, the pattern for this operation should be a
+ `define_expand' (*note Expander Definitions::) that places the
+ address into a register and uses that register in the call
+ instruction.
+
+`call_value'
+ Subroutine call instruction returning a value. Operand 0 is the
+ hard register in which the value is returned. There are three more
+ operands, the same as the three operands of the `call' instruction
+ (but with numbers increased by one).
+
+ Subroutines that return `BLKmode' objects use the `call' insn.
+
+`call_pop', `call_value_pop'
+ Similar to `call' and `call_value', except used if defined and if
+ `RETURN_POPS_ARGS' is nonzero. They should emit a `parallel' that
+ contains both the function call and a `set' to indicate the
+ adjustment made to the frame pointer.
+
+ For machines where `RETURN_POPS_ARGS' can be nonzero, the use of
+ these patterns increases the number of functions for which the
+ frame pointer can be eliminated, if desired.
+
+`untyped_call'
+ Subroutine call instruction returning a value of any type.
+ Operand 0 is the function to call; operand 1 is a memory location
+ where the result of calling the function is to be stored; operand
+ 2 is a `parallel' expression where each element is a `set'
+ expression that indicates the saving of a function return value
+ into the result block.
+
+ This instruction pattern should be defined to support
+ `__builtin_apply' on machines where special instructions are needed
+ to call a subroutine with arbitrary arguments or to save the value
+ returned. This instruction pattern is required on machines that
+ have multiple registers that can hold a return value (i.e.
+ `FUNCTION_VALUE_REGNO_P' is true for more than one register).
+
+`return'
+ Subroutine return instruction. This instruction pattern name
+ should be defined only if a single instruction can do all the work
+ of returning from a function.
+
+ Like the `movM' patterns, this pattern is also used after the RTL
+ generation phase. In this case it is to support machines where
+ multiple instructions are usually needed to return from a
+ function, but some class of functions only requires one
+ instruction to implement a return. Normally, the applicable
+ functions are those which do not need to save any registers or
+ allocate stack space.
+
+ For such machines, the condition specified in this pattern should
+ only be true when `reload_completed' is nonzero and the function's
+ epilogue would only be a single instruction. For machines with
+ register windows, the routine `leaf_function_p' may be used to
+ determine if a register window push is required.
+
+ Machines that have conditional return instructions should define
+ patterns such as
+
+ (define_insn ""
+ [(set (pc)
+ (if_then_else (match_operator
+ 0 "comparison_operator"
+ [(cc0) (const_int 0)])
+ (return)
+ (pc)))]
+ "CONDITION"
+ "...")
+
+ where CONDITION would normally be the same condition specified on
+ the named `return' pattern.
+
+`untyped_return'
+ Untyped subroutine return instruction. This instruction pattern
+ should be defined to support `__builtin_return' on machines where
+ special instructions are needed to return a value of any type.
+
+ Operand 0 is a memory location where the result of calling a
+ function with `__builtin_apply' is stored; operand 1 is a
+ `parallel' expression where each element is a `set' expression
+ that indicates the restoring of a function return value from the
+ result block.
+
+`nop'
+ No-op instruction. This instruction pattern name should always be
+ defined to output a no-op in assembler code. `(const_int 0)' will
+ do as an RTL pattern.
+
+`indirect_jump'
+ An instruction to jump to an address which is operand zero. This
+ pattern name is mandatory on all machines.
+
+`casesi'
+ Instruction to jump through a dispatch table, including bounds
+ checking. This instruction takes five operands:
+
+ 1. The index to dispatch on, which has mode `SImode'.
+
+ 2. The lower bound for indices in the table, an integer constant.
+
+ 3. The total range of indices in the table--the largest index
+ minus the smallest one (both inclusive).
+
+ 4. A label that precedes the table itself.
+
+ 5. A label to jump to if the index has a value outside the
+ bounds.
+
+ The table is a `addr_vec' or `addr_diff_vec' inside of a
+ `jump_insn'. The number of elements in the table is one plus the
+ difference between the upper bound and the lower bound.
+
+`tablejump'
+ Instruction to jump to a variable address. This is a low-level
+ capability which can be used to implement a dispatch table when
+ there is no `casesi' pattern.
+
+ This pattern requires two operands: the address or offset, and a
+ label which should immediately precede the jump table. If the
+ macro `CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then
+ the first operand is an offset which counts from the address of
+ the table; otherwise, it is an absolute address to jump to. In
+ either case, the first operand has mode `Pmode'.
+
+ The `tablejump' insn is always the last insn before the jump table
+ it uses. Its assembler code normally has no need to use the
+ second operand, but you should incorporate it in the RTL pattern so
+ that the jump optimizer will not delete the table as unreachable
+ code.
+
+`decrement_and_branch_until_zero'
+ Conditional branch instruction that decrements a register and
+ jumps if the register is nonzero. Operand 0 is the register to
+ decrement and test; operand 1 is the label to jump to if the
+ register is nonzero. *Note Looping Patterns::.
+
+ This optional instruction pattern is only used by the combiner,
+ typically for loops reversed by the loop optimizer when strength
+ reduction is enabled.
+
+`doloop_end'
+ Conditional branch instruction that decrements a register and
+ jumps if the register is nonzero. This instruction takes five
+ operands: Operand 0 is the register to decrement and test; operand
+ 1 is the number of loop iterations as a `const_int' or
+ `const0_rtx' if this cannot be determined until run-time; operand
+ 2 is the actual or estimated maximum number of iterations as a
+ `const_int'; operand 3 is the number of enclosed loops as a
+ `const_int' (an innermost loop has a value of 1); operand 4 is the
+ label to jump to if the register is nonzero. *Note Looping
+ Patterns::.
+
+ This optional instruction pattern should be defined for machines
+ with low-overhead looping instructions as the loop optimizer will
+ try to modify suitable loops to utilize it. If nested
+ low-overhead looping is not supported, use a `define_expand'
+ (*note Expander Definitions::) and make the pattern fail if
+ operand 3 is not `const1_rtx'. Similarly, if the actual or
+ estimated maximum number of iterations is too large for this
+ instruction, make it fail.
+
+`doloop_begin'
+ Companion instruction to `doloop_end' required for machines that
+ need to perform some initialization, such as loading special
+ registers used by a low-overhead looping instruction. If
+ initialization insns do not always need to be emitted, use a
+ `define_expand' (*note Expander Definitions::) and make it fail.
+
+`canonicalize_funcptr_for_compare'
+ Canonicalize the function pointer in operand 1 and store the result
+ into operand 0.
+
+ Operand 0 is always a `reg' and has mode `Pmode'; operand 1 may be
+ a `reg', `mem', `symbol_ref', `const_int', etc and also has mode
+ `Pmode'.
+
+ Canonicalization of a function pointer usually involves computing
+ the address of the function which would be called if the function
+ pointer were used in an indirect call.
+
+ Only define this pattern if function pointers on the target machine
+ can have different values but still call the same function when
+ used in an indirect call.
+
+`save_stack_block'
+`save_stack_function'
+`save_stack_nonlocal'
+`restore_stack_block'
+`restore_stack_function'
+`restore_stack_nonlocal'
+ Most machines save and restore the stack pointer by copying it to
+ or from an object of mode `Pmode'. Do not define these patterns on
+ such machines.
+
+ Some machines require special handling for stack pointer saves and
+ restores. On those machines, define the patterns corresponding to
+ the non-standard cases by using a `define_expand' (*note Expander
+ Definitions::) that produces the required insns. The three types
+ of saves and restores are:
+
+ 1. `save_stack_block' saves the stack pointer at the start of a
+ block that allocates a variable-sized object, and
+ `restore_stack_block' restores the stack pointer when the
+ block is exited.
+
+ 2. `save_stack_function' and `restore_stack_function' do a
+ similar job for the outermost block of a function and are
+ used when the function allocates variable-sized objects or
+ calls `alloca'. Only the epilogue uses the restored stack
+ pointer, allowing a simpler save or restore sequence on some
+ machines.
+
+ 3. `save_stack_nonlocal' is used in functions that contain labels
+ branched to by nested functions. It saves the stack pointer
+ in such a way that the inner function can use
+ `restore_stack_nonlocal' to restore the stack pointer. The
+ compiler generates code to restore the frame and argument
+ pointer registers, but some machines require saving and
+ restoring additional data such as register window information
+ or stack backchains. Place insns in these patterns to save
+ and restore any such required data.
+
+ When saving the stack pointer, operand 0 is the save area and
+ operand 1 is the stack pointer. The mode used to allocate the
+ save area defaults to `Pmode' but you can override that choice by
+ defining the `STACK_SAVEAREA_MODE' macro (*note Storage Layout::).
+ You must specify an integral mode, or `VOIDmode' if no save area
+ is needed for a particular type of save (either because no save is
+ needed or because a machine-specific save area can be used).
+ Operand 0 is the stack pointer and operand 1 is the save area for
+ restore operations. If `save_stack_block' is defined, operand 0
+ must not be `VOIDmode' since these saves can be arbitrarily nested.
+
+ A save area is a `mem' that is at a constant offset from
+ `virtual_stack_vars_rtx' when the stack pointer is saved for use by
+ nonlocal gotos and a `reg' in the other two cases.
+
+`allocate_stack'
+ Subtract (or add if `STACK_GROWS_DOWNWARD' is undefined) operand 1
+ from the stack pointer to create space for dynamically allocated
+ data.
+
+ Store the resultant pointer to this space into operand 0. If you
+ are allocating space from the main stack, do this by emitting a
+ move insn to copy `virtual_stack_dynamic_rtx' to operand 0. If
+ you are allocating the space elsewhere, generate code to copy the
+ location of the space to operand 0. In the latter case, you must
+ ensure this space gets freed when the corresponding space on the
+ main stack is free.
+
+ Do not define this pattern if all that must be done is the
+ subtraction. Some machines require other operations such as stack
+ probes or maintaining the back chain. Define this pattern to emit
+ those operations in addition to updating the stack pointer.
+
+`check_stack'
+ If stack checking cannot be done on your system by probing the
+ stack with a load or store instruction (*note Stack Checking::),
+ define this pattern to perform the needed check and signaling an
+ error if the stack has overflowed. The single operand is the
+ location in the stack furthest from the current stack pointer that
+ you need to validate. Normally, on machines where this pattern is
+ needed, you would obtain the stack limit from a global or
+ thread-specific variable or register.
+
+`nonlocal_goto'
+ Emit code to generate a non-local goto, e.g., a jump from one
+ function to a label in an outer function. This pattern has four
+ arguments, each representing a value to be used in the jump. The
+ first argument is to be loaded into the frame pointer, the second
+ is the address to branch to (code to dispatch to the actual label),
+ the third is the address of a location where the stack is saved,
+ and the last is the address of the label, to be placed in the
+ location for the incoming static chain.
+
+ On most machines you need not define this pattern, since GCC will
+ already generate the correct code, which is to load the frame
+ pointer and static chain, restore the stack (using the
+ `restore_stack_nonlocal' pattern, if defined), and jump indirectly
+ to the dispatcher. You need only define this pattern if this code
+ will not work on your machine.
+
+`nonlocal_goto_receiver'
+ This pattern, if defined, contains code needed at the target of a
+ nonlocal goto after the code already generated by GCC. You will
+ not normally need to define this pattern. A typical reason why
+ you might need this pattern is if some value, such as a pointer to
+ a global table, must be restored when the frame pointer is
+ restored. Note that a nonlocal goto only occurs within a
+ unit-of-translation, so a global table pointer that is shared by
+ all functions of a given module need not be restored. There are
+ no arguments.
+
+`exception_receiver'
+ This pattern, if defined, contains code needed at the site of an
+ exception handler that isn't needed at the site of a nonlocal
+ goto. You will not normally need to define this pattern. A
+ typical reason why you might need this pattern is if some value,
+ such as a pointer to a global table, must be restored after
+ control flow is branched to the handler of an exception. There
+ are no arguments.
+
+`builtin_setjmp_setup'
+ This pattern, if defined, contains additional code needed to
+ initialize the `jmp_buf'. You will not normally need to define
+ this pattern. A typical reason why you might need this pattern is
+ if some value, such as a pointer to a global table, must be
+ restored. Though it is preferred that the pointer value be
+ recalculated if possible (given the address of a label for
+ instance). The single argument is a pointer to the `jmp_buf'.
+ Note that the buffer is five words long and that the first three
+ are normally used by the generic mechanism.
+
+`builtin_setjmp_receiver'
+ This pattern, if defined, contains code needed at the site of an
+ built-in setjmp that isn't needed at the site of a nonlocal goto.
+ You will not normally need to define this pattern. A typical
+ reason why you might need this pattern is if some value, such as a
+ pointer to a global table, must be restored. It takes one
+ argument, which is the label to which builtin_longjmp transfered
+ control; this pattern may be emitted at a small offset from that
+ label.
+
+`builtin_longjmp'
+ This pattern, if defined, performs the entire action of the
+ longjmp. You will not normally need to define this pattern unless
+ you also define `builtin_setjmp_setup'. The single argument is a
+ pointer to the `jmp_buf'.
+
+`eh_return'
+ This pattern, if defined, affects the way `__builtin_eh_return',
+ and thence the call frame exception handling library routines, are
+ built. It is intended to handle non-trivial actions needed along
+ the abnormal return path.
+
+ The address of the exception handler to which the function should
+ return is passed as operand to this pattern. It will normally
+ need to copied by the pattern to some special register or memory
+ location. If the pattern needs to determine the location of the
+ target call frame in order to do so, it may use
+ `EH_RETURN_STACKADJ_RTX', if defined; it will have already been
+ assigned.
+
+ If this pattern is not defined, the default action will be to
+ simply copy the return address to `EH_RETURN_HANDLER_RTX'. Either
+ that macro or this pattern needs to be defined if call frame
+ exception handling is to be used.
+
+`prologue'
+ This pattern, if defined, emits RTL for entry to a function. The
+ function entry is responsible for setting up the stack frame,
+ initializing the frame pointer register, saving callee saved
+ registers, etc.
+
+ Using a prologue pattern is generally preferred over defining
+ `TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the
+ prologue.
+
+ The `prologue' pattern is particularly useful for targets which
+ perform instruction scheduling.
+
+`epilogue'
+ This pattern emits RTL for exit from a function. The function
+ exit is responsible for deallocating the stack frame, restoring
+ callee saved registers and emitting the return instruction.
+
+ Using an epilogue pattern is generally preferred over defining
+ `TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the
+ epilogue.
+
+ The `epilogue' pattern is particularly useful for targets which
+ perform instruction scheduling or which have delay slots for their
+ return instruction.
+
+`sibcall_epilogue'
+ This pattern, if defined, emits RTL for exit from a function
+ without the final branch back to the calling function. This
+ pattern will be emitted before any sibling call (aka tail call)
+ sites.
+
+ The `sibcall_epilogue' pattern must not clobber any arguments used
+ for parameter passing or any stack slots for arguments passed to
+ the current function.
+
+`trap'
+ This pattern, if defined, signals an error, typically by causing
+ some kind of signal to be raised. Among other places, it is used
+ by the Java front end to signal `invalid array index' exceptions.
+
+`conditional_trap'
+ Conditional trap instruction. Operand 0 is a piece of RTL which
+ performs a comparison. Operand 1 is the trap code, an integer.
+
+ A typical `conditional_trap' pattern looks like
+
+ (define_insn "conditional_trap"
+ [(trap_if (match_operator 0 "trap_operator"
+ [(cc0) (const_int 0)])
+ (match_operand 1 "const_int_operand" "i"))]
+ ""
+ "...")
+
+`prefetch'
+ This pattern, if defined, emits code for a non-faulting data
+ prefetch instruction. Operand 0 is the address of the memory to
+ prefetch. Operand 1 is a constant 1 if the prefetch is preparing
+ for a write to the memory address, or a constant 0 otherwise.
+ Operand 2 is the expected degree of temporal locality of the data
+ and is a value between 0 and 3, inclusive; 0 means that the data
+ has no temporal locality, so it need not be left in the cache
+ after the access; 3 means that the data has a high degree of
+ temporal locality and should be left in all levels of cache
+ possible; 1 and 2 mean, respectively, a low or moderate degree of
+ temporal locality.
+
+ Targets that do not support write prefetches or locality hints can
+ ignore the values of operands 1 and 2.
+
+`blockage'
+ This pattern defines a pseudo insn that prevents the instruction
+ scheduler from moving instructions across the boundary defined by
+ the blockage insn. Normally an UNSPEC_VOLATILE pattern.
+
+`memory_barrier'
+ If the target memory model is not fully synchronous, then this
+ pattern should be defined to an instruction that orders both loads
+ and stores before the instruction with respect to loads and stores
+ after the instruction. This pattern has no operands.
+
+`sync_compare_and_swapMODE'
+ This pattern, if defined, emits code for an atomic compare-and-swap
+ operation. Operand 1 is the memory on which the atomic operation
+ is performed. Operand 2 is the "old" value to be compared against
+ the current contents of the memory location. Operand 3 is the
+ "new" value to store in the memory if the compare succeeds.
+ Operand 0 is the result of the operation; it should contain the
+ contents of the memory before the operation. If the compare
+ succeeds, this should obviously be a copy of operand 2.
+
+ This pattern must show that both operand 0 and operand 1 are
+ modified.
+
+ This pattern must issue any memory barrier instructions such that
+ all memory operations before the atomic operation occur before the
+ atomic operation and all memory operations after the atomic
+ operation occur after the atomic operation.
+
+`sync_compare_and_swap_ccMODE'
+ This pattern is just like `sync_compare_and_swapMODE', except it
+ should act as if compare part of the compare-and-swap were issued
+ via `cmpM'. This comparison will only be used with `EQ' and `NE'
+ branches and `setcc' operations.
+
+ Some targets do expose the success or failure of the
+ compare-and-swap operation via the status flags. Ideally we
+ wouldn't need a separate named pattern in order to take advantage
+ of this, but the combine pass does not handle patterns with
+ multiple sets, which is required by definition for
+ `sync_compare_and_swapMODE'.
+
+`sync_addMODE', `sync_subMODE'
+`sync_iorMODE', `sync_andMODE'
+`sync_xorMODE', `sync_nandMODE'
+ These patterns emit code for an atomic operation on memory.
+ Operand 0 is the memory on which the atomic operation is performed.
+ Operand 1 is the second operand to the binary operator.
+
+ This pattern must issue any memory barrier instructions such that
+ all memory operations before the atomic operation occur before the
+ atomic operation and all memory operations after the atomic
+ operation occur after the atomic operation.
+
+ If these patterns are not defined, the operation will be
+ constructed from a compare-and-swap operation, if defined.
+
+`sync_old_addMODE', `sync_old_subMODE'
+`sync_old_iorMODE', `sync_old_andMODE'
+`sync_old_xorMODE', `sync_old_nandMODE'
+ These patterns are emit code for an atomic operation on memory,
+ and return the value that the memory contained before the
+ operation. Operand 0 is the result value, operand 1 is the memory
+ on which the atomic operation is performed, and operand 2 is the
+ second operand to the binary operator.
+
+ This pattern must issue any memory barrier instructions such that
+ all memory operations before the atomic operation occur before the
+ atomic operation and all memory operations after the atomic
+ operation occur after the atomic operation.
+
+ If these patterns are not defined, the operation will be
+ constructed from a compare-and-swap operation, if defined.
+
+`sync_new_addMODE', `sync_new_subMODE'
+`sync_new_iorMODE', `sync_new_andMODE'
+`sync_new_xorMODE', `sync_new_nandMODE'
+ These patterns are like their `sync_old_OP' counterparts, except
+ that they return the value that exists in the memory location
+ after the operation, rather than before the operation.
+
+`sync_lock_test_and_setMODE'
+ This pattern takes two forms, based on the capabilities of the
+ target. In either case, operand 0 is the result of the operand,
+ operand 1 is the memory on which the atomic operation is
+ performed, and operand 2 is the value to set in the lock.
+
+ In the ideal case, this operation is an atomic exchange operation,
+ in which the previous value in memory operand is copied into the
+ result operand, and the value operand is stored in the memory
+ operand.
+
+ For less capable targets, any value operand that is not the
+ constant 1 should be rejected with `FAIL'. In this case the
+ target may use an atomic test-and-set bit operation. The result
+ operand should contain 1 if the bit was previously set and 0 if
+ the bit was previously clear. The true contents of the memory
+ operand are implementation defined.
+
+ This pattern must issue any memory barrier instructions such that
+ the pattern as a whole acts as an acquire barrier, that is all
+ memory operations after the pattern do not occur until the lock is
+ acquired.
+
+ If this pattern is not defined, the operation will be constructed
+ from a compare-and-swap operation, if defined.
+
+`sync_lock_releaseMODE'
+ This pattern, if defined, releases a lock set by
+ `sync_lock_test_and_setMODE'. Operand 0 is the memory that
+ contains the lock; operand 1 is the value to store in the lock.
+
+ If the target doesn't implement full semantics for
+ `sync_lock_test_and_setMODE', any value operand which is not the
+ constant 0 should be rejected with `FAIL', and the true contents
+ of the memory operand are implementation defined.
+
+ This pattern must issue any memory barrier instructions such that
+ the pattern as a whole acts as a release barrier, that is the lock
+ is released only after all previous memory operations have
+ completed.
+
+ If this pattern is not defined, then a `memory_barrier' pattern
+ will be emitted, followed by a store of the value to the memory
+ operand.
+
+`stack_protect_set'
+ This pattern, if defined, moves a `Pmode' value from the memory in
+ operand 1 to the memory in operand 0 without leaving the value in
+ a register afterward. This is to avoid leaking the value some
+ place that an attacker might use to rewrite the stack guard slot
+ after having clobbered it.
+
+ If this pattern is not defined, then a plain move pattern is
+ generated.
+
+`stack_protect_test'
+ This pattern, if defined, compares a `Pmode' value from the memory
+ in operand 1 with the memory in operand 0 without leaving the
+ value in a register afterward and branches to operand 2 if the
+ values weren't equal.
+
+ If this pattern is not defined, then a plain compare pattern and
+ conditional branch pattern is used.
+
+`clear_cache'
+ This pattern, if defined, flushes the instruction cache for a
+ region of memory. The region is bounded to by the Pmode pointers
+ in operand 0 inclusive and operand 1 exclusive.
+
+ If this pattern is not defined, a call to the library function
+ `__clear_cache' is used.
+
+
+\1f
+File: gccint.info, Node: Pattern Ordering, Next: Dependent Patterns, Prev: Standard Names, Up: Machine Desc
+
+16.10 When the Order of Patterns Matters
+========================================
+
+Sometimes an insn can match more than one instruction pattern. Then the
+pattern that appears first in the machine description is the one used.
+Therefore, more specific patterns (patterns that will match fewer
+things) and faster instructions (those that will produce better code
+when they do match) should usually go first in the description.
+
+ In some cases the effect of ordering the patterns can be used to hide
+a pattern when it is not valid. For example, the 68000 has an
+instruction for converting a fullword to floating point and another for
+converting a byte to floating point. An instruction converting an
+integer to floating point could match either one. We put the pattern
+to convert the fullword first to make sure that one will be used rather
+than the other. (Otherwise a large integer might be generated as a
+single-byte immediate quantity, which would not work.) Instead of
+using this pattern ordering it would be possible to make the pattern
+for convert-a-byte smart enough to deal properly with any constant
+value.
+
+\1f
+File: gccint.info, Node: Dependent Patterns, Next: Jump Patterns, Prev: Pattern Ordering, Up: Machine Desc
+
+16.11 Interdependence of Patterns
+=================================
+
+Every machine description must have a named pattern for each of the
+conditional branch names `bCOND'. The recognition template must always
+have the form
+
+ (set (pc)
+ (if_then_else (COND (cc0) (const_int 0))
+ (label_ref (match_operand 0 "" ""))
+ (pc)))
+
+In addition, every machine description must have an anonymous pattern
+for each of the possible reverse-conditional branches. Their templates
+look like
+
+ (set (pc)
+ (if_then_else (COND (cc0) (const_int 0))
+ (pc)
+ (label_ref (match_operand 0 "" ""))))
+
+They are necessary because jump optimization can turn direct-conditional
+branches into reverse-conditional branches.
+
+ It is often convenient to use the `match_operator' construct to reduce
+the number of patterns that must be specified for branches. For
+example,
+
+ (define_insn ""
+ [(set (pc)
+ (if_then_else (match_operator 0 "comparison_operator"
+ [(cc0) (const_int 0)])
+ (pc)
+ (label_ref (match_operand 1 "" ""))))]
+ "CONDITION"
+ "...")
+
+ In some cases machines support instructions identical except for the
+machine mode of one or more operands. For example, there may be
+"sign-extend halfword" and "sign-extend byte" instructions whose
+patterns are
+
+ (set (match_operand:SI 0 ...)
+ (extend:SI (match_operand:HI 1 ...)))
+
+ (set (match_operand:SI 0 ...)
+ (extend:SI (match_operand:QI 1 ...)))
+
+Constant integers do not specify a machine mode, so an instruction to
+extend a constant value could match either pattern. The pattern it
+actually will match is the one that appears first in the file. For
+correct results, this must be the one for the widest possible mode
+(`HImode', here). If the pattern matches the `QImode' instruction, the
+results will be incorrect if the constant value does not actually fit
+that mode.
+
+ Such instructions to extend constants are rarely generated because
+they are optimized away, but they do occasionally happen in nonoptimized
+compilations.
+
+ If a constraint in a pattern allows a constant, the reload pass may
+replace a register with a constant permitted by the constraint in some
+cases. Similarly for memory references. Because of this substitution,
+you should not provide separate patterns for increment and decrement
+instructions. Instead, they should be generated from the same pattern
+that supports register-register add insns by examining the operands and
+generating the appropriate machine instruction.
+
+\1f
+File: gccint.info, Node: Jump Patterns, Next: Looping Patterns, Prev: Dependent Patterns, Up: Machine Desc
+
+16.12 Defining Jump Instruction Patterns
+========================================
+
+For most machines, GCC assumes that the machine has a condition code.
+A comparison insn sets the condition code, recording the results of both
+signed and unsigned comparison of the given operands. A separate branch
+insn tests the condition code and branches or not according its value.
+The branch insns come in distinct signed and unsigned flavors. Many
+common machines, such as the VAX, the 68000 and the 32000, work this
+way.
+
+ Some machines have distinct signed and unsigned compare instructions,
+and only one set of conditional branch instructions. The easiest way
+to handle these machines is to treat them just like the others until
+the final stage where assembly code is written. At this time, when
+outputting code for the compare instruction, peek ahead at the
+following branch using `next_cc0_user (insn)'. (The variable `insn'
+refers to the insn being output, in the output-writing code in an
+instruction pattern.) If the RTL says that is an unsigned branch,
+output an unsigned compare; otherwise output a signed compare. When
+the branch itself is output, you can treat signed and unsigned branches
+identically.
+
+ The reason you can do this is that GCC always generates a pair of
+consecutive RTL insns, possibly separated by `note' insns, one to set
+the condition code and one to test it, and keeps the pair inviolate
+until the end.
+
+ To go with this technique, you must define the machine-description
+macro `NOTICE_UPDATE_CC' to do `CC_STATUS_INIT'; in other words, no
+compare instruction is superfluous.
+
+ Some machines have compare-and-branch instructions and no condition
+code. A similar technique works for them. When it is time to "output"
+a compare instruction, record its operands in two static variables.
+When outputting the branch-on-condition-code instruction that follows,
+actually output a compare-and-branch instruction that uses the
+remembered operands.
+
+ It also works to define patterns for compare-and-branch instructions.
+In optimizing compilation, the pair of compare and branch instructions
+will be combined according to these patterns. But this does not happen
+if optimization is not requested. So you must use one of the solutions
+above in addition to any special patterns you define.
+
+ In many RISC machines, most instructions do not affect the condition
+code and there may not even be a separate condition code register. On
+these machines, the restriction that the definition and use of the
+condition code be adjacent insns is not necessary and can prevent
+important optimizations. For example, on the IBM RS/6000, there is a
+delay for taken branches unless the condition code register is set three
+instructions earlier than the conditional branch. The instruction
+scheduler cannot perform this optimization if it is not permitted to
+separate the definition and use of the condition code register.
+
+ On these machines, do not use `(cc0)', but instead use a register to
+represent the condition code. If there is a specific condition code
+register in the machine, use a hard register. If the condition code or
+comparison result can be placed in any general register, or if there are
+multiple condition registers, use a pseudo register.
+
+ On some machines, the type of branch instruction generated may depend
+on the way the condition code was produced; for example, on the 68k and
+SPARC, setting the condition code directly from an add or subtract
+instruction does not clear the overflow bit the way that a test
+instruction does, so a different branch instruction must be used for
+some conditional branches. For machines that use `(cc0)', the set and
+use of the condition code must be adjacent (separated only by `note'
+insns) allowing flags in `cc_status' to be used. (*Note Condition
+Code::.) Also, the comparison and branch insns can be located from
+each other by using the functions `prev_cc0_setter' and `next_cc0_user'.
+
+ However, this is not true on machines that do not use `(cc0)'. On
+those machines, no assumptions can be made about the adjacency of the
+compare and branch insns and the above methods cannot be used. Instead,
+we use the machine mode of the condition code register to record
+different formats of the condition code register.
+
+ Registers used to store the condition code value should have a mode
+that is in class `MODE_CC'. Normally, it will be `CCmode'. If
+additional modes are required (as for the add example mentioned above in
+the SPARC), define them in `MACHINE-modes.def' (*note Condition
+Code::). Also define `SELECT_CC_MODE' to choose a mode given an
+operand of a compare.
+
+ If it is known during RTL generation that a different mode will be
+required (for example, if the machine has separate compare instructions
+for signed and unsigned quantities, like most IBM processors), they can
+be specified at that time.
+
+ If the cases that require different modes would be made by instruction
+combination, the macro `SELECT_CC_MODE' determines which machine mode
+should be used for the comparison result. The patterns should be
+written using that mode. To support the case of the add on the SPARC
+discussed above, we have the pattern
+
+ (define_insn ""
+ [(set (reg:CC_NOOV 0)
+ (compare:CC_NOOV
+ (plus:SI (match_operand:SI 0 "register_operand" "%r")
+ (match_operand:SI 1 "arith_operand" "rI"))
+ (const_int 0)))]
+ ""
+ "...")
+
+ The `SELECT_CC_MODE' macro on the SPARC returns `CC_NOOVmode' for
+comparisons whose argument is a `plus'.
+
+\1f
+File: gccint.info, Node: Looping Patterns, Next: Insn Canonicalizations, Prev: Jump Patterns, Up: Machine Desc
+
+16.13 Defining Looping Instruction Patterns
+===========================================
+
+Some machines have special jump instructions that can be utilized to
+make loops more efficient. A common example is the 68000 `dbra'
+instruction which performs a decrement of a register and a branch if the
+result was greater than zero. Other machines, in particular digital
+signal processors (DSPs), have special block repeat instructions to
+provide low-overhead loop support. For example, the TI TMS320C3x/C4x
+DSPs have a block repeat instruction that loads special registers to
+mark the top and end of a loop and to count the number of loop
+iterations. This avoids the need for fetching and executing a
+`dbra'-like instruction and avoids pipeline stalls associated with the
+jump.
+
+ GCC has three special named patterns to support low overhead looping.
+They are `decrement_and_branch_until_zero', `doloop_begin', and
+`doloop_end'. The first pattern, `decrement_and_branch_until_zero', is
+not emitted during RTL generation but may be emitted during the
+instruction combination phase. This requires the assistance of the
+loop optimizer, using information collected during strength reduction,
+to reverse a loop to count down to zero. Some targets also require the
+loop optimizer to add a `REG_NONNEG' note to indicate that the
+iteration count is always positive. This is needed if the target
+performs a signed loop termination test. For example, the 68000 uses a
+pattern similar to the following for its `dbra' instruction:
+
+ (define_insn "decrement_and_branch_until_zero"
+ [(set (pc)
+ (if_then_else
+ (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am")
+ (const_int -1))
+ (const_int 0))
+ (label_ref (match_operand 1 "" ""))
+ (pc)))
+ (set (match_dup 0)
+ (plus:SI (match_dup 0)
+ (const_int -1)))]
+ "find_reg_note (insn, REG_NONNEG, 0)"
+ "...")
+
+ Note that since the insn is both a jump insn and has an output, it must
+deal with its own reloads, hence the `m' constraints. Also note that
+since this insn is generated by the instruction combination phase
+combining two sequential insns together into an implicit parallel insn,
+the iteration counter needs to be biased by the same amount as the
+decrement operation, in this case -1. Note that the following similar
+pattern will not be matched by the combiner.
+
+ (define_insn "decrement_and_branch_until_zero"
+ [(set (pc)
+ (if_then_else
+ (ge (match_operand:SI 0 "general_operand" "+d*am")
+ (const_int 1))
+ (label_ref (match_operand 1 "" ""))
+ (pc)))
+ (set (match_dup 0)
+ (plus:SI (match_dup 0)
+ (const_int -1)))]
+ "find_reg_note (insn, REG_NONNEG, 0)"
+ "...")
+
+ The other two special looping patterns, `doloop_begin' and
+`doloop_end', are emitted by the loop optimizer for certain
+well-behaved loops with a finite number of loop iterations using
+information collected during strength reduction.
+
+ The `doloop_end' pattern describes the actual looping instruction (or
+the implicit looping operation) and the `doloop_begin' pattern is an
+optional companion pattern that can be used for initialization needed
+for some low-overhead looping instructions.
+
+ Note that some machines require the actual looping instruction to be
+emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs). Emitting
+the true RTL for a looping instruction at the top of the loop can cause
+problems with flow analysis. So instead, a dummy `doloop' insn is
+emitted at the end of the loop. The machine dependent reorg pass checks
+for the presence of this `doloop' insn and then searches back to the
+top of the loop, where it inserts the true looping insn (provided there
+are no instructions in the loop which would cause problems). Any
+additional labels can be emitted at this point. In addition, if the
+desired special iteration counter register was not allocated, this
+machine dependent reorg pass could emit a traditional compare and jump
+instruction pair.
+
+ The essential difference between the `decrement_and_branch_until_zero'
+and the `doloop_end' patterns is that the loop optimizer allocates an
+additional pseudo register for the latter as an iteration counter.
+This pseudo register cannot be used within the loop (i.e., general
+induction variables cannot be derived from it), however, in many cases
+the loop induction variable may become redundant and removed by the
+flow pass.
+
+\1f
+File: gccint.info, Node: Insn Canonicalizations, Next: Expander Definitions, Prev: Looping Patterns, Up: Machine Desc
+
+16.14 Canonicalization of Instructions
+======================================
+
+There are often cases where multiple RTL expressions could represent an
+operation performed by a single machine instruction. This situation is
+most commonly encountered with logical, branch, and multiply-accumulate
+instructions. In such cases, the compiler attempts to convert these
+multiple RTL expressions into a single canonical form to reduce the
+number of insn patterns required.
+
+ In addition to algebraic simplifications, following canonicalizations
+are performed:
+
+ * For commutative and comparison operators, a constant is always
+ made the second operand. If a machine only supports a constant as
+ the second operand, only patterns that match a constant in the
+ second operand need be supplied.
+
+ * For associative operators, a sequence of operators will always
+ chain to the left; for instance, only the left operand of an
+ integer `plus' can itself be a `plus'. `and', `ior', `xor',
+ `plus', `mult', `smin', `smax', `umin', and `umax' are associative
+ when applied to integers, and sometimes to floating-point.
+
+ * For these operators, if only one operand is a `neg', `not',
+ `mult', `plus', or `minus' expression, it will be the first
+ operand.
+
+ * In combinations of `neg', `mult', `plus', and `minus', the `neg'
+ operations (if any) will be moved inside the operations as far as
+ possible. For instance, `(neg (mult A B))' is canonicalized as
+ `(mult (neg A) B)', but `(plus (mult (neg A) B) C)' is
+ canonicalized as `(minus A (mult B C))'.
+
+ * For the `compare' operator, a constant is always the second operand
+ on machines where `cc0' is used (*note Jump Patterns::). On other
+ machines, there are rare cases where the compiler might want to
+ construct a `compare' with a constant as the first operand.
+ However, these cases are not common enough for it to be worthwhile
+ to provide a pattern matching a constant as the first operand
+ unless the machine actually has such an instruction.
+
+ An operand of `neg', `not', `mult', `plus', or `minus' is made the
+ first operand under the same conditions as above.
+
+ * `(ltu (plus A B) B)' is converted to `(ltu (plus A B) A)'.
+ Likewise with `geu' instead of `ltu'.
+
+ * `(minus X (const_int N))' is converted to `(plus X (const_int
+ -N))'.
+
+ * Within address computations (i.e., inside `mem'), a left shift is
+ converted into the appropriate multiplication by a power of two.
+
+ * De Morgan's Law is used to move bitwise negation inside a bitwise
+ logical-and or logical-or operation. If this results in only one
+ operand being a `not' expression, it will be the first one.
+
+ A machine that has an instruction that performs a bitwise
+ logical-and of one operand with the bitwise negation of the other
+ should specify the pattern for that instruction as
+
+ (define_insn ""
+ [(set (match_operand:M 0 ...)
+ (and:M (not:M (match_operand:M 1 ...))
+ (match_operand:M 2 ...)))]
+ "..."
+ "...")
+
+ Similarly, a pattern for a "NAND" instruction should be written
+
+ (define_insn ""
+ [(set (match_operand:M 0 ...)
+ (ior:M (not:M (match_operand:M 1 ...))
+ (not:M (match_operand:M 2 ...))))]
+ "..."
+ "...")
+
+ In both cases, it is not necessary to include patterns for the many
+ logically equivalent RTL expressions.
+
+ * The only possible RTL expressions involving both bitwise
+ exclusive-or and bitwise negation are `(xor:M X Y)' and `(not:M
+ (xor:M X Y))'.
+
+ * The sum of three items, one of which is a constant, will only
+ appear in the form
+
+ (plus:M (plus:M X Y) CONSTANT)
+
+ * On machines that do not use `cc0', `(compare X (const_int 0))'
+ will be converted to X.
+
+ * Equality comparisons of a group of bits (usually a single bit)
+ with zero will be written using `zero_extract' rather than the
+ equivalent `and' or `sign_extract' operations.
+
+
+ Further canonicalization rules are defined in the function
+`commutative_operand_precedence' in `gcc/rtlanal.c'.
+
+\1f
+File: gccint.info, Node: Expander Definitions, Next: Insn Splitting, Prev: Insn Canonicalizations, Up: Machine Desc
+
+16.15 Defining RTL Sequences for Code Generation
+================================================
+
+On some target machines, some standard pattern names for RTL generation
+cannot be handled with single insn, but a sequence of RTL insns can
+represent them. For these target machines, you can write a
+`define_expand' to specify how to generate the sequence of RTL.
+
+ A `define_expand' is an RTL expression that looks almost like a
+`define_insn'; but, unlike the latter, a `define_expand' is used only
+for RTL generation and it can produce more than one RTL insn.
+
+ A `define_expand' RTX has four operands:
+
+ * The name. Each `define_expand' must have a name, since the only
+ use for it is to refer to it by name.
+
+ * The RTL template. This is a vector of RTL expressions representing
+ a sequence of separate instructions. Unlike `define_insn', there
+ is no implicit surrounding `PARALLEL'.
+
+ * The condition, a string containing a C expression. This
+ expression is used to express how the availability of this pattern
+ depends on subclasses of target machine, selected by command-line
+ options when GCC is run. This is just like the condition of a
+ `define_insn' that has a standard name. Therefore, the condition
+ (if present) may not depend on the data in the insn being matched,
+ but only the target-machine-type flags. The compiler needs to
+ test these conditions during initialization in order to learn
+ exactly which named instructions are available in a particular run.
+
+ * The preparation statements, a string containing zero or more C
+ statements which are to be executed before RTL code is generated
+ from the RTL template.
+
+ Usually these statements prepare temporary registers for use as
+ internal operands in the RTL template, but they can also generate
+ RTL insns directly by calling routines such as `emit_insn', etc.
+ Any such insns precede the ones that come from the RTL template.
+
+ Every RTL insn emitted by a `define_expand' must match some
+`define_insn' in the machine description. Otherwise, the compiler will
+crash when trying to generate code for the insn or trying to optimize
+it.
+
+ The RTL template, in addition to controlling generation of RTL insns,
+also describes the operands that need to be specified when this pattern
+is used. In particular, it gives a predicate for each operand.
+
+ A true operand, which needs to be specified in order to generate RTL
+from the pattern, should be described with a `match_operand' in its
+first occurrence in the RTL template. This enters information on the
+operand's predicate into the tables that record such things. GCC uses
+the information to preload the operand into a register if that is
+required for valid RTL code. If the operand is referred to more than
+once, subsequent references should use `match_dup'.
+
+ The RTL template may also refer to internal "operands" which are
+temporary registers or labels used only within the sequence made by the
+`define_expand'. Internal operands are substituted into the RTL
+template with `match_dup', never with `match_operand'. The values of
+the internal operands are not passed in as arguments by the compiler
+when it requests use of this pattern. Instead, they are computed
+within the pattern, in the preparation statements. These statements
+compute the values and store them into the appropriate elements of
+`operands' so that `match_dup' can find them.
+
+ There are two special macros defined for use in the preparation
+statements: `DONE' and `FAIL'. Use them with a following semicolon, as
+a statement.
+
+`DONE'
+ Use the `DONE' macro to end RTL generation for the pattern. The
+ only RTL insns resulting from the pattern on this occasion will be
+ those already emitted by explicit calls to `emit_insn' within the
+ preparation statements; the RTL template will not be generated.
+
+`FAIL'
+ Make the pattern fail on this occasion. When a pattern fails, it
+ means that the pattern was not truly available. The calling
+ routines in the compiler will try other strategies for code
+ generation using other patterns.
+
+ Failure is currently supported only for binary (addition,
+ multiplication, shifting, etc.) and bit-field (`extv', `extzv',
+ and `insv') operations.
+
+ If the preparation falls through (invokes neither `DONE' nor `FAIL'),
+then the `define_expand' acts like a `define_insn' in that the RTL
+template is used to generate the insn.
+
+ The RTL template is not used for matching, only for generating the
+initial insn list. If the preparation statement always invokes `DONE'
+or `FAIL', the RTL template may be reduced to a simple list of
+operands, such as this example:
+
+ (define_expand "addsi3"
+ [(match_operand:SI 0 "register_operand" "")
+ (match_operand:SI 1 "register_operand" "")
+ (match_operand:SI 2 "register_operand" "")]
+ ""
+ "
+ {
+ handle_add (operands[0], operands[1], operands[2]);
+ DONE;
+ }")
+
+ Here is an example, the definition of left-shift for the SPUR chip:
+
+ (define_expand "ashlsi3"
+ [(set (match_operand:SI 0 "register_operand" "")
+ (ashift:SI
+ (match_operand:SI 1 "register_operand" "")
+ (match_operand:SI 2 "nonmemory_operand" "")))]
+ ""
+ "
+
+ {
+ if (GET_CODE (operands[2]) != CONST_INT
+ || (unsigned) INTVAL (operands[2]) > 3)
+ FAIL;
+ }")
+
+This example uses `define_expand' so that it can generate an RTL insn
+for shifting when the shift-count is in the supported range of 0 to 3
+but fail in other cases where machine insns aren't available. When it
+fails, the compiler tries another strategy using different patterns
+(such as, a library call).
+
+ If the compiler were able to handle nontrivial condition-strings in
+patterns with names, then it would be possible to use a `define_insn'
+in that case. Here is another case (zero-extension on the 68000) which
+makes more use of the power of `define_expand':
+
+ (define_expand "zero_extendhisi2"
+ [(set (match_operand:SI 0 "general_operand" "")
+ (const_int 0))
+ (set (strict_low_part
+ (subreg:HI
+ (match_dup 0)
+ 0))
+ (match_operand:HI 1 "general_operand" ""))]
+ ""
+ "operands[1] = make_safe_from (operands[1], operands[0]);")
+
+Here two RTL insns are generated, one to clear the entire output operand
+and the other to copy the input operand into its low half. This
+sequence is incorrect if the input operand refers to [the old value of]
+the output operand, so the preparation statement makes sure this isn't
+so. The function `make_safe_from' copies the `operands[1]' into a
+temporary register if it refers to `operands[0]'. It does this by
+emitting another RTL insn.
+
+ Finally, a third example shows the use of an internal operand.
+Zero-extension on the SPUR chip is done by `and'-ing the result against
+a halfword mask. But this mask cannot be represented by a `const_int'
+because the constant value is too large to be legitimate on this
+machine. So it must be copied into a register with `force_reg' and
+then the register used in the `and'.
+
+ (define_expand "zero_extendhisi2"
+ [(set (match_operand:SI 0 "register_operand" "")
+ (and:SI (subreg:SI
+ (match_operand:HI 1 "register_operand" "")
+ 0)
+ (match_dup 2)))]
+ ""
+ "operands[2]
+ = force_reg (SImode, GEN_INT (65535)); ")
+
+ _Note:_ If the `define_expand' is used to serve a standard binary or
+unary arithmetic operation or a bit-field operation, then the last insn
+it generates must not be a `code_label', `barrier' or `note'. It must
+be an `insn', `jump_insn' or `call_insn'. If you don't need a real insn
+at the end, emit an insn to copy the result of the operation into
+itself. Such an insn will generate no code, but it can avoid problems
+in the compiler.
+
+\1f
+File: gccint.info, Node: Insn Splitting, Next: Including Patterns, Prev: Expander Definitions, Up: Machine Desc
+
+16.16 Defining How to Split Instructions
+========================================
+
+There are two cases where you should specify how to split a pattern
+into multiple insns. On machines that have instructions requiring
+delay slots (*note Delay Slots::) or that have instructions whose
+output is not available for multiple cycles (*note Processor pipeline
+description::), the compiler phases that optimize these cases need to
+be able to move insns into one-instruction delay slots. However, some
+insns may generate more than one machine instruction. These insns
+cannot be placed into a delay slot.
+
+ Often you can rewrite the single insn as a list of individual insns,
+each corresponding to one machine instruction. The disadvantage of
+doing so is that it will cause the compilation to be slower and require
+more space. If the resulting insns are too complex, it may also
+suppress some optimizations. The compiler splits the insn if there is a
+reason to believe that it might improve instruction or delay slot
+scheduling.
+
+ The insn combiner phase also splits putative insns. If three insns are
+merged into one insn with a complex expression that cannot be matched by
+some `define_insn' pattern, the combiner phase attempts to split the
+complex pattern into two insns that are recognized. Usually it can
+break the complex pattern into two patterns by splitting out some
+subexpression. However, in some other cases, such as performing an
+addition of a large constant in two insns on a RISC machine, the way to
+split the addition into two insns is machine-dependent.
+
+ The `define_split' definition tells the compiler how to split a
+complex insn into several simpler insns. It looks like this:
+
+ (define_split
+ [INSN-PATTERN]
+ "CONDITION"
+ [NEW-INSN-PATTERN-1
+ NEW-INSN-PATTERN-2
+ ...]
+ "PREPARATION-STATEMENTS")
+
+ INSN-PATTERN is a pattern that needs to be split and CONDITION is the
+final condition to be tested, as in a `define_insn'. When an insn
+matching INSN-PATTERN and satisfying CONDITION is found, it is replaced
+in the insn list with the insns given by NEW-INSN-PATTERN-1,
+NEW-INSN-PATTERN-2, etc.
+
+ The PREPARATION-STATEMENTS are similar to those statements that are
+specified for `define_expand' (*note Expander Definitions::) and are
+executed before the new RTL is generated to prepare for the generated
+code or emit some insns whose pattern is not fixed. Unlike those in
+`define_expand', however, these statements must not generate any new
+pseudo-registers. Once reload has completed, they also must not
+allocate any space in the stack frame.
+
+ Patterns are matched against INSN-PATTERN in two different
+circumstances. If an insn needs to be split for delay slot scheduling
+or insn scheduling, the insn is already known to be valid, which means
+that it must have been matched by some `define_insn' and, if
+`reload_completed' is nonzero, is known to satisfy the constraints of
+that `define_insn'. In that case, the new insn patterns must also be
+insns that are matched by some `define_insn' and, if `reload_completed'
+is nonzero, must also satisfy the constraints of those definitions.
+
+ As an example of this usage of `define_split', consider the following
+example from `a29k.md', which splits a `sign_extend' from `HImode' to
+`SImode' into a pair of shift insns:
+
+ (define_split
+ [(set (match_operand:SI 0 "gen_reg_operand" "")
+ (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))]
+ ""
+ [(set (match_dup 0)
+ (ashift:SI (match_dup 1)
+ (const_int 16)))
+ (set (match_dup 0)
+ (ashiftrt:SI (match_dup 0)
+ (const_int 16)))]
+ "
+ { operands[1] = gen_lowpart (SImode, operands[1]); }")
+
+ When the combiner phase tries to split an insn pattern, it is always
+the case that the pattern is _not_ matched by any `define_insn'. The
+combiner pass first tries to split a single `set' expression and then
+the same `set' expression inside a `parallel', but followed by a
+`clobber' of a pseudo-reg to use as a scratch register. In these
+cases, the combiner expects exactly two new insn patterns to be
+generated. It will verify that these patterns match some `define_insn'
+definitions, so you need not do this test in the `define_split' (of
+course, there is no point in writing a `define_split' that will never
+produce insns that match).
+
+ Here is an example of this use of `define_split', taken from
+`rs6000.md':
+
+ (define_split
+ [(set (match_operand:SI 0 "gen_reg_operand" "")
+ (plus:SI (match_operand:SI 1 "gen_reg_operand" "")
+ (match_operand:SI 2 "non_add_cint_operand" "")))]
+ ""
+ [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3)))
+ (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))]
+ "
+ {
+ int low = INTVAL (operands[2]) & 0xffff;
+ int high = (unsigned) INTVAL (operands[2]) >> 16;
+
+ if (low & 0x8000)
+ high++, low |= 0xffff0000;
+
+ operands[3] = GEN_INT (high << 16);
+ operands[4] = GEN_INT (low);
+ }")
+
+ Here the predicate `non_add_cint_operand' matches any `const_int' that
+is _not_ a valid operand of a single add insn. The add with the
+smaller displacement is written so that it can be substituted into the
+address of a subsequent operation.
+
+ An example that uses a scratch register, from the same file, generates
+an equality comparison of a register and a large constant:
+
+ (define_split
+ [(set (match_operand:CC 0 "cc_reg_operand" "")
+ (compare:CC (match_operand:SI 1 "gen_reg_operand" "")
+ (match_operand:SI 2 "non_short_cint_operand" "")))
+ (clobber (match_operand:SI 3 "gen_reg_operand" ""))]
+ "find_single_use (operands[0], insn, 0)
+ && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ
+ || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)"
+ [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4)))
+ (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))]
+ "
+ {
+ /* Get the constant we are comparing against, C, and see what it
+ looks like sign-extended to 16 bits. Then see what constant
+ could be XOR'ed with C to get the sign-extended value. */
+
+ int c = INTVAL (operands[2]);
+ int sextc = (c << 16) >> 16;
+ int xorv = c ^ sextc;
+
+ operands[4] = GEN_INT (xorv);
+ operands[5] = GEN_INT (sextc);
+ }")
+
+ To avoid confusion, don't write a single `define_split' that accepts
+some insns that match some `define_insn' as well as some insns that
+don't. Instead, write two separate `define_split' definitions, one for
+the insns that are valid and one for the insns that are not valid.
+
+ The splitter is allowed to split jump instructions into sequence of
+jumps or create new jumps in while splitting non-jump instructions. As
+the central flowgraph and branch prediction information needs to be
+updated, several restriction apply.
+
+ Splitting of jump instruction into sequence that over by another jump
+instruction is always valid, as compiler expect identical behavior of
+new jump. When new sequence contains multiple jump instructions or new
+labels, more assistance is needed. Splitter is required to create only
+unconditional jumps, or simple conditional jump instructions.
+Additionally it must attach a `REG_BR_PROB' note to each conditional
+jump. A global variable `split_branch_probability' holds the
+probability of the original branch in case it was an simple conditional
+jump, -1 otherwise. To simplify recomputing of edge frequencies, the
+new sequence is required to have only forward jumps to the newly
+created labels.
+
+ For the common case where the pattern of a define_split exactly
+matches the pattern of a define_insn, use `define_insn_and_split'. It
+looks like this:
+
+ (define_insn_and_split
+ [INSN-PATTERN]
+ "CONDITION"
+ "OUTPUT-TEMPLATE"
+ "SPLIT-CONDITION"
+ [NEW-INSN-PATTERN-1
+ NEW-INSN-PATTERN-2
+ ...]
+ "PREPARATION-STATEMENTS"
+ [INSN-ATTRIBUTES])
+
+ INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used
+as in `define_insn'. The NEW-INSN-PATTERN vector and the
+PREPARATION-STATEMENTS are used as in a `define_split'. The
+SPLIT-CONDITION is also used as in `define_split', with the additional
+behavior that if the condition starts with `&&', the condition used for
+the split will be the constructed as a logical "and" of the split
+condition with the insn condition. For example, from i386.md:
+
+ (define_insn_and_split "zero_extendhisi2_and"
+ [(set (match_operand:SI 0 "register_operand" "=r")
+ (zero_extend:SI (match_operand:HI 1 "register_operand" "0")))
+ (clobber (reg:CC 17))]
+ "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size"
+ "#"
+ "&& reload_completed"
+ [(parallel [(set (match_dup 0)
+ (and:SI (match_dup 0) (const_int 65535)))
+ (clobber (reg:CC 17))])]
+ ""
+ [(set_attr "type" "alu1")])
+
+ In this case, the actual split condition will be
+`TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'.
+
+ The `define_insn_and_split' construction provides exactly the same
+functionality as two separate `define_insn' and `define_split'
+patterns. It exists for compactness, and as a maintenance tool to
+prevent having to ensure the two patterns' templates match.
+
+\1f
+File: gccint.info, Node: Including Patterns, Next: Peephole Definitions, Prev: Insn Splitting, Up: Machine Desc
+
+16.17 Including Patterns in Machine Descriptions.
+=================================================
+
+The `include' pattern tells the compiler tools where to look for
+patterns that are in files other than in the file `.md'. This is used
+only at build time and there is no preprocessing allowed.
+
+ It looks like:
+
+
+ (include
+ PATHNAME)
+
+ For example:
+
+
+ (include "filestuff")
+
+ Where PATHNAME is a string that specifies the location of the file,
+specifies the include file to be in `gcc/config/target/filestuff'. The
+directory `gcc/config/target' is regarded as the default directory.
+
+ Machine descriptions may be split up into smaller more manageable
+subsections and placed into subdirectories.
+
+ By specifying:
+
+
+ (include "BOGUS/filestuff")
+
+ the include file is specified to be in
+`gcc/config/TARGET/BOGUS/filestuff'.
+
+ Specifying an absolute path for the include file such as;
+
+ (include "/u2/BOGUS/filestuff")
+ is permitted but is not encouraged.
+
+16.17.1 RTL Generation Tool Options for Directory Search
+--------------------------------------------------------
+
+The `-IDIR' option specifies directories to search for machine
+descriptions. For example:
+
+
+ genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md
+
+ Add the directory DIR to the head of the list of directories to be
+searched for header files. This can be used to override a system
+machine definition file, substituting your own version, since these
+directories are searched before the default machine description file
+directories. If you use more than one `-I' option, the directories are
+scanned in left-to-right order; the standard default directory come
+after.
+
+\1f
+File: gccint.info, Node: Peephole Definitions, Next: Insn Attributes, Prev: Including Patterns, Up: Machine Desc
+
+16.18 Machine-Specific Peephole Optimizers
+==========================================
+
+In addition to instruction patterns the `md' file may contain
+definitions of machine-specific peephole optimizations.
+
+ The combiner does not notice certain peephole optimizations when the
+data flow in the program does not suggest that it should try them. For
+example, sometimes two consecutive insns related in purpose can be
+combined even though the second one does not appear to use a register
+computed in the first one. A machine-specific peephole optimizer can
+detect such opportunities.
+
+ There are two forms of peephole definitions that may be used. The
+original `define_peephole' is run at assembly output time to match
+insns and substitute assembly text. Use of `define_peephole' is
+deprecated.
+
+ A newer `define_peephole2' matches insns and substitutes new insns.
+The `peephole2' pass is run after register allocation but before
+scheduling, which may result in much better code for targets that do
+scheduling.
+
+* Menu:
+
+* define_peephole:: RTL to Text Peephole Optimizers
+* define_peephole2:: RTL to RTL Peephole Optimizers
+
+\1f
+File: gccint.info, Node: define_peephole, Next: define_peephole2, Up: Peephole Definitions
+
+16.18.1 RTL to Text Peephole Optimizers
+---------------------------------------
+
+A definition looks like this:
+
+ (define_peephole
+ [INSN-PATTERN-1
+ INSN-PATTERN-2
+ ...]
+ "CONDITION"
+ "TEMPLATE"
+ "OPTIONAL-INSN-ATTRIBUTES")
+
+The last string operand may be omitted if you are not using any
+machine-specific information in this machine description. If present,
+it must obey the same rules as in a `define_insn'.
+
+ In this skeleton, INSN-PATTERN-1 and so on are patterns to match
+consecutive insns. The optimization applies to a sequence of insns when
+INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next,
+and so on.
+
+ Each of the insns matched by a peephole must also match a
+`define_insn'. Peepholes are checked only at the last stage just
+before code generation, and only optionally. Therefore, any insn which
+would match a peephole but no `define_insn' will cause a crash in code
+generation in an unoptimized compilation, or at various optimization
+stages.
+
+ The operands of the insns are matched with `match_operands',
+`match_operator', and `match_dup', as usual. What is not usual is that
+the operand numbers apply to all the insn patterns in the definition.
+So, you can check for identical operands in two insns by using
+`match_operand' in one insn and `match_dup' in the other.
+
+ The operand constraints used in `match_operand' patterns do not have
+any direct effect on the applicability of the peephole, but they will
+be validated afterward, so make sure your constraints are general enough
+to apply whenever the peephole matches. If the peephole matches but
+the constraints are not satisfied, the compiler will crash.
+
+ It is safe to omit constraints in all the operands of the peephole; or
+you can write constraints which serve as a double-check on the criteria
+previously tested.
+
+ Once a sequence of insns matches the patterns, the CONDITION is
+checked. This is a C expression which makes the final decision whether
+to perform the optimization (we do so if the expression is nonzero). If
+CONDITION is omitted (in other words, the string is empty) then the
+optimization is applied to every sequence of insns that matches the
+patterns.
+
+ The defined peephole optimizations are applied after register
+allocation is complete. Therefore, the peephole definition can check
+which operands have ended up in which kinds of registers, just by
+looking at the operands.
+
+ The way to refer to the operands in CONDITION is to write
+`operands[I]' for operand number I (as matched by `(match_operand I
+...)'). Use the variable `insn' to refer to the last of the insns
+being matched; use `prev_active_insn' to find the preceding insns.
+
+ When optimizing computations with intermediate results, you can use
+CONDITION to match only when the intermediate results are not used
+elsewhere. Use the C expression `dead_or_set_p (INSN, OP)', where INSN
+is the insn in which you expect the value to be used for the last time
+(from the value of `insn', together with use of `prev_nonnote_insn'),
+and OP is the intermediate value (from `operands[I]').
+
+ Applying the optimization means replacing the sequence of insns with
+one new insn. The TEMPLATE controls ultimate output of assembler code
+for this combined insn. It works exactly like the template of a
+`define_insn'. Operand numbers in this template are the same ones used
+in matching the original sequence of insns.
+
+ The result of a defined peephole optimizer does not need to match any
+of the insn patterns in the machine description; it does not even have
+an opportunity to match them. The peephole optimizer definition itself
+serves as the insn pattern to control how the insn is output.
+
+ Defined peephole optimizers are run as assembler code is being output,
+so the insns they produce are never combined or rearranged in any way.
+
+ Here is an example, taken from the 68000 machine description:
+
+ (define_peephole
+ [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4)))
+ (set (match_operand:DF 0 "register_operand" "=f")
+ (match_operand:DF 1 "register_operand" "ad"))]
+ "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])"
+ {
+ rtx xoperands[2];
+ xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1);
+ #ifdef MOTOROLA
+ output_asm_insn ("move.l %1,(sp)", xoperands);
+ output_asm_insn ("move.l %1,-(sp)", operands);
+ return "fmove.d (sp)+,%0";
+ #else
+ output_asm_insn ("movel %1,sp@", xoperands);
+ output_asm_insn ("movel %1,sp@-", operands);
+ return "fmoved sp@+,%0";
+ #endif
+ })
+
+ The effect of this optimization is to change
+
+ jbsr _foobar
+ addql #4,sp
+ movel d1,sp@-
+ movel d0,sp@-
+ fmoved sp@+,fp0
+
+into
+
+ jbsr _foobar
+ movel d1,sp@
+ movel d0,sp@-
+ fmoved sp@+,fp0
+
+ INSN-PATTERN-1 and so on look _almost_ like the second operand of
+`define_insn'. There is one important difference: the second operand
+of `define_insn' consists of one or more RTX's enclosed in square
+brackets. Usually, there is only one: then the same action can be
+written as an element of a `define_peephole'. But when there are
+multiple actions in a `define_insn', they are implicitly enclosed in a
+`parallel'. Then you must explicitly write the `parallel', and the
+square brackets within it, in the `define_peephole'. Thus, if an insn
+pattern looks like this,
+
+ (define_insn "divmodsi4"
+ [(set (match_operand:SI 0 "general_operand" "=d")
+ (div:SI (match_operand:SI 1 "general_operand" "0")
+ (match_operand:SI 2 "general_operand" "dmsK")))
+ (set (match_operand:SI 3 "general_operand" "=d")
+ (mod:SI (match_dup 1) (match_dup 2)))]
+ "TARGET_68020"
+ "divsl%.l %2,%3:%0")
+
+then the way to mention this insn in a peephole is as follows:
+
+ (define_peephole
+ [...
+ (parallel
+ [(set (match_operand:SI 0 "general_operand" "=d")
+ (div:SI (match_operand:SI 1 "general_operand" "0")
+ (match_operand:SI 2 "general_operand" "dmsK")))
+ (set (match_operand:SI 3 "general_operand" "=d")
+ (mod:SI (match_dup 1) (match_dup 2)))])
+ ...]
+ ...)
+
+\1f
+File: gccint.info, Node: define_peephole2, Prev: define_peephole, Up: Peephole Definitions
+
+16.18.2 RTL to RTL Peephole Optimizers
+--------------------------------------
+
+The `define_peephole2' definition tells the compiler how to substitute
+one sequence of instructions for another sequence, what additional
+scratch registers may be needed and what their lifetimes must be.
+
+ (define_peephole2
+ [INSN-PATTERN-1
+ INSN-PATTERN-2
+ ...]
+ "CONDITION"
+ [NEW-INSN-PATTERN-1
+ NEW-INSN-PATTERN-2
+ ...]
+ "PREPARATION-STATEMENTS")
+
+ The definition is almost identical to `define_split' (*note Insn
+Splitting::) except that the pattern to match is not a single
+instruction, but a sequence of instructions.
+
+ It is possible to request additional scratch registers for use in the
+output template. If appropriate registers are not free, the pattern
+will simply not match.
+
+ Scratch registers are requested with a `match_scratch' pattern at the
+top level of the input pattern. The allocated register (initially) will
+be dead at the point requested within the original sequence. If the
+scratch is used at more than a single point, a `match_dup' pattern at
+the top level of the input pattern marks the last position in the input
+sequence at which the register must be available.
+
+ Here is an example from the IA-32 machine description:
+
+ (define_peephole2
+ [(match_scratch:SI 2 "r")
+ (parallel [(set (match_operand:SI 0 "register_operand" "")
+ (match_operator:SI 3 "arith_or_logical_operator"
+ [(match_dup 0)
+ (match_operand:SI 1 "memory_operand" "")]))
+ (clobber (reg:CC 17))])]
+ "! optimize_size && ! TARGET_READ_MODIFY"
+ [(set (match_dup 2) (match_dup 1))
+ (parallel [(set (match_dup 0)
+ (match_op_dup 3 [(match_dup 0) (match_dup 2)]))
+ (clobber (reg:CC 17))])]
+ "")
+
+This pattern tries to split a load from its use in the hopes that we'll
+be able to schedule around the memory load latency. It allocates a
+single `SImode' register of class `GENERAL_REGS' (`"r"') that needs to
+be live only at the point just before the arithmetic.
+
+ A real example requiring extended scratch lifetimes is harder to come
+by, so here's a silly made-up example:
+
+ (define_peephole2
+ [(match_scratch:SI 4 "r")
+ (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" ""))
+ (set (match_operand:SI 2 "" "") (match_dup 1))
+ (match_dup 4)
+ (set (match_operand:SI 3 "" "") (match_dup 1))]
+ "/* determine 1 does not overlap 0 and 2 */"
+ [(set (match_dup 4) (match_dup 1))
+ (set (match_dup 0) (match_dup 4))
+ (set (match_dup 2) (match_dup 4))]
+ (set (match_dup 3) (match_dup 4))]
+ "")
+
+If we had not added the `(match_dup 4)' in the middle of the input
+sequence, it might have been the case that the register we chose at the
+beginning of the sequence is killed by the first or second `set'.
+
+\1f
+File: gccint.info, Node: Insn Attributes, Next: Conditional Execution, Prev: Peephole Definitions, Up: Machine Desc
+
+16.19 Instruction Attributes
+============================
+
+In addition to describing the instruction supported by the target
+machine, the `md' file also defines a group of "attributes" and a set of
+values for each. Every generated insn is assigned a value for each
+attribute. One possible attribute would be the effect that the insn
+has on the machine's condition code. This attribute can then be used
+by `NOTICE_UPDATE_CC' to track the condition codes.
+
+* Menu:
+
+* Defining Attributes:: Specifying attributes and their values.
+* Expressions:: Valid expressions for attribute values.
+* Tagging Insns:: Assigning attribute values to insns.
+* Attr Example:: An example of assigning attributes.
+* Insn Lengths:: Computing the length of insns.
+* Constant Attributes:: Defining attributes that are constant.
+* Delay Slots:: Defining delay slots required for a machine.
+* Processor pipeline description:: Specifying information for insn scheduling.
+
+\1f
+File: gccint.info, Node: Defining Attributes, Next: Expressions, Up: Insn Attributes
+
+16.19.1 Defining Attributes and their Values
+--------------------------------------------
+
+The `define_attr' expression is used to define each attribute required
+by the target machine. It looks like:
+
+ (define_attr NAME LIST-OF-VALUES DEFAULT)
+
+ NAME is a string specifying the name of the attribute being defined.
+
+ LIST-OF-VALUES is either a string that specifies a comma-separated
+list of values that can be assigned to the attribute, or a null string
+to indicate that the attribute takes numeric values.
+
+ DEFAULT is an attribute expression that gives the value of this
+attribute for insns that match patterns whose definition does not
+include an explicit value for this attribute. *Note Attr Example::,
+for more information on the handling of defaults. *Note Constant
+Attributes::, for information on attributes that do not depend on any
+particular insn.
+
+ For each defined attribute, a number of definitions are written to the
+`insn-attr.h' file. For cases where an explicit set of values is
+specified for an attribute, the following are defined:
+
+ * A `#define' is written for the symbol `HAVE_ATTR_NAME'.
+
+ * An enumerated class is defined for `attr_NAME' with elements of
+ the form `UPPER-NAME_UPPER-VALUE' where the attribute name and
+ value are first converted to uppercase.
+
+ * A function `get_attr_NAME' is defined that is passed an insn and
+ returns the attribute value for that insn.
+
+ For example, if the following is present in the `md' file:
+
+ (define_attr "type" "branch,fp,load,store,arith" ...)
+
+the following lines will be written to the file `insn-attr.h'.
+
+ #define HAVE_ATTR_type
+ enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD,
+ TYPE_STORE, TYPE_ARITH};
+ extern enum attr_type get_attr_type ();
+
+ If the attribute takes numeric values, no `enum' type will be defined
+and the function to obtain the attribute's value will return `int'.
+
+ There are attributes which are tied to a specific meaning. These
+attributes are not free to use for other purposes:
+
+`length'
+ The `length' attribute is used to calculate the length of emitted
+ code chunks. This is especially important when verifying branch
+ distances. *Note Insn Lengths::.
+
+`enabled'
+ The `enabled' attribute can be defined to prevent certain
+ alternatives of an insn definition from being used during code
+ generation. *Note Disable Insn Alternatives::.
+
+
+\1f
+File: gccint.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes
+
+16.19.2 Attribute Expressions
+-----------------------------
+
+RTL expressions used to define attributes use the codes described above
+plus a few specific to attribute definitions, to be discussed below.
+Attribute value expressions must have one of the following forms:
+
+`(const_int I)'
+ The integer I specifies the value of a numeric attribute. I must
+ be non-negative.
+
+ The value of a numeric attribute can be specified either with a
+ `const_int', or as an integer represented as a string in
+ `const_string', `eq_attr' (see below), `attr', `symbol_ref',
+ simple arithmetic expressions, and `set_attr' overrides on
+ specific instructions (*note Tagging Insns::).
+
+`(const_string VALUE)'
+ The string VALUE specifies a constant attribute value. If VALUE
+ is specified as `"*"', it means that the default value of the
+ attribute is to be used for the insn containing this expression.
+ `"*"' obviously cannot be used in the DEFAULT expression of a
+ `define_attr'.
+
+ If the attribute whose value is being specified is numeric, VALUE
+ must be a string containing a non-negative integer (normally
+ `const_int' would be used in this case). Otherwise, it must
+ contain one of the valid values for the attribute.
+
+`(if_then_else TEST TRUE-VALUE FALSE-VALUE)'
+ TEST specifies an attribute test, whose format is defined below.
+ The value of this expression is TRUE-VALUE if TEST is true,
+ otherwise it is FALSE-VALUE.
+
+`(cond [TEST1 VALUE1 ...] DEFAULT)'
+ The first operand of this expression is a vector containing an even
+ number of expressions and consisting of pairs of TEST and VALUE
+ expressions. The value of the `cond' expression is that of the
+ VALUE corresponding to the first true TEST expression. If none of
+ the TEST expressions are true, the value of the `cond' expression
+ is that of the DEFAULT expression.
+
+ TEST expressions can have one of the following forms:
+
+`(const_int I)'
+ This test is true if I is nonzero and false otherwise.
+
+`(not TEST)'
+`(ior TEST1 TEST2)'
+`(and TEST1 TEST2)'
+ These tests are true if the indicated logical function is true.
+
+`(match_operand:M N PRED CONSTRAINTS)'
+ This test is true if operand N of the insn whose attribute value
+ is being determined has mode M (this part of the test is ignored
+ if M is `VOIDmode') and the function specified by the string PRED
+ returns a nonzero value when passed operand N and mode M (this
+ part of the test is ignored if PRED is the null string).
+
+ The CONSTRAINTS operand is ignored and should be the null string.
+
+`(le ARITH1 ARITH2)'
+`(leu ARITH1 ARITH2)'
+`(lt ARITH1 ARITH2)'
+`(ltu ARITH1 ARITH2)'
+`(gt ARITH1 ARITH2)'
+`(gtu ARITH1 ARITH2)'
+`(ge ARITH1 ARITH2)'
+`(geu ARITH1 ARITH2)'
+`(ne ARITH1 ARITH2)'
+`(eq ARITH1 ARITH2)'
+ These tests are true if the indicated comparison of the two
+ arithmetic expressions is true. Arithmetic expressions are formed
+ with `plus', `minus', `mult', `div', `mod', `abs', `neg', `and',
+ `ior', `xor', `not', `ashift', `lshiftrt', and `ashiftrt'
+ expressions.
+
+ `const_int' and `symbol_ref' are always valid terms (*note Insn
+ Lengths::,for additional forms). `symbol_ref' is a string
+ denoting a C expression that yields an `int' when evaluated by the
+ `get_attr_...' routine. It should normally be a global variable.
+
+`(eq_attr NAME VALUE)'
+ NAME is a string specifying the name of an attribute.
+
+ VALUE is a string that is either a valid value for attribute NAME,
+ a comma-separated list of values, or `!' followed by a value or
+ list. If VALUE does not begin with a `!', this test is true if
+ the value of the NAME attribute of the current insn is in the list
+ specified by VALUE. If VALUE begins with a `!', this test is true
+ if the attribute's value is _not_ in the specified list.
+
+ For example,
+
+ (eq_attr "type" "load,store")
+
+ is equivalent to
+
+ (ior (eq_attr "type" "load") (eq_attr "type" "store"))
+
+ If NAME specifies an attribute of `alternative', it refers to the
+ value of the compiler variable `which_alternative' (*note Output
+ Statement::) and the values must be small integers. For example,
+
+ (eq_attr "alternative" "2,3")
+
+ is equivalent to
+
+ (ior (eq (symbol_ref "which_alternative") (const_int 2))
+ (eq (symbol_ref "which_alternative") (const_int 3)))
+
+ Note that, for most attributes, an `eq_attr' test is simplified in
+ cases where the value of the attribute being tested is known for
+ all insns matching a particular pattern. This is by far the most
+ common case.
+
+`(attr_flag NAME)'
+ The value of an `attr_flag' expression is true if the flag
+ specified by NAME is true for the `insn' currently being scheduled.
+
+ NAME is a string specifying one of a fixed set of flags to test.
+ Test the flags `forward' and `backward' to determine the direction
+ of a conditional branch. Test the flags `very_likely', `likely',
+ `very_unlikely', and `unlikely' to determine if a conditional
+ branch is expected to be taken.
+
+ If the `very_likely' flag is true, then the `likely' flag is also
+ true. Likewise for the `very_unlikely' and `unlikely' flags.
+
+ This example describes a conditional branch delay slot which can
+ be nullified for forward branches that are taken (annul-true) or
+ for backward branches which are not taken (annul-false).
+
+ (define_delay (eq_attr "type" "cbranch")
+ [(eq_attr "in_branch_delay" "true")
+ (and (eq_attr "in_branch_delay" "true")
+ (attr_flag "forward"))
+ (and (eq_attr "in_branch_delay" "true")
+ (attr_flag "backward"))])
+
+ The `forward' and `backward' flags are false if the current `insn'
+ being scheduled is not a conditional branch.
+
+ The `very_likely' and `likely' flags are true if the `insn' being
+ scheduled is not a conditional branch. The `very_unlikely' and
+ `unlikely' flags are false if the `insn' being scheduled is not a
+ conditional branch.
+
+ `attr_flag' is only used during delay slot scheduling and has no
+ meaning to other passes of the compiler.
+
+`(attr NAME)'
+ The value of another attribute is returned. This is most useful
+ for numeric attributes, as `eq_attr' and `attr_flag' produce more
+ efficient code for non-numeric attributes.
+
+\1f
+File: gccint.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes
+
+16.19.3 Assigning Attribute Values to Insns
+-------------------------------------------
+
+The value assigned to an attribute of an insn is primarily determined by
+which pattern is matched by that insn (or which `define_peephole'
+generated it). Every `define_insn' and `define_peephole' can have an
+optional last argument to specify the values of attributes for matching
+insns. The value of any attribute not specified in a particular insn
+is set to the default value for that attribute, as specified in its
+`define_attr'. Extensive use of default values for attributes permits
+the specification of the values for only one or two attributes in the
+definition of most insn patterns, as seen in the example in the next
+section.
+
+ The optional last argument of `define_insn' and `define_peephole' is a
+vector of expressions, each of which defines the value for a single
+attribute. The most general way of assigning an attribute's value is
+to use a `set' expression whose first operand is an `attr' expression
+giving the name of the attribute being set. The second operand of the
+`set' is an attribute expression (*note Expressions::) giving the value
+of the attribute.
+
+ When the attribute value depends on the `alternative' attribute (i.e.,
+which is the applicable alternative in the constraint of the insn), the
+`set_attr_alternative' expression can be used. It allows the
+specification of a vector of attribute expressions, one for each
+alternative.
+
+ When the generality of arbitrary attribute expressions is not required,
+the simpler `set_attr' expression can be used, which allows specifying
+a string giving either a single attribute value or a list of attribute
+values, one for each alternative.
+
+ The form of each of the above specifications is shown below. In each
+case, NAME is a string specifying the attribute to be set.
+
+`(set_attr NAME VALUE-STRING)'
+ VALUE-STRING is either a string giving the desired attribute value,
+ or a string containing a comma-separated list giving the values for
+ succeeding alternatives. The number of elements must match the
+ number of alternatives in the constraint of the insn pattern.
+
+ Note that it may be useful to specify `*' for some alternative, in
+ which case the attribute will assume its default value for insns
+ matching that alternative.
+
+`(set_attr_alternative NAME [VALUE1 VALUE2 ...])'
+ Depending on the alternative of the insn, the value will be one of
+ the specified values. This is a shorthand for using a `cond' with
+ tests on the `alternative' attribute.
+
+`(set (attr NAME) VALUE)'
+ The first operand of this `set' must be the special RTL expression
+ `attr', whose sole operand is a string giving the name of the
+ attribute being set. VALUE is the value of the attribute.
+
+ The following shows three different ways of representing the same
+attribute value specification:
+
+ (set_attr "type" "load,store,arith")
+
+ (set_attr_alternative "type"
+ [(const_string "load") (const_string "store")
+ (const_string "arith")])
+
+ (set (attr "type")
+ (cond [(eq_attr "alternative" "1") (const_string "load")
+ (eq_attr "alternative" "2") (const_string "store")]
+ (const_string "arith")))
+
+ The `define_asm_attributes' expression provides a mechanism to specify
+the attributes assigned to insns produced from an `asm' statement. It
+has the form:
+
+ (define_asm_attributes [ATTR-SETS])
+
+where ATTR-SETS is specified the same as for both the `define_insn' and
+the `define_peephole' expressions.
+
+ These values will typically be the "worst case" attribute values. For
+example, they might indicate that the condition code will be clobbered.
+
+ A specification for a `length' attribute is handled specially. The
+way to compute the length of an `asm' insn is to multiply the length
+specified in the expression `define_asm_attributes' by the number of
+machine instructions specified in the `asm' statement, determined by
+counting the number of semicolons and newlines in the string.
+Therefore, the value of the `length' attribute specified in a
+`define_asm_attributes' should be the maximum possible length of a
+single machine instruction.
+
+\1f
+File: gccint.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes
+
+16.19.4 Example of Attribute Specifications
+-------------------------------------------
+
+The judicious use of defaulting is important in the efficient use of
+insn attributes. Typically, insns are divided into "types" and an
+attribute, customarily called `type', is used to represent this value.
+This attribute is normally used only to define the default value for
+other attributes. An example will clarify this usage.
+
+ Assume we have a RISC machine with a condition code and in which only
+full-word operations are performed in registers. Let us assume that we
+can divide all insns into loads, stores, (integer) arithmetic
+operations, floating point operations, and branches.
+
+ Here we will concern ourselves with determining the effect of an insn
+on the condition code and will limit ourselves to the following possible
+effects: The condition code can be set unpredictably (clobbered), not
+be changed, be set to agree with the results of the operation, or only
+changed if the item previously set into the condition code has been
+modified.
+
+ Here is part of a sample `md' file for such a machine:
+
+ (define_attr "type" "load,store,arith,fp,branch" (const_string "arith"))
+
+ (define_attr "cc" "clobber,unchanged,set,change0"
+ (cond [(eq_attr "type" "load")
+ (const_string "change0")
+ (eq_attr "type" "store,branch")
+ (const_string "unchanged")
+ (eq_attr "type" "arith")
+ (if_then_else (match_operand:SI 0 "" "")
+ (const_string "set")
+ (const_string "clobber"))]
+ (const_string "clobber")))
+
+ (define_insn ""
+ [(set (match_operand:SI 0 "general_operand" "=r,r,m")
+ (match_operand:SI 1 "general_operand" "r,m,r"))]
+ ""
+ "@
+ move %0,%1
+ load %0,%1
+ store %0,%1"
+ [(set_attr "type" "arith,load,store")])
+
+ Note that we assume in the above example that arithmetic operations
+performed on quantities smaller than a machine word clobber the
+condition code since they will set the condition code to a value
+corresponding to the full-word result.
+
+\1f
+File: gccint.info, Node: Insn Lengths, Next: Constant Attributes, Prev: Attr Example, Up: Insn Attributes
+
+16.19.5 Computing the Length of an Insn
+---------------------------------------
+
+For many machines, multiple types of branch instructions are provided,
+each for different length branch displacements. In most cases, the
+assembler will choose the correct instruction to use. However, when
+the assembler cannot do so, GCC can when a special attribute, the
+`length' attribute, is defined. This attribute must be defined to have
+numeric values by specifying a null string in its `define_attr'.
+
+ In the case of the `length' attribute, two additional forms of
+arithmetic terms are allowed in test expressions:
+
+`(match_dup N)'
+ This refers to the address of operand N of the current insn, which
+ must be a `label_ref'.
+
+`(pc)'
+ This refers to the address of the _current_ insn. It might have
+ been more consistent with other usage to make this the address of
+ the _next_ insn but this would be confusing because the length of
+ the current insn is to be computed.
+
+ For normal insns, the length will be determined by value of the
+`length' attribute. In the case of `addr_vec' and `addr_diff_vec' insn
+patterns, the length is computed as the number of vectors multiplied by
+the size of each vector.
+
+ Lengths are measured in addressable storage units (bytes).
+
+ The following macros can be used to refine the length computation:
+
+`ADJUST_INSN_LENGTH (INSN, LENGTH)'
+ If defined, modifies the length assigned to instruction INSN as a
+ function of the context in which it is used. LENGTH is an lvalue
+ that contains the initially computed length of the insn and should
+ be updated with the correct length of the insn.
+
+ This macro will normally not be required. A case in which it is
+ required is the ROMP. On this machine, the size of an `addr_vec'
+ insn must be increased by two to compensate for the fact that
+ alignment may be required.
+
+ The routine that returns `get_attr_length' (the value of the `length'
+attribute) can be used by the output routine to determine the form of
+the branch instruction to be written, as the example below illustrates.
+
+ As an example of the specification of variable-length branches,
+consider the IBM 360. If we adopt the convention that a register will
+be set to the starting address of a function, we can jump to labels
+within 4k of the start using a four-byte instruction. Otherwise, we
+need a six-byte sequence to load the address from memory and then
+branch to it.
+
+ On such a machine, a pattern for a branch instruction might be
+specified as follows:
+
+ (define_insn "jump"
+ [(set (pc)
+ (label_ref (match_operand 0 "" "")))]
+ ""
+ {
+ return (get_attr_length (insn) == 4
+ ? "b %l0" : "l r15,=a(%l0); br r15");
+ }
+ [(set (attr "length")
+ (if_then_else (lt (match_dup 0) (const_int 4096))
+ (const_int 4)
+ (const_int 6)))])
+
+\1f
+File: gccint.info, Node: Constant Attributes, Next: Delay Slots, Prev: Insn Lengths, Up: Insn Attributes
+
+16.19.6 Constant Attributes
+---------------------------
+
+A special form of `define_attr', where the expression for the default
+value is a `const' expression, indicates an attribute that is constant
+for a given run of the compiler. Constant attributes may be used to
+specify which variety of processor is used. For example,
+
+ (define_attr "cpu" "m88100,m88110,m88000"
+ (const
+ (cond [(symbol_ref "TARGET_88100") (const_string "m88100")
+ (symbol_ref "TARGET_88110") (const_string "m88110")]
+ (const_string "m88000"))))
+
+ (define_attr "memory" "fast,slow"
+ (const
+ (if_then_else (symbol_ref "TARGET_FAST_MEM")
+ (const_string "fast")
+ (const_string "slow"))))
+
+ The routine generated for constant attributes has no parameters as it
+does not depend on any particular insn. RTL expressions used to define
+the value of a constant attribute may use the `symbol_ref' form, but
+may not use either the `match_operand' form or `eq_attr' forms
+involving insn attributes.
+
+\1f
+File: gccint.info, Node: Delay Slots, Next: Processor pipeline description, Prev: Constant Attributes, Up: Insn Attributes
+
+16.19.7 Delay Slot Scheduling
+-----------------------------
+
+The insn attribute mechanism can be used to specify the requirements for
+delay slots, if any, on a target machine. An instruction is said to
+require a "delay slot" if some instructions that are physically after
+the instruction are executed as if they were located before it.
+Classic examples are branch and call instructions, which often execute
+the following instruction before the branch or call is performed.
+
+ On some machines, conditional branch instructions can optionally
+"annul" instructions in the delay slot. This means that the
+instruction will not be executed for certain branch outcomes. Both
+instructions that annul if the branch is true and instructions that
+annul if the branch is false are supported.
+
+ Delay slot scheduling differs from instruction scheduling in that
+determining whether an instruction needs a delay slot is dependent only
+on the type of instruction being generated, not on data flow between the
+instructions. See the next section for a discussion of data-dependent
+instruction scheduling.
+
+ The requirement of an insn needing one or more delay slots is indicated
+via the `define_delay' expression. It has the following form:
+
+ (define_delay TEST
+ [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1
+ DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2
+ ...])
+
+ TEST is an attribute test that indicates whether this `define_delay'
+applies to a particular insn. If so, the number of required delay
+slots is determined by the length of the vector specified as the second
+argument. An insn placed in delay slot N must satisfy attribute test
+DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns
+may be annulled if the branch is true. Similarly, ANNUL-FALSE-N
+specifies which insns in the delay slot may be annulled if the branch
+is false. If annulling is not supported for that delay slot, `(nil)'
+should be coded.
+
+ For example, in the common case where branch and call insns require a
+single delay slot, which may contain any insn other than a branch or
+call, the following would be placed in the `md' file:
+
+ (define_delay (eq_attr "type" "branch,call")
+ [(eq_attr "type" "!branch,call") (nil) (nil)])
+
+ Multiple `define_delay' expressions may be specified. In this case,
+each such expression specifies different delay slot requirements and
+there must be no insn for which tests in two `define_delay' expressions
+are both true.
+
+ For example, if we have a machine that requires one delay slot for
+branches but two for calls, no delay slot can contain a branch or call
+insn, and any valid insn in the delay slot for the branch can be
+annulled if the branch is true, we might represent this as follows:
+
+ (define_delay (eq_attr "type" "branch")
+ [(eq_attr "type" "!branch,call")
+ (eq_attr "type" "!branch,call")
+ (nil)])
+
+ (define_delay (eq_attr "type" "call")
+ [(eq_attr "type" "!branch,call") (nil) (nil)
+ (eq_attr "type" "!branch,call") (nil) (nil)])
+
+\1f
+File: gccint.info, Node: Processor pipeline description, Prev: Delay Slots, Up: Insn Attributes
+
+16.19.8 Specifying processor pipeline description
+-------------------------------------------------
+
+To achieve better performance, most modern processors (super-pipelined,
+superscalar RISC, and VLIW processors) have many "functional units" on
+which several instructions can be executed simultaneously. An
+instruction starts execution if its issue conditions are satisfied. If
+not, the instruction is stalled until its conditions are satisfied.
+Such "interlock (pipeline) delay" causes interruption of the fetching
+of successor instructions (or demands nop instructions, e.g. for some
+MIPS processors).
+
+ There are two major kinds of interlock delays in modern processors.
+The first one is a data dependence delay determining "instruction
+latency time". The instruction execution is not started until all
+source data have been evaluated by prior instructions (there are more
+complex cases when the instruction execution starts even when the data
+are not available but will be ready in given time after the instruction
+execution start). Taking the data dependence delays into account is
+simple. The data dependence (true, output, and anti-dependence) delay
+between two instructions is given by a constant. In most cases this
+approach is adequate. The second kind of interlock delays is a
+reservation delay. The reservation delay means that two instructions
+under execution will be in need of shared processors resources, i.e.
+buses, internal registers, and/or functional units, which are reserved
+for some time. Taking this kind of delay into account is complex
+especially for modern RISC processors.
+
+ The task of exploiting more processor parallelism is solved by an
+instruction scheduler. For a better solution to this problem, the
+instruction scheduler has to have an adequate description of the
+processor parallelism (or "pipeline description"). GCC machine
+descriptions describe processor parallelism and functional unit
+reservations for groups of instructions with the aid of "regular
+expressions".
+
+ The GCC instruction scheduler uses a "pipeline hazard recognizer" to
+figure out the possibility of the instruction issue by the processor on
+a given simulated processor cycle. The pipeline hazard recognizer is
+automatically generated from the processor pipeline description. The
+pipeline hazard recognizer generated from the machine description is
+based on a deterministic finite state automaton (DFA): the instruction
+issue is possible if there is a transition from one automaton state to
+another one. This algorithm is very fast, and furthermore, its speed
+is not dependent on processor complexity(1).
+
+ The rest of this section describes the directives that constitute an
+automaton-based processor pipeline description. The order of these
+constructions within the machine description file is not important.
+
+ The following optional construction describes names of automata
+generated and used for the pipeline hazards recognition. Sometimes the
+generated finite state automaton used by the pipeline hazard recognizer
+is large. If we use more than one automaton and bind functional units
+to the automata, the total size of the automata is usually less than
+the size of the single automaton. If there is no one such
+construction, only one finite state automaton is generated.
+
+ (define_automaton AUTOMATA-NAMES)
+
+ AUTOMATA-NAMES is a string giving names of the automata. The names
+are separated by commas. All the automata should have unique names.
+The automaton name is used in the constructions `define_cpu_unit' and
+`define_query_cpu_unit'.
+
+ Each processor functional unit used in the description of instruction
+reservations should be described by the following construction.
+
+ (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME])
+
+ UNIT-NAMES is a string giving the names of the functional units
+separated by commas. Don't use name `nothing', it is reserved for
+other goals.
+
+ AUTOMATON-NAME is a string giving the name of the automaton with which
+the unit is bound. The automaton should be described in construction
+`define_automaton'. You should give "automaton-name", if there is a
+defined automaton.
+
+ The assignment of units to automata are constrained by the uses of the
+units in insn reservations. The most important constraint is: if a
+unit reservation is present on a particular cycle of an alternative for
+an insn reservation, then some unit from the same automaton must be
+present on the same cycle for the other alternatives of the insn
+reservation. The rest of the constraints are mentioned in the
+description of the subsequent constructions.
+
+ The following construction describes CPU functional units analogously
+to `define_cpu_unit'. The reservation of such units can be queried for
+an automaton state. The instruction scheduler never queries
+reservation of functional units for given automaton state. So as a
+rule, you don't need this construction. This construction could be
+used for future code generation goals (e.g. to generate VLIW insn
+templates).
+
+ (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME])
+
+ UNIT-NAMES is a string giving names of the functional units separated
+by commas.
+
+ AUTOMATON-NAME is a string giving the name of the automaton with which
+the unit is bound.
+
+ The following construction is the major one to describe pipeline
+characteristics of an instruction.
+
+ (define_insn_reservation INSN-NAME DEFAULT_LATENCY
+ CONDITION REGEXP)
+
+ DEFAULT_LATENCY is a number giving latency time of the instruction.
+There is an important difference between the old description and the
+automaton based pipeline description. The latency time is used for all
+dependencies when we use the old description. In the automaton based
+pipeline description, the given latency time is only used for true
+dependencies. The cost of anti-dependencies is always zero and the
+cost of output dependencies is the difference between latency times of
+the producing and consuming insns (if the difference is negative, the
+cost is considered to be zero). You can always change the default
+costs for any description by using the target hook
+`TARGET_SCHED_ADJUST_COST' (*note Scheduling::).
+
+ INSN-NAME is a string giving the internal name of the insn. The
+internal names are used in constructions `define_bypass' and in the
+automaton description file generated for debugging. The internal name
+has nothing in common with the names in `define_insn'. It is a good
+practice to use insn classes described in the processor manual.
+
+ CONDITION defines what RTL insns are described by this construction.
+You should remember that you will be in trouble if CONDITION for two or
+more different `define_insn_reservation' constructions is TRUE for an
+insn. In this case what reservation will be used for the insn is not
+defined. Such cases are not checked during generation of the pipeline
+hazards recognizer because in general recognizing that two conditions
+may have the same value is quite difficult (especially if the conditions
+contain `symbol_ref'). It is also not checked during the pipeline
+hazard recognizer work because it would slow down the recognizer
+considerably.
+
+ REGEXP is a string describing the reservation of the cpu's functional
+units by the instruction. The reservations are described by a regular
+expression according to the following syntax:
+
+ regexp = regexp "," oneof
+ | oneof
+
+ oneof = oneof "|" allof
+ | allof
+
+ allof = allof "+" repeat
+ | repeat
+
+ repeat = element "*" number
+ | element
+
+ element = cpu_function_unit_name
+ | reservation_name
+ | result_name
+ | "nothing"
+ | "(" regexp ")"
+
+ * `,' is used for describing the start of the next cycle in the
+ reservation.
+
+ * `|' is used for describing a reservation described by the first
+ regular expression *or* a reservation described by the second
+ regular expression *or* etc.
+
+ * `+' is used for describing a reservation described by the first
+ regular expression *and* a reservation described by the second
+ regular expression *and* etc.
+
+ * `*' is used for convenience and simply means a sequence in which
+ the regular expression are repeated NUMBER times with cycle
+ advancing (see `,').
+
+ * `cpu_function_unit_name' denotes reservation of the named
+ functional unit.
+
+ * `reservation_name' -- see description of construction
+ `define_reservation'.
+
+ * `nothing' denotes no unit reservations.
+
+ Sometimes unit reservations for different insns contain common parts.
+In such case, you can simplify the pipeline description by describing
+the common part by the following construction
+
+ (define_reservation RESERVATION-NAME REGEXP)
+
+ RESERVATION-NAME is a string giving name of REGEXP. Functional unit
+names and reservation names are in the same name space. So the
+reservation names should be different from the functional unit names
+and can not be the reserved name `nothing'.
+
+ The following construction is used to describe exceptions in the
+latency time for given instruction pair. This is so called bypasses.
+
+ (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES
+ [GUARD])
+
+ NUMBER defines when the result generated by the instructions given in
+string OUT_INSN_NAMES will be ready for the instructions given in
+string IN_INSN_NAMES. The instructions in the string are separated by
+commas.
+
+ GUARD is an optional string giving the name of a C function which
+defines an additional guard for the bypass. The function will get the
+two insns as parameters. If the function returns zero the bypass will
+be ignored for this case. The additional guard is necessary to
+recognize complicated bypasses, e.g. when the consumer is only an
+address of insn `store' (not a stored value).
+
+ The following five constructions are usually used to describe VLIW
+processors, or more precisely, to describe a placement of small
+instructions into VLIW instruction slots. They can be used for RISC
+processors, too.
+
+ (exclusion_set UNIT-NAMES UNIT-NAMES)
+ (presence_set UNIT-NAMES PATTERNS)
+ (final_presence_set UNIT-NAMES PATTERNS)
+ (absence_set UNIT-NAMES PATTERNS)
+ (final_absence_set UNIT-NAMES PATTERNS)
+
+ UNIT-NAMES is a string giving names of functional units separated by
+commas.
+
+ PATTERNS is a string giving patterns of functional units separated by
+comma. Currently pattern is one unit or units separated by
+white-spaces.
+
+ The first construction (`exclusion_set') means that each functional
+unit in the first string can not be reserved simultaneously with a unit
+whose name is in the second string and vice versa. For example, the
+construction is useful for describing processors (e.g. some SPARC
+processors) with a fully pipelined floating point functional unit which
+can execute simultaneously only single floating point insns or only
+double floating point insns.
+
+ The second construction (`presence_set') means that each functional
+unit in the first string can not be reserved unless at least one of
+pattern of units whose names are in the second string is reserved.
+This is an asymmetric relation. For example, it is useful for
+description that VLIW `slot1' is reserved after `slot0' reservation.
+We could describe it by the following construction
+
+ (presence_set "slot1" "slot0")
+
+ Or `slot1' is reserved only after `slot0' and unit `b0' reservation.
+In this case we could write
+
+ (presence_set "slot1" "slot0 b0")
+
+ The third construction (`final_presence_set') is analogous to
+`presence_set'. The difference between them is when checking is done.
+When an instruction is issued in given automaton state reflecting all
+current and planned unit reservations, the automaton state is changed.
+The first state is a source state, the second one is a result state.
+Checking for `presence_set' is done on the source state reservation,
+checking for `final_presence_set' is done on the result reservation.
+This construction is useful to describe a reservation which is actually
+two subsequent reservations. For example, if we use
+
+ (presence_set "slot1" "slot0")
+
+ the following insn will be never issued (because `slot1' requires
+`slot0' which is absent in the source state).
+
+ (define_reservation "insn_and_nop" "slot0 + slot1")
+
+ but it can be issued if we use analogous `final_presence_set'.
+
+ The forth construction (`absence_set') means that each functional unit
+in the first string can be reserved only if each pattern of units whose
+names are in the second string is not reserved. This is an asymmetric
+relation (actually `exclusion_set' is analogous to this one but it is
+symmetric). For example it might be useful in a VLIW description to
+say that `slot0' cannot be reserved after either `slot1' or `slot2'
+have been reserved. This can be described as:
+
+ (absence_set "slot0" "slot1, slot2")
+
+ Or `slot2' can not be reserved if `slot0' and unit `b0' are reserved
+or `slot1' and unit `b1' are reserved. In this case we could write
+
+ (absence_set "slot2" "slot0 b0, slot1 b1")
+
+ All functional units mentioned in a set should belong to the same
+automaton.
+
+ The last construction (`final_absence_set') is analogous to
+`absence_set' but checking is done on the result (state) reservation.
+See comments for `final_presence_set'.
+
+ You can control the generator of the pipeline hazard recognizer with
+the following construction.
+
+ (automata_option OPTIONS)
+
+ OPTIONS is a string giving options which affect the generated code.
+Currently there are the following options:
+
+ * "no-minimization" makes no minimization of the automaton. This is
+ only worth to do when we are debugging the description and need to
+ look more accurately at reservations of states.
+
+ * "time" means printing time statistics about the generation of
+ automata.
+
+ * "stats" means printing statistics about the generated automata
+ such as the number of DFA states, NDFA states and arcs.
+
+ * "v" means a generation of the file describing the result automata.
+ The file has suffix `.dfa' and can be used for the description
+ verification and debugging.
+
+ * "w" means a generation of warning instead of error for
+ non-critical errors.
+
+ * "ndfa" makes nondeterministic finite state automata. This affects
+ the treatment of operator `|' in the regular expressions. The
+ usual treatment of the operator is to try the first alternative
+ and, if the reservation is not possible, the second alternative.
+ The nondeterministic treatment means trying all alternatives, some
+ of them may be rejected by reservations in the subsequent insns.
+
+ * "progress" means output of a progress bar showing how many states
+ were generated so far for automaton being processed. This is
+ useful during debugging a DFA description. If you see too many
+ generated states, you could interrupt the generator of the pipeline
+ hazard recognizer and try to figure out a reason for generation of
+ the huge automaton.
+
+ As an example, consider a superscalar RISC machine which can issue
+three insns (two integer insns and one floating point insn) on the
+cycle but can finish only two insns. To describe this, we define the
+following functional units.
+
+ (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline")
+ (define_cpu_unit "port0, port1")
+
+ All simple integer insns can be executed in any integer pipeline and
+their result is ready in two cycles. The simple integer insns are
+issued into the first pipeline unless it is reserved, otherwise they
+are issued into the second pipeline. Integer division and
+multiplication insns can be executed only in the second integer
+pipeline and their results are ready correspondingly in 8 and 4 cycles.
+The integer division is not pipelined, i.e. the subsequent integer
+division insn can not be issued until the current division insn
+finished. Floating point insns are fully pipelined and their results
+are ready in 3 cycles. Where the result of a floating point insn is
+used by an integer insn, an additional delay of one cycle is incurred.
+To describe all of this we could specify
+
+ (define_cpu_unit "div")
+
+ (define_insn_reservation "simple" 2 (eq_attr "type" "int")
+ "(i0_pipeline | i1_pipeline), (port0 | port1)")
+
+ (define_insn_reservation "mult" 4 (eq_attr "type" "mult")
+ "i1_pipeline, nothing*2, (port0 | port1)")
+
+ (define_insn_reservation "div" 8 (eq_attr "type" "div")
+ "i1_pipeline, div*7, div + (port0 | port1)")
+
+ (define_insn_reservation "float" 3 (eq_attr "type" "float")
+ "f_pipeline, nothing, (port0 | port1))
+
+ (define_bypass 4 "float" "simple,mult,div")
+
+ To simplify the description we could describe the following reservation
+
+ (define_reservation "finish" "port0|port1")
+
+ and use it in all `define_insn_reservation' as in the following
+construction
+
+ (define_insn_reservation "simple" 2 (eq_attr "type" "int")
+ "(i0_pipeline | i1_pipeline), finish")
+
+ ---------- Footnotes ----------
+
+ (1) However, the size of the automaton depends on processor
+complexity. To limit this effect, machine descriptions can split
+orthogonal parts of the machine description among several automata: but
+then, since each of these must be stepped independently, this does
+cause a small decrease in the algorithm's performance.
+
+\1f
+File: gccint.info, Node: Conditional Execution, Next: Constant Definitions, Prev: Insn Attributes, Up: Machine Desc
+
+16.20 Conditional Execution
+===========================
+
+A number of architectures provide for some form of conditional
+execution, or predication. The hallmark of this feature is the ability
+to nullify most of the instructions in the instruction set. When the
+instruction set is large and not entirely symmetric, it can be quite
+tedious to describe these forms directly in the `.md' file. An
+alternative is the `define_cond_exec' template.
+
+ (define_cond_exec
+ [PREDICATE-PATTERN]
+ "CONDITION"
+ "OUTPUT-TEMPLATE")
+
+ PREDICATE-PATTERN is the condition that must be true for the insn to
+be executed at runtime and should match a relational operator. One can
+use `match_operator' to match several relational operators at once.
+Any `match_operand' operands must have no more than one alternative.
+
+ CONDITION is a C expression that must be true for the generated
+pattern to match.
+
+ OUTPUT-TEMPLATE is a string similar to the `define_insn' output
+template (*note Output Template::), except that the `*' and `@' special
+cases do not apply. This is only useful if the assembly text for the
+predicate is a simple prefix to the main insn. In order to handle the
+general case, there is a global variable `current_insn_predicate' that
+will contain the entire predicate if the current insn is predicated,
+and will otherwise be `NULL'.
+
+ When `define_cond_exec' is used, an implicit reference to the
+`predicable' instruction attribute is made. *Note Insn Attributes::.
+This attribute must be boolean (i.e. have exactly two elements in its
+LIST-OF-VALUES). Further, it must not be used with complex
+expressions. That is, the default and all uses in the insns must be a
+simple constant, not dependent on the alternative or anything else.
+
+ For each `define_insn' for which the `predicable' attribute is true, a
+new `define_insn' pattern will be generated that matches a predicated
+version of the instruction. For example,
+
+ (define_insn "addsi"
+ [(set (match_operand:SI 0 "register_operand" "r")
+ (plus:SI (match_operand:SI 1 "register_operand" "r")
+ (match_operand:SI 2 "register_operand" "r")))]
+ "TEST1"
+ "add %2,%1,%0")
+
+ (define_cond_exec
+ [(ne (match_operand:CC 0 "register_operand" "c")
+ (const_int 0))]
+ "TEST2"
+ "(%0)")
+
+generates a new pattern
+
+ (define_insn ""
+ [(cond_exec
+ (ne (match_operand:CC 3 "register_operand" "c") (const_int 0))
+ (set (match_operand:SI 0 "register_operand" "r")
+ (plus:SI (match_operand:SI 1 "register_operand" "r")
+ (match_operand:SI 2 "register_operand" "r"))))]
+ "(TEST2) && (TEST1)"
+ "(%3) add %2,%1,%0")
+
+\1f
+File: gccint.info, Node: Constant Definitions, Next: Iterators, Prev: Conditional Execution, Up: Machine Desc
+
+16.21 Constant Definitions
+==========================
+
+Using literal constants inside instruction patterns reduces legibility
+and can be a maintenance problem.
+
+ To overcome this problem, you may use the `define_constants'
+expression. It contains a vector of name-value pairs. From that point
+on, wherever any of the names appears in the MD file, it is as if the
+corresponding value had been written instead. You may use
+`define_constants' multiple times; each appearance adds more constants
+to the table. It is an error to redefine a constant with a different
+value.
+
+ To come back to the a29k load multiple example, instead of
+
+ (define_insn ""
+ [(match_parallel 0 "load_multiple_operation"
+ [(set (match_operand:SI 1 "gpc_reg_operand" "=r")
+ (match_operand:SI 2 "memory_operand" "m"))
+ (use (reg:SI 179))
+ (clobber (reg:SI 179))])]
+ ""
+ "loadm 0,0,%1,%2")
+
+ You could write:
+
+ (define_constants [
+ (R_BP 177)
+ (R_FC 178)
+ (R_CR 179)
+ (R_Q 180)
+ ])
+
+ (define_insn ""
+ [(match_parallel 0 "load_multiple_operation"
+ [(set (match_operand:SI 1 "gpc_reg_operand" "=r")
+ (match_operand:SI 2 "memory_operand" "m"))
+ (use (reg:SI R_CR))
+ (clobber (reg:SI R_CR))])]
+ ""
+ "loadm 0,0,%1,%2")
+
+ The constants that are defined with a define_constant are also output
+in the insn-codes.h header file as #defines.
+
+\1f
+File: gccint.info, Node: Iterators, Prev: Constant Definitions, Up: Machine Desc
+
+16.22 Iterators
+===============
+
+Ports often need to define similar patterns for more than one machine
+mode or for more than one rtx code. GCC provides some simple iterator
+facilities to make this process easier.
+
+* Menu:
+
+* Mode Iterators:: Generating variations of patterns for different modes.
+* Code Iterators:: Doing the same for codes.
+
+\1f
+File: gccint.info, Node: Mode Iterators, Next: Code Iterators, Up: Iterators
+
+16.22.1 Mode Iterators
+----------------------
+
+Ports often need to define similar patterns for two or more different
+modes. For example:
+
+ * If a processor has hardware support for both single and double
+ floating-point arithmetic, the `SFmode' patterns tend to be very
+ similar to the `DFmode' ones.
+
+ * If a port uses `SImode' pointers in one configuration and `DImode'
+ pointers in another, it will usually have very similar `SImode'
+ and `DImode' patterns for manipulating pointers.
+
+ Mode iterators allow several patterns to be instantiated from one
+`.md' file template. They can be used with any type of rtx-based
+construct, such as a `define_insn', `define_split', or
+`define_peephole2'.
+
+* Menu:
+
+* Defining Mode Iterators:: Defining a new mode iterator.
+* Substitutions:: Combining mode iterators with substitutions
+* Examples:: Examples
+
+\1f
+File: gccint.info, Node: Defining Mode Iterators, Next: Substitutions, Up: Mode Iterators
+
+16.22.1.1 Defining Mode Iterators
+.................................
+
+The syntax for defining a mode iterator is:
+
+ (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")])
+
+ This allows subsequent `.md' file constructs to use the mode suffix
+`:NAME'. Every construct that does so will be expanded N times, once
+with every use of `:NAME' replaced by `:MODE1', once with every use
+replaced by `:MODE2', and so on. In the expansion for a particular
+MODEI, every C condition will also require that CONDI be true.
+
+ For example:
+
+ (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
+
+ defines a new mode suffix `:P'. Every construct that uses `:P' will
+be expanded twice, once with every `:P' replaced by `:SI' and once with
+every `:P' replaced by `:DI'. The `:SI' version will only apply if
+`Pmode == SImode' and the `:DI' version will only apply if `Pmode ==
+DImode'.
+
+ As with other `.md' conditions, an empty string is treated as "always
+true". `(MODE "")' can also be abbreviated to `MODE'. For example:
+
+ (define_mode_iterator GPR [SI (DI "TARGET_64BIT")])
+
+ means that the `:DI' expansion only applies if `TARGET_64BIT' but that
+the `:SI' expansion has no such constraint.
+
+ Iterators are applied in the order they are defined. This can be
+significant if two iterators are used in a construct that requires
+substitutions. *Note Substitutions::.
+
+\1f
+File: gccint.info, Node: Substitutions, Next: Examples, Prev: Defining Mode Iterators, Up: Mode Iterators
+
+16.22.1.2 Substitution in Mode Iterators
+........................................
+
+If an `.md' file construct uses mode iterators, each version of the
+construct will often need slightly different strings or modes. For
+example:
+
+ * When a `define_expand' defines several `addM3' patterns (*note
+ Standard Names::), each expander will need to use the appropriate
+ mode name for M.
+
+ * When a `define_insn' defines several instruction patterns, each
+ instruction will often use a different assembler mnemonic.
+
+ * When a `define_insn' requires operands with different modes, using
+ an iterator for one of the operand modes usually requires a
+ specific mode for the other operand(s).
+
+ GCC supports such variations through a system of "mode attributes".
+There are two standard attributes: `mode', which is the name of the
+mode in lower case, and `MODE', which is the same thing in upper case.
+You can define other attributes using:
+
+ (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")])
+
+ where NAME is the name of the attribute and VALUEI is the value
+associated with MODEI.
+
+ When GCC replaces some :ITERATOR with :MODE, it will scan each string
+and mode in the pattern for sequences of the form `<ITERATOR:ATTR>',
+where ATTR is the name of a mode attribute. If the attribute is
+defined for MODE, the whole `<...>' sequence will be replaced by the
+appropriate attribute value.
+
+ For example, suppose an `.md' file has:
+
+ (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
+ (define_mode_attr load [(SI "lw") (DI "ld")])
+
+ If one of the patterns that uses `:P' contains the string
+`"<P:load>\t%0,%1"', the `SI' version of that pattern will use
+`"lw\t%0,%1"' and the `DI' version will use `"ld\t%0,%1"'.
+
+ Here is an example of using an attribute for a mode:
+
+ (define_mode_iterator LONG [SI DI])
+ (define_mode_attr SHORT [(SI "HI") (DI "SI")])
+ (define_insn ...
+ (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...)
+
+ The `ITERATOR:' prefix may be omitted, in which case the substitution
+will be attempted for every iterator expansion.
+
+\1f
+File: gccint.info, Node: Examples, Prev: Substitutions, Up: Mode Iterators
+
+16.22.1.3 Mode Iterator Examples
+................................
+
+Here is an example from the MIPS port. It defines the following modes
+and attributes (among others):
+
+ (define_mode_iterator GPR [SI (DI "TARGET_64BIT")])
+ (define_mode_attr d [(SI "") (DI "d")])
+
+ and uses the following template to define both `subsi3' and `subdi3':
+
+ (define_insn "sub<mode>3"
+ [(set (match_operand:GPR 0 "register_operand" "=d")
+ (minus:GPR (match_operand:GPR 1 "register_operand" "d")
+ (match_operand:GPR 2 "register_operand" "d")))]
+ ""
+ "<d>subu\t%0,%1,%2"
+ [(set_attr "type" "arith")
+ (set_attr "mode" "<MODE>")])
+
+ This is exactly equivalent to:
+
+ (define_insn "subsi3"
+ [(set (match_operand:SI 0 "register_operand" "=d")
+ (minus:SI (match_operand:SI 1 "register_operand" "d")
+ (match_operand:SI 2 "register_operand" "d")))]
+ ""
+ "subu\t%0,%1,%2"
+ [(set_attr "type" "arith")
+ (set_attr "mode" "SI")])
+
+ (define_insn "subdi3"
+ [(set (match_operand:DI 0 "register_operand" "=d")
+ (minus:DI (match_operand:DI 1 "register_operand" "d")
+ (match_operand:DI 2 "register_operand" "d")))]
+ ""
+ "dsubu\t%0,%1,%2"
+ [(set_attr "type" "arith")
+ (set_attr "mode" "DI")])
+
+\1f
+File: gccint.info, Node: Code Iterators, Prev: Mode Iterators, Up: Iterators
+
+16.22.2 Code Iterators
+----------------------
+
+Code iterators operate in a similar way to mode iterators. *Note Mode
+Iterators::.
+
+ The construct:
+
+ (define_code_iterator NAME [(CODE1 "COND1") ... (CODEN "CONDN")])
+
+ defines a pseudo rtx code NAME that can be instantiated as CODEI if
+condition CONDI is true. Each CODEI must have the same rtx format.
+*Note RTL Classes::.
+
+ As with mode iterators, each pattern that uses NAME will be expanded N
+times, once with all uses of NAME replaced by CODE1, once with all uses
+replaced by CODE2, and so on. *Note Defining Mode Iterators::.
+
+ It is possible to define attributes for codes as well as for modes.
+There are two standard code attributes: `code', the name of the code in
+lower case, and `CODE', the name of the code in upper case. Other
+attributes are defined using:
+
+ (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")])
+
+ Here's an example of code iterators in action, taken from the MIPS
+port:
+
+ (define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt
+ eq ne gt ge lt le gtu geu ltu leu])
+
+ (define_expand "b<code>"
+ [(set (pc)
+ (if_then_else (any_cond:CC (cc0)
+ (const_int 0))
+ (label_ref (match_operand 0 ""))
+ (pc)))]
+ ""
+ {
+ gen_conditional_branch (operands, <CODE>);
+ DONE;
+ })
+
+ This is equivalent to:
+
+ (define_expand "bunordered"
+ [(set (pc)
+ (if_then_else (unordered:CC (cc0)
+ (const_int 0))
+ (label_ref (match_operand 0 ""))
+ (pc)))]
+ ""
+ {
+ gen_conditional_branch (operands, UNORDERED);
+ DONE;
+ })
+
+ (define_expand "bordered"
+ [(set (pc)
+ (if_then_else (ordered:CC (cc0)
+ (const_int 0))
+ (label_ref (match_operand 0 ""))
+ (pc)))]
+ ""
+ {
+ gen_conditional_branch (operands, ORDERED);
+ DONE;
+ })
+
+ ...
+
+\1f
+File: gccint.info, Node: Target Macros, Next: Host Config, Prev: Machine Desc, Up: Top
+
+17 Target Description Macros and Functions
+******************************************
+
+In addition to the file `MACHINE.md', a machine description includes a
+C header file conventionally given the name `MACHINE.h' and a C source
+file named `MACHINE.c'. The header file defines numerous macros that
+convey the information about the target machine that does not fit into
+the scheme of the `.md' file. The file `tm.h' should be a link to
+`MACHINE.h'. The header file `config.h' includes `tm.h' and most
+compiler source files include `config.h'. The source file defines a
+variable `targetm', which is a structure containing pointers to
+functions and data relating to the target machine. `MACHINE.c' should
+also contain their definitions, if they are not defined elsewhere in
+GCC, and other functions called through the macros defined in the `.h'
+file.
+
+* Menu:
+
+* Target Structure:: The `targetm' variable.
+* Driver:: Controlling how the driver runs the compilation passes.
+* Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'.
+* Per-Function Data:: Defining data structures for per-function information.
+* Storage Layout:: Defining sizes and alignments of data.
+* Type Layout:: Defining sizes and properties of basic user data types.
+* Registers:: Naming and describing the hardware registers.
+* Register Classes:: Defining the classes of hardware registers.
+* Old Constraints:: The old way to define machine-specific constraints.
+* Stack and Calling:: Defining which way the stack grows and by how much.
+* Varargs:: Defining the varargs macros.
+* Trampolines:: Code set up at run time to enter a nested function.
+* Library Calls:: Controlling how library routines are implicitly called.
+* Addressing Modes:: Defining addressing modes valid for memory operands.
+* Anchored Addresses:: Defining how `-fsection-anchors' should work.
+* Condition Code:: Defining how insns update the condition code.
+* Costs:: Defining relative costs of different operations.
+* Scheduling:: Adjusting the behavior of the instruction scheduler.
+* Sections:: Dividing storage into text, data, and other sections.
+* PIC:: Macros for position independent code.
+* Assembler Format:: Defining how to write insns and pseudo-ops to output.
+* Debugging Info:: Defining the format of debugging output.
+* Floating Point:: Handling floating point for cross-compilers.
+* Mode Switching:: Insertion of mode-switching instructions.
+* Target Attributes:: Defining target-specific uses of `__attribute__'.
+* Emulated TLS:: Emulated TLS support.
+* MIPS Coprocessors:: MIPS coprocessor support and how to customize it.
+* PCH Target:: Validity checking for precompiled headers.
+* C++ ABI:: Controlling C++ ABI changes.
+* Misc:: Everything else.
+
+\1f
+File: gccint.info, Node: Target Structure, Next: Driver, Up: Target Macros
+
+17.1 The Global `targetm' Variable
+==================================
+
+ -- Variable: struct gcc_target targetm
+ The target `.c' file must define the global `targetm' variable
+ which contains pointers to functions and data relating to the
+ target machine. The variable is declared in `target.h';
+ `target-def.h' defines the macro `TARGET_INITIALIZER' which is
+ used to initialize the variable, and macros for the default
+ initializers for elements of the structure. The `.c' file should
+ override those macros for which the default definition is
+ inappropriate. For example:
+ #include "target.h"
+ #include "target-def.h"
+
+ /* Initialize the GCC target structure. */
+
+ #undef TARGET_COMP_TYPE_ATTRIBUTES
+ #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes
+
+ struct gcc_target targetm = TARGET_INITIALIZER;
+
+Where a macro should be defined in the `.c' file in this manner to form
+part of the `targetm' structure, it is documented below as a "Target
+Hook" with a prototype. Many macros will change in future from being
+defined in the `.h' file to being part of the `targetm' structure.
+
+\1f
+File: gccint.info, Node: Driver, Next: Run-time Target, Prev: Target Structure, Up: Target Macros
+
+17.2 Controlling the Compilation Driver, `gcc'
+==============================================
+
+You can control the compilation driver.
+
+ -- Macro: SWITCH_TAKES_ARG (CHAR)
+ A C expression which determines whether the option `-CHAR' takes
+ arguments. The value should be the number of arguments that
+ option takes-zero, for many options.
+
+ By default, this macro is defined as `DEFAULT_SWITCH_TAKES_ARG',
+ which handles the standard options properly. You need not define
+ `SWITCH_TAKES_ARG' unless you wish to add additional options which
+ take arguments. Any redefinition should call
+ `DEFAULT_SWITCH_TAKES_ARG' and then check for additional options.
+
+ -- Macro: WORD_SWITCH_TAKES_ARG (NAME)
+ A C expression which determines whether the option `-NAME' takes
+ arguments. The value should be the number of arguments that
+ option takes-zero, for many options. This macro rather than
+ `SWITCH_TAKES_ARG' is used for multi-character option names.
+
+ By default, this macro is defined as
+ `DEFAULT_WORD_SWITCH_TAKES_ARG', which handles the standard options
+ properly. You need not define `WORD_SWITCH_TAKES_ARG' unless you
+ wish to add additional options which take arguments. Any
+ redefinition should call `DEFAULT_WORD_SWITCH_TAKES_ARG' and then
+ check for additional options.
+
+ -- Macro: SWITCH_CURTAILS_COMPILATION (CHAR)
+ A C expression which determines whether the option `-CHAR' stops
+ compilation before the generation of an executable. The value is
+ boolean, nonzero if the option does stop an executable from being
+ generated, zero otherwise.
+
+ By default, this macro is defined as
+ `DEFAULT_SWITCH_CURTAILS_COMPILATION', which handles the standard
+ options properly. You need not define
+ `SWITCH_CURTAILS_COMPILATION' unless you wish to add additional
+ options which affect the generation of an executable. Any
+ redefinition should call `DEFAULT_SWITCH_CURTAILS_COMPILATION' and
+ then check for additional options.
+
+ -- Macro: SWITCHES_NEED_SPACES
+ A string-valued C expression which enumerates the options for which
+ the linker needs a space between the option and its argument.
+
+ If this macro is not defined, the default value is `""'.
+
+ -- Macro: TARGET_OPTION_TRANSLATE_TABLE
+ If defined, a list of pairs of strings, the first of which is a
+ potential command line target to the `gcc' driver program, and the
+ second of which is a space-separated (tabs and other whitespace
+ are not supported) list of options with which to replace the first
+ option. The target defining this list is responsible for assuring
+ that the results are valid. Replacement options may not be the
+ `--opt' style, they must be the `-opt' style. It is the intention
+ of this macro to provide a mechanism for substitution that affects
+ the multilibs chosen, such as one option that enables many
+ options, some of which select multilibs. Example nonsensical
+ definition, where `-malt-abi', `-EB', and `-mspoo' cause different
+ multilibs to be chosen:
+
+ #define TARGET_OPTION_TRANSLATE_TABLE \
+ { "-fast", "-march=fast-foo -malt-abi -I/usr/fast-foo" }, \
+ { "-compat", "-EB -malign=4 -mspoo" }
+
+ -- Macro: DRIVER_SELF_SPECS
+ A list of specs for the driver itself. It should be a suitable
+ initializer for an array of strings, with no surrounding braces.
+
+ The driver applies these specs to its own command line between
+ loading default `specs' files (but not command-line specified
+ ones) and choosing the multilib directory or running any
+ subcommands. It applies them in the order given, so each spec can
+ depend on the options added by earlier ones. It is also possible
+ to remove options using `%<OPTION' in the usual way.
+
+ This macro can be useful when a port has several interdependent
+ target options. It provides a way of standardizing the command
+ line so that the other specs are easier to write.
+
+ Do not define this macro if it does not need to do anything.
+
+ -- Macro: OPTION_DEFAULT_SPECS
+ A list of specs used to support configure-time default options
+ (i.e. `--with' options) in the driver. It should be a suitable
+ initializer for an array of structures, each containing two
+ strings, without the outermost pair of surrounding braces.
+
+ The first item in the pair is the name of the default. This must
+ match the code in `config.gcc' for the target. The second item is
+ a spec to apply if a default with this name was specified. The
+ string `%(VALUE)' in the spec will be replaced by the value of the
+ default everywhere it occurs.
+
+ The driver will apply these specs to its own command line between
+ loading default `specs' files and processing `DRIVER_SELF_SPECS',
+ using the same mechanism as `DRIVER_SELF_SPECS'.
+
+ Do not define this macro if it does not need to do anything.
+
+ -- Macro: CPP_SPEC
+ A C string constant that tells the GCC driver program options to
+ pass to CPP. It can also specify how to translate options you
+ give to GCC into options for GCC to pass to the CPP.
+
+ Do not define this macro if it does not need to do anything.
+
+ -- Macro: CPLUSPLUS_CPP_SPEC
+ This macro is just like `CPP_SPEC', but is used for C++, rather
+ than C. If you do not define this macro, then the value of
+ `CPP_SPEC' (if any) will be used instead.
+
+ -- Macro: CC1_SPEC
+ A C string constant that tells the GCC driver program options to
+ pass to `cc1', `cc1plus', `f771', and the other language front
+ ends. It can also specify how to translate options you give to
+ GCC into options for GCC to pass to front ends.
+
+ Do not define this macro if it does not need to do anything.
+
+ -- Macro: CC1PLUS_SPEC
+ A C string constant that tells the GCC driver program options to
+ pass to `cc1plus'. It can also specify how to translate options
+ you give to GCC into options for GCC to pass to the `cc1plus'.
+
+ Do not define this macro if it does not need to do anything. Note
+ that everything defined in CC1_SPEC is already passed to `cc1plus'
+ so there is no need to duplicate the contents of CC1_SPEC in
+ CC1PLUS_SPEC.
+
+ -- Macro: ASM_SPEC
+ A C string constant that tells the GCC driver program options to
+ pass to the assembler. It can also specify how to translate
+ options you give to GCC into options for GCC to pass to the
+ assembler. See the file `sun3.h' for an example of this.
+
+ Do not define this macro if it does not need to do anything.
+
+ -- Macro: ASM_FINAL_SPEC
+ A C string constant that tells the GCC driver program how to run
+ any programs which cleanup after the normal assembler. Normally,
+ this is not needed. See the file `mips.h' for an example of this.
+
+ Do not define this macro if it does not need to do anything.
+
+ -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT
+ Define this macro, with no value, if the driver should give the
+ assembler an argument consisting of a single dash, `-', to
+ instruct it to read from its standard input (which will be a pipe
+ connected to the output of the compiler proper). This argument is
+ given after any `-o' option specifying the name of the output file.
+
+ If you do not define this macro, the assembler is assumed to read
+ its standard input if given no non-option arguments. If your
+ assembler cannot read standard input at all, use a `%{pipe:%e}'
+ construct; see `mips.h' for instance.
+
+ -- Macro: LINK_SPEC
+ A C string constant that tells the GCC driver program options to
+ pass to the linker. It can also specify how to translate options
+ you give to GCC into options for GCC to pass to the linker.
+
+ Do not define this macro if it does not need to do anything.
+
+ -- Macro: LIB_SPEC
+ Another C string constant used much like `LINK_SPEC'. The
+ difference between the two is that `LIB_SPEC' is used at the end
+ of the command given to the linker.
+
+ If this macro is not defined, a default is provided that loads the
+ standard C library from the usual place. See `gcc.c'.
+
+ -- Macro: LIBGCC_SPEC
+ Another C string constant that tells the GCC driver program how
+ and when to place a reference to `libgcc.a' into the linker
+ command line. This constant is placed both before and after the
+ value of `LIB_SPEC'.
+
+ If this macro is not defined, the GCC driver provides a default
+ that passes the string `-lgcc' to the linker.
+
+ -- Macro: REAL_LIBGCC_SPEC
+ By default, if `ENABLE_SHARED_LIBGCC' is defined, the
+ `LIBGCC_SPEC' is not directly used by the driver program but is
+ instead modified to refer to different versions of `libgcc.a'
+ depending on the values of the command line flags `-static',
+ `-shared', `-static-libgcc', and `-shared-libgcc'. On targets
+ where these modifications are inappropriate, define
+ `REAL_LIBGCC_SPEC' instead. `REAL_LIBGCC_SPEC' tells the driver
+ how to place a reference to `libgcc' on the link command line,
+ but, unlike `LIBGCC_SPEC', it is used unmodified.
+
+ -- Macro: USE_LD_AS_NEEDED
+ A macro that controls the modifications to `LIBGCC_SPEC' mentioned
+ in `REAL_LIBGCC_SPEC'. If nonzero, a spec will be generated that
+ uses -as-needed and the shared libgcc in place of the static
+ exception handler library, when linking without any of `-static',
+ `-static-libgcc', or `-shared-libgcc'.
+
+ -- Macro: LINK_EH_SPEC
+ If defined, this C string constant is added to `LINK_SPEC'. When
+ `USE_LD_AS_NEEDED' is zero or undefined, it also affects the
+ modifications to `LIBGCC_SPEC' mentioned in `REAL_LIBGCC_SPEC'.
+
+ -- Macro: STARTFILE_SPEC
+ Another C string constant used much like `LINK_SPEC'. The
+ difference between the two is that `STARTFILE_SPEC' is used at the
+ very beginning of the command given to the linker.
+
+ If this macro is not defined, a default is provided that loads the
+ standard C startup file from the usual place. See `gcc.c'.
+
+ -- Macro: ENDFILE_SPEC
+ Another C string constant used much like `LINK_SPEC'. The
+ difference between the two is that `ENDFILE_SPEC' is used at the
+ very end of the command given to the linker.
+
+ Do not define this macro if it does not need to do anything.
+
+ -- Macro: THREAD_MODEL_SPEC
+ GCC `-v' will print the thread model GCC was configured to use.
+ However, this doesn't work on platforms that are multilibbed on
+ thread models, such as AIX 4.3. On such platforms, define
+ `THREAD_MODEL_SPEC' such that it evaluates to a string without
+ blanks that names one of the recognized thread models. `%*', the
+ default value of this macro, will expand to the value of
+ `thread_file' set in `config.gcc'.
+
+ -- Macro: SYSROOT_SUFFIX_SPEC
+ Define this macro to add a suffix to the target sysroot when GCC is
+ configured with a sysroot. This will cause GCC to search for
+ usr/lib, et al, within sysroot+suffix.
+
+ -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC
+ Define this macro to add a headers_suffix to the target sysroot
+ when GCC is configured with a sysroot. This will cause GCC to
+ pass the updated sysroot+headers_suffix to CPP, causing it to
+ search for usr/include, et al, within sysroot+headers_suffix.
+
+ -- Macro: EXTRA_SPECS
+ Define this macro to provide additional specifications to put in
+ the `specs' file that can be used in various specifications like
+ `CC1_SPEC'.
+
+ The definition should be an initializer for an array of structures,
+ containing a string constant, that defines the specification name,
+ and a string constant that provides the specification.
+
+ Do not define this macro if it does not need to do anything.
+
+ `EXTRA_SPECS' is useful when an architecture contains several
+ related targets, which have various `..._SPECS' which are similar
+ to each other, and the maintainer would like one central place to
+ keep these definitions.
+
+ For example, the PowerPC System V.4 targets use `EXTRA_SPECS' to
+ define either `_CALL_SYSV' when the System V calling sequence is
+ used or `_CALL_AIX' when the older AIX-based calling sequence is
+ used.
+
+ The `config/rs6000/rs6000.h' target file defines:
+
+ #define EXTRA_SPECS \
+ { "cpp_sysv_default", CPP_SYSV_DEFAULT },
+
+ #define CPP_SYS_DEFAULT ""
+
+ The `config/rs6000/sysv.h' target file defines:
+ #undef CPP_SPEC
+ #define CPP_SPEC \
+ "%{posix: -D_POSIX_SOURCE } \
+ %{mcall-sysv: -D_CALL_SYSV } \
+ %{!mcall-sysv: %(cpp_sysv_default) } \
+ %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}"
+
+ #undef CPP_SYSV_DEFAULT
+ #define CPP_SYSV_DEFAULT "-D_CALL_SYSV"
+
+ while the `config/rs6000/eabiaix.h' target file defines
+ `CPP_SYSV_DEFAULT' as:
+
+ #undef CPP_SYSV_DEFAULT
+ #define CPP_SYSV_DEFAULT "-D_CALL_AIX"
+
+ -- Macro: LINK_LIBGCC_SPECIAL_1
+ Define this macro if the driver program should find the library
+ `libgcc.a'. If you do not define this macro, the driver program
+ will pass the argument `-lgcc' to tell the linker to do the search.
+
+ -- Macro: LINK_GCC_C_SEQUENCE_SPEC
+ The sequence in which libgcc and libc are specified to the linker.
+ By default this is `%G %L %G'.
+
+ -- Macro: LINK_COMMAND_SPEC
+ A C string constant giving the complete command line need to
+ execute the linker. When you do this, you will need to update
+ your port each time a change is made to the link command line
+ within `gcc.c'. Therefore, define this macro only if you need to
+ completely redefine the command line for invoking the linker and
+ there is no other way to accomplish the effect you need.
+ Overriding this macro may be avoidable by overriding
+ `LINK_GCC_C_SEQUENCE_SPEC' instead.
+
+ -- Macro: LINK_ELIMINATE_DUPLICATE_LDIRECTORIES
+ A nonzero value causes `collect2' to remove duplicate
+ `-LDIRECTORY' search directories from linking commands. Do not
+ give it a nonzero value if removing duplicate search directories
+ changes the linker's semantics.
+
+ -- Macro: MULTILIB_DEFAULTS
+ Define this macro as a C expression for the initializer of an
+ array of string to tell the driver program which options are
+ defaults for this target and thus do not need to be handled
+ specially when using `MULTILIB_OPTIONS'.
+
+ Do not define this macro if `MULTILIB_OPTIONS' is not defined in
+ the target makefile fragment or if none of the options listed in
+ `MULTILIB_OPTIONS' are set by default. *Note Target Fragment::.
+
+ -- Macro: RELATIVE_PREFIX_NOT_LINKDIR
+ Define this macro to tell `gcc' that it should only translate a
+ `-B' prefix into a `-L' linker option if the prefix indicates an
+ absolute file name.
+
+ -- Macro: MD_EXEC_PREFIX
+ If defined, this macro is an additional prefix to try after
+ `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when the
+ `-b' option is used, or the compiler is built as a cross compiler.
+ If you define `MD_EXEC_PREFIX', then be sure to add it to the list
+ of directories used to find the assembler in `configure.in'.
+
+ -- Macro: STANDARD_STARTFILE_PREFIX
+ Define this macro as a C string constant if you wish to override
+ the standard choice of `libdir' as the default prefix to try when
+ searching for startup files such as `crt0.o'.
+ `STANDARD_STARTFILE_PREFIX' is not searched when the compiler is
+ built as a cross compiler.
+
+ -- Macro: STANDARD_STARTFILE_PREFIX_1
+ Define this macro as a C string constant if you wish to override
+ the standard choice of `/lib' as a prefix to try after the default
+ prefix when searching for startup files such as `crt0.o'.
+ `STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is
+ built as a cross compiler.
+
+ -- Macro: STANDARD_STARTFILE_PREFIX_2
+ Define this macro as a C string constant if you wish to override
+ the standard choice of `/lib' as yet another prefix to try after
+ the default prefix when searching for startup files such as
+ `crt0.o'. `STANDARD_STARTFILE_PREFIX_2' is not searched when the
+ compiler is built as a cross compiler.
+
+ -- Macro: MD_STARTFILE_PREFIX
+ If defined, this macro supplies an additional prefix to try after
+ the standard prefixes. `MD_EXEC_PREFIX' is not searched when the
+ `-b' option is used, or when the compiler is built as a cross
+ compiler.
+
+ -- Macro: MD_STARTFILE_PREFIX_1
+ If defined, this macro supplies yet another prefix to try after the
+ standard prefixes. It is not searched when the `-b' option is
+ used, or when the compiler is built as a cross compiler.
+
+ -- Macro: INIT_ENVIRONMENT
+ Define this macro as a C string constant if you wish to set
+ environment variables for programs called by the driver, such as
+ the assembler and loader. The driver passes the value of this
+ macro to `putenv' to initialize the necessary environment
+ variables.
+
+ -- Macro: LOCAL_INCLUDE_DIR
+ Define this macro as a C string constant if you wish to override
+ the standard choice of `/usr/local/include' as the default prefix
+ to try when searching for local header files. `LOCAL_INCLUDE_DIR'
+ comes before `SYSTEM_INCLUDE_DIR' in the search order.
+
+ Cross compilers do not search either `/usr/local/include' or its
+ replacement.
+
+ -- Macro: MODIFY_TARGET_NAME
+ Define this macro if you wish to define command-line switches that
+ modify the default target name.
+
+ For each switch, you can include a string to be appended to the
+ first part of the configuration name or a string to be deleted
+ from the configuration name, if present. The definition should be
+ an initializer for an array of structures. Each array element
+ should have three elements: the switch name (a string constant,
+ including the initial dash), one of the enumeration codes `ADD' or
+ `DELETE' to indicate whether the string should be inserted or
+ deleted, and the string to be inserted or deleted (a string
+ constant).
+
+ For example, on a machine where `64' at the end of the
+ configuration name denotes a 64-bit target and you want the `-32'
+ and `-64' switches to select between 32- and 64-bit targets, you
+ would code
+
+ #define MODIFY_TARGET_NAME \
+ { { "-32", DELETE, "64"}, \
+ {"-64", ADD, "64"}}
+
+ -- Macro: SYSTEM_INCLUDE_DIR
+ Define this macro as a C string constant if you wish to specify a
+ system-specific directory to search for header files before the
+ standard directory. `SYSTEM_INCLUDE_DIR' comes before
+ `STANDARD_INCLUDE_DIR' in the search order.
+
+ Cross compilers do not use this macro and do not search the
+ directory specified.
+
+ -- Macro: STANDARD_INCLUDE_DIR
+ Define this macro as a C string constant if you wish to override
+ the standard choice of `/usr/include' as the default prefix to try
+ when searching for header files.
+
+ Cross compilers ignore this macro and do not search either
+ `/usr/include' or its replacement.
+
+ -- Macro: STANDARD_INCLUDE_COMPONENT
+ The "component" corresponding to `STANDARD_INCLUDE_DIR'. See
+ `INCLUDE_DEFAULTS', below, for the description of components. If
+ you do not define this macro, no component is used.
+
+ -- Macro: INCLUDE_DEFAULTS
+ Define this macro if you wish to override the entire default
+ search path for include files. For a native compiler, the default
+ search path usually consists of `GCC_INCLUDE_DIR',
+ `LOCAL_INCLUDE_DIR', `SYSTEM_INCLUDE_DIR',
+ `GPLUSPLUS_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition,
+ `GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are defined
+ automatically by `Makefile', and specify private search areas for
+ GCC. The directory `GPLUSPLUS_INCLUDE_DIR' is used only for C++
+ programs.
+
+ The definition should be an initializer for an array of structures.
+ Each array element should have four elements: the directory name (a
+ string constant), the component name (also a string constant), a
+ flag for C++-only directories, and a flag showing that the
+ includes in the directory don't need to be wrapped in `extern `C''
+ when compiling C++. Mark the end of the array with a null element.
+
+ The component name denotes what GNU package the include file is
+ part of, if any, in all uppercase letters. For example, it might
+ be `GCC' or `BINUTILS'. If the package is part of a
+ vendor-supplied operating system, code the component name as `0'.
+
+ For example, here is the definition used for VAX/VMS:
+
+ #define INCLUDE_DEFAULTS \
+ { \
+ { "GNU_GXX_INCLUDE:", "G++", 1, 1}, \
+ { "GNU_CC_INCLUDE:", "GCC", 0, 0}, \
+ { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0}, \
+ { ".", 0, 0, 0}, \
+ { 0, 0, 0, 0} \
+ }
+
+ Here is the order of prefixes tried for exec files:
+
+ 1. Any prefixes specified by the user with `-B'.
+
+ 2. The environment variable `GCC_EXEC_PREFIX' or, if `GCC_EXEC_PREFIX'
+ is not set and the compiler has not been installed in the
+ configure-time PREFIX, the location in which the compiler has
+ actually been installed.
+
+ 3. The directories specified by the environment variable
+ `COMPILER_PATH'.
+
+ 4. The macro `STANDARD_EXEC_PREFIX', if the compiler has been
+ installed in the configured-time PREFIX.
+
+ 5. The location `/usr/libexec/gcc/', but only if this is a native
+ compiler.
+
+ 6. The location `/usr/lib/gcc/', but only if this is a native
+ compiler.
+
+ 7. The macro `MD_EXEC_PREFIX', if defined, but only if this is a
+ native compiler.
+
+ Here is the order of prefixes tried for startfiles:
+
+ 1. Any prefixes specified by the user with `-B'.
+
+ 2. The environment variable `GCC_EXEC_PREFIX' or its automatically
+ determined value based on the installed toolchain location.
+
+ 3. The directories specified by the environment variable
+ `LIBRARY_PATH' (or port-specific name; native only, cross
+ compilers do not use this).
+
+ 4. The macro `STANDARD_EXEC_PREFIX', but only if the toolchain is
+ installed in the configured PREFIX or this is a native compiler.
+
+ 5. The location `/usr/lib/gcc/', but only if this is a native
+ compiler.
+
+ 6. The macro `MD_EXEC_PREFIX', if defined, but only if this is a
+ native compiler.
+
+ 7. The macro `MD_STARTFILE_PREFIX', if defined, but only if this is a
+ native compiler, or we have a target system root.
+
+ 8. The macro `MD_STARTFILE_PREFIX_1', if defined, but only if this is
+ a native compiler, or we have a target system root.
+
+ 9. The macro `STANDARD_STARTFILE_PREFIX', with any sysroot
+ modifications. If this path is relative it will be prefixed by
+ `GCC_EXEC_PREFIX' and the machine suffix or `STANDARD_EXEC_PREFIX'
+ and the machine suffix.
+
+ 10. The macro `STANDARD_STARTFILE_PREFIX_1', but only if this is a
+ native compiler, or we have a target system root. The default for
+ this macro is `/lib/'.
+
+ 11. The macro `STANDARD_STARTFILE_PREFIX_2', but only if this is a
+ native compiler, or we have a target system root. The default for
+ this macro is `/usr/lib/'.
+
+\1f
+File: gccint.info, Node: Run-time Target, Next: Per-Function Data, Prev: Driver, Up: Target Macros
+
+17.3 Run-time Target Specification
+==================================
+
+Here are run-time target specifications.
+
+ -- Macro: TARGET_CPU_CPP_BUILTINS ()
+ This function-like macro expands to a block of code that defines
+ built-in preprocessor macros and assertions for the target CPU,
+ using the functions `builtin_define', `builtin_define_std' and
+ `builtin_assert'. When the front end calls this macro it provides
+ a trailing semicolon, and since it has finished command line
+ option processing your code can use those results freely.
+
+ `builtin_assert' takes a string in the form you pass to the
+ command-line option `-A', such as `cpu=mips', and creates the
+ assertion. `builtin_define' takes a string in the form accepted
+ by option `-D' and unconditionally defines the macro.
+
+ `builtin_define_std' takes a string representing the name of an
+ object-like macro. If it doesn't lie in the user's namespace,
+ `builtin_define_std' defines it unconditionally. Otherwise, it
+ defines a version with two leading underscores, and another version
+ with two leading and trailing underscores, and defines the original
+ only if an ISO standard was not requested on the command line. For
+ example, passing `unix' defines `__unix', `__unix__' and possibly
+ `unix'; passing `_mips' defines `__mips', `__mips__' and possibly
+ `_mips', and passing `_ABI64' defines only `_ABI64'.
+
+ You can also test for the C dialect being compiled. The variable
+ `c_language' is set to one of `clk_c', `clk_cplusplus' or
+ `clk_objective_c'. Note that if we are preprocessing assembler,
+ this variable will be `clk_c' but the function-like macro
+ `preprocessing_asm_p()' will return true, so you might want to
+ check for that first. If you need to check for strict ANSI, the
+ variable `flag_iso' can be used. The function-like macro
+ `preprocessing_trad_p()' can be used to check for traditional
+ preprocessing.
+
+ -- Macro: TARGET_OS_CPP_BUILTINS ()
+ Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional
+ and is used for the target operating system instead.
+
+ -- Macro: TARGET_OBJFMT_CPP_BUILTINS ()
+ Similarly to `TARGET_CPU_CPP_BUILTINS' but this macro is optional
+ and is used for the target object format. `elfos.h' uses this
+ macro to define `__ELF__', so you probably do not need to define
+ it yourself.
+
+ -- Variable: extern int target_flags
+ This variable is declared in `options.h', which is included before
+ any target-specific headers.
+
+ -- Variable: Target Hook int TARGET_DEFAULT_TARGET_FLAGS
+ This variable specifies the initial value of `target_flags'. Its
+ default setting is 0.
+
+ -- Target Hook: bool TARGET_HANDLE_OPTION (size_t CODE, const char
+ *ARG, int VALUE)
+ This hook is called whenever the user specifies one of the
+ target-specific options described by the `.opt' definition files
+ (*note Options::). It has the opportunity to do some
+ option-specific processing and should return true if the option is
+ valid. The default definition does nothing but return true.
+
+ CODE specifies the `OPT_NAME' enumeration value associated with
+ the selected option; NAME is just a rendering of the option name
+ in which non-alphanumeric characters are replaced by underscores.
+ ARG specifies the string argument and is null if no argument was
+ given. If the option is flagged as a `UInteger' (*note Option
+ properties::), VALUE is the numeric value of the argument.
+ Otherwise VALUE is 1 if the positive form of the option was used
+ and 0 if the "no-" form was.
+
+ -- Target Hook: bool TARGET_HANDLE_C_OPTION (size_t CODE, const char
+ *ARG, int VALUE)
+ This target hook is called whenever the user specifies one of the
+ target-specific C language family options described by the `.opt'
+ definition files(*note Options::). It has the opportunity to do
+ some option-specific processing and should return true if the
+ option is valid. The default definition does nothing but return
+ false.
+
+ In general, you should use `TARGET_HANDLE_OPTION' to handle
+ options. However, if processing an option requires routines that
+ are only available in the C (and related language) front ends,
+ then you should use `TARGET_HANDLE_C_OPTION' instead.
+
+ -- Macro: TARGET_VERSION
+ This macro is a C statement to print on `stderr' a string
+ describing the particular machine description choice. Every
+ machine description should define `TARGET_VERSION'. For example:
+
+ #ifdef MOTOROLA
+ #define TARGET_VERSION \
+ fprintf (stderr, " (68k, Motorola syntax)");
+ #else
+ #define TARGET_VERSION \
+ fprintf (stderr, " (68k, MIT syntax)");
+ #endif
+
+ -- Macro: OVERRIDE_OPTIONS
+ Sometimes certain combinations of command options do not make
+ sense on a particular target machine. You can define a macro
+ `OVERRIDE_OPTIONS' to take account of this. This macro, if
+ defined, is executed once just after all the command options have
+ been parsed.
+
+ Don't use this macro to turn on various extra optimizations for
+ `-O'. That is what `OPTIMIZATION_OPTIONS' is for.
+
+ -- Macro: C_COMMON_OVERRIDE_OPTIONS
+ This is similar to `OVERRIDE_OPTIONS' but is only used in the C
+ language frontends (C, Objective-C, C++, Objective-C++) and so can
+ be used to alter option flag variables which only exist in those
+ frontends.
+
+ -- Macro: OPTIMIZATION_OPTIONS (LEVEL, SIZE)
+ Some machines may desire to change what optimizations are
+ performed for various optimization levels. This macro, if
+ defined, is executed once just after the optimization level is
+ determined and before the remainder of the command options have
+ been parsed. Values set in this macro are used as the default
+ values for the other command line options.
+
+ LEVEL is the optimization level specified; 2 if `-O2' is
+ specified, 1 if `-O' is specified, and 0 if neither is specified.
+
+ SIZE is nonzero if `-Os' is specified and zero otherwise.
+
+ This macro is run once at program startup and when the optimization
+ options are changed via `#pragma GCC optimize' or by using the
+ `optimize' attribute.
+
+ *Do not examine `write_symbols' in this macro!* The debugging
+ options are not supposed to alter the generated code.
+
+ -- Target Hook: bool TARGET_HELP (void)
+ This hook is called in response to the user invoking
+ `--target-help' on the command line. It gives the target a chance
+ to display extra information on the target specific command line
+ options found in its `.opt' file.
+
+ -- Macro: CAN_DEBUG_WITHOUT_FP
+ Define this macro if debugging can be performed even without a
+ frame pointer. If this macro is defined, GCC will turn on the
+ `-fomit-frame-pointer' option whenever `-O' is specified.
+
+\1f
+File: gccint.info, Node: Per-Function Data, Next: Storage Layout, Prev: Run-time Target, Up: Target Macros
+
+17.4 Defining data structures for per-function information.
+===========================================================
+
+If the target needs to store information on a per-function basis, GCC
+provides a macro and a couple of variables to allow this. Note, just
+using statics to store the information is a bad idea, since GCC supports
+nested functions, so you can be halfway through encoding one function
+when another one comes along.
+
+ GCC defines a data structure called `struct function' which contains
+all of the data specific to an individual function. This structure
+contains a field called `machine' whose type is `struct
+machine_function *', which can be used by targets to point to their own
+specific data.
+
+ If a target needs per-function specific data it should define the type
+`struct machine_function' and also the macro `INIT_EXPANDERS'. This
+macro should be used to initialize the function pointer
+`init_machine_status'. This pointer is explained below.
+
+ One typical use of per-function, target specific data is to create an
+RTX to hold the register containing the function's return address. This
+RTX can then be used to implement the `__builtin_return_address'
+function, for level 0.
+
+ Note--earlier implementations of GCC used a single data area to hold
+all of the per-function information. Thus when processing of a nested
+function began the old per-function data had to be pushed onto a stack,
+and when the processing was finished, it had to be popped off the
+stack. GCC used to provide function pointers called
+`save_machine_status' and `restore_machine_status' to handle the saving
+and restoring of the target specific information. Since the single
+data area approach is no longer used, these pointers are no longer
+supported.
+
+ -- Macro: INIT_EXPANDERS
+ Macro called to initialize any target specific information. This
+ macro is called once per function, before generation of any RTL
+ has begun. The intention of this macro is to allow the
+ initialization of the function pointer `init_machine_status'.
+
+ -- Variable: void (*)(struct function *) init_machine_status
+ If this function pointer is non-`NULL' it will be called once per
+ function, before function compilation starts, in order to allow the
+ target to perform any target specific initialization of the
+ `struct function' structure. It is intended that this would be
+ used to initialize the `machine' of that structure.
+
+ `struct machine_function' structures are expected to be freed by
+ GC. Generally, any memory that they reference must be allocated
+ by using `ggc_alloc', including the structure itself.
+
+\1f
+File: gccint.info, Node: Storage Layout, Next: Type Layout, Prev: Per-Function Data, Up: Target Macros
+
+17.5 Storage Layout
+===================
+
+Note that the definitions of the macros in this table which are sizes or
+alignments measured in bits do not need to be constant. They can be C
+expressions that refer to static variables, such as the `target_flags'.
+*Note Run-time Target::.
+
+ -- Macro: BITS_BIG_ENDIAN
+ Define this macro to have the value 1 if the most significant bit
+ in a byte has the lowest number; otherwise define it to have the
+ value zero. This means that bit-field instructions count from the
+ most significant bit. If the machine has no bit-field
+ instructions, then this must still be defined, but it doesn't
+ matter which value it is defined to. This macro need not be a
+ constant.
+
+ This macro does not affect the way structure fields are packed into
+ bytes or words; that is controlled by `BYTES_BIG_ENDIAN'.
+
+ -- Macro: BYTES_BIG_ENDIAN
+ Define this macro to have the value 1 if the most significant byte
+ in a word has the lowest number. This macro need not be a
+ constant.
+
+ -- Macro: WORDS_BIG_ENDIAN
+ Define this macro to have the value 1 if, in a multiword object,
+ the most significant word has the lowest number. This applies to
+ both memory locations and registers; GCC fundamentally assumes
+ that the order of words in memory is the same as the order in
+ registers. This macro need not be a constant.
+
+ -- Macro: LIBGCC2_WORDS_BIG_ENDIAN
+ Define this macro if `WORDS_BIG_ENDIAN' is not constant. This
+ must be a constant value with the same meaning as
+ `WORDS_BIG_ENDIAN', which will be used only when compiling
+ `libgcc2.c'. Typically the value will be set based on
+ preprocessor defines.
+
+ -- Macro: FLOAT_WORDS_BIG_ENDIAN
+ Define this macro to have the value 1 if `DFmode', `XFmode' or
+ `TFmode' floating point numbers are stored in memory with the word
+ containing the sign bit at the lowest address; otherwise define it
+ to have the value 0. This macro need not be a constant.
+
+ You need not define this macro if the ordering is the same as for
+ multi-word integers.
+
+ -- Macro: BITS_PER_UNIT
+ Define this macro to be the number of bits in an addressable
+ storage unit (byte). If you do not define this macro the default
+ is 8.
+
+ -- Macro: BITS_PER_WORD
+ Number of bits in a word. If you do not define this macro, the
+ default is `BITS_PER_UNIT * UNITS_PER_WORD'.
+
+ -- Macro: MAX_BITS_PER_WORD
+ Maximum number of bits in a word. If this is undefined, the
+ default is `BITS_PER_WORD'. Otherwise, it is the constant value
+ that is the largest value that `BITS_PER_WORD' can have at
+ run-time.
+
+ -- Macro: UNITS_PER_WORD
+ Number of storage units in a word; normally the size of a
+ general-purpose register, a power of two from 1 or 8.
+
+ -- Macro: MIN_UNITS_PER_WORD
+ Minimum number of units in a word. If this is undefined, the
+ default is `UNITS_PER_WORD'. Otherwise, it is the constant value
+ that is the smallest value that `UNITS_PER_WORD' can have at
+ run-time.
+
+ -- Macro: UNITS_PER_SIMD_WORD (MODE)
+ Number of units in the vectors that the vectorizer can produce for
+ scalar mode MODE. The default is equal to `UNITS_PER_WORD',
+ because the vectorizer can do some transformations even in absence
+ of specialized SIMD hardware.
+
+ -- Macro: POINTER_SIZE
+ Width of a pointer, in bits. You must specify a value no wider
+ than the width of `Pmode'. If it is not equal to the width of
+ `Pmode', you must define `POINTERS_EXTEND_UNSIGNED'. If you do
+ not specify a value the default is `BITS_PER_WORD'.
+
+ -- Macro: POINTERS_EXTEND_UNSIGNED
+ A C expression that determines how pointers should be extended from
+ `ptr_mode' to either `Pmode' or `word_mode'. It is greater than
+ zero if pointers should be zero-extended, zero if they should be
+ sign-extended, and negative if some other sort of conversion is
+ needed. In the last case, the extension is done by the target's
+ `ptr_extend' instruction.
+
+ You need not define this macro if the `ptr_mode', `Pmode' and
+ `word_mode' are all the same width.
+
+ -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE)
+ A macro to update M and UNSIGNEDP when an object whose type is
+ TYPE and which has the specified mode and signedness is to be
+ stored in a register. This macro is only called when TYPE is a
+ scalar type.
+
+ On most RISC machines, which only have operations that operate on
+ a full register, define this macro to set M to `word_mode' if M is
+ an integer mode narrower than `BITS_PER_WORD'. In most cases,
+ only integer modes should be widened because wider-precision
+ floating-point operations are usually more expensive than their
+ narrower counterparts.
+
+ For most machines, the macro definition does not change UNSIGNEDP.
+ However, some machines, have instructions that preferentially
+ handle either signed or unsigned quantities of certain modes. For
+ example, on the DEC Alpha, 32-bit loads from memory and 32-bit add
+ instructions sign-extend the result to 64 bits. On such machines,
+ set UNSIGNEDP according to which kind of extension is more
+ efficient.
+
+ Do not define this macro if it would never modify M.
+
+ -- Macro: PROMOTE_FUNCTION_MODE
+ Like `PROMOTE_MODE', but is applied to outgoing function arguments
+ or function return values, as specified by
+ `TARGET_PROMOTE_FUNCTION_ARGS' and
+ `TARGET_PROMOTE_FUNCTION_RETURN', respectively.
+
+ The default is `PROMOTE_MODE'.
+
+ -- Target Hook: bool TARGET_PROMOTE_FUNCTION_ARGS (tree FNTYPE)
+ This target hook should return `true' if the promotion described by
+ `PROMOTE_FUNCTION_MODE' should be done for outgoing function
+ arguments.
+
+ -- Target Hook: bool TARGET_PROMOTE_FUNCTION_RETURN (tree FNTYPE)
+ This target hook should return `true' if the promotion described by
+ `PROMOTE_FUNCTION_MODE' should be done for the return value of
+ functions.
+
+ If this target hook returns `true', `TARGET_FUNCTION_VALUE' must
+ perform the same promotions done by `PROMOTE_FUNCTION_MODE'.
+
+ -- Macro: PARM_BOUNDARY
+ Normal alignment required for function parameters on the stack, in
+ bits. All stack parameters receive at least this much alignment
+ regardless of data type. On most machines, this is the same as the
+ size of an integer.
+
+ -- Macro: STACK_BOUNDARY
+ Define this macro to the minimum alignment enforced by hardware
+ for the stack pointer on this machine. The definition is a C
+ expression for the desired alignment (measured in bits). This
+ value is used as a default if `PREFERRED_STACK_BOUNDARY' is not
+ defined. On most machines, this should be the same as
+ `PARM_BOUNDARY'.
+
+ -- Macro: PREFERRED_STACK_BOUNDARY
+ Define this macro if you wish to preserve a certain alignment for
+ the stack pointer, greater than what the hardware enforces. The
+ definition is a C expression for the desired alignment (measured
+ in bits). This macro must evaluate to a value equal to or larger
+ than `STACK_BOUNDARY'.
+
+ -- Macro: INCOMING_STACK_BOUNDARY
+ Define this macro if the incoming stack boundary may be different
+ from `PREFERRED_STACK_BOUNDARY'. This macro must evaluate to a
+ value equal to or larger than `STACK_BOUNDARY'.
+
+ -- Macro: FUNCTION_BOUNDARY
+ Alignment required for a function entry point, in bits.
+
+ -- Macro: BIGGEST_ALIGNMENT
+ Biggest alignment that any data type can require on this machine,
+ in bits. Note that this is not the biggest alignment that is
+ supported, just the biggest alignment that, when violated, may
+ cause a fault.
+
+ -- Macro: MALLOC_ABI_ALIGNMENT
+ Alignment, in bits, a C conformant malloc implementation has to
+ provide. If not defined, the default value is `BITS_PER_WORD'.
+
+ -- Macro: ATTRIBUTE_ALIGNED_VALUE
+ Alignment used by the `__attribute__ ((aligned))' construct. If
+ not defined, the default value is `BIGGEST_ALIGNMENT'.
+
+ -- Macro: MINIMUM_ATOMIC_ALIGNMENT
+ If defined, the smallest alignment, in bits, that can be given to
+ an object that can be referenced in one operation, without
+ disturbing any nearby object. Normally, this is `BITS_PER_UNIT',
+ but may be larger on machines that don't have byte or half-word
+ store operations.
+
+ -- Macro: BIGGEST_FIELD_ALIGNMENT
+ Biggest alignment that any structure or union field can require on
+ this machine, in bits. If defined, this overrides
+ `BIGGEST_ALIGNMENT' for structure and union fields only, unless
+ the field alignment has been set by the `__attribute__ ((aligned
+ (N)))' construct.
+
+ -- Macro: ADJUST_FIELD_ALIGN (FIELD, COMPUTED)
+ An expression for the alignment of a structure field FIELD if the
+ alignment computed in the usual way (including applying of
+ `BIGGEST_ALIGNMENT' and `BIGGEST_FIELD_ALIGNMENT' to the
+ alignment) is COMPUTED. It overrides alignment only if the field
+ alignment has not been set by the `__attribute__ ((aligned (N)))'
+ construct.
+
+ -- Macro: MAX_STACK_ALIGNMENT
+ Biggest stack alignment guaranteed by the backend. Use this macro
+ to specify the maximum alignment of a variable on stack.
+
+ If not defined, the default value is `STACK_BOUNDARY'.
+
+
+ -- Macro: MAX_OFILE_ALIGNMENT
+ Biggest alignment supported by the object file format of this
+ machine. Use this macro to limit the alignment which can be
+ specified using the `__attribute__ ((aligned (N)))' construct. If
+ not defined, the default value is `BIGGEST_ALIGNMENT'.
+
+ On systems that use ELF, the default (in `config/elfos.h') is the
+ largest supported 32-bit ELF section alignment representable on a
+ 32-bit host e.g. `(((unsigned HOST_WIDEST_INT) 1 << 28) * 8)'. On
+ 32-bit ELF the largest supported section alignment in bits is
+ `(0x80000000 * 8)', but this is not representable on 32-bit hosts.
+
+ -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN)
+ If defined, a C expression to compute the alignment for a variable
+ in the static store. TYPE is the data type, and BASIC-ALIGN is
+ the alignment that the object would ordinarily have. The value of
+ this macro is used instead of that alignment to align the object.
+
+ If this macro is not defined, then BASIC-ALIGN is used.
+
+ One use of this macro is to increase alignment of medium-size data
+ to make it all fit in fewer cache lines. Another is to cause
+ character arrays to be word-aligned so that `strcpy' calls that
+ copy constants to character arrays can be done inline.
+
+ -- Macro: CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN)
+ If defined, a C expression to compute the alignment given to a
+ constant that is being placed in memory. CONSTANT is the constant
+ and BASIC-ALIGN is the alignment that the object would ordinarily
+ have. The value of this macro is used instead of that alignment to
+ align the object.
+
+ If this macro is not defined, then BASIC-ALIGN is used.
+
+ The typical use of this macro is to increase alignment for string
+ constants to be word aligned so that `strcpy' calls that copy
+ constants can be done inline.
+
+ -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN)
+ If defined, a C expression to compute the alignment for a variable
+ in the local store. TYPE is the data type, and BASIC-ALIGN is the
+ alignment that the object would ordinarily have. The value of this
+ macro is used instead of that alignment to align the object.
+
+ If this macro is not defined, then BASIC-ALIGN is used.
+
+ One use of this macro is to increase alignment of medium-size data
+ to make it all fit in fewer cache lines.
+
+ -- Macro: STACK_SLOT_ALIGNMENT (TYPE, MODE, BASIC-ALIGN)
+ If defined, a C expression to compute the alignment for stack slot.
+ TYPE is the data type, MODE is the widest mode available, and
+ BASIC-ALIGN is the alignment that the slot would ordinarily have.
+ The value of this macro is used instead of that alignment to align
+ the slot.
+
+ If this macro is not defined, then BASIC-ALIGN is used when TYPE
+ is `NULL'. Otherwise, `LOCAL_ALIGNMENT' will be used.
+
+ This macro is to set alignment of stack slot to the maximum
+ alignment of all possible modes which the slot may have.
+
+ -- Macro: LOCAL_DECL_ALIGNMENT (DECL)
+ If defined, a C expression to compute the alignment for a local
+ variable DECL.
+
+ If this macro is not defined, then `LOCAL_ALIGNMENT (TREE_TYPE
+ (DECL), DECL_ALIGN (DECL))' is used.
+
+ One use of this macro is to increase alignment of medium-size data
+ to make it all fit in fewer cache lines.
+
+ -- Macro: MINIMUM_ALIGNMENT (EXP, MODE, ALIGN)
+ If defined, a C expression to compute the minimum required
+ alignment for dynamic stack realignment purposes for EXP (a type
+ or decl), MODE, assuming normal alignment ALIGN.
+
+ If this macro is not defined, then ALIGN will be used.
+
+ -- Macro: EMPTY_FIELD_BOUNDARY
+ Alignment in bits to be given to a structure bit-field that
+ follows an empty field such as `int : 0;'.
+
+ If `PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro.
+
+ -- Macro: STRUCTURE_SIZE_BOUNDARY
+ Number of bits which any structure or union's size must be a
+ multiple of. Each structure or union's size is rounded up to a
+ multiple of this.
+
+ If you do not define this macro, the default is the same as
+ `BITS_PER_UNIT'.
+
+ -- Macro: STRICT_ALIGNMENT
+ Define this macro to be the value 1 if instructions will fail to
+ work if given data not on the nominal alignment. If instructions
+ will merely go slower in that case, define this macro as 0.
+
+ -- Macro: PCC_BITFIELD_TYPE_MATTERS
+ Define this if you wish to imitate the way many other C compilers
+ handle alignment of bit-fields and the structures that contain
+ them.
+
+ The behavior is that the type written for a named bit-field (`int',
+ `short', or other integer type) imposes an alignment for the entire
+ structure, as if the structure really did contain an ordinary
+ field of that type. In addition, the bit-field is placed within
+ the structure so that it would fit within such a field, not
+ crossing a boundary for it.
+
+ Thus, on most machines, a named bit-field whose type is written as
+ `int' would not cross a four-byte boundary, and would force
+ four-byte alignment for the whole structure. (The alignment used
+ may not be four bytes; it is controlled by the other alignment
+ parameters.)
+
+ An unnamed bit-field will not affect the alignment of the
+ containing structure.
+
+ If the macro is defined, its definition should be a C expression;
+ a nonzero value for the expression enables this behavior.
+
+ Note that if this macro is not defined, or its value is zero, some
+ bit-fields may cross more than one alignment boundary. The
+ compiler can support such references if there are `insv', `extv',
+ and `extzv' insns that can directly reference memory.
+
+ The other known way of making bit-fields work is to define
+ `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then
+ every structure can be accessed with fullwords.
+
+ Unless the machine has bit-field instructions or you define
+ `STRUCTURE_SIZE_BOUNDARY' that way, you must define
+ `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value.
+
+ If your aim is to make GCC use the same conventions for laying out
+ bit-fields as are used by another compiler, here is how to
+ investigate what the other compiler does. Compile and run this
+ program:
+
+ struct foo1
+ {
+ char x;
+ char :0;
+ char y;
+ };
+
+ struct foo2
+ {
+ char x;
+ int :0;
+ char y;
+ };
+
+ main ()
+ {
+ printf ("Size of foo1 is %d\n",
+ sizeof (struct foo1));
+ printf ("Size of foo2 is %d\n",
+ sizeof (struct foo2));
+ exit (0);
+ }
+
+ If this prints 2 and 5, then the compiler's behavior is what you
+ would get from `PCC_BITFIELD_TYPE_MATTERS'.
+
+ -- Macro: BITFIELD_NBYTES_LIMITED
+ Like `PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited
+ to aligning a bit-field within the structure.
+
+ -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELD (void)
+ When `PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine
+ whether unnamed bitfields affect the alignment of the containing
+ structure. The hook should return true if the structure should
+ inherit the alignment requirements of an unnamed bitfield's type.
+
+ -- Target Hook: bool TARGET_NARROW_VOLATILE_BITFIELD (void)
+ This target hook should return `true' if accesses to volatile
+ bitfields should use the narrowest mode possible. It should
+ return `false' if these accesses should use the bitfield container
+ type.
+
+ The default is `!TARGET_STRICT_ALIGN'.
+
+ -- Macro: MEMBER_TYPE_FORCES_BLK (FIELD, MODE)
+ Return 1 if a structure or array containing FIELD should be
+ accessed using `BLKMODE'.
+
+ If FIELD is the only field in the structure, MODE is its mode,
+ otherwise MODE is VOIDmode. MODE is provided in the case where
+ structures of one field would require the structure's mode to
+ retain the field's mode.
+
+ Normally, this is not needed.
+
+ -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED)
+ Define this macro as an expression for the alignment of a type
+ (given by TYPE as a tree node) if the alignment computed in the
+ usual way is COMPUTED and the alignment explicitly specified was
+ SPECIFIED.
+
+ The default is to use SPECIFIED if it is larger; otherwise, use
+ the smaller of COMPUTED and `BIGGEST_ALIGNMENT'
+
+ -- Macro: MAX_FIXED_MODE_SIZE
+ An integer expression for the size in bits of the largest integer
+ machine mode that should actually be used. All integer machine
+ modes of this size or smaller can be used for structures and
+ unions with the appropriate sizes. If this macro is undefined,
+ `GET_MODE_BITSIZE (DImode)' is assumed.
+
+ -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL)
+ If defined, an expression of type `enum machine_mode' that
+ specifies the mode of the save area operand of a
+ `save_stack_LEVEL' named pattern (*note Standard Names::).
+ SAVE_LEVEL is one of `SAVE_BLOCK', `SAVE_FUNCTION', or
+ `SAVE_NONLOCAL' and selects which of the three named patterns is
+ having its mode specified.
+
+ You need not define this macro if it always returns `Pmode'. You
+ would most commonly define this macro if the `save_stack_LEVEL'
+ patterns need to support both a 32- and a 64-bit mode.
+
+ -- Macro: STACK_SIZE_MODE
+ If defined, an expression of type `enum machine_mode' that
+ specifies the mode of the size increment operand of an
+ `allocate_stack' named pattern (*note Standard Names::).
+
+ You need not define this macro if it always returns `word_mode'.
+ You would most commonly define this macro if the `allocate_stack'
+ pattern needs to support both a 32- and a 64-bit mode.
+
+ -- Target Hook: enum machine_mode TARGET_LIBGCC_CMP_RETURN_MODE ()
+ This target hook should return the mode to be used for the return
+ value of compare instructions expanded to libgcc calls. If not
+ defined `word_mode' is returned which is the right choice for a
+ majority of targets.
+
+ -- Target Hook: enum machine_mode TARGET_LIBGCC_SHIFT_COUNT_MODE ()
+ This target hook should return the mode to be used for the shift
+ count operand of shift instructions expanded to libgcc calls. If
+ not defined `word_mode' is returned which is the right choice for
+ a majority of targets.
+
+ -- Macro: ROUND_TOWARDS_ZERO
+ If defined, this macro should be true if the prevailing rounding
+ mode is towards zero.
+
+ Defining this macro only affects the way `libgcc.a' emulates
+ floating-point arithmetic.
+
+ Not defining this macro is equivalent to returning zero.
+
+ -- Macro: LARGEST_EXPONENT_IS_NORMAL (SIZE)
+ This macro should return true if floats with SIZE bits do not have
+ a NaN or infinity representation, but use the largest exponent for
+ normal numbers instead.
+
+ Defining this macro only affects the way `libgcc.a' emulates
+ floating-point arithmetic.
+
+ The default definition of this macro returns false for all sizes.
+
+ -- Target Hook: bool TARGET_VECTOR_OPAQUE_P (tree TYPE)
+ This target hook should return `true' a vector is opaque. That
+ is, if no cast is needed when copying a vector value of type TYPE
+ into another vector lvalue of the same size. Vector opaque types
+ cannot be initialized. The default is that there are no such
+ types.
+
+ -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (tree RECORD_TYPE)
+ This target hook returns `true' if bit-fields in the given
+ RECORD_TYPE are to be laid out following the rules of Microsoft
+ Visual C/C++, namely: (i) a bit-field won't share the same storage
+ unit with the previous bit-field if their underlying types have
+ different sizes, and the bit-field will be aligned to the highest
+ alignment of the underlying types of itself and of the previous
+ bit-field; (ii) a zero-sized bit-field will affect the alignment of
+ the whole enclosing structure, even if it is unnamed; except that
+ (iii) a zero-sized bit-field will be disregarded unless it follows
+ another bit-field of nonzero size. If this hook returns `true',
+ other macros that control bit-field layout are ignored.
+
+ 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). In an unpacked record, this is the
+ same as using alignment, but not equivalent when packing.
+
+ 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.
+
+ -- Target Hook: bool TARGET_DECIMAL_FLOAT_SUPPORTED_P (void)
+ Returns true if the target supports decimal floating point.
+
+ -- Target Hook: bool TARGET_FIXED_POINT_SUPPORTED_P (void)
+ Returns true if the target supports fixed-point arithmetic.
+
+ -- Target Hook: void TARGET_EXPAND_TO_RTL_HOOK (void)
+ This hook is called just before expansion into rtl, allowing the
+ target to perform additional initializations or analysis before
+ the expansion. For example, the rs6000 port uses it to allocate a
+ scratch stack slot for use in copying SDmode values between memory
+ and floating point registers whenever the function being expanded
+ has any SDmode usage.
+
+ -- Target Hook: void TARGET_INSTANTIATE_DECLS (void)
+ This hook allows the backend to perform additional instantiations
+ on rtl that are not actually in any insns yet, but will be later.
+
+ -- Target Hook: const char * TARGET_MANGLE_TYPE (tree TYPE)
+ If your target defines any fundamental types, or any types your
+ target uses should be mangled differently from the default, define
+ this hook to return the appropriate encoding for these types as
+ part of a C++ mangled name. The TYPE argument is the tree
+ structure representing the type to be mangled. The hook may be
+ applied to trees which are not target-specific fundamental types;
+ it should return `NULL' for all such types, as well as arguments
+ it does not recognize. If the return value is not `NULL', it must
+ point to a statically-allocated string constant.
+
+ Target-specific fundamental types might be new fundamental types or
+ qualified versions of ordinary fundamental types. Encode new
+ fundamental types as `u N NAME', where NAME is the name used for
+ the type in source code, and N is the length of NAME in decimal.
+ Encode qualified versions of ordinary types as `U N NAME CODE',
+ where NAME is the name used for the type qualifier in source code,
+ N is the length of NAME as above, and CODE is the code used to
+ represent the unqualified version of this type. (See
+ `write_builtin_type' in `cp/mangle.c' for the list of codes.) In
+ both cases the spaces are for clarity; do not include any spaces
+ in your string.
+
+ This hook is applied to types prior to typedef resolution. If the
+ mangled name for a particular type depends only on that type's
+ main variant, you can perform typedef resolution yourself using
+ `TYPE_MAIN_VARIANT' before mangling.
+
+ The default version of this hook always returns `NULL', which is
+ appropriate for a target that does not define any new fundamental
+ types.
+
+\1f
+File: gccint.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros
+
+17.6 Layout of Source Language Data Types
+=========================================
+
+These macros define the sizes and other characteristics of the standard
+basic data types used in programs being compiled. Unlike the macros in
+the previous section, these apply to specific features of C and related
+languages, rather than to fundamental aspects of storage layout.
+
+ -- Macro: INT_TYPE_SIZE
+ A C expression for the size in bits of the type `int' on the
+ target machine. If you don't define this, the default is one word.
+
+ -- Macro: SHORT_TYPE_SIZE
+ A C expression for the size in bits of the type `short' on the
+ target machine. If you don't define this, the default is half a
+ word. (If this would be less than one storage unit, it is rounded
+ up to one unit.)
+
+ -- Macro: LONG_TYPE_SIZE
+ A C expression for the size in bits of the type `long' on the
+ target machine. If you don't define this, the default is one word.
+
+ -- Macro: ADA_LONG_TYPE_SIZE
+ On some machines, the size used for the Ada equivalent of the type
+ `long' by a native Ada compiler differs from that used by C. In
+ that situation, define this macro to be a C expression to be used
+ for the size of that type. If you don't define this, the default
+ is the value of `LONG_TYPE_SIZE'.
+
+ -- Macro: LONG_LONG_TYPE_SIZE
+ A C expression for the size in bits of the type `long long' on the
+ target machine. If you don't define this, the default is two
+ words. If you want to support GNU Ada on your machine, the value
+ of this macro must be at least 64.
+
+ -- Macro: CHAR_TYPE_SIZE
+ A C expression for the size in bits of the type `char' on the
+ target machine. If you don't define this, the default is
+ `BITS_PER_UNIT'.
+
+ -- Macro: BOOL_TYPE_SIZE
+ A C expression for the size in bits of the C++ type `bool' and C99
+ type `_Bool' on the target machine. If you don't define this, and
+ you probably shouldn't, the default is `CHAR_TYPE_SIZE'.
+
+ -- Macro: FLOAT_TYPE_SIZE
+ A C expression for the size in bits of the type `float' on the
+ target machine. If you don't define this, the default is one word.
+
+ -- Macro: DOUBLE_TYPE_SIZE
+ A C expression for the size in bits of the type `double' on the
+ target machine. If you don't define this, the default is two
+ words.
+
+ -- Macro: LONG_DOUBLE_TYPE_SIZE
+ A C expression for the size in bits of the type `long double' on
+ the target machine. If you don't define this, the default is two
+ words.
+
+ -- Macro: SHORT_FRACT_TYPE_SIZE
+ A C expression for the size in bits of the type `short _Fract' on
+ the target machine. If you don't define this, the default is
+ `BITS_PER_UNIT'.
+
+ -- Macro: FRACT_TYPE_SIZE
+ A C expression for the size in bits of the type `_Fract' on the
+ target machine. If you don't define this, the default is
+ `BITS_PER_UNIT * 2'.
+
+ -- Macro: LONG_FRACT_TYPE_SIZE
+ A C expression for the size in bits of the type `long _Fract' on
+ the target machine. If you don't define this, the default is
+ `BITS_PER_UNIT * 4'.
+
+ -- Macro: LONG_LONG_FRACT_TYPE_SIZE
+ A C expression for the size in bits of the type `long long _Fract'
+ on the target machine. If you don't define this, the default is
+ `BITS_PER_UNIT * 8'.
+
+ -- Macro: SHORT_ACCUM_TYPE_SIZE
+ A C expression for the size in bits of the type `short _Accum' on
+ the target machine. If you don't define this, the default is
+ `BITS_PER_UNIT * 2'.
+
+ -- Macro: ACCUM_TYPE_SIZE
+ A C expression for the size in bits of the type `_Accum' on the
+ target machine. If you don't define this, the default is
+ `BITS_PER_UNIT * 4'.
+
+ -- Macro: LONG_ACCUM_TYPE_SIZE
+ A C expression for the size in bits of the type `long _Accum' on
+ the target machine. If you don't define this, the default is
+ `BITS_PER_UNIT * 8'.
+
+ -- Macro: LONG_LONG_ACCUM_TYPE_SIZE
+ A C expression for the size in bits of the type `long long _Accum'
+ on the target machine. If you don't define this, the default is
+ `BITS_PER_UNIT * 16'.
+
+ -- Macro: LIBGCC2_LONG_DOUBLE_TYPE_SIZE
+ Define this macro if `LONG_DOUBLE_TYPE_SIZE' is not constant or if
+ you want routines in `libgcc2.a' for a size other than
+ `LONG_DOUBLE_TYPE_SIZE'. If you don't define this, the default is
+ `LONG_DOUBLE_TYPE_SIZE'.
+
+ -- Macro: LIBGCC2_HAS_DF_MODE
+ Define this macro if neither `LIBGCC2_DOUBLE_TYPE_SIZE' nor
+ `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is `DFmode' but you want `DFmode'
+ routines in `libgcc2.a' anyway. If you don't define this and
+ either `LIBGCC2_DOUBLE_TYPE_SIZE' or
+ `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 64 then the default is 1,
+ otherwise it is 0.
+
+ -- Macro: LIBGCC2_HAS_XF_MODE
+ Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not
+ `XFmode' but you want `XFmode' routines in `libgcc2.a' anyway. If
+ you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 80
+ then the default is 1, otherwise it is 0.
+
+ -- Macro: LIBGCC2_HAS_TF_MODE
+ Define this macro if `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not
+ `TFmode' but you want `TFmode' routines in `libgcc2.a' anyway. If
+ you don't define this and `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 128
+ then the default is 1, otherwise it is 0.
+
+ -- Macro: SF_SIZE
+ -- Macro: DF_SIZE
+ -- Macro: XF_SIZE
+ -- Macro: TF_SIZE
+ Define these macros to be the size in bits of the mantissa of
+ `SFmode', `DFmode', `XFmode' and `TFmode' values, if the defaults
+ in `libgcc2.h' are inappropriate. By default, `FLT_MANT_DIG' is
+ used for `SF_SIZE', `LDBL_MANT_DIG' for `XF_SIZE' and `TF_SIZE',
+ and `DBL_MANT_DIG' or `LDBL_MANT_DIG' for `DF_SIZE' according to
+ whether `LIBGCC2_DOUBLE_TYPE_SIZE' or
+ `LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 64.
+
+ -- Macro: TARGET_FLT_EVAL_METHOD
+ A C expression for the value for `FLT_EVAL_METHOD' in `float.h',
+ assuming, if applicable, that the floating-point control word is
+ in its default state. If you do not define this macro the value of
+ `FLT_EVAL_METHOD' will be zero.
+
+ -- Macro: WIDEST_HARDWARE_FP_SIZE
+ A C expression for the size in bits of the widest floating-point
+ format supported by the hardware. If you define this macro, you
+ must specify a value less than or equal to the value of
+ `LONG_DOUBLE_TYPE_SIZE'. If you do not define this macro, the
+ value of `LONG_DOUBLE_TYPE_SIZE' is the default.
+
+ -- Macro: DEFAULT_SIGNED_CHAR
+ An expression whose value is 1 or 0, according to whether the type
+ `char' should be signed or unsigned by default. The user can
+ always override this default with the options `-fsigned-char' and
+ `-funsigned-char'.
+
+ -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void)
+ This target hook should return true if the compiler should give an
+ `enum' type only as many bytes as it takes to represent the range
+ of possible values of that type. It should return false if all
+ `enum' types should be allocated like `int'.
+
+ The default is to return false.
+
+ -- Macro: SIZE_TYPE
+ A C expression for a string describing the name of the data type
+ to use for size values. The typedef name `size_t' is defined
+ using the contents of the string.
+
+ The string can contain more than one keyword. If so, separate
+ them with spaces, and write first any length keyword, then
+ `unsigned' if appropriate, and finally `int'. The string must
+ exactly match one of the data type names defined in the function
+ `init_decl_processing' in the file `c-decl.c'. You may not omit
+ `int' or change the order--that would cause the compiler to crash
+ on startup.
+
+ If you don't define this macro, the default is `"long unsigned
+ int"'.
+
+ -- Macro: PTRDIFF_TYPE
+ A C expression for a string describing the name of the data type
+ to use for the result of subtracting two pointers. The typedef
+ name `ptrdiff_t' is defined using the contents of the string. See
+ `SIZE_TYPE' above for more information.
+
+ If you don't define this macro, the default is `"long int"'.
+
+ -- Macro: WCHAR_TYPE
+ A C expression for a string describing the name of the data type
+ to use for wide characters. The typedef name `wchar_t' is defined
+ using the contents of the string. See `SIZE_TYPE' above for more
+ information.
+
+ If you don't define this macro, the default is `"int"'.
+
+ -- Macro: WCHAR_TYPE_SIZE
+ A C expression for the size in bits of the data type for wide
+ characters. This is used in `cpp', which cannot make use of
+ `WCHAR_TYPE'.
+
+ -- Macro: WINT_TYPE
+ A C expression for a string describing the name of the data type to
+ use for wide characters passed to `printf' and returned from
+ `getwc'. The typedef name `wint_t' is defined using the contents
+ of the string. See `SIZE_TYPE' above for more information.
+
+ If you don't define this macro, the default is `"unsigned int"'.
+
+ -- Macro: INTMAX_TYPE
+ A C expression for a string describing the name of the data type
+ that can represent any value of any standard or extended signed
+ integer type. The typedef name `intmax_t' is defined using the
+ contents of the string. See `SIZE_TYPE' above for more
+ information.
+
+ If you don't define this macro, the default is the first of
+ `"int"', `"long int"', or `"long long int"' that has as much
+ precision as `long long int'.
+
+ -- Macro: UINTMAX_TYPE
+ A C expression for a string describing the name of the data type
+ that can represent any value of any standard or extended unsigned
+ integer type. The typedef name `uintmax_t' is defined using the
+ contents of the string. See `SIZE_TYPE' above for more
+ information.
+
+ If you don't define this macro, the default is the first of
+ `"unsigned int"', `"long unsigned int"', or `"long long unsigned
+ int"' that has as much precision as `long long unsigned int'.
+
+ -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION
+ The C++ compiler represents a pointer-to-member-function with a
+ struct that looks like:
+
+ struct {
+ union {
+ void (*fn)();
+ ptrdiff_t vtable_index;
+ };
+ ptrdiff_t delta;
+ };
+
+ The C++ compiler must use one bit to indicate whether the function
+ that will be called through a pointer-to-member-function is
+ virtual. Normally, we assume that the low-order bit of a function
+ pointer must always be zero. Then, by ensuring that the
+ vtable_index is odd, we can distinguish which variant of the union
+ is in use. But, on some platforms function pointers can be odd,
+ and so this doesn't work. In that case, we use the low-order bit
+ of the `delta' field, and shift the remainder of the `delta' field
+ to the left.
+
+ GCC will automatically make the right selection about where to
+ store this bit using the `FUNCTION_BOUNDARY' setting for your
+ platform. However, some platforms such as ARM/Thumb have
+ `FUNCTION_BOUNDARY' set such that functions always start at even
+ addresses, but the lowest bit of pointers to functions indicate
+ whether the function at that address is in ARM or Thumb mode. If
+ this is the case of your architecture, you should define this
+ macro to `ptrmemfunc_vbit_in_delta'.
+
+ In general, you should not have to define this macro. On
+ architectures in which function addresses are always even,
+ according to `FUNCTION_BOUNDARY', GCC will automatically define
+ this macro to `ptrmemfunc_vbit_in_pfn'.
+
+ -- Macro: TARGET_VTABLE_USES_DESCRIPTORS
+ Normally, the C++ compiler uses function pointers in vtables. This
+ macro allows the target to change to use "function descriptors"
+ instead. Function descriptors are found on targets for whom a
+ function pointer is actually a small data structure. Normally the
+ data structure consists of the actual code address plus a data
+ pointer to which the function's data is relative.
+
+ If vtables are used, the value of this macro should be the number
+ of words that the function descriptor occupies.
+
+ -- Macro: TARGET_VTABLE_ENTRY_ALIGN
+ By default, the vtable entries are void pointers, the so the
+ alignment is the same as pointer alignment. The value of this
+ macro specifies the alignment of the vtable entry in bits. It
+ should be defined only when special alignment is necessary. */
+
+ -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE
+ There are a few non-descriptor entries in the vtable at offsets
+ below zero. If these entries must be padded (say, to preserve the
+ alignment specified by `TARGET_VTABLE_ENTRY_ALIGN'), set this to
+ the number of words in each data entry.
+
+\1f
+File: gccint.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros
+
+17.7 Register Usage
+===================
+
+This section explains how to describe what registers the target machine
+has, and how (in general) they can be used.
+
+ The description of which registers a specific instruction can use is
+done with register classes; see *note Register Classes::. For
+information on using registers to access a stack frame, see *note Frame
+Registers::. For passing values in registers, see *note Register
+Arguments::. For returning values in registers, see *note Scalar
+Return::.
+
+* Menu:
+
+* Register Basics:: Number and kinds of registers.
+* Allocation Order:: Order in which registers are allocated.
+* Values in Registers:: What kinds of values each reg can hold.
+* Leaf Functions:: Renumbering registers for leaf functions.
+* Stack Registers:: Handling a register stack such as 80387.
+
+\1f
+File: gccint.info, Node: Register Basics, Next: Allocation Order, Up: Registers
+
+17.7.1 Basic Characteristics of Registers
+-----------------------------------------
+
+Registers have various characteristics.
+
+ -- Macro: FIRST_PSEUDO_REGISTER
+ Number of hardware registers known to the compiler. They receive
+ numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first
+ pseudo register's number really is assigned the number
+ `FIRST_PSEUDO_REGISTER'.
+
+ -- Macro: FIXED_REGISTERS
+ An initializer that says which registers are used for fixed
+ purposes all throughout the compiled code and are therefore not
+ available for general allocation. These would include the stack
+ pointer, the frame pointer (except on machines where that can be
+ used as a general register when no frame pointer is needed), the
+ program counter on machines where that is considered one of the
+ addressable registers, and any other numbered register with a
+ standard use.
+
+ This information is expressed as a sequence of numbers, separated
+ by commas and surrounded by braces. The Nth number is 1 if
+ register N is fixed, 0 otherwise.
+
+ The table initialized from this macro, and the table initialized by
+ the following one, may be overridden at run time either
+ automatically, by the actions of the macro
+ `CONDITIONAL_REGISTER_USAGE', or by the user with the command
+ options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'.
+
+ -- Macro: CALL_USED_REGISTERS
+ Like `FIXED_REGISTERS' but has 1 for each register that is
+ clobbered (in general) by function calls as well as for fixed
+ registers. This macro therefore identifies the registers that are
+ not available for general allocation of values that must live
+ across function calls.
+
+ If a register has 0 in `CALL_USED_REGISTERS', the compiler
+ automatically saves it on function entry and restores it on
+ function exit, if the register is used within the function.
+
+ -- Macro: CALL_REALLY_USED_REGISTERS
+ Like `CALL_USED_REGISTERS' except this macro doesn't require that
+ the entire set of `FIXED_REGISTERS' be included.
+ (`CALL_USED_REGISTERS' must be a superset of `FIXED_REGISTERS').
+ This macro is optional. If not specified, it defaults to the value
+ of `CALL_USED_REGISTERS'.
+
+ -- Macro: HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE)
+ A C expression that is nonzero if it is not permissible to store a
+ value of mode MODE in hard register number REGNO across a call
+ without some part of it being clobbered. For most machines this
+ macro need not be defined. It is only required for machines that
+ do not preserve the entire contents of a register across a call.
+
+ -- Macro: CONDITIONAL_REGISTER_USAGE
+ Zero or more C statements that may conditionally modify five
+ variables `fixed_regs', `call_used_regs', `global_regs',
+ `reg_names', and `reg_class_contents', to take into account any
+ dependence of these register sets on target flags. The first three
+ of these are of type `char []' (interpreted as Boolean vectors).
+ `global_regs' is a `const char *[]', and `reg_class_contents' is a
+ `HARD_REG_SET'. Before the macro is called, `fixed_regs',
+ `call_used_regs', `reg_class_contents', and `reg_names' have been
+ initialized from `FIXED_REGISTERS', `CALL_USED_REGISTERS',
+ `REG_CLASS_CONTENTS', and `REGISTER_NAMES', respectively.
+ `global_regs' has been cleared, and any `-ffixed-REG',
+ `-fcall-used-REG' and `-fcall-saved-REG' command options have been
+ applied.
+
+ You need not define this macro if it has no work to do.
+
+ If the usage of an entire class of registers depends on the target
+ flags, you may indicate this to GCC by using this macro to modify
+ `fixed_regs' and `call_used_regs' to 1 for each of the registers
+ in the classes which should not be used by GCC. Also define the
+ macro `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' to
+ return `NO_REGS' if it is called with a letter for a class that
+ shouldn't be used.
+
+ (However, if this class is not included in `GENERAL_REGS' and all
+ of the insn patterns whose constraints permit this class are
+ controlled by target switches, then GCC will automatically avoid
+ using these registers when the target switches are opposed to
+ them.)
+
+ -- Macro: INCOMING_REGNO (OUT)
+ Define this macro if the target machine has register windows.
+ This C expression returns the register number as seen by the
+ called function corresponding to the register number OUT as seen
+ by the calling function. Return OUT if register number OUT is not
+ an outbound register.
+
+ -- Macro: OUTGOING_REGNO (IN)
+ Define this macro if the target machine has register windows.
+ This C expression returns the register number as seen by the
+ calling function corresponding to the register number IN as seen
+ by the called function. Return IN if register number IN is not an
+ inbound register.
+
+ -- Macro: LOCAL_REGNO (REGNO)
+ Define this macro if the target machine has register windows.
+ This C expression returns true if the register is call-saved but
+ is in the register window. Unlike most call-saved registers, such
+ registers need not be explicitly restored on function exit or
+ during non-local gotos.
+
+ -- Macro: PC_REGNUM
+ If the program counter has a register number, define this as that
+ register number. Otherwise, do not define it.
+
+\1f
+File: gccint.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers
+
+17.7.2 Order of Allocation of Registers
+---------------------------------------
+
+Registers are allocated in order.
+
+ -- Macro: REG_ALLOC_ORDER
+ If defined, an initializer for a vector of integers, containing the
+ numbers of hard registers in the order in which GCC should prefer
+ to use them (from most preferred to least).
+
+ If this macro is not defined, registers are used lowest numbered
+ first (all else being equal).
+
+ One use of this macro is on machines where the highest numbered
+ registers must always be saved and the save-multiple-registers
+ instruction supports only sequences of consecutive registers. On
+ such machines, define `REG_ALLOC_ORDER' to be an initializer that
+ lists the highest numbered allocable register first.
+
+ -- Macro: ORDER_REGS_FOR_LOCAL_ALLOC
+ A C statement (sans semicolon) to choose the order in which to
+ allocate hard registers for pseudo-registers local to a basic
+ block.
+
+ Store the desired register order in the array `reg_alloc_order'.
+ Element 0 should be the register to allocate first; element 1, the
+ next register; and so on.
+
+ The macro body should not assume anything about the contents of
+ `reg_alloc_order' before execution of the macro.
+
+ On most machines, it is not necessary to define this macro.
+
+ -- Macro: IRA_HARD_REGNO_ADD_COST_MULTIPLIER (REGNO)
+ In some case register allocation order is not enough for the
+ Integrated Register Allocator (IRA) to generate a good code. If
+ this macro is defined, it should return a floating point value
+ based on REGNO. The cost of using REGNO for a pseudo will be
+ increased by approximately the pseudo's usage frequency times the
+ value returned by this macro. Not defining this macro is
+ equivalent to having it always return `0.0'.
+
+ On most machines, it is not necessary to define this macro.
+
+\1f
+File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers
+
+17.7.3 How Values Fit in Registers
+----------------------------------
+
+This section discusses the macros that describe which kinds of values
+(specifically, which machine modes) each register can hold, and how many
+consecutive registers are needed for a given mode.
+
+ -- Macro: HARD_REGNO_NREGS (REGNO, MODE)
+ A C expression for the number of consecutive hard registers,
+ starting at register number REGNO, required to hold a value of mode
+ MODE. This macro must never return zero, even if a register
+ cannot hold the requested mode - indicate that with
+ HARD_REGNO_MODE_OK and/or CANNOT_CHANGE_MODE_CLASS instead.
+
+ On a machine where all registers are exactly one word, a suitable
+ definition of this macro is
+
+ #define HARD_REGNO_NREGS(REGNO, MODE) \
+ ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
+ / UNITS_PER_WORD)
+
+ -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE)
+ A C expression that is nonzero if a value of mode MODE, stored in
+ memory, ends with padding that causes it to take up more space than
+ in registers starting at register number REGNO (as determined by
+ multiplying GCC's notion of the size of the register when
+ containing this mode by the number of registers returned by
+ `HARD_REGNO_NREGS'). By default this is zero.
+
+ For example, if a floating-point value is stored in three 32-bit
+ registers but takes up 128 bits in memory, then this would be
+ nonzero.
+
+ This macros only needs to be defined if there are cases where
+ `subreg_get_info' would otherwise wrongly determine that a
+ `subreg' can be represented by an offset to the register number,
+ when in fact such a `subreg' would contain some of the padding not
+ stored in registers and so not be representable.
+
+ -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE)
+ For values of REGNO and MODE for which
+ `HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression
+ returning the greater number of registers required to hold the
+ value including any padding. In the example above, the value
+ would be four.
+
+ -- Macro: REGMODE_NATURAL_SIZE (MODE)
+ Define this macro if the natural size of registers that hold values
+ of mode MODE is not the word size. It is a C expression that
+ should give the natural size in bytes for the specified mode. It
+ is used by the register allocator to try to optimize its results.
+ This happens for example on SPARC 64-bit where the natural size of
+ floating-point registers is still 32-bit.
+
+ -- Macro: HARD_REGNO_MODE_OK (REGNO, MODE)
+ A C expression that is nonzero if it is permissible to store a
+ value of mode MODE in hard register number REGNO (or in several
+ registers starting with that one). For a machine where all
+ registers are equivalent, a suitable definition is
+
+ #define HARD_REGNO_MODE_OK(REGNO, MODE) 1
+
+ You need not include code to check for the numbers of fixed
+ registers, because the allocation mechanism considers them to be
+ always occupied.
+
+ On some machines, double-precision values must be kept in even/odd
+ register pairs. You can implement that by defining this macro to
+ reject odd register numbers for such modes.
+
+ The minimum requirement for a mode to be OK in a register is that
+ the `movMODE' instruction pattern support moves between the
+ register and other hard register in the same class and that moving
+ a value into the register and back out not alter it.
+
+ Since the same instruction used to move `word_mode' will work for
+ all narrower integer modes, it is not necessary on any machine for
+ `HARD_REGNO_MODE_OK' to distinguish between these modes, provided
+ you define patterns `movhi', etc., to take advantage of this. This
+ is useful because of the interaction between `HARD_REGNO_MODE_OK'
+ and `MODES_TIEABLE_P'; it is very desirable for all integer modes
+ to be tieable.
+
+ Many machines have special registers for floating point arithmetic.
+ Often people assume that floating point machine modes are allowed
+ only in floating point registers. This is not true. Any
+ registers that can hold integers can safely _hold_ a floating
+ point machine mode, whether or not floating arithmetic can be done
+ on it in those registers. Integer move instructions can be used
+ to move the values.
+
+ On some machines, though, the converse is true: fixed-point machine
+ modes may not go in floating registers. This is true if the
+ floating registers normalize any value stored in them, because
+ storing a non-floating value there would garble it. In this case,
+ `HARD_REGNO_MODE_OK' should reject fixed-point machine modes in
+ floating registers. But if the floating registers do not
+ automatically normalize, if you can store any bit pattern in one
+ and retrieve it unchanged without a trap, then any machine mode
+ may go in a floating register, so you can define this macro to say
+ so.
+
+ The primary significance of special floating registers is rather
+ that they are the registers acceptable in floating point arithmetic
+ instructions. However, this is of no concern to
+ `HARD_REGNO_MODE_OK'. You handle it by writing the proper
+ constraints for those instructions.
+
+ On some machines, the floating registers are especially slow to
+ access, so that it is better to store a value in a stack frame
+ than in such a register if floating point arithmetic is not being
+ done. As long as the floating registers are not in class
+ `GENERAL_REGS', they will not be used unless some pattern's
+ constraint asks for one.
+
+ -- Macro: HARD_REGNO_RENAME_OK (FROM, TO)
+ A C expression that is nonzero if it is OK to rename a hard
+ register FROM to another hard register TO.
+
+ One common use of this macro is to prevent renaming of a register
+ to another register that is not saved by a prologue in an interrupt
+ handler.
+
+ The default is always nonzero.
+
+ -- Macro: MODES_TIEABLE_P (MODE1, MODE2)
+ A C expression that is nonzero if a value of mode MODE1 is
+ accessible in mode MODE2 without copying.
+
+ If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R,
+ MODE2)' are always the same for any R, then `MODES_TIEABLE_P
+ (MODE1, MODE2)' should be nonzero. If they differ for any R, you
+ should define this macro to return zero unless some other
+ mechanism ensures the accessibility of the value in a narrower
+ mode.
+
+ You should define this macro to return nonzero in as many cases as
+ possible since doing so will allow GCC to perform better register
+ allocation.
+
+ -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO)
+ This target hook should return `true' if it is OK to use a hard
+ register REGNO as scratch reg in peephole2.
+
+ One common use of this macro is to prevent using of a register that
+ is not saved by a prologue in an interrupt handler.
+
+ The default version of this hook always returns `true'.
+
+ -- Macro: AVOID_CCMODE_COPIES
+ Define this macro if the compiler should avoid copies to/from
+ `CCmode' registers. You should only define this macro if support
+ for copying to/from `CCmode' is incomplete.
+
+\1f
+File: gccint.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers
+
+17.7.4 Handling Leaf Functions
+------------------------------
+
+On some machines, a leaf function (i.e., one which makes no calls) can
+run more efficiently if it does not make its own register window.
+Often this means it is required to receive its arguments in the
+registers where they are passed by the caller, instead of the registers
+where they would normally arrive.
+
+ The special treatment for leaf functions generally applies only when
+other conditions are met; for example, often they may use only those
+registers for its own variables and temporaries. We use the term "leaf
+function" to mean a function that is suitable for this special
+handling, so that functions with no calls are not necessarily "leaf
+functions".
+
+ GCC assigns register numbers before it knows whether the function is
+suitable for leaf function treatment. So it needs to renumber the
+registers in order to output a leaf function. The following macros
+accomplish this.
+
+ -- Macro: LEAF_REGISTERS
+ Name of a char vector, indexed by hard register number, which
+ contains 1 for a register that is allowable in a candidate for leaf
+ function treatment.
+
+ If leaf function treatment involves renumbering the registers,
+ then the registers marked here should be the ones before
+ renumbering--those that GCC would ordinarily allocate. The
+ registers which will actually be used in the assembler code, after
+ renumbering, should not be marked with 1 in this vector.
+
+ Define this macro only if the target machine offers a way to
+ optimize the treatment of leaf functions.
+
+ -- Macro: LEAF_REG_REMAP (REGNO)
+ A C expression whose value is the register number to which REGNO
+ should be renumbered, when a function is treated as a leaf
+ function.
+
+ If REGNO is a register number which should not appear in a leaf
+ function before renumbering, then the expression should yield -1,
+ which will cause the compiler to abort.
+
+ Define this macro only if the target machine offers a way to
+ optimize the treatment of leaf functions, and registers need to be
+ renumbered to do this.
+
+ `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE' must
+usually treat leaf functions specially. They can test the C variable
+`current_function_is_leaf' which is nonzero for leaf functions.
+`current_function_is_leaf' is set prior to local register allocation
+and is valid for the remaining compiler passes. They can also test the
+C variable `current_function_uses_only_leaf_regs' which is nonzero for
+leaf functions which only use leaf registers.
+`current_function_uses_only_leaf_regs' is valid after all passes that
+modify the instructions have been run and is only useful if
+`LEAF_REGISTERS' is defined.
+
+\1f
+File: gccint.info, Node: Stack Registers, Prev: Leaf Functions, Up: Registers
+
+17.7.5 Registers That Form a Stack
+----------------------------------
+
+There are special features to handle computers where some of the
+"registers" form a stack. Stack registers are normally written by
+pushing onto the stack, and are numbered relative to the top of the
+stack.
+
+ Currently, GCC can only handle one group of stack-like registers, and
+they must be consecutively numbered. Furthermore, the existing support
+for stack-like registers is specific to the 80387 floating point
+coprocessor. If you have a new architecture that uses stack-like
+registers, you will need to do substantial work on `reg-stack.c' and
+write your machine description to cooperate with it, as well as
+defining these macros.
+
+ -- Macro: STACK_REGS
+ Define this if the machine has any stack-like registers.
+
+ -- Macro: FIRST_STACK_REG
+ The number of the first stack-like register. This one is the top
+ of the stack.
+
+ -- Macro: LAST_STACK_REG
+ The number of the last stack-like register. This one is the
+ bottom of the stack.
+
+\1f
+File: gccint.info, Node: Register Classes, Next: Old Constraints, Prev: Registers, Up: Target Macros
+
+17.8 Register Classes
+=====================
+
+On many machines, the numbered registers are not all equivalent. For
+example, certain registers may not be allowed for indexed addressing;
+certain registers may not be allowed in some instructions. These
+machine restrictions are described to the compiler using "register
+classes".
+
+ You define a number of register classes, giving each one a name and
+saying which of the registers belong to it. Then you can specify
+register classes that are allowed as operands to particular instruction
+patterns.
+
+ In general, each register will belong to several classes. In fact, one
+class must be named `ALL_REGS' and contain all the registers. Another
+class must be named `NO_REGS' and contain no registers. Often the
+union of two classes will be another class; however, this is not
+required.
+
+ One of the classes must be named `GENERAL_REGS'. There is nothing
+terribly special about the name, but the operand constraint letters `r'
+and `g' specify this class. If `GENERAL_REGS' is the same as
+`ALL_REGS', just define it as a macro which expands to `ALL_REGS'.
+
+ Order the classes so that if class X is contained in class Y then X
+has a lower class number than Y.
+
+ The way classes other than `GENERAL_REGS' are specified in operand
+constraints is through machine-dependent operand constraint letters.
+You can define such letters to correspond to various classes, then use
+them in operand constraints.
+
+ You should define a class for the union of two classes whenever some
+instruction allows both classes. For example, if an instruction allows
+either a floating point (coprocessor) register or a general register
+for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS'
+which includes both of them. Otherwise you will get suboptimal code.
+
+ You must also specify certain redundant information about the register
+classes: for each class, which classes contain it and which ones are
+contained in it; for each pair of classes, the largest class contained
+in their union.
+
+ When a value occupying several consecutive registers is expected in a
+certain class, all the registers used must belong to that class.
+Therefore, register classes cannot be used to enforce a requirement for
+a register pair to start with an even-numbered register. The way to
+specify this requirement is with `HARD_REGNO_MODE_OK'.
+
+ Register classes used for input-operands of bitwise-and or shift
+instructions have a special requirement: each such class must have, for
+each fixed-point machine mode, a subclass whose registers can transfer
+that mode to or from memory. For example, on some machines, the
+operations for single-byte values (`QImode') are limited to certain
+registers. When this is so, each register class that is used in a
+bitwise-and or shift instruction must have a subclass consisting of
+registers from which single-byte values can be loaded or stored. This
+is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to
+return.
+
+ -- Data type: enum reg_class
+ An enumerated type that must be defined with all the register
+ class names as enumerated values. `NO_REGS' must be first.
+ `ALL_REGS' must be the last register class, followed by one more
+ enumerated value, `LIM_REG_CLASSES', which is not a register class
+ but rather tells how many classes there are.
+
+ Each register class has a number, which is the value of casting
+ the class name to type `int'. The number serves as an index in
+ many of the tables described below.
+
+ -- Macro: N_REG_CLASSES
+ The number of distinct register classes, defined as follows:
+
+ #define N_REG_CLASSES (int) LIM_REG_CLASSES
+
+ -- Macro: REG_CLASS_NAMES
+ An initializer containing the names of the register classes as C
+ string constants. These names are used in writing some of the
+ debugging dumps.
+
+ -- Macro: REG_CLASS_CONTENTS
+ An initializer containing the contents of the register classes, as
+ integers which are bit masks. The Nth integer specifies the
+ contents of class N. The way the integer MASK is interpreted is
+ that register R is in the class if `MASK & (1 << R)' is 1.
+
+ When the machine has more than 32 registers, an integer does not
+ suffice. Then the integers are replaced by sub-initializers,
+ braced groupings containing several integers. Each
+ sub-initializer must be suitable as an initializer for the type
+ `HARD_REG_SET' which is defined in `hard-reg-set.h'. In this
+ situation, the first integer in each sub-initializer corresponds to
+ registers 0 through 31, the second integer to registers 32 through
+ 63, and so on.
+
+ -- Macro: REGNO_REG_CLASS (REGNO)
+ A C expression whose value is a register class containing hard
+ register REGNO. In general there is more than one such class;
+ choose a class which is "minimal", meaning that no smaller class
+ also contains the register.
+
+ -- Macro: BASE_REG_CLASS
+ A macro whose definition is the name of the class to which a valid
+ base register must belong. A base register is one used in an
+ address which is the register value plus a displacement.
+
+ -- Macro: MODE_BASE_REG_CLASS (MODE)
+ This is a variation of the `BASE_REG_CLASS' macro which allows the
+ selection of a base register in a mode dependent manner. If MODE
+ is VOIDmode then it should return the same value as
+ `BASE_REG_CLASS'.
+
+ -- Macro: MODE_BASE_REG_REG_CLASS (MODE)
+ A C expression whose value is the register class to which a valid
+ base register must belong in order to be used in a base plus index
+ register address. You should define this macro if base plus index
+ addresses have different requirements than other base register
+ uses.
+
+ -- Macro: MODE_CODE_BASE_REG_CLASS (MODE, OUTER_CODE, INDEX_CODE)
+ A C expression whose value is the register class to which a valid
+ base register must belong. OUTER_CODE and INDEX_CODE define the
+ context in which the base register occurs. OUTER_CODE is the code
+ of the immediately enclosing expression (`MEM' for the top level
+ of an address, `ADDRESS' for something that occurs in an
+ `address_operand'). INDEX_CODE is the code of the corresponding
+ index expression if OUTER_CODE is `PLUS'; `SCRATCH' otherwise.
+
+ -- Macro: INDEX_REG_CLASS
+ A macro whose definition is the name of the class to which a valid
+ index register must belong. An index register is one used in an
+ address where its value is either multiplied by a scale factor or
+ added to another register (as well as added to a displacement).
+
+ -- Macro: REGNO_OK_FOR_BASE_P (NUM)
+ A C expression which is nonzero if register number NUM is suitable
+ for use as a base register in operand addresses. It may be either
+ a suitable hard register or a pseudo register that has been
+ allocated such a hard register.
+
+ -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE)
+ A C expression that is just like `REGNO_OK_FOR_BASE_P', except that
+ that expression may examine the mode of the memory reference in
+ MODE. You should define this macro if the mode of the memory
+ reference affects whether a register may be used as a base
+ register. If you define this macro, the compiler will use it
+ instead of `REGNO_OK_FOR_BASE_P'. The mode may be `VOIDmode' for
+ addresses that appear outside a `MEM', i.e., as an
+ `address_operand'.
+
+
+ -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE)
+ A C expression which is nonzero if register number NUM is suitable
+ for use as a base register in base plus index operand addresses,
+ accessing memory in mode MODE. It may be either a suitable hard
+ register or a pseudo register that has been allocated such a hard
+ register. You should define this macro if base plus index
+ addresses have different requirements than other base register
+ uses.
+
+ Use of this macro is deprecated; please use the more general
+ `REGNO_MODE_CODE_OK_FOR_BASE_P'.
+
+ -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, OUTER_CODE,
+ INDEX_CODE)
+ A C expression that is just like `REGNO_MODE_OK_FOR_BASE_P', except
+ that that expression may examine the context in which the register
+ appears in the memory reference. OUTER_CODE is the code of the
+ immediately enclosing expression (`MEM' if at the top level of the
+ address, `ADDRESS' for something that occurs in an
+ `address_operand'). INDEX_CODE is the code of the corresponding
+ index expression if OUTER_CODE is `PLUS'; `SCRATCH' otherwise.
+ The mode may be `VOIDmode' for addresses that appear outside a
+ `MEM', i.e., as an `address_operand'.
+
+ -- Macro: REGNO_OK_FOR_INDEX_P (NUM)
+ A C expression which is nonzero if register number NUM is suitable
+ for use as an index register in operand addresses. It may be
+ either a suitable hard register or a pseudo register that has been
+ allocated such a hard register.
+
+ The difference between an index register and a base register is
+ that the index register may be scaled. If an address involves the
+ sum of two registers, neither one of them scaled, then either one
+ may be labeled the "base" and the other the "index"; but whichever
+ labeling is used must fit the machine's constraints of which
+ registers may serve in each capacity. The compiler will try both
+ labelings, looking for one that is valid, and will reload one or
+ both registers only if neither labeling works.
+
+ -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS)
+ A C expression that places additional restrictions on the register
+ class to use when it is necessary to copy value X into a register
+ in class CLASS. The value is a register class; perhaps CLASS, or
+ perhaps another, smaller class. On many machines, the following
+ definition is safe:
+
+ #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
+
+ Sometimes returning a more restrictive class makes better code.
+ For example, on the 68000, when X is an integer constant that is
+ in range for a `moveq' instruction, the value of this macro is
+ always `DATA_REGS' as long as CLASS includes the data registers.
+ Requiring a data register guarantees that a `moveq' will be used.
+
+ One case where `PREFERRED_RELOAD_CLASS' must not return CLASS is
+ if X is a legitimate constant which cannot be loaded into some
+ register class. By returning `NO_REGS' you can force X into a
+ memory location. For example, rs6000 can load immediate values
+ into general-purpose registers, but does not have an instruction
+ for loading an immediate value into a floating-point register, so
+ `PREFERRED_RELOAD_CLASS' returns `NO_REGS' when X is a
+ floating-point constant. If the constant can't be loaded into any
+ kind of register, code generation will be better if
+ `LEGITIMATE_CONSTANT_P' makes the constant illegitimate instead of
+ using `PREFERRED_RELOAD_CLASS'.
+
+ If an insn has pseudos in it after register allocation, reload
+ will go through the alternatives and call repeatedly
+ `PREFERRED_RELOAD_CLASS' to find the best one. Returning
+ `NO_REGS', in this case, makes reload add a `!' in front of the
+ constraint: the x86 back-end uses this feature to discourage usage
+ of 387 registers when math is done in the SSE registers (and vice
+ versa).
+
+ -- Macro: PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS)
+ Like `PREFERRED_RELOAD_CLASS', but for output reloads instead of
+ input reloads. If you don't define this macro, the default is to
+ use CLASS, unchanged.
+
+ You can also use `PREFERRED_OUTPUT_RELOAD_CLASS' to discourage
+ reload from using some alternatives, like `PREFERRED_RELOAD_CLASS'.
+
+ -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS)
+ A C expression that places additional restrictions on the register
+ class to use when it is necessary to be able to hold a value of
+ mode MODE in a reload register for which class CLASS would
+ ordinarily be used.
+
+ Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when
+ there are certain modes that simply can't go in certain reload
+ classes.
+
+ The value is a register class; perhaps CLASS, or perhaps another,
+ smaller class.
+
+ Don't define this macro unless the target machine has limitations
+ which require the macro to do something nontrivial.
+
+ -- Target Hook: enum reg_class TARGET_SECONDARY_RELOAD (bool IN_P, rtx
+ X, enum reg_class RELOAD_CLASS, enum machine_mode
+ RELOAD_MODE, secondary_reload_info *SRI)
+ Many machines have some registers that cannot be copied directly
+ to or from memory or even from other types of registers. An
+ example is the `MQ' register, which on most machines, can only be
+ copied to or from general registers, but not memory. Below, we
+ shall be using the term 'intermediate register' when a move
+ operation cannot be performed directly, but has to be done by
+ copying the source into the intermediate register first, and then
+ copying the intermediate register to the destination. An
+ intermediate register always has the same mode as source and
+ destination. Since it holds the actual value being copied, reload
+ might apply optimizations to re-use an intermediate register and
+ eliding the copy from the source when it can determine that the
+ intermediate register still holds the required value.
+
+ Another kind of secondary reload is required on some machines which
+ allow copying all registers to and from memory, but require a
+ scratch register for stores to some memory locations (e.g., those
+ with symbolic address on the RT, and those with certain symbolic
+ address on the SPARC when compiling PIC). Scratch registers need
+ not have the same mode as the value being copied, and usually hold
+ a different value that that being copied. Special patterns in the
+ md file are needed to describe how the copy is performed with the
+ help of the scratch register; these patterns also describe the
+ number, register class(es) and mode(s) of the scratch register(s).
+
+ In some cases, both an intermediate and a scratch register are
+ required.
+
+ For input reloads, this target hook is called with nonzero IN_P,
+ and X is an rtx that needs to be copied to a register of class
+ RELOAD_CLASS in RELOAD_MODE. For output reloads, this target hook
+ is called with zero IN_P, and a register of class RELOAD_CLASS
+ needs to be copied to rtx X in RELOAD_MODE.
+
+ If copying a register of RELOAD_CLASS from/to X requires an
+ intermediate register, the hook `secondary_reload' should return
+ the register class required for this intermediate register. If no
+ intermediate register is required, it should return NO_REGS. If
+ more than one intermediate register is required, describe the one
+ that is closest in the copy chain to the reload register.
+
+ If scratch registers are needed, you also have to describe how to
+ perform the copy from/to the reload register to/from this closest
+ intermediate register. Or if no intermediate register is
+ required, but still a scratch register is needed, describe the
+ copy from/to the reload register to/from the reload operand X.
+
+ You do this by setting `sri->icode' to the instruction code of a
+ pattern in the md file which performs the move. Operands 0 and 1
+ are the output and input of this copy, respectively. Operands
+ from operand 2 onward are for scratch operands. These scratch
+ operands must have a mode, and a single-register-class output
+ constraint.
+
+ When an intermediate register is used, the `secondary_reload' hook
+ will be called again to determine how to copy the intermediate
+ register to/from the reload operand X, so your hook must also have
+ code to handle the register class of the intermediate operand.
+
+ X might be a pseudo-register or a `subreg' of a pseudo-register,
+ which could either be in a hard register or in memory. Use
+ `true_regnum' to find out; it will return -1 if the pseudo is in
+ memory and the hard register number if it is in a register.
+
+ Scratch operands in memory (constraint `"=m"' / `"=&m"') are
+ currently not supported. For the time being, you will have to
+ continue to use `SECONDARY_MEMORY_NEEDED' for that purpose.
+
+ `copy_cost' also uses this target hook to find out how values are
+ copied. If you want it to include some extra cost for the need to
+ allocate (a) scratch register(s), set `sri->extra_cost' to the
+ additional cost. Or if two dependent moves are supposed to have a
+ lower cost than the sum of the individual moves due to expected
+ fortuitous scheduling and/or special forwarding logic, you can set
+ `sri->extra_cost' to a negative amount.
+
+ -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X)
+ -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)
+ -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)
+ These macros are obsolete, new ports should use the target hook
+ `TARGET_SECONDARY_RELOAD' instead.
+
+ These are obsolete macros, replaced by the
+ `TARGET_SECONDARY_RELOAD' target hook. Older ports still define
+ these macros to indicate to the reload phase that it may need to
+ allocate at least one register for a reload in addition to the
+ register to contain the data. Specifically, if copying X to a
+ register CLASS in MODE requires an intermediate register, you were
+ supposed to define `SECONDARY_INPUT_RELOAD_CLASS' to return the
+ largest register class all of whose registers can be used as
+ intermediate registers or scratch registers.
+
+ If copying a register CLASS in MODE to X requires an intermediate
+ or scratch register, `SECONDARY_OUTPUT_RELOAD_CLASS' was supposed
+ to be defined be defined to return the largest register class
+ required. If the requirements for input and output reloads were
+ the same, the macro `SECONDARY_RELOAD_CLASS' should have been used
+ instead of defining both macros identically.
+
+ The values returned by these macros are often `GENERAL_REGS'.
+ Return `NO_REGS' if no spare register is needed; i.e., if X can be
+ directly copied to or from a register of CLASS in MODE without
+ requiring a scratch register. Do not define this macro if it
+ would always return `NO_REGS'.
+
+ If a scratch register is required (either with or without an
+ intermediate register), you were supposed to define patterns for
+ `reload_inM' or `reload_outM', as required (*note Standard
+ Names::. These patterns, which were normally implemented with a
+ `define_expand', should be similar to the `movM' patterns, except
+ that operand 2 is the scratch register.
+
+ These patterns need constraints for the reload register and scratch
+ register that contain a single register class. If the original
+ reload register (whose class is CLASS) can meet the constraint
+ given in the pattern, the value returned by these macros is used
+ for the class of the scratch register. Otherwise, two additional
+ reload registers are required. Their classes are obtained from
+ the constraints in the insn pattern.
+
+ X might be a pseudo-register or a `subreg' of a pseudo-register,
+ which could either be in a hard register or in memory. Use
+ `true_regnum' to find out; it will return -1 if the pseudo is in
+ memory and the hard register number if it is in a register.
+
+ These macros should not be used in the case where a particular
+ class of registers can only be copied to memory and not to another
+ class of registers. In that case, secondary reload registers are
+ not needed and would not be helpful. Instead, a stack location
+ must be used to perform the copy and the `movM' pattern should use
+ memory as an intermediate storage. This case often occurs between
+ floating-point and general registers.
+
+ -- Macro: SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M)
+ Certain machines have the property that some registers cannot be
+ copied to some other registers without using memory. Define this
+ macro on those machines to be a C expression that is nonzero if
+ objects of mode M in registers of CLASS1 can only be copied to
+ registers of class CLASS2 by storing a register of CLASS1 into
+ memory and loading that memory location into a register of CLASS2.
+
+ Do not define this macro if its value would always be zero.
+
+ -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE)
+ Normally when `SECONDARY_MEMORY_NEEDED' is defined, the compiler
+ allocates a stack slot for a memory location needed for register
+ copies. If this macro is defined, the compiler instead uses the
+ memory location defined by this macro.
+
+ Do not define this macro if you do not define
+ `SECONDARY_MEMORY_NEEDED'.
+
+ -- Macro: SECONDARY_MEMORY_NEEDED_MODE (MODE)
+ When the compiler needs a secondary memory location to copy
+ between two registers of mode MODE, it normally allocates
+ sufficient memory to hold a quantity of `BITS_PER_WORD' bits and
+ performs the store and load operations in a mode that many bits
+ wide and whose class is the same as that of MODE.
+
+ This is right thing to do on most machines because it ensures that
+ all bits of the register are copied and prevents accesses to the
+ registers in a narrower mode, which some machines prohibit for
+ floating-point registers.
+
+ However, this default behavior is not correct on some machines,
+ such as the DEC Alpha, that store short integers in floating-point
+ registers differently than in integer registers. On those
+ machines, the default widening will not work correctly and you
+ must define this macro to suppress that widening in some cases.
+ See the file `alpha.h' for details.
+
+ Do not define this macro if you do not define
+ `SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is
+ `BITS_PER_WORD' bits wide is correct for your machine.
+
+ -- Macro: SMALL_REGISTER_CLASSES
+ On some machines, it is risky to let hard registers live across
+ arbitrary insns. Typically, these machines have instructions that
+ require values to be in specific registers (like an accumulator),
+ and reload will fail if the required hard register is used for
+ another purpose across such an insn.
+
+ Define `SMALL_REGISTER_CLASSES' to be an expression with a nonzero
+ value on these machines. When this macro has a nonzero value, the
+ compiler will try to minimize the lifetime of hard registers.
+
+ It is always safe to define this macro with a nonzero value, but
+ if you unnecessarily define it, you will reduce the amount of
+ optimizations that can be performed in some cases. If you do not
+ define this macro with a nonzero value when it is required, the
+ compiler will run out of spill registers and print a fatal error
+ message. For most machines, you should not define this macro at
+ all.
+
+ -- Macro: CLASS_LIKELY_SPILLED_P (CLASS)
+ A C expression whose value is nonzero if pseudos that have been
+ assigned to registers of class CLASS would likely be spilled
+ because registers of CLASS are needed for spill registers.
+
+ The default value of this macro returns 1 if CLASS has exactly one
+ register and zero otherwise. On most machines, this default
+ should be used. Only define this macro to some other expression
+ if pseudos allocated by `local-alloc.c' end up in memory because
+ their hard registers were needed for spill registers. If this
+ macro returns nonzero for those classes, those pseudos will only
+ be allocated by `global.c', which knows how to reallocate the
+ pseudo to another register. If there would not be another
+ register available for reallocation, you should not change the
+ definition of this macro since the only effect of such a
+ definition would be to slow down register allocation.
+
+ -- Macro: CLASS_MAX_NREGS (CLASS, MODE)
+ A C expression for the maximum number of consecutive registers of
+ class CLASS needed to hold a value of mode MODE.
+
+ This is closely related to the macro `HARD_REGNO_NREGS'. In fact,
+ the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be
+ the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all
+ REGNO values in the class CLASS.
+
+ This macro helps control the handling of multiple-word values in
+ the reload pass.
+
+ -- Macro: CANNOT_CHANGE_MODE_CLASS (FROM, TO, CLASS)
+ If defined, a C expression that returns nonzero for a CLASS for
+ which a change from mode FROM to mode TO is invalid.
+
+ For the example, loading 32-bit integer or floating-point objects
+ into floating-point registers on the Alpha extends them to 64 bits.
+ Therefore loading a 64-bit object and then storing it as a 32-bit
+ object does not store the low-order 32 bits, as would be the case
+ for a normal register. Therefore, `alpha.h' defines
+ `CANNOT_CHANGE_MODE_CLASS' as below:
+
+ #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \
+ (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \
+ ? reg_classes_intersect_p (FLOAT_REGS, (CLASS)) : 0)
+
+ -- Target Hook: const enum reg_class * TARGET_IRA_COVER_CLASSES ()
+ Return an array of cover classes for the Integrated Register
+ Allocator (IRA). Cover classes are a set of non-intersecting
+ register classes covering all hard registers used for register
+ allocation purposes. If a move between two registers in the same
+ cover class is possible, it should be cheaper than a load or store
+ of the registers. The array is terminated by a `LIM_REG_CLASSES'
+ element.
+
+ This hook is called once at compiler startup, after the
+ command-line options have been processed. It is then re-examined
+ by every call to `target_reinit'.
+
+ The default implementation returns `IRA_COVER_CLASSES', if defined,
+ otherwise there is no default implementation. You must define
+ either this macro or `IRA_COVER_CLASSES' in order to use the
+ integrated register allocator with Chaitin-Briggs coloring. If the
+ macro is not defined, the only available coloring algorithm is
+ Chow's priority coloring.
+
+ -- Macro: IRA_COVER_CLASSES
+ See the documentation for `TARGET_IRA_COVER_CLASSES'.
+
+\1f
+File: gccint.info, Node: Old Constraints, Next: Stack and Calling, Prev: Register Classes, Up: Target Macros
+
+17.9 Obsolete Macros for Defining Constraints
+=============================================
+
+Machine-specific constraints can be defined with these macros instead
+of the machine description constructs described in *note Define
+Constraints::. This mechanism is obsolete. New ports should not use
+it; old ports should convert to the new mechanism.
+
+ -- Macro: CONSTRAINT_LEN (CHAR, STR)
+ For the constraint at the start of STR, which starts with the
+ letter C, return the length. This allows you to have register
+ class / constant / extra constraints that are longer than a single
+ letter; you don't need to define this macro if you can do with
+ single-letter constraints only. The definition of this macro
+ should use DEFAULT_CONSTRAINT_LEN for all the characters that you
+ don't want to handle specially. There are some sanity checks in
+ genoutput.c that check the constraint lengths for the md file, so
+ you can also use this macro to help you while you are
+ transitioning from a byzantine single-letter-constraint scheme:
+ when you return a negative length for a constraint you want to
+ re-use, genoutput will complain about every instance where it is
+ used in the md file.
+
+ -- Macro: REG_CLASS_FROM_LETTER (CHAR)
+ A C expression which defines the machine-dependent operand
+ constraint letters for register classes. If CHAR is such a
+ letter, the value should be the register class corresponding to
+ it. Otherwise, the value should be `NO_REGS'. The register
+ letter `r', corresponding to class `GENERAL_REGS', will not be
+ passed to this macro; you do not need to handle it.
+
+ -- Macro: REG_CLASS_FROM_CONSTRAINT (CHAR, STR)
+ Like `REG_CLASS_FROM_LETTER', but you also get the constraint
+ string passed in STR, so that you can use suffixes to distinguish
+ between different variants.
+
+ -- Macro: CONST_OK_FOR_LETTER_P (VALUE, C)
+ A C expression that defines the machine-dependent operand
+ constraint letters (`I', `J', `K', ... `P') that specify
+ particular ranges of integer values. If C is one of those
+ letters, the expression should check that VALUE, an integer, is in
+ the appropriate range and return 1 if so, 0 otherwise. If C is
+ not one of those letters, the value should be 0 regardless of
+ VALUE.
+
+ -- Macro: CONST_OK_FOR_CONSTRAINT_P (VALUE, C, STR)
+ Like `CONST_OK_FOR_LETTER_P', but you also get the constraint
+ string passed in STR, so that you can use suffixes to distinguish
+ between different variants.
+
+ -- Macro: CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)
+ A C expression that defines the machine-dependent operand
+ constraint letters that specify particular ranges of
+ `const_double' values (`G' or `H').
+
+ If C is one of those letters, the expression should check that
+ VALUE, an RTX of code `const_double', is in the appropriate range
+ and return 1 if so, 0 otherwise. If C is not one of those
+ letters, the value should be 0 regardless of VALUE.
+
+ `const_double' is used for all floating-point constants and for
+ `DImode' fixed-point constants. A given letter can accept either
+ or both kinds of values. It can use `GET_MODE' to distinguish
+ between these kinds.
+
+ -- Macro: CONST_DOUBLE_OK_FOR_CONSTRAINT_P (VALUE, C, STR)
+ Like `CONST_DOUBLE_OK_FOR_LETTER_P', but you also get the
+ constraint string passed in STR, so that you can use suffixes to
+ distinguish between different variants.
+
+ -- Macro: EXTRA_CONSTRAINT (VALUE, C)
+ A C expression that defines the optional machine-dependent
+ constraint letters that can be used to segregate specific types of
+ operands, usually memory references, for the target machine. Any
+ letter that is not elsewhere defined and not matched by
+ `REG_CLASS_FROM_LETTER' / `REG_CLASS_FROM_CONSTRAINT' may be used.
+ Normally this macro will not be defined.
+
+ If it is required for a particular target machine, it should
+ return 1 if VALUE corresponds to the operand type represented by
+ the constraint letter C. If C is not defined as an extra
+ constraint, the value returned should be 0 regardless of VALUE.
+
+ For example, on the ROMP, load instructions cannot have their
+ output in r0 if the memory reference contains a symbolic address.
+ Constraint letter `Q' is defined as representing a memory address
+ that does _not_ contain a symbolic address. An alternative is
+ specified with a `Q' constraint on the input and `r' on the
+ output. The next alternative specifies `m' on the input and a
+ register class that does not include r0 on the output.
+
+ -- Macro: EXTRA_CONSTRAINT_STR (VALUE, C, STR)
+ Like `EXTRA_CONSTRAINT', but you also get the constraint string
+ passed in STR, so that you can use suffixes to distinguish between
+ different variants.
+
+ -- Macro: EXTRA_MEMORY_CONSTRAINT (C, STR)
+ A C expression that defines the optional machine-dependent
+ constraint letters, amongst those accepted by `EXTRA_CONSTRAINT',
+ that should be treated like memory constraints by the reload pass.
+
+ It should return 1 if the operand type represented by the
+ constraint at the start of STR, the first letter of which is the
+ letter C, comprises a subset of all memory references including
+ all those whose address is simply a base register. This allows
+ the reload pass to reload an operand, if it does not directly
+ correspond to the operand type of C, by copying its address into a
+ base register.
+
+ For example, on the S/390, some instructions do not accept
+ arbitrary memory references, but only those that do not make use
+ of an index register. The constraint letter `Q' is defined via
+ `EXTRA_CONSTRAINT' as representing a memory address of this type.
+ If the letter `Q' is marked as `EXTRA_MEMORY_CONSTRAINT', a `Q'
+ constraint can handle any memory operand, because the reload pass
+ knows it can be reloaded by copying the memory address into a base
+ register if required. This is analogous to the way a `o'
+ constraint can handle any memory operand.
+
+ -- Macro: EXTRA_ADDRESS_CONSTRAINT (C, STR)
+ A C expression that defines the optional machine-dependent
+ constraint letters, amongst those accepted by `EXTRA_CONSTRAINT' /
+ `EXTRA_CONSTRAINT_STR', that should be treated like address
+ constraints by the reload pass.
+
+ It should return 1 if the operand type represented by the
+ constraint at the start of STR, which starts with the letter C,
+ comprises a subset of all memory addresses including all those
+ that consist of just a base register. This allows the reload pass
+ to reload an operand, if it does not directly correspond to the
+ operand type of STR, by copying it into a base register.
+
+ Any constraint marked as `EXTRA_ADDRESS_CONSTRAINT' can only be
+ used with the `address_operand' predicate. It is treated
+ analogously to the `p' constraint.
+
+\1f
+File: gccint.info, Node: Stack and Calling, Next: Varargs, Prev: Old Constraints, Up: Target Macros
+
+17.10 Stack Layout and Calling Conventions
+==========================================
+
+This describes the stack layout and calling conventions.
+
+* Menu:
+
+* Frame Layout::
+* Exception Handling::
+* Stack Checking::
+* Frame Registers::
+* Elimination::
+* Stack Arguments::
+* Register Arguments::
+* Scalar Return::
+* Aggregate Return::
+* Caller Saves::
+* Function Entry::
+* Profiling::
+* Tail Calls::
+* Stack Smashing Protection::
+
+\1f
+File: gccint.info, Node: Frame Layout, Next: Exception Handling, Up: Stack and Calling
+
+17.10.1 Basic Stack Layout
+--------------------------
+
+Here is the basic stack layout.
+
+ -- Macro: STACK_GROWS_DOWNWARD
+ Define this macro if pushing a word onto the stack moves the stack
+ pointer to a smaller address.
+
+ When we say, "define this macro if ...", it means that the
+ compiler checks this macro only with `#ifdef' so the precise
+ definition used does not matter.
+
+ -- Macro: STACK_PUSH_CODE
+ This macro defines the operation used when something is pushed on
+ the stack. In RTL, a push operation will be `(set (mem
+ (STACK_PUSH_CODE (reg sp))) ...)'
+
+ The choices are `PRE_DEC', `POST_DEC', `PRE_INC', and `POST_INC'.
+ Which of these is correct depends on the stack direction and on
+ whether the stack pointer points to the last item on the stack or
+ whether it points to the space for the next item on the stack.
+
+ The default is `PRE_DEC' when `STACK_GROWS_DOWNWARD' is defined,
+ which is almost always right, and `PRE_INC' otherwise, which is
+ often wrong.
+
+ -- Macro: FRAME_GROWS_DOWNWARD
+ Define this macro to nonzero value if the addresses of local
+ variable slots are at negative offsets from the frame pointer.
+
+ -- Macro: ARGS_GROW_DOWNWARD
+ Define this macro if successive arguments to a function occupy
+ decreasing addresses on the stack.
+
+ -- Macro: STARTING_FRAME_OFFSET
+ Offset from the frame pointer to the first local variable slot to
+ be allocated.
+
+ If `FRAME_GROWS_DOWNWARD', find the next slot's offset by
+ subtracting the first slot's length from `STARTING_FRAME_OFFSET'.
+ Otherwise, it is found by adding the length of the first slot to
+ the value `STARTING_FRAME_OFFSET'.
+
+ -- Macro: STACK_ALIGNMENT_NEEDED
+ Define to zero to disable final alignment of the stack during
+ reload. The nonzero default for this macro is suitable for most
+ ports.
+
+ On ports where `STARTING_FRAME_OFFSET' is nonzero or where there
+ is a register save block following the local block that doesn't
+ require alignment to `STACK_BOUNDARY', it may be beneficial to
+ disable stack alignment and do it in the backend.
+
+ -- Macro: STACK_POINTER_OFFSET
+ Offset from the stack pointer register to the first location at
+ which outgoing arguments are placed. If not specified, the
+ default value of zero is used. This is the proper value for most
+ machines.
+
+ If `ARGS_GROW_DOWNWARD', this is the offset to the location above
+ the first location at which outgoing arguments are placed.
+
+ -- Macro: FIRST_PARM_OFFSET (FUNDECL)
+ Offset from the argument pointer register to the first argument's
+ address. On some machines it may depend on the data type of the
+ function.
+
+ If `ARGS_GROW_DOWNWARD', this is the offset to the location above
+ the first argument's address.
+
+ -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL)
+ Offset from the stack pointer register to an item dynamically
+ allocated on the stack, e.g., by `alloca'.
+
+ The default value for this macro is `STACK_POINTER_OFFSET' plus the
+ length of the outgoing arguments. The default is correct for most
+ machines. See `function.c' for details.
+
+ -- Macro: INITIAL_FRAME_ADDRESS_RTX
+ A C expression whose value is RTL representing the address of the
+ initial stack frame. This address is passed to `RETURN_ADDR_RTX'
+ and `DYNAMIC_CHAIN_ADDRESS'. If you don't define this macro, a
+ reasonable default value will be used. Define this macro in order
+ to make frame pointer elimination work in the presence of
+ `__builtin_frame_address (count)' and `__builtin_return_address
+ (count)' for `count' not equal to zero.
+
+ -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)
+ A C expression whose value is RTL representing the address in a
+ stack frame where the pointer to the caller's frame is stored.
+ Assume that FRAMEADDR is an RTL expression for the address of the
+ stack frame itself.
+
+ If you don't define this macro, the default is to return the value
+ of FRAMEADDR--that is, the stack frame address is also the address
+ of the stack word that points to the previous frame.
+
+ -- Macro: SETUP_FRAME_ADDRESSES
+ If defined, a C expression that produces the machine-specific code
+ to setup the stack so that arbitrary frames can be accessed. For
+ example, on the SPARC, we must flush all of the register windows
+ to the stack before we can access arbitrary stack frames. You
+ will seldom need to define this macro.
+
+ -- Target Hook: bool TARGET_BUILTIN_SETJMP_FRAME_VALUE ()
+ This target hook should return an rtx that is used to store the
+ address of the current frame into the built in `setjmp' buffer.
+ The default value, `virtual_stack_vars_rtx', is correct for most
+ machines. One reason you may need to define this target hook is if
+ `hard_frame_pointer_rtx' is the appropriate value on your machine.
+
+ -- Macro: FRAME_ADDR_RTX (FRAMEADDR)
+ A C expression whose value is RTL representing the value of the
+ frame address for the current frame. FRAMEADDR is the frame
+ pointer of the current frame. This is used for
+ __builtin_frame_address. You need only define this macro if the
+ frame address is not the same as the frame pointer. Most machines
+ do not need to define it.
+
+ -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR)
+ A C expression whose value is RTL representing the value of the
+ return address for the frame COUNT steps up from the current
+ frame, after the prologue. FRAMEADDR is the frame pointer of the
+ COUNT frame, or the frame pointer of the COUNT - 1 frame if
+ `RETURN_ADDR_IN_PREVIOUS_FRAME' is defined.
+
+ The value of the expression must always be the correct address when
+ COUNT is zero, but may be `NULL_RTX' if there is no way to
+ determine the return address of other frames.
+
+ -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME
+ Define this if the return address of a particular stack frame is
+ accessed from the frame pointer of the previous stack frame.
+
+ -- Macro: INCOMING_RETURN_ADDR_RTX
+ A C expression whose value is RTL representing the location of the
+ incoming return address at the beginning of any function, before
+ the prologue. This RTL is either a `REG', indicating that the
+ return value is saved in `REG', or a `MEM' representing a location
+ in the stack.
+
+ You only need to define this macro if you want to support call
+ frame debugging information like that provided by DWARF 2.
+
+ If this RTL is a `REG', you should also define
+ `DWARF_FRAME_RETURN_COLUMN' to `DWARF_FRAME_REGNUM (REGNO)'.
+
+ -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN
+ A C expression whose value is an integer giving a DWARF 2 column
+ number that may be used as an alternative return column. The
+ column must not correspond to any gcc hard register (that is, it
+ must not be in the range of `DWARF_FRAME_REGNUM').
+
+ This macro can be useful if `DWARF_FRAME_RETURN_COLUMN' is set to a
+ general register, but an alternative column needs to be used for
+ signal frames. Some targets have also used different frame return
+ columns over time.
+
+ -- Macro: DWARF_ZERO_REG
+ A C expression whose value is an integer giving a DWARF 2 register
+ number that is considered to always have the value zero. This
+ should only be defined if the target has an architected zero
+ register, and someone decided it was a good idea to use that
+ register number to terminate the stack backtrace. New ports
+ should avoid this.
+
+ -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char
+ *LABEL, rtx PATTERN, int INDEX)
+ This target hook allows the backend to emit frame-related insns
+ that contain UNSPECs or UNSPEC_VOLATILEs. The DWARF 2 call frame
+ debugging info engine will invoke it on insns of the form
+ (set (reg) (unspec [...] UNSPEC_INDEX))
+ and
+ (set (reg) (unspec_volatile [...] UNSPECV_INDEX)).
+ to let the backend emit the call frame instructions. LABEL is the
+ CFI label attached to the insn, PATTERN is the pattern of the insn
+ and INDEX is `UNSPEC_INDEX' or `UNSPECV_INDEX'.
+
+ -- Macro: INCOMING_FRAME_SP_OFFSET
+ A C expression whose value is an integer giving the offset, in
+ bytes, from the value of the stack pointer register to the top of
+ the stack frame at the beginning of any function, before the
+ prologue. The top of the frame is defined to be the value of the
+ stack pointer in the previous frame, just before the call
+ instruction.
+
+ You only need to define this macro if you want to support call
+ frame debugging information like that provided by DWARF 2.
+
+ -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL)
+ A C expression whose value is an integer giving the offset, in
+ bytes, from the argument pointer to the canonical frame address
+ (cfa). The final value should coincide with that calculated by
+ `INCOMING_FRAME_SP_OFFSET'. Which is unfortunately not usable
+ during virtual register instantiation.
+
+ The default value for this macro is `FIRST_PARM_OFFSET (fundecl)',
+ which is correct for most machines; in general, the arguments are
+ found immediately before the stack frame. Note that this is not
+ the case on some targets that save registers into the caller's
+ frame, such as SPARC and rs6000, and so such targets need to
+ define this macro.
+
+ You only need to define this macro if the default is incorrect,
+ and you want to support call frame debugging information like that
+ provided by DWARF 2.
+
+ -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL)
+ If defined, a C expression whose value is an integer giving the
+ offset in bytes from the frame pointer to the canonical frame
+ address (cfa). The final value should coincide with that
+ calculated by `INCOMING_FRAME_SP_OFFSET'.
+
+ Normally the CFA is calculated as an offset from the argument
+ pointer, via `ARG_POINTER_CFA_OFFSET', but if the argument pointer
+ is variable due to the ABI, this may not be possible. If this
+ macro is defined, it implies that the virtual register
+ instantiation should be based on the frame pointer instead of the
+ argument pointer. Only one of `FRAME_POINTER_CFA_OFFSET' and
+ `ARG_POINTER_CFA_OFFSET' should be defined.
+
+ -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL)
+ If defined, a C expression whose value is an integer giving the
+ offset in bytes from the canonical frame address (cfa) to the
+ frame base used in DWARF 2 debug information. The default is
+ zero. A different value may reduce the size of debug information
+ on some ports.
+
+\1f
+File: gccint.info, Node: Exception Handling, Next: Stack Checking, Prev: Frame Layout, Up: Stack and Calling
+
+17.10.2 Exception Handling Support
+----------------------------------
+
+ -- Macro: EH_RETURN_DATA_REGNO (N)
+ A C expression whose value is the Nth register number used for
+ data by exception handlers, or `INVALID_REGNUM' if fewer than N
+ registers are usable.
+
+ The exception handling library routines communicate with the
+ exception handlers via a set of agreed upon registers. Ideally
+ these registers should be call-clobbered; it is possible to use
+ call-saved registers, but may negatively impact code size. The
+ target must support at least 2 data registers, but should define 4
+ if there are enough free registers.
+
+ You must define this macro if you want to support call frame
+ exception handling like that provided by DWARF 2.
+
+ -- Macro: EH_RETURN_STACKADJ_RTX
+ A C expression whose value is RTL representing a location in which
+ to store a stack adjustment to be applied before function return.
+ This is used to unwind the stack to an exception handler's call
+ frame. It will be assigned zero on code paths that return
+ normally.
+
+ Typically this is a call-clobbered hard register that is otherwise
+ untouched by the epilogue, but could also be a stack slot.
+
+ Do not define this macro if the stack pointer is saved and restored
+ by the regular prolog and epilog code in the call frame itself; in
+ this case, the exception handling library routines will update the
+ stack location to be restored in place. Otherwise, you must define
+ this macro if you want to support call frame exception handling
+ like that provided by DWARF 2.
+
+ -- Macro: EH_RETURN_HANDLER_RTX
+ A C expression whose value is RTL representing a location in which
+ to store the address of an exception handler to which we should
+ return. It will not be assigned on code paths that return
+ normally.
+
+ Typically this is the location in the call frame at which the
+ normal return address is stored. For targets that return by
+ popping an address off the stack, this might be a memory address
+ just below the _target_ call frame rather than inside the current
+ call frame. If defined, `EH_RETURN_STACKADJ_RTX' will have already
+ been assigned, so it may be used to calculate the location of the
+ target call frame.
+
+ Some targets have more complex requirements than storing to an
+ address calculable during initial code generation. In that case
+ the `eh_return' instruction pattern should be used instead.
+
+ If you want to support call frame exception handling, you must
+ define either this macro or the `eh_return' instruction pattern.
+
+ -- Macro: RETURN_ADDR_OFFSET
+ If defined, an integer-valued C expression for which rtl will be
+ generated to add it to the exception handler address before it is
+ searched in the exception handling tables, and to subtract it
+ again from the address before using it to return to the exception
+ handler.
+
+ -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL)
+ This macro chooses the encoding of pointers embedded in the
+ exception handling sections. If at all possible, this should be
+ defined such that the exception handling section will not require
+ dynamic relocations, and so may be read-only.
+
+ CODE is 0 for data, 1 for code labels, 2 for function pointers.
+ GLOBAL is true if the symbol may be affected by dynamic
+ relocations. The macro should return a combination of the
+ `DW_EH_PE_*' defines as found in `dwarf2.h'.
+
+ If this macro is not defined, pointers will not be encoded but
+ represented directly.
+
+ -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE,
+ ADDR, DONE)
+ This macro allows the target to emit whatever special magic is
+ required to represent the encoding chosen by
+ `ASM_PREFERRED_EH_DATA_FORMAT'. Generic code takes care of
+ pc-relative and indirect encodings; this must be defined if the
+ target uses text-relative or data-relative encodings.
+
+ This is a C statement that branches to DONE if the format was
+ handled. ENCODING is the format chosen, SIZE is the number of
+ bytes that the format occupies, ADDR is the `SYMBOL_REF' to be
+ emitted.
+
+ -- Macro: MD_UNWIND_SUPPORT
+ A string specifying a file to be #include'd in unwind-dw2.c. The
+ file so included typically defines `MD_FALLBACK_FRAME_STATE_FOR'.
+
+ -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS)
+ This macro allows the target to add CPU and operating system
+ specific code to the call-frame unwinder for use when there is no
+ unwind data available. The most common reason to implement this
+ macro is to unwind through signal frames.
+
+ This macro is called from `uw_frame_state_for' in `unwind-dw2.c',
+ `unwind-dw2-xtensa.c' and `unwind-ia64.c'. CONTEXT is an
+ `_Unwind_Context'; FS is an `_Unwind_FrameState'. Examine
+ `context->ra' for the address of the code being executed and
+ `context->cfa' for the stack pointer value. If the frame can be
+ decoded, the register save addresses should be updated in FS and
+ the macro should evaluate to `_URC_NO_REASON'. If the frame
+ cannot be decoded, the macro should evaluate to
+ `_URC_END_OF_STACK'.
+
+ For proper signal handling in Java this macro is accompanied by
+ `MAKE_THROW_FRAME', defined in `libjava/include/*-signal.h'
+ headers.
+
+ -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS)
+ This macro allows the target to add operating system specific code
+ to the call-frame unwinder to handle the IA-64 `.unwabi' unwinding
+ directive, usually used for signal or interrupt frames.
+
+ This macro is called from `uw_update_context' in `unwind-ia64.c'.
+ CONTEXT is an `_Unwind_Context'; FS is an `_Unwind_FrameState'.
+ Examine `fs->unwabi' for the abi and context in the `.unwabi'
+ directive. If the `.unwabi' directive can be handled, the
+ register save addresses should be updated in FS.
+
+ -- Macro: TARGET_USES_WEAK_UNWIND_INFO
+ A C expression that evaluates to true if the target requires unwind
+ info to be given comdat linkage. Define it to be `1' if comdat
+ linkage is necessary. The default is `0'.
+
+\1f
+File: gccint.info, Node: Stack Checking, Next: Frame Registers, Prev: Exception Handling, Up: Stack and Calling
+
+17.10.3 Specifying How Stack Checking is Done
+---------------------------------------------
+
+GCC will check that stack references are within the boundaries of the
+stack, if the option `-fstack-check' is specified, in one of three ways:
+
+ 1. If the value of the `STACK_CHECK_BUILTIN' macro is nonzero, GCC
+ will assume that you have arranged for full stack checking to be
+ done at appropriate places in the configuration files. GCC will
+ not do other special processing.
+
+ 2. If `STACK_CHECK_BUILTIN' is zero and the value of the
+ `STACK_CHECK_STATIC_BUILTIN' macro is nonzero, GCC will assume
+ that you have arranged for static stack checking (checking of the
+ static stack frame of functions) to be done at appropriate places
+ in the configuration files. GCC will only emit code to do dynamic
+ stack checking (checking on dynamic stack allocations) using the
+ third approach below.
+
+ 3. If neither of the above are true, GCC will generate code to
+ periodically "probe" the stack pointer using the values of the
+ macros defined below.
+
+ If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is
+defined, GCC will change its allocation strategy for large objects if
+the option `-fstack-check' is specified: they will always be allocated
+dynamically if their size exceeds `STACK_CHECK_MAX_VAR_SIZE' bytes.
+
+ -- Macro: STACK_CHECK_BUILTIN
+ A nonzero value if stack checking is done by the configuration
+ files in a machine-dependent manner. You should define this macro
+ if stack checking is require by the ABI of your machine or if you
+ would like to do stack checking in some more efficient way than
+ the generic approach. The default value of this macro is zero.
+
+ -- Macro: STACK_CHECK_STATIC_BUILTIN
+ A nonzero value if static stack checking is done by the
+ configuration files in a machine-dependent manner. You should
+ define this macro if you would like to do static stack checking in
+ some more efficient way than the generic approach. The default
+ value of this macro is zero.
+
+ -- Macro: STACK_CHECK_PROBE_INTERVAL
+ An integer representing the interval at which GCC must generate
+ stack probe instructions. You will normally define this macro to
+ be no larger than the size of the "guard pages" at the end of a
+ stack area. The default value of 4096 is suitable for most
+ systems.
+
+ -- Macro: STACK_CHECK_PROBE_LOAD
+ An integer which is nonzero if GCC should perform the stack probe
+ as a load instruction and zero if GCC should use a store
+ instruction. The default is zero, which is the most efficient
+ choice on most systems.
+
+ -- Macro: STACK_CHECK_PROTECT
+ The number of bytes of stack needed to recover from a stack
+ overflow, for languages where such a recovery is supported. The
+ default value of 75 words should be adequate for most machines.
+
+ The following macros are relevant only if neither STACK_CHECK_BUILTIN
+nor STACK_CHECK_STATIC_BUILTIN is defined; you can omit them altogether
+in the opposite case.
+
+ -- Macro: STACK_CHECK_MAX_FRAME_SIZE
+ The maximum size of a stack frame, in bytes. GCC will generate
+ probe instructions in non-leaf functions to ensure at least this
+ many bytes of stack are available. If a stack frame is larger
+ than this size, stack checking will not be reliable and GCC will
+ issue a warning. The default is chosen so that GCC only generates
+ one instruction on most systems. You should normally not change
+ the default value of this macro.
+
+ -- Macro: STACK_CHECK_FIXED_FRAME_SIZE
+ GCC uses this value to generate the above warning message. It
+ represents the amount of fixed frame used by a function, not
+ including space for any callee-saved registers, temporaries and
+ user variables. You need only specify an upper bound for this
+ amount and will normally use the default of four words.
+
+ -- Macro: STACK_CHECK_MAX_VAR_SIZE
+ The maximum size, in bytes, of an object that GCC will place in the
+ fixed area of the stack frame when the user specifies
+ `-fstack-check'. GCC computed the default from the values of the
+ above macros and you will normally not need to override that
+ default.
+
+\1f
+File: gccint.info, Node: Frame Registers, Next: Elimination, Prev: Stack Checking, Up: Stack and Calling
+
+17.10.4 Registers That Address the Stack Frame
+----------------------------------------------
+
+This discusses registers that address the stack frame.
+
+ -- Macro: STACK_POINTER_REGNUM
+ The register number of the stack pointer register, which must also
+ be a fixed register according to `FIXED_REGISTERS'. On most
+ machines, the hardware determines which register this is.
+
+ -- Macro: FRAME_POINTER_REGNUM
+ The register number of the frame pointer register, which is used to
+ access automatic variables in the stack frame. On some machines,
+ the hardware determines which register this is. On other
+ machines, you can choose any register you wish for this purpose.
+
+ -- Macro: HARD_FRAME_POINTER_REGNUM
+ On some machines the offset between the frame pointer and starting
+ offset of the automatic variables is not known until after register
+ allocation has been done (for example, because the saved registers
+ are between these two locations). On those machines, define
+ `FRAME_POINTER_REGNUM' the number of a special, fixed register to
+ be used internally until the offset is known, and define
+ `HARD_FRAME_POINTER_REGNUM' to be the actual hard register number
+ used for the frame pointer.
+
+ You should define this macro only in the very rare circumstances
+ when it is not possible to calculate the offset between the frame
+ pointer and the automatic variables until after register
+ allocation has been completed. When this macro is defined, you
+ must also indicate in your definition of `ELIMINABLE_REGS' how to
+ eliminate `FRAME_POINTER_REGNUM' into either
+ `HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'.
+
+ Do not define this macro if it would be the same as
+ `FRAME_POINTER_REGNUM'.
+
+ -- Macro: ARG_POINTER_REGNUM
+ The register number of the arg pointer register, which is used to
+ access the function's argument list. On some machines, this is
+ the same as the frame pointer register. On some machines, the
+ hardware determines which register this is. On other machines,
+ you can choose any register you wish for this purpose. If this is
+ not the same register as the frame pointer register, then you must
+ mark it as a fixed register according to `FIXED_REGISTERS', or
+ arrange to be able to eliminate it (*note Elimination::).
+
+ -- Macro: RETURN_ADDRESS_POINTER_REGNUM
+ The register number of the return address pointer register, which
+ is used to access the current function's return address from the
+ stack. On some machines, the return address is not at a fixed
+ offset from the frame pointer or stack pointer or argument
+ pointer. This register can be defined to point to the return
+ address on the stack, and then be converted by `ELIMINABLE_REGS'
+ into either the frame pointer or stack pointer.
+
+ Do not define this macro unless there is no other way to get the
+ return address from the stack.
+
+ -- Macro: STATIC_CHAIN_REGNUM
+ -- Macro: STATIC_CHAIN_INCOMING_REGNUM
+ Register numbers used for passing a function's static chain
+ pointer. If register windows are used, the register number as
+ seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM',
+ while the register number as seen by the calling function is
+ `STATIC_CHAIN_REGNUM'. If these registers are the same,
+ `STATIC_CHAIN_INCOMING_REGNUM' need not be defined.
+
+ The static chain register need not be a fixed register.
+
+ If the static chain is passed in memory, these macros should not be
+ defined; instead, the next two macros should be defined.
+
+ -- Macro: STATIC_CHAIN
+ -- Macro: STATIC_CHAIN_INCOMING
+ If the static chain is passed in memory, these macros provide rtx
+ giving `mem' expressions that denote where they are stored.
+ `STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as
+ seen by the calling and called functions, respectively. Often the
+ former will be at an offset from the stack pointer and the latter
+ at an offset from the frame pointer.
+
+ The variables `stack_pointer_rtx', `frame_pointer_rtx', and
+ `arg_pointer_rtx' will have been initialized prior to the use of
+ these macros and should be used to refer to those items.
+
+ If the static chain is passed in a register, the two previous
+ macros should be defined instead.
+
+ -- Macro: DWARF_FRAME_REGISTERS
+ This macro specifies the maximum number of hard registers that can
+ be saved in a call frame. This is used to size data structures
+ used in DWARF2 exception handling.
+
+ Prior to GCC 3.0, this macro was needed in order to establish a
+ stable exception handling ABI in the face of adding new hard
+ registers for ISA extensions. In GCC 3.0 and later, the EH ABI is
+ insulated from changes in the number of hard registers.
+ Nevertheless, this macro can still be used to reduce the runtime
+ memory requirements of the exception handling routines, which can
+ be substantial if the ISA contains a lot of registers that are not
+ call-saved.
+
+ If this macro is not defined, it defaults to
+ `FIRST_PSEUDO_REGISTER'.
+
+ -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS
+ This macro is similar to `DWARF_FRAME_REGISTERS', but is provided
+ for backward compatibility in pre GCC 3.0 compiled code.
+
+ If this macro is not defined, it defaults to
+ `DWARF_FRAME_REGISTERS'.
+
+ -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO)
+ Define this macro if the target's representation for dwarf
+ registers is different than the internal representation for unwind
+ column. Given a dwarf register, this macro should return the
+ internal unwind column number to use instead.
+
+ See the PowerPC's SPE target for an example.
+
+ -- Macro: DWARF_FRAME_REGNUM (REGNO)
+ Define this macro if the target's representation for dwarf
+ registers used in .eh_frame or .debug_frame is different from that
+ used in other debug info sections. Given a GCC hard register
+ number, this macro should return the .eh_frame register number.
+ The default is `DBX_REGISTER_NUMBER (REGNO)'.
+
+
+ -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH)
+ Define this macro to map register numbers held in the call frame
+ info that GCC has collected using `DWARF_FRAME_REGNUM' to those
+ that should be output in .debug_frame (`FOR_EH' is zero) and
+ .eh_frame (`FOR_EH' is nonzero). The default is to return `REGNO'.
+
+
+\1f
+File: gccint.info, Node: Elimination, Next: Stack Arguments, Prev: Frame Registers, Up: Stack and Calling
+
+17.10.5 Eliminating Frame Pointer and Arg Pointer
+-------------------------------------------------
+
+This is about eliminating the frame pointer and arg pointer.
+
+ -- Macro: FRAME_POINTER_REQUIRED
+ A C expression which is nonzero if a function must have and use a
+ frame pointer. This expression is evaluated in the reload pass.
+ If its value is nonzero the function will have a frame pointer.
+
+ The expression can in principle examine the current function and
+ decide according to the facts, but on most machines the constant 0
+ or the constant 1 suffices. Use 0 when the machine allows code to
+ be generated with no frame pointer, and doing so saves some time
+ or space. Use 1 when there is no possible advantage to avoiding a
+ frame pointer.
+
+ In certain cases, the compiler does not know how to produce valid
+ code without a frame pointer. The compiler recognizes those cases
+ and automatically gives the function a frame pointer regardless of
+ what `FRAME_POINTER_REQUIRED' says. You don't need to worry about
+ them.
+
+ In a function that does not require a frame pointer, the frame
+ pointer register can be allocated for ordinary usage, unless you
+ mark it as a fixed register. See `FIXED_REGISTERS' for more
+ information.
+
+ -- Macro: INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)
+ A C statement to store in the variable DEPTH-VAR the difference
+ between the frame pointer and the stack pointer values immediately
+ after the function prologue. The value would be computed from
+ information such as the result of `get_frame_size ()' and the
+ tables of registers `regs_ever_live' and `call_used_regs'.
+
+ If `ELIMINABLE_REGS' is defined, this macro will be not be used and
+ need not be defined. Otherwise, it must be defined even if
+ `FRAME_POINTER_REQUIRED' is defined to always be true; in that
+ case, you may set DEPTH-VAR to anything.
+
+ -- Macro: ELIMINABLE_REGS
+ If defined, this macro specifies a table of register pairs used to
+ eliminate unneeded registers that point into the stack frame. If
+ it is not defined, the only elimination attempted by the compiler
+ is to replace references to the frame pointer with references to
+ the stack pointer.
+
+ The definition of this macro is a list of structure
+ initializations, each of which specifies an original and
+ replacement register.
+
+ On some machines, the position of the argument pointer is not
+ known until the compilation is completed. In such a case, a
+ separate hard register must be used for the argument pointer.
+ This register can be eliminated by replacing it with either the
+ frame pointer or the argument pointer, depending on whether or not
+ the frame pointer has been eliminated.
+
+ In this case, you might specify:
+ #define ELIMINABLE_REGS \
+ {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
+ {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \
+ {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}
+
+ Note that the elimination of the argument pointer with the stack
+ pointer is specified first since that is the preferred elimination.
+
+ -- Macro: CAN_ELIMINATE (FROM-REG, TO-REG)
+ A C expression that returns nonzero if the compiler is allowed to
+ try to replace register number FROM-REG with register number
+ TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is
+ defined, and will usually be the constant 1, since most of the
+ cases preventing register elimination are things that the compiler
+ already knows about.
+
+ -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)
+ This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'. It
+ specifies the initial difference between the specified pair of
+ registers. This macro must be defined if `ELIMINABLE_REGS' is
+ defined.
+
+\1f
+File: gccint.info, Node: Stack Arguments, Next: Register Arguments, Prev: Elimination, Up: Stack and Calling
+
+17.10.6 Passing Function Arguments on the Stack
+-----------------------------------------------
+
+The macros in this section control how arguments are passed on the
+stack. See the following section for other macros that control passing
+certain arguments in registers.
+
+ -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (tree FNTYPE)
+ This target hook returns `true' if an argument declared in a
+ prototype as an integral type smaller than `int' should actually be
+ passed as an `int'. In addition to avoiding errors in certain
+ cases of mismatch, it also makes for better code on certain
+ machines. The default is to not promote prototypes.
+
+ -- Macro: PUSH_ARGS
+ A C expression. If nonzero, push insns will be used to pass
+ outgoing arguments. If the target machine does not have a push
+ instruction, set it to zero. That directs GCC to use an alternate
+ strategy: to allocate the entire argument block and then store the
+ arguments into it. When `PUSH_ARGS' is nonzero, `PUSH_ROUNDING'
+ must be defined too.
+
+ -- Macro: PUSH_ARGS_REVERSED
+ A C expression. If nonzero, function arguments will be evaluated
+ from last to first, rather than from first to last. If this macro
+ is not defined, it defaults to `PUSH_ARGS' on targets where the
+ stack and args grow in opposite directions, and 0 otherwise.
+
+ -- Macro: PUSH_ROUNDING (NPUSHED)
+ A C expression that is the number of bytes actually pushed onto the
+ stack when an instruction attempts to push NPUSHED bytes.
+
+ On some machines, the definition
+
+ #define PUSH_ROUNDING(BYTES) (BYTES)
+
+ will suffice. But on other machines, instructions that appear to
+ push one byte actually push two bytes in an attempt to maintain
+ alignment. Then the definition should be
+
+ #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
+
+ -- Macro: ACCUMULATE_OUTGOING_ARGS
+ A C expression. If nonzero, the maximum amount of space required
+ for outgoing arguments will be computed and placed into the
+ variable `current_function_outgoing_args_size'. No space will be
+ pushed onto the stack for each call; instead, the function
+ prologue should increase the stack frame size by this amount.
+
+ Setting both `PUSH_ARGS' and `ACCUMULATE_OUTGOING_ARGS' is not
+ proper.
+
+ -- Macro: REG_PARM_STACK_SPACE (FNDECL)
+ Define this macro if functions should assume that stack space has
+ been allocated for arguments even when their values are passed in
+ registers.
+
+ The value of this macro is the size, in bytes, of the area
+ reserved for arguments passed in registers for the function
+ represented by FNDECL, which can be zero if GCC is calling a
+ library function. The argument FNDECL can be the FUNCTION_DECL,
+ or the type itself of the function.
+
+ This space can be allocated by the caller, or be a part of the
+ machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says
+ which.
+
+ -- Macro: OUTGOING_REG_PARM_STACK_SPACE (FNTYPE)
+ Define this to a nonzero value if it is the responsibility of the
+ caller to allocate the area reserved for arguments passed in
+ registers when calling a function of FNTYPE. FNTYPE may be NULL
+ if the function called is a library function.
+
+ If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls
+ whether the space for these arguments counts in the value of
+ `current_function_outgoing_args_size'.
+
+ -- Macro: STACK_PARMS_IN_REG_PARM_AREA
+ Define this macro if `REG_PARM_STACK_SPACE' is defined, but the
+ stack parameters don't skip the area specified by it.
+
+ Normally, when a parameter is not passed in registers, it is
+ placed on the stack beyond the `REG_PARM_STACK_SPACE' area.
+ Defining this macro suppresses this behavior and causes the
+ parameter to be passed on the stack in its natural location.
+
+ -- Macro: RETURN_POPS_ARGS (FUNDECL, FUNTYPE, STACK-SIZE)
+ A C expression that should indicate the number of bytes of its own
+ arguments that a function pops on returning, or 0 if the function
+ pops no arguments and the caller must therefore pop them all after
+ the function returns.
+
+ FUNDECL is a C variable whose value is a tree node that describes
+ the function in question. Normally it is a node of type
+ `FUNCTION_DECL' that describes the declaration of the function.
+ From this you can obtain the `DECL_ATTRIBUTES' of the function.
+
+ FUNTYPE is a C variable whose value is a tree node that describes
+ the function in question. Normally it is a node of type
+ `FUNCTION_TYPE' that describes the data type of the function.
+ From this it is possible to obtain the data types of the value and
+ arguments (if known).
+
+ When a call to a library function is being considered, FUNDECL
+ will contain an identifier node for the library function. Thus, if
+ you need to distinguish among various library functions, you can
+ do so by their names. Note that "library function" in this
+ context means a function used to perform arithmetic, whose name is
+ known specially in the compiler and was not mentioned in the C
+ code being compiled.
+
+ STACK-SIZE is the number of bytes of arguments passed on the
+ stack. If a variable number of bytes is passed, it is zero, and
+ argument popping will always be the responsibility of the calling
+ function.
+
+ On the VAX, all functions always pop their arguments, so the
+ definition of this macro is STACK-SIZE. On the 68000, using the
+ standard calling convention, no functions pop their arguments, so
+ the value of the macro is always 0 in this case. But an
+ alternative calling convention is available in which functions
+ that take a fixed number of arguments pop them but other functions
+ (such as `printf') pop nothing (the caller pops all). When this
+ convention is in use, FUNTYPE is examined to determine whether a
+ function takes a fixed number of arguments.
+
+ -- Macro: CALL_POPS_ARGS (CUM)
+ A C expression that should indicate the number of bytes a call
+ sequence pops off the stack. It is added to the value of
+ `RETURN_POPS_ARGS' when compiling a function call.
+
+ CUM is the variable in which all arguments to the called function
+ have been accumulated.
+
+ On certain architectures, such as the SH5, a call trampoline is
+ used that pops certain registers off the stack, depending on the
+ arguments that have been passed to the function. Since this is a
+ property of the call site, not of the called function,
+ `RETURN_POPS_ARGS' is not appropriate.
+
+\1f
+File: gccint.info, Node: Register Arguments, Next: Scalar Return, Prev: Stack Arguments, Up: Stack and Calling
+
+17.10.7 Passing Arguments in Registers
+--------------------------------------
+
+This section describes the macros which let you control how various
+types of arguments are passed in registers or how they are arranged in
+the stack.
+
+ -- Macro: FUNCTION_ARG (CUM, MODE, TYPE, NAMED)
+ A C expression that controls whether a function argument is passed
+ in a register, and which register.
+
+ The arguments are CUM, which summarizes all the previous
+ arguments; MODE, the machine mode of the argument; TYPE, the data
+ type of the argument as a tree node or 0 if that is not known
+ (which happens for C support library functions); and NAMED, which
+ is 1 for an ordinary argument and 0 for nameless arguments that
+ correspond to `...' in the called function's prototype. TYPE can
+ be an incomplete type if a syntax error has previously occurred.
+
+ The value of the expression is usually either a `reg' RTX for the
+ hard register in which to pass the argument, or zero to pass the
+ argument on the stack.
+
+ For machines like the VAX and 68000, where normally all arguments
+ are pushed, zero suffices as a definition.
+
+ The value of the expression can also be a `parallel' RTX. This is
+ used when an argument is passed in multiple locations. The mode
+ of the `parallel' should be the mode of the entire argument. The
+ `parallel' holds any number of `expr_list' pairs; each one
+ describes where part of the argument is passed. In each
+ `expr_list' the first operand must be a `reg' RTX for the hard
+ register in which to pass this part of the argument, and the mode
+ of the register RTX indicates how large this part of the argument
+ is. The second operand of the `expr_list' is a `const_int' which
+ gives the offset in bytes into the entire argument of where this
+ part starts. As a special exception the first `expr_list' in the
+ `parallel' RTX may have a first operand of zero. This indicates
+ that the entire argument is also stored on the stack.
+
+ The last time this macro is called, it is called with `MODE ==
+ VOIDmode', and its result is passed to the `call' or `call_value'
+ pattern as operands 2 and 3 respectively.
+
+ The usual way to make the ISO library `stdarg.h' work on a machine
+ where some arguments are usually passed in registers, is to cause
+ nameless arguments to be passed on the stack instead. This is done
+ by making `FUNCTION_ARG' return 0 whenever NAMED is 0.
+
+ You may use the hook `targetm.calls.must_pass_in_stack' in the
+ definition of this macro to determine if this argument is of a
+ type that must be passed in the stack. If `REG_PARM_STACK_SPACE'
+ is not defined and `FUNCTION_ARG' returns nonzero for such an
+ argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is
+ defined, the argument will be computed in the stack and then
+ loaded into a register.
+
+ -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (enum machine_mode
+ MODE, tree TYPE)
+ This target hook should return `true' if we should not pass TYPE
+ solely in registers. The file `expr.h' defines a definition that
+ is usually appropriate, refer to `expr.h' for additional
+ documentation.
+
+ -- Macro: FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)
+ Define this macro if the target machine has "register windows", so
+ that the register in which a function sees an arguments is not
+ necessarily the same as the one in which the caller passed the
+ argument.
+
+ For such machines, `FUNCTION_ARG' computes the register in which
+ the caller passes the value, and `FUNCTION_INCOMING_ARG' should be
+ defined in a similar fashion to tell the function being called
+ where the arguments will arrive.
+
+ If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
+ both purposes.
+
+ -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (CUMULATIVE_ARGS *CUM,
+ enum machine_mode MODE, tree TYPE, bool NAMED)
+ This target hook returns the number of bytes at the beginning of an
+ argument that must be put in registers. The value must be zero for
+ arguments that are passed entirely in registers or that are
+ entirely pushed on the stack.
+
+ On some machines, certain arguments must be passed partially in
+ registers and partially in memory. On these machines, typically
+ the first few words of arguments are passed in registers, and the
+ rest on the stack. If a multi-word argument (a `double' or a
+ structure) crosses that boundary, its first few words must be
+ passed in registers and the rest must be pushed. This macro tells
+ the compiler when this occurs, and how many bytes should go in
+ registers.
+
+ `FUNCTION_ARG' for these arguments should return the first
+ register to be used by the caller for this argument; likewise
+ `FUNCTION_INCOMING_ARG', for the called function.
+
+ -- Target Hook: bool TARGET_PASS_BY_REFERENCE (CUMULATIVE_ARGS *CUM,
+ enum machine_mode MODE, tree TYPE, bool NAMED)
+ This target hook should return `true' if an argument at the
+ position indicated by CUM should be passed by reference. This
+ predicate is queried after target independent reasons for being
+ passed by reference, such as `TREE_ADDRESSABLE (type)'.
+
+ If the hook returns true, a copy of that argument is made in
+ memory and a pointer to the argument is passed instead of the
+ argument itself. The pointer is passed in whatever way is
+ appropriate for passing a pointer to that type.
+
+ -- Target Hook: bool TARGET_CALLEE_COPIES (CUMULATIVE_ARGS *CUM, enum
+ machine_mode MODE, tree TYPE, bool NAMED)
+ The function argument described by the parameters to this hook is
+ known to be passed by reference. The hook should return true if
+ the function argument should be copied by the callee instead of
+ copied by the caller.
+
+ For any argument for which the hook returns true, if it can be
+ determined that the argument is not modified, then a copy need not
+ be generated.
+
+ The default version of this hook always returns false.
+
+ -- Macro: CUMULATIVE_ARGS
+ A C type for declaring a variable that is used as the first
+ argument of `FUNCTION_ARG' and other related values. For some
+ target machines, the type `int' suffices and can hold the number
+ of bytes of argument so far.
+
+ There is no need to record in `CUMULATIVE_ARGS' anything about the
+ arguments that have been passed on the stack. The compiler has
+ other variables to keep track of that. For target machines on
+ which all arguments are passed on the stack, there is no need to
+ store anything in `CUMULATIVE_ARGS'; however, the data structure
+ must exist and should not be empty, so use `int'.
+
+ -- Macro: OVERRIDE_ABI_FORMAT (FNDECL)
+ If defined, this macro is called before generating any code for a
+ function, but after the CFUN descriptor for the function has been
+ created. The back end may use this macro to update CFUN to
+ reflect an ABI other than that which would normally be used by
+ default. If the compiler is generating code for a
+ compiler-generated function, FNDECL may be `NULL'.
+
+ -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL,
+ N_NAMED_ARGS)
+ A C statement (sans semicolon) for initializing the variable CUM
+ for the state at the beginning of the argument list. The variable
+ has type `CUMULATIVE_ARGS'. The value of FNTYPE is the tree node
+ for the data type of the function which will receive the args, or
+ 0 if the args are to a compiler support library function. For
+ direct calls that are not libcalls, FNDECL contain the declaration
+ node of the function. FNDECL is also set when
+ `INIT_CUMULATIVE_ARGS' is used to find arguments for the function
+ being compiled. N_NAMED_ARGS is set to the number of named
+ arguments, including a structure return address if it is passed as
+ a parameter, when making a call. When processing incoming
+ arguments, N_NAMED_ARGS is set to -1.
+
+ When processing a call to a compiler support library function,
+ LIBNAME identifies which one. It is a `symbol_ref' rtx which
+ contains the name of the function, as a string. LIBNAME is 0 when
+ an ordinary C function call is being processed. Thus, each time
+ this macro is called, either LIBNAME or FNTYPE is nonzero, but
+ never both of them at once.
+
+ -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME)
+ Like `INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls,
+ it gets a `MODE' argument instead of FNTYPE, that would be `NULL'.
+ INDIRECT would always be zero, too. If this macro is not defined,
+ `INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead.
+
+ -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)
+ Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of
+ finding the arguments for the function being compiled. If this
+ macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead.
+
+ The value passed for LIBNAME is always 0, since library routines
+ with special calling conventions are never compiled with GCC. The
+ argument LIBNAME exists for symmetry with `INIT_CUMULATIVE_ARGS'.
+
+ -- Macro: FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)
+ A C statement (sans semicolon) to update the summarizer variable
+ CUM to advance past an argument in the argument list. The values
+ MODE, TYPE and NAMED describe that argument. Once this is done,
+ the variable CUM is suitable for analyzing the _following_
+ argument with `FUNCTION_ARG', etc.
+
+ This macro need not do anything if the argument in question was
+ passed on the stack. The compiler knows how to track the amount
+ of stack space used for arguments without any special help.
+
+ -- Macro: FUNCTION_ARG_OFFSET (MODE, TYPE)
+ If defined, a C expression that is the number of bytes to add to
+ the offset of the argument passed in memory. This is needed for
+ the SPU, which passes `char' and `short' arguments in the preferred
+ slot that is in the middle of the quad word instead of starting at
+ the top.
+
+ -- Macro: FUNCTION_ARG_PADDING (MODE, TYPE)
+ If defined, a C expression which determines whether, and in which
+ direction, to pad out an argument with extra space. The value
+ should be of type `enum direction': either `upward' to pad above
+ the argument, `downward' to pad below, or `none' to inhibit
+ padding.
+
+ The _amount_ of padding is always just enough to reach the next
+ multiple of `FUNCTION_ARG_BOUNDARY'; this macro does not control
+ it.
+
+ This macro has a default definition which is right for most
+ systems. For little-endian machines, the default is to pad
+ upward. For big-endian machines, the default is to pad downward
+ for an argument of constant size shorter than an `int', and upward
+ otherwise.
+
+ -- Macro: PAD_VARARGS_DOWN
+ If defined, a C expression which determines whether the default
+ implementation of va_arg will attempt to pad down before reading
+ the next argument, if that argument is smaller than its aligned
+ space as controlled by `PARM_BOUNDARY'. If this macro is not
+ defined, all such arguments are padded down if `BYTES_BIG_ENDIAN'
+ is true.
+
+ -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST)
+ Specify padding for the last element of a block move between
+ registers and memory. FIRST is nonzero if this is the only
+ element. Defining this macro allows better control of register
+ function parameters on big-endian machines, without using
+ `PARALLEL' rtl. In particular, `MUST_PASS_IN_STACK' need not test
+ padding and mode of types in registers, as there is no longer a
+ "wrong" part of a register; For example, a three byte aggregate
+ may be passed in the high part of a register if so required.
+
+ -- Macro: FUNCTION_ARG_BOUNDARY (MODE, TYPE)
+ If defined, a C expression that gives the alignment boundary, in
+ bits, of an argument with the specified mode and type. If it is
+ not defined, `PARM_BOUNDARY' is used for all arguments.
+
+ -- Macro: FUNCTION_ARG_REGNO_P (REGNO)
+ A C expression that is nonzero if REGNO is the number of a hard
+ register in which function arguments are sometimes passed. This
+ does _not_ include implicit arguments such as the static chain and
+ the structure-value address. On many machines, no registers can be
+ used for this purpose since all function arguments are pushed on
+ the stack.
+
+ -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (tree TYPE)
+ This hook should return true if parameter of type TYPE are passed
+ as two scalar parameters. By default, GCC will attempt to pack
+ complex arguments into the target's word size. Some ABIs require
+ complex arguments to be split and treated as their individual
+ components. For example, on AIX64, complex floats should be
+ passed in a pair of floating point registers, even though a
+ complex float would fit in one 64-bit floating point register.
+
+ The default value of this hook is `NULL', which is treated as
+ always false.
+
+ -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void)
+ This hook returns a type node for `va_list' for the target. The
+ default version of the hook returns `void*'.
+
+ -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL)
+ This hook returns the va_list type of the calling convention
+ specified by FNDECL. The default version of this hook returns
+ `va_list_type_node'.
+
+ -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE)
+ This hook returns the va_list type of the calling convention
+ specified by the type of TYPE. If TYPE is not a valid va_list
+ type, it returns `NULL_TREE'.
+
+ -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree
+ TYPE, tree *PRE_P, tree *POST_P)
+ This hook performs target-specific gimplification of
+ `VA_ARG_EXPR'. The first two parameters correspond to the
+ arguments to `va_arg'; the latter two are as in
+ `gimplify.c:gimplify_expr'.
+
+ -- Target Hook: bool TARGET_VALID_POINTER_MODE (enum machine_mode MODE)
+ Define this to return nonzero if the port can handle pointers with
+ machine mode MODE. The default version of this hook returns true
+ for both `ptr_mode' and `Pmode'.
+
+ -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (enum machine_mode
+ MODE)
+ Define this to return nonzero if the port is prepared to handle
+ insns involving scalar mode MODE. For a scalar mode to be
+ considered supported, all the basic arithmetic and comparisons
+ must work.
+
+ The default version of this hook returns true for any mode
+ required to handle the basic C types (as defined by the port).
+ Included here are the double-word arithmetic supported by the code
+ in `optabs.c'.
+
+ -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (enum machine_mode
+ MODE)
+ Define this to return nonzero if the port is prepared to handle
+ insns involving vector mode MODE. At the very least, it must have
+ move patterns for this mode.
+
+\1f
+File: gccint.info, Node: Scalar Return, Next: Aggregate Return, Prev: Register Arguments, Up: Stack and Calling
+
+17.10.8 How Scalar Function Values Are Returned
+-----------------------------------------------
+
+This section discusses the macros that control returning scalars as
+values--values that can fit in registers.
+
+ -- Target Hook: rtx TARGET_FUNCTION_VALUE (tree RET_TYPE, tree
+ FN_DECL_OR_TYPE, bool OUTGOING)
+ Define this to return an RTX representing the place where a
+ function returns or receives a value of data type RET_TYPE, a tree
+ node node representing a data type. FN_DECL_OR_TYPE is a tree node
+ representing `FUNCTION_DECL' or `FUNCTION_TYPE' of a function
+ being called. If OUTGOING is false, the hook should compute the
+ register in which the caller will see the return value.
+ Otherwise, the hook should return an RTX representing the place
+ where a function returns a value.
+
+ On many machines, only `TYPE_MODE (RET_TYPE)' is relevant.
+ (Actually, on most machines, scalar values are returned in the same
+ place regardless of mode.) The value of the expression is usually
+ a `reg' RTX for the hard register where the return value is stored.
+ The value can also be a `parallel' RTX, if the return value is in
+ multiple places. See `FUNCTION_ARG' for an explanation of the
+ `parallel' form. Note that the callee will populate every
+ location specified in the `parallel', but if the first element of
+ the `parallel' contains the whole return value, callers will use
+ that element as the canonical location and ignore the others. The
+ m68k port uses this type of `parallel' to return pointers in both
+ `%a0' (the canonical location) and `%d0'.
+
+ If `TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply
+ the same promotion rules specified in `PROMOTE_MODE' if VALTYPE is
+ a scalar type.
+
+ If the precise function being called is known, FUNC is a tree node
+ (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. This
+ makes it possible to use a different value-returning convention
+ for specific functions when all their calls are known.
+
+ Some target machines have "register windows" so that the register
+ in which a function returns its value is not the same as the one
+ in which the caller sees the value. For such machines, you should
+ return different RTX depending on OUTGOING.
+
+ `TARGET_FUNCTION_VALUE' is not used for return values with
+ aggregate data types, because these are returned in another way.
+ See `TARGET_STRUCT_VALUE_RTX' and related macros, below.
+
+ -- Macro: FUNCTION_VALUE (VALTYPE, FUNC)
+ This macro has been deprecated. Use `TARGET_FUNCTION_VALUE' for a
+ new target instead.
+
+ -- Macro: FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)
+ This macro has been deprecated. Use `TARGET_FUNCTION_VALUE' for a
+ new target instead.
+
+ -- Macro: LIBCALL_VALUE (MODE)
+ A C expression to create an RTX representing the place where a
+ library function returns a value of mode MODE.
+
+ Note that "library function" in this context means a compiler
+ support routine, used to perform arithmetic, whose name is known
+ specially by the compiler and was not mentioned in the C code being
+ compiled.
+
+ -- Macro: FUNCTION_VALUE_REGNO_P (REGNO)
+ A C expression that is nonzero if REGNO is the number of a hard
+ register in which the values of called function may come back.
+
+ A register whose use for returning values is limited to serving as
+ the second of a pair (for a value of type `double', say) need not
+ be recognized by this macro. So for most machines, this definition
+ suffices:
+
+ #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
+
+ If the machine has register windows, so that the caller and the
+ called function use different registers for the return value, this
+ macro should recognize only the caller's register numbers.
+
+ -- Macro: TARGET_ENUM_VA_LIST (IDX, PNAME, PTYPE)
+ This target macro is used in function `c_common_nodes_and_builtins'
+ to iterate through the target specific builtin types for va_list.
+ The variable IDX is used as iterator. PNAME has to be a pointer to
+ a `const char *' and PTYPE a pointer to a `tree' typed variable.
+ The arguments PNAME and PTYPE are used to store the result of this
+ macro and are set to the name of the va_list builtin type and its
+ internal type. If the return value of this macro is zero, then
+ there is no more element. Otherwise the IDX should be increased
+ for the next call of this macro to iterate through all types.
+
+ -- Macro: APPLY_RESULT_SIZE
+ Define this macro if `untyped_call' and `untyped_return' need more
+ space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and
+ restoring an arbitrary return value.
+
+ -- Target Hook: bool TARGET_RETURN_IN_MSB (tree TYPE)
+ This hook should return true if values of type TYPE are returned
+ at the most significant end of a register (in other words, if they
+ are padded at the least significant end). You can assume that TYPE
+ is returned in a register; the caller is required to check this.
+
+ Note that the register provided by `TARGET_FUNCTION_VALUE' must be
+ able to hold the complete return value. For example, if a 1-, 2-
+ or 3-byte structure is returned at the most significant end of a
+ 4-byte register, `TARGET_FUNCTION_VALUE' should provide an
+ `SImode' rtx.
+
+\1f
+File: gccint.info, Node: Aggregate Return, Next: Caller Saves, Prev: Scalar Return, Up: Stack and Calling
+
+17.10.9 How Large Values Are Returned
+-------------------------------------
+
+When a function value's mode is `BLKmode' (and in some other cases),
+the value is not returned according to `TARGET_FUNCTION_VALUE' (*note
+Scalar Return::). Instead, the caller passes the address of a block of
+memory in which the value should be stored. This address is called the
+"structure value address".
+
+ This section describes how to control returning structure values in
+memory.
+
+ -- Target Hook: bool TARGET_RETURN_IN_MEMORY (tree TYPE, tree FNTYPE)
+ This target hook should return a nonzero value to say to return the
+ function value in memory, just as large structures are always
+ returned. Here TYPE will be the data type of the value, and FNTYPE
+ will be the type of the function doing the returning, or `NULL' for
+ libcalls.
+
+ Note that values of mode `BLKmode' must be explicitly handled by
+ this function. Also, the option `-fpcc-struct-return' takes
+ effect regardless of this macro. On most systems, it is possible
+ to leave the hook undefined; this causes a default definition to
+ be used, whose value is the constant 1 for `BLKmode' values, and 0
+ otherwise.
+
+ Do not use this hook to indicate that structures and unions should
+ always be returned in memory. You should instead use
+ `DEFAULT_PCC_STRUCT_RETURN' to indicate this.
+
+ -- Macro: DEFAULT_PCC_STRUCT_RETURN
+ Define this macro to be 1 if all structure and union return values
+ must be in memory. Since this results in slower code, this should
+ be defined only if needed for compatibility with other compilers
+ or with an ABI. If you define this macro to be 0, then the
+ conventions used for structure and union return values are decided
+ by the `TARGET_RETURN_IN_MEMORY' target hook.
+
+ If not defined, this defaults to the value 1.
+
+ -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING)
+ This target hook should return the location of the structure value
+ address (normally a `mem' or `reg'), or 0 if the address is passed
+ as an "invisible" first argument. Note that FNDECL may be `NULL',
+ for libcalls. You do not need to define this target hook if the
+ address is always passed as an "invisible" first argument.
+
+ On some architectures the place where the structure value address
+ is found by the called function is not the same place that the
+ caller put it. This can be due to register windows, or it could
+ be because the function prologue moves it to a different place.
+ INCOMING is `1' or `2' when the location is needed in the context
+ of the called function, and `0' in the context of the caller.
+
+ If INCOMING is nonzero and the address is to be found on the
+ stack, return a `mem' which refers to the frame pointer. If
+ INCOMING is `2', the result is being used to fetch the structure
+ value address at the beginning of a function. If you need to emit
+ adjusting code, you should do it at this point.
+
+ -- Macro: PCC_STATIC_STRUCT_RETURN
+ Define this macro if the usual system convention on the target
+ machine for returning structures and unions is for the called
+ function to return the address of a static variable containing the
+ value.
+
+ Do not define this if the usual system convention is for the
+ caller to pass an address to the subroutine.
+
+ This macro has effect in `-fpcc-struct-return' mode, but it does
+ nothing when you use `-freg-struct-return' mode.
+
+\1f
+File: gccint.info, Node: Caller Saves, Next: Function Entry, Prev: Aggregate Return, Up: Stack and Calling
+
+17.10.10 Caller-Saves Register Allocation
+-----------------------------------------
+
+If you enable it, GCC can save registers around function calls. This
+makes it possible to use call-clobbered registers to hold variables that
+must live across calls.
+
+ -- Macro: CALLER_SAVE_PROFITABLE (REFS, CALLS)
+ A C expression to determine whether it is worthwhile to consider
+ placing a pseudo-register in a call-clobbered hard register and
+ saving and restoring it around each function call. The expression
+ should be 1 when this is worth doing, and 0 otherwise.
+
+ If you don't define this macro, a default is used which is good on
+ most machines: `4 * CALLS < REFS'.
+
+ -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS)
+ A C expression specifying which mode is required for saving NREGS
+ of a pseudo-register in call-clobbered hard register REGNO. If
+ REGNO is unsuitable for caller save, `VOIDmode' should be
+ returned. For most machines this macro need not be defined since
+ GCC will select the smallest suitable mode.
+
+\1f
+File: gccint.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling
+
+17.10.11 Function Entry and Exit
+--------------------------------
+
+This section describes the macros that output function entry
+("prologue") and exit ("epilogue") code.
+
+ -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE,
+ HOST_WIDE_INT SIZE)
+ If defined, a function that outputs the assembler code for entry
+ to a function. The prologue is responsible for setting up the
+ stack frame, initializing the frame pointer register, saving
+ registers that must be saved, and allocating SIZE additional bytes
+ of storage for the local variables. SIZE is an integer. FILE is
+ a stdio stream to which the assembler code should be output.
+
+ The label for the beginning of the function need not be output by
+ this macro. That has already been done when the macro is run.
+
+ To determine which registers to save, the macro can refer to the
+ array `regs_ever_live': element R is nonzero if hard register R is
+ used anywhere within the function. This implies the function
+ prologue should save register R, provided it is not one of the
+ call-used registers. (`TARGET_ASM_FUNCTION_EPILOGUE' must
+ likewise use `regs_ever_live'.)
+
+ On machines that have "register windows", the function entry code
+ does not save on the stack the registers that are in the windows,
+ even if they are supposed to be preserved by function calls;
+ instead it takes appropriate steps to "push" the register stack,
+ if any non-call-used registers are used in the function.
+
+ On machines where functions may or may not have frame-pointers, the
+ function entry code must vary accordingly; it must set up the frame
+ pointer if one is wanted, and not otherwise. To determine whether
+ a frame pointer is in wanted, the macro can refer to the variable
+ `frame_pointer_needed'. The variable's value will be 1 at run
+ time in a function that needs a frame pointer. *Note
+ Elimination::.
+
+ The function entry code is responsible for allocating any stack
+ space required for the function. This stack space consists of the
+ regions listed below. In most cases, these regions are allocated
+ in the order listed, with the last listed region closest to the
+ top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is
+ defined, and the highest address if it is not defined). You can
+ use a different order for a machine if doing so is more convenient
+ or required for compatibility reasons. Except in cases where
+ required by standard or by a debugger, there is no reason why the
+ stack layout used by GCC need agree with that used by other
+ compilers for a machine.
+
+ -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE)
+ If defined, a function that outputs assembler code at the end of a
+ prologue. This should be used when the function prologue is being
+ emitted as RTL, and you have some extra assembler that needs to be
+ emitted. *Note prologue instruction pattern::.
+
+ -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE)
+ If defined, a function that outputs assembler code at the start of
+ an epilogue. This should be used when the function epilogue is
+ being emitted as RTL, and you have some extra assembler that needs
+ to be emitted. *Note epilogue instruction pattern::.
+
+ -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE,
+ HOST_WIDE_INT SIZE)
+ If defined, a function that outputs the assembler code for exit
+ from a function. The epilogue is responsible for restoring the
+ saved registers and stack pointer to their values when the
+ function was called, and returning control to the caller. This
+ macro takes the same arguments as the macro
+ `TARGET_ASM_FUNCTION_PROLOGUE', and the registers to restore are
+ determined from `regs_ever_live' and `CALL_USED_REGISTERS' in the
+ same way.
+
+ On some machines, there is a single instruction that does all the
+ work of returning from the function. On these machines, give that
+ instruction the name `return' and do not define the macro
+ `TARGET_ASM_FUNCTION_EPILOGUE' at all.
+
+ Do not define a pattern named `return' if you want the
+ `TARGET_ASM_FUNCTION_EPILOGUE' to be used. If you want the target
+ switches to control whether return instructions or epilogues are
+ used, define a `return' pattern with a validity condition that
+ tests the target switches appropriately. If the `return'
+ pattern's validity condition is false, epilogues will be used.
+
+ On machines where functions may or may not have frame-pointers, the
+ function exit code must vary accordingly. Sometimes the code for
+ these two cases is completely different. To determine whether a
+ frame pointer is wanted, the macro can refer to the variable
+ `frame_pointer_needed'. The variable's value will be 1 when
+ compiling a function that needs a frame pointer.
+
+ Normally, `TARGET_ASM_FUNCTION_PROLOGUE' and
+ `TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially.
+ The C variable `current_function_is_leaf' is nonzero for such a
+ function. *Note Leaf Functions::.
+
+ On some machines, some functions pop their arguments on exit while
+ others leave that for the caller to do. For example, the 68020
+ when given `-mrtd' pops arguments in functions that take a fixed
+ number of arguments.
+
+ Your definition of the macro `RETURN_POPS_ARGS' decides which
+ functions pop their own arguments. `TARGET_ASM_FUNCTION_EPILOGUE'
+ needs to know what was decided. The variable that is called
+ `current_function_pops_args' is the number of bytes of its
+ arguments that a function should pop. *Note Scalar Return::.
+
+ * A region of `current_function_pretend_args_size' bytes of
+ uninitialized space just underneath the first argument arriving on
+ the stack. (This may not be at the very start of the allocated
+ stack region if the calling sequence has pushed anything else
+ since pushing the stack arguments. But usually, on such machines,
+ nothing else has been pushed yet, because the function prologue
+ itself does all the pushing.) This region is used on machines
+ where an argument may be passed partly in registers and partly in
+ memory, and, in some cases to support the features in `<stdarg.h>'.
+
+ * An area of memory used to save certain registers used by the
+ function. The size of this area, which may also include space for
+ such things as the return address and pointers to previous stack
+ frames, is machine-specific and usually depends on which registers
+ have been used in the function. Machines with register windows
+ often do not require a save area.
+
+ * A region of at least SIZE bytes, possibly rounded up to an
+ allocation boundary, to contain the local variables of the
+ function. On some machines, this region and the save area may
+ occur in the opposite order, with the save area closer to the top
+ of the stack.
+
+ * Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a region of
+ `current_function_outgoing_args_size' bytes to be used for outgoing
+ argument lists of the function. *Note Stack Arguments::.
+
+ -- Macro: EXIT_IGNORE_STACK
+ Define this macro as a C expression that is nonzero if the return
+ instruction or the function epilogue ignores the value of the stack
+ pointer; in other words, if it is safe to delete an instruction to
+ adjust the stack pointer before a return from the function. The
+ default is 0.
+
+ Note that this macro's value is relevant only for functions for
+ which frame pointers are maintained. It is never safe to delete a
+ final stack adjustment in a function that has no frame pointer,
+ and the compiler knows this regardless of `EXIT_IGNORE_STACK'.
+
+ -- Macro: EPILOGUE_USES (REGNO)
+ Define this macro as a C expression that is nonzero for registers
+ that are used by the epilogue or the `return' pattern. The stack
+ and frame pointer registers are already assumed to be used as
+ needed.
+
+ -- Macro: EH_USES (REGNO)
+ Define this macro as a C expression that is nonzero for registers
+ that are used by the exception handling mechanism, and so should
+ be considered live on entry to an exception edge.
+
+ -- Macro: DELAY_SLOTS_FOR_EPILOGUE
+ Define this macro if the function epilogue contains delay slots to
+ which instructions from the rest of the function can be "moved".
+ The definition should be a C expression whose value is an integer
+ representing the number of delay slots there.
+
+ -- Macro: ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)
+ A C expression that returns 1 if INSN can be placed in delay slot
+ number N of the epilogue.
+
+ The argument N is an integer which identifies the delay slot now
+ being considered (since different slots may have different rules of
+ eligibility). It is never negative and is always less than the
+ number of epilogue delay slots (what `DELAY_SLOTS_FOR_EPILOGUE'
+ returns). If you reject a particular insn for a given delay slot,
+ in principle, it may be reconsidered for a subsequent delay slot.
+ Also, other insns may (at least in principle) be considered for
+ the so far unfilled delay slot.
+
+ The insns accepted to fill the epilogue delay slots are put in an
+ RTL list made with `insn_list' objects, stored in the variable
+ `current_function_epilogue_delay_list'. The insn for the first
+ delay slot comes first in the list. Your definition of the macro
+ `TARGET_ASM_FUNCTION_EPILOGUE' should fill the delay slots by
+ outputting the insns in this list, usually by calling
+ `final_scan_insn'.
+
+ You need not define this macro if you did not define
+ `DELAY_SLOTS_FOR_EPILOGUE'.
+
+ -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree
+ THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT
+ VCALL_OFFSET, tree FUNCTION)
+ A function that outputs the assembler code for a thunk function,
+ used to implement C++ virtual function calls with multiple
+ inheritance. The thunk acts as a wrapper around a virtual
+ function, adjusting the implicit object parameter before handing
+ control off to the real function.
+
+ First, emit code to add the integer DELTA to the location that
+ contains the incoming first argument. Assume that this argument
+ contains a pointer, and is the one used to pass the `this' pointer
+ in C++. This is the incoming argument _before_ the function
+ prologue, e.g. `%o0' on a sparc. The addition must preserve the
+ values of all other incoming arguments.
+
+ Then, if VCALL_OFFSET is nonzero, an additional adjustment should
+ be made after adding `delta'. In particular, if P is the adjusted
+ pointer, the following adjustment should be made:
+
+ p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)]
+
+ After the additions, emit code to jump to FUNCTION, which is a
+ `FUNCTION_DECL'. This is a direct pure jump, not a call, and does
+ not touch the return address. Hence returning from FUNCTION will
+ return to whoever called the current `thunk'.
+
+ The effect must be as if FUNCTION had been called directly with
+ the adjusted first argument. This macro is responsible for
+ emitting all of the code for a thunk function;
+ `TARGET_ASM_FUNCTION_PROLOGUE' and `TARGET_ASM_FUNCTION_EPILOGUE'
+ are not invoked.
+
+ The THUNK_FNDECL is redundant. (DELTA and FUNCTION have already
+ been extracted from it.) It might possibly be useful on some
+ targets, but probably not.
+
+ If you do not define this macro, the target-independent code in
+ the C++ front end will generate a less efficient heavyweight thunk
+ that calls FUNCTION instead of jumping to it. The generic
+ approach does not support varargs.
+
+ -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (tree
+ THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT
+ VCALL_OFFSET, tree FUNCTION)
+ A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would
+ be able to output the assembler code for the thunk function
+ specified by the arguments it is passed, and false otherwise. In
+ the latter case, the generic approach will be used by the C++
+ front end, with the limitations previously exposed.
+
+\1f
+File: gccint.info, Node: Profiling, Next: Tail Calls, Prev: Function Entry, Up: Stack and Calling
+
+17.10.12 Generating Code for Profiling
+--------------------------------------
+
+These macros will help you generate code for profiling.
+
+ -- Macro: FUNCTION_PROFILER (FILE, LABELNO)
+ A C statement or compound statement to output to FILE some
+ assembler code to call the profiling subroutine `mcount'.
+
+ The details of how `mcount' expects to be called are determined by
+ your operating system environment, not by GCC. To figure them out,
+ compile a small program for profiling using the system's installed
+ C compiler and look at the assembler code that results.
+
+ Older implementations of `mcount' expect the address of a counter
+ variable to be loaded into some register. The name of this
+ variable is `LP' followed by the number LABELNO, so you would
+ generate the name using `LP%d' in a `fprintf'.
+
+ -- Macro: PROFILE_HOOK
+ A C statement or compound statement to output to FILE some assembly
+ code to call the profiling subroutine `mcount' even the target does
+ not support profiling.
+
+ -- Macro: NO_PROFILE_COUNTERS
+ Define this macro to be an expression with a nonzero value if the
+ `mcount' subroutine on your system does not need a counter variable
+ allocated for each function. This is true for almost all modern
+ implementations. If you define this macro, you must not use the
+ LABELNO argument to `FUNCTION_PROFILER'.
+
+ -- Macro: PROFILE_BEFORE_PROLOGUE
+ Define this macro if the code for function profiling should come
+ before the function prologue. Normally, the profiling code comes
+ after.
+
+\1f
+File: gccint.info, Node: Tail Calls, Next: Stack Smashing Protection, Prev: Profiling, Up: Stack and Calling
+
+17.10.13 Permitting tail calls
+------------------------------
+
+ -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree
+ EXP)
+ True if it is ok to do sibling call optimization for the specified
+ call expression EXP. DECL will be the called function, or `NULL'
+ if this is an indirect call.
+
+ It is not uncommon for limitations of calling conventions to
+ prevent tail calls to functions outside the current unit of
+ translation, or during PIC compilation. The hook is used to
+ enforce these restrictions, as the `sibcall' md pattern can not
+ fail, or fall over to a "normal" call. The criteria for
+ successful sibling call optimization may vary greatly between
+ different architectures.
+
+ -- Target Hook: void TARGET_EXTRA_LIVE_ON_ENTRY (bitmap *REGS)
+ Add any hard registers to REGS that are live on entry to the
+ function. This hook only needs to be defined to provide registers
+ that cannot be found by examination of FUNCTION_ARG_REGNO_P, the
+ callee saved registers, STATIC_CHAIN_INCOMING_REGNUM,
+ STATIC_CHAIN_REGNUM, TARGET_STRUCT_VALUE_RTX,
+ FRAME_POINTER_REGNUM, EH_USES, FRAME_POINTER_REGNUM,
+ ARG_POINTER_REGNUM, and the PIC_OFFSET_TABLE_REGNUM.
+
+\1f
+File: gccint.info, Node: Stack Smashing Protection, Prev: Tail Calls, Up: Stack and Calling
+
+17.10.14 Stack smashing protection
+----------------------------------
+
+ -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void)
+ This hook returns a `DECL' node for the external variable to use
+ for the stack protection guard. This variable is initialized by
+ the runtime to some random value and is used to initialize the
+ guard value that is placed at the top of the local stack frame.
+ The type of this variable must be `ptr_type_node'.
+
+ The default version of this hook creates a variable called
+ `__stack_chk_guard', which is normally defined in `libgcc2.c'.
+
+ -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void)
+ This hook returns a tree expression that alerts the runtime that
+ the stack protect guard variable has been modified. This
+ expression should involve a call to a `noreturn' function.
+
+ The default version of this hook invokes a function called
+ `__stack_chk_fail', taking no arguments. This function is
+ normally defined in `libgcc2.c'.
+
+\1f
+File: gccint.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros
+
+17.11 Implementing the Varargs Macros
+=====================================
+
+GCC comes with an implementation of `<varargs.h>' and `<stdarg.h>' that
+work without change on machines that pass arguments on the stack.
+Other machines require their own implementations of varargs, and the
+two machine independent header files must have conditionals to include
+it.
+
+ ISO `<stdarg.h>' differs from traditional `<varargs.h>' mainly in the
+calling convention for `va_start'. The traditional implementation
+takes just one argument, which is the variable in which to store the
+argument pointer. The ISO implementation of `va_start' takes an
+additional second argument. The user is supposed to write the last
+named argument of the function here.
+
+ However, `va_start' should not use this argument. The way to find the
+end of the named arguments is with the built-in functions described
+below.
+
+ -- Macro: __builtin_saveregs ()
+ Use this built-in function to save the argument registers in
+ memory so that the varargs mechanism can access them. Both ISO
+ and traditional versions of `va_start' must use
+ `__builtin_saveregs', unless you use
+ `TARGET_SETUP_INCOMING_VARARGS' (see below) instead.
+
+ On some machines, `__builtin_saveregs' is open-coded under the
+ control of the target hook `TARGET_EXPAND_BUILTIN_SAVEREGS'. On
+ other machines, it calls a routine written in assembler language,
+ found in `libgcc2.c'.
+
+ Code generated for the call to `__builtin_saveregs' appears at the
+ beginning of the function, as opposed to where the call to
+ `__builtin_saveregs' is written, regardless of what the code is.
+ This is because the registers must be saved before the function
+ starts to use them for its own purposes.
+
+ -- Macro: __builtin_args_info (CATEGORY)
+ Use this built-in function to find the first anonymous arguments in
+ registers.
+
+ In general, a machine may have several categories of registers
+ used for arguments, each for a particular category of data types.
+ (For example, on some machines, floating-point registers are used
+ for floating-point arguments while other arguments are passed in
+ the general registers.) To make non-varargs functions use the
+ proper calling convention, you have defined the `CUMULATIVE_ARGS'
+ data type to record how many registers in each category have been
+ used so far
+
+ `__builtin_args_info' accesses the same data structure of type
+ `CUMULATIVE_ARGS' after the ordinary argument layout is finished
+ with it, with CATEGORY specifying which word to access. Thus, the
+ value indicates the first unused register in a given category.
+
+ Normally, you would use `__builtin_args_info' in the implementation
+ of `va_start', accessing each category just once and storing the
+ value in the `va_list' object. This is because `va_list' will
+ have to update the values, and there is no way to alter the values
+ accessed by `__builtin_args_info'.
+
+ -- Macro: __builtin_next_arg (LASTARG)
+ This is the equivalent of `__builtin_args_info', for stack
+ arguments. It returns the address of the first anonymous stack
+ argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns
+ the address of the location above the first anonymous stack
+ argument. Use it in `va_start' to initialize the pointer for
+ fetching arguments from the stack. Also use it in `va_start' to
+ verify that the second parameter LASTARG is the last named argument
+ of the current function.
+
+ -- Macro: __builtin_classify_type (OBJECT)
+ Since each machine has its own conventions for which data types are
+ passed in which kind of register, your implementation of `va_arg'
+ has to embody these conventions. The easiest way to categorize the
+ specified data type is to use `__builtin_classify_type' together
+ with `sizeof' and `__alignof__'.
+
+ `__builtin_classify_type' ignores the value of OBJECT, considering
+ only its data type. It returns an integer describing what kind of
+ type that is--integer, floating, pointer, structure, and so on.
+
+ The file `typeclass.h' defines an enumeration that you can use to
+ interpret the values of `__builtin_classify_type'.
+
+ These machine description macros help implement varargs:
+
+ -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void)
+ If defined, this hook produces the machine-specific code for a
+ call to `__builtin_saveregs'. This code will be moved to the very
+ beginning of the function, before any parameter access are made.
+ The return value of this function should be an RTX that contains
+ the value to use as the return of `__builtin_saveregs'.
+
+ -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (CUMULATIVE_ARGS
+ *ARGS_SO_FAR, enum machine_mode MODE, tree TYPE, int
+ *PRETEND_ARGS_SIZE, int SECOND_TIME)
+ This target hook offers an alternative to using
+ `__builtin_saveregs' and defining the hook
+ `TARGET_EXPAND_BUILTIN_SAVEREGS'. Use it to store the anonymous
+ register arguments into the stack so that all the arguments appear
+ to have been passed consecutively on the stack. Once this is
+ done, you can use the standard implementation of varargs that
+ works for machines that pass all their arguments on the stack.
+
+ The argument ARGS_SO_FAR points to the `CUMULATIVE_ARGS' data
+ structure, containing the values that are obtained after
+ processing the named arguments. The arguments MODE and TYPE
+ describe the last named argument--its machine mode and its data
+ type as a tree node.
+
+ The target hook should do two things: first, push onto the stack
+ all the argument registers _not_ used for the named arguments, and
+ second, store the size of the data thus pushed into the
+ `int'-valued variable pointed to by PRETEND_ARGS_SIZE. The value
+ that you store here will serve as additional offset for setting up
+ the stack frame.
+
+ Because you must generate code to push the anonymous arguments at
+ compile time without knowing their data types,
+ `TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that
+ have just a single category of argument register and use it
+ uniformly for all data types.
+
+ If the argument SECOND_TIME is nonzero, it means that the
+ arguments of the function are being analyzed for the second time.
+ This happens for an inline function, which is not actually
+ compiled until the end of the source file. The hook
+ `TARGET_SETUP_INCOMING_VARARGS' should not generate any
+ instructions in this case.
+
+ -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (CUMULATIVE_ARGS
+ *CA)
+ Define this hook to return `true' if the location where a function
+ argument is passed depends on whether or not it is a named
+ argument.
+
+ This hook controls how the NAMED argument to `FUNCTION_ARG' is set
+ for varargs and stdarg functions. If this hook returns `true',
+ the NAMED argument is always true for named arguments, and false
+ for unnamed arguments. If it returns `false', but
+ `TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns `true', then all
+ arguments are treated as named. Otherwise, all named arguments
+ except the last are treated as named.
+
+ You need not define this hook if it always returns zero.
+
+ -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED
+ If you need to conditionally change ABIs so that one works with
+ `TARGET_SETUP_INCOMING_VARARGS', but the other works like neither
+ `TARGET_SETUP_INCOMING_VARARGS' nor
+ `TARGET_STRICT_ARGUMENT_NAMING' was defined, then define this hook
+ to return `true' if `TARGET_SETUP_INCOMING_VARARGS' is used,
+ `false' otherwise. Otherwise, you should not define this hook.
+
+\1f
+File: gccint.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros
+
+17.12 Trampolines for Nested Functions
+======================================
+
+A "trampoline" is a small piece of code that is created at run time
+when the address of a nested function is taken. It normally resides on
+the stack, in the stack frame of the containing function. These macros
+tell GCC how to generate code to allocate and initialize a trampoline.
+
+ The instructions in the trampoline must do two things: load a constant
+address into the static chain register, and jump to the real address of
+the nested function. On CISC machines such as the m68k, this requires
+two instructions, a move immediate and a jump. Then the two addresses
+exist in the trampoline as word-long immediate operands. On RISC
+machines, it is often necessary to load each address into a register in
+two parts. Then pieces of each address form separate immediate
+operands.
+
+ The code generated to initialize the trampoline must store the variable
+parts--the static chain value and the function address--into the
+immediate operands of the instructions. On a CISC machine, this is
+simply a matter of copying each address to a memory reference at the
+proper offset from the start of the trampoline. On a RISC machine, it
+may be necessary to take out pieces of the address and store them
+separately.
+
+ -- Macro: TRAMPOLINE_TEMPLATE (FILE)
+ A C statement to output, on the stream FILE, assembler code for a
+ block of data that contains the constant parts of a trampoline.
+ This code should not include a label--the label is taken care of
+ automatically.
+
+ If you do not define this macro, it means no template is needed
+ for the target. Do not define this macro on systems where the
+ block move code to copy the trampoline into place would be larger
+ than the code to generate it on the spot.
+
+ -- Macro: TRAMPOLINE_SECTION
+ Return the section into which the trampoline template is to be
+ placed (*note Sections::). The default value is
+ `readonly_data_section'.
+
+ -- Macro: TRAMPOLINE_SIZE
+ A C expression for the size in bytes of the trampoline, as an
+ integer.
+
+ -- Macro: TRAMPOLINE_ALIGNMENT
+ Alignment required for trampolines, in bits.
+
+ If you don't define this macro, the value of `BIGGEST_ALIGNMENT'
+ is used for aligning trampolines.
+
+ -- Macro: INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN)
+ A C statement to initialize the variable parts of a trampoline.
+ ADDR is an RTX for the address of the trampoline; FNADDR is an RTX
+ for the address of the nested function; STATIC_CHAIN is an RTX for
+ the static chain value that should be passed to the function when
+ it is called.
+
+ -- Macro: TRAMPOLINE_ADJUST_ADDRESS (ADDR)
+ A C statement that should perform any machine-specific adjustment
+ in the address of the trampoline. Its argument contains the
+ address that was passed to `INITIALIZE_TRAMPOLINE'. In case the
+ address to be used for a function call should be different from
+ the address in which the template was stored, the different
+ address should be assigned to ADDR. If this macro is not defined,
+ ADDR will be used for function calls.
+
+ If this macro is not defined, by default the trampoline is
+ allocated as a stack slot. This default is right for most
+ machines. The exceptions are machines where it is impossible to
+ execute instructions in the stack area. On such machines, you may
+ have to implement a separate stack, using this macro in
+ conjunction with `TARGET_ASM_FUNCTION_PROLOGUE' and
+ `TARGET_ASM_FUNCTION_EPILOGUE'.
+
+ FP points to a data structure, a `struct function', which
+ describes the compilation status of the immediate containing
+ function of the function which the trampoline is for. The stack
+ slot for the trampoline is in the stack frame of this containing
+ function. Other allocation strategies probably must do something
+ analogous with this information.
+
+ Implementing trampolines is difficult on many machines because they
+have separate instruction and data caches. Writing into a stack
+location fails to clear the memory in the instruction cache, so when
+the program jumps to that location, it executes the old contents.
+
+ Here are two possible solutions. One is to clear the relevant parts of
+the instruction cache whenever a trampoline is set up. The other is to
+make all trampolines identical, by having them jump to a standard
+subroutine. The former technique makes trampoline execution faster; the
+latter makes initialization faster.
+
+ To clear the instruction cache when a trampoline is initialized, define
+the following macro.
+
+ -- Macro: CLEAR_INSN_CACHE (BEG, END)
+ If defined, expands to a C expression clearing the _instruction
+ cache_ in the specified interval. The definition of this macro
+ would typically be a series of `asm' statements. Both BEG and END
+ are both pointer expressions.
+
+ The operating system may also require the stack to be made executable
+before calling the trampoline. To implement this requirement, define
+the following macro.
+
+ -- Macro: ENABLE_EXECUTE_STACK
+ Define this macro if certain operations must be performed before
+ executing code located on the stack. The macro should expand to a
+ series of C file-scope constructs (e.g. functions) and provide a
+ unique entry point named `__enable_execute_stack'. The target is
+ responsible for emitting calls to the entry point in the code, for
+ example from the `INITIALIZE_TRAMPOLINE' macro.
+
+ To use a standard subroutine, define the following macro. In addition,
+you must make sure that the instructions in a trampoline fill an entire
+cache line with identical instructions, or else ensure that the
+beginning of the trampoline code is always aligned at the same point in
+its cache line. Look in `m68k.h' as a guide.
+
+ -- Macro: TRANSFER_FROM_TRAMPOLINE
+ Define this macro if trampolines need a special subroutine to do
+ their work. The macro should expand to a series of `asm'
+ statements which will be compiled with GCC. They go in a library
+ function named `__transfer_from_trampoline'.
+
+ If you need to avoid executing the ordinary prologue code of a
+ compiled C function when you jump to the subroutine, you can do so
+ by placing a special label of your own in the assembler code. Use
+ one `asm' statement to generate an assembler label, and another to
+ make the label global. Then trampolines can use that label to
+ jump directly to your special assembler code.
+
+\1f
+File: gccint.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros
+
+17.13 Implicit Calls to Library Routines
+========================================
+
+Here is an explanation of implicit calls to library routines.
+
+ -- Macro: DECLARE_LIBRARY_RENAMES
+ This macro, if defined, should expand to a piece of C code that
+ will get expanded when compiling functions for libgcc.a. It can
+ be used to provide alternate names for GCC's internal library
+ functions if there are ABI-mandated names that the compiler should
+ provide.
+
+ -- Target Hook: void TARGET_INIT_LIBFUNCS (void)
+ This hook should declare additional library routines or rename
+ existing ones, using the functions `set_optab_libfunc' and
+ `init_one_libfunc' defined in `optabs.c'. `init_optabs' calls
+ this macro after initializing all the normal library routines.
+
+ The default is to do nothing. Most ports don't need to define
+ this hook.
+
+ -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON)
+ This macro should return `true' if the library routine that
+ implements the floating point comparison operator COMPARISON in
+ mode MODE will return a boolean, and FALSE if it will return a
+ tristate.
+
+ GCC's own floating point libraries return tristates from the
+ comparison operators, so the default returns false always. Most
+ ports don't need to define this macro.
+
+ -- Macro: TARGET_LIB_INT_CMP_BIASED
+ This macro should evaluate to `true' if the integer comparison
+ functions (like `__cmpdi2') return 0 to indicate that the first
+ operand is smaller than the second, 1 to indicate that they are
+ equal, and 2 to indicate that the first operand is greater than
+ the second. If this macro evaluates to `false' the comparison
+ functions return -1, 0, and 1 instead of 0, 1, and 2. If the
+ target uses the routines in `libgcc.a', you do not need to define
+ this macro.
+
+ -- Macro: US_SOFTWARE_GOFAST
+ Define this macro if your system C library uses the US Software
+ GOFAST library to provide floating point emulation.
+
+ In addition to defining this macro, your architecture must set
+ `TARGET_INIT_LIBFUNCS' to `gofast_maybe_init_libfuncs', or else
+ call that function from its version of that hook. It is defined
+ in `config/gofast.h', which must be included by your
+ architecture's `CPU.c' file. See `sparc/sparc.c' for an example.
+
+ If this macro is defined, the
+ `TARGET_FLOAT_LIB_COMPARE_RETURNS_BOOL' target hook must return
+ false for `SFmode' and `DFmode' comparisons.
+
+ -- Macro: TARGET_EDOM
+ The value of `EDOM' on the target machine, as a C integer constant
+ expression. If you don't define this macro, GCC does not attempt
+ to deposit the value of `EDOM' into `errno' directly. Look in
+ `/usr/include/errno.h' to find the value of `EDOM' on your system.
+
+ If you do not define `TARGET_EDOM', then compiled code reports
+ domain errors by calling the library function and letting it
+ report the error. If mathematical functions on your system use
+ `matherr' when there is an error, then you should leave
+ `TARGET_EDOM' undefined so that `matherr' is used normally.
+
+ -- Macro: GEN_ERRNO_RTX
+ Define this macro as a C expression to create an rtl expression
+ that refers to the global "variable" `errno'. (On certain systems,
+ `errno' may not actually be a variable.) If you don't define this
+ macro, a reasonable default is used.
+
+ -- Macro: TARGET_C99_FUNCTIONS
+ When this macro is nonzero, GCC will implicitly optimize `sin'
+ calls into `sinf' and similarly for other functions defined by C99
+ standard. The default is zero because a number of existing
+ systems lack support for these functions in their runtime so this
+ macro needs to be redefined to one on systems that do support the
+ C99 runtime.
+
+ -- Macro: TARGET_HAS_SINCOS
+ When this macro is nonzero, GCC will implicitly optimize calls to
+ `sin' and `cos' with the same argument to a call to `sincos'. The
+ default is zero. The target has to provide the following
+ functions:
+ void sincos(double x, double *sin, double *cos);
+ void sincosf(float x, float *sin, float *cos);
+ void sincosl(long double x, long double *sin, long double *cos);
+
+ -- Macro: NEXT_OBJC_RUNTIME
+ Define this macro to generate code for Objective-C message sending
+ using the calling convention of the NeXT system. This calling
+ convention involves passing the object, the selector and the
+ method arguments all at once to the method-lookup library function.
+
+ The default calling convention passes just the object and the
+ selector to the lookup function, which returns a pointer to the
+ method.
+
+\1f
+File: gccint.info, Node: Addressing Modes, Next: Anchored Addresses, Prev: Library Calls, Up: Target Macros
+
+17.14 Addressing Modes
+======================
+
+This is about addressing modes.
+
+ -- Macro: HAVE_PRE_INCREMENT
+ -- Macro: HAVE_PRE_DECREMENT
+ -- Macro: HAVE_POST_INCREMENT
+ -- Macro: HAVE_POST_DECREMENT
+ A C expression that is nonzero if the machine supports
+ pre-increment, pre-decrement, post-increment, or post-decrement
+ addressing respectively.
+
+ -- Macro: HAVE_PRE_MODIFY_DISP
+ -- Macro: HAVE_POST_MODIFY_DISP
+ A C expression that is nonzero if the machine supports pre- or
+ post-address side-effect generation involving constants other than
+ the size of the memory operand.
+
+ -- Macro: HAVE_PRE_MODIFY_REG
+ -- Macro: HAVE_POST_MODIFY_REG
+ A C expression that is nonzero if the machine supports pre- or
+ post-address side-effect generation involving a register
+ displacement.
+
+ -- Macro: CONSTANT_ADDRESS_P (X)
+ A C expression that is 1 if the RTX X is a constant which is a
+ valid address. On most machines, this can be defined as
+ `CONSTANT_P (X)', but a few machines are more restrictive in which
+ constant addresses are supported.
+
+ -- Macro: CONSTANT_P (X)
+ `CONSTANT_P', which is defined by target-independent code, accepts
+ integer-values expressions whose values are not explicitly known,
+ such as `symbol_ref', `label_ref', and `high' expressions and
+ `const' arithmetic expressions, in addition to `const_int' and
+ `const_double' expressions.
+
+ -- Macro: MAX_REGS_PER_ADDRESS
+ A number, the maximum number of registers that can appear in a
+ valid memory address. Note that it is up to you to specify a
+ value equal to the maximum number that `GO_IF_LEGITIMATE_ADDRESS'
+ would ever accept.
+
+ -- Macro: GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)
+ A C compound statement with a conditional `goto LABEL;' executed
+ if X (an RTX) is a legitimate memory address on the target machine
+ for a memory operand of mode MODE.
+
+ It usually pays to define several simpler macros to serve as
+ subroutines for this one. Otherwise it may be too complicated to
+ understand.
+
+ This macro must exist in two variants: a strict variant and a
+ non-strict one. The strict variant is used in the reload pass. It
+ must be defined so that any pseudo-register that has not been
+ allocated a hard register is considered a memory reference. In
+ contexts where some kind of register is required, a pseudo-register
+ with no hard register must be rejected.
+
+ The non-strict variant is used in other passes. It must be
+ defined to accept all pseudo-registers in every context where some
+ kind of register is required.
+
+ Compiler source files that want to use the strict variant of this
+ macro define the macro `REG_OK_STRICT'. You should use an `#ifdef
+ REG_OK_STRICT' conditional to define the strict variant in that
+ case and the non-strict variant otherwise.
+
+ Subroutines to check for acceptable registers for various purposes
+ (one for base registers, one for index registers, and so on) are
+ typically among the subroutines used to define
+ `GO_IF_LEGITIMATE_ADDRESS'. Then only these subroutine macros
+ need have two variants; the higher levels of macros may be the
+ same whether strict or not.
+
+ Normally, constant addresses which are the sum of a `symbol_ref'
+ and an integer are stored inside a `const' RTX to mark them as
+ constant. Therefore, there is no need to recognize such sums
+ specifically as legitimate addresses. Normally you would simply
+ recognize any `const' as legitimate.
+
+ Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant
+ sums that are not marked with `const'. It assumes that a naked
+ `plus' indicates indexing. If so, then you _must_ reject such
+ naked constant sums as illegitimate addresses, so that none of
+ them will be given to `PRINT_OPERAND_ADDRESS'.
+
+ On some machines, whether a symbolic address is legitimate depends
+ on the section that the address refers to. On these machines,
+ define the target hook `TARGET_ENCODE_SECTION_INFO' to store the
+ information into the `symbol_ref', and then check for it here.
+ When you see a `const', you will have to look inside it to find the
+ `symbol_ref' in order to determine the section. *Note Assembler
+ Format::.
+
+ -- Macro: TARGET_MEM_CONSTRAINT
+ A single character to be used instead of the default `'m''
+ character for general memory addresses. This defines the
+ constraint letter which matches the memory addresses accepted by
+ `GO_IF_LEGITIMATE_ADDRESS_P'. Define this macro if you want to
+ support new address formats in your back end without changing the
+ semantics of the `'m'' constraint. This is necessary in order to
+ preserve functionality of inline assembly constructs using the
+ `'m'' constraint.
+
+ -- Macro: FIND_BASE_TERM (X)
+ A C expression to determine the base term of address X, or to
+ provide a simplified version of X from which `alias.c' can easily
+ find the base term. This macro is used in only two places:
+ `find_base_value' and `find_base_term' in `alias.c'.
+
+ It is always safe for this macro to not be defined. It exists so
+ that alias analysis can understand machine-dependent addresses.
+
+ The typical use of this macro is to handle addresses containing a
+ label_ref or symbol_ref within an UNSPEC.
+
+ -- Macro: LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)
+ A C compound statement that attempts to replace X with a valid
+ memory address for an operand of mode MODE. WIN will be a C
+ statement label elsewhere in the code; the macro definition may use
+
+ GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN);
+
+ to avoid further processing if the address has become legitimate.
+
+ X will always be the result of a call to `break_out_memory_refs',
+ and OLDX will be the operand that was given to that function to
+ produce X.
+
+ The code generated by this macro should not alter the substructure
+ of X. If it transforms X into a more legitimate form, it should
+ assign X (which will always be a C variable) a new value.
+
+ It is not necessary for this macro to come up with a legitimate
+ address. The compiler has standard ways of doing so in all cases.
+ In fact, it is safe to omit this macro. But often a
+ machine-dependent strategy can generate better code.
+
+ -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS,
+ WIN)
+ A C compound statement that attempts to replace X, which is an
+ address that needs reloading, with a valid memory address for an
+ operand of mode MODE. WIN will be a C statement label elsewhere
+ in the code. It is not necessary to define this macro, but it
+ might be useful for performance reasons.
+
+ For example, on the i386, it is sometimes possible to use a single
+ reload register instead of two by reloading a sum of two pseudo
+ registers into a register. On the other hand, for number of RISC
+ processors offsets are limited so that often an intermediate
+ address needs to be generated in order to address a stack slot.
+ By defining `LEGITIMIZE_RELOAD_ADDRESS' appropriately, the
+ intermediate addresses generated for adjacent some stack slots can
+ be made identical, and thus be shared.
+
+ _Note_: This macro should be used with caution. It is necessary
+ to know something of how reload works in order to effectively use
+ this, and it is quite easy to produce macros that build in too
+ much knowledge of reload internals.
+
+ _Note_: This macro must be able to reload an address created by a
+ previous invocation of this macro. If it fails to handle such
+ addresses then the compiler may generate incorrect code or abort.
+
+ The macro definition should use `push_reload' to indicate parts
+ that need reloading; OPNUM, TYPE and IND_LEVELS are usually
+ suitable to be passed unaltered to `push_reload'.
+
+ The code generated by this macro must not alter the substructure of
+ X. If it transforms X into a more legitimate form, it should
+ assign X (which will always be a C variable) a new value. This
+ also applies to parts that you change indirectly by calling
+ `push_reload'.
+
+ The macro definition may use `strict_memory_address_p' to test if
+ the address has become legitimate.
+
+ If you want to change only a part of X, one standard way of doing
+ this is to use `copy_rtx'. Note, however, that it unshares only a
+ single level of rtl. Thus, if the part to be changed is not at the
+ top level, you'll need to replace first the top level. It is not
+ necessary for this macro to come up with a legitimate address;
+ but often a machine-dependent strategy can generate better code.
+
+ -- Macro: GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)
+ A C statement or compound statement with a conditional `goto
+ LABEL;' executed if memory address X (an RTX) can have different
+ meanings depending on the machine mode of the memory reference it
+ is used for or if the address is valid for some modes but not
+ others.
+
+ Autoincrement and autodecrement addresses typically have
+ mode-dependent effects because the amount of the increment or
+ decrement is the size of the operand being addressed. Some
+ machines have other mode-dependent addresses. Many RISC machines
+ have no mode-dependent addresses.
+
+ You may assume that ADDR is a valid address for the machine.
+
+ -- Macro: LEGITIMATE_CONSTANT_P (X)
+ A C expression that is nonzero if X is a legitimate constant for
+ an immediate operand on the target machine. You can assume that X
+ satisfies `CONSTANT_P', so you need not check this. In fact, `1'
+ is a suitable definition for this macro on machines where anything
+ `CONSTANT_P' is valid.
+
+ -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X)
+ This hook is used to undo the possibly obfuscating effects of the
+ `LEGITIMIZE_ADDRESS' and `LEGITIMIZE_RELOAD_ADDRESS' target
+ macros. Some backend implementations of these macros wrap symbol
+ references inside an `UNSPEC' rtx to represent PIC or similar
+ addressing modes. This target hook allows GCC's optimizers to
+ understand the semantics of these opaque `UNSPEC's by converting
+ them back into their original form.
+
+ -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (rtx X)
+ This hook should return true if X is of a form that cannot (or
+ should not) be spilled to the constant pool. The default version
+ of this hook returns false.
+
+ The primary reason to define this hook is to prevent reload from
+ deciding that a non-legitimate constant would be better reloaded
+ from the constant pool instead of spilling and reloading a register
+ holding the constant. This restriction is often true of addresses
+ of TLS symbols for various targets.
+
+ -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (enum
+ machine_mode MODE, rtx X)
+ This hook should return true if pool entries for constant X can be
+ placed in an `object_block' structure. MODE is the mode of X.
+
+ The default version returns false for all constants.
+
+ -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (enum tree_code FN,
+ bool TM_FN, bool SQRT)
+ This hook should return the DECL of a function that implements
+ reciprocal of the builtin function with builtin function code FN,
+ or `NULL_TREE' if such a function is not available. TM_FN is true
+ when FN is a code of a machine-dependent builtin function. When
+ SQRT is true, additional optimizations that apply only to the
+ reciprocal of a square root function are performed, and only
+ reciprocals of `sqrt' function are valid.
+
+ -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void)
+ This hook should return the DECL of a function F that given an
+ address ADDR as an argument returns a mask M that can be used to
+ extract from two vectors the relevant data that resides in ADDR in
+ case ADDR is not properly aligned.
+
+ The autovectorizer, when vectorizing a load operation from an
+ address ADDR that may be unaligned, will generate two vector loads
+ from the two aligned addresses around ADDR. It then generates a
+ `REALIGN_LOAD' operation to extract the relevant data from the two
+ loaded vectors. The first two arguments to `REALIGN_LOAD', V1 and
+ V2, are the two vectors, each of size VS, and the third argument,
+ OFF, defines how the data will be extracted from these two
+ vectors: if OFF is 0, then the returned vector is V2; otherwise,
+ the returned vector is composed from the last VS-OFF elements of
+ V1 concatenated to the first OFF elements of V2.
+
+ If this hook is defined, the autovectorizer will generate a call
+ to F (using the DECL tree that this hook returns) and will use the
+ return value of F as the argument OFF to `REALIGN_LOAD'.
+ Therefore, the mask M returned by F should comply with the
+ semantics expected by `REALIGN_LOAD' described above. If this
+ hook is not defined, then ADDR will be used as the argument OFF to
+ `REALIGN_LOAD', in which case the low log2(VS)-1 bits of ADDR will
+ be considered.
+
+ -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN (tree X)
+ This hook should return the DECL of a function F that implements
+ widening multiplication of the even elements of two input vectors
+ of type X.
+
+ If this hook is defined, the autovectorizer will use it along with
+ the `TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD' target hook when
+ vectorizing widening multiplication in cases that the order of the
+ results does not have to be preserved (e.g. used only by a
+ reduction computation). Otherwise, the `widen_mult_hi/lo' idioms
+ will be used.
+
+ -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD (tree X)
+ This hook should return the DECL of a function F that implements
+ widening multiplication of the odd elements of two input vectors
+ of type X.
+
+ If this hook is defined, the autovectorizer will use it along with
+ the `TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN' target hook when
+ vectorizing widening multiplication in cases that the order of the
+ results does not have to be preserved (e.g. used only by a
+ reduction computation). Otherwise, the `widen_mult_hi/lo' idioms
+ will be used.
+
+ -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_CONVERSION (enum
+ tree_code CODE, tree TYPE)
+ This hook should return the DECL of a function that implements
+ conversion of the input vector of type TYPE. If TYPE is an
+ integral type, the result of the conversion is a vector of
+ floating-point type of the same size. If TYPE is a floating-point
+ type, the result of the conversion is a vector of integral type of
+ the same size. CODE specifies how the conversion is to be applied
+ (truncation, rounding, etc.).
+
+ If this hook is defined, the autovectorizer will use the
+ `TARGET_VECTORIZE_BUILTIN_CONVERSION' target hook when vectorizing
+ conversion. Otherwise, it will return `NULL_TREE'.
+
+ -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
+ (enum built_in_function CODE, tree VEC_TYPE_OUT, tree
+ VEC_TYPE_IN)
+ This hook should return the decl of a function that implements the
+ vectorized variant of the builtin function with builtin function
+ code CODE or `NULL_TREE' if such a function is not available. The
+ return type of the vectorized function shall be of vector type
+ VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN.
+
+\1f
+File: gccint.info, Node: Anchored Addresses, Next: Condition Code, Prev: Addressing Modes, Up: Target Macros
+
+17.15 Anchored Addresses
+========================
+
+GCC usually addresses every static object as a separate entity. For
+example, if we have:
+
+ static int a, b, c;
+ int foo (void) { return a + b + c; }
+
+ the code for `foo' will usually calculate three separate symbolic
+addresses: those of `a', `b' and `c'. On some targets, it would be
+better to calculate just one symbolic address and access the three
+variables relative to it. The equivalent pseudocode would be something
+like:
+
+ int foo (void)
+ {
+ register int *xr = &x;
+ return xr[&a - &x] + xr[&b - &x] + xr[&c - &x];
+ }
+
+ (which isn't valid C). We refer to shared addresses like `x' as
+"section anchors". Their use is controlled by `-fsection-anchors'.
+
+ The hooks below describe the target properties that GCC needs to know
+in order to make effective use of section anchors. It won't use
+section anchors at all unless either `TARGET_MIN_ANCHOR_OFFSET' or
+`TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value.
+
+ -- Variable: Target Hook HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET
+ The minimum offset that should be applied to a section anchor. On
+ most targets, it should be the smallest offset that can be applied
+ to a base register while still giving a legitimate address for
+ every mode. The default value is 0.
+
+ -- Variable: Target Hook HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET
+ Like `TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive)
+ offset that should be applied to section anchors. The default
+ value is 0.
+
+ -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X)
+ Write the assembly code to define section anchor X, which is a
+ `SYMBOL_REF' for which `SYMBOL_REF_ANCHOR_P (X)' is true. The
+ hook is called with the assembly output position set to the
+ beginning of `SYMBOL_REF_BLOCK (X)'.
+
+ If `ASM_OUTPUT_DEF' is available, the hook's default definition
+ uses it to define the symbol as `. + SYMBOL_REF_BLOCK_OFFSET (X)'.
+ If `ASM_OUTPUT_DEF' is not available, the hook's default definition
+ is `NULL', which disables the use of section anchors altogether.
+
+ -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (rtx X)
+ Return true if GCC should attempt to use anchors to access
+ `SYMBOL_REF' X. You can assume `SYMBOL_REF_HAS_BLOCK_INFO_P (X)'
+ and `!SYMBOL_REF_ANCHOR_P (X)'.
+
+ The default version is correct for most targets, but you might
+ need to intercept this hook to handle things like target-specific
+ attributes or target-specific sections.
+
+\1f
+File: gccint.info, Node: Condition Code, Next: Costs, Prev: Anchored Addresses, Up: Target Macros
+
+17.16 Condition Code Status
+===========================
+
+This describes the condition code status.
+
+ The file `conditions.h' defines a variable `cc_status' to describe how
+the condition code was computed (in case the interpretation of the
+condition code depends on the instruction that it was set by). This
+variable contains the RTL expressions on which the condition code is
+currently based, and several standard flags.
+
+ Sometimes additional machine-specific flags must be defined in the
+machine description header file. It can also add additional
+machine-specific information by defining `CC_STATUS_MDEP'.
+
+ -- Macro: CC_STATUS_MDEP
+ C code for a data type which is used for declaring the `mdep'
+ component of `cc_status'. It defaults to `int'.
+
+ This macro is not used on machines that do not use `cc0'.
+
+ -- Macro: CC_STATUS_MDEP_INIT
+ A C expression to initialize the `mdep' field to "empty". The
+ default definition does nothing, since most machines don't use the
+ field anyway. If you want to use the field, you should probably
+ define this macro to initialize it.
+
+ This macro is not used on machines that do not use `cc0'.
+
+ -- Macro: NOTICE_UPDATE_CC (EXP, INSN)
+ A C compound statement to set the components of `cc_status'
+ appropriately for an insn INSN whose body is EXP. It is this
+ macro's responsibility to recognize insns that set the condition
+ code as a byproduct of other activity as well as those that
+ explicitly set `(cc0)'.
+
+ This macro is not used on machines that do not use `cc0'.
+
+ If there are insns that do not set the condition code but do alter
+ other machine registers, this macro must check to see whether they
+ invalidate the expressions that the condition code is recorded as
+ reflecting. For example, on the 68000, insns that store in address
+ registers do not set the condition code, which means that usually
+ `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns.
+ But suppose that the previous insn set the condition code based on
+ location `a4@(102)' and the current insn stores a new value in
+ `a4'. Although the condition code is not changed by this, it will
+ no longer be true that it reflects the contents of `a4@(102)'.
+ Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case
+ to say that nothing is known about the condition code value.
+
+ The definition of `NOTICE_UPDATE_CC' must be prepared to deal with
+ the results of peephole optimization: insns whose patterns are
+ `parallel' RTXs containing various `reg', `mem' or constants which
+ are just the operands. The RTL structure of these insns is not
+ sufficient to indicate what the insns actually do. What
+ `NOTICE_UPDATE_CC' should do when it sees one is just to run
+ `CC_STATUS_INIT'.
+
+ A possible definition of `NOTICE_UPDATE_CC' is to call a function
+ that looks at an attribute (*note Insn Attributes::) named, for
+ example, `cc'. This avoids having detailed information about
+ patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'.
+
+ -- Macro: SELECT_CC_MODE (OP, X, Y)
+ Returns a mode from class `MODE_CC' to be used when comparison
+ operation code OP is applied to rtx X and Y. For example, on the
+ SPARC, `SELECT_CC_MODE' is defined as (see *note Jump Patterns::
+ for a description of the reason for this definition)
+
+ #define SELECT_CC_MODE(OP,X,Y) \
+ (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \
+ ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode) \
+ : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \
+ || GET_CODE (X) == NEG) \
+ ? CC_NOOVmode : CCmode))
+
+ You should define this macro if and only if you define extra CC
+ modes in `MACHINE-modes.def'.
+
+ -- Macro: CANONICALIZE_COMPARISON (CODE, OP0, OP1)
+ On some machines not all possible comparisons are defined, but you
+ can convert an invalid comparison into a valid one. For example,
+ the Alpha does not have a `GT' comparison, but you can use an `LT'
+ comparison instead and swap the order of the operands.
+
+ On such machines, define this macro to be a C statement to do any
+ required conversions. CODE is the initial comparison code and OP0
+ and OP1 are the left and right operands of the comparison,
+ respectively. You should modify CODE, OP0, and OP1 as required.
+
+ GCC will not assume that the comparison resulting from this macro
+ is valid but will see if the resulting insn matches a pattern in
+ the `md' file.
+
+ You need not define this macro if it would never change the
+ comparison code or operands.
+
+ -- Macro: REVERSIBLE_CC_MODE (MODE)
+ A C expression whose value is one if it is always safe to reverse a
+ comparison whose mode is MODE. If `SELECT_CC_MODE' can ever
+ return MODE for a floating-point inequality comparison, then
+ `REVERSIBLE_CC_MODE (MODE)' must be zero.
+
+ You need not define this macro if it would always returns zero or
+ if the floating-point format is anything other than
+ `IEEE_FLOAT_FORMAT'. For example, here is the definition used on
+ the SPARC, where floating-point inequality comparisons are always
+ given `CCFPEmode':
+
+ #define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode)
+
+ -- Macro: REVERSE_CONDITION (CODE, MODE)
+ A C expression whose value is reversed condition code of the CODE
+ for comparison done in CC_MODE MODE. The macro is used only in
+ case `REVERSIBLE_CC_MODE (MODE)' is nonzero. Define this macro in
+ case machine has some non-standard way how to reverse certain
+ conditionals. For instance in case all floating point conditions
+ are non-trapping, compiler may freely convert unordered compares
+ to ordered one. Then definition may look like:
+
+ #define REVERSE_CONDITION(CODE, MODE) \
+ ((MODE) != CCFPmode ? reverse_condition (CODE) \
+ : reverse_condition_maybe_unordered (CODE))
+
+ -- Macro: REVERSE_CONDEXEC_PREDICATES_P (OP1, OP2)
+ A C expression that returns true if the conditional execution
+ predicate OP1, a comparison operation, is the inverse of OP2 and
+ vice versa. Define this to return 0 if the target has conditional
+ execution predicates that cannot be reversed safely. There is no
+ need to validate that the arguments of op1 and op2 are the same,
+ this is done separately. If no expansion is specified, this macro
+ is defined as follows:
+
+ #define REVERSE_CONDEXEC_PREDICATES_P (x, y) \
+ (GET_CODE ((x)) == reversed_comparison_code ((y), NULL))
+
+ -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int *,
+ unsigned int *)
+ On targets which do not use `(cc0)', and which use a hard register
+ rather than a pseudo-register to hold condition codes, the regular
+ CSE passes are often not able to identify cases in which the hard
+ register is set to a common value. Use this hook to enable a
+ small pass which optimizes such cases. This hook should return
+ true to enable this pass, and it should set the integers to which
+ its arguments point to the hard register numbers used for
+ condition codes. When there is only one such register, as is true
+ on most systems, the integer pointed to by the second argument
+ should be set to `INVALID_REGNUM'.
+
+ The default version of this hook returns false.
+
+ -- Target Hook: enum machine_mode TARGET_CC_MODES_COMPATIBLE (enum
+ machine_mode, enum machine_mode)
+ On targets which use multiple condition code modes in class
+ `MODE_CC', it is sometimes the case that a comparison can be
+ validly done in more than one mode. On such a system, define this
+ target hook to take two mode arguments and to return a mode in
+ which both comparisons may be validly done. If there is no such
+ mode, return `VOIDmode'.
+
+ The default version of this hook checks whether the modes are the
+ same. If they are, it returns that mode. If they are different,
+ it returns `VOIDmode'.
+
+\1f
+File: gccint.info, Node: Costs, Next: Scheduling, Prev: Condition Code, Up: Target Macros
+
+17.17 Describing Relative Costs of Operations
+=============================================
+
+These macros let you describe the relative speed of various operations
+on the target machine.
+
+ -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO)
+ A C expression for the cost of moving data of mode MODE from a
+ register in class FROM to one in class TO. The classes are
+ expressed using the enumeration values such as `GENERAL_REGS'. A
+ value of 2 is the default; other values are interpreted relative to
+ that.
+
+ It is not required that the cost always equal 2 when FROM is the
+ same as TO; on some machines it is expensive to move between
+ registers if they are not general registers.
+
+ If reload sees an insn consisting of a single `set' between two
+ hard registers, and if `REGISTER_MOVE_COST' applied to their
+ classes returns a value of 2, reload does not check to ensure that
+ the constraints of the insn are met. Setting a cost of other than
+ 2 will allow reload to verify that the constraints are met. You
+ should do this if the `movM' pattern's constraints do not allow
+ such copying.
+
+ -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN)
+ A C expression for the cost of moving data of mode MODE between a
+ register of class CLASS and memory; IN is zero if the value is to
+ be written to memory, nonzero if it is to be read in. This cost
+ is relative to those in `REGISTER_MOVE_COST'. If moving between
+ registers and memory is more expensive than between two registers,
+ you should define this macro to express the relative cost.
+
+ If you do not define this macro, GCC uses a default cost of 4 plus
+ the cost of copying via a secondary reload register, if one is
+ needed. If your machine requires a secondary reload register to
+ copy between memory and a register of CLASS but the reload
+ mechanism is more complex than copying via an intermediate, define
+ this macro to reflect the actual cost of the move.
+
+ GCC defines the function `memory_move_secondary_cost' if secondary
+ reloads are needed. It computes the costs due to copying via a
+ secondary register. If your machine copies from memory using a
+ secondary register in the conventional way but the default base
+ value of 4 is not correct for your machine, define this macro to
+ add some other value to the result of that function. The
+ arguments to that function are the same as to this macro.
+
+ -- Macro: BRANCH_COST (SPEED_P, PREDICTABLE_P)
+ A C expression for the cost of a branch instruction. A value of 1
+ is the default; other values are interpreted relative to that.
+ Parameter SPEED_P is true when the branch in question should be
+ optimized for speed. When it is false, `BRANCH_COST' should be
+ returning value optimal for code size rather then performance
+ considerations. PREDICTABLE_P is true for well predictable
+ branches. On many architectures the `BRANCH_COST' can be reduced
+ then.
+
+ Here are additional macros which do not specify precise relative costs,
+but only that certain actions are more expensive than GCC would
+ordinarily expect.
+
+ -- Macro: SLOW_BYTE_ACCESS
+ Define this macro as a C expression which is nonzero if accessing
+ less than a word of memory (i.e. a `char' or a `short') is no
+ faster than accessing a word of memory, i.e., if such access
+ require more than one instruction or if there is no difference in
+ cost between byte and (aligned) word loads.
+
+ When this macro is not defined, the compiler will access a field by
+ finding the smallest containing object; when it is defined, a
+ fullword load will be used if alignment permits. Unless bytes
+ accesses are faster than word accesses, using word accesses is
+ preferable since it may eliminate subsequent memory access if
+ subsequent accesses occur to other fields in the same word of the
+ structure, but to different bytes.
+
+ -- Macro: SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT)
+ Define this macro to be the value 1 if memory accesses described
+ by the MODE and ALIGNMENT parameters have a cost many times greater
+ than aligned accesses, for example if they are emulated in a trap
+ handler.
+
+ When this macro is nonzero, the compiler will act as if
+ `STRICT_ALIGNMENT' were nonzero when generating code for block
+ moves. This can cause significantly more instructions to be
+ produced. Therefore, do not set this macro nonzero if unaligned
+ accesses only add a cycle or two to the time for a memory access.
+
+ If the value of this macro is always zero, it need not be defined.
+ If this macro is defined, it should produce a nonzero value when
+ `STRICT_ALIGNMENT' is nonzero.
+
+ -- Macro: MOVE_RATIO
+ The threshold of number of scalar memory-to-memory move insns,
+ _below_ which a sequence of insns should be generated instead of a
+ string move insn or a library call. Increasing the value will
+ always make code faster, but eventually incurs high cost in
+ increased code size.
+
+ Note that on machines where the corresponding move insn is a
+ `define_expand' that emits a sequence of insns, this macro counts
+ the number of such sequences.
+
+ If you don't define this, a reasonable default is used.
+
+ -- Macro: MOVE_BY_PIECES_P (SIZE, ALIGNMENT)
+ A C expression used to determine whether `move_by_pieces' will be
+ used to copy a chunk of memory, or whether some other block move
+ mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns'
+ returns less than `MOVE_RATIO'.
+
+ -- Macro: MOVE_MAX_PIECES
+ A C expression used by `move_by_pieces' to determine the largest
+ unit a load or store used to copy memory is. Defaults to
+ `MOVE_MAX'.
+
+ -- Macro: CLEAR_RATIO
+ The threshold of number of scalar move insns, _below_ which a
+ sequence of insns should be generated to clear memory instead of a
+ string clear insn or a library call. Increasing the value will
+ always make code faster, but eventually incurs high cost in
+ increased code size.
+
+ If you don't define this, a reasonable default is used.
+
+ -- Macro: CLEAR_BY_PIECES_P (SIZE, ALIGNMENT)
+ A C expression used to determine whether `clear_by_pieces' will be
+ used to clear a chunk of memory, or whether some other block clear
+ mechanism will be used. Defaults to 1 if `move_by_pieces_ninsns'
+ returns less than `CLEAR_RATIO'.
+
+ -- Macro: SET_RATIO
+ The threshold of number of scalar move insns, _below_ which a
+ sequence of insns should be generated to set memory to a constant
+ value, instead of a block set insn or a library call. Increasing
+ the value will always make code faster, but eventually incurs high
+ cost in increased code size.
+
+ If you don't define this, it defaults to the value of `MOVE_RATIO'.
+
+ -- Macro: SET_BY_PIECES_P (SIZE, ALIGNMENT)
+ A C expression used to determine whether `store_by_pieces' will be
+ used to set a chunk of memory to a constant value, or whether some
+ other mechanism will be used. Used by `__builtin_memset' when
+ storing values other than constant zero. Defaults to 1 if
+ `move_by_pieces_ninsns' returns less than `SET_RATIO'.
+
+ -- Macro: STORE_BY_PIECES_P (SIZE, ALIGNMENT)
+ A C expression used to determine whether `store_by_pieces' will be
+ used to set a chunk of memory to a constant string value, or
+ whether some other mechanism will be used. Used by
+ `__builtin_strcpy' when called with a constant source string.
+ Defaults to 1 if `move_by_pieces_ninsns' returns less than
+ `MOVE_RATIO'.
+
+ -- Macro: USE_LOAD_POST_INCREMENT (MODE)
+ A C expression used to determine whether a load postincrement is a
+ good thing to use for a given mode. Defaults to the value of
+ `HAVE_POST_INCREMENT'.
+
+ -- Macro: USE_LOAD_POST_DECREMENT (MODE)
+ A C expression used to determine whether a load postdecrement is a
+ good thing to use for a given mode. Defaults to the value of
+ `HAVE_POST_DECREMENT'.
+
+ -- Macro: USE_LOAD_PRE_INCREMENT (MODE)
+ A C expression used to determine whether a load preincrement is a
+ good thing to use for a given mode. Defaults to the value of
+ `HAVE_PRE_INCREMENT'.
+
+ -- Macro: USE_LOAD_PRE_DECREMENT (MODE)
+ A C expression used to determine whether a load predecrement is a
+ good thing to use for a given mode. Defaults to the value of
+ `HAVE_PRE_DECREMENT'.
+
+ -- Macro: USE_STORE_POST_INCREMENT (MODE)
+ A C expression used to determine whether a store postincrement is
+ a good thing to use for a given mode. Defaults to the value of
+ `HAVE_POST_INCREMENT'.
+
+ -- Macro: USE_STORE_POST_DECREMENT (MODE)
+ A C expression used to determine whether a store postdecrement is
+ a good thing to use for a given mode. Defaults to the value of
+ `HAVE_POST_DECREMENT'.
+
+ -- Macro: USE_STORE_PRE_INCREMENT (MODE)
+ This macro is used to determine whether a store preincrement is a
+ good thing to use for a given mode. Defaults to the value of
+ `HAVE_PRE_INCREMENT'.
+
+ -- Macro: USE_STORE_PRE_DECREMENT (MODE)
+ This macro is used to determine whether a store predecrement is a
+ good thing to use for a given mode. Defaults to the value of
+ `HAVE_PRE_DECREMENT'.
+
+ -- Macro: NO_FUNCTION_CSE
+ Define this macro if it is as good or better to call a constant
+ function address than to call an address kept in a register.
+
+ -- Macro: RANGE_TEST_NON_SHORT_CIRCUIT
+ Define this macro if a non-short-circuit operation produced by
+ `fold_range_test ()' is optimal. This macro defaults to true if
+ `BRANCH_COST' is greater than or equal to the value 2.
+
+ -- Target Hook: bool TARGET_RTX_COSTS (rtx X, int CODE, int
+ OUTER_CODE, int *TOTAL)
+ This target hook describes the relative costs of RTL expressions.
+
+ The cost may depend on the precise form of the expression, which is
+ available for examination in X, and the rtx code of the expression
+ in which it is contained, found in OUTER_CODE. CODE is the
+ expression code--redundant, since it can be obtained with
+ `GET_CODE (X)'.
+
+ In implementing this hook, you can use the construct
+ `COSTS_N_INSNS (N)' to specify a cost equal to N fast instructions.
+
+ On entry to the hook, `*TOTAL' contains a default estimate for the
+ cost of the expression. The hook should modify this value as
+ necessary. Traditionally, the default costs are `COSTS_N_INSNS
+ (5)' for multiplications, `COSTS_N_INSNS (7)' for division and
+ modulus operations, and `COSTS_N_INSNS (1)' for all other
+ operations.
+
+ When optimizing for code size, i.e. when `optimize_size' is
+ nonzero, this target hook should be used to estimate the relative
+ size cost of an expression, again relative to `COSTS_N_INSNS'.
+
+ The hook returns true when all subexpressions of X have been
+ processed, and false when `rtx_cost' should recurse.
+
+ -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS)
+ This hook computes the cost of an addressing mode that contains
+ ADDRESS. If not defined, the cost is computed from the ADDRESS
+ expression and the `TARGET_RTX_COST' hook.
+
+ For most CISC machines, the default cost is a good approximation
+ of the true cost of the addressing mode. However, on RISC
+ machines, all instructions normally have the same length and
+ execution time. Hence all addresses will have equal costs.
+
+ In cases where more than one form of an address is known, the form
+ with the lowest cost will be used. If multiple forms have the
+ same, lowest, cost, the one that is the most complex will be used.
+
+ For example, suppose an address that is equal to the sum of a
+ register and a constant is used twice in the same basic block.
+ When this macro is not defined, the address will be computed in a
+ register and memory references will be indirect through that
+ register. On machines where the cost of the addressing mode
+ containing the sum is no higher than that of a simple indirect
+ reference, this will produce an additional instruction and
+ possibly require an additional register. Proper specification of
+ this macro eliminates this overhead for such machines.
+
+ This hook is never called with an invalid address.
+
+ On machines where an address involving more than one register is as
+ cheap as an address computation involving only one register,
+ defining `TARGET_ADDRESS_COST' to reflect this can cause two
+ registers to be live over a region of code where only one would
+ have been if `TARGET_ADDRESS_COST' were not defined in that
+ manner. This effect should be considered in the definition of
+ this macro. Equivalent costs should probably only be given to
+ addresses with different numbers of registers on machines with
+ lots of registers.
+
+\1f
+File: gccint.info, Node: Scheduling, Next: Sections, Prev: Costs, Up: Target Macros
+
+17.18 Adjusting the Instruction Scheduler
+=========================================
+
+The instruction scheduler may need a fair amount of machine-specific
+adjustment in order to produce good code. GCC provides several target
+hooks for this purpose. It is usually enough to define just a few of
+them: try the first ones in this list first.
+
+ -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void)
+ This hook returns the maximum number of instructions that can ever
+ issue at the same time on the target machine. The default is one.
+ Although the insn scheduler can define itself the possibility of
+ issue an insn on the same cycle, the value can serve as an
+ additional constraint to issue insns on the same simulated
+ processor cycle (see hooks `TARGET_SCHED_REORDER' and
+ `TARGET_SCHED_REORDER2'). This value must be constant over the
+ entire compilation. If you need it to vary depending on what the
+ instructions are, you must use `TARGET_SCHED_VARIABLE_ISSUE'.
+
+ -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int
+ VERBOSE, rtx INSN, int MORE)
+ This hook is executed by the scheduler after it has scheduled an
+ insn from the ready list. It should return the number of insns
+ which can still be issued in the current cycle. The default is
+ `MORE - 1' for insns other than `CLOBBER' and `USE', which
+ normally are not counted against the issue rate. You should
+ define this hook if some insns take more machine resources than
+ others, so that fewer insns can follow them in the same cycle.
+ 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.
+
+ -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx INSN, rtx LINK, rtx
+ DEP_INSN, int COST)
+ This function corrects the value of COST based on the relationship
+ between INSN and DEP_INSN through the dependence LINK. It should
+ return the new value. The default is to make no adjustment to
+ COST. This can be used for example to specify to the scheduler
+ using the traditional pipeline description that an output- or
+ anti-dependence does not incur the same cost as a data-dependence.
+ If the scheduler using the automaton based pipeline description,
+ the cost of anti-dependence is zero and the cost of
+ output-dependence is maximum of one and the difference of latency
+ times of the first and the second insns. If these values are not
+ acceptable, you could use the hook to modify them too. See also
+ *note Processor pipeline description::.
+
+ -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx INSN, int
+ PRIORITY)
+ This hook adjusts the integer scheduling priority PRIORITY of
+ INSN. It should return the new priority. Increase the priority to
+ execute INSN earlier, reduce the priority to execute INSN later.
+ Do not define this hook if you do not need to adjust the
+ scheduling priorities of insns.
+
+ -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, rtx
+ *READY, int *N_READYP, int CLOCK)
+ This hook 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_READYP is a
+ pointer to the number of elements in the ready list. The scheduler
+ reads the ready list in reverse order, starting with
+ READY[*N_READYP-1] and going to READY[0]. CLOCK is the timer tick
+ of the scheduler. You may modify the ready list and the number of
+ ready insns. The return value is the number of insns that can
+ issue this cycle; normally this is just `issue_rate'. See also
+ `TARGET_SCHED_REORDER2'.
+
+ -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE,
+ rtx *READY, int *N_READY, CLOCK)
+ Like `TARGET_SCHED_REORDER', but called at a different time. That
+ function is called whenever the scheduler starts a new cycle.
+ This one is called once per iteration over a cycle, immediately
+ after `TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list
+ and return the number of insns to be scheduled in the same cycle.
+ Defining this hook 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.
+
+ -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK (rtx
+ HEAD, rtx TAIL)
+ This hook is called after evaluation forward dependencies of insns
+ in chain given by two parameter values (HEAD and TAIL
+ correspondingly) but before insns scheduling of the insn chain.
+ For example, it can be used for better insn classification if it
+ requires analysis of dependencies. This hook can use backward and
+ forward dependencies of the insn scheduler because they are already
+ calculated.
+
+ -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int
+ MAX_READY)
+ This hook 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, e.g. by
+ `TARGET_SCHED_REORDER'.
+
+ -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE)
+ This hook 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 hooks. 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'.
+
+ -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int
+ VERBOSE, int OLD_MAX_UID)
+ This hook is executed by the scheduler after function level
+ initializations. 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'. OLD_MAX_UID is the maximum insn
+ uid when scheduling begins.
+
+ -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int
+ VERBOSE)
+ This is the cleanup hook corresponding to
+ `TARGET_SCHED_INIT_GLOBAL'. 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'.
+
+ -- Target Hook: int TARGET_SCHED_DFA_PRE_CYCLE_INSN (void)
+ The hook returns an RTL insn. The automaton state used in the
+ pipeline hazard recognizer is changed as if the insn were scheduled
+ when the new simulated processor cycle starts. Usage of the hook
+ may simplify the automaton pipeline description for some VLIW
+ processors. If the hook is defined, it is used only for the
+ automaton based pipeline description. The default is not to
+ change the state when the new simulated processor cycle starts.
+
+ -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void)
+ The hook can be used to initialize data used by the previous hook.
+
+ -- Target Hook: int TARGET_SCHED_DFA_POST_CYCLE_INSN (void)
+ The hook is analogous to `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used
+ to changed the state as if the insn were scheduled when the new
+ simulated processor cycle finishes.
+
+ -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void)
+ The hook is analogous to `TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but
+ used to initialize data used by the previous hook.
+
+ -- Target Hook: void TARGET_SCHED_DFA_PRE_CYCLE_ADVANCE (void)
+ The hook to notify target that the current simulated cycle is
+ about to finish. The hook is analogous to
+ `TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used to change the state in
+ more complicated situations - e.g., when advancing state on a
+ single insn is not enough.
+
+ -- Target Hook: void TARGET_SCHED_DFA_POST_CYCLE_ADVANCE (void)
+ The hook to notify target that new simulated cycle has just
+ started. The hook is analogous to
+ `TARGET_SCHED_DFA_POST_CYCLE_INSN' but used to change the state in
+ more complicated situations - e.g., when advancing state on a
+ single insn is not enough.
+
+ -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD
+ (void)
+ This hook controls better choosing an insn from the ready insn
+ queue for the DFA-based insn scheduler. Usually the scheduler
+ chooses the first insn from the queue. If the hook returns a
+ positive value, an additional scheduler code tries all
+ permutations of `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD
+ ()' subsequent ready insns to choose an insn whose issue will
+ result in maximal number of issued insns on the same cycle. For
+ the VLIW processor, the code could actually solve the problem of
+ packing simple insns into the VLIW insn. Of course, if the rules
+ of VLIW packing are described in the automaton.
+
+ This code also could be used for superscalar RISC processors. Let
+ us consider a superscalar RISC processor with 3 pipelines. Some
+ insns can be executed in pipelines A or B, some insns can be
+ executed only in pipelines B or C, and one insn can be executed in
+ pipeline B. The processor may issue the 1st insn into A and the
+ 2nd one into B. In this case, the 3rd insn will wait for freeing B
+ until the next cycle. If the scheduler issues the 3rd insn the
+ first, the processor could issue all 3 insns per cycle.
+
+ Actually this code demonstrates advantages of the automaton based
+ pipeline hazard recognizer. We try quickly and easy many insn
+ schedules to choose the best one.
+
+ The default is no multipass scheduling.
+
+ -- Target Hook: int
+TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD (rtx)
+ This hook controls what insns from the ready insn queue will be
+ considered for the multipass insn scheduling. If the hook returns
+ zero for insn passed as the parameter, the insn will be not chosen
+ to be issued.
+
+ The default is that any ready insns can be chosen to be issued.
+
+ -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *, int, rtx, int,
+ int, int *)
+ This hook is called by the insn scheduler before issuing insn
+ passed as the third parameter on given cycle. If the hook returns
+ nonzero, the insn is not issued on given processors cycle.
+ Instead of that, the processor cycle is advanced. If the value
+ passed through the last parameter is zero, the insn ready queue is
+ not sorted on the new cycle start as usually. The first parameter
+ passes file for debugging output. The second one passes the
+ scheduler verbose level of the debugging output. The forth and
+ the fifth parameter values are correspondingly processor cycle on
+ which the previous insn has been issued and the current processor
+ cycle.
+
+ -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (struct dep_def
+ *_DEP, int COST, int DISTANCE)
+ This hook is used to define which dependences are considered
+ costly by the target, so costly that it is not advisable to
+ schedule the insns that are involved in the dependence too close
+ to one another. The parameters to this hook are as follows: The
+ first parameter _DEP is the dependence being evaluated. The
+ second parameter COST is the cost of the dependence, and the third
+ parameter DISTANCE is the distance in cycles between the two insns.
+ The hook returns `true' if considering the distance between the two
+ insns the dependence between them is considered costly by the
+ target, and `false' otherwise.
+
+ Defining this hook can be useful in multiple-issue out-of-order
+ machines, where (a) it's practically hopeless to predict the
+ actual data/resource delays, however: (b) there's a better chance
+ to predict the actual grouping that will be formed, and (c)
+ correctly emulating the grouping can be very important. In such
+ targets one may want to allow issuing dependent insns closer to
+ one another--i.e., closer than the dependence distance; however,
+ not in cases of "costly dependences", which this hooks allows to
+ define.
+
+ -- Target Hook: void TARGET_SCHED_H_I_D_EXTENDED (void)
+ This hook is called by the insn scheduler after emitting a new
+ instruction to the instruction stream. The hook notifies a target
+ backend to extend its per instruction data structures.
+
+ -- Target Hook: void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void)
+ Return a pointer to a store large enough to hold target scheduling
+ context.
+
+ -- Target Hook: void TARGET_SCHED_INIT_SCHED_CONTEXT (void *TC, bool
+ CLEAN_P)
+ Initialize store pointed to by TC to hold target scheduling
+ context. It CLEAN_P is true then initialize TC as if scheduler is
+ at the beginning of the block. Otherwise, make a copy of the
+ current context in TC.
+
+ -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC)
+ Copy target scheduling context pointer to by TC to the current
+ context.
+
+ -- Target Hook: void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *TC)
+ Deallocate internal data in target scheduling context pointed to
+ by TC.
+
+ -- Target Hook: void TARGET_SCHED_FREE_SCHED_CONTEXT (void *TC)
+ Deallocate a store for target scheduling context pointed to by TC.
+
+ -- Target Hook: void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void)
+ Return a pointer to a store large enough to hold target scheduling
+ context.
+
+ -- Target Hook: void TARGET_SCHED_INIT_SCHED_CONTEXT (void *TC, bool
+ CLEAN_P)
+ Initialize store pointed to by TC to hold target scheduling
+ context. It CLEAN_P is true then initialize TC as if scheduler is
+ at the beginning of the block. Otherwise, make a copy of the
+ current context in TC.
+
+ -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC)
+ Copy target scheduling context pointer to by TC to the current
+ context.
+
+ -- Target Hook: void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *TC)
+ Deallocate internal data in target scheduling context pointed to
+ by TC.
+
+ -- Target Hook: void TARGET_SCHED_FREE_SCHED_CONTEXT (void *TC)
+ Deallocate a store for target scheduling context pointed to by TC.
+
+ -- Target Hook: int TARGET_SCHED_SPECULATE_INSN (rtx INSN, int
+ REQUEST, rtx *NEW_PAT)
+ This hook is called by the insn scheduler when INSN has only
+ speculative dependencies and therefore can be scheduled
+ speculatively. The hook is used to check if the pattern of INSN
+ has a speculative version and, in case of successful check, to
+ generate that speculative pattern. The hook should return 1, if
+ the instruction has a speculative form, or -1, if it doesn't.
+ REQUEST describes the type of requested speculation. If the
+ return value equals 1 then NEW_PAT is assigned the generated
+ speculative pattern.
+
+ -- Target Hook: int TARGET_SCHED_NEEDS_BLOCK_P (rtx INSN)
+ This hook is called by the insn scheduler during generation of
+ recovery code for INSN. It should return nonzero, if the
+ corresponding check instruction should branch to recovery code, or
+ zero otherwise.
+
+ -- Target Hook: rtx TARGET_SCHED_GEN_CHECK (rtx INSN, rtx LABEL, int
+ MUTATE_P)
+ This hook is called by the insn scheduler to generate a pattern
+ for recovery check instruction. If MUTATE_P is zero, then INSN is
+ a speculative instruction for which the check should be generated.
+ LABEL is either a label of a basic block, where recovery code
+ should be emitted, or a null pointer, when requested check doesn't
+ branch to recovery code (a simple check). If MUTATE_P is nonzero,
+ then a pattern for a branchy check corresponding to a simple check
+ denoted by INSN should be generated. In this case LABEL can't be
+ null.
+
+ -- Target Hook: int
+TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC (rtx INSN)
+ This hook is used as a workaround for
+ `TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD' not being
+ called on the first instruction of the ready list. The hook is
+ used to discard speculative instruction that stand first in the
+ ready list from being scheduled on the current cycle. For
+ non-speculative instructions, the hook should always return
+ nonzero. For example, in the ia64 backend the hook is used to
+ cancel data speculative insns when the ALAT table is nearly full.
+
+ -- Target Hook: void TARGET_SCHED_SET_SCHED_FLAGS (unsigned int
+ *FLAGS, spec_info_t SPEC_INFO)
+ This hook is used by the insn scheduler to find out what features
+ should be enabled/used. FLAGS initially may have either the
+ SCHED_RGN or SCHED_EBB bit set. This denotes the scheduler pass
+ for which the data should be provided. The target backend should
+ modify FLAGS by modifying the bits corresponding to the following
+ features: USE_DEPS_LIST, USE_GLAT, DETACH_LIFE_INFO, and
+ DO_SPECULATION. For the DO_SPECULATION feature an additional
+ structure SPEC_INFO should be filled by the target. The structure
+ describes speculation types that can be used in the scheduler.
+
+ -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G)
+ This hook is called by the swing modulo scheduler to calculate a
+ resource-based lower bound which is based on the resources
+ available in the machine and the resources required by each
+ instruction. The target backend can use G to calculate such
+ bound. A very simple lower bound will be used in case this hook
+ is not implemented: the total number of instructions divided by
+ the issue rate.
+
+\1f
+File: gccint.info, Node: Sections, Next: PIC, Prev: Scheduling, Up: Target Macros
+
+17.19 Dividing the Output into Sections (Texts, Data, ...)
+==========================================================
+
+An object file is divided into sections containing different types of
+data. In the most common case, there are three sections: the "text
+section", which holds instructions and read-only data; the "data
+section", which holds initialized writable data; and the "bss section",
+which holds uninitialized data. Some systems have other kinds of
+sections.
+
+ `varasm.c' provides several well-known sections, such as
+`text_section', `data_section' and `bss_section'. The normal way of
+controlling a `FOO_section' variable is to define the associated
+`FOO_SECTION_ASM_OP' macro, as described below. The macros are only
+read once, when `varasm.c' initializes itself, so their values must be
+run-time constants. They may however depend on command-line flags.
+
+ _Note:_ Some run-time files, such `crtstuff.c', also make use of the
+`FOO_SECTION_ASM_OP' macros, and expect them to be string literals.
+
+ Some assemblers require a different string to be written every time a
+section is selected. If your assembler falls into this category, you
+should define the `TARGET_ASM_INIT_SECTIONS' hook and use
+`get_unnamed_section' to set up the sections.
+
+ You must always create a `text_section', either by defining
+`TEXT_SECTION_ASM_OP' or by initializing `text_section' in
+`TARGET_ASM_INIT_SECTIONS'. The same is true of `data_section' and
+`DATA_SECTION_ASM_OP'. If you do not create a distinct
+`readonly_data_section', the default is to reuse `text_section'.
+
+ All the other `varasm.c' sections are optional, and are null if the
+target does not provide them.
+
+ -- Macro: TEXT_SECTION_ASM_OP
+ A C expression whose value is a string, including spacing,
+ containing the assembler operation that should precede
+ instructions and read-only data. Normally `"\t.text"' is right.
+
+ -- Macro: HOT_TEXT_SECTION_NAME
+ If defined, a C string constant for the name of the section
+ containing most frequently executed functions of the program. If
+ not defined, GCC will provide a default definition if the target
+ supports named sections.
+
+ -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME
+ If defined, a C string constant for the name of the section
+ containing unlikely executed functions in the program.
+
+ -- Macro: DATA_SECTION_ASM_OP
+ A C expression whose value is a string, including spacing,
+ containing the assembler operation to identify the following data
+ as writable initialized data. Normally `"\t.data"' is right.
+
+ -- Macro: SDATA_SECTION_ASM_OP
+ If defined, a C expression whose value is a string, including
+ spacing, containing the assembler operation to identify the
+ following data as initialized, writable small data.
+
+ -- Macro: READONLY_DATA_SECTION_ASM_OP
+ A C expression whose value is a string, including spacing,
+ containing the assembler operation to identify the following data
+ as read-only initialized data.
+
+ -- Macro: BSS_SECTION_ASM_OP
+ If defined, a C expression whose value is a string, including
+ spacing, containing the assembler operation to identify the
+ following data as uninitialized global data. If not defined, and
+ neither `ASM_OUTPUT_BSS' nor `ASM_OUTPUT_ALIGNED_BSS' are defined,
+ uninitialized global data will be output in the data section if
+ `-fno-common' is passed, otherwise `ASM_OUTPUT_COMMON' will be
+ used.
+
+ -- Macro: SBSS_SECTION_ASM_OP
+ If defined, a C expression whose value is a string, including
+ spacing, containing the assembler operation to identify the
+ following data as uninitialized, writable small data.
+
+ -- Macro: INIT_SECTION_ASM_OP
+ If defined, a C expression whose value is a string, including
+ spacing, containing the assembler operation to identify the
+ following data as initialization code. If not defined, GCC will
+ assume such a section does not exist. This section has no
+ corresponding `init_section' variable; it is used entirely in
+ runtime code.
+
+ -- Macro: FINI_SECTION_ASM_OP
+ If defined, a C expression whose value is a string, including
+ spacing, containing the assembler operation to identify the
+ following data as finalization code. If not defined, GCC will
+ assume such a section does not exist. This section has no
+ corresponding `fini_section' variable; it is used entirely in
+ runtime code.
+
+ -- Macro: INIT_ARRAY_SECTION_ASM_OP
+ If defined, a C expression whose value is a string, including
+ spacing, containing the assembler operation to identify the
+ following data as part of the `.init_array' (or equivalent)
+ section. If not defined, GCC will assume such a section does not
+ exist. Do not define both this macro and `INIT_SECTION_ASM_OP'.
+
+ -- Macro: FINI_ARRAY_SECTION_ASM_OP
+ If defined, a C expression whose value is a string, including
+ spacing, containing the assembler operation to identify the
+ following data as part of the `.fini_array' (or equivalent)
+ section. If not defined, GCC will assume such a section does not
+ exist. Do not define both this macro and `FINI_SECTION_ASM_OP'.
+
+ -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION)
+ If defined, an ASM statement that switches to a different section
+ via SECTION_OP, calls FUNCTION, and switches back to the text
+ section. This is used in `crtstuff.c' if `INIT_SECTION_ASM_OP' or
+ `FINI_SECTION_ASM_OP' to calls to initialization and finalization
+ functions from the init and fini sections. By default, this macro
+ uses a simple function call. Some ports need hand-crafted
+ assembly code to avoid dependencies on registers initialized in
+ the function prologue or to ensure that constant pools don't end
+ up too far way in the text section.
+
+ -- Macro: TARGET_LIBGCC_SDATA_SECTION
+ If defined, a string which names the section into which small
+ variables defined in crtstuff and libgcc should go. This is useful
+ when the target has options for optimizing access to small data,
+ and you want the crtstuff and libgcc routines to be conservative
+ in what they expect of your application yet liberal in what your
+ application expects. For example, for targets with a `.sdata'
+ section (like MIPS), you could compile crtstuff with `-G 0' so
+ that it doesn't require small data support from your application,
+ but use this macro to put small data into `.sdata' so that your
+ application can access these variables whether it uses small data
+ or not.
+
+ -- Macro: FORCE_CODE_SECTION_ALIGN
+ If defined, an ASM statement that aligns a code section to some
+ arbitrary boundary. This is used to force all fragments of the
+ `.init' and `.fini' sections to have to same alignment and thus
+ prevent the linker from having to add any padding.
+
+ -- Macro: JUMP_TABLES_IN_TEXT_SECTION
+ Define this macro to be an expression with a nonzero value if jump
+ tables (for `tablejump' insns) should be output in the text
+ section, along with the assembler instructions. Otherwise, the
+ readonly data section is used.
+
+ This macro is irrelevant if there is no separate readonly data
+ section.
+
+ -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void)
+ Define this hook if you need to do something special to set up the
+ `varasm.c' sections, or if your target has some special sections
+ of its own that you need to create.
+
+ GCC calls this hook after processing the command line, but before
+ writing any assembly code, and before calling any of the
+ section-returning hooks described below.
+
+ -- Target Hook: TARGET_ASM_RELOC_RW_MASK (void)
+ Return a mask describing how relocations should be treated when
+ selecting sections. Bit 1 should be set if global relocations
+ should be placed in a read-write section; bit 0 should be set if
+ local relocations should be placed in a read-write section.
+
+ The default version of this function returns 3 when `-fpic' is in
+ effect, and 0 otherwise. The hook is typically redefined when the
+ target cannot support (some kinds of) dynamic relocations in
+ read-only sections even in executables.
+
+ -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int
+ RELOC, unsigned HOST_WIDE_INT ALIGN)
+ Return the section into which EXP should be placed. You can
+ assume that EXP is either a `VAR_DECL' node or a constant of some
+ sort. RELOC indicates whether the initial value of EXP requires
+ link-time relocations. Bit 0 is set when variable contains local
+ relocations only, while bit 1 is set for global relocations.
+ ALIGN is the constant alignment in bits.
+
+ The default version of this function takes care of putting
+ read-only variables in `readonly_data_section'.
+
+ See also USE_SELECT_SECTION_FOR_FUNCTIONS.
+
+ -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS
+ Define this macro if you wish TARGET_ASM_SELECT_SECTION to be
+ called for `FUNCTION_DECL's as well as for variables and constants.
+
+ In the case of a `FUNCTION_DECL', RELOC will be zero if the
+ function has been determined to be likely to be called, and
+ nonzero if it is unlikely to be called.
+
+ -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC)
+ Build up a unique section name, expressed as a `STRING_CST' node,
+ and assign it to `DECL_SECTION_NAME (DECL)'. As with
+ `TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial
+ value of EXP requires link-time relocations.
+
+ The default version of this function appends the symbol name to the
+ ELF section name that would normally be used for the symbol. For
+ example, the function `foo' would be placed in `.text.foo'.
+ Whatever the actual target object format, this is often good
+ enough.
+
+ -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree
+ DECL)
+ Return the readonly data section associated with
+ `DECL_SECTION_NAME (DECL)'. The default version of this function
+ selects `.gnu.linkonce.r.name' if the function's section is
+ `.gnu.linkonce.t.name', `.rodata.name' if function is in
+ `.text.name', and the normal readonly-data section otherwise.
+
+ -- Target Hook: section * TARGET_ASM_SELECT_RTX_SECTION (enum
+ machine_mode MODE, rtx X, unsigned HOST_WIDE_INT ALIGN)
+ Return the section into which a constant X, of mode MODE, should
+ be placed. You can assume that X is some kind of constant in RTL.
+ The argument MODE is redundant except in the case of a `const_int'
+ rtx. ALIGN is the constant alignment in bits.
+
+ The default version of this function takes care of putting symbolic
+ constants in `flag_pic' mode in `data_section' and everything else
+ in `readonly_data_section'.
+
+ -- Target Hook: void TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL,
+ tree ID)
+ Define this hook if you need to postprocess the assembler name
+ generated by target-independent code. The ID provided to this
+ hook will be the computed name (e.g., the macro `DECL_NAME' of the
+ DECL in C, or the mangled name of the DECL in C++). The return
+ value of the hook is an `IDENTIFIER_NODE' for the appropriate
+ mangled name on your target system. The default implementation of
+ this hook just returns the ID provided.
+
+ -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL,
+ int NEW_DECL_P)
+ Define this hook if references to a symbol or a constant must be
+ treated differently depending on something about the variable or
+ function named by the symbol (such as what section it is in).
+
+ The hook is executed immediately after rtl has been created for
+ DECL, which may be a variable or function declaration or an entry
+ in the constant pool. In either case, RTL is the rtl in question.
+ Do _not_ use `DECL_RTL (DECL)' in this hook; that field may not
+ have been initialized yet.
+
+ In the case of a constant, it is safe to assume that the rtl is a
+ `mem' whose address is a `symbol_ref'. Most decls will also have
+ this form, but that is not guaranteed. Global register variables,
+ for instance, will have a `reg' for their rtl. (Normally the
+ right thing to do with such unusual rtl is leave it alone.)
+
+ The NEW_DECL_P argument will be true if this is the first time
+ that `TARGET_ENCODE_SECTION_INFO' has been invoked on this decl.
+ It will be false for subsequent invocations, which will happen for
+ duplicate declarations. Whether or not anything must be done for
+ the duplicate declaration depends on whether the hook examines
+ `DECL_ATTRIBUTES'. NEW_DECL_P is always true when the hook is
+ called for a constant.
+
+ The usual thing for this hook to do is to record flags in the
+ `symbol_ref', using `SYMBOL_REF_FLAG' or `SYMBOL_REF_FLAGS'.
+ Historically, the name string was modified if it was necessary to
+ encode more than one bit of information, but this practice is now
+ discouraged; use `SYMBOL_REF_FLAGS'.
+
+ The default definition of this hook, `default_encode_section_info'
+ in `varasm.c', sets a number of commonly-useful bits in
+ `SYMBOL_REF_FLAGS'. Check whether the default does what you need
+ before overriding it.
+
+ -- Target Hook: const char *TARGET_STRIP_NAME_ENCODING (const char
+ *name)
+ Decode NAME and return the real name part, sans the characters
+ that `TARGET_ENCODE_SECTION_INFO' may have added.
+
+ -- Target Hook: bool TARGET_IN_SMALL_DATA_P (tree EXP)
+ Returns true if EXP should be placed into a "small data" section.
+ The default version of this hook always returns false.
+
+ -- Variable: Target Hook bool TARGET_HAVE_SRODATA_SECTION
+ Contains the value true if the target places read-only "small
+ data" into a separate section. The default value is false.
+
+ -- Target Hook: bool TARGET_BINDS_LOCAL_P (tree EXP)
+ Returns true if EXP names an object for which name resolution
+ rules must resolve to the current "module" (dynamic shared library
+ or executable image).
+
+ The default version of this hook implements the name resolution
+ rules for ELF, which has a looser model of global name binding
+ than other currently supported object file formats.
+
+ -- Variable: Target Hook bool TARGET_HAVE_TLS
+ Contains the value true if the target supports thread-local
+ storage. The default value is false.
+
+\1f
+File: gccint.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros
+
+17.20 Position Independent Code
+===============================
+
+This section describes macros that help implement generation of position
+independent code. Simply defining these macros is not enough to
+generate valid PIC; you must also add support to the macros
+`GO_IF_LEGITIMATE_ADDRESS' and `PRINT_OPERAND_ADDRESS', as well as
+`LEGITIMIZE_ADDRESS'. You must modify the definition of `movsi' to do
+something appropriate when the source operand contains a symbolic
+address. You may also need to alter the handling of switch statements
+so that they use relative addresses.
+
+ -- Macro: PIC_OFFSET_TABLE_REGNUM
+ The register number of the register used to address a table of
+ static data addresses in memory. In some cases this register is
+ defined by a processor's "application binary interface" (ABI).
+ When this macro is defined, RTL is generated for this register
+ once, as with the stack pointer and frame pointer registers. If
+ this macro is not defined, it is up to the machine-dependent files
+ to allocate such a register (if necessary). Note that this
+ register must be fixed when in use (e.g. when `flag_pic' is true).
+
+ -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED
+ Define this macro if the register defined by
+ `PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. Do not define
+ this macro if `PIC_OFFSET_TABLE_REGNUM' is not defined.
+
+ -- Macro: LEGITIMATE_PIC_OPERAND_P (X)
+ A C expression that is nonzero if X is a legitimate immediate
+ operand on the target machine when generating position independent
+ code. You can assume that X satisfies `CONSTANT_P', so you need
+ not check this. You can also assume FLAG_PIC is true, so you need
+ not check it either. You need not define this macro if all
+ constants (including `SYMBOL_REF') can be immediate operands when
+ generating position independent code.
+
+\1f
+File: gccint.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros
+
+17.21 Defining the Output Assembler Language
+============================================
+
+This section describes macros whose principal purpose is to describe how
+to write instructions in assembler language--rather than what the
+instructions do.
+
+* Menu:
+
+* File Framework:: Structural information for the assembler file.
+* Data Output:: Output of constants (numbers, strings, addresses).
+* Uninitialized Data:: Output of uninitialized variables.
+* Label Output:: Output and generation of labels.
+* Initialization:: General principles of initialization
+ and termination routines.
+* Macros for Initialization::
+ Specific macros that control the handling of
+ initialization and termination routines.
+* Instruction Output:: Output of actual instructions.
+* Dispatch Tables:: Output of jump tables.
+* Exception Region Output:: Output of exception region code.
+* Alignment Output:: Pseudo ops for alignment and skipping data.
+
+\1f
+File: gccint.info, Node: File Framework, Next: Data Output, Up: Assembler Format
+
+17.21.1 The Overall Framework of an Assembler File
+--------------------------------------------------
+
+This describes the overall framework of an assembly file.
+
+ -- Target Hook: void TARGET_ASM_FILE_START ()
+ Output to `asm_out_file' any text which the assembler expects to
+ find at the beginning of a file. The default behavior is
+ controlled by two flags, documented below. Unless your target's
+ assembler is quite unusual, if you override the default, you
+ should call `default_file_start' at some point in your target
+ hook. This lets other target files rely on these variables.
+
+ -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF
+ If this flag is true, the text of the macro `ASM_APP_OFF' will be
+ printed as the very first line in the assembly file, unless
+ `-fverbose-asm' is in effect. (If that macro has been defined to
+ the empty string, this variable has no effect.) With the normal
+ definition of `ASM_APP_OFF', the effect is to notify the GNU
+ assembler that it need not bother stripping comments or extra
+ whitespace from its input. This allows it to work a bit faster.
+
+ The default is false. You should not set it to true unless you
+ have verified that your port does not generate any extra
+ whitespace or comments that will cause GAS to issue errors in
+ NO_APP mode.
+
+ -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE
+ If this flag is true, `output_file_directive' will be called for
+ the primary source file, immediately after printing `ASM_APP_OFF'
+ (if that is enabled). Most ELF assemblers expect this to be done.
+ The default is false.
+
+ -- Target Hook: void TARGET_ASM_FILE_END ()
+ Output to `asm_out_file' any text which the assembler expects to
+ find at the end of a file. The default is to output nothing.
+
+ -- Function: void file_end_indicate_exec_stack ()
+ Some systems use a common convention, the `.note.GNU-stack'
+ special section, to indicate whether or not an object file relies
+ on the stack being executable. If your system uses this
+ convention, you should define `TARGET_ASM_FILE_END' to this
+ function. If you need to do other things in that hook, have your
+ hook function call this function.
+
+ -- Macro: ASM_COMMENT_START
+ A C string constant describing how to begin a comment in the target
+ assembler language. The compiler assumes that the comment will
+ end at the end of the line.
+
+ -- Macro: ASM_APP_ON
+ A C string constant for text to be output before each `asm'
+ statement or group of consecutive ones. Normally this is
+ `"#APP"', which is a comment that has no effect on most assemblers
+ but tells the GNU assembler that it must check the lines that
+ follow for all valid assembler constructs.
+
+ -- Macro: ASM_APP_OFF
+ A C string constant for text to be output after each `asm'
+ statement or group of consecutive ones. Normally this is
+ `"#NO_APP"', which tells the GNU assembler to resume making the
+ time-saving assumptions that are valid for ordinary compiler
+ output.
+
+ -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME)
+ A C statement to output COFF information or DWARF debugging
+ information which indicates that filename NAME is the current
+ source file to the stdio stream STREAM.
+
+ This macro need not be defined if the standard form of output for
+ the file format in use is appropriate.
+
+ -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING)
+ A C statement to output the string STRING to the stdio stream
+ STREAM. If you do not call the function `output_quoted_string' in
+ your config files, GCC will only call it to output filenames to
+ the assembler source. So you can use it to canonicalize the format
+ of the filename using this macro.
+
+ -- Macro: ASM_OUTPUT_IDENT (STREAM, STRING)
+ A C statement to output something to the assembler file to handle a
+ `#ident' directive containing the text STRING. If this macro is
+ not defined, nothing is output for a `#ident' directive.
+
+ -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME,
+ unsigned int FLAGS, unsigned int ALIGN)
+ Output assembly directives to switch to section NAME. The section
+ should have attributes as specified by FLAGS, which is a bit mask
+ of the `SECTION_*' flags defined in `output.h'. If ALIGN is
+ nonzero, it contains an alignment in bytes to be used for the
+ section, otherwise some target default should be used. Only
+ targets that must specify an alignment within the section
+ directive need pay attention to ALIGN - we will still use
+ `ASM_OUTPUT_ALIGN'.
+
+ -- Target Hook: bool TARGET_HAVE_NAMED_SECTIONS
+ This flag is true if the target supports
+ `TARGET_ASM_NAMED_SECTION'.
+
+ -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS
+ This flag is true if we can create zeroed data by switching to a
+ BSS section and then using `ASM_OUTPUT_SKIP' to allocate the space.
+ This is true on most ELF targets.
+
+ -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL,
+ const char *NAME, int RELOC)
+ Choose a set of section attributes for use by
+ `TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a
+ section name, and whether or not the declaration's initializer may
+ contain runtime relocations. DECL may be null, in which case
+ read-write data should be assumed.
+
+ The default version of this function handles choosing code vs data,
+ read-only vs read-write data, and `flag_pic'. You should only
+ need to override this if your target has special flags that might
+ be set via `__attribute__'.
+
+ -- Target Hook: int TARGET_ASM_RECORD_GCC_SWITCHES (print_switch_type
+ TYPE, const char * TEXT)
+ Provides the target with the ability to record the gcc command line
+ switches that have been passed to the compiler, and options that
+ are enabled. The TYPE argument specifies what is being recorded.
+ It can take the following values:
+
+ `SWITCH_TYPE_PASSED'
+ TEXT is a command line switch that has been set by the user.
+
+ `SWITCH_TYPE_ENABLED'
+ TEXT is an option which has been enabled. This might be as a
+ direct result of a command line switch, or because it is
+ enabled by default or because it has been enabled as a side
+ effect of a different command line switch. For example, the
+ `-O2' switch enables various different individual
+ optimization passes.
+
+ `SWITCH_TYPE_DESCRIPTIVE'
+ TEXT is either NULL or some descriptive text which should be
+ ignored. If TEXT is NULL then it is being used to warn the
+ target hook that either recording is starting or ending. The
+ first time TYPE is SWITCH_TYPE_DESCRIPTIVE and TEXT is NULL,
+ the warning is for start up and the second time the warning
+ is for wind down. This feature is to allow the target hook
+ to make any necessary preparations before it starts to record
+ switches and to perform any necessary tidying up after it has
+ finished recording switches.
+
+ `SWITCH_TYPE_LINE_START'
+ This option can be ignored by this target hook.
+
+ `SWITCH_TYPE_LINE_END'
+ This option can be ignored by this target hook.
+
+ The hook's return value must be zero. Other return values may be
+ supported in the future.
+
+ By default this hook is set to NULL, but an example implementation
+ is provided for ELF based targets. Called ELF_RECORD_GCC_SWITCHES,
+ it records the switches as ASCII text inside a new, string
+ mergeable section in the assembler output file. The name of the
+ new section is provided by the
+ `TARGET_ASM_RECORD_GCC_SWITCHES_SECTION' target hook.
+
+ -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION
+ This is the name of the section that will be created by the example
+ ELF implementation of the `TARGET_ASM_RECORD_GCC_SWITCHES' target
+ hook.
+
+\1f
+File: gccint.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format
+
+17.21.2 Output of Data
+----------------------
+
+ -- Target Hook: const char * TARGET_ASM_BYTE_OP
+ -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP
+ -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP
+ -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP
+ -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP
+ -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP
+ -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP
+ -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP
+ -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP
+ These hooks specify assembly directives for creating certain kinds
+ of integer object. The `TARGET_ASM_BYTE_OP' directive creates a
+ byte-sized object, the `TARGET_ASM_ALIGNED_HI_OP' one creates an
+ aligned two-byte object, and so on. Any of the hooks may be
+ `NULL', indicating that no suitable directive is available.
+
+ The compiler will print these strings at the start of a new line,
+ followed immediately by the object's initial value. In most cases,
+ the string should contain a tab, a pseudo-op, and then another tab.
+
+ -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int
+ ALIGNED_P)
+ The `assemble_integer' function uses this hook to output an
+ integer object. X is the object's value, SIZE is its size in
+ bytes and ALIGNED_P indicates whether it is aligned. The function
+ should return `true' if it was able to output the object. If it
+ returns false, `assemble_integer' will try to split the object
+ into smaller parts.
+
+ The default implementation of this hook will use the
+ `TARGET_ASM_BYTE_OP' family of strings, returning `false' when the
+ relevant string is `NULL'.
+
+ -- Macro: OUTPUT_ADDR_CONST_EXTRA (STREAM, X, FAIL)
+ A C statement to recognize RTX patterns that `output_addr_const'
+ can't deal with, and output assembly code to STREAM corresponding
+ to the pattern X. This may be used to allow machine-dependent
+ `UNSPEC's to appear within constants.
+
+ If `OUTPUT_ADDR_CONST_EXTRA' fails to recognize a pattern, it must
+ `goto fail', so that a standard error message is printed. If it
+ prints an error message itself, by calling, for example,
+ `output_operand_lossage', it may just complete normally.
+
+ -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN)
+ A C statement to output to the stdio stream STREAM an assembler
+ instruction to assemble a string constant containing the LEN bytes
+ at PTR. PTR will be a C expression of type `char *' and LEN a C
+ expression of type `int'.
+
+ If the assembler has a `.ascii' pseudo-op as found in the Berkeley
+ Unix assembler, do not define the macro `ASM_OUTPUT_ASCII'.
+
+ -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N)
+ A C statement to output word N of a function descriptor for DECL.
+ This must be defined if `TARGET_VTABLE_USES_DESCRIPTORS' is
+ defined, and is otherwise unused.
+
+ -- Macro: CONSTANT_POOL_BEFORE_FUNCTION
+ You may define this macro as a C expression. You should define the
+ expression to have a nonzero value if GCC should output the
+ constant pool for a function before the code for the function, or
+ a zero value if GCC should output the constant pool after the
+ function. If you do not define this macro, the usual case, GCC
+ will output the constant pool before the function.
+
+ -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE)
+ A C statement to output assembler commands to define the start of
+ the constant pool for a function. FUNNAME is a string giving the
+ name of the function. Should the return type of the function be
+ required, it can be obtained via FUNDECL. SIZE is the size, in
+ bytes, of the constant pool that will be written immediately after
+ this call.
+
+ If no constant-pool prefix is required, the usual case, this macro
+ need not be defined.
+
+ -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN,
+ LABELNO, JUMPTO)
+ A C statement (with or without semicolon) to output a constant in
+ the constant pool, if it needs special treatment. (This macro
+ need not do anything for RTL expressions that can be output
+ normally.)
+
+ The argument FILE is the standard I/O stream to output the
+ assembler code on. X is the RTL expression for the constant to
+ output, and MODE is the machine mode (in case X is a `const_int').
+ ALIGN is the required alignment for the value X; you should output
+ an assembler directive to force this much alignment.
+
+ The argument LABELNO is a number to use in an internal label for
+ the address of this pool entry. The definition of this macro is
+ responsible for outputting the label definition at the proper
+ place. Here is how to do this:
+
+ `(*targetm.asm_out.internal_label)' (FILE, "LC", LABELNO);
+
+ When you output a pool entry specially, you should end with a
+ `goto' to the label JUMPTO. This will prevent the same pool entry
+ from being output a second time in the usual manner.
+
+ You need not define this macro if it would do nothing.
+
+ -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE)
+ A C statement to output assembler commands to at the end of the
+ constant pool for a function. FUNNAME is a string giving the name
+ of the function. Should the return type of the function be
+ required, you can obtain it via FUNDECL. SIZE is the size, in
+ bytes, of the constant pool that GCC wrote immediately before this
+ call.
+
+ If no constant-pool epilogue is required, the usual case, you need
+ not define this macro.
+
+ -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C, STR)
+ Define this macro as a C expression which is nonzero if C is used
+ as a logical line separator by the assembler. STR points to the
+ position in the string where C was found; this can be used if a
+ line separator uses multiple characters.
+
+ If you do not define this macro, the default is that only the
+ character `;' is treated as a logical line separator.
+
+ -- Target Hook: const char * TARGET_ASM_OPEN_PAREN
+ -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN
+ These target hooks are C string constants, describing the syntax
+ in the assembler for grouping arithmetic expressions. If not
+ overridden, they default to normal parentheses, which is correct
+ for most assemblers.
+
+ These macros are provided by `real.h' for writing the definitions of
+`ASM_OUTPUT_DOUBLE' and the like:
+
+ -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L)
+ -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L)
+ -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L)
+ -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L)
+ -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L)
+ -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L)
+ These translate X, of type `REAL_VALUE_TYPE', to the target's
+ floating point representation, and store its bit pattern in the
+ variable L. For `REAL_VALUE_TO_TARGET_SINGLE' and
+ `REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple
+ `long int'. For the others, it should be an array of `long int'.
+ The number of elements in this array is determined by the size of
+ the desired target floating point data type: 32 bits of it go in
+ each `long int' array element. Each array element holds 32 bits
+ of the result, even if `long int' is wider than 32 bits on the
+ host machine.
+
+ The array element values are designed so that you can print them
+ out using `fprintf' in the order they should appear in the target
+ machine's memory.
+
+\1f
+File: gccint.info, Node: Uninitialized Data, Next: Label Output, Prev: Data Output, Up: Assembler Format
+
+17.21.3 Output of Uninitialized Variables
+-----------------------------------------
+
+Each of the macros in this section is used to do the whole job of
+outputting a single uninitialized variable.
+
+ -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM the assembler definition of a common-label named NAME whose
+ size is SIZE bytes. The variable ROUNDED is the size rounded up
+ to whatever alignment the caller wants.
+
+ Use the expression `assemble_name (STREAM, NAME)' to output the
+ name itself; before and after that, output the additional
+ assembler syntax for defining the name, and a newline.
+
+ This macro controls how the assembler definitions of uninitialized
+ common global variables are output.
+
+ -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT)
+ Like `ASM_OUTPUT_COMMON' except takes the required alignment as a
+ separate, explicit argument. If you define this macro, it is used
+ in place of `ASM_OUTPUT_COMMON', and gives you more flexibility in
+ handling the required alignment of the variable. The alignment is
+ specified as the number of bits.
+
+ -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE,
+ ALIGNMENT)
+ Like `ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable
+ to be output, if there is one, or `NULL_TREE' if there is no
+ corresponding variable. If you define this macro, GCC will use it
+ in place of both `ASM_OUTPUT_COMMON' and
+ `ASM_OUTPUT_ALIGNED_COMMON'. Define this macro when you need to
+ see the variable's decl in order to chose what to output.
+
+ -- Macro: ASM_OUTPUT_BSS (STREAM, DECL, NAME, SIZE, ROUNDED)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM the assembler definition of uninitialized global DECL named
+ NAME whose size is SIZE bytes. The variable ROUNDED is the size
+ rounded up to whatever alignment the caller wants.
+
+ Try to use function `asm_output_bss' defined in `varasm.c' when
+ defining this macro. If unable, use the expression `assemble_name
+ (STREAM, NAME)' to output the name itself; before and after that,
+ output the additional assembler syntax for defining the name, and
+ a newline.
+
+ There are two ways of handling global BSS. One is to define either
+ this macro or its aligned counterpart, `ASM_OUTPUT_ALIGNED_BSS'.
+ The other is to have `TARGET_ASM_SELECT_SECTION' return a
+ switchable BSS section (*note
+ TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::). You do not need to do
+ both.
+
+ Some languages do not have `common' data, and require a non-common
+ form of global BSS in order to handle uninitialized globals
+ efficiently. C++ is one example of this. However, if the target
+ does not support global BSS, the front end may choose to make
+ globals common in order to save space in the object file.
+
+ -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT)
+ Like `ASM_OUTPUT_BSS' except takes the required alignment as a
+ separate, explicit argument. If you define this macro, it is used
+ in place of `ASM_OUTPUT_BSS', and gives you more flexibility in
+ handling the required alignment of the variable. The alignment is
+ specified as the number of bits.
+
+ Try to use function `asm_output_aligned_bss' defined in file
+ `varasm.c' when defining this macro.
+
+ -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM the assembler definition of a local-common-label named NAME
+ whose size is SIZE bytes. The variable ROUNDED is the size
+ rounded up to whatever alignment the caller wants.
+
+ Use the expression `assemble_name (STREAM, NAME)' to output the
+ name itself; before and after that, output the additional
+ assembler syntax for defining the name, and a newline.
+
+ This macro controls how the assembler definitions of uninitialized
+ static variables are output.
+
+ -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT)
+ Like `ASM_OUTPUT_LOCAL' except takes the required alignment as a
+ separate, explicit argument. If you define this macro, it is used
+ in place of `ASM_OUTPUT_LOCAL', and gives you more flexibility in
+ handling the required alignment of the variable. The alignment is
+ specified as the number of bits.
+
+ -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE,
+ ALIGNMENT)
+ Like `ASM_OUTPUT_ALIGNED_DECL' except that DECL of the variable to
+ be output, if there is one, or `NULL_TREE' if there is no
+ corresponding variable. If you define this macro, GCC will use it
+ in place of both `ASM_OUTPUT_DECL' and `ASM_OUTPUT_ALIGNED_DECL'.
+ Define this macro when you need to see the variable's decl in
+ order to chose what to output.
+
+\1f
+File: gccint.info, Node: Label Output, Next: Initialization, Prev: Uninitialized Data, Up: Assembler Format
+
+17.21.4 Output and Generation of Labels
+---------------------------------------
+
+This is about outputting labels.
+
+ -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM the assembler definition of a label named NAME. Use the
+ expression `assemble_name (STREAM, NAME)' to output the name
+ itself; before and after that, output the additional assembler
+ syntax for defining the name, and a newline. A default definition
+ of this macro is provided which is correct for most systems.
+
+ -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME)
+ Identical to `ASM_OUTPUT_LABEL', except that NAME is known to
+ refer to a compiler-generated label. The default definition uses
+ `assemble_name_raw', which is like `assemble_name' except that it
+ is more efficient.
+
+ -- Macro: SIZE_ASM_OP
+ A C string containing the appropriate assembler directive to
+ specify the size of a symbol, without any arguments. On systems
+ that use ELF, the default (in `config/elfos.h') is `"\t.size\t"';
+ on other systems, the default is not to define this macro.
+
+ Define this macro only if it is correct to use the default
+ definitions of `ASM_OUTPUT_SIZE_DIRECTIVE' and
+ `ASM_OUTPUT_MEASURED_SIZE' for your system. If you need your own
+ custom definitions of those macros, or if you do not need explicit
+ symbol sizes at all, do not define this macro.
+
+ -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM a directive telling the assembler that the size of the
+ symbol NAME is SIZE. SIZE is a `HOST_WIDE_INT'. If you define
+ `SIZE_ASM_OP', a default definition of this macro is provided.
+
+ -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM a directive telling the assembler to calculate the size of
+ the symbol NAME by subtracting its address from the current
+ address.
+
+ If you define `SIZE_ASM_OP', a default definition of this macro is
+ provided. The default assumes that the assembler recognizes a
+ special `.' symbol as referring to the current address, and can
+ calculate the difference between this and another symbol. If your
+ assembler does not recognize `.' or cannot do calculations with
+ it, you will need to redefine `ASM_OUTPUT_MEASURED_SIZE' to use
+ some other technique.
+
+ -- Macro: TYPE_ASM_OP
+ A C string containing the appropriate assembler directive to
+ specify the type of a symbol, without any arguments. On systems
+ that use ELF, the default (in `config/elfos.h') is `"\t.type\t"';
+ on other systems, the default is not to define this macro.
+
+ Define this macro only if it is correct to use the default
+ definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you
+ need your own custom definition of this macro, or if you do not
+ need explicit symbol types at all, do not define this macro.
+
+ -- Macro: TYPE_OPERAND_FMT
+ A C string which specifies (using `printf' syntax) the format of
+ the second operand to `TYPE_ASM_OP'. On systems that use ELF, the
+ default (in `config/elfos.h') is `"@%s"'; on other systems, the
+ default is not to define this macro.
+
+ Define this macro only if it is correct to use the default
+ definition of `ASM_OUTPUT_TYPE_DIRECTIVE' for your system. If you
+ need your own custom definition of this macro, or if you do not
+ need explicit symbol types at all, do not define this macro.
+
+ -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM a directive telling the assembler that the type of the
+ symbol NAME is TYPE. TYPE is a C string; currently, that string
+ is always either `"function"' or `"object"', but you should not
+ count on this.
+
+ If you define `TYPE_ASM_OP' and `TYPE_OPERAND_FMT', a default
+ definition of this macro is provided.
+
+ -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM any text necessary for declaring the name NAME of a
+ function which is being defined. This macro is responsible for
+ outputting the label definition (perhaps using
+ `ASM_OUTPUT_LABEL'). The argument DECL is the `FUNCTION_DECL'
+ tree node representing the function.
+
+ If this macro is not defined, then the function name is defined in
+ the usual manner as a label (by means of `ASM_OUTPUT_LABEL').
+
+ You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition
+ of this macro.
+
+ -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM any text necessary for declaring the size of a function
+ which is being defined. The argument NAME is the name of the
+ function. The argument DECL is the `FUNCTION_DECL' tree node
+ representing the function.
+
+ If this macro is not defined, then the function size is not
+ defined.
+
+ You may wish to use `ASM_OUTPUT_MEASURED_SIZE' in the definition
+ of this macro.
+
+ -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM any text necessary for declaring the name NAME of an
+ initialized variable which is being defined. This macro must
+ output the label definition (perhaps using `ASM_OUTPUT_LABEL').
+ The argument DECL is the `VAR_DECL' tree node representing the
+ variable.
+
+ If this macro is not defined, then the variable name is defined in
+ the usual manner as a label (by means of `ASM_OUTPUT_LABEL').
+
+ You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' and/or
+ `ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro.
+
+ -- Macro: ASM_DECLARE_CONSTANT_NAME (STREAM, NAME, EXP, SIZE)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM any text necessary for declaring the name NAME of a
+ constant which is being defined. This macro is responsible for
+ outputting the label definition (perhaps using
+ `ASM_OUTPUT_LABEL'). The argument EXP is the value of the
+ constant, and SIZE is the size of the constant in bytes. NAME
+ will be an internal label.
+
+ If this macro is not defined, then the NAME is defined in the
+ usual manner as a label (by means of `ASM_OUTPUT_LABEL').
+
+ You may wish to use `ASM_OUTPUT_TYPE_DIRECTIVE' in the definition
+ of this macro.
+
+ -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM any text necessary for claiming a register REGNO for a
+ global variable DECL with name NAME.
+
+ If you don't define this macro, that is equivalent to defining it
+ to do nothing.
+
+ -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND)
+ A C statement (sans semicolon) to finish up declaring a variable
+ name once the compiler has processed its initializer fully and
+ thus has had a chance to determine the size of an array when
+ controlled by an initializer. This is used on systems where it's
+ necessary to declare something about the size of the object.
+
+ If you don't define this macro, that is equivalent to defining it
+ to do nothing.
+
+ You may wish to use `ASM_OUTPUT_SIZE_DIRECTIVE' and/or
+ `ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro.
+
+ -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const
+ char *NAME)
+ This target hook is a function to output to the stdio stream
+ STREAM some commands that will make the label NAME global; that
+ is, available for reference from other files.
+
+ The default implementation relies on a proper definition of
+ `GLOBAL_ASM_OP'.
+
+ -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM,
+ tree DECL)
+ This target hook is a function to output to the stdio stream
+ STREAM some commands that will make the name associated with DECL
+ global; that is, available for reference from other files.
+
+ The default implementation uses the TARGET_ASM_GLOBALIZE_LABEL
+ target hook.
+
+ -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM some commands that will make the label NAME weak; that is,
+ available for reference from other files but only used if no other
+ definition is available. Use the expression `assemble_name
+ (STREAM, NAME)' to output the name itself; before and after that,
+ output the additional assembler syntax for making that name weak,
+ and a newline.
+
+ If you don't define this macro or `ASM_WEAKEN_DECL', GCC will not
+ support weak symbols and you should not define the `SUPPORTS_WEAK'
+ macro.
+
+ -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE)
+ Combines (and replaces) the function of `ASM_WEAKEN_LABEL' and
+ `ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function
+ or variable decl. If VALUE is not `NULL', this C statement should
+ output to the stdio stream STREAM assembler code which defines
+ (equates) the weak symbol NAME to have the value VALUE. If VALUE
+ is `NULL', it should output commands to make NAME weak.
+
+ -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE)
+ Outputs a directive that enables NAME to be used to refer to
+ symbol VALUE with weak-symbol semantics. `decl' is the
+ declaration of `name'.
+
+ -- Macro: SUPPORTS_WEAK
+ A C expression which evaluates to true if the target supports weak
+ symbols.
+
+ If you don't define this macro, `defaults.h' provides a default
+ definition. If either `ASM_WEAKEN_LABEL' or `ASM_WEAKEN_DECL' is
+ defined, the default definition is `1'; otherwise, it is `0'.
+ Define this macro if you want to control weak symbol support with
+ a compiler flag such as `-melf'.
+
+ -- Macro: MAKE_DECL_ONE_ONLY (DECL)
+ A C statement (sans semicolon) to mark DECL to be emitted as a
+ public symbol such that extra copies in multiple translation units
+ will be discarded by the linker. Define this macro if your object
+ file format provides support for this concept, such as the `COMDAT'
+ section flags in the Microsoft Windows PE/COFF format, and this
+ support requires changes to DECL, such as putting it in a separate
+ section.
+
+ -- Macro: SUPPORTS_ONE_ONLY
+ A C expression which evaluates to true if the target supports
+ one-only semantics.
+
+ If you don't define this macro, `varasm.c' provides a default
+ definition. If `MAKE_DECL_ONE_ONLY' is defined, the default
+ definition is `1'; otherwise, it is `0'. Define this macro if you
+ want to control one-only symbol support with a compiler flag, or if
+ setting the `DECL_ONE_ONLY' flag is enough to mark a declaration to
+ be emitted as one-only.
+
+ -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, const
+ char *VISIBILITY)
+ This target hook is a function to output to ASM_OUT_FILE some
+ commands that will make the symbol(s) associated with DECL have
+ hidden, protected or internal visibility as specified by
+ VISIBILITY.
+
+ -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC
+ A C expression that evaluates to true if the target's linker
+ expects that weak symbols do not appear in a static archive's
+ table of contents. The default is `0'.
+
+ Leaving weak symbols out of an archive's table of contents means
+ that, if a symbol will only have a definition in one translation
+ unit and will have undefined references from other translation
+ units, that symbol should not be weak. Defining this macro to be
+ nonzero will thus have the effect that certain symbols that would
+ normally be weak (explicit template instantiations, and vtables
+ for polymorphic classes with noninline key methods) will instead
+ be nonweak.
+
+ The C++ ABI requires this macro to be zero. Define this macro for
+ targets where full C++ ABI compliance is impossible and where
+ linker restrictions require weak symbols to be left out of a
+ static archive's table of contents.
+
+ -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM any text necessary for declaring the name of an external
+ symbol named NAME which is referenced in this compilation but not
+ defined. The value of DECL is the tree node for the declaration.
+
+ This macro need not be defined if it does not need to output
+ anything. The GNU assembler and most Unix assemblers don't
+ require anything.
+
+ -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF)
+ This target hook is a function to output to ASM_OUT_FILE an
+ assembler pseudo-op to declare a library function name external.
+ The name of the library function is given by SYMREF, which is a
+ `symbol_ref'.
+
+ -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (tree DECL)
+ This target hook is a function to output to ASM_OUT_FILE an
+ assembler directive to annotate used symbol. Darwin target use
+ .no_dead_code_strip directive.
+
+ -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM a reference in assembler syntax to a label named NAME.
+ This should add `_' to the front of the name, if that is customary
+ on your operating system, as it is in most Berkeley Unix systems.
+ This macro is used in `assemble_name'.
+
+ -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM)
+ A C statement (sans semicolon) to output a reference to
+ `SYMBOL_REF' SYM. If not defined, `assemble_name' will be used to
+ output the name of the symbol. This macro may be used to modify
+ the way a symbol is referenced depending on information encoded by
+ `TARGET_ENCODE_SECTION_INFO'.
+
+ -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF)
+ A C statement (sans semicolon) to output a reference to BUF, the
+ result of `ASM_GENERATE_INTERNAL_LABEL'. If not defined,
+ `assemble_name' will be used to output the name of the symbol.
+ This macro is not used by `output_asm_label', or the `%l'
+ specifier that calls it; the intention is that this macro should
+ be set when it is necessary to output a label differently when its
+ address is being taken.
+
+ -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const
+ char *PREFIX, unsigned long LABELNO)
+ A function to output to the stdio stream STREAM a label whose name
+ is made from the string PREFIX and the number LABELNO.
+
+ It is absolutely essential that these labels be distinct from the
+ labels used for user-level functions and variables. Otherwise,
+ certain programs will have name conflicts with internal labels.
+
+ It is desirable to exclude internal labels from the symbol table
+ of the object file. Most assemblers have a naming convention for
+ labels that should be excluded; on many systems, the letter `L' at
+ the beginning of a label has this effect. You should find out what
+ convention your system uses, and follow it.
+
+ The default version of this function utilizes
+ `ASM_GENERATE_INTERNAL_LABEL'.
+
+ -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM)
+ A C statement to output to the stdio stream STREAM a debug info
+ label whose name is made from the string PREFIX and the number
+ NUM. This is useful for VLIW targets, where debug info labels may
+ need to be treated differently than branch target labels. On some
+ systems, branch target labels must be at the beginning of
+ instruction bundles, but debug info labels can occur in the middle
+ of instruction bundles.
+
+ If this macro is not defined, then
+ `(*targetm.asm_out.internal_label)' will be used.
+
+ -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM)
+ A C statement to store into the string STRING a label whose name
+ is made from the string PREFIX and the number NUM.
+
+ This string, when output subsequently by `assemble_name', should
+ produce the output that `(*targetm.asm_out.internal_label)' would
+ produce with the same PREFIX and NUM.
+
+ If the string begins with `*', then `assemble_name' will output
+ the rest of the string unchanged. It is often convenient for
+ `ASM_GENERATE_INTERNAL_LABEL' to use `*' in this way. If the
+ string doesn't start with `*', then `ASM_OUTPUT_LABELREF' gets to
+ output the string, and may change it. (Of course,
+ `ASM_OUTPUT_LABELREF' is also part of your machine description, so
+ you should know what it does on your machine.)
+
+ -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER)
+ A C expression to assign to OUTVAR (which is a variable of type
+ `char *') a newly allocated string made from the string NAME and
+ the number NUMBER, with some suitable punctuation added. Use
+ `alloca' to get space for the string.
+
+ The string will be used as an argument to `ASM_OUTPUT_LABELREF' to
+ produce an assembler label for an internal static variable whose
+ name is NAME. Therefore, the string must be such as to result in
+ valid assembler code. The argument NUMBER is different each time
+ this macro is executed; it prevents conflicts between
+ similarly-named internal static variables in different scopes.
+
+ Ideally this string should not be a valid C identifier, to prevent
+ any conflict with the user's own symbols. Most assemblers allow
+ periods or percent signs in assembler symbols; putting at least
+ one of these between the name and the number will suffice.
+
+ If this macro is not defined, a default definition will be provided
+ which is correct for most systems.
+
+ -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE)
+ A C statement to output to the stdio stream STREAM assembler code
+ which defines (equates) the symbol NAME to have the value VALUE.
+
+ If `SET_ASM_OP' is defined, a default definition is provided which
+ is correct for most systems.
+
+ -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME,
+ DECL_OF_VALUE)
+ A C statement to output to the stdio stream STREAM assembler code
+ which defines (equates) the symbol whose tree node is DECL_OF_NAME
+ to have the value of the tree node DECL_OF_VALUE. This macro will
+ be used in preference to `ASM_OUTPUT_DEF' if it is defined and if
+ the tree nodes are available.
+
+ If `SET_ASM_OP' is defined, a default definition is provided which
+ is correct for most systems.
+
+ -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE)
+ A C statement that evaluates to true if the assembler code which
+ defines (equates) the symbol whose tree node is DECL_OF_NAME to
+ have the value of the tree node DECL_OF_VALUE should be emitted
+ near the end of the current compilation unit. The default is to
+ not defer output of defines. This macro affects defines output by
+ `ASM_OUTPUT_DEF' and `ASM_OUTPUT_DEF_FROM_DECLS'.
+
+ -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE)
+ A C statement to output to the stdio stream STREAM assembler code
+ which defines (equates) the weak symbol NAME to have the value
+ VALUE. If VALUE is `NULL', it defines NAME as an undefined weak
+ symbol.
+
+ Define this macro if the target only supports weak aliases; define
+ `ASM_OUTPUT_DEF' instead if possible.
+
+ -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME,
+ SEL_NAME)
+ Define this macro to override the default assembler names used for
+ Objective-C methods.
+
+ The default name is a unique method number followed by the name of
+ the class (e.g. `_1_Foo'). For methods in categories, the name of
+ the category is also included in the assembler name (e.g.
+ `_1_Foo_Bar').
+
+ These names are safe on most systems, but make debugging difficult
+ since the method's selector is not present in the name.
+ Therefore, particular systems define other ways of computing names.
+
+ BUF is an expression of type `char *' which gives you a buffer in
+ which to store the name; its length is as long as CLASS_NAME,
+ CAT_NAME and SEL_NAME put together, plus 50 characters extra.
+
+ The argument IS_INST specifies whether the method is an instance
+ method or a class method; CLASS_NAME is the name of the class;
+ CAT_NAME is the name of the category (or `NULL' if the method is
+ not in a category); and SEL_NAME is the name of the selector.
+
+ On systems where the assembler can handle quoted names, you can
+ use this macro to provide more human-readable names.
+
+ -- Macro: ASM_DECLARE_CLASS_REFERENCE (STREAM, NAME)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM commands to declare that the label NAME is an Objective-C
+ class reference. This is only needed for targets whose linkers
+ have special support for NeXT-style runtimes.
+
+ -- Macro: ASM_DECLARE_UNRESOLVED_REFERENCE (STREAM, NAME)
+ A C statement (sans semicolon) to output to the stdio stream
+ STREAM commands to declare that the label NAME is an unresolved
+ Objective-C class reference. This is only needed for targets
+ whose linkers have special support for NeXT-style runtimes.
+
+\1f
+File: gccint.info, Node: Initialization, Next: Macros for Initialization, Prev: Label Output, Up: Assembler Format
+
+17.21.5 How Initialization Functions Are Handled
+------------------------------------------------
+
+The compiled code for certain languages includes "constructors" (also
+called "initialization routines")--functions to initialize data in the
+program when the program is started. These functions need to be called
+before the program is "started"--that is to say, before `main' is
+called.
+
+ Compiling some languages generates "destructors" (also called
+"termination routines") that should be called when the program
+terminates.
+
+ To make the initialization and termination functions work, the compiler
+must output something in the assembler code to cause those functions to
+be called at the appropriate time. When you port the compiler to a new
+system, you need to specify how to do this.
+
+ There are two major ways that GCC currently supports the execution of
+initialization and termination functions. Each way has two variants.
+Much of the structure is common to all four variations.
+
+ The linker must build two lists of these functions--a list of
+initialization functions, called `__CTOR_LIST__', and a list of
+termination functions, called `__DTOR_LIST__'.
+
+ Each list always begins with an ignored function pointer (which may
+hold 0, -1, or a count of the function pointers after it, depending on
+the environment). This is followed by a series of zero or more function
+pointers to constructors (or destructors), followed by a function
+pointer containing zero.
+
+ Depending on the operating system and its executable file format,
+either `crtstuff.c' or `libgcc2.c' traverses these lists at startup
+time and exit time. Constructors are called in reverse order of the
+list; destructors in forward order.
+
+ The best way to handle static constructors works only for object file
+formats which provide arbitrarily-named sections. A section is set
+aside for a list of constructors, and another for a list of destructors.
+Traditionally these are called `.ctors' and `.dtors'. Each object file
+that defines an initialization function also puts a word in the
+constructor section to point to that function. The linker accumulates
+all these words into one contiguous `.ctors' section. Termination
+functions are handled similarly.
+
+ This method will be chosen as the default by `target-def.h' if
+`TARGET_ASM_NAMED_SECTION' is defined. A target that does not support
+arbitrary sections, but does support special designated constructor and
+destructor sections may define `CTORS_SECTION_ASM_OP' and
+`DTORS_SECTION_ASM_OP' to achieve the same effect.
+
+ When arbitrary sections are available, there are two variants,
+depending upon how the code in `crtstuff.c' is called. On systems that
+support a ".init" section which is executed at program startup, parts
+of `crtstuff.c' are compiled into that section. The program is linked
+by the `gcc' driver like this:
+
+ ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o
+
+ The prologue of a function (`__init') appears in the `.init' section
+of `crti.o'; the epilogue appears in `crtn.o'. Likewise for the
+function `__fini' in the ".fini" section. Normally these files are
+provided by the operating system or by the GNU C library, but are
+provided by GCC for a few targets.
+
+ The objects `crtbegin.o' and `crtend.o' are (for most targets)
+compiled from `crtstuff.c'. They contain, among other things, code
+fragments within the `.init' and `.fini' sections that branch to
+routines in the `.text' section. The linker will pull all parts of a
+section together, which results in a complete `__init' function that
+invokes the routines we need at startup.
+
+ To use this variant, you must define the `INIT_SECTION_ASM_OP' macro
+properly.
+
+ If no init section is available, when GCC compiles any function called
+`main' (or more accurately, any function designated as a program entry
+point by the language front end calling `expand_main_function'), it
+inserts a procedure call to `__main' as the first executable code after
+the function prologue. The `__main' function is defined in `libgcc2.c'
+and runs the global constructors.
+
+ In file formats that don't support arbitrary sections, there are again
+two variants. In the simplest variant, the GNU linker (GNU `ld') and
+an `a.out' format must be used. In this case, `TARGET_ASM_CONSTRUCTOR'
+is defined to produce a `.stabs' entry of type `N_SETT', referencing
+the name `__CTOR_LIST__', and with the address of the void function
+containing the initialization code as its value. The GNU linker
+recognizes this as a request to add the value to a "set"; the values
+are accumulated, and are eventually placed in the executable as a
+vector in the format described above, with a leading (ignored) count
+and a trailing zero element. `TARGET_ASM_DESTRUCTOR' is handled
+similarly. Since no init section is available, the absence of
+`INIT_SECTION_ASM_OP' causes the compilation of `main' to call `__main'
+as above, starting the initialization process.
+
+ The last variant uses neither arbitrary sections nor the GNU linker.
+This is preferable when you want to do dynamic linking and when using
+file formats which the GNU linker does not support, such as `ECOFF'. In
+this case, `TARGET_HAVE_CTORS_DTORS' is false, initialization and
+termination functions are recognized simply by their names. This
+requires an extra program in the linkage step, called `collect2'. This
+program pretends to be the linker, for use with GCC; it does its job by
+running the ordinary linker, but also arranges to include the vectors of
+initialization and termination functions. These functions are called
+via `__main' as described above. In order to use this method,
+`use_collect2' must be defined in the target in `config.gcc'.
+
+ The following section describes the specific macros that control and
+customize the handling of initialization and termination functions.
+
+\1f
+File: gccint.info, Node: Macros for Initialization, Next: Instruction Output, Prev: Initialization, Up: Assembler Format
+
+17.21.6 Macros Controlling Initialization Routines
+--------------------------------------------------
+
+Here are the macros that control how the compiler handles initialization
+and termination functions:
+
+ -- Macro: INIT_SECTION_ASM_OP
+ If defined, a C string constant, including spacing, for the
+ assembler operation to identify the following data as
+ initialization code. If not defined, GCC will assume such a
+ section does not exist. When you are using special sections for
+ initialization and termination functions, this macro also controls
+ how `crtstuff.c' and `libgcc2.c' arrange to run the initialization
+ functions.
+
+ -- Macro: HAS_INIT_SECTION
+ If defined, `main' will not call `__main' as described above.
+ This macro should be defined for systems that control start-up code
+ on a symbol-by-symbol basis, such as OSF/1, and should not be
+ defined explicitly for systems that support `INIT_SECTION_ASM_OP'.
+
+ -- Macro: LD_INIT_SWITCH
+ If defined, a C string constant for a switch that tells the linker
+ that the following symbol is an initialization routine.
+
+ -- Macro: LD_FINI_SWITCH
+ If defined, a C string constant for a switch that tells the linker
+ that the following symbol is a finalization routine.
+
+ -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC)
+ If defined, a C statement that will write a function that can be
+ automatically called when a shared library is loaded. The function
+ should call FUNC, which takes no arguments. If not defined, and
+ the object format requires an explicit initialization function,
+ then a function called `_GLOBAL__DI' will be generated.
+
+ This function and the following one are used by collect2 when
+ linking a shared library that needs constructors or destructors,
+ or has DWARF2 exception tables embedded in the code.
+
+ -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC)
+ If defined, a C statement that will write a function that can be
+ automatically called when a shared library is unloaded. The
+ function should call FUNC, which takes no arguments. If not
+ defined, and the object format requires an explicit finalization
+ function, then a function called `_GLOBAL__DD' will be generated.
+
+ -- Macro: INVOKE__main
+ If defined, `main' will call `__main' despite the presence of
+ `INIT_SECTION_ASM_OP'. This macro should be defined for systems
+ where the init section is not actually run automatically, but is
+ still useful for collecting the lists of constructors and
+ destructors.
+
+ -- Macro: SUPPORTS_INIT_PRIORITY
+ If nonzero, the C++ `init_priority' attribute is supported and the
+ compiler should emit instructions to control the order of
+ initialization of objects. If zero, the compiler will issue an
+ error message upon encountering an `init_priority' attribute.
+
+ -- Target Hook: bool TARGET_HAVE_CTORS_DTORS
+ This value is true if the target supports some "native" method of
+ collecting constructors and destructors to be run at startup and
+ exit. It is false if we must use `collect2'.
+
+ -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY)
+ If defined, a function that outputs assembler code to arrange to
+ call the function referenced by SYMBOL at initialization time.
+
+ Assume that SYMBOL is a `SYMBOL_REF' for a function taking no
+ arguments and with no return value. If the target supports
+ initialization priorities, PRIORITY is a value between 0 and
+ `MAX_INIT_PRIORITY'; otherwise it must be `DEFAULT_INIT_PRIORITY'.
+
+ If this macro is not defined by the target, a suitable default will
+ be chosen if (1) the target supports arbitrary section names, (2)
+ the target defines `CTORS_SECTION_ASM_OP', or (3) `USE_COLLECT2'
+ is not defined.
+
+ -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY)
+ This is like `TARGET_ASM_CONSTRUCTOR' but used for termination
+ functions rather than initialization functions.
+
+ If `TARGET_HAVE_CTORS_DTORS' is true, the initialization routine
+generated for the generated object file will have static linkage.
+
+ If your system uses `collect2' as the means of processing
+constructors, then that program normally uses `nm' to scan an object
+file for constructor functions to be called.
+
+ On certain kinds of systems, you can define this macro to make
+`collect2' work faster (and, in some cases, make it work at all):
+
+ -- Macro: OBJECT_FORMAT_COFF
+ Define this macro if the system uses COFF (Common Object File
+ Format) object files, so that `collect2' can assume this format
+ and scan object files directly for dynamic constructor/destructor
+ functions.
+
+ This macro is effective only in a native compiler; `collect2' as
+ part of a cross compiler always uses `nm' for the target machine.
+
+ -- Macro: REAL_NM_FILE_NAME
+ Define this macro as a C string constant containing the file name
+ to use to execute `nm'. The default is to search the path
+ normally for `nm'.
+
+ If your system supports shared libraries and has a program to list
+ the dynamic dependencies of a given library or executable, you can
+ define these macros to enable support for running initialization
+ and termination functions in shared libraries:
+
+ -- Macro: LDD_SUFFIX
+ Define this macro to a C string constant containing the name of
+ the program which lists dynamic dependencies, like `"ldd"' under
+ SunOS 4.
+
+ -- Macro: PARSE_LDD_OUTPUT (PTR)
+ Define this macro to be C code that extracts filenames from the
+ output of the program denoted by `LDD_SUFFIX'. PTR is a variable
+ of type `char *' that points to the beginning of a line of output
+ from `LDD_SUFFIX'. If the line lists a dynamic dependency, the
+ code must advance PTR to the beginning of the filename on that
+ line. Otherwise, it must set PTR to `NULL'.
+
+ -- Macro: SHLIB_SUFFIX
+ Define this macro to a C string constant containing the default
+ shared library extension of the target (e.g., `".so"'). `collect2'
+ strips version information after this suffix when generating global
+ constructor and destructor names. This define is only needed on
+ targets that use `collect2' to process constructors and
+ destructors.
+
+\1f
+File: gccint.info, Node: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format
+
+17.21.7 Output of Assembler Instructions
+----------------------------------------
+
+This describes assembler instruction output.
+
+ -- Macro: REGISTER_NAMES
+ A C initializer containing the assembler's names for the machine
+ registers, each one as a C string constant. This is what
+ translates register numbers in the compiler into assembler
+ language.
+
+ -- Macro: ADDITIONAL_REGISTER_NAMES
+ If defined, a C initializer for an array of structures containing
+ a name and a register number. This macro defines additional names
+ for hard registers, thus allowing the `asm' option in declarations
+ to refer to registers using alternate names.
+
+ -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR)
+ Define this macro if you are using an unusual assembler that
+ requires different names for the machine instructions.
+
+ The definition is a C statement or statements which output an
+ assembler instruction opcode to the stdio stream STREAM. The
+ macro-operand PTR is a variable of type `char *' which points to
+ the opcode name in its "internal" form--the form that is written
+ in the machine description. The definition should output the
+ opcode name to STREAM, performing any translation you desire, and
+ increment the variable PTR to point at the end of the opcode so
+ that it will not be output twice.
+
+ In fact, your macro definition may process less than the entire
+ opcode name, or more than the opcode name; but if you want to
+ process text that includes `%'-sequences to substitute operands,
+ you must take care of the substitution yourself. Just be sure to
+ increment PTR over whatever text should not be output normally.
+
+ If you need to look at the operand values, they can be found as the
+ elements of `recog_data.operand'.
+
+ If the macro definition does nothing, the instruction is output in
+ the usual way.
+
+ -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS)
+ If defined, a C statement to be executed just prior to the output
+ of assembler code for INSN, to modify the extracted operands so
+ they will be output differently.
+
+ Here the argument OPVEC is the vector containing the operands
+ extracted from INSN, and NOPERANDS is the number of elements of
+ the vector which contain meaningful data for this insn. The
+ contents of this vector are what will be used to convert the insn
+ template into assembler code, so you can change the assembler
+ output by changing the contents of the vector.
+
+ This macro is useful when various assembler syntaxes share a single
+ file of instruction patterns; by defining this macro differently,
+ you can cause a large class of instructions to be output
+ differently (such as with rearranged operands). Naturally,
+ variations in assembler syntax affecting individual insn patterns
+ ought to be handled by writing conditional output routines in
+ those patterns.
+
+ If this macro is not defined, it is equivalent to a null statement.
+
+ -- Macro: PRINT_OPERAND (STREAM, X, CODE)
+ A C compound statement to output to stdio stream STREAM the
+ assembler syntax for an instruction operand X. X is an RTL
+ expression.
+
+ CODE is a value that can be used to specify one of several ways of
+ printing the operand. It is used when identical operands must be
+ printed differently depending on the context. CODE comes from the
+ `%' specification that was used to request printing of the
+ operand. If the specification was just `%DIGIT' then CODE is 0;
+ if the specification was `%LTR DIGIT' then CODE is the ASCII code
+ for LTR.
+
+ If X is a register, this macro should print the register's name.
+ The names can be found in an array `reg_names' whose type is `char
+ *[]'. `reg_names' is initialized from `REGISTER_NAMES'.
+
+ When the machine description has a specification `%PUNCT' (a `%'
+ followed by a punctuation character), this macro is called with a
+ null pointer for X and the punctuation character for CODE.
+
+ -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE)
+ A C expression which evaluates to true if CODE is a valid
+ punctuation character for use in the `PRINT_OPERAND' macro. If
+ `PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no
+ punctuation characters (except for the standard one, `%') are used
+ in this way.
+
+ -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X)
+ A C compound statement to output to stdio stream STREAM the
+ assembler syntax for an instruction operand that is a memory
+ reference whose address is X. X is an RTL expression.
+
+ On some machines, the syntax for a symbolic address depends on the
+ section that the address refers to. On these machines, define the
+ hook `TARGET_ENCODE_SECTION_INFO' to store the information into the
+ `symbol_ref', and then check for it here. *Note Assembler
+ Format::.
+
+ -- Macro: DBR_OUTPUT_SEQEND (FILE)
+ A C statement, to be executed after all slot-filler instructions
+ have been output. If necessary, call `dbr_sequence_length' to
+ determine the number of slots filled in a sequence (zero if not
+ currently outputting a sequence), to decide how many no-ops to
+ output, or whatever.
+
+ Don't define this macro if it has nothing to do, but it is helpful
+ in reading assembly output if the extent of the delay sequence is
+ made explicit (e.g. with white space).
+
+ Note that output routines for instructions with delay slots must be
+prepared to deal with not being output as part of a sequence (i.e. when
+the scheduling pass is not run, or when no slot fillers could be
+found.) The variable `final_sequence' is null when not processing a
+sequence, otherwise it contains the `sequence' rtx being output.
+
+ -- Macro: REGISTER_PREFIX
+ -- Macro: LOCAL_LABEL_PREFIX
+ -- Macro: USER_LABEL_PREFIX
+ -- Macro: IMMEDIATE_PREFIX
+ If defined, C string expressions to be used for the `%R', `%L',
+ `%U', and `%I' options of `asm_fprintf' (see `final.c'). These
+ are useful when a single `md' file must support multiple assembler
+ formats. In that case, the various `tm.h' files can define these
+ macros differently.
+
+ -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT)
+ If defined this macro should expand to a series of `case'
+ statements which will be parsed inside the `switch' statement of
+ the `asm_fprintf' function. This allows targets to define extra
+ printf formats which may useful when generating their assembler
+ statements. Note that uppercase letters are reserved for future
+ generic extensions to asm_fprintf, and so are not available to
+ target specific code. The output file is given by the parameter
+ FILE. The varargs input pointer is ARGPTR and the rest of the
+ format string, starting the character after the one that is being
+ switched upon, is pointed to by FORMAT.
+
+ -- Macro: ASSEMBLER_DIALECT
+ If your target supports multiple dialects of assembler language
+ (such as different opcodes), define this macro as a C expression
+ that gives the numeric index of the assembler language dialect to
+ use, with zero as the first variant.
+
+ If this macro is defined, you may use constructs of the form
+ `{option0|option1|option2...}'
+ in the output templates of patterns (*note Output Template::) or
+ in the first argument of `asm_fprintf'. This construct outputs
+ `option0', `option1', `option2', etc., if the value of
+ `ASSEMBLER_DIALECT' is zero, one, two, etc. Any special characters
+ within these strings retain their usual meaning. If there are
+ fewer alternatives within the braces than the value of
+ `ASSEMBLER_DIALECT', the construct outputs nothing.
+
+ If you do not define this macro, the characters `{', `|' and `}'
+ do not have any special meaning when used in templates or operands
+ to `asm_fprintf'.
+
+ Define the macros `REGISTER_PREFIX', `LOCAL_LABEL_PREFIX',
+ `USER_LABEL_PREFIX' and `IMMEDIATE_PREFIX' if you can express the
+ variations in assembler language syntax with that mechanism.
+ Define `ASSEMBLER_DIALECT' and use the `{option0|option1}' syntax
+ if the syntax variant are larger and involve such things as
+ different opcodes or operand order.
+
+ -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO)
+ A C expression to output to STREAM some assembler code which will
+ push hard register number REGNO onto the stack. The code need not
+ be optimal, since this macro is used only when profiling.
+
+ -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO)
+ A C expression to output to STREAM some assembler code which will
+ pop hard register number REGNO off of the stack. The code need
+ not be optimal, since this macro is used only when profiling.
+
+\1f
+File: gccint.info, Node: Dispatch Tables, Next: Exception Region Output, Prev: Instruction Output, Up: Assembler Format
+
+17.21.8 Output of Dispatch Tables
+---------------------------------
+
+This concerns dispatch tables.
+
+ -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL)
+ A C statement to output to the stdio stream STREAM an assembler
+ pseudo-instruction to generate a difference between two labels.
+ VALUE and REL are the numbers of two internal labels. The
+ definitions of these labels are output using
+ `(*targetm.asm_out.internal_label)', and they must be printed in
+ the same way here. For example,
+
+ fprintf (STREAM, "\t.word L%d-L%d\n",
+ VALUE, REL)
+
+ You must provide this macro on machines where the addresses in a
+ dispatch table are relative to the table's own address. If
+ defined, GCC will also use this macro on all machines when
+ producing PIC. BODY is the body of the `ADDR_DIFF_VEC'; it is
+ provided so that the mode and flags can be read.
+
+ -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE)
+ This macro should be provided on machines where the addresses in a
+ dispatch table are absolute.
+
+ The definition should be a C statement to output to the stdio
+ stream STREAM an assembler pseudo-instruction to generate a
+ reference to a label. VALUE is the number of an internal label
+ whose definition is output using
+ `(*targetm.asm_out.internal_label)'. For example,
+
+ fprintf (STREAM, "\t.word L%d\n", VALUE)
+
+ -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE)
+ Define this if the label before a jump-table needs to be output
+ specially. The first three arguments are the same as for
+ `(*targetm.asm_out.internal_label)'; the fourth argument is the
+ jump-table which follows (a `jump_insn' containing an `addr_vec'
+ or `addr_diff_vec').
+
+ This feature is used on system V to output a `swbeg' statement for
+ the table.
+
+ If this macro is not defined, these labels are output with
+ `(*targetm.asm_out.internal_label)'.
+
+ -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE)
+ Define this if something special must be output at the end of a
+ jump-table. The definition should be a C statement to be executed
+ after the assembler code for the table is written. It should write
+ the appropriate code to stdio stream STREAM. The argument TABLE
+ is the jump-table insn, and NUM is the label-number of the
+ preceding label.
+
+ If this macro is not defined, nothing special is output at the end
+ of the jump-table.
+
+ -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (STREAM, DECL,
+ FOR_EH, EMPTY)
+ This target hook emits a label at the beginning of each FDE. It
+ should be defined on targets where FDEs need special labels, and it
+ should write the appropriate label, for the FDE associated with the
+ function declaration DECL, to the stdio stream STREAM. The third
+ argument, FOR_EH, is a boolean: true if this is for an exception
+ table. The fourth argument, EMPTY, is a boolean: true if this is
+ a placeholder label for an omitted FDE.
+
+ The default is that FDEs are not given nonlocal labels.
+
+ -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL (STREAM)
+ This target hook emits a label at the beginning of the exception
+ table. It should be defined on targets where it is desirable for
+ the table to be broken up according to function.
+
+ The default is that no label is emitted.
+
+ -- Target Hook: void TARGET_UNWIND_EMIT (FILE * STREAM, rtx INSN)
+ This target hook emits and assembly directives required to unwind
+ the given instruction. This is only used when TARGET_UNWIND_INFO
+ is set.
+
+\1f
+File: gccint.info, Node: Exception Region Output, Next: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format
+
+17.21.9 Assembler Commands for Exception Regions
+------------------------------------------------
+
+This describes commands marking the start and the end of an exception
+region.
+
+ -- Macro: EH_FRAME_SECTION_NAME
+ If defined, a C string constant for the name of the section
+ containing exception handling frame unwind information. If not
+ defined, GCC will provide a default definition if the target
+ supports named sections. `crtstuff.c' uses this macro to switch
+ to the appropriate section.
+
+ You should define this symbol if your target supports DWARF 2 frame
+ unwind information and the default definition does not work.
+
+ -- Macro: EH_FRAME_IN_DATA_SECTION
+ If defined, DWARF 2 frame unwind information will be placed in the
+ data section even though the target supports named sections. This
+ might be necessary, for instance, if the system linker does garbage
+ collection and sections cannot be marked as not to be collected.
+
+ Do not define this macro unless `TARGET_ASM_NAMED_SECTION' is also
+ defined.
+
+ -- Macro: EH_TABLES_CAN_BE_READ_ONLY
+ Define this macro to 1 if your target is such that no frame unwind
+ information encoding used with non-PIC code will ever require a
+ runtime relocation, but the linker may not support merging
+ read-only and read-write sections into a single read-write section.
+
+ -- Macro: MASK_RETURN_ADDR
+ An rtx used to mask the return address found via
+ `RETURN_ADDR_RTX', so that it does not contain any extraneous set
+ bits in it.
+
+ -- Macro: DWARF2_UNWIND_INFO
+ Define this macro to 0 if your target supports DWARF 2 frame unwind
+ information, but it does not yet work with exception handling.
+ Otherwise, if your target supports this information (if it defines
+ `INCOMING_RETURN_ADDR_RTX' and either `UNALIGNED_INT_ASM_OP' or
+ `OBJECT_FORMAT_ELF'), GCC will provide a default definition of 1.
+
+ If `TARGET_UNWIND_INFO' is defined, the target specific unwinder
+ will be used in all cases. Defining this macro will enable the
+ generation of DWARF 2 frame debugging information.
+
+ If `TARGET_UNWIND_INFO' is not defined, and this macro is defined
+ to 1, the DWARF 2 unwinder will be the default exception handling
+ mechanism; otherwise, the `setjmp'/`longjmp'-based scheme will be
+ used by default.
+
+ -- Macro: TARGET_UNWIND_INFO
+ Define this macro if your target has ABI specified unwind tables.
+ Usually these will be output by `TARGET_UNWIND_EMIT'.
+
+ -- Variable: Target Hook bool TARGET_UNWIND_TABLES_DEFAULT
+ This variable should be set to `true' if the target ABI requires
+ unwinding tables even when exceptions are not used.
+
+ -- Macro: MUST_USE_SJLJ_EXCEPTIONS
+ This macro need only be defined if `DWARF2_UNWIND_INFO' is
+ runtime-variable. In that case, `except.h' cannot correctly
+ determine the corresponding definition of
+ `MUST_USE_SJLJ_EXCEPTIONS', so the target must provide it directly.
+
+ -- Macro: DONT_USE_BUILTIN_SETJMP
+ Define this macro to 1 if the `setjmp'/`longjmp'-based scheme
+ should use the `setjmp'/`longjmp' functions from the C library
+ instead of the `__builtin_setjmp'/`__builtin_longjmp' machinery.
+
+ -- Macro: DWARF_CIE_DATA_ALIGNMENT
+ This macro need only be defined if the target might save registers
+ in the function prologue at an offset to the stack pointer that is
+ not aligned to `UNITS_PER_WORD'. The definition should be the
+ negative minimum alignment if `STACK_GROWS_DOWNWARD' is defined,
+ and the positive minimum alignment otherwise. *Note SDB and
+ DWARF::. Only applicable if the target supports DWARF 2 frame
+ unwind information.
+
+ -- Variable: Target Hook bool TARGET_TERMINATE_DW2_EH_FRAME_INFO
+ Contains the value true if the target should add a zero word onto
+ the end of a Dwarf-2 frame info section when used for exception
+ handling. Default value is false if `EH_FRAME_SECTION_NAME' is
+ defined, and true otherwise.
+
+ -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG)
+ Given a register, this hook should return a parallel of registers
+ to represent where to find the register pieces. Define this hook
+ if the register and its mode are represented in Dwarf in
+ non-contiguous locations, or if the register should be represented
+ in more than one register in Dwarf. Otherwise, this hook should
+ return `NULL_RTX'. If not defined, the default is to return
+ `NULL_RTX'.
+
+ -- Target Hook: void TARGET_INIT_DWARF_REG_SIZES_EXTRA (tree ADDRESS)
+ If some registers are represented in Dwarf-2 unwind information in
+ multiple pieces, define this hook to fill in information about the
+ sizes of those pieces in the table used by the unwinder at runtime.
+ It will be called by `expand_builtin_init_dwarf_reg_sizes' after
+ filling in a single size corresponding to each hard register;
+ ADDRESS is the address of the table.
+
+ -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM)
+ This hook is used to output a reference from a frame unwinding
+ table to the type_info object identified by SYM. It should return
+ `true' if the reference was output. Returning `false' will cause
+ the reference to be output using the normal Dwarf2 routines.
+
+ -- Target Hook: bool TARGET_ARM_EABI_UNWINDER
+ This hook should be set to `true' on targets that use an ARM EABI
+ based unwinding library, and `false' on other targets. This
+ effects the format of unwinding tables, and how the unwinder in
+ entered after running a cleanup. The default is `false'.
+
+\1f
+File: gccint.info, Node: Alignment Output, Prev: Exception Region Output, Up: Assembler Format
+
+17.21.10 Assembler Commands for Alignment
+-----------------------------------------
+
+This describes commands for alignment.
+
+ -- Macro: JUMP_ALIGN (LABEL)
+ The alignment (log base 2) to put in front of LABEL, which is a
+ common destination of jumps and has no fallthru incoming edge.
+
+ This macro need not be defined if you don't want any special
+ alignment to be done at such a time. Most machine descriptions do
+ not currently define the macro.
+
+ Unless it's necessary to inspect the LABEL parameter, it is better
+ to set the variable ALIGN_JUMPS in the target's
+ `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's
+ selection in ALIGN_JUMPS in a `JUMP_ALIGN' implementation.
+
+ -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL)
+ The alignment (log base 2) to put in front of LABEL, which follows
+ a `BARRIER'.
+
+ This macro need not be defined if you don't want any special
+ alignment to be done at such a time. Most machine descriptions do
+ not currently define the macro.
+
+ -- Macro: LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP
+ The maximum number of bytes to skip when applying
+ `LABEL_ALIGN_AFTER_BARRIER'. This works only if
+ `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined.
+
+ -- Macro: LOOP_ALIGN (LABEL)
+ The alignment (log base 2) to put in front of LABEL, which follows
+ a `NOTE_INSN_LOOP_BEG' note.
+
+ This macro need not be defined if you don't want any special
+ alignment to be done at such a time. Most machine descriptions do
+ not currently define the macro.
+
+ Unless it's necessary to inspect the LABEL parameter, it is better
+ to set the variable `align_loops' in the target's
+ `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's
+ selection in `align_loops' in a `LOOP_ALIGN' implementation.
+
+ -- Macro: LOOP_ALIGN_MAX_SKIP
+ The maximum number of bytes to skip when applying `LOOP_ALIGN'.
+ This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined.
+
+ -- Macro: LABEL_ALIGN (LABEL)
+ The alignment (log base 2) to put in front of LABEL. If
+ `LABEL_ALIGN_AFTER_BARRIER' / `LOOP_ALIGN' specify a different
+ alignment, the maximum of the specified values is used.
+
+ Unless it's necessary to inspect the LABEL parameter, it is better
+ to set the variable `align_labels' in the target's
+ `OVERRIDE_OPTIONS'. Otherwise, you should try to honor the user's
+ selection in `align_labels' in a `LABEL_ALIGN' implementation.
+
+ -- Macro: LABEL_ALIGN_MAX_SKIP
+ The maximum number of bytes to skip when applying `LABEL_ALIGN'.
+ This works only if `ASM_OUTPUT_MAX_SKIP_ALIGN' is defined.
+
+ -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES)
+ A C statement to output to the stdio stream STREAM an assembler
+ instruction to advance the location counter by NBYTES bytes.
+ Those bytes should be zero when loaded. NBYTES will be a C
+ expression of type `unsigned HOST_WIDE_INT'.
+
+ -- Macro: ASM_NO_SKIP_IN_TEXT
+ Define this macro if `ASM_OUTPUT_SKIP' should not be used in the
+ text section because it fails to put zeros in the bytes that are
+ skipped. This is true on many Unix systems, where the pseudo-op
+ to skip bytes produces no-op instructions rather than zeros when
+ used in the text section.
+
+ -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER)
+ A C statement to output to the stdio stream STREAM an assembler
+ command to advance the location counter to a multiple of 2 to the
+ POWER bytes. POWER will be a C expression of type `int'.
+
+ -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER)
+ Like `ASM_OUTPUT_ALIGN', except that the "nop" instruction is used
+ for padding, if necessary.
+
+ -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP)
+ A C statement to output to the stdio stream STREAM an assembler
+ command to advance the location counter to a multiple of 2 to the
+ POWER bytes, but only if MAX_SKIP or fewer bytes are needed to
+ satisfy the alignment request. POWER and MAX_SKIP will be a C
+ expression of type `int'.
+
+\1f
+File: gccint.info, Node: Debugging Info, Next: Floating Point, Prev: Assembler Format, Up: Target Macros
+
+17.22 Controlling Debugging Information Format
+==============================================
+
+This describes how to specify debugging information.
+
+* Menu:
+
+* All Debuggers:: Macros that affect all debugging formats uniformly.
+* DBX Options:: Macros enabling specific options in DBX format.
+* DBX Hooks:: Hook macros for varying DBX format.
+* File Names and DBX:: Macros controlling output of file names in DBX format.
+* SDB and DWARF:: Macros for SDB (COFF) and DWARF formats.
+* VMS Debug:: Macros for VMS debug format.
+
+\1f
+File: gccint.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info
+
+17.22.1 Macros Affecting All Debugging Formats
+----------------------------------------------
+
+These macros affect all debugging formats.
+
+ -- Macro: DBX_REGISTER_NUMBER (REGNO)
+ A C expression that returns the DBX register number for the
+ compiler register number REGNO. In the default macro provided,
+ the value of this expression will be REGNO itself. But sometimes
+ there are some registers that the compiler knows about and DBX
+ does not, or vice versa. In such cases, some register may need to
+ have one number in the compiler and another for DBX.
+
+ If two registers have consecutive numbers inside GCC, and they can
+ be used as a pair to hold a multiword value, then they _must_ have
+ consecutive numbers after renumbering with `DBX_REGISTER_NUMBER'.
+ Otherwise, debuggers will be unable to access such a pair, because
+ they expect register pairs to be consecutive in their own
+ numbering scheme.
+
+ If you find yourself defining `DBX_REGISTER_NUMBER' in way that
+ does not preserve register pairs, then what you must do instead is
+ redefine the actual register numbering scheme.
+
+ -- Macro: DEBUGGER_AUTO_OFFSET (X)
+ A C expression that returns the integer offset value for an
+ automatic variable having address X (an RTL expression). The
+ default computation assumes that X is based on the frame-pointer
+ and gives the offset from the frame-pointer. This is required for
+ targets that produce debugging output for DBX or COFF-style
+ debugging output for SDB and allow the frame-pointer to be
+ eliminated when the `-g' options is used.
+
+ -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X)
+ A C expression that returns the integer offset value for an
+ argument having address X (an RTL expression). The nominal offset
+ is OFFSET.
+
+ -- Macro: PREFERRED_DEBUGGING_TYPE
+ A C expression that returns the type of debugging output GCC should
+ produce when the user specifies just `-g'. Define this if you
+ have arranged for GCC to support more than one format of debugging
+ output. Currently, the allowable values are `DBX_DEBUG',
+ `SDB_DEBUG', `DWARF_DEBUG', `DWARF2_DEBUG', `XCOFF_DEBUG',
+ `VMS_DEBUG', and `VMS_AND_DWARF2_DEBUG'.
+
+ When the user specifies `-ggdb', GCC normally also uses the value
+ of this macro to select the debugging output format, but with two
+ exceptions. If `DWARF2_DEBUGGING_INFO' is defined, GCC uses the
+ value `DWARF2_DEBUG'. Otherwise, if `DBX_DEBUGGING_INFO' is
+ defined, GCC uses `DBX_DEBUG'.
+
+ The value of this macro only affects the default debugging output;
+ the user can always get a specific type of output by using
+ `-gstabs', `-gcoff', `-gdwarf-2', `-gxcoff', or `-gvms'.
+
+\1f
+File: gccint.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info
+
+17.22.2 Specific Options for DBX Output
+---------------------------------------
+
+These are specific options for DBX output.
+
+ -- Macro: DBX_DEBUGGING_INFO
+ Define this macro if GCC should produce debugging output for DBX
+ in response to the `-g' option.
+
+ -- Macro: XCOFF_DEBUGGING_INFO
+ Define this macro if GCC should produce XCOFF format debugging
+ output in response to the `-g' option. This is a variant of DBX
+ format.
+
+ -- Macro: DEFAULT_GDB_EXTENSIONS
+ Define this macro to control whether GCC should by default generate
+ GDB's extended version of DBX debugging information (assuming
+ DBX-format debugging information is enabled at all). If you don't
+ define the macro, the default is 1: always generate the extended
+ information if there is any occasion to.
+
+ -- Macro: DEBUG_SYMS_TEXT
+ Define this macro if all `.stabs' commands should be output while
+ in the text section.
+
+ -- Macro: ASM_STABS_OP
+ A C string constant, including spacing, naming the assembler
+ pseudo op to use instead of `"\t.stabs\t"' to define an ordinary
+ debugging symbol. If you don't define this macro, `"\t.stabs\t"'
+ is used. This macro applies only to DBX debugging information
+ format.
+
+ -- Macro: ASM_STABD_OP
+ A C string constant, including spacing, naming the assembler
+ pseudo op to use instead of `"\t.stabd\t"' to define a debugging
+ symbol whose value is the current location. If you don't define
+ this macro, `"\t.stabd\t"' is used. This macro applies only to
+ DBX debugging information format.
+
+ -- Macro: ASM_STABN_OP
+ A C string constant, including spacing, naming the assembler
+ pseudo op to use instead of `"\t.stabn\t"' to define a debugging
+ symbol with no name. If you don't define this macro,
+ `"\t.stabn\t"' is used. This macro applies only to DBX debugging
+ information format.
+
+ -- Macro: DBX_NO_XREFS
+ Define this macro if DBX on your system does not support the
+ construct `xsTAGNAME'. On some systems, this construct is used to
+ describe a forward reference to a structure named TAGNAME. On
+ other systems, this construct is not supported at all.
+
+ -- Macro: DBX_CONTIN_LENGTH
+ A symbol name in DBX-format debugging information is normally
+ continued (split into two separate `.stabs' directives) when it
+ exceeds a certain length (by default, 80 characters). On some
+ operating systems, DBX requires this splitting; on others,
+ splitting must not be done. You can inhibit splitting by defining
+ this macro with the value zero. You can override the default
+ splitting-length by defining this macro as an expression for the
+ length you desire.
+
+ -- Macro: DBX_CONTIN_CHAR
+ Normally continuation is indicated by adding a `\' character to
+ the end of a `.stabs' string when a continuation follows. To use
+ a different character instead, define this macro as a character
+ constant for the character you want to use. Do not define this
+ macro if backslash is correct for your system.
+
+ -- Macro: DBX_STATIC_STAB_DATA_SECTION
+ Define this macro if it is necessary to go to the data section
+ before outputting the `.stabs' pseudo-op for a non-global static
+ variable.
+
+ -- Macro: DBX_TYPE_DECL_STABS_CODE
+ The value to use in the "code" field of the `.stabs' directive for
+ a typedef. The default is `N_LSYM'.
+
+ -- Macro: DBX_STATIC_CONST_VAR_CODE
+ The value to use in the "code" field of the `.stabs' directive for
+ a static variable located in the text section. DBX format does not
+ provide any "right" way to do this. The default is `N_FUN'.
+
+ -- Macro: DBX_REGPARM_STABS_CODE
+ The value to use in the "code" field of the `.stabs' directive for
+ a parameter passed in registers. DBX format does not provide any
+ "right" way to do this. The default is `N_RSYM'.
+
+ -- Macro: DBX_REGPARM_STABS_LETTER
+ The letter to use in DBX symbol data to identify a symbol as a
+ parameter passed in registers. DBX format does not customarily
+ provide any way to do this. The default is `'P''.
+
+ -- Macro: DBX_FUNCTION_FIRST
+ Define this macro if the DBX information for a function and its
+ arguments should precede the assembler code for the function.
+ Normally, in DBX format, the debugging information entirely
+ follows the assembler code.
+
+ -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE
+ Define this macro, with value 1, if the value of a symbol
+ describing the scope of a block (`N_LBRAC' or `N_RBRAC') should be
+ relative to the start of the enclosing function. Normally, GCC
+ uses an absolute address.
+
+ -- Macro: DBX_LINES_FUNCTION_RELATIVE
+ Define this macro, with value 1, if the value of a symbol
+ indicating the current line number (`N_SLINE') should be relative
+ to the start of the enclosing function. Normally, GCC uses an
+ absolute address.
+
+ -- Macro: DBX_USE_BINCL
+ Define this macro if GCC should generate `N_BINCL' and `N_EINCL'
+ stabs for included header files, as on Sun systems. This macro
+ also directs GCC to output a type number as a pair of a file
+ number and a type number within the file. Normally, GCC does not
+ generate `N_BINCL' or `N_EINCL' stabs, and it outputs a single
+ number for a type number.
+
+\1f
+File: gccint.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info
+
+17.22.3 Open-Ended Hooks for DBX Format
+---------------------------------------
+
+These are hooks for DBX format.
+
+ -- Macro: DBX_OUTPUT_LBRAC (STREAM, NAME)
+ Define this macro to say how to output to STREAM the debugging
+ information for the start of a scope level for variable names. The
+ argument NAME is the name of an assembler symbol (for use with
+ `assemble_name') whose value is the address where the scope begins.
+
+ -- Macro: DBX_OUTPUT_RBRAC (STREAM, NAME)
+ Like `DBX_OUTPUT_LBRAC', but for the end of a scope level.
+
+ -- Macro: DBX_OUTPUT_NFUN (STREAM, LSCOPE_LABEL, DECL)
+ Define this macro if the target machine requires special handling
+ to output an `N_FUN' entry for the function DECL.
+
+ -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER)
+ A C statement to output DBX debugging information before code for
+ line number LINE of the current source file to the stdio stream
+ STREAM. COUNTER is the number of time the macro was invoked,
+ including the current invocation; it is intended to generate
+ unique labels in the assembly output.
+
+ This macro should not be defined if the default output is correct,
+ or if it can be made correct by defining
+ `DBX_LINES_FUNCTION_RELATIVE'.
+
+ -- Macro: NO_DBX_FUNCTION_END
+ Some stabs encapsulation formats (in particular ECOFF), cannot
+ handle the `.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx
+ extension construct. On those machines, define this macro to turn
+ this feature off without disturbing the rest of the gdb extensions.
+
+ -- Macro: NO_DBX_BNSYM_ENSYM
+ Some assemblers cannot handle the `.stabd BNSYM/ENSYM,0,0' gdb dbx
+ extension construct. On those machines, define this macro to turn
+ this feature off without disturbing the rest of the gdb extensions.
+
+\1f
+File: gccint.info, Node: File Names and DBX, Next: SDB and DWARF, Prev: DBX Hooks, Up: Debugging Info
+
+17.22.4 File Names in DBX Format
+--------------------------------
+
+This describes file names in DBX format.
+
+ -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME)
+ A C statement to output DBX debugging information to the stdio
+ stream STREAM, which indicates that file NAME is the main source
+ file--the file specified as the input file for compilation. This
+ macro is called only once, at the beginning of compilation.
+
+ This macro need not be defined if the standard form of output for
+ DBX debugging information is appropriate.
+
+ It may be necessary to refer to a label equal to the beginning of
+ the text section. You can use `assemble_name (stream,
+ ltext_label_name)' to do so. If you do this, you must also set
+ the variable USED_LTEXT_LABEL_NAME to `true'.
+
+ -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY
+ Define this macro, with value 1, if GCC should not emit an
+ indication of the current directory for compilation and current
+ source language at the beginning of the file.
+
+ -- Macro: NO_DBX_GCC_MARKER
+ Define this macro, with value 1, if GCC should not emit an
+ indication that this object file was compiled by GCC. The default
+ is to emit an `N_OPT' stab at the beginning of every source file,
+ with `gcc2_compiled.' for the string and value 0.
+
+ -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME)
+ A C statement to output DBX debugging information at the end of
+ compilation of the main source file NAME. Output should be
+ written to the stdio stream STREAM.
+
+ If you don't define this macro, nothing special is output at the
+ end of compilation, which is correct for most machines.
+
+ -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END
+ Define this macro _instead of_ defining
+ `DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at
+ the end of compilation is a `N_SO' stab with an empty string,
+ whose value is the highest absolute text address in the file.
+
+\1f
+File: gccint.info, Node: SDB and DWARF, Next: VMS Debug, Prev: File Names and DBX, Up: Debugging Info
+
+17.22.5 Macros for SDB and DWARF Output
+---------------------------------------
+
+Here are macros for SDB and DWARF output.
+
+ -- Macro: SDB_DEBUGGING_INFO
+ Define this macro if GCC should produce COFF-style debugging output
+ for SDB in response to the `-g' option.
+
+ -- Macro: DWARF2_DEBUGGING_INFO
+ Define this macro if GCC should produce dwarf version 2 format
+ debugging output in response to the `-g' option.
+
+ -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (tree
+ FUNCTION)
+ Define this to enable the dwarf attribute
+ `DW_AT_calling_convention' to be emitted for each function.
+ Instead of an integer return the enum value for the `DW_CC_'
+ tag.
+
+ To support optional call frame debugging information, you must also
+ define `INCOMING_RETURN_ADDR_RTX' and either set
+ `RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the
+ prologue, or call `dwarf2out_def_cfa' and `dwarf2out_reg_save' as
+ appropriate from `TARGET_ASM_FUNCTION_PROLOGUE' if you don't.
+
+ -- Macro: DWARF2_FRAME_INFO
+ Define this macro to a nonzero value if GCC should always output
+ Dwarf 2 frame information. If `DWARF2_UNWIND_INFO' (*note
+ Exception Region Output:: is nonzero, GCC will output this
+ information not matter how you define `DWARF2_FRAME_INFO'.
+
+ -- Macro: DWARF2_ASM_LINE_DEBUG_INFO
+ Define this macro to be a nonzero value if the assembler can
+ generate Dwarf 2 line debug info sections. This will result in
+ much more compact line number tables, and hence is desirable if it
+ works.
+
+ -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2)
+ A C statement to issue assembly directives that create a difference
+ LAB1 minus LAB2, using an integer of the given SIZE.
+
+ -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL, SECTION)
+ A C statement to issue assembly directives that create a
+ section-relative reference to the given LABEL, using an integer of
+ the given SIZE. The label is known to be defined in the given
+ SECTION.
+
+ -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL)
+ A C statement to issue assembly directives that create a
+ self-relative reference to the given LABEL, using an integer of
+ the given SIZE.
+
+ -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int
+ SIZE, rtx X)
+ If defined, this target hook is a function which outputs a
+ DTP-relative reference to the given TLS symbol of the specified
+ size.
+
+ -- Macro: PUT_SDB_...
+ Define these macros to override the assembler syntax for the
+ special SDB assembler directives. See `sdbout.c' for a list of
+ these macros and their arguments. If the standard syntax is used,
+ you need not define them yourself.
+
+ -- Macro: SDB_DELIM
+ Some assemblers do not support a semicolon as a delimiter, even
+ between SDB assembler directives. In that case, define this macro
+ to be the delimiter to use (usually `\n'). It is not necessary to
+ define a new set of `PUT_SDB_OP' macros if this is the only change
+ required.
+
+ -- Macro: SDB_ALLOW_UNKNOWN_REFERENCES
+ Define this macro to allow references to unknown structure, union,
+ or enumeration tags to be emitted. Standard COFF does not allow
+ handling of unknown references, MIPS ECOFF has support for it.
+
+ -- Macro: SDB_ALLOW_FORWARD_REFERENCES
+ Define this macro to allow references to structure, union, or
+ enumeration tags that have not yet been seen to be handled. Some
+ assemblers choke if forward tags are used, while some require it.
+
+ -- Macro: SDB_OUTPUT_SOURCE_LINE (STREAM, LINE)
+ A C statement to output SDB debugging information before code for
+ line number LINE of the current source file to the stdio stream
+ STREAM. The default is to emit an `.ln' directive.
+
+\1f
+File: gccint.info, Node: VMS Debug, Prev: SDB and DWARF, Up: Debugging Info
+
+17.22.6 Macros for VMS Debug Format
+-----------------------------------
+
+Here are macros for VMS debug format.
+
+ -- Macro: VMS_DEBUGGING_INFO
+ Define this macro if GCC should produce debugging output for VMS
+ in response to the `-g' option. The default behavior for VMS is
+ to generate minimal debug info for a traceback in the absence of
+ `-g' unless explicitly overridden with `-g0'. This behavior is
+ controlled by `OPTIMIZATION_OPTIONS' and `OVERRIDE_OPTIONS'.
+
+\1f
+File: gccint.info, Node: Floating Point, Next: Mode Switching, Prev: Debugging Info, Up: Target Macros
+
+17.23 Cross Compilation and Floating Point
+==========================================
+
+While all modern machines use twos-complement representation for
+integers, there are a variety of representations for floating point
+numbers. This means that in a cross-compiler the representation of
+floating point numbers in the compiled program may be different from
+that used in the machine doing the compilation.
+
+ Because different representation systems may offer different amounts of
+range and precision, all floating point constants must be represented in
+the target machine's format. Therefore, the cross compiler cannot
+safely use the host machine's floating point arithmetic; it must emulate
+the target's arithmetic. To ensure consistency, GCC always uses
+emulation to work with floating point values, even when the host and
+target floating point formats are identical.
+
+ The following macros are provided by `real.h' for the compiler to use.
+All parts of the compiler which generate or optimize floating-point
+calculations must use these macros. They may evaluate their operands
+more than once, so operands must not have side effects.
+
+ -- Macro: REAL_VALUE_TYPE
+ The C data type to be used to hold a floating point value in the
+ target machine's format. Typically this is a `struct' containing
+ an array of `HOST_WIDE_INT', but all code should treat it as an
+ opaque quantity.
+
+ -- Macro: int REAL_VALUES_EQUAL (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
+ Compares for equality the two values, X and Y. If the target
+ floating point format supports negative zeroes and/or NaNs,
+ `REAL_VALUES_EQUAL (-0.0, 0.0)' is true, and `REAL_VALUES_EQUAL
+ (NaN, NaN)' is false.
+
+ -- Macro: int REAL_VALUES_LESS (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
+ Tests whether X is less than Y.
+
+ -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X)
+ Truncates X to a signed integer, rounding toward zero.
+
+ -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX
+ (REAL_VALUE_TYPE X)
+ Truncates X to an unsigned integer, rounding toward zero. If X is
+ negative, returns zero.
+
+ -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, enum
+ machine_mode MODE)
+ Converts STRING into a floating point number in the target
+ machine's representation for mode MODE. This routine can handle
+ both decimal and hexadecimal floating point constants, using the
+ syntax defined by the C language for both.
+
+ -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X)
+ Returns 1 if X is negative (including negative zero), 0 otherwise.
+
+ -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X)
+ Determines whether X represents infinity (positive or negative).
+
+ -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X)
+ Determines whether X represents a "NaN" (not-a-number).
+
+ -- Macro: void REAL_ARITHMETIC (REAL_VALUE_TYPE OUTPUT, enum tree_code
+ CODE, REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
+ Calculates an arithmetic operation on the two floating point values
+ X and Y, storing the result in OUTPUT (which must be a variable).
+
+ The operation to be performed is specified by CODE. Only the
+ following codes are supported: `PLUS_EXPR', `MINUS_EXPR',
+ `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'.
+
+ If `REAL_ARITHMETIC' is asked to evaluate division by zero and the
+ target's floating point format cannot represent infinity, it will
+ call `abort'. Callers should check for this situation first, using
+ `MODE_HAS_INFINITIES'. *Note Storage Layout::.
+
+ -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X)
+ Returns the negative of the floating point value X.
+
+ -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X)
+ Returns the absolute value of X.
+
+ -- Macro: REAL_VALUE_TYPE REAL_VALUE_TRUNCATE (REAL_VALUE_TYPE MODE,
+ enum machine_mode X)
+ Truncates the floating point value X to fit in MODE. The return
+ value is still a full-size `REAL_VALUE_TYPE', but it has an
+ appropriate bit pattern to be output as a floating constant whose
+ precision accords with mode MODE.
+
+ -- Macro: void REAL_VALUE_TO_INT (HOST_WIDE_INT LOW, HOST_WIDE_INT
+ HIGH, REAL_VALUE_TYPE X)
+ Converts a floating point value X into a double-precision integer
+ which is then stored into LOW and HIGH. If the value is not
+ integral, it is truncated.
+
+ -- Macro: void REAL_VALUE_FROM_INT (REAL_VALUE_TYPE X, HOST_WIDE_INT
+ LOW, HOST_WIDE_INT HIGH, enum machine_mode MODE)
+ Converts a double-precision integer found in LOW and HIGH, into a
+ floating point value which is then stored into X. The value is
+ truncated to fit in mode MODE.
+
+\1f
+File: gccint.info, Node: Mode Switching, Next: Target Attributes, Prev: Floating Point, Up: Target Macros
+
+17.24 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'. `MODE_AFTER',
+ `MODE_ENTRY', and `MODE_EXIT' are 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: MODE_AFTER (MODE, INSN)
+ If this macro is defined, it is evaluated for every INSN during
+ mode switching. It determines the mode that an insn results in (if
+ different from the incoming mode).
+
+ -- Macro: MODE_ENTRY (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.
+ If `MODE_ENTRY' is defined then `MODE_EXIT' must be defined.
+
+ -- Macro: MODE_EXIT (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 exit.
+ If `MODE_EXIT' is defined then `MODE_ENTRY' must be defined.
+
+ -- 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.
+
+\1f
+File: gccint.info, Node: Target Attributes, Next: Emulated TLS, Prev: Mode Switching, Up: Target Macros
+
+17.25 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 Microsoft Windows targets, you should define the macro
+ `TARGET_DLLIMPORT_DECL_ATTRIBUTES' to `1'. The compiler will then
+ define a function called `merge_dllimport_decl_attributes' which
+ can then be defined as the expansion of
+ `TARGET_MERGE_DECL_ATTRIBUTES'. You can also add
+ `handle_dll_attribute' in the attribute table for your port to
+ perform initial processing of the `dllimport' and `dllexport'
+ attributes. This is done in `i386/cygwin.h' and `i386/i386.c',
+ for example.
+
+ -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (tree DECL)
+ DECL is a variable or function with `__attribute__((dllimport))'
+ specified. Use this hook if the target needs to add extra
+ validation checks to `handle_dll_attribute'.
+
+ -- Macro: TARGET_DECLSPEC
+ Define this macro to a nonzero value if you want to treat
+ `__declspec(X)' as equivalent to `__attribute((X))'. By default,
+ this behavior is enabled only for targets that define
+ `TARGET_DLLIMPORT_DECL_ATTRIBUTES'. The current implementation of
+ `__declspec' is via a built-in macro, but you should not rely on
+ this implementation detail.
+
+ -- 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.
+
+ -- Target Hook: bool TARGET_VALID_OPTION_ATTRIBUTE_P (tree FNDECL,
+ tree NAME, tree ARGS, int FLAGS)
+ This hook is called to parse the `attribute(option("..."))', and
+ it allows the function to set different target machine compile time
+ options for the current function that might be different than the
+ options specified on the command line. The hook should return
+ `true' if the options are valid.
+
+ The hook should set the DECL_FUNCTION_SPECIFIC_TARGET field in the
+ function declaration to hold a pointer to a target specific STRUCT
+ CL_TARGET_OPTION structure.
+
+ -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR)
+ This hook is called to save any additional target specific
+ information in the STRUCT CL_TARGET_OPTION structure for function
+ specific options. *Note Option file format::.
+
+ -- Target Hook: void TARGET_OPTION_RESTORE (struct cl_target_option
+ *PTR)
+ This hook is called to restore any additional target specific
+ information in the STRUCT CL_TARGET_OPTION structure for function
+ specific options.
+
+ -- Target Hook: void TARGET_OPTION_PRINT (struct cl_target_option *PTR)
+ This hook is called to print any additional target specific
+ information in the STRUCT CL_TARGET_OPTION structure for function
+ specific options.
+
+ -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (target ARGS)
+ This target hook parses the options for `#pragma GCC option' to
+ set the machine specific options for functions that occur later in
+ the input stream. The options should be the same as handled by the
+ `TARGET_VALID_OPTION_ATTRIBUTE_P' hook.
+
+ -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE)
+ This target hook returns `false' if the CALLER function cannot
+ inline CALLEE, based on target specific information. By default,
+ inlining is not allowed if the callee function has function
+ specific target options and the caller does not use the same
+ options.
+
+\1f
+File: gccint.info, Node: Emulated TLS, Next: MIPS Coprocessors, Prev: Target Attributes, Up: Target Macros
+
+17.26 Emulating TLS
+===================
+
+For targets whose psABI does not provide Thread Local Storage via
+specific relocations and instruction sequences, an emulation layer is
+used. A set of target hooks allows this emulation layer to be
+configured for the requirements of a particular target. For instance
+the psABI may in fact specify TLS support in terms of an emulation
+layer.
+
+ The emulation layer works by creating a control object for every TLS
+object. To access the TLS object, a lookup function is provided which,
+when given the address of the control object, will return the address
+of the current thread's instance of the TLS object.
+
+ -- Target Hook: const char * TARGET_EMUTLS_GET_ADDRESS
+ Contains the name of the helper function that uses a TLS control
+ object to locate a TLS instance. The default causes libgcc's
+ emulated TLS helper function to be used.
+
+ -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON
+ Contains the name of the helper function that should be used at
+ program startup to register TLS objects that are implicitly
+ initialized to zero. If this is `NULL', all TLS objects will have
+ explicit initializers. The default causes libgcc's emulated TLS
+ registration function to be used.
+
+ -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION
+ Contains the name of the section in which TLS control variables
+ should be placed. The default of `NULL' allows these to be placed
+ in any section.
+
+ -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION
+ Contains the name of the section in which TLS initializers should
+ be placed. The default of `NULL' allows these to be placed in any
+ section.
+
+ -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX
+ Contains the prefix to be prepended to TLS control variable names.
+ The default of `NULL' uses a target-specific prefix.
+
+ -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX
+ Contains the prefix to be prepended to TLS initializer objects.
+ The default of `NULL' uses a target-specific prefix.
+
+ -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME)
+ Specifies a function that generates the FIELD_DECLs for a TLS
+ control object type. TYPE is the RECORD_TYPE the fields are for
+ and NAME should be filled with the structure tag, if the default of
+ `__emutls_object' is unsuitable. The default creates a type
+ suitable for libgcc's emulated TLS function.
+
+ -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree
+ TMPL_ADDR)
+ Specifies a function that generates the CONSTRUCTOR to initialize a
+ TLS control object. VAR is the TLS control object, DECL is the
+ TLS object and TMPL_ADDR is the address of the initializer. The
+ default initializes libgcc's emulated TLS control object.
+
+ -- Target Hook: bool TARGET_EMUTLS_VAR_ALIGN_FIXED
+ Specifies whether the alignment of TLS control variable objects is
+ fixed and should not be increased as some backends may do to
+ optimize single objects. The default is false.
+
+ -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS
+ Specifies whether a DWARF `DW_OP_form_tls_address' location
+ descriptor may be used to describe emulated TLS control objects.
+
+\1f
+File: gccint.info, Node: MIPS Coprocessors, Next: PCH Target, Prev: Emulated TLS, Up: Target Macros
+
+17.27 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.
+
+\1f
+File: gccint.info, Node: PCH Target, Next: C++ ABI, Prev: MIPS Coprocessors, Up: Target Macros
+
+17.28 Parameters for Precompiled Header Validity Checking
+=========================================================
+
+ -- Target Hook: void *TARGET_GET_PCH_VALIDITY (size_t *SZ)
+ This hook returns the data needed by `TARGET_PCH_VALID_P' and sets
+ `*SZ' to the size of the data in bytes.
+
+ -- Target Hook: const char *TARGET_PCH_VALID_P (const void *DATA,
+ size_t SZ)
+ This hook checks whether the options used to create a PCH file are
+ compatible with the current settings. It returns `NULL' if so and
+ a suitable error message if not. Error messages will be presented
+ to the user and must be localized using `_(MSG)'.
+
+ DATA is the data that was returned by `TARGET_GET_PCH_VALIDITY'
+ when the PCH file was created and SZ is the size of that data in
+ bytes. It's safe to assume that the data was created by the same
+ version of the compiler, so no format checking is needed.
+
+ The default definition of `default_pch_valid_p' should be suitable
+ for most targets.
+
+ -- Target Hook: const char *TARGET_CHECK_PCH_TARGET_FLAGS (int
+ PCH_FLAGS)
+ If this hook is nonnull, the default implementation of
+ `TARGET_PCH_VALID_P' will use it to check for compatible values of
+ `target_flags'. PCH_FLAGS specifies the value that `target_flags'
+ had when the PCH file was created. The return value is the same
+ as for `TARGET_PCH_VALID_P'.
+
+\1f
+File: gccint.info, Node: C++ ABI, Next: Misc, Prev: PCH Target, Up: Target Macros
+
+17.29 C++ ABI parameters
+========================
+
+ -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void)
+ Define this hook to override the integer type used for guard
+ variables. These are used to implement one-time construction of
+ static objects. The default is long_long_integer_type_node.
+
+ -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void)
+ This hook determines how guard variables are used. It should
+ return `false' (the default) if first byte should be used. A
+ return value of `true' indicates the least significant bit should
+ be used.
+
+ -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE)
+ This hook returns the size of the cookie to use when allocating an
+ array whose elements have the indicated TYPE. Assumes that it is
+ already known that a cookie is needed. The default is `max(sizeof
+ (size_t), alignof(type))', as defined in section 2.7 of the
+ IA64/Generic C++ ABI.
+
+ -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void)
+ This hook should return `true' if the element size should be
+ stored in array cookies. The default is to return `false'.
+
+ -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int
+ IMPORT_EXPORT)
+ If defined by a backend this hook allows the decision made to
+ export class TYPE to be overruled. Upon entry IMPORT_EXPORT will
+ contain 1 if the class is going to be exported, -1 if it is going
+ to be imported and 0 otherwise. This function should return the
+ modified value and perform any other actions necessary to support
+ the backend's targeted operating system.
+
+ -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void)
+ This hook should return `true' if constructors and destructors
+ return the address of the object created/destroyed. The default
+ is to return `false'.
+
+ -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void)
+ This hook returns true if the key method for a class (i.e., the
+ method which, if defined in the current translation unit, causes
+ the virtual table to be emitted) may be an inline function. Under
+ the standard Itanium C++ ABI the key method may be an inline
+ function so long as the function is not declared inline in the
+ class definition. Under some variants of the ABI, an inline
+ function can never be the key method. The default is to return
+ `true'.
+
+ -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree
+ DECL)
+ DECL is a virtual table, virtual table table, typeinfo object, or
+ other similar implicit class data object that will be emitted with
+ external linkage in this translation unit. No ELF visibility has
+ been explicitly specified. If the target needs to specify a
+ visibility other than that of the containing class, use this hook
+ to set `DECL_VISIBILITY' and `DECL_VISIBILITY_SPECIFIED'.
+
+ -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void)
+ This hook returns true (the default) if virtual tables and other
+ similar implicit class data objects are always COMDAT if they have
+ external linkage. If this hook returns false, then class data for
+ classes whose virtual table will be emitted in only one translation
+ unit will not be COMDAT.
+
+ -- Target Hook: bool TARGET_CXX_LIBRARY_RTTI_COMDAT (void)
+ This hook returns true (the default) if the RTTI information for
+ the basic types which is defined in the C++ runtime should always
+ be COMDAT, false if it should not be COMDAT.
+
+ -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void)
+ This hook returns true if `__aeabi_atexit' (as defined by the ARM
+ EABI) should be used to register static destructors when
+ `-fuse-cxa-atexit' is in effect. The default is to return false
+ to use `__cxa_atexit'.
+
+ -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void)
+ This hook returns true if the target `atexit' function can be used
+ in the same manner as `__cxa_atexit' to register C++ static
+ destructors. This requires that `atexit'-registered functions in
+ shared libraries are run in the correct order when the libraries
+ are unloaded. The default is to return false.
+
+ -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE)
+ TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has
+ just been defined. Use this hook to make adjustments to the class
+ (eg, tweak visibility or perform any other required target
+ modifications).
+
+\1f
+File: gccint.info, Node: Misc, Prev: C++ ABI, Up: Target Macros
+
+17.30 Miscellaneous Parameters
+==============================
+
+Here are several miscellaneous parameters.
+
+ -- Macro: HAS_LONG_COND_BRANCH
+ Define this boolean macro to indicate whether or not your
+ architecture has conditional branches that can span all of memory.
+ It is used in conjunction with an optimization that partitions hot
+ and cold basic blocks into separate sections of the executable.
+ If this macro is set to false, gcc will convert any conditional
+ branches that attempt to cross between sections into unconditional
+ branches or indirect jumps.
+
+ -- Macro: HAS_LONG_UNCOND_BRANCH
+ Define this boolean macro to indicate whether or not your
+ architecture has unconditional branches that can span all of
+ memory. It is used in conjunction with an optimization that
+ partitions hot and cold basic blocks into separate sections of the
+ executable. If this macro is set to false, gcc will convert any
+ unconditional branches that attempt to cross between sections into
+ indirect jumps.
+
+ -- 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. You need not define this macro
+ if jump-tables never contain relative addresses, or jump-tables
+ should contain relative addresses only when `-fPIC' or `-fPIC' is
+ in effect.
+
+ -- 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 (MEM_MODE)
+ Define this macro to be a C expression indicating when insns that
+ read memory in MEM_MODE, an integral mode narrower than a word,
+ set the bits outside of MEM_MODE to be either the sign-extension
+ or the zero-extension of the data read. Return `SIGN_EXTEND' for
+ values of MEM_MODE for which the insn sign-extends, `ZERO_EXTEND'
+ for which it zero-extends, and `UNKNOWN' for other modes.
+
+ This macro is not called with MEM_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 `UNKNOWN'. On machines where this macro is defined, you
+ will normally define it as the constant `SIGN_EXTEND' or
+ `ZERO_EXTEND'.
+
+ You may return a non-`UNKNOWN' value even if for some hard
+ registers the sign extension is not performed, if for the
+ `REGNO_REG_CLASS' of these hard registers
+ `CANNOT_CHANGE_MODE_CLASS' returns nonzero when the FROM mode is
+ MEM_MODE and the TO mode is any integral mode larger than this but
+ not larger than `word_mode'.
+
+ You must return `UNKNOWN' if for some hard registers that allow
+ this mode, `CANNOT_CHANGE_MODE_CLASS' says that they cannot change
+ to `word_mode', but that they can change to another integral mode
+ that is larger then MEM_MODE but still smaller than `word_mode'.
+
+ -- 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.
+
+ -- Target Hook: int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL (enum
+ machine_mode MODE)
+ When `-ffast-math' is in effect, GCC tries to optimize divisions
+ by the same divisor, by turning them into multiplications by the
+ reciprocal. This target hook specifies the minimum number of
+ divisions that should be there for GCC to perform the optimization
+ for a variable of mode MODE. The default implementation returns 3
+ if the machine has an instruction for the division, and 2 if it
+ does not.
+
+ -- 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.
+
+ -- Target Hook: int TARGET_SHIFT_TRUNCATION_MASK (enum machine_mode
+ MODE)
+ This function describes how the standard shift patterns for MODE
+ deal with shifts by negative amounts or by more than the width of
+ the mode. *Note shift patterns::.
+
+ On many machines, the shift patterns will apply a mask M to the
+ shift count, meaning that a fixed-width shift of X by Y is
+ equivalent to an arbitrary-width shift of X by Y & M. If this is
+ true for mode MODE, the function should return M, otherwise it
+ should return 0. A return value of 0 indicates that no particular
+ behavior is guaranteed.
+
+ Note that, unlike `SHIFT_COUNT_TRUNCATED', this function does
+ _not_ apply to general shift rtxes; it applies only to instructions
+ that are generated by the named shift patterns.
+
+ The default implementation of this function returns
+ `GET_MODE_BITSIZE (MODE) - 1' if `SHIFT_COUNT_TRUNCATED' and 0
+ otherwise. This definition is always safe, but if
+ `SHIFT_COUNT_TRUNCATED' is false, and some shift patterns
+ nevertheless truncate the shift count, you may get better code by
+ overriding it.
+
+ -- 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.
+
+ -- Target Hook: int TARGET_MODE_REP_EXTENDED (enum machine_mode MODE,
+ enum machine_mode REP_MODE)
+ The representation of an integral mode can be such that the values
+ are always extended to a wider integral mode. Return
+ `SIGN_EXTEND' if values of MODE are represented in sign-extended
+ form to REP_MODE. Return `UNKNOWN' otherwise. (Currently, none
+ of the targets use zero-extended representation this way so unlike
+ `LOAD_EXTEND_OP', `TARGET_MODE_REP_EXTENDED' is expected to return
+ either `SIGN_EXTEND' or `UNKNOWN'. Also no target extends MODE to
+ MODE_REP so that MODE_REP is not the next widest integral mode and
+ currently we take advantage of this fact.)
+
+ Similarly to `LOAD_EXTEND_OP' you may return a non-`UNKNOWN' value
+ even if the extension is not performed on certain hard registers
+ as long as for the `REGNO_REG_CLASS' of these hard registers
+ `CANNOT_CHANGE_MODE_CLASS' returns nonzero.
+
+ Note that `TARGET_MODE_REP_EXTENDED' and `LOAD_EXTEND_OP' describe
+ two related properties. If you define `TARGET_MODE_REP_EXTENDED
+ (mode, word_mode)' you probably also want to define
+ `LOAD_EXTEND_OP (mode)' to return the same type of extension.
+
+ In order to enforce the representation of `mode',
+ `TRULY_NOOP_TRUNCATION' should return false when truncating to
+ `mode'.
+
+ -- 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 machines that have comparison
+ operations that return floating-point values. If there are no
+ such operations, do not define this macro.
+
+ -- Macro: VECTOR_STORE_FLAG_VALUE (MODE)
+ A C expression that gives a rtx representing the nonzero true
+ element for vector comparisons. The returned rtx should be valid
+ for the inner mode of MODE which is guaranteed to be a vector
+ mode. Define this macro on machines that have vector comparison
+ operations that return a vector result. If there are no such
+ operations, do not define this macro. Typically, this macro is
+ defined as `const1_rtx' or `constm1_rtx'. This macro may return
+ `NULL_RTX' to prevent the compiler optimizing such vector
+ comparison operations for the given mode.
+
+ -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
+ -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
+ A C expression that indicates whether the architecture defines a
+ value for `clz' or `ctz' with a zero operand. A result of `0'
+ indicates the value is undefined. If the value is defined for
+ only the RTL expression, the macro should evaluate to `1'; if the
+ value applies also to the corresponding optab entry (which is
+ normally the case if it expands directly into the corresponding
+ RTL), then the macro should evaluate to `2'. In the cases where
+ the value is defined, VALUE should be set to this value.
+
+ If this macro is not defined, the value of `clz' or `ctz' at zero
+ is assumed to be undefined.
+
+ This macro must be defined if the target's expansion for `ffs'
+ relies on a particular value to get correct results. Otherwise it
+ is not necessary, though it may be used to optimize some corner
+ cases, and to provide a default expansion for the `ffs' optab.
+
+ Note that regardless of this macro the "definedness" of `clz' and
+ `ctz' at zero do _not_ extend to the builtin functions visible to
+ the user. Thus one may be free to adjust the value at will to
+ match the target expansion of these operations without fear of
+ breaking the API.
+
+ -- Macro: Pmode
+ An alias for the machine mode for pointers. On most machines,
+ define this to be the integer mode corresponding to the width of a
+ hardware pointer; `SImode' on 32-bit machine or `DImode' on 64-bit
+ machines. On some machines you must define this to be one of the
+ partial integer modes, such as `PSImode'.
+
+ The width of `Pmode' must be at least as large as the value of
+ `POINTER_SIZE'. If it is not equal, you must define the macro
+ `POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to
+ `Pmode'.
+
+ -- Macro: FUNCTION_MODE
+ An alias for the machine mode used for memory references to
+ functions being called, in `call' RTL expressions. On most CISC
+ machines, where an instruction can begin at any byte address, this
+ should be `QImode'. On most RISC machines, where all instructions
+ have fixed size and alignment, this should be a mode with the same
+ size and alignment as the machine instruction words - typically
+ `SImode' or `HImode'.
+
+ -- Macro: STDC_0_IN_SYSTEM_HEADERS
+ In normal operation, the preprocessor expands `__STDC__' to the
+ constant 1, to signify that GCC conforms to ISO Standard C. On
+ some hosts, like Solaris, the system compiler uses a different
+ convention, where `__STDC__' is normally 0, but is 1 if the user
+ specifies strict conformance to the C Standard.
+
+ Defining `STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host
+ convention when processing system header files, but when
+ processing user files `__STDC__' will always expand to 1.
+
+ -- Macro: NO_IMPLICIT_EXTERN_C
+ Define this macro if the system header files support C++ as well
+ as C. This macro inhibits the usual method of using system header
+ files in C++, which is to pretend that the file's contents are
+ enclosed in `extern "C" {...}'.
+
+ -- Macro: REGISTER_TARGET_PRAGMAS ()
+ Define this macro if you want to implement any target-specific
+ pragmas. If defined, it is a C expression which makes a series of
+ calls to `c_register_pragma' or `c_register_pragma_with_expansion'
+ for each pragma. The macro may also do any setup required for the
+ pragmas.
+
+ The primary reason to define this macro is to provide
+ compatibility with other compilers for the same target. In
+ general, we discourage definition of target-specific pragmas for
+ GCC.
+
+ If the pragma can be implemented by attributes then you should
+ consider defining the target hook `TARGET_INSERT_ATTRIBUTES' as
+ well.
+
+ Preprocessor macros that appear on pragma lines are not expanded.
+ All `#pragma' directives that do not match any registered pragma
+ are silently ignored, unless the user specifies
+ `-Wunknown-pragmas'.
+
+ -- Function: void c_register_pragma (const char *SPACE, const char
+ *NAME, void (*CALLBACK) (struct cpp_reader *))
+ -- Function: void c_register_pragma_with_expansion (const char *SPACE,
+ const char *NAME, void (*CALLBACK) (struct cpp_reader *))
+ Each call to `c_register_pragma' or
+ `c_register_pragma_with_expansion' establishes one pragma. The
+ CALLBACK routine will be called when the preprocessor encounters a
+ pragma of the form
+
+ #pragma [SPACE] NAME ...
+
+ SPACE is the case-sensitive namespace of the pragma, or `NULL' to
+ put the pragma in the global namespace. The callback routine
+ receives PFILE as its first argument, which can be passed on to
+ cpplib's functions if necessary. You can lex tokens after the
+ NAME by calling `pragma_lex'. Tokens that are not read by the
+ callback will be silently ignored. The end of the line is
+ indicated by a token of type `CPP_EOF'. Macro expansion occurs on
+ the arguments of pragmas registered with
+ `c_register_pragma_with_expansion' but not on the arguments of
+ pragmas registered with `c_register_pragma'.
+
+ Note that the use of `pragma_lex' is specific to the C and C++
+ compilers. It will not work in the Java or Fortran compilers, or
+ any other language compilers for that matter. Thus if
+ `pragma_lex' is going to be called from target-specific code, it
+ must only be done so when building the C and C++ compilers. This
+ can be done by defining the variables `c_target_objs' and
+ `cxx_target_objs' in the target entry in the `config.gcc' file.
+ These variables should name the target-specific, language-specific
+ object file which contains the code that uses `pragma_lex'. Note
+ it will also be necessary to add a rule to the makefile fragment
+ pointed to by `tmake_file' that shows how to build this object
+ file.
+
+ -- Macro: HANDLE_SYSV_PRAGMA
+ Define this macro (to a value of 1) if you want the System V style
+ pragmas `#pragma pack(<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: HANDLE_PRAGMA_PACK_WITH_EXPANSION
+ Define this macro, as well as `HANDLE_SYSV_PRAGMA', if macros
+ should be expanded in the arguments of `#pragma pack'.
+
+ -- Macro: TARGET_DEFAULT_PACK_STRUCT
+ If your target requires a structure packing default other than 0
+ (meaning the machine default), define this macro to the necessary
+ value (in bytes). This must be a value that would also be valid
+ to use with `#pragma pack()' (that is, a small power of two).
+
+ -- Macro: DOLLARS_IN_IDENTIFIERS
+ Define this macro to control use of the character `$' in
+ identifier names for the C family of languages. 0 means `$' is
+ not allowed by default; 1 means it is allowed. 1 is the default;
+ there is no need to define this macro in that case.
+
+ -- Macro: NO_DOLLAR_IN_LABEL
+ Define this macro if the assembler does not accept the character
+ `$' in label names. By default constructors and destructors in
+ G++ have `$' in the identifiers. If this macro is defined, `.' is
+ used instead.
+
+ -- Macro: NO_DOT_IN_LABEL
+ Define this macro if the assembler does not accept the character
+ `.' in label names. By default constructors and destructors in G++
+ have names that use `.'. If this macro is defined, these names
+ are rewritten to avoid `.'.
+
+ -- Macro: INSN_SETS_ARE_DELAYED (INSN)
+ Define this macro as a C expression that is nonzero if it is safe
+ for the delay slot scheduler to place instructions in the delay
+ slot of INSN, even if they appear to use a resource set or
+ clobbered in INSN. INSN is always a `jump_insn' or an `insn'; GCC
+ knows that every `call_insn' has this behavior. On machines where
+ some `insn' or `jump_insn' is really a function call and hence has
+ this behavior, you should define this macro.
+
+ You need not define this macro if it would always return zero.
+
+ -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN)
+ Define this macro as a C expression that is nonzero if it is safe
+ for the delay slot scheduler to place instructions in the delay
+ slot of INSN, even if they appear to set or clobber a resource
+ referenced in INSN. INSN is always a `jump_insn' or an `insn'.
+ On machines where some `insn' or `jump_insn' is really a function
+ call and its operands are registers whose use is actually in the
+ subroutine it calls, you should define this macro. Doing so
+ allows the delay slot scheduler to move instructions which copy
+ arguments into the argument registers into the delay slot of INSN.
+
+ You need not define this macro if it would always return zero.
+
+ -- Macro: MULTIPLE_SYMBOL_SPACES
+ Define this macro as a C expression that is nonzero if, in some
+ cases, global symbols from one translation unit may not be bound
+ to undefined symbols in another translation unit without user
+ intervention. For instance, under Microsoft Windows symbols must
+ be explicitly imported from shared libraries (DLLs).
+
+ You need not define this macro if it would always evaluate to zero.
+
+ -- Target Hook: tree TARGET_MD_ASM_CLOBBERS (tree OUTPUTS, tree
+ INPUTS, tree CLOBBERS)
+ This target hook should add to CLOBBERS `STRING_CST' trees for any
+ hard regs the port wishes to automatically clobber for an asm. It
+ should return the result of the last `tree_cons' used to add a
+ clobber. The OUTPUTS, INPUTS and CLOBBER lists are the
+ corresponding parameters to the asm and may be inspected to avoid
+ clobbering a register that is an input or output of the asm. You
+ can use `tree_overlaps_hard_reg_set', declared in `tree.h', to test
+ for overlap with regards to asm-declared registers.
+
+ -- Macro: MATH_LIBRARY
+ Define this macro as a C string constant for the linker argument
+ to link in the system math library, or `""' if the target does not
+ have a separate math library.
+
+ You need only define this macro if the default of `"-lm"' is wrong.
+
+ -- Macro: LIBRARY_PATH_ENV
+ Define this macro as a C string constant for the environment
+ variable that specifies where the linker should look for libraries.
+
+ You need only define this macro if the default of `"LIBRARY_PATH"'
+ is wrong.
+
+ -- Macro: TARGET_POSIX_IO
+ Define this macro if the target supports the following POSIX file
+ functions, access, mkdir and file locking with fcntl / F_SETLKW.
+ Defining `TARGET_POSIX_IO' will enable the test coverage code to
+ use file locking when exiting a program, which avoids race
+ conditions if the program has forked. It will also create
+ directories at run-time for cross-profiling.
+
+ -- Macro: MAX_CONDITIONAL_EXECUTE
+ A C expression for the maximum number of instructions to execute
+ via conditional execution instructions instead of a branch. A
+ value of `BRANCH_COST'+1 is the default if the machine does not
+ use cc0, and 1 if it does use cc0.
+
+ -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR)
+ Used if the target needs to perform machine-dependent
+ modifications on the conditionals used for turning basic blocks
+ into conditionally executed code. CE_INFO points to a data
+ structure, `struct ce_if_block', which contains information about
+ the currently processed blocks. TRUE_EXPR and FALSE_EXPR are the
+ tests that are used for converting the then-block and the
+ else-block, respectively. Set either TRUE_EXPR or FALSE_EXPR to a
+ null pointer if the tests cannot be converted.
+
+ -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR,
+ FALSE_EXPR)
+ Like `IFCVT_MODIFY_TESTS', but used when converting more
+ complicated if-statements into conditions combined by `and' and
+ `or' operations. BB contains the basic block that contains the
+ test that is currently being processed and about to be turned into
+ a condition.
+
+ -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN)
+ A C expression to modify the PATTERN of an INSN that is to be
+ converted to conditional execution format. CE_INFO points to a
+ data structure, `struct ce_if_block', which contains information
+ about the currently processed blocks.
+
+ -- Macro: IFCVT_MODIFY_FINAL (CE_INFO)
+ A C expression to perform any final machine dependent
+ modifications in converting code to conditional execution. The
+ involved basic blocks can be found in the `struct ce_if_block'
+ structure that is pointed to by CE_INFO.
+
+ -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO)
+ A C expression to cancel any machine dependent modifications in
+ converting code to conditional execution. The involved basic
+ blocks can be found in the `struct ce_if_block' structure that is
+ pointed to by CE_INFO.
+
+ -- Macro: IFCVT_INIT_EXTRA_FIELDS (CE_INFO)
+ A C expression to initialize any extra fields in a `struct
+ ce_if_block' structure, which are defined by the
+ `IFCVT_EXTRA_FIELDS' macro.
+
+ -- Macro: IFCVT_EXTRA_FIELDS
+ If defined, it should expand to a set of field declarations that
+ will be added to the `struct ce_if_block' structure. These should
+ be initialized by the `IFCVT_INIT_EXTRA_FIELDS' macro.
+
+ -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG ()
+ If non-null, this hook performs a target-specific pass over the
+ instruction stream. The compiler will run it at all optimization
+ levels, just before the point at which it normally does
+ delayed-branch scheduling.
+
+ The exact purpose of the hook varies from target to target. Some
+ use it to do transformations that are necessary for correctness,
+ such as laying out in-function constant pools or avoiding hardware
+ hazards. Others use it as an opportunity to do some
+ machine-dependent optimizations.
+
+ You need not implement the hook if it has nothing to do. The
+ default definition is null.
+
+ -- Target Hook: void TARGET_INIT_BUILTINS ()
+ Define this hook if you have any machine-specific built-in
+ functions that need to be defined. It should be a function that
+ performs the necessary setup.
+
+ Machine specific built-in functions can be useful to expand
+ special machine instructions that would otherwise not normally be
+ generated because they have no equivalent in the source language
+ (for example, SIMD vector instructions or prefetch instructions).
+
+ To create a built-in function, call the function
+ `lang_hooks.builtin_function' which is defined by the language
+ front end. You can use any type nodes set up by
+ `build_common_tree_nodes' and `build_common_tree_nodes_2'; only
+ language front ends that use those two functions will call
+ `TARGET_INIT_BUILTINS'.
+
+ -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx
+ SUBTARGET, enum machine_mode MODE, int IGNORE)
+ Expand a call to a machine specific built-in function that was set
+ up by `TARGET_INIT_BUILTINS'. EXP is the expression for the
+ function call; the result should go to TARGET if that is
+ convenient, and have mode MODE if that is convenient. SUBTARGET
+ may be used as the target for computing one of EXP's operands.
+ IGNORE is nonzero if the value is to be ignored. This function
+ should return the result of the call to the built-in function.
+
+ -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (tree FNDECL,
+ tree ARGLIST)
+ Select a replacement for a machine specific built-in function that
+ was set up by `TARGET_INIT_BUILTINS'. This is done _before_
+ regular type checking, and so allows the target to implement a
+ crude form of function overloading. FNDECL is the declaration of
+ the built-in function. ARGLIST is the list of arguments passed to
+ the built-in function. The result is a complete expression that
+ implements the operation, usually another `CALL_EXPR'.
+
+ -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, tree ARGLIST,
+ bool IGNORE)
+ Fold a call to a machine specific built-in function that was set
+ up by `TARGET_INIT_BUILTINS'. FNDECL is the declaration of the
+ built-in function. ARGLIST is the list of arguments passed to the
+ built-in function. The result is another tree containing a
+ simplified expression for the call's result. If IGNORE is true
+ the value will be ignored.
+
+ -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (rtx INSN)
+ Take an instruction in INSN and return NULL if it is valid within a
+ low-overhead loop, otherwise return a string why doloop could not
+ be applied.
+
+ Many targets use special registers for low-overhead looping. For
+ any instruction that clobbers these this function should return a
+ string indicating the reason why the doloop could not be applied.
+ By default, the RTL loop optimizer does not use a present doloop
+ pattern for loops containing function calls or branch on table
+ instructions.
+
+ -- Macro: MD_CAN_REDIRECT_BRANCH (BRANCH1, BRANCH2)
+ Take a branch insn in BRANCH1 and another in BRANCH2. Return true
+ if redirecting BRANCH1 to the destination of BRANCH2 is possible.
+
+ On some targets, branches may have a limited range. Optimizing the
+ filling of delay slots can result in branches being redirected,
+ and this may in turn cause a branch offset to overflow.
+
+ -- Target Hook: bool TARGET_COMMUTATIVE_P (rtx X, OUTER_CODE)
+ This target hook returns `true' if X is considered to be
+ commutative. Usually, this is just COMMUTATIVE_P (X), but the HP
+ PA doesn't consider PLUS to be commutative inside a MEM.
+ OUTER_CODE is the rtx code of the enclosing rtl, if known,
+ otherwise it is UNKNOWN.
+
+ -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG)
+ When the initial value of a hard register has been copied in a
+ pseudo register, it is often not necessary to actually allocate
+ another register to this pseudo register, because the original
+ hard register or a stack slot it has been saved into can be used.
+ `TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register
+ allocation once for each hard register that had its initial value
+ copied by using `get_func_hard_reg_initial_val' or
+ `get_hard_reg_initial_val'. Possible values are `NULL_RTX', if
+ you don't want to do any special allocation, a `REG' rtx--that
+ would typically be the hard register itself, if it is known not to
+ be clobbered--or a `MEM'. If you are returning a `MEM', this is
+ only a hint for the allocator; it might decide to use another
+ register anyways. You may use `current_function_leaf_function' in
+ the hook, functions that use `REG_N_SETS', to determine if the hard
+ register in question will not be clobbered. The default value of
+ this hook is `NULL', which disables any special allocation.
+
+ -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned
+ FLAGS)
+ This target hook returns nonzero if X, an `unspec' or
+ `unspec_volatile' operation, might cause a trap. Targets can use
+ this hook to enhance precision of analysis for `unspec' and
+ `unspec_volatile' operations. You may call `may_trap_p_1' to
+ analyze inner elements of X in which case FLAGS should be passed
+ along.
+
+ -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL)
+ The compiler invokes this hook whenever it changes its current
+ function context (`cfun'). You can define this function if the
+ back end needs to perform any initialization or reset actions on a
+ per-function basis. For example, it may be used to implement
+ function attributes that affect register usage or code generation
+ patterns. The argument DECL is the declaration for the new
+ function context, and may be null to indicate that the compiler
+ has left a function context and is returning to processing at the
+ top level. The default hook function does nothing.
+
+ GCC sets `cfun' to a dummy function context during initialization
+ of some parts of the back end. The hook function is not invoked
+ in this situation; you need not worry about the hook being invoked
+ recursively, or when the back end is in a partially-initialized
+ state.
+
+ -- Macro: TARGET_OBJECT_SUFFIX
+ Define this macro to be a C string representing the suffix for
+ object files on your target machine. If you do not define this
+ macro, GCC will use `.o' as the suffix for object files.
+
+ -- Macro: TARGET_EXECUTABLE_SUFFIX
+ Define this macro to be a C string representing the suffix to be
+ automatically added to executable files on your target machine.
+ If you do not define this macro, GCC will use the null string as
+ the suffix for executable files.
+
+ -- Macro: COLLECT_EXPORT_LIST
+ If defined, `collect2' will scan the individual object files
+ specified on its command line and create an export list for the
+ linker. Define this macro for systems like AIX, where the linker
+ discards object files that are not referenced from `main' and uses
+ export lists.
+
+ -- Macro: MODIFY_JNI_METHOD_CALL (MDECL)
+ Define this macro to a C expression representing a variant of the
+ method call MDECL, if Java Native Interface (JNI) methods must be
+ invoked differently from other methods on your target. For
+ example, on 32-bit Microsoft Windows, JNI methods must be invoked
+ using the `stdcall' calling convention and this macro is then
+ defined as this expression:
+
+ build_type_attribute_variant (MDECL,
+ build_tree_list
+ (get_identifier ("stdcall"),
+ NULL))
+
+ -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void)
+ This target hook returns `true' past the point in which new jump
+ instructions could be created. On machines that require a
+ register for every jump such as the SHmedia ISA of SH5, this point
+ would typically be reload, so this target hook should be defined
+ to a function such as:
+
+ static bool
+ cannot_modify_jumps_past_reload_p ()
+ {
+ return (reload_completed || reload_in_progress);
+ }
+
+ -- Target Hook: int TARGET_BRANCH_TARGET_REGISTER_CLASS (void)
+ This target hook returns a register class for which branch target
+ register optimizations should be applied. All registers in this
+ class should be usable interchangeably. After reload, registers
+ in this class will be re-allocated and loads will be hoisted out
+ of loops and be subjected to inter-block scheduling.
+
+ -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool
+ AFTER_PROLOGUE_EPILOGUE_GEN)
+ Branch target register optimization will by default exclude
+ callee-saved registers that are not already live during the
+ current function; if this target hook returns true, they will be
+ included. The target code must than make sure that all target
+ registers in the class returned by
+ `TARGET_BRANCH_TARGET_REGISTER_CLASS' that might need saving are
+ saved. AFTER_PROLOGUE_EPILOGUE_GEN indicates if prologues and
+ epilogues have already been generated. Note, even if you only
+ return true when AFTER_PROLOGUE_EPILOGUE_GEN is false, you still
+ are likely to have to make special provisions in
+ `INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved
+ target registers.
+
+ -- Macro: POWI_MAX_MULTS
+ If defined, this macro is interpreted as a signed integer C
+ expression that specifies the maximum number of floating point
+ multiplications that should be emitted when expanding
+ exponentiation by an integer constant inline. When this value is
+ defined, exponentiation requiring more than this number of
+ multiplications is implemented by calling the system library's
+ `pow', `powf' or `powl' routines. The default value places no
+ upper bound on the multiplication count.
+
+ -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char
+ *IPREFIX, int STDINC)
+ This target hook should register any extra include files for the
+ target. The parameter STDINC indicates if normal include files
+ are present. The parameter SYSROOT is the system root directory.
+ The parameter IPREFIX is the prefix for the gcc directory.
+
+ -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const
+ char *IPREFIX, int STDINC)
+ This target hook should register any extra include files for the
+ target before any standard headers. The parameter STDINC
+ indicates if normal include files are present. The parameter
+ SYSROOT is the system root directory. The parameter IPREFIX is
+ the prefix for the gcc directory.
+
+ -- Macro: void TARGET_OPTF (char *PATH)
+ This target hook should register special include paths for the
+ target. The parameter PATH is the include to register. On Darwin
+ systems, this is used for Framework includes, which have semantics
+ that are different from `-I'.
+
+ -- Target Hook: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL)
+ This target hook returns `true' if it is safe to use a local alias
+ for a virtual function FNDECL when constructing thunks, `false'
+ otherwise. By default, the hook returns `true' for all functions,
+ if a target supports aliases (i.e. defines `ASM_OUTPUT_DEF'),
+ `false' otherwise,
+
+ -- Macro: TARGET_FORMAT_TYPES
+ If defined, this macro is the name of a global variable containing
+ target-specific format checking information for the `-Wformat'
+ option. The default is to have no target-specific format checks.
+
+ -- Macro: TARGET_N_FORMAT_TYPES
+ If defined, this macro is the number of entries in
+ `TARGET_FORMAT_TYPES'.
+
+ -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES
+ If defined, this macro is the name of a global variable containing
+ target-specific format overrides for the `-Wformat' option. The
+ default is to have no target-specific format overrides. If defined,
+ `TARGET_FORMAT_TYPES' must be defined, too.
+
+ -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT
+ If defined, this macro specifies the number of entries in
+ `TARGET_OVERRIDES_FORMAT_ATTRIBUTES'.
+
+ -- Macro: TARGET_OVERRIDES_FORMAT_INIT
+ If defined, this macro specifies the optional initialization
+ routine for target specific customizations of the system printf
+ and scanf formatter settings.
+
+ -- Target Hook: bool TARGET_RELAXED_ORDERING
+ If set to `true', means that the target's memory model does not
+ guarantee that loads which do not depend on one another will access
+ main memory in the order of the instruction stream; if ordering is
+ important, an explicit memory barrier must be used. This is true
+ of many recent processors which implement a policy of "relaxed,"
+ "weak," or "release" memory consistency, such as Alpha, PowerPC,
+ and ia64. The default is `false'.
+
+ -- Target Hook: const char *TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN
+ (tree TYPELIST, tree FUNCDECL, tree VAL)
+ If defined, this macro returns the diagnostic message when it is
+ illegal to pass argument VAL to function FUNCDECL with prototype
+ TYPELIST.
+
+ -- Target Hook: const char * TARGET_INVALID_CONVERSION (tree FROMTYPE,
+ tree TOTYPE)
+ If defined, this macro returns the diagnostic message when it is
+ invalid to convert from FROMTYPE to TOTYPE, or `NULL' if validity
+ should be determined by the front end.
+
+ -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP, tree
+ TYPE)
+ If defined, this macro returns the diagnostic message when it is
+ invalid to apply operation OP (where unary plus is denoted by
+ `CONVERT_EXPR') to an operand of type TYPE, or `NULL' if validity
+ should be determined by the front end.
+
+ -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP, tree
+ TYPE1, tree TYPE2)
+ If defined, this macro returns the diagnostic message when it is
+ invalid to apply operation OP to operands of types TYPE1 and
+ TYPE2, or `NULL' if validity should be determined by the front end.
+
+ -- Macro: TARGET_USE_JCR_SECTION
+ This macro determines whether to use the JCR section to register
+ Java classes. By default, TARGET_USE_JCR_SECTION is defined to 1
+ if both SUPPORTS_WEAK and TARGET_HAVE_NAMED_SECTIONS are true,
+ else 0.
+
+ -- Macro: OBJC_JBLEN
+ This macro determines the size of the objective C jump buffer for
+ the NeXT runtime. By default, OBJC_JBLEN is defined to an
+ innocuous value.
+
+ -- Macro: LIBGCC2_UNWIND_ATTRIBUTE
+ Define this macro if any target-specific attributes need to be
+ attached to the functions in `libgcc' that provide low-level
+ support for call stack unwinding. It is used in declarations in
+ `unwind-generic.h' and the associated definitions of those
+ functions.
+
+ -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void)
+ Define this macro to update the current function stack boundary if
+ necessary.
+
+ -- Target Hook: rtx TARGET_GET_DRAP_RTX (void)
+ Define this macro to an rtx for Dynamic Realign Argument Pointer
+ if a different argument pointer register is needed to access the
+ function's argument list when stack is aligned.
+
+ -- Target Hook: bool TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS (void)
+ When optimization is disabled, this hook indicates whether or not
+ arguments should be allocated to stack slots. Normally, GCC
+ allocates stacks slots for arguments when not optimizing in order
+ to make debugging easier. However, when a function is declared
+ with `__attribute__((naked))', there is no stack frame, and the
+ compiler cannot safely move arguments from the registers in which
+ they are passed to the stack. Therefore, this hook should return
+ true in general, but false for naked functions. The default
+ implementation always returns true.
+
+\1f
+File: gccint.info, Node: Host Config, Next: Fragments, Prev: Target Macros, Up: Top
+
+18 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.
+
+\1f
+File: gccint.info, Node: Host Common, Next: Filesystem, Up: Host Config
+
+18.1 Host Common
+================
+
+Some things are just not portable, even between similar operating
+systems, and are too difficult for autoconf to detect. They get
+implemented using hook functions in the file specified by the
+HOST_HOOK_OBJ variable in `config.gcc'.
+
+ -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void)
+ This host hook is used to set up handling for extra signals. The
+ most common thing to do in this hook is to detect stack overflow.
+
+ -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int
+ FD)
+ This host hook returns the address of some space that is likely to
+ be free in some subsequent invocation of the compiler. We intend
+ to load the PCH data at this address such that the data need not
+ be relocated. The area should be able to hold SIZE bytes. If the
+ host uses `mmap', FD is an open file descriptor that can be used
+ for probing.
+
+ -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS,
+ size_t SIZE, int FD, size_t OFFSET)
+ This host hook is called when a PCH file is about to be loaded.
+ We want to load SIZE bytes from FD at OFFSET into memory at
+ ADDRESS. The given address will be the result of a previous
+ invocation of `HOST_HOOKS_GT_PCH_GET_ADDRESS'. Return -1 if we
+ couldn't allocate SIZE bytes at ADDRESS. Return 0 if the memory
+ is allocated but the data is not loaded. Return 1 if the hook has
+ performed everything.
+
+ If the implementation uses reserved address space, free any
+ reserved space beyond SIZE, regardless of the return value. If no
+ PCH will be loaded, this hook may be called with SIZE zero, in
+ which case all reserved address space should be freed.
+
+ Do not try to handle values of ADDRESS that could not have been
+ returned by this executable; just return -1. Such values usually
+ indicate an out-of-date PCH file (built by some other GCC
+ executable), and such a PCH file won't work.
+
+ -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void);
+ This host hook returns the alignment required for allocating
+ virtual memory. Usually this is the same as getpagesize, but on
+ some hosts the alignment for reserving memory differs from the
+ pagesize for committing memory.
+
+\1f
+File: gccint.info, Node: Filesystem, Next: Host Misc, Prev: Host Common, Up: Host Config
+
+18.2 Host Filesystem
+====================
+
+GCC needs to know a number of things about the semantics of the host
+machine's filesystem. Filesystems with Unix and MS-DOS semantics are
+automatically detected. For other systems, you can define the
+following macros in `xm-MACHINE.h'.
+
+`HAVE_DOS_BASED_FILE_SYSTEM'
+ This macro is automatically defined by `system.h' if the host file
+ system obeys the semantics defined by MS-DOS instead of Unix. DOS
+ file systems are case insensitive, file specifications may begin
+ with a drive letter, and both forward slash and backslash (`/' and
+ `\') are directory separators.
+
+`DIR_SEPARATOR'
+`DIR_SEPARATOR_2'
+ If defined, these macros expand to character constants specifying
+ separators for directory names within a file specification.
+ `system.h' will automatically give them appropriate values on Unix
+ and MS-DOS file systems. If your file system is neither of these,
+ define one or both appropriately in `xm-MACHINE.h'.
+
+ However, operating systems like VMS, where constructing a pathname
+ is more complicated than just stringing together directory names
+ separated by a special character, should not define either of these
+ macros.
+
+`PATH_SEPARATOR'
+ If defined, this macro should expand to a character constant
+ specifying the separator for elements of search paths. The default
+ value is a colon (`:'). DOS-based systems usually, but not
+ always, use semicolon (`;').
+
+`VMS'
+ Define this macro if the host system is VMS.
+
+`HOST_OBJECT_SUFFIX'
+ Define this macro to be a C string representing the suffix for
+ object files on your host machine. If you do not define this
+ macro, GCC will use `.o' as the suffix for object files.
+
+`HOST_EXECUTABLE_SUFFIX'
+ Define this macro to be a C string representing the suffix for
+ executable files on your host machine. If you do not define this
+ macro, GCC will use the null string as the suffix for executable
+ files.
+
+`HOST_BIT_BUCKET'
+ A pathname defined by the host operating system, which can be
+ opened as a file and written to, but all the information written
+ is discarded. This is commonly known as a "bit bucket" or "null
+ device". If you do not define this macro, GCC will use
+ `/dev/null' as the bit bucket. If the host does not support a bit
+ bucket, define this macro to an invalid filename.
+
+`UPDATE_PATH_HOST_CANONICALIZE (PATH)'
+ If defined, a C statement (sans semicolon) that performs
+ host-dependent canonicalization when a path used in a compilation
+ driver or preprocessor is canonicalized. PATH is a malloc-ed path
+ to be canonicalized. If the C statement does canonicalize PATH
+ into a different buffer, the old path should be freed and the new
+ buffer should have been allocated with malloc.
+
+`DUMPFILE_FORMAT'
+ Define this macro to be a C string representing the format to use
+ for constructing the index part of debugging dump file names. The
+ resultant string must fit in fifteen bytes. The full filename
+ will be the concatenation of: the prefix of the assembler file
+ name, the string resulting from applying this format to an index
+ number, and a string unique to each dump file kind, e.g. `rtl'.
+
+ If you do not define this macro, GCC will use `.%02d.'. You should
+ define this macro if using the default will create an invalid file
+ name.
+
+`DELETE_IF_ORDINARY'
+ Define this macro to be a C statement (sans semicolon) that
+ performs host-dependent removal of ordinary temp files in the
+ compilation driver.
+
+ If you do not define this macro, GCC will use the default version.
+ You should define this macro if the default version does not
+ reliably remove the temp file as, for example, on VMS which allows
+ multiple versions of a file.
+
+`HOST_LACKS_INODE_NUMBERS'
+ Define this macro if the host filesystem does not report
+ meaningful inode numbers in struct stat.
+
+\1f
+File: gccint.info, Node: Host Misc, Prev: Filesystem, Up: Host Config
+
+18.3 Host Misc
+==============
+
+`FATAL_EXIT_CODE'
+ A C expression for the status code to be returned when the compiler
+ exits after serious errors. The default is the system-provided
+ macro `EXIT_FAILURE', or `1' if the system doesn't define that
+ macro. Define this macro only if these defaults are incorrect.
+
+`SUCCESS_EXIT_CODE'
+ A C expression for the status code to be returned when the compiler
+ exits without serious errors. (Warnings are not serious errors.)
+ The default is the system-provided macro `EXIT_SUCCESS', or `0' if
+ the system doesn't define that macro. Define this macro only if
+ these defaults are incorrect.
+
+`USE_C_ALLOCA'
+ Define this macro if GCC should use the C implementation of
+ `alloca' provided by `libiberty.a'. This only affects how some
+ parts of the compiler itself allocate memory. It does not change
+ code generation.
+
+ When GCC is built with a compiler other than itself, the C `alloca'
+ is always used. This is because most other implementations have
+ serious bugs. You should define this macro only on a system where
+ no stack-based `alloca' can possibly work. For instance, if a
+ system has a small limit on the size of the stack, GCC's builtin
+ `alloca' will not work reliably.
+
+`COLLECT2_HOST_INITIALIZATION'
+ If defined, a C statement (sans semicolon) that performs
+ host-dependent initialization when `collect2' is being initialized.
+
+`GCC_DRIVER_HOST_INITIALIZATION'
+ If defined, a C statement (sans semicolon) that performs
+ host-dependent initialization when a compilation driver is being
+ initialized.
+
+`HOST_LONG_LONG_FORMAT'
+ If defined, the string used to indicate an argument of type `long
+ long' to functions like `printf'. The default value is `"ll"'.
+
+ In addition, if `configure' generates an incorrect definition of any
+of the macros in `auto-host.h', you can override that definition in a
+host configuration header. If you need to do this, first see if it is
+possible to fix `configure'.
+
+\1f
+File: gccint.info, Node: Fragments, Next: Collect2, Prev: Host Config, Up: Top
+
+19 Makefile Fragments
+*********************
+
+When you configure GCC using the `configure' script, it will construct
+the file `Makefile' from the template file `Makefile.in'. When it does
+this, it can incorporate makefile fragments from the `config'
+directory. These are used to set Makefile parameters that are not
+amenable to being calculated by autoconf. The list of fragments to
+incorporate is set by `config.gcc' (and occasionally `config.build' and
+`config.host'); *Note System Config::.
+
+ Fragments are named either `t-TARGET' or `x-HOST', depending on
+whether they are relevant to configuring GCC to produce code for a
+particular target, or to configuring GCC to run on a particular host.
+Here TARGET and HOST are mnemonics which usually have some relationship
+to the canonical system name, but no formal connection.
+
+ If these files do not exist, it means nothing needs to be added for a
+given target or host. Most targets need a few `t-TARGET' fragments,
+but needing `x-HOST' fragments is rare.
+
+* Menu:
+
+* Target Fragment:: Writing `t-TARGET' files.
+* Host Fragment:: Writing `x-HOST' files.
+
+\1f
+File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments
+
+19.1 Target Makefile Fragments
+==============================
+
+Target makefile fragments can set these Makefile variables.
+
+`LIBGCC2_CFLAGS'
+ Compiler flags to use when compiling `libgcc2.c'.
+
+`LIB2FUNCS_EXTRA'
+ A list of source file names to be compiled or assembled and
+ inserted into `libgcc.a'.
+
+`Floating Point Emulation'
+ To have GCC include software floating point libraries in `libgcc.a'
+ define `FPBIT' and `DPBIT' along with a few rules as follows:
+ # We want fine grained libraries, so use the new code
+ # to build the floating point emulation libraries.
+ FPBIT = fp-bit.c
+ DPBIT = dp-bit.c
+
+
+ fp-bit.c: $(srcdir)/config/fp-bit.c
+ echo '#define FLOAT' > fp-bit.c
+ cat $(srcdir)/config/fp-bit.c >> fp-bit.c
+
+ dp-bit.c: $(srcdir)/config/fp-bit.c
+ cat $(srcdir)/config/fp-bit.c > dp-bit.c
+
+ You may need to provide additional #defines at the beginning of
+ `fp-bit.c' and `dp-bit.c' to control target endianness and other
+ options.
+
+`CRTSTUFF_T_CFLAGS'
+ Special flags used when compiling `crtstuff.c'. *Note
+ Initialization::.
+
+`CRTSTUFF_T_CFLAGS_S'
+ Special flags used when compiling `crtstuff.c' for shared linking.
+ Used if you use `crtbeginS.o' and `crtendS.o' in `EXTRA-PARTS'.
+ *Note Initialization::.
+
+`MULTILIB_OPTIONS'
+ For some targets, invoking GCC in different ways produces objects
+ that can not be linked together. For example, for some targets GCC
+ produces both big and little endian code. For these targets, you
+ must arrange for multiple versions of `libgcc.a' to be compiled,
+ one for each set of incompatible options. When GCC invokes the
+ linker, it arranges to link in the right version of `libgcc.a',
+ based on the command line options used.
+
+ The `MULTILIB_OPTIONS' macro lists the set of options for which
+ special versions of `libgcc.a' must be built. Write options that
+ are mutually incompatible side by side, separated by a slash.
+ Write options that may be used together separated by a space. The
+ build procedure will build all combinations of compatible options.
+
+ For example, if you set `MULTILIB_OPTIONS' to `m68000/m68020
+ msoft-float', `Makefile' will build special versions of `libgcc.a'
+ using the following sets of options: `-m68000', `-m68020',
+ `-msoft-float', `-m68000 -msoft-float', and `-m68020 -msoft-float'.
+
+`MULTILIB_DIRNAMES'
+ If `MULTILIB_OPTIONS' is used, this variable specifies the
+ directory names that should be used to hold the various libraries.
+ Write one element in `MULTILIB_DIRNAMES' for each element in
+ `MULTILIB_OPTIONS'. If `MULTILIB_DIRNAMES' is not used, the
+ default value will be `MULTILIB_OPTIONS', with all slashes treated
+ as spaces.
+
+ For example, if `MULTILIB_OPTIONS' is set to `m68000/m68020
+ msoft-float', then the default value of `MULTILIB_DIRNAMES' is
+ `m68000 m68020 msoft-float'. You may specify a different value if
+ you desire a different set of directory names.
+
+`MULTILIB_MATCHES'
+ Sometimes the same option may be written in two different ways.
+ If an option is listed in `MULTILIB_OPTIONS', GCC needs to know
+ about any synonyms. In that case, set `MULTILIB_MATCHES' to a
+ list of items of the form `option=option' to describe all relevant
+ synonyms. For example, `m68000=mc68000 m68020=mc68020'.
+
+`MULTILIB_EXCEPTIONS'
+ Sometimes when there are multiple sets of `MULTILIB_OPTIONS' being
+ specified, there are combinations that should not be built. In
+ that case, set `MULTILIB_EXCEPTIONS' to be all of the switch
+ exceptions in shell case syntax that should not be built.
+
+ For example the ARM processor cannot execute both hardware floating
+ point instructions and the reduced size THUMB instructions at the
+ same time, so there is no need to build libraries with both of
+ these options enabled. Therefore `MULTILIB_EXCEPTIONS' is set to:
+ *mthumb/*mhard-float*
+
+`MULTILIB_EXTRA_OPTS'
+ Sometimes it is desirable that when building multiple versions of
+ `libgcc.a' certain options should always be passed on to the
+ compiler. In that case, set `MULTILIB_EXTRA_OPTS' to be the list
+ of options to be used for all builds. If you set this, you should
+ probably set `CRTSTUFF_T_CFLAGS' to a dash followed by it.
+
+`NATIVE_SYSTEM_HEADER_DIR'
+ If the default location for system headers is not `/usr/include',
+ you must set this to the directory containing the headers. This
+ value should match the value of the `SYSTEM_INCLUDE_DIR' macro.
+
+`SPECS'
+ Unfortunately, setting `MULTILIB_EXTRA_OPTS' is not enough, since
+ it does not affect the build of target libraries, at least not the
+ build of the default multilib. One possible work-around is to use
+ `DRIVER_SELF_SPECS' to bring options from the `specs' file as if
+ they had been passed in the compiler driver command line.
+ However, you don't want to be adding these options after the
+ toolchain is installed, so you can instead tweak the `specs' file
+ that will be used during the toolchain build, while you still
+ install the original, built-in `specs'. The trick is to set
+ `SPECS' to some other filename (say `specs.install'), that will
+ then be created out of the built-in specs, and introduce a
+ `Makefile' rule to generate the `specs' file that's going to be
+ used at build time out of your `specs.install'.
+
+`T_CFLAGS'
+ These are extra flags to pass to the C compiler. They are used
+ both when building GCC, and when compiling things with the
+ just-built GCC. This variable is deprecated and should not be
+ used.
+
+\1f
+File: gccint.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments
+
+19.2 Host Makefile Fragments
+============================
+
+The use of `x-HOST' fragments is discouraged. You should only use it
+for makefile dependencies.
+
+\1f
+File: gccint.info, Node: Collect2, Next: Header Dirs, Prev: Fragments, Up: Top
+
+20 `collect2'
+*************
+
+GCC uses a utility called `collect2' on nearly all systems to arrange
+to call various initialization functions at start time.
+
+ The program `collect2' works by linking the program once and looking
+through the linker output file for symbols with particular names
+indicating they are constructor functions. If it finds any, it creates
+a new temporary `.c' file containing a table of them, compiles it, and
+links the program a second time including that file.
+
+ The actual calls to the constructors are carried out by a subroutine
+called `__main', which is called (automatically) at the beginning of
+the body of `main' (provided `main' was compiled with GNU CC). Calling
+`__main' is necessary, even when compiling C code, to allow linking C
+and C++ object code together. (If you use `-nostdlib', you get an
+unresolved reference to `__main', since it's defined in the standard
+GCC library. Include `-lgcc' at the end of your compiler command line
+to resolve this reference.)
+
+ The program `collect2' is installed as `ld' in the directory where the
+passes of the compiler are installed. When `collect2' needs to find
+the _real_ `ld', it tries the following file names:
+
+ * `real-ld' in the directories listed in the compiler's search
+ directories.
+
+ * `real-ld' in the directories listed in the environment variable
+ `PATH'.
+
+ * The file specified in the `REAL_LD_FILE_NAME' configuration macro,
+ if specified.
+
+ * `ld' in the compiler's search directories, except that `collect2'
+ will not execute itself recursively.
+
+ * `ld' in `PATH'.
+
+ "The compiler's search directories" means all the directories where
+`gcc' searches for passes of the compiler. This includes directories
+that you specify with `-B'.
+
+ Cross-compilers search a little differently:
+
+ * `real-ld' in the compiler's search directories.
+
+ * `TARGET-real-ld' in `PATH'.
+
+ * The file specified in the `REAL_LD_FILE_NAME' configuration macro,
+ if specified.
+
+ * `ld' in the compiler's search directories.
+
+ * `TARGET-ld' in `PATH'.
+
+ `collect2' explicitly avoids running `ld' using the file name under
+which `collect2' itself was invoked. In fact, it remembers up a list
+of such names--in case one copy of `collect2' finds another copy (or
+version) of `collect2' installed as `ld' in a second place in the
+search path.
+
+ `collect2' searches for the utilities `nm' and `strip' using the same
+algorithm as above for `ld'.
+
+\1f
+File: gccint.info, Node: Header Dirs, Next: Type Information, Prev: Collect2, Up: Top
+
+21 Standard Header File Directories
+***********************************
+
+`GCC_INCLUDE_DIR' means the same thing for native and cross. It is
+where GCC stores its private include files, and also where GCC stores
+the fixed include files. A cross compiled GCC runs `fixincludes' on
+the header files in `$(tooldir)/include'. (If the cross compilation
+header files need to be fixed, they must be installed before GCC is
+built. If the cross compilation header files are already suitable for
+GCC, nothing special need be done).
+
+ `GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross. It
+is where `g++' looks first for header files. The C++ library installs
+only target independent header files in that directory.
+
+ `LOCAL_INCLUDE_DIR' is used only by native compilers. GCC doesn't
+install anything there. It is normally `/usr/local/include'. This is
+where local additions to a packaged system should place header files.
+
+ `CROSS_INCLUDE_DIR' is used only by cross compilers. GCC doesn't
+install anything there.
+
+ `TOOL_INCLUDE_DIR' is used for both native and cross compilers. It is
+the place for other packages to install header files that GCC will use.
+For a cross-compiler, this is the equivalent of `/usr/include'. When
+you build a cross-compiler, `fixincludes' processes any header files in
+this directory.
+
+\1f
+File: gccint.info, Node: Type Information, Next: Funding, Prev: Header Dirs, Up: Top
+
+22 Memory Management and Type Information
+*****************************************
+
+GCC uses some fairly sophisticated memory management techniques, which
+involve determining information about GCC's data structures from GCC's
+source code and using this information to perform garbage collection and
+implement precompiled headers.
+
+ A full C parser would be too complicated for this task, so a limited
+subset of C is interpreted and special markers are used to determine
+what parts of the source to look at. All `struct' and `union'
+declarations that define data structures that are allocated under
+control of the garbage collector must be marked. All global variables
+that hold pointers to garbage-collected memory must also be marked.
+Finally, all global variables that need to be saved and restored by a
+precompiled header must be marked. (The precompiled header mechanism
+can only save static variables if they're scalar. Complex data
+structures must be allocated in garbage-collected memory to be saved in
+a precompiled header.)
+
+ The full format of a marker is
+ GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...))
+ but in most cases no options are needed. The outer double parentheses
+are still necessary, though: `GTY(())'. Markers can appear:
+
+ * In a structure definition, before the open brace;
+
+ * In a global variable declaration, after the keyword `static' or
+ `extern'; and
+
+ * In a structure field definition, before the name of the field.
+
+ Here are some examples of marking simple data structures and globals.
+
+ struct TAG GTY(())
+ {
+ FIELDS...
+ };
+
+ typedef struct TAG GTY(())
+ {
+ FIELDS...
+ } *TYPENAME;
+
+ static GTY(()) struct TAG *LIST; /* points to GC memory */
+ static GTY(()) int COUNTER; /* save counter in a PCH */
+
+ The parser understands simple typedefs such as `typedef struct TAG
+*NAME;' and `typedef int NAME;'. These don't need to be marked.
+
+* Menu:
+
+* GTY Options:: What goes inside a `GTY(())'.
+* GGC Roots:: Making global variables GGC roots.
+* Files:: How the generated files work.
+* Invoking the garbage collector:: How to invoke the garbage collector.
+
+\1f
+File: gccint.info, Node: GTY Options, Next: GGC Roots, Up: Type Information
+
+22.1 The Inside of a `GTY(())'
+==============================
+
+Sometimes the C code is not enough to fully describe the type
+structure. Extra information can be provided with `GTY' options and
+additional markers. Some options take a parameter, which may be either
+a string or a type name, depending on the parameter. If an option
+takes no parameter, it is acceptable either to omit the parameter
+entirely, or to provide an empty string as a parameter. For example,
+`GTY ((skip))' and `GTY ((skip ("")))' are equivalent.
+
+ When the parameter is a string, often it is a fragment of C code. Four
+special escapes may be used in these strings, to refer to pieces of the
+data structure being marked:
+
+`%h'
+ The current structure.
+
+`%1'
+ The structure that immediately contains the current structure.
+
+`%0'
+ The outermost structure that contains the current structure.
+
+`%a'
+ A partial expression of the form `[i1][i2]...' that indexes the
+ array item currently being marked.
+
+ For instance, suppose that you have a structure of the form
+ struct A {
+ ...
+ };
+ struct B {
+ struct A foo[12];
+ };
+ and `b' is a variable of type `struct B'. When marking `b.foo[11]',
+`%h' would expand to `b.foo[11]', `%0' and `%1' would both expand to
+`b', and `%a' would expand to `[11]'.
+
+ As in ordinary C, adjacent strings will be concatenated; this is
+helpful when you have a complicated expression.
+ GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE"
+ " ? TYPE_NEXT_VARIANT (&%h.generic)"
+ " : TREE_CHAIN (&%h.generic)")))
+
+ The available options are:
+
+`length ("EXPRESSION")'
+ There are two places the type machinery will need to be explicitly
+ told the length of an array. The first case is when a structure
+ ends in a variable-length array, like this:
+ struct rtvec_def GTY(()) {
+ int num_elem; /* number of elements */
+ rtx GTY ((length ("%h.num_elem"))) elem[1];
+ };
+
+ In this case, the `length' option is used to override the specified
+ array length (which should usually be `1'). The parameter of the
+ option is a fragment of C code that calculates the length.
+
+ The second case is when a structure or a global variable contains a
+ pointer to an array, like this:
+ tree *
+ GTY ((length ("%h.regno_pointer_align_length"))) regno_decl;
+ In this case, `regno_decl' has been allocated by writing something
+ like
+ x->regno_decl =
+ ggc_alloc (x->regno_pointer_align_length * sizeof (tree));
+ and the `length' provides the length of the field.
+
+ This second use of `length' also works on global variables, like: static GTY((length ("reg_base_value_size")))
+ rtx *reg_base_value;
+
+`skip'
+ If `skip' is applied to a field, the type machinery will ignore it.
+ This is somewhat dangerous; the only safe use is in a union when
+ one field really isn't ever used.
+
+`desc ("EXPRESSION")'
+`tag ("CONSTANT")'
+`default'
+ The type machinery needs to be told which field of a `union' is
+ currently active. This is done by giving each field a constant
+ `tag' value, and then specifying a discriminator using `desc'.
+ The value of the expression given by `desc' is compared against
+ each `tag' value, each of which should be different. If no `tag'
+ is matched, the field marked with `default' is used if there is
+ one, otherwise no field in the union will be marked.
+
+ In the `desc' option, the "current structure" is the union that it
+ discriminates. Use `%1' to mean the structure containing it.
+ There are no escapes available to the `tag' option, since it is a
+ constant.
+
+ For example,
+ struct tree_binding GTY(())
+ {
+ struct tree_common common;
+ union tree_binding_u {
+ tree GTY ((tag ("0"))) scope;
+ struct cp_binding_level * GTY ((tag ("1"))) level;
+ } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope;
+ tree value;
+ };
+
+ In this example, the value of BINDING_HAS_LEVEL_P when applied to a
+ `struct tree_binding *' is presumed to be 0 or 1. If 1, the type
+ mechanism will treat the field `level' as being present and if 0,
+ will treat the field `scope' as being present.
+
+`param_is (TYPE)'
+`use_param'
+ Sometimes it's convenient to define some data structure to work on
+ generic pointers (that is, `PTR') and then use it with a specific
+ type. `param_is' specifies the real type pointed to, and
+ `use_param' says where in the generic data structure that type
+ should be put.
+
+ For instance, to have a `htab_t' that points to trees, one would
+ write the definition of `htab_t' like this:
+ typedef struct GTY(()) {
+ ...
+ void ** GTY ((use_param, ...)) entries;
+ ...
+ } htab_t;
+ and then declare variables like this:
+ static htab_t GTY ((param_is (union tree_node))) ict;
+
+`paramN_is (TYPE)'
+`use_paramN'
+ In more complicated cases, the data structure might need to work on
+ several different types, which might not necessarily all be
+ pointers. For this, `param1_is' through `param9_is' may be used to
+ specify the real type of a field identified by `use_param1' through
+ `use_param9'.
+
+`use_params'
+ When a structure contains another structure that is parameterized,
+ there's no need to do anything special, the inner structure
+ inherits the parameters of the outer one. When a structure
+ contains a pointer to a parameterized structure, the type
+ machinery won't automatically detect this (it could, it just
+ doesn't yet), so it's necessary to tell it that the pointed-to
+ structure should use the same parameters as the outer structure.
+ This is done by marking the pointer with the `use_params' option.
+
+`deletable'
+ `deletable', when applied to a global variable, indicates that when
+ garbage collection runs, there's no need to mark anything pointed
+ to by this variable, it can just be set to `NULL' instead. This
+ is used to keep a list of free structures around for re-use.
+
+`if_marked ("EXPRESSION")'
+ Suppose you want some kinds of object to be unique, and so you put
+ them in a hash table. If garbage collection marks the hash table,
+ these objects will never be freed, even if the last other
+ reference to them goes away. GGC has special handling to deal
+ with this: if you use the `if_marked' option on a global hash
+ table, GGC will call the routine whose name is the parameter to
+ the option on each hash table entry. If the routine returns
+ nonzero, the hash table entry will be marked as usual. If the
+ routine returns zero, the hash table entry will be deleted.
+
+ The routine `ggc_marked_p' can be used to determine if an element
+ has been marked already; in fact, the usual case is to use
+ `if_marked ("ggc_marked_p")'.
+
+`mark_hook ("HOOK-ROUTINE-NAME")'
+ If provided for a structure or union type, the given
+ HOOK-ROUTINE-NAME (between double-quotes) is the name of a routine
+ called when the garbage collector has just marked the data as
+ reachable. This routine should not change the data, or call any ggc
+ routine. Its only argument is a pointer to the just marked (const)
+ structure or union.
+
+`maybe_undef'
+ When applied to a field, `maybe_undef' indicates that it's OK if
+ the structure that this fields points to is never defined, so long
+ as this field is always `NULL'. This is used to avoid requiring
+ backends to define certain optional structures. It doesn't work
+ with language frontends.
+
+`nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")'
+ The type machinery expects all pointers to point to the start of an
+ object. Sometimes for abstraction purposes it's convenient to have
+ a pointer which points inside an object. So long as it's possible
+ to convert the original object to and from the pointer, such
+ pointers can still be used. TYPE is the type of the original
+ object, the TO EXPRESSION returns the pointer given the original
+ object, and the FROM EXPRESSION returns the original object given
+ the pointer. The pointer will be available using the `%h' escape.
+
+`chain_next ("EXPRESSION")'
+`chain_prev ("EXPRESSION")'
+`chain_circular ("EXPRESSION")'
+ It's helpful for the type machinery to know if objects are often
+ chained together in long lists; this lets it generate code that
+ uses less stack space by iterating along the list instead of
+ recursing down it. `chain_next' is an expression for the next
+ item in the list, `chain_prev' is an expression for the previous
+ item. For singly linked lists, use only `chain_next'; for doubly
+ linked lists, use both. The machinery requires that taking the
+ next item of the previous item gives the original item.
+ `chain_circular' is similar to `chain_next', but can be used for
+ circular single linked lists.
+
+`reorder ("FUNCTION NAME")'
+ Some data structures depend on the relative ordering of pointers.
+ If the precompiled header machinery needs to change that ordering,
+ it will call the function referenced by the `reorder' option,
+ before changing the pointers in the object that's pointed to by
+ the field the option applies to. The function must take four
+ arguments, with the signature
+ `void *, void *, gt_pointer_operator, void *'. The first
+ parameter is a pointer to the structure that contains the object
+ being updated, or the object itself if there is no containing
+ structure. The second parameter is a cookie that should be
+ ignored. The third parameter is a routine that, given a pointer,
+ will update it to its correct new value. The fourth parameter is
+ a cookie that must be passed to the second parameter.
+
+ PCH cannot handle data structures that depend on the absolute
+ values of pointers. `reorder' functions can be expensive. When
+ possible, it is better to depend on properties of the data, like
+ an ID number or the hash of a string instead.
+
+`special ("NAME")'
+ The `special' option is used to mark types that have to be dealt
+ with by special case machinery. The parameter is the name of the
+ special case. See `gengtype.c' for further details. Avoid adding
+ new special cases unless there is no other alternative.
+
+\1f
+File: gccint.info, Node: GGC Roots, Next: Files, Prev: GTY Options, Up: Type Information
+
+22.2 Marking Roots for the Garbage Collector
+============================================
+
+In addition to keeping track of types, the type machinery also locates
+the global variables ("roots") that the garbage collector starts at.
+Roots must be declared using one of the following syntaxes:
+
+ * `extern GTY(([OPTIONS])) TYPE NAME;'
+
+ * `static GTY(([OPTIONS])) TYPE NAME;'
+ The syntax
+ * `GTY(([OPTIONS])) TYPE NAME;'
+ is _not_ accepted. There should be an `extern' declaration of such a
+variable in a header somewhere--mark that, not the definition. Or, if
+the variable is only used in one file, make it `static'.
+
+\1f
+File: gccint.info, Node: Files, Next: Invoking the garbage collector, Prev: GGC Roots, Up: Type Information
+
+22.3 Source Files Containing Type Information
+=============================================
+
+Whenever you add `GTY' markers to a source file that previously had
+none, or create a new source file containing `GTY' markers, there are
+three things you need to do:
+
+ 1. You need to add the file to the list of source files the type
+ machinery scans. There are four cases:
+
+ a. For a back-end file, this is usually done automatically; if
+ not, you should add it to `target_gtfiles' in the appropriate
+ port's entries in `config.gcc'.
+
+ b. For files shared by all front ends, add the filename to the
+ `GTFILES' variable in `Makefile.in'.
+
+ c. For files that are part of one front end, add the filename to
+ the `gtfiles' variable defined in the appropriate
+ `config-lang.in'. For C, the file is `c-config-lang.in'.
+ Headers should appear before non-headers in this list.
+
+ d. For files that are part of some but not all front ends, add
+ the filename to the `gtfiles' variable of _all_ the front ends
+ that use it.
+
+ 2. If the file was a header file, you'll need to check that it's
+ included in the right place to be visible to the generated files.
+ For a back-end header file, this should be done automatically.
+ For a front-end header file, it needs to be included by the same
+ file that includes `gtype-LANG.h'. For other header files, it
+ needs to be included in `gtype-desc.c', which is a generated file,
+ so add it to `ifiles' in `open_base_file' in `gengtype.c'.
+
+ For source files that aren't header files, the machinery will
+ generate a header file that should be included in the source file
+ you just changed. The file will be called `gt-PATH.h' where PATH
+ is the pathname relative to the `gcc' directory with slashes
+ replaced by -, so for example the header file to be included in
+ `cp/parser.c' is called `gt-cp-parser.c'. The generated header
+ file should be included after everything else in the source file.
+ Don't forget to mention this file as a dependency in the
+ `Makefile'!
+
+
+ For language frontends, there is another file that needs to be included
+somewhere. It will be called `gtype-LANG.h', where LANG is the name of
+the subdirectory the language is contained in.
+
+\1f
+File: gccint.info, Node: Invoking the garbage collector, Prev: Files, Up: Type Information
+
+22.4 How to invoke the garbage collector
+========================================
+
+The GCC garbage collector GGC is only invoked explicitly. In contrast
+with many other garbage collectors, it is not implicitly invoked by
+allocation routines when a lot of memory has been consumed. So the only
+way to have GGC reclaim storage it to call the `ggc_collect' function
+explicitly. This call is an expensive operation, as it may have to scan
+the entire heap. Beware that local variables (on the GCC call stack)
+are not followed by such an invocation (as many other garbage
+collectors do): you should reference all your data from static or
+external `GTY'-ed variables, and it is advised to call `ggc_collect'
+with a shallow call stack. The GGC is an exact mark and sweep garbage
+collector (so it does not scan the call stack for pointers). In
+practice GCC passes don't often call `ggc_collect' themselves, because
+it is called by the pass manager between passes.
+
+\1f
+File: gccint.info, Node: Funding, Next: GNU Project, Prev: Type Information, 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.
+
+\1f
+File: gccint.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top
+
+The GNU Project and GNU/Linux
+*****************************
+
+The GNU Project was launched in 1984 to develop a complete Unix-like
+operating system which is free software: the GNU system. (GNU is a
+recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".)
+Variants of the GNU operating system, which use the kernel Linux, are
+now widely used; though these systems are often referred to as "Linux",
+they are more accurately called GNU/Linux systems.
+
+ For more information, see:
+ `http://www.gnu.org/'
+ `http://www.gnu.org/gnu/linux-and-gnu.html'
+
+\1f
+File: gccint.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, Up: Top
+
+GNU General Public License
+**************************
+
+ Version 3, 29 June 2007
+
+ Copyright (C) 2007 Free Software Foundation, Inc. `http://fsf.org/'
+
+ Everyone is permitted to copy and distribute verbatim copies of this
+ license document, but changing it is not allowed.
+
+Preamble
+========
+
+The GNU General Public License is a free, copyleft license for software
+and other kinds of works.
+
+ The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works. By contrast,
+the GNU General Public License is intended to guarantee your freedom to
+share and change all versions of a program-to make sure it remains free
+software for all its users. We, the Free Software Foundation, use the
+GNU General Public License for most of our software; it applies also to
+any other work released this way by its authors. You can apply it to
+your programs, too.
+
+ When we speak of free software, we are referring to freedom, not
+price. Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+ To protect your rights, we need to prevent others from denying you
+these rights or asking you to surrender the rights. Therefore, you
+have certain responsibilities if you distribute copies of the software,
+or if you modify it: responsibilities to respect the freedom of others.
+
+ For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must pass on to the recipients the same
+freedoms that you received. You must make sure that they, too, receive
+or can get the source code. And you must show them these terms so they
+know their rights.
+
+ Developers that use the GNU GPL protect your rights with two steps:
+(1) assert copyright on the software, and (2) offer you this License
+giving you legal permission to copy, distribute and/or modify it.
+
+ For the developers' and authors' protection, the GPL clearly explains
+that there is no warranty for this free software. For both users' and
+authors' sake, the GPL requires that modified versions be marked as
+changed, so that their problems will not be attributed erroneously to
+authors of previous versions.
+
+ Some devices are designed to deny users access to install or run
+modified versions of the software inside them, although the
+manufacturer can do so. This is fundamentally incompatible with the
+aim of protecting users' freedom to change the software. The
+systematic pattern of such abuse occurs in the area of products for
+individuals to use, which is precisely where it is most unacceptable.
+Therefore, we have designed this version of the GPL to prohibit the
+practice for those products. If such problems arise substantially in
+other domains, we stand ready to extend this provision to those domains
+in future versions of the GPL, as needed to protect the freedom of
+users.
+
+ Finally, every program is threatened constantly by software patents.
+States should not allow patents to restrict development and use of
+software on general-purpose computers, but in those that do, we wish to
+avoid the special danger that patents applied to a free program could
+make it effectively proprietary. To prevent this, the GPL assures that
+patents cannot be used to render the program non-free.
+
+ The precise terms and conditions for copying, distribution and
+modification follow.
+
+TERMS AND CONDITIONS
+====================
+
+ 0. Definitions.
+
+ "This License" refers to version 3 of the GNU General Public
+ License.
+
+ "Copyright" also means copyright-like laws that apply to other
+ kinds of works, such as semiconductor masks.
+
+ "The Program" refers to any copyrightable work licensed under this
+ License. Each licensee is addressed as "you". "Licensees" and
+ "recipients" may be individuals or organizations.
+
+ To "modify" a work means to copy from or adapt all or part of the
+ work in a fashion requiring copyright permission, other than the
+ making of an exact copy. The resulting work is called a "modified
+ version" of the earlier work or a work "based on" the earlier work.
+
+ A "covered work" means either the unmodified Program or a work
+ based on the Program.
+
+ To "propagate" a work means to do anything with it that, without
+ permission, would make you directly or secondarily liable for
+ infringement under applicable copyright law, except executing it
+ on a computer or modifying a private copy. Propagation includes
+ copying, distribution (with or without modification), making
+ available to the public, and in some countries other activities as
+ well.
+
+ To "convey" a work means any kind of propagation that enables other
+ parties to make or receive copies. Mere interaction with a user
+ through a computer network, with no transfer of a copy, is not
+ conveying.
+
+ An interactive user interface displays "Appropriate Legal Notices"
+ to the extent that it includes a convenient and prominently visible
+ feature that (1) displays an appropriate copyright notice, and (2)
+ tells the user that there is no warranty for the work (except to
+ the extent that warranties are provided), that licensees may
+ convey the work under this License, and how to view a copy of this
+ License. If the interface presents a list of user commands or
+ options, such as a menu, a prominent item in the list meets this
+ criterion.
+
+ 1. Source Code.
+
+ The "source code" for a work means the preferred form of the work
+ for making modifications to it. "Object code" means any
+ non-source form of a work.
+
+ A "Standard Interface" means an interface that either is an
+ official standard defined by a recognized standards body, or, in
+ the case of interfaces specified for a particular programming
+ language, one that is widely used among developers working in that
+ language.
+
+ The "System Libraries" of an executable work include anything,
+ other than the work as a whole, that (a) is included in the normal
+ form of packaging a Major Component, but which is not part of that
+ Major Component, and (b) serves only to enable use of the work
+ with that Major Component, or to implement a Standard Interface
+ for which an implementation is available to the public in source
+ code form. A "Major Component", in this context, means a major
+ essential component (kernel, window system, and so on) of the
+ specific operating system (if any) on which the executable work
+ runs, or a compiler used to produce the work, or an object code
+ interpreter used to run it.
+
+ The "Corresponding Source" for a work in object code form means all
+ the source code needed to generate, install, and (for an executable
+ work) run the object code and to modify the work, including
+ scripts to control those activities. However, it does not include
+ the work's System Libraries, or general-purpose tools or generally
+ available free programs which are used unmodified in performing
+ those activities but which are not part of the work. For example,
+ Corresponding Source includes interface definition files
+ associated with source files for the work, and the source code for
+ shared libraries and dynamically linked subprograms that the work
+ is specifically designed to require, such as by intimate data
+ communication or control flow between those subprograms and other
+ parts of the work.
+
+ The Corresponding Source need not include anything that users can
+ regenerate automatically from other parts of the Corresponding
+ Source.
+
+ The Corresponding Source for a work in source code form is that
+ same work.
+
+ 2. Basic Permissions.
+
+ All rights granted under this License are granted for the term of
+ copyright on the Program, and are irrevocable provided the stated
+ conditions are met. This License explicitly affirms your unlimited
+ permission to run the unmodified Program. The output from running
+ a covered work is covered by this License only if the output,
+ given its content, constitutes a covered work. This License
+ acknowledges your rights of fair use or other equivalent, as
+ provided by copyright law.
+
+ You may make, run and propagate covered works that you do not
+ convey, without conditions so long as your license otherwise
+ remains in force. You may convey covered works to others for the
+ sole purpose of having them make modifications exclusively for
+ you, or provide you with facilities for running those works,
+ provided that you comply with the terms of this License in
+ conveying all material for which you do not control copyright.
+ Those thus making or running the covered works for you must do so
+ exclusively on your behalf, under your direction and control, on
+ terms that prohibit them from making any copies of your
+ copyrighted material outside their relationship with you.
+
+ Conveying under any other circumstances is permitted solely under
+ the conditions stated below. Sublicensing is not allowed; section
+ 10 makes it unnecessary.
+
+ 3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+ No covered work shall be deemed part of an effective technological
+ measure under any applicable law fulfilling obligations under
+ article 11 of the WIPO copyright treaty adopted on 20 December
+ 1996, or similar laws prohibiting or restricting circumvention of
+ such measures.
+
+ When you convey a covered work, you waive any legal power to forbid
+ circumvention of technological measures to the extent such
+ circumvention is effected by exercising rights under this License
+ with respect to the covered work, and you disclaim any intention
+ to limit operation or modification of the work as a means of
+ enforcing, against the work's users, your or third parties' legal
+ rights to forbid circumvention of technological measures.
+
+ 4. Conveying Verbatim Copies.
+
+ You may convey verbatim copies of the Program's source code as you
+ receive it, in any medium, provided that you conspicuously and
+ appropriately publish on each copy an appropriate copyright notice;
+ keep intact all notices stating that this License and any
+ non-permissive terms added in accord with section 7 apply to the
+ code; keep intact all notices of the absence of any warranty; and
+ give all recipients a copy of this License along with the Program.
+
+ You may charge any price or no price for each copy that you convey,
+ and you may offer support or warranty protection for a fee.
+
+ 5. Conveying Modified Source Versions.
+
+ You may convey a work based on the Program, or the modifications to
+ produce it from the Program, in the form of source code under the
+ terms of section 4, provided that you also meet all of these
+ conditions:
+
+ a. The work must carry prominent notices stating that you
+ modified it, and giving a relevant date.
+
+ b. The work must carry prominent notices stating that it is
+ released under this License and any conditions added under
+ section 7. This requirement modifies the requirement in
+ section 4 to "keep intact all notices".
+
+ c. You must license the entire work, as a whole, under this
+ License to anyone who comes into possession of a copy. This
+ License will therefore apply, along with any applicable
+ section 7 additional terms, to the whole of the work, and all
+ its parts, regardless of how they are packaged. This License
+ gives no permission to license the work in any other way, but
+ it does not invalidate such permission if you have separately
+ received it.
+
+ d. If the work has interactive user interfaces, each must display
+ Appropriate Legal Notices; however, if the Program has
+ interactive interfaces that do not display Appropriate Legal
+ Notices, your work need not make them do so.
+
+ A compilation of a covered work with other separate and independent
+ works, which are not by their nature extensions of the covered
+ work, and which are not combined with it such as to form a larger
+ program, in or on a volume of a storage or distribution medium, is
+ called an "aggregate" if the compilation and its resulting
+ copyright are not used to limit the access or legal rights of the
+ compilation's users beyond what the individual works permit.
+ Inclusion of a covered work in an aggregate does not cause this
+ License to apply to the other parts of the aggregate.
+
+ 6. Conveying Non-Source Forms.
+
+ You may convey a covered work in object code form under the terms
+ of sections 4 and 5, provided that you also convey the
+ machine-readable Corresponding Source under the terms of this
+ License, in one of these ways:
+
+ a. Convey the object code in, or embodied in, a physical product
+ (including a physical distribution medium), accompanied by the
+ Corresponding Source fixed on a durable physical medium
+ customarily used for software interchange.
+
+ b. Convey the object code in, or embodied in, a physical product
+ (including a physical distribution medium), accompanied by a
+ written offer, valid for at least three years and valid for
+ as long as you offer spare parts or customer support for that
+ product model, to give anyone who possesses the object code
+ either (1) a copy of the Corresponding Source for all the
+ software in the product that is covered by this License, on a
+ durable physical medium customarily used for software
+ interchange, for a price no more than your reasonable cost of
+ physically performing this conveying of source, or (2) access
+ to copy the Corresponding Source from a network server at no
+ charge.
+
+ c. Convey individual copies of the object code with a copy of
+ the written offer to provide the Corresponding Source. This
+ alternative is allowed only occasionally and noncommercially,
+ and only if you received the object code with such an offer,
+ in accord with subsection 6b.
+
+ d. Convey the object code by offering access from a designated
+ place (gratis or for a charge), and offer equivalent access
+ to the Corresponding Source in the same way through the same
+ place at no further charge. You need not require recipients
+ to copy the Corresponding Source along with the object code.
+ If the place to copy the object code is a network server, the
+ Corresponding Source may be on a different server (operated
+ by you or a third party) that supports equivalent copying
+ facilities, provided you maintain clear directions next to
+ the object code saying where to find the Corresponding Source.
+ Regardless of what server hosts the Corresponding Source, you
+ remain obligated to ensure that it is available for as long
+ as needed to satisfy these requirements.
+
+ e. Convey the object code using peer-to-peer transmission,
+ provided you inform other peers where the object code and
+ Corresponding Source of the work are being offered to the
+ general public at no charge under subsection 6d.
+
+
+ A separable portion of the object code, whose source code is
+ excluded from the Corresponding Source as a System Library, need
+ not be included in conveying the object code work.
+
+ A "User Product" is either (1) a "consumer product", which means
+ any tangible personal property which is normally used for personal,
+ family, or household purposes, or (2) anything designed or sold for
+ incorporation into a dwelling. In determining whether a product
+ is a consumer product, doubtful cases shall be resolved in favor of
+ coverage. For a particular product received by a particular user,
+ "normally used" refers to a typical or common use of that class of
+ product, regardless of the status of the particular user or of the
+ way in which the particular user actually uses, or expects or is
+ expected to use, the product. A product is a consumer product
+ regardless of whether the product has substantial commercial,
+ industrial or non-consumer uses, unless such uses represent the
+ only significant mode of use of the product.
+
+ "Installation Information" for a User Product means any methods,
+ procedures, authorization keys, or other information required to
+ install and execute modified versions of a covered work in that
+ User Product from a modified version of its Corresponding Source.
+ The information must suffice to ensure that the continued
+ functioning of the modified object code is in no case prevented or
+ interfered with solely because modification has been made.
+
+ If you convey an object code work under this section in, or with,
+ or specifically for use in, a User Product, and the conveying
+ occurs as part of a transaction in which the right of possession
+ and use of the User Product is transferred to the recipient in
+ perpetuity or for a fixed term (regardless of how the transaction
+ is characterized), the Corresponding Source conveyed under this
+ section must be accompanied by the Installation Information. But
+ this requirement does not apply if neither you nor any third party
+ retains the ability to install modified object code on the User
+ Product (for example, the work has been installed in ROM).
+
+ The requirement to provide Installation Information does not
+ include a requirement to continue to provide support service,
+ warranty, or updates for a work that has been modified or
+ installed by the recipient, or for the User Product in which it
+ has been modified or installed. Access to a network may be denied
+ when the modification itself materially and adversely affects the
+ operation of the network or violates the rules and protocols for
+ communication across the network.
+
+ Corresponding Source conveyed, and Installation Information
+ provided, in accord with this section must be in a format that is
+ publicly documented (and with an implementation available to the
+ public in source code form), and must require no special password
+ or key for unpacking, reading or copying.
+
+ 7. Additional Terms.
+
+ "Additional permissions" are terms that supplement the terms of
+ this License by making exceptions from one or more of its
+ conditions. Additional permissions that are applicable to the
+ entire Program shall be treated as though they were included in
+ this License, to the extent that they are valid under applicable
+ law. If additional permissions apply only to part of the Program,
+ that part may be used separately under those permissions, but the
+ entire Program remains governed by this License without regard to
+ the additional permissions.
+
+ When you convey a copy of a covered work, you may at your option
+ remove any additional permissions from that copy, or from any part
+ of it. (Additional permissions may be written to require their own
+ removal in certain cases when you modify the work.) You may place
+ additional permissions on material, added by you to a covered work,
+ for which you have or can give appropriate copyright permission.
+
+ Notwithstanding any other provision of this License, for material
+ you add to a covered work, you may (if authorized by the copyright
+ holders of that material) supplement the terms of this License
+ with terms:
+
+ a. Disclaiming warranty or limiting liability differently from
+ the terms of sections 15 and 16 of this License; or
+
+ b. Requiring preservation of specified reasonable legal notices
+ or author attributions in that material or in the Appropriate
+ Legal Notices displayed by works containing it; or
+
+ c. Prohibiting misrepresentation of the origin of that material,
+ or requiring that modified versions of such material be
+ marked in reasonable ways as different from the original
+ version; or
+
+ d. Limiting the use for publicity purposes of names of licensors
+ or authors of the material; or
+
+ e. Declining to grant rights under trademark law for use of some
+ trade names, trademarks, or service marks; or
+
+ f. Requiring indemnification of licensors and authors of that
+ material by anyone who conveys the material (or modified
+ versions of it) with contractual assumptions of liability to
+ the recipient, for any liability that these contractual
+ assumptions directly impose on those licensors and authors.
+
+ All other non-permissive additional terms are considered "further
+ restrictions" within the meaning of section 10. If the Program as
+ you received it, or any part of it, contains a notice stating that
+ it is governed by this License along with a term that is a further
+ restriction, you may remove that term. If a license document
+ contains a further restriction but permits relicensing or
+ conveying under this License, you may add to a covered work
+ material governed by the terms of that license document, provided
+ that the further restriction does not survive such relicensing or
+ conveying.
+
+ If you add terms to a covered work in accord with this section, you
+ must place, in the relevant source files, a statement of the
+ additional terms that apply to those files, or a notice indicating
+ where to find the applicable terms.
+
+ Additional terms, permissive or non-permissive, may be stated in
+ the form of a separately written license, or stated as exceptions;
+ the above requirements apply either way.
+
+ 8. Termination.
+
+ You may not propagate or modify a covered work except as expressly
+ provided under this License. Any attempt otherwise to propagate or
+ modify it is void, and will automatically terminate your rights
+ under this License (including any patent licenses granted under
+ the third paragraph of section 11).
+
+ However, if you cease all violation of this License, then your
+ license from a particular copyright holder is reinstated (a)
+ provisionally, unless and until the copyright holder explicitly
+ and finally terminates your license, and (b) permanently, if the
+ copyright holder fails to notify you of the violation by some
+ reasonable means prior to 60 days after the cessation.
+
+ Moreover, your license from a particular copyright holder is
+ reinstated permanently if the copyright holder notifies you of the
+ violation by some reasonable means, this is the first time you have
+ received notice of violation of this License (for any work) from
+ that copyright holder, and you cure the violation prior to 30 days
+ after your receipt of the notice.
+
+ Termination of your rights under this section does not terminate
+ the licenses of parties who have received copies or rights from
+ you under this License. If your rights have been terminated and
+ not permanently reinstated, you do not qualify to receive new
+ licenses for the same material under section 10.
+
+ 9. Acceptance Not Required for Having Copies.
+
+ You are not required to accept this License in order to receive or
+ run a copy of the Program. Ancillary propagation of a covered work
+ occurring solely as a consequence of using peer-to-peer
+ transmission to receive a copy likewise does not require
+ acceptance. However, nothing other than this License grants you
+ permission to propagate or modify any covered work. These actions
+ infringe copyright if you do not accept this License. Therefore,
+ by modifying or propagating a covered work, you indicate your
+ acceptance of this License to do so.
+
+ 10. Automatic Licensing of Downstream Recipients.
+
+ Each time you convey a covered work, the recipient automatically
+ receives a license from the original licensors, to run, modify and
+ propagate that work, subject to this License. You are not
+ responsible for enforcing compliance by third parties with this
+ License.
+
+ An "entity transaction" is a transaction transferring control of an
+ organization, or substantially all assets of one, or subdividing an
+ organization, or merging organizations. If propagation of a
+ covered work results from an entity transaction, each party to that
+ transaction who receives a copy of the work also receives whatever
+ licenses to the work the party's predecessor in interest had or
+ could give under the previous paragraph, plus a right to
+ possession of the Corresponding Source of the work from the
+ predecessor in interest, if the predecessor has it or can get it
+ with reasonable efforts.
+
+ You may not impose any further restrictions on the exercise of the
+ rights granted or affirmed under this License. For example, you
+ may not impose a license fee, royalty, or other charge for
+ exercise of rights granted under this License, and you may not
+ initiate litigation (including a cross-claim or counterclaim in a
+ lawsuit) alleging that any patent claim is infringed by making,
+ using, selling, offering for sale, or importing the Program or any
+ portion of it.
+
+ 11. Patents.
+
+ A "contributor" is a copyright holder who authorizes use under this
+ License of the Program or a work on which the Program is based.
+ The work thus licensed is called the contributor's "contributor
+ version".
+
+ A contributor's "essential patent claims" are all patent claims
+ owned or controlled by the contributor, whether already acquired or
+ hereafter acquired, that would be infringed by some manner,
+ permitted by this License, of making, using, or selling its
+ contributor version, but do not include claims that would be
+ infringed only as a consequence of further modification of the
+ contributor version. For purposes of this definition, "control"
+ includes the right to grant patent sublicenses in a manner
+ consistent with the requirements of this License.
+
+ Each contributor grants you a non-exclusive, worldwide,
+ royalty-free patent license under the contributor's essential
+ patent claims, to make, use, sell, offer for sale, import and
+ otherwise run, modify and propagate the contents of its
+ contributor version.
+
+ In the following three paragraphs, a "patent license" is any
+ express agreement or commitment, however denominated, not to
+ enforce a patent (such as an express permission to practice a
+ patent or covenant not to sue for patent infringement). To
+ "grant" such a patent license to a party means to make such an
+ agreement or commitment not to enforce a patent against the party.
+
+ If you convey a covered work, knowingly relying on a patent
+ license, and the Corresponding Source of the work is not available
+ for anyone to copy, free of charge and under the terms of this
+ License, through a publicly available network server or other
+ readily accessible means, then you must either (1) cause the
+ Corresponding Source to be so available, or (2) arrange to deprive
+ yourself of the benefit of the patent license for this particular
+ work, or (3) arrange, in a manner consistent with the requirements
+ of this License, to extend the patent license to downstream
+ recipients. "Knowingly relying" means you have actual knowledge
+ that, but for the patent license, your conveying the covered work
+ in a country, or your recipient's use of the covered work in a
+ country, would infringe one or more identifiable patents in that
+ country that you have reason to believe are valid.
+
+ If, pursuant to or in connection with a single transaction or
+ arrangement, you convey, or propagate by procuring conveyance of, a
+ covered work, and grant a patent license to some of the parties
+ receiving the covered work authorizing them to use, propagate,
+ modify or convey a specific copy of the covered work, then the
+ patent license you grant is automatically extended to all
+ recipients of the covered work and works based on it.
+
+ A patent license is "discriminatory" if it does not include within
+ the scope of its coverage, prohibits the exercise of, or is
+ conditioned on the non-exercise of one or more of the rights that
+ are specifically granted under this License. You may not convey a
+ covered work if you are a party to an arrangement with a third
+ party that is in the business of distributing software, under
+ which you make payment to the third party based on the extent of
+ your activity of conveying the work, and under which the third
+ party grants, to any of the parties who would receive the covered
+ work from you, a discriminatory patent license (a) in connection
+ with copies of the covered work conveyed by you (or copies made
+ from those copies), or (b) primarily for and in connection with
+ specific products or compilations that contain the covered work,
+ unless you entered into that arrangement, or that patent license
+ was granted, prior to 28 March 2007.
+
+ Nothing in this License shall be construed as excluding or limiting
+ any implied license or other defenses to infringement that may
+ otherwise be available to you under applicable patent law.
+
+ 12. No Surrender of Others' Freedom.
+
+ If conditions are imposed on you (whether by court order,
+ agreement or otherwise) that contradict the conditions of this
+ License, they do not excuse you from the conditions of this
+ License. If you cannot convey a covered work so as to satisfy
+ simultaneously your obligations under this License and any other
+ pertinent obligations, then as a consequence you may not convey it
+ at all. For example, if you agree to terms that obligate you to
+ collect a royalty for further conveying from those to whom you
+ convey the Program, the only way you could satisfy both those
+ terms and this License would be to refrain entirely from conveying
+ the Program.
+
+ 13. Use with the GNU Affero General Public License.
+
+ Notwithstanding any other provision of this License, you have
+ permission to link or combine any covered work with a work licensed
+ under version 3 of the GNU Affero General Public License into a
+ single combined work, and to convey the resulting work. The terms
+ of this License will continue to apply to the part which is the
+ covered work, but the special requirements of the GNU Affero
+ General Public License, section 13, concerning interaction through
+ a network will apply to the combination as such.
+
+ 14. Revised Versions of this License.
+
+ The Free Software Foundation may publish revised and/or new
+ versions of the GNU General Public License from time to time.
+ Such new versions will be similar in spirit to the present
+ version, but may differ in detail to address new problems or
+ concerns.
+
+ Each version is given a distinguishing version number. If the
+ Program specifies that a certain numbered version of the GNU
+ General Public License "or any later version" applies to it, you
+ have the option of following the terms and conditions either of
+ that numbered version or of any later version published by the
+ Free Software Foundation. If the Program does not specify a
+ version number of the GNU General Public License, you may choose
+ any version ever published by the Free Software Foundation.
+
+ If the Program specifies that a proxy can decide which future
+ versions of the GNU General Public License can be used, that
+ proxy's public statement of acceptance of a version permanently
+ authorizes you to choose that version for the Program.
+
+ Later license versions may give you additional or different
+ permissions. However, no additional obligations are imposed on any
+ author or copyright holder as a result of your choosing to follow a
+ later version.
+
+ 15. Disclaimer of Warranty.
+
+ THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+ APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE
+ COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS"
+ WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
+ INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE
+ RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.
+ SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
+ NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+ 16. Limitation of Liability.
+
+ IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
+ WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES
+ AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU
+ FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
+ CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE
+ THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA
+ BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+ PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+ PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF
+ THE POSSIBILITY OF SUCH DAMAGES.
+
+ 17. Interpretation of Sections 15 and 16.
+
+ If the disclaimer of warranty and limitation of liability provided
+ above cannot be given local legal effect according to their terms,
+ reviewing courts shall apply local law that most closely
+ approximates an absolute waiver of all civil liability in
+ connection with the Program, unless a warranty or assumption of
+ liability accompanies a copy of the Program in return for a fee.
+
+
+END OF TERMS AND CONDITIONS
+===========================
+
+How to Apply These Terms to Your New Programs
+=============================================
+
+If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these
+terms.
+
+ To do so, attach the following notices to the program. It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least the
+"copyright" line and a pointer to where the full notice is found.
+
+ ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
+ Copyright (C) YEAR NAME OF AUTHOR
+
+ This program is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 3 of the License, or (at
+ your option) any later version.
+
+ This program is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see `http://www.gnu.org/licenses/'.
+
+ Also add information on how to contact you by electronic and paper
+mail.
+
+ If the program does terminal interaction, make it output a short
+notice like this when it starts in an interactive mode:
+
+ PROGRAM Copyright (C) YEAR NAME OF AUTHOR
+ This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+ This is free software, and you are welcome to redistribute it
+ under certain conditions; type `show c' for details.
+
+ The hypothetical commands `show w' and `show c' should show the
+appropriate parts of the General Public License. Of course, your
+program's commands might be different; for a GUI interface, you would
+use an "about box".
+
+ You should also get your employer (if you work as a programmer) or
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary. For more information on this, and how to apply and follow
+the GNU GPL, see `http://www.gnu.org/licenses/'.
+
+ The GNU General Public License does not permit incorporating your
+program into proprietary programs. If your program is a subroutine
+library, you may consider it more useful to permit linking proprietary
+applications with the library. If this is what you want to do, use the
+GNU Lesser General Public License instead of this License. But first,
+please read `http://www.gnu.org/philosophy/why-not-lgpl.html'.
+
+\1f
+File: gccint.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top
+
+GNU Free Documentation License
+******************************
+
+ Version 1.2, November 2002
+
+ Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
+ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
+
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+ 0. PREAMBLE
+
+ The purpose of this License is to make a manual, textbook, or other
+ functional and useful document "free" in the sense of freedom: to
+ assure everyone the effective freedom to copy and redistribute it,
+ with or without modifying it, either commercially or
+ noncommercially. Secondarily, this License preserves for the
+ author and publisher a way to get credit for their work, while not
+ being considered responsible for modifications made by others.
+
+ This License is a kind of "copyleft", which means that derivative
+ works of the document must themselves be free in the same sense.
+ It complements the GNU General Public License, which is a copyleft
+ license designed for free software.
+
+ We have designed this License in order to use it for manuals for
+ free software, because free software needs free documentation: a
+ free program should come with manuals providing the same freedoms
+ that the software does. But this License is not limited to
+ software manuals; it can be used for any textual work, regardless
+ of subject matter or whether it is published as a printed book.
+ We recommend this License principally for works whose purpose is
+ instruction or reference.
+
+ 1. APPLICABILITY AND DEFINITIONS
+
+ This License applies to any manual or other work, in any medium,
+ that contains a notice placed by the copyright holder saying it
+ can be distributed under the terms of this License. Such a notice
+ grants a world-wide, royalty-free license, unlimited in duration,
+ to use that work under the conditions stated herein. The
+ "Document", below, refers to any such manual or work. Any member
+ of the public is a licensee, and is addressed as "you". You
+ accept the license if you copy, modify or distribute the work in a
+ way requiring permission under copyright law.
+
+ A "Modified Version" of the Document means any work containing the
+ Document or a portion of it, either copied verbatim, or with
+ modifications and/or translated into another language.
+
+ A "Secondary Section" is a named appendix or a front-matter section
+ of the Document that deals exclusively with the relationship of the
+ publishers or authors of the Document to the Document's overall
+ subject (or to related matters) and contains nothing that could
+ fall directly within that overall subject. (Thus, if the Document
+ is in part a textbook of mathematics, a Secondary Section may not
+ explain any mathematics.) The relationship could be a matter of
+ historical connection with the subject or with related matters, or
+ of legal, commercial, philosophical, ethical or political position
+ regarding them.
+
+ The "Invariant Sections" are certain Secondary Sections whose
+ titles are designated, as being those of Invariant Sections, in
+ the notice that says that the Document is released under this
+ License. If a section does not fit the above definition of
+ Secondary then it is not allowed to be designated as Invariant.
+ The Document may contain zero Invariant Sections. If the Document
+ does not identify any Invariant Sections then there are none.
+
+ The "Cover Texts" are certain short passages of text that are
+ listed, as Front-Cover Texts or Back-Cover Texts, in the notice
+ that says that the Document is released under this License. A
+ Front-Cover Text may be at most 5 words, and a Back-Cover Text may
+ be at most 25 words.
+
+ A "Transparent" copy of the Document means a machine-readable copy,
+ represented in a format whose specification is available to the
+ general public, that is suitable for revising the document
+ straightforwardly with generic text editors or (for images
+ composed of pixels) generic paint programs or (for drawings) some
+ widely available drawing editor, and that is suitable for input to
+ text formatters or for automatic translation to a variety of
+ formats suitable for input to text formatters. A copy made in an
+ otherwise Transparent file format whose markup, or absence of
+ markup, has been arranged to thwart or discourage subsequent
+ modification by readers is not Transparent. An image format is
+ not Transparent if used for any substantial amount of text. A
+ copy that is not "Transparent" is called "Opaque".
+
+ Examples of suitable formats for Transparent copies include plain
+ ASCII without markup, Texinfo input format, LaTeX input format,
+ SGML or XML using a publicly available DTD, and
+ standard-conforming simple HTML, PostScript or PDF designed for
+ human modification. Examples of transparent image formats include
+ PNG, XCF and JPG. Opaque formats include proprietary formats that
+ can be read and edited only by proprietary word processors, SGML or
+ XML for which the DTD and/or processing tools are not generally
+ available, and the machine-generated HTML, PostScript or PDF
+ produced by some word processors for output purposes only.
+
+ The "Title Page" means, for a printed book, the title page itself,
+ plus such following pages as are needed to hold, legibly, the
+ material this License requires to appear in the title page. For
+ works in formats which do not have any title page as such, "Title
+ Page" means the text near the most prominent appearance of the
+ work's title, preceding the beginning of the body of the text.
+
+ A section "Entitled XYZ" means a named subunit of the Document
+ whose title either is precisely XYZ or contains XYZ in parentheses
+ following text that translates XYZ in another language. (Here XYZ
+ stands for a specific section name mentioned below, such as
+ "Acknowledgements", "Dedications", "Endorsements", or "History".)
+ To "Preserve the Title" of such a section when you modify the
+ Document means that it remains a section "Entitled XYZ" according
+ to this definition.
+
+ The Document may include Warranty Disclaimers next to the notice
+ which states that this License applies to the Document. These
+ Warranty Disclaimers are considered to be included by reference in
+ this License, but only as regards disclaiming warranties: any other
+ implication that these Warranty Disclaimers may have is void and
+ has no effect on the meaning of this License.
+
+ 2. VERBATIM COPYING
+
+ You may copy and distribute the Document in any medium, either
+ commercially or noncommercially, provided that this License, the
+ copyright notices, and the license notice saying this License
+ applies to the Document are reproduced in all copies, and that you
+ add no other conditions whatsoever to those of this License. You
+ may not use technical measures to obstruct or control the reading
+ or further copying of the copies you make or distribute. However,
+ you may accept compensation in exchange for copies. If you
+ distribute a large enough number of copies you must also follow
+ the conditions in section 3.
+
+ You may also lend copies, under the same conditions stated above,
+ and you may publicly display copies.
+
+ 3. COPYING IN QUANTITY
+
+ If you publish printed copies (or copies in media that commonly
+ have printed covers) of the Document, numbering more than 100, and
+ the Document's license notice requires Cover Texts, you must
+ enclose the copies in covers that carry, clearly and legibly, all
+ these Cover Texts: Front-Cover Texts on the front cover, and
+ Back-Cover Texts on the back cover. Both covers must also clearly
+ and legibly identify you as the publisher of these copies. The
+ front cover must present the full title with all words of the
+ title equally prominent and visible. You may add other material
+ on the covers in addition. Copying with changes limited to the
+ covers, as long as they preserve the title of the Document and
+ satisfy these conditions, can be treated as verbatim copying in
+ other respects.
+
+ If the required texts for either cover are too voluminous to fit
+ legibly, you should put the first ones listed (as many as fit
+ reasonably) on the actual cover, and continue the rest onto
+ adjacent pages.
+
+ If you publish or distribute Opaque copies of the Document
+ numbering more than 100, you must either include a
+ machine-readable Transparent copy along with each Opaque copy, or
+ state in or with each Opaque copy a computer-network location from
+ which the general network-using public has access to download
+ using public-standard network protocols a complete Transparent
+ copy of the Document, free of added material. If you use the
+ latter option, you must take reasonably prudent steps, when you
+ begin distribution of Opaque copies in quantity, to ensure that
+ this Transparent copy will remain thus accessible at the stated
+ location until at least one year after the last time you
+ distribute an Opaque copy (directly or through your agents or
+ retailers) of that edition to the public.
+
+ It is requested, but not required, that you contact the authors of
+ the Document well before redistributing any large number of
+ copies, to give them a chance to provide you with an updated
+ version of the Document.
+
+ 4. MODIFICATIONS
+
+ You may copy and distribute a Modified Version of the Document
+ under the conditions of sections 2 and 3 above, provided that you
+ release the Modified Version under precisely this License, with
+ the Modified Version filling the role of the Document, thus
+ licensing distribution and modification of the Modified Version to
+ whoever possesses a copy of it. In addition, you must do these
+ things in the Modified Version:
+
+ A. Use in the Title Page (and on the covers, if any) a title
+ distinct from that of the Document, and from those of
+ previous versions (which should, if there were any, be listed
+ in the History section of the Document). You may use the
+ same title as a previous version if the original publisher of
+ that version gives permission.
+
+ B. List on the Title Page, as authors, one or more persons or
+ entities responsible for authorship of the modifications in
+ the Modified Version, together with at least five of the
+ principal authors of the Document (all of its principal
+ authors, if it has fewer than five), unless they release you
+ from this requirement.
+
+ C. State on the Title page the name of the publisher of the
+ Modified Version, as the publisher.
+
+ D. Preserve all the copyright notices of the Document.
+
+ E. Add an appropriate copyright notice for your modifications
+ adjacent to the other copyright notices.
+
+ F. Include, immediately after the copyright notices, a license
+ notice giving the public permission to use the Modified
+ Version under the terms of this License, in the form shown in
+ the Addendum below.
+
+ G. Preserve in that license notice the full lists of Invariant
+ Sections and required Cover Texts given in the Document's
+ license notice.
+
+ H. Include an unaltered copy of this License.
+
+ I. Preserve the section Entitled "History", Preserve its Title,
+ and add to it an item stating at least the title, year, new
+ authors, and publisher of the Modified Version as given on
+ the Title Page. If there is no section Entitled "History" in
+ the Document, create one stating the title, year, authors,
+ and publisher of the Document as given on its Title Page,
+ then add an item describing the Modified Version as stated in
+ the previous sentence.
+
+ J. Preserve the network location, if any, given in the Document
+ for public access to a Transparent copy of the Document, and
+ likewise the network locations given in the Document for
+ previous versions it was based on. These may be placed in
+ the "History" section. You may omit a network location for a
+ work that was published at least four years before the
+ Document itself, or if the original publisher of the version
+ it refers to gives permission.
+
+ K. For any section Entitled "Acknowledgements" or "Dedications",
+ Preserve the Title of the section, and preserve in the
+ section all the substance and tone of each of the contributor
+ acknowledgements and/or dedications given therein.
+
+ L. Preserve all the Invariant Sections of the Document,
+ unaltered in their text and in their titles. Section numbers
+ or the equivalent are not considered part of the section
+ titles.
+
+ M. Delete any section Entitled "Endorsements". Such a section
+ may not be included in the Modified Version.
+
+ N. Do not retitle any existing section to be Entitled
+ "Endorsements" or to conflict in title with any Invariant
+ Section.
+
+ O. Preserve any Warranty Disclaimers.
+
+ If the Modified Version includes new front-matter sections or
+ appendices that qualify as Secondary Sections and contain no
+ material copied from the Document, you may at your option
+ designate some or all of these sections as invariant. To do this,
+ add their titles to the list of Invariant Sections in the Modified
+ Version's license notice. These titles must be distinct from any
+ other section titles.
+
+ You may add a section Entitled "Endorsements", provided it contains
+ nothing but endorsements of your Modified Version by various
+ parties--for example, statements of peer review or that the text
+ has been approved by an organization as the authoritative
+ definition of a standard.
+
+ You may add a passage of up to five words as a Front-Cover Text,
+ and a passage of up to 25 words as a Back-Cover Text, to the end
+ of the list of Cover Texts in the Modified Version. Only one
+ passage of Front-Cover Text and one of Back-Cover Text may be
+ added by (or through arrangements made by) any one entity. If the
+ Document already includes a cover text for the same cover,
+ previously added by you or by arrangement made by the same entity
+ you are acting on behalf of, you may not add another; but you may
+ replace the old one, on explicit permission from the previous
+ publisher that added the old one.
+
+ The author(s) and publisher(s) of the Document do not by this
+ License give permission to use their names for publicity for or to
+ assert or imply endorsement of any Modified Version.
+
+ 5. COMBINING DOCUMENTS
+
+ You may combine the Document with other documents released under
+ this License, under the terms defined in section 4 above for
+ modified versions, provided that you include in the combination
+ all of the Invariant Sections of all of the original documents,
+ unmodified, and list them all as Invariant Sections of your
+ combined work in its license notice, and that you preserve all
+ their Warranty Disclaimers.
+
+ The combined work need only contain one copy of this License, and
+ multiple identical Invariant Sections may be replaced with a single
+ copy. If there are multiple Invariant Sections with the same name
+ but different contents, make the title of each such section unique
+ by adding at the end of it, in parentheses, the name of the
+ original author or publisher of that section if known, or else a
+ unique number. Make the same adjustment to the section titles in
+ the list of Invariant Sections in the license notice of the
+ combined work.
+
+ In the combination, you must combine any sections Entitled
+ "History" in the various original documents, forming one section
+ Entitled "History"; likewise combine any sections Entitled
+ "Acknowledgements", and any sections Entitled "Dedications". You
+ must delete all sections Entitled "Endorsements."
+
+ 6. COLLECTIONS OF DOCUMENTS
+
+ You may make a collection consisting of the Document and other
+ documents released under this License, and replace the individual
+ copies of this License in the various documents with a single copy
+ that is included in the collection, provided that you follow the
+ rules of this License for verbatim copying of each of the
+ documents in all other respects.
+
+ You may extract a single document from such a collection, and
+ distribute it individually under this License, provided you insert
+ a copy of this License into the extracted document, and follow
+ this License in all other respects regarding verbatim copying of
+ that document.
+
+ 7. AGGREGATION WITH INDEPENDENT WORKS
+
+ A compilation of the Document or its derivatives with other
+ separate and independent documents or works, in or on a volume of
+ a storage or distribution medium, is called an "aggregate" if the
+ copyright resulting from the compilation is not used to limit the
+ legal rights of the compilation's users beyond what the individual
+ works permit. When the Document is included in an aggregate, this
+ License does not apply to the other works in the aggregate which
+ are not themselves derivative works of the Document.
+
+ If the Cover Text requirement of section 3 is applicable to these
+ copies of the Document, then if the Document is less than one half
+ of the entire aggregate, the Document's Cover Texts may be placed
+ on covers that bracket the Document within the aggregate, or the
+ electronic equivalent of covers if the Document is in electronic
+ form. Otherwise they must appear on printed covers that bracket
+ the whole aggregate.
+
+ 8. TRANSLATION
+
+ Translation is considered a kind of modification, so you may
+ distribute translations of the Document under the terms of section
+ 4. Replacing Invariant Sections with translations requires special
+ permission from their copyright holders, but you may include
+ translations of some or all Invariant Sections in addition to the
+ original versions of these Invariant Sections. You may include a
+ translation of this License, and all the license notices in the
+ Document, and any Warranty Disclaimers, provided that you also
+ include the original English version of this License and the
+ original versions of those notices and disclaimers. In case of a
+ disagreement between the translation and the original version of
+ this License or a notice or disclaimer, the original version will
+ prevail.
+
+ If a section in the Document is Entitled "Acknowledgements",
+ "Dedications", or "History", the requirement (section 4) to
+ Preserve its Title (section 1) will typically require changing the
+ actual title.
+
+ 9. TERMINATION
+
+ You may not copy, modify, sublicense, or distribute the Document
+ except as expressly provided for under this License. Any other
+ attempt to copy, modify, sublicense or distribute the Document is
+ void, and will automatically terminate your rights under this
+ License. However, parties who have received copies, or rights,
+ from you under this License will not have their licenses
+ terminated so long as such parties remain in full compliance.
+
+ 10. FUTURE REVISIONS OF THIS LICENSE
+
+ The Free Software Foundation may publish new, revised versions of
+ the GNU Free Documentation License from time to time. Such new
+ versions will be similar in spirit to the present version, but may
+ differ in detail to address new problems or concerns. See
+ `http://www.gnu.org/copyleft/'.
+
+ Each version of the License is given a distinguishing version
+ number. If the Document specifies that a particular numbered
+ version of this License "or any later version" applies to it, you
+ have the option of following the terms and conditions either of
+ that specified version or of any later version that has been
+ published (not as a draft) by the Free Software Foundation. If
+ the Document does not specify a version number of this License,
+ you may choose any version ever published (not as a draft) by the
+ Free Software Foundation.
+
+ADDENDUM: How to use this License for your documents
+====================================================
+
+To use this License in a document you have written, include a copy of
+the License in the document and put the following copyright and license
+notices just after the title page:
+
+ Copyright (C) YEAR YOUR NAME.
+ 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 no Invariant Sections, no Front-Cover Texts, and no Back-Cover
+ Texts. A copy of the license is included in the section entitled ``GNU
+ Free Documentation License''.
+
+ If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
+replace the "with...Texts." line with this:
+
+ with the Invariant Sections being LIST THEIR TITLES, with
+ the Front-Cover Texts being LIST, and with the Back-Cover Texts
+ being LIST.
+
+ If you have Invariant Sections without Cover Texts, or some other
+combination of the three, merge those two alternatives to suit the
+situation.
+
+ If your document contains nontrivial examples of program code, we
+recommend releasing these examples in parallel under your choice of
+free software license, such as the GNU General Public License, to
+permit their use in free software.
+
+\1f
+File: gccint.info, Node: Contributors, Next: Option Index, Prev: GNU Free Documentation License, Up: Top
+
+Contributors to GCC
+*******************
+
+The GCC project would like to thank its many contributors. Without
+them the project would not have been nearly as successful as it has
+been. Any omissions in this list are accidental. Feel free to contact
+<law@redhat.com> or <gerald@pfeifer.com> if you have been left out or
+some of your contributions are not listed. Please keep this list in
+alphabetical order.
+
+ * Analog Devices helped implement the support for complex data types
+ and iterators.
+
+ * John David Anglin for threading-related fixes and improvements to
+ libstdc++-v3, and the HP-UX port.
+
+ * James van Artsdalen wrote the code that makes efficient use of the
+ Intel 80387 register stack.
+
+ * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta
+ Series port.
+
+ * Alasdair Baird for various bug fixes.
+
+ * Giovanni Bajo for analyzing lots of complicated C++ problem
+ reports.
+
+ * Peter Barada for his work to improve code generation for new
+ ColdFire cores.
+
+ * Gerald Baumgartner added the signature extension to the C++ front
+ end.
+
+ * Godmar Back for his Java improvements and encouragement.
+
+ * Scott Bambrough for help porting the Java compiler.
+
+ * Wolfgang Bangerth for processing tons of bug reports.
+
+ * Jon Beniston for his Microsoft Windows port of Java.
+
+ * Daniel Berlin for better DWARF2 support, faster/better
+ optimizations, improved alias analysis, plus migrating GCC to
+ Bugzilla.
+
+ * Geoff Berry for his Java object serialization work and various
+ patches.
+
+ * Uros Bizjak for the implementation of x87 math built-in functions
+ and for various middle end and i386 back end improvements and bug
+ fixes.
+
+ * Eric Blake for helping to make GCJ and libgcj conform to the
+ specifications.
+
+ * Janne Blomqvist for contributions to GNU Fortran.
+
+ * Segher Boessenkool for various fixes.
+
+ * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and
+ other Java work.
+
+ * Neil Booth for work on cpplib, lang hooks, debug hooks and other
+ miscellaneous clean-ups.
+
+ * Steven Bosscher for integrating the GNU Fortran front end into GCC
+ and for contributing to the tree-ssa branch.
+
+ * Eric Botcazou for fixing middle- and backend bugs left and right.
+
+ * Per Bothner for his direction via the steering committee and
+ various improvements to the infrastructure for supporting new
+ languages. Chill front end implementation. Initial
+ implementations of cpplib, fix-header, config.guess, libio, and
+ past C++ library (libg++) maintainer. Dreaming up, designing and
+ implementing much of GCJ.
+
+ * Devon Bowen helped port GCC to the Tahoe.
+
+ * Don Bowman for mips-vxworks contributions.
+
+ * Dave Brolley for work on cpplib and Chill.
+
+ * Paul Brook for work on the ARM architecture and maintaining GNU
+ Fortran.
+
+ * Robert Brown implemented the support for Encore 32000 systems.
+
+ * Christian Bruel for improvements to local store elimination.
+
+ * Herman A.J. ten Brugge for various fixes.
+
+ * Joerg Brunsmann for Java compiler hacking and help with the GCJ
+ FAQ.
+
+ * Joe Buck for his direction via the steering committee.
+
+ * Craig Burley for leadership of the G77 Fortran effort.
+
+ * Stephan Buys for contributing Doxygen notes for libstdc++.
+
+ * Paolo Carlini for libstdc++ work: lots of efficiency improvements
+ to the C++ strings, streambufs and formatted I/O, hard detective
+ work on the frustrating localization issues, and keeping up with
+ the problem reports.
+
+ * John Carr for his alias work, SPARC hacking, infrastructure
+ improvements, previous contributions to the steering committee,
+ loop optimizations, etc.
+
+ * Stephane Carrez for 68HC11 and 68HC12 ports.
+
+ * Steve Chamberlain for support for the Renesas SH and H8 processors
+ and the PicoJava processor, and for GCJ config fixes.
+
+ * Glenn Chambers for help with the GCJ FAQ.
+
+ * John-Marc Chandonia for various libgcj patches.
+
+ * Scott Christley for his Objective-C contributions.
+
+ * Eric Christopher for his Java porting help and clean-ups.
+
+ * Branko Cibej for more warning contributions.
+
+ * The GNU Classpath project for all of their merged runtime code.
+
+ * Nick Clifton for arm, mcore, fr30, v850, m32r work, `--help', and
+ other random hacking.
+
+ * Michael Cook for libstdc++ cleanup patches to reduce warnings.
+
+ * R. Kelley Cook for making GCC buildable from a read-only directory
+ as well as other miscellaneous build process and documentation
+ clean-ups.
+
+ * Ralf Corsepius for SH testing and minor bug fixing.
+
+ * Stan Cox for care and feeding of the x86 port and lots of behind
+ the scenes hacking.
+
+ * Alex Crain provided changes for the 3b1.
+
+ * Ian Dall for major improvements to the NS32k port.
+
+ * Paul Dale for his work to add uClinux platform support to the m68k
+ backend.
+
+ * Dario Dariol contributed the four varieties of sample programs
+ that print a copy of their source.
+
+ * Russell Davidson for fstream and stringstream fixes in libstdc++.
+
+ * Bud Davis for work on the G77 and GNU Fortran compilers.
+
+ * Mo DeJong for GCJ and libgcj bug fixes.
+
+ * DJ Delorie for the DJGPP port, build and libiberty maintenance,
+ various bug fixes, and the M32C port.
+
+ * Arnaud Desitter for helping to debug GNU Fortran.
+
+ * Gabriel Dos Reis for contributions to G++, contributions and
+ maintenance of GCC diagnostics infrastructure, libstdc++-v3,
+ including `valarray<>', `complex<>', maintaining the numerics
+ library (including that pesky `<limits>' :-) and keeping
+ up-to-date anything to do with numbers.
+
+ * Ulrich Drepper for his work on glibc, testing of GCC using glibc,
+ ISO C99 support, CFG dumping support, etc., plus support of the
+ C++ runtime libraries including for all kinds of C interface
+ issues, contributing and maintaining `complex<>', sanity checking
+ and disbursement, configuration architecture, libio maintenance,
+ and early math work.
+
+ * Zdenek Dvorak for a new loop unroller and various fixes.
+
+ * Richard Earnshaw for his ongoing work with the ARM.
+
+ * David Edelsohn for his direction via the steering committee,
+ ongoing work with the RS6000/PowerPC port, help cleaning up Haifa
+ loop changes, doing the entire AIX port of libstdc++ with his bare
+ hands, and for ensuring GCC properly keeps working on AIX.
+
+ * Kevin Ediger for the floating point formatting of num_put::do_put
+ in libstdc++.
+
+ * Phil Edwards for libstdc++ work including configuration hackery,
+ documentation maintainer, chief breaker of the web pages, the
+ occasional iostream bug fix, and work on shared library symbol
+ versioning.
+
+ * Paul Eggert for random hacking all over GCC.
+
+ * Mark Elbrecht for various DJGPP improvements, and for libstdc++
+ configuration support for locales and fstream-related fixes.
+
+ * Vadim Egorov for libstdc++ fixes in strings, streambufs, and
+ iostreams.
+
+ * Christian Ehrhardt for dealing with bug reports.
+
+ * Ben Elliston for his work to move the Objective-C runtime into its
+ own subdirectory and for his work on autoconf.
+
+ * Revital Eres for work on the PowerPC 750CL port.
+
+ * Marc Espie for OpenBSD support.
+
+ * Doug Evans for much of the global optimization framework, arc,
+ m32r, and SPARC work.
+
+ * Christopher Faylor for his work on the Cygwin port and for caring
+ and feeding the gcc.gnu.org box and saving its users tons of spam.
+
+ * Fred Fish for BeOS support and Ada fixes.
+
+ * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ.
+
+ * Peter Gerwinski for various bug fixes and the Pascal front end.
+
+ * Kaveh R. Ghazi for his direction via the steering committee,
+ amazing work to make `-W -Wall -W* -Werror' useful, and
+ continuously testing GCC on a plethora of platforms. Kaveh
+ extends his gratitude to the CAIP Center at Rutgers University for
+ providing him with computing resources to work on Free Software
+ since the late 1980s.
+
+ * John Gilmore for a donation to the FSF earmarked improving GNU
+ Java.
+
+ * Judy Goldberg for c++ contributions.
+
+ * Torbjorn Granlund for various fixes and the c-torture testsuite,
+ multiply- and divide-by-constant optimization, improved long long
+ support, improved leaf function register allocation, and his
+ direction via the steering committee.
+
+ * Anthony Green for his `-Os' contributions and Java front end work.
+
+ * Stu Grossman for gdb hacking, allowing GCJ developers to debug
+ Java code.
+
+ * Michael K. Gschwind contributed the port to the PDP-11.
+
+ * Ron Guilmette implemented the `protoize' and `unprotoize' tools,
+ the support for Dwarf symbolic debugging information, and much of
+ the support for System V Release 4. He has also worked heavily on
+ the Intel 386 and 860 support.
+
+ * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload
+ GCSE.
+
+ * Bruno Haible for improvements in the runtime overhead for EH, new
+ warnings and assorted bug fixes.
+
+ * Andrew Haley for his amazing Java compiler and library efforts.
+
+ * Chris Hanson assisted in making GCC work on HP-UX for the 9000
+ series 300.
+
+ * Michael Hayes for various thankless work he's done trying to get
+ the c30/c40 ports functional. Lots of loop and unroll
+ improvements and fixes.
+
+ * Dara Hazeghi for wading through myriads of target-specific bug
+ reports.
+
+ * Kate Hedstrom for staking the G77 folks with an initial testsuite.
+
+ * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64
+ work, loop opts, and generally fixing lots of old problems we've
+ ignored for years, flow rewrite and lots of further stuff,
+ including reviewing tons of patches.
+
+ * Aldy Hernandez for working on the PowerPC port, SIMD support, and
+ various fixes.
+
+ * Nobuyuki Hikichi of Software Research Associates, Tokyo,
+ contributed the support for the Sony NEWS machine.
+
+ * Kazu Hirata for caring and feeding the Renesas H8/300 port and
+ various fixes.
+
+ * Katherine Holcomb for work on GNU Fortran.
+
+ * Manfred Hollstein for his ongoing work to keep the m88k alive, lots
+ of testing and bug fixing, particularly of GCC configury code.
+
+ * Steve Holmgren for MachTen patches.
+
+ * Jan Hubicka for his x86 port improvements.
+
+ * Falk Hueffner for working on C and optimization bug reports.
+
+ * Bernardo Innocenti for his m68k work, including merging of
+ ColdFire improvements and uClinux support.
+
+ * Christian Iseli for various bug fixes.
+
+ * Kamil Iskra for general m68k hacking.
+
+ * Lee Iverson for random fixes and MIPS testing.
+
+ * Andreas Jaeger for testing and benchmarking of GCC and various bug
+ fixes.
+
+ * Jakub Jelinek for his SPARC work and sibling call optimizations as
+ well as lots of bug fixes and test cases, and for improving the
+ Java build system.
+
+ * Janis Johnson for ia64 testing and fixes, her quality improvement
+ sidetracks, and web page maintenance.
+
+ * Kean Johnston for SCO OpenServer support and various fixes.
+
+ * Tim Josling for the sample language treelang based originally on
+ Richard Kenner's "toy" language.
+
+ * Nicolai Josuttis for additional libstdc++ documentation.
+
+ * Klaus Kaempf for his ongoing work to make alpha-vms a viable
+ target.
+
+ * Steven G. Kargl for work on GNU Fortran.
+
+ * David Kashtan of SRI adapted GCC to VMS.
+
+ * Ryszard Kabatek for many, many libstdc++ bug fixes and
+ optimizations of strings, especially member functions, and for
+ auto_ptr fixes.
+
+ * Geoffrey Keating for his ongoing work to make the PPC work for
+ GNU/Linux and his automatic regression tester.
+
+ * Brendan Kehoe for his ongoing work with G++ and for a lot of early
+ work in just about every part of libstdc++.
+
+ * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the
+ MIL-STD-1750A.
+
+ * Richard Kenner of the New York University Ultracomputer Research
+ Laboratory wrote the machine descriptions for the AMD 29000, the
+ DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the
+ support for instruction attributes. He also made changes to
+ better support RISC processors including changes to common
+ subexpression elimination, strength reduction, function calling
+ sequence handling, and condition code support, in addition to
+ generalizing the code for frame pointer elimination and delay slot
+ scheduling. Richard Kenner was also the head maintainer of GCC
+ for several years.
+
+ * Mumit Khan for various contributions to the Cygwin and Mingw32
+ ports and maintaining binary releases for Microsoft Windows hosts,
+ and for massive libstdc++ porting work to Cygwin/Mingw32.
+
+ * Robin Kirkham for cpu32 support.
+
+ * Mark Klein for PA improvements.
+
+ * Thomas Koenig for various bug fixes.
+
+ * Bruce Korb for the new and improved fixincludes code.
+
+ * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3
+ effort.
+
+ * Charles LaBrec contributed the support for the Integrated Solutions
+ 68020 system.
+
+ * Asher Langton and Mike Kumbera for contributing Cray pointer
+ support to GNU Fortran, and for other GNU Fortran improvements.
+
+ * Jeff Law for his direction via the steering committee,
+ coordinating the entire egcs project and GCC 2.95, rolling out
+ snapshots and releases, handling merges from GCC2, reviewing tons
+ of patches that might have fallen through the cracks else, and
+ random but extensive hacking.
+
+ * Marc Lehmann for his direction via the steering committee and
+ helping with analysis and improvements of x86 performance.
+
+ * Victor Leikehman for work on GNU Fortran.
+
+ * Ted Lemon wrote parts of the RTL reader and printer.
+
+ * Kriang Lerdsuwanakij for C++ improvements including template as
+ template parameter support, and many C++ fixes.
+
+ * Warren Levy for tremendous work on libgcj (Java Runtime Library)
+ and random work on the Java front end.
+
+ * Alain Lichnewsky ported GCC to the MIPS CPU.
+
+ * Oskar Liljeblad for hacking on AWT and his many Java bug reports
+ and patches.
+
+ * Robert Lipe for OpenServer support, new testsuites, testing, etc.
+
+ * Chen Liqin for various S+core related fixes/improvement, and for
+ maintaining the S+core port.
+
+ * Weiwen Liu for testing and various bug fixes.
+
+ * Manuel Lo'pez-Iba'n~ez for improving `-Wconversion' and many other
+ diagnostics fixes and improvements.
+
+ * Dave Love for his ongoing work with the Fortran front end and
+ runtime libraries.
+
+ * Martin von Lo"wis for internal consistency checking infrastructure,
+ various C++ improvements including namespace support, and tons of
+ assistance with libstdc++/compiler merges.
+
+ * H.J. Lu for his previous contributions to the steering committee,
+ many x86 bug reports, prototype patches, and keeping the GNU/Linux
+ ports working.
+
+ * Greg McGary for random fixes and (someday) bounded pointers.
+
+ * Andrew MacLeod for his ongoing work in building a real EH system,
+ various code generation improvements, work on the global
+ optimizer, etc.
+
+ * Vladimir Makarov for hacking some ugly i960 problems, PowerPC
+ hacking improvements to compile-time performance, overall
+ knowledge and direction in the area of instruction scheduling, and
+ design and implementation of the automaton based instruction
+ scheduler.
+
+ * Bob Manson for his behind the scenes work on dejagnu.
+
+ * Philip Martin for lots of libstdc++ string and vector iterator
+ fixes and improvements, and string clean up and testsuites.
+
+ * All of the Mauve project contributors, for Java test code.
+
+ * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements.
+
+ * Adam Megacz for his work on the Microsoft Windows port of GCJ.
+
+ * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS,
+ powerpc, haifa, ECOFF debug support, and other assorted hacking.
+
+ * Jason Merrill for his direction via the steering committee and
+ leading the G++ effort.
+
+ * Martin Michlmayr for testing GCC on several architectures using the
+ entire Debian archive.
+
+ * David Miller for his direction via the steering committee, lots of
+ SPARC work, improvements in jump.c and interfacing with the Linux
+ kernel developers.
+
+ * Gary Miller ported GCC to Charles River Data Systems machines.
+
+ * Alfred Minarik for libstdc++ string and ios bug fixes, and turning
+ the entire libstdc++ testsuite namespace-compatible.
+
+ * Mark Mitchell for his direction via the steering committee,
+ mountains of C++ work, load/store hoisting out of loops, alias
+ analysis improvements, ISO C `restrict' support, and serving as
+ release manager for GCC 3.x.
+
+ * Alan Modra for various GNU/Linux bits and testing.
+
+ * Toon Moene for his direction via the steering committee, Fortran
+ maintenance, and his ongoing work to make us make Fortran run fast.
+
+ * Jason Molenda for major help in the care and feeding of all the
+ services on the gcc.gnu.org (formerly egcs.cygnus.com)
+ machine--mail, web services, ftp services, etc etc. Doing all
+ this work on scrap paper and the backs of envelopes would have
+ been... difficult.
+
+ * Catherine Moore for fixing various ugly problems we have sent her
+ way, including the haifa bug which was killing the Alpha & PowerPC
+ Linux kernels.
+
+ * Mike Moreton for his various Java patches.
+
+ * David Mosberger-Tang for various Alpha improvements, and for the
+ initial IA-64 port.
+
+ * Stephen Moshier contributed the floating point emulator that
+ assists in cross-compilation and permits support for floating
+ point numbers wider than 64 bits and for ISO C99 support.
+
+ * Bill Moyer for his behind the scenes work on various issues.
+
+ * Philippe De Muyter for his work on the m68k port.
+
+ * Joseph S. Myers for his work on the PDP-11 port, format checking
+ and ISO C99 support, and continuous emphasis on (and contributions
+ to) documentation.
+
+ * Nathan Myers for his work on libstdc++-v3: architecture and
+ authorship through the first three snapshots, including
+ implementation of locale infrastructure, string, shadow C headers,
+ and the initial project documentation (DESIGN, CHECKLIST, and so
+ forth). Later, more work on MT-safe string and shadow headers.
+
+ * Felix Natter for documentation on porting libstdc++.
+
+ * Nathanael Nerode for cleaning up the configuration/build process.
+
+ * NeXT, Inc. donated the front end that supports the Objective-C
+ language.
+
+ * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to
+ the search engine setup, various documentation fixes and other
+ small fixes.
+
+ * Geoff Noer for his work on getting cygwin native builds working.
+
+ * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance
+ tracking web pages, GIMPLE tuples, and assorted fixes.
+
+ * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64,
+ FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and
+ related infrastructure improvements.
+
+ * Alexandre Oliva for various build infrastructure improvements,
+ scripts and amazing testing work, including keeping libtool issues
+ sane and happy.
+
+ * Stefan Olsson for work on mt_alloc.
+
+ * Melissa O'Neill for various NeXT fixes.
+
+ * Rainer Orth for random MIPS work, including improvements to GCC's
+ o32 ABI support, improvements to dejagnu's MIPS support, Java
+ configuration clean-ups and porting work, etc.
+
+ * Hartmut Penner for work on the s390 port.
+
+ * Paul Petersen wrote the machine description for the Alliant FX/8.
+
+ * Alexandre Petit-Bianco for implementing much of the Java compiler
+ and continued Java maintainership.
+
+ * Matthias Pfaller for major improvements to the NS32k port.
+
+ * Gerald Pfeifer for his direction via the steering committee,
+ pointing out lots of problems we need to solve, maintenance of the
+ web pages, and taking care of documentation maintenance in general.
+
+ * Andrew Pinski for processing bug reports by the dozen.
+
+ * Ovidiu Predescu for his work on the Objective-C front end and
+ runtime libraries.
+
+ * Jerry Quinn for major performance improvements in C++ formatted
+ I/O.
+
+ * Ken Raeburn for various improvements to checker, MIPS ports and
+ various cleanups in the compiler.
+
+ * Rolf W. Rasmussen for hacking on AWT.
+
+ * David Reese of Sun Microsystems contributed to the Solaris on
+ PowerPC port.
+
+ * Volker Reichelt for keeping up with the problem reports.
+
+ * Joern Rennecke for maintaining the sh port, loop, regmove & reload
+ hacking.
+
+ * Loren J. Rittle for improvements to libstdc++-v3 including the
+ FreeBSD port, threading fixes, thread-related configury changes,
+ critical threading documentation, and solutions to really tricky
+ I/O problems, as well as keeping GCC properly working on FreeBSD
+ and continuous testing.
+
+ * Craig Rodrigues for processing tons of bug reports.
+
+ * Ola Ro"nnerup for work on mt_alloc.
+
+ * Gavin Romig-Koch for lots of behind the scenes MIPS work.
+
+ * David Ronis inspired and encouraged Craig to rewrite the G77
+ documentation in texinfo format by contributing a first pass at a
+ translation of the old `g77-0.5.16/f/DOC' file.
+
+ * Ken Rose for fixes to GCC's delay slot filling code.
+
+ * Paul Rubin wrote most of the preprocessor.
+
+ * Pe'tur Runo'lfsson for major performance improvements in C++
+ formatted I/O and large file support in C++ filebuf.
+
+ * Chip Salzenberg for libstdc++ patches and improvements to locales,
+ traits, Makefiles, libio, libtool hackery, and "long long" support.
+
+ * Juha Sarlin for improvements to the H8 code generator.
+
+ * Greg Satz assisted in making GCC work on HP-UX for the 9000 series
+ 300.
+
+ * Roger Sayle for improvements to constant folding and GCC's RTL
+ optimizers as well as for fixing numerous bugs.
+
+ * Bradley Schatz for his work on the GCJ FAQ.
+
+ * Peter Schauer wrote the code to allow debugging to work on the
+ Alpha.
+
+ * William Schelter did most of the work on the Intel 80386 support.
+
+ * Tobias Schlu"ter for work on GNU Fortran.
+
+ * Bernd Schmidt for various code generation improvements and major
+ work in the reload pass as well a serving as release manager for
+ GCC 2.95.3.
+
+ * Peter Schmid for constant testing of libstdc++--especially
+ application testing, going above and beyond what was requested for
+ the release criteria--and libstdc++ header file tweaks.
+
+ * Jason Schroeder for jcf-dump patches.
+
+ * Andreas Schwab for his work on the m68k port.
+
+ * Lars Segerlund for work on GNU Fortran.
+
+ * Joel Sherrill for his direction via the steering committee, RTEMS
+ contributions and RTEMS testing.
+
+ * Nathan Sidwell for many C++ fixes/improvements.
+
+ * Jeffrey Siegal for helping RMS with the original design of GCC,
+ some code which handles the parse tree and RTL data structures,
+ constant folding and help with the original VAX & m68k ports.
+
+ * Kenny Simpson for prompting libstdc++ fixes due to defect reports
+ from the LWG (thereby keeping GCC in line with updates from the
+ ISO).
+
+ * Franz Sirl for his ongoing work with making the PPC port stable
+ for GNU/Linux.
+
+ * Andrey Slepuhin for assorted AIX hacking.
+
+ * Trevor Smigiel for contributing the SPU port.
+
+ * Christopher Smith did the port for Convex machines.
+
+ * Danny Smith for his major efforts on the Mingw (and Cygwin) ports.
+
+ * Randy Smith finished the Sun FPA support.
+
+ * Scott Snyder for queue, iterator, istream, and string fixes and
+ libstdc++ testsuite entries. Also for providing the patch to G77
+ to add rudimentary support for `INTEGER*1', `INTEGER*2', and
+ `LOGICAL*1'.
+
+ * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique.
+
+ * Richard Stallman, for writing the original GCC and launching the
+ GNU project.
+
+ * Jan Stein of the Chalmers Computer Society provided support for
+ Genix, as well as part of the 32000 machine description.
+
+ * Nigel Stephens for various mips16 related fixes/improvements.
+
+ * Jonathan Stone wrote the machine description for the Pyramid
+ computer.
+
+ * Graham Stott for various infrastructure improvements.
+
+ * John Stracke for his Java HTTP protocol fixes.
+
+ * Mike Stump for his Elxsi port, G++ contributions over the years
+ and more recently his vxworks contributions
+
+ * Jeff Sturm for Java porting help, bug fixes, and encouragement.
+
+ * Shigeya Suzuki for this fixes for the bsdi platforms.
+
+ * Ian Lance Taylor for his mips16 work, general configury hacking,
+ fixincludes, etc.
+
+ * Holger Teutsch provided the support for the Clipper CPU.
+
+ * Gary Thomas for his ongoing work to make the PPC work for
+ GNU/Linux.
+
+ * Philipp Thomas for random bug fixes throughout the compiler
+
+ * Jason Thorpe for thread support in libstdc++ on NetBSD.
+
+ * Kresten Krab Thorup wrote the run time support for the Objective-C
+ language and the fantastic Java bytecode interpreter.
+
+ * Michael Tiemann for random bug fixes, the first instruction
+ scheduler, initial C++ support, function integration, NS32k, SPARC
+ and M88k machine description work, delay slot scheduling.
+
+ * Andreas Tobler for his work porting libgcj to Darwin.
+
+ * Teemu Torma for thread safe exception handling support.
+
+ * Leonard Tower wrote parts of the parser, RTL generator, and RTL
+ definitions, and of the VAX machine description.
+
+ * Daniel Towner and Hariharan Sandanagobalane contributed and
+ maintain the picoChip port.
+
+ * Tom Tromey for internationalization support and for his many Java
+ contributions and libgcj maintainership.
+
+ * Lassi Tuura for improvements to config.guess to determine HP
+ processor types.
+
+ * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes.
+
+ * Andy Vaught for the design and initial implementation of the GNU
+ Fortran front end.
+
+ * Brent Verner for work with the libstdc++ cshadow files and their
+ associated configure steps.
+
+ * Todd Vierling for contributions for NetBSD ports.
+
+ * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML
+ guidance.
+
+ * Dean Wakerley for converting the install documentation from HTML
+ to texinfo in time for GCC 3.0.
+
+ * Krister Walfridsson for random bug fixes.
+
+ * Feng Wang for contributions to GNU Fortran.
+
+ * Stephen M. Webb for time and effort on making libstdc++ shadow
+ files work with the tricky Solaris 8+ headers, and for pushing the
+ build-time header tree.
+
+ * John Wehle for various improvements for the x86 code generator,
+ related infrastructure improvements to help x86 code generation,
+ value range propagation and other work, WE32k port.
+
+ * Ulrich Weigand for work on the s390 port.
+
+ * Zack Weinberg for major work on cpplib and various other bug fixes.
+
+ * Matt Welsh for help with Linux Threads support in GCJ.
+
+ * Urban Widmark for help fixing java.io.
+
+ * Mark Wielaard for new Java library code and his work integrating
+ with Classpath.
+
+ * Dale Wiles helped port GCC to the Tahoe.
+
+ * Bob Wilson from Tensilica, Inc. for the Xtensa port.
+
+ * Jim Wilson for his direction via the steering committee, tackling
+ hard problems in various places that nobody else wanted to work
+ on, strength reduction and other loop optimizations.
+
+ * Paul Woegerer and Tal Agmon for the CRX port.
+
+ * Carlo Wood for various fixes.
+
+ * Tom Wood for work on the m88k port.
+
+ * Canqun Yang for work on GNU Fortran.
+
+ * Masanobu Yuhara of Fujitsu Laboratories implemented the machine
+ description for the Tron architecture (specifically, the Gmicro).
+
+ * Kevin Zachmann helped port GCC to the Tahoe.
+
+ * Ayal Zaks for Swing Modulo Scheduling (SMS).
+
+ * Xiaoqiang Zhang for work on GNU Fortran.
+
+ * Gilles Zunino for help porting Java to Irix.
+
+
+ The following people are recognized for their contributions to GNAT,
+the Ada front end of GCC:
+ * Bernard Banner
+
+ * Romain Berrendonner
+
+ * Geert Bosch
+
+ * Emmanuel Briot
+
+ * Joel Brobecker
+
+ * Ben Brosgol
+
+ * Vincent Celier
+
+ * Arnaud Charlet
+
+ * Chien Chieng
+
+ * Cyrille Comar
+
+ * Cyrille Crozes
+
+ * Robert Dewar
+
+ * Gary Dismukes
+
+ * Robert Duff
+
+ * Ed Falis
+
+ * Ramon Fernandez
+
+ * Sam Figueroa
+
+ * Vasiliy Fofanov
+
+ * Michael Friess
+
+ * Franco Gasperoni
+
+ * Ted Giering
+
+ * Matthew Gingell
+
+ * Laurent Guerby
+
+ * Jerome Guitton
+
+ * Olivier Hainque
+
+ * Jerome Hugues
+
+ * Hristian Kirtchev
+
+ * Jerome Lambourg
+
+ * Bruno Leclerc
+
+ * Albert Lee
+
+ * Sean McNeil
+
+ * Javier Miranda
+
+ * Laurent Nana
+
+ * Pascal Obry
+
+ * Dong-Ik Oh
+
+ * Laurent Pautet
+
+ * Brett Porter
+
+ * Thomas Quinot
+
+ * Nicolas Roche
+
+ * Pat Rogers
+
+ * Jose Ruiz
+
+ * Douglas Rupp
+
+ * Sergey Rybin
+
+ * Gail Schenker
+
+ * Ed Schonberg
+
+ * Nicolas Setton
+
+ * Samuel Tardieu
+
+
+ The following people are recognized for their contributions of new
+features, bug reports, testing and integration of classpath/libgcj for
+GCC version 4.1:
+ * Lillian Angel for `JTree' implementation and lots Free Swing
+ additions and bug fixes.
+
+ * Wolfgang Baer for `GapContent' bug fixes.
+
+ * Anthony Balkissoon for `JList', Free Swing 1.5 updates and mouse
+ event fixes, lots of Free Swing work including `JTable' editing.
+
+ * Stuart Ballard for RMI constant fixes.
+
+ * Goffredo Baroncelli for `HTTPURLConnection' fixes.
+
+ * Gary Benson for `MessageFormat' fixes.
+
+ * Daniel Bonniot for `Serialization' fixes.
+
+ * Chris Burdess for lots of gnu.xml and http protocol fixes, `StAX'
+ and `DOM xml:id' support.
+
+ * Ka-Hing Cheung for `TreePath' and `TreeSelection' fixes.
+
+ * Archie Cobbs for build fixes, VM interface updates,
+ `URLClassLoader' updates.
+
+ * Kelley Cook for build fixes.
+
+ * Martin Cordova for Suggestions for better `SocketTimeoutException'.
+
+ * David Daney for `BitSet' bug fixes, `HttpURLConnection' rewrite
+ and improvements.
+
+ * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo
+ 2D support. Lots of imageio framework additions, lots of AWT and
+ Free Swing bug fixes.
+
+ * Jeroen Frijters for `ClassLoader' and nio cleanups, serialization
+ fixes, better `Proxy' support, bug fixes and IKVM integration.
+
+ * Santiago Gala for `AccessControlContext' fixes.
+
+ * Nicolas Geoffray for `VMClassLoader' and `AccessController'
+ improvements.
+
+ * David Gilbert for `basic' and `metal' icon and plaf support and
+ lots of documenting, Lots of Free Swing and metal theme additions.
+ `MetalIconFactory' implementation.
+
+ * Anthony Green for `MIDI' framework, `ALSA' and `DSSI' providers.
+
+ * Andrew Haley for `Serialization' and `URLClassLoader' fixes, gcj
+ build speedups.
+
+ * Kim Ho for `JFileChooser' implementation.
+
+ * Andrew John Hughes for `Locale' and net fixes, URI RFC2986
+ updates, `Serialization' fixes, `Properties' XML support and
+ generic branch work, VMIntegration guide update.
+
+ * Bastiaan Huisman for `TimeZone' bug fixing.
+
+ * Andreas Jaeger for mprec updates.
+
+ * Paul Jenner for better `-Werror' support.
+
+ * Ito Kazumitsu for `NetworkInterface' implementation and updates.
+
+ * Roman Kennke for `BoxLayout', `GrayFilter' and `SplitPane', plus
+ bug fixes all over. Lots of Free Swing work including styled text.
+
+ * Simon Kitching for `String' cleanups and optimization suggestions.
+
+ * Michael Koch for configuration fixes, `Locale' updates, bug and
+ build fixes.
+
+ * Guilhem Lavaux for configuration, thread and channel fixes and
+ Kaffe integration. JCL native `Pointer' updates. Logger bug fixes.
+
+ * David Lichteblau for JCL support library global/local reference
+ cleanups.
+
+ * Aaron Luchko for JDWP updates and documentation fixes.
+
+ * Ziga Mahkovec for `Graphics2D' upgraded to Cairo 0.5 and new regex
+ features.
+
+ * Sven de Marothy for BMP imageio support, CSS and `TextLayout'
+ fixes. `GtkImage' rewrite, 2D, awt, free swing and date/time fixes
+ and implementing the Qt4 peers.
+
+ * Casey Marshall for crypto algorithm fixes, `FileChannel' lock,
+ `SystemLogger' and `FileHandler' rotate implementations, NIO
+ `FileChannel.map' support, security and policy updates.
+
+ * Bryce McKinlay for RMI work.
+
+ * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus
+ testing and documenting.
+
+ * Kalle Olavi Niemitalo for build fixes.
+
+ * Rainer Orth for build fixes.
+
+ * Andrew Overholt for `File' locking fixes.
+
+ * Ingo Proetel for `Image', `Logger' and `URLClassLoader' updates.
+
+ * Olga Rodimina for `MenuSelectionManager' implementation.
+
+ * Jan Roehrich for `BasicTreeUI' and `JTree' fixes.
+
+ * Julian Scheid for documentation updates and gjdoc support.
+
+ * Christian Schlichtherle for zip fixes and cleanups.
+
+ * Robert Schuster for documentation updates and beans fixes,
+ `TreeNode' enumerations and `ActionCommand' and various fixes, XML
+ and URL, AWT and Free Swing bug fixes.
+
+ * Keith Seitz for lots of JDWP work.
+
+ * Christian Thalinger for 64-bit cleanups, Configuration and VM
+ interface fixes and `CACAO' integration, `fdlibm' updates.
+
+ * Gael Thomas for `VMClassLoader' boot packages support suggestions.
+
+ * Andreas Tobler for Darwin and Solaris testing and fixing, `Qt4'
+ support for Darwin/OS X, `Graphics2D' support, `gtk+' updates.
+
+ * Dalibor Topic for better `DEBUG' support, build cleanups and Kaffe
+ integration. `Qt4' build infrastructure, `SHA1PRNG' and
+ `GdkPixbugDecoder' updates.
+
+ * Tom Tromey for Eclipse integration, generics work, lots of bug
+ fixes and gcj integration including coordinating The Big Merge.
+
+ * Mark Wielaard for bug fixes, packaging and release management,
+ `Clipboard' implementation, system call interrupts and network
+ timeouts and `GdkPixpufDecoder' fixes.
+
+
+ In addition to the above, all of which also contributed time and
+energy in testing GCC, we would like to thank the following for their
+contributions to testing:
+
+ * Michael Abd-El-Malek
+
+ * Thomas Arend
+
+ * Bonzo Armstrong
+
+ * Steven Ashe
+
+ * Chris Baldwin
+
+ * David Billinghurst
+
+ * Jim Blandy
+
+ * Stephane Bortzmeyer
+
+ * Horst von Brand
+
+ * Frank Braun
+
+ * Rodney Brown
+
+ * Sidney Cadot
+
+ * Bradford Castalia
+
+ * Robert Clark
+
+ * Jonathan Corbet
+
+ * Ralph Doncaster
+
+ * Richard Emberson
+
+ * Levente Farkas
+
+ * Graham Fawcett
+
+ * Mark Fernyhough
+
+ * Robert A. French
+
+ * Jo"rgen Freyh
+
+ * Mark K. Gardner
+
+ * Charles-Antoine Gauthier
+
+ * Yung Shing Gene
+
+ * David Gilbert
+
+ * Simon Gornall
+
+ * Fred Gray
+
+ * John Griffin
+
+ * Patrik Hagglund
+
+ * Phil Hargett
+
+ * Amancio Hasty
+
+ * Takafumi Hayashi
+
+ * Bryan W. Headley
+
+ * Kevin B. Hendricks
+
+ * Joep Jansen
+
+ * Christian Joensson
+
+ * Michel Kern
+
+ * David Kidd
+
+ * Tobias Kuipers
+
+ * Anand Krishnaswamy
+
+ * A. O. V. Le Blanc
+
+ * llewelly
+
+ * Damon Love
+
+ * Brad Lucier
+
+ * Matthias Klose
+
+ * Martin Knoblauch
+
+ * Rick Lutowski
+
+ * Jesse Macnish
+
+ * Stefan Morrell
+
+ * Anon A. Mous
+
+ * Matthias Mueller
+
+ * Pekka Nikander
+
+ * Rick Niles
+
+ * Jon Olson
+
+ * Magnus Persson
+
+ * Chris Pollard
+
+ * Richard Polton
+
+ * Derk Reefman
+
+ * David Rees
+
+ * Paul Reilly
+
+ * Tom Reilly
+
+ * Torsten Rueger
+
+ * Danny Sadinoff
+
+ * Marc Schifer
+
+ * Erik Schnetter
+
+ * Wayne K. Schroll
+
+ * David Schuler
+
+ * Vin Shelton
+
+ * Tim Souder
+
+ * Adam Sulmicki
+
+ * Bill Thorson
+
+ * George Talbot
+
+ * Pedro A. M. Vazquez
+
+ * Gregory Warnes
+
+ * Ian Watson
+
+ * David E. Young
+
+ * And many others
+
+ And finally we'd like to thank everyone who uses the compiler, provides
+feedback and generally reminds us why we're doing this work in the first
+place.
+
+\1f
+File: gccint.info, Node: Option Index, Next: Concept Index, Prev: Contributors, Up: Top
+
+Option Index
+************
+
+GCC's command line options are indexed here without any initial `-' or
+`--'. Where an option has both positive and negative forms (such as
+`-fOPTION' and `-fno-OPTION'), relevant entries in the manual are
+indexed under the most appropriate form; it may sometimes be useful to
+look up both forms.
+
+\0\b[index\0\b]
+* Menu:
+
+* msoft-float: Soft float library routines.
+ (line 6)
+
+\1f
+File: gccint.info, Node: Concept Index, Prev: Option Index, Up: Top
+
+Concept Index
+*************
+
+\0\b[index\0\b]
+* Menu:
+
+* ! in constraint: Multi-Alternative. (line 47)
+* # in constraint: Modifiers. (line 67)
+* # in template: Output Template. (line 66)
+* #pragma: Misc. (line 381)
+* % in constraint: Modifiers. (line 45)
+* % in GTY option: GTY Options. (line 18)
+* % in template: Output Template. (line 6)
+* & in constraint: Modifiers. (line 25)
+* ( <1>: Sections. (line 160)
+* ( <2>: GIMPLE_CALL. (line 63)
+* ( <3>: GIMPLE_ASM. (line 21)
+* (: Logical Operators. (line 107)
+* (nil): RTL Objects. (line 73)
+* * <1>: Host Common. (line 17)
+* *: Scheduling. (line 246)
+* * in constraint: Modifiers. (line 72)
+* * in template: Output Statement. (line 29)
+* *gimple_assign_lhs_ptr: GIMPLE_ASSIGN. (line 54)
+* *gimple_assign_rhs1_ptr: GIMPLE_ASSIGN. (line 60)
+* *gimple_assign_rhs2_ptr: GIMPLE_ASSIGN. (line 67)
+* *gimple_call_arg_ptr: GIMPLE_CALL. (line 71)
+* *gimple_call_lhs_ptr: GIMPLE_CALL. (line 32)
+* *gimple_catch_types_ptr: GIMPLE_CATCH. (line 16)
+* *gimple_cdt_location_ptr: GIMPLE_CHANGE_DYNAMIC_TYPE.
+ (line 28)
+* *gimple_cdt_new_type_ptr: GIMPLE_CHANGE_DYNAMIC_TYPE.
+ (line 15)
+* *gimple_eh_filter_types_ptr: GIMPLE_EH_FILTER. (line 15)
+* *gimple_omp_critical_name_ptr: GIMPLE_OMP_CRITICAL.
+ (line 16)
+* *gimple_omp_for_clauses_ptr: GIMPLE_OMP_FOR. (line 23)
+* *gimple_omp_for_final_ptr: GIMPLE_OMP_FOR. (line 54)
+* *gimple_omp_for_incr_ptr: GIMPLE_OMP_FOR. (line 64)
+* *gimple_omp_for_index_ptr: GIMPLE_OMP_FOR. (line 34)
+* *gimple_omp_for_initial_ptr: GIMPLE_OMP_FOR. (line 44)
+* *gimple_omp_parallel_child_fn_ptr: GIMPLE_OMP_PARALLEL.
+ (line 46)
+* *gimple_omp_parallel_clauses_ptr: GIMPLE_OMP_PARALLEL.
+ (line 34)
+* *gimple_omp_parallel_data_arg_ptr: GIMPLE_OMP_PARALLEL.
+ (line 58)
+* *gimple_omp_sections_clauses_ptr: GIMPLE_OMP_SECTIONS.
+ (line 33)
+* *gimple_omp_sections_control_ptr: GIMPLE_OMP_SECTIONS.
+ (line 21)
+* *gimple_omp_single_clauses_ptr: GIMPLE_OMP_SINGLE. (line 17)
+* *gimple_op_ptr: Manipulating GIMPLE statements.
+ (line 84)
+* *gimple_ops <1>: Manipulating GIMPLE statements.
+ (line 78)
+* *gimple_ops: Logical Operators. (line 82)
+* *gimple_phi_result_ptr: GIMPLE_PHI. (line 22)
+* *gsi_stmt_ptr: Sequence iterators. (line 80)
+* *TARGET_GET_PCH_VALIDITY: PCH Target. (line 7)
+* + in constraint: Modifiers. (line 12)
+* -fsection-anchors <1>: Anchored Addresses. (line 6)
+* -fsection-anchors: Special Accessors. (line 106)
+* /c in RTL dump: Flags. (line 234)
+* /f in RTL dump: Flags. (line 242)
+* /i in RTL dump: Flags. (line 294)
+* /j in RTL dump: Flags. (line 309)
+* /s in RTL dump: Flags. (line 258)
+* /u in RTL dump: Flags. (line 319)
+* /v in RTL dump: Flags. (line 351)
+* 0 in constraint: Simple Constraints. (line 120)
+* < in constraint: Simple Constraints. (line 48)
+* = in constraint: Modifiers. (line 8)
+* > in constraint: Simple Constraints. (line 52)
+* ? in constraint: Multi-Alternative. (line 41)
+* \: Output Template. (line 46)
+* __absvdi2: Integer library routines.
+ (line 107)
+* __absvsi2: Integer library routines.
+ (line 106)
+* __addda3: Fixed-point fractional library routines.
+ (line 45)
+* __adddf3: Soft float library routines.
+ (line 23)
+* __adddq3: Fixed-point fractional library routines.
+ (line 33)
+* __addha3: Fixed-point fractional library routines.
+ (line 43)
+* __addhq3: Fixed-point fractional library routines.
+ (line 30)
+* __addqq3: Fixed-point fractional library routines.
+ (line 29)
+* __addsa3: Fixed-point fractional library routines.
+ (line 44)
+* __addsf3: Soft float library routines.
+ (line 22)
+* __addsq3: Fixed-point fractional library routines.
+ (line 31)
+* __addta3: Fixed-point fractional library routines.
+ (line 47)
+* __addtf3: Soft float library routines.
+ (line 25)
+* __adduda3: Fixed-point fractional library routines.
+ (line 53)
+* __addudq3: Fixed-point fractional library routines.
+ (line 41)
+* __adduha3: Fixed-point fractional library routines.
+ (line 49)
+* __adduhq3: Fixed-point fractional library routines.
+ (line 37)
+* __adduqq3: Fixed-point fractional library routines.
+ (line 35)
+* __addusa3: Fixed-point fractional library routines.
+ (line 51)
+* __addusq3: Fixed-point fractional library routines.
+ (line 39)
+* __adduta3: Fixed-point fractional library routines.
+ (line 55)
+* __addvdi3: Integer library routines.
+ (line 111)
+* __addvsi3: Integer library routines.
+ (line 110)
+* __addxf3: Soft float library routines.
+ (line 27)
+* __ashlda3: Fixed-point fractional library routines.
+ (line 351)
+* __ashldi3: Integer library routines.
+ (line 14)
+* __ashldq3: Fixed-point fractional library routines.
+ (line 340)
+* __ashlha3: Fixed-point fractional library routines.
+ (line 349)
+* __ashlhq3: Fixed-point fractional library routines.
+ (line 337)
+* __ashlqq3: Fixed-point fractional library routines.
+ (line 336)
+* __ashlsa3: Fixed-point fractional library routines.
+ (line 350)
+* __ashlsi3: Integer library routines.
+ (line 13)
+* __ashlsq3: Fixed-point fractional library routines.
+ (line 338)
+* __ashlta3: Fixed-point fractional library routines.
+ (line 353)
+* __ashlti3: Integer library routines.
+ (line 15)
+* __ashluda3: Fixed-point fractional library routines.
+ (line 359)
+* __ashludq3: Fixed-point fractional library routines.
+ (line 348)
+* __ashluha3: Fixed-point fractional library routines.
+ (line 355)
+* __ashluhq3: Fixed-point fractional library routines.
+ (line 344)
+* __ashluqq3: Fixed-point fractional library routines.
+ (line 342)
+* __ashlusa3: Fixed-point fractional library routines.
+ (line 357)
+* __ashlusq3: Fixed-point fractional library routines.
+ (line 346)
+* __ashluta3: Fixed-point fractional library routines.
+ (line 361)
+* __ashrda3: Fixed-point fractional library routines.
+ (line 371)
+* __ashrdi3: Integer library routines.
+ (line 19)
+* __ashrdq3: Fixed-point fractional library routines.
+ (line 368)
+* __ashrha3: Fixed-point fractional library routines.
+ (line 369)
+* __ashrhq3: Fixed-point fractional library routines.
+ (line 365)
+* __ashrqq3: Fixed-point fractional library routines.
+ (line 364)
+* __ashrsa3: Fixed-point fractional library routines.
+ (line 370)
+* __ashrsi3: Integer library routines.
+ (line 18)
+* __ashrsq3: Fixed-point fractional library routines.
+ (line 366)
+* __ashrta3: Fixed-point fractional library routines.
+ (line 373)
+* __ashrti3: Integer library routines.
+ (line 20)
+* __bid_adddd3: Decimal float library routines.
+ (line 25)
+* __bid_addsd3: Decimal float library routines.
+ (line 21)
+* __bid_addtd3: Decimal float library routines.
+ (line 29)
+* __bid_divdd3: Decimal float library routines.
+ (line 68)
+* __bid_divsd3: Decimal float library routines.
+ (line 64)
+* __bid_divtd3: Decimal float library routines.
+ (line 72)
+* __bid_eqdd2: Decimal float library routines.
+ (line 259)
+* __bid_eqsd2: Decimal float library routines.
+ (line 257)
+* __bid_eqtd2: Decimal float library routines.
+ (line 261)
+* __bid_extendddtd2: Decimal float library routines.
+ (line 92)
+* __bid_extendddtf: Decimal float library routines.
+ (line 140)
+* __bid_extendddxf: Decimal float library routines.
+ (line 134)
+* __bid_extenddfdd: Decimal float library routines.
+ (line 147)
+* __bid_extenddftd: Decimal float library routines.
+ (line 107)
+* __bid_extendsddd2: Decimal float library routines.
+ (line 88)
+* __bid_extendsddf: Decimal float library routines.
+ (line 128)
+* __bid_extendsdtd2: Decimal float library routines.
+ (line 90)
+* __bid_extendsdtf: Decimal float library routines.
+ (line 138)
+* __bid_extendsdxf: Decimal float library routines.
+ (line 132)
+* __bid_extendsfdd: Decimal float library routines.
+ (line 103)
+* __bid_extendsfsd: Decimal float library routines.
+ (line 145)
+* __bid_extendsftd: Decimal float library routines.
+ (line 105)
+* __bid_extendtftd: Decimal float library routines.
+ (line 149)
+* __bid_extendxftd: Decimal float library routines.
+ (line 109)
+* __bid_fixdddi: Decimal float library routines.
+ (line 170)
+* __bid_fixddsi: Decimal float library routines.
+ (line 162)
+* __bid_fixsddi: Decimal float library routines.
+ (line 168)
+* __bid_fixsdsi: Decimal float library routines.
+ (line 160)
+* __bid_fixtddi: Decimal float library routines.
+ (line 172)
+* __bid_fixtdsi: Decimal float library routines.
+ (line 164)
+* __bid_fixunsdddi: Decimal float library routines.
+ (line 187)
+* __bid_fixunsddsi: Decimal float library routines.
+ (line 178)
+* __bid_fixunssddi: Decimal float library routines.
+ (line 185)
+* __bid_fixunssdsi: Decimal float library routines.
+ (line 176)
+* __bid_fixunstddi: Decimal float library routines.
+ (line 189)
+* __bid_fixunstdsi: Decimal float library routines.
+ (line 180)
+* __bid_floatdidd: Decimal float library routines.
+ (line 205)
+* __bid_floatdisd: Decimal float library routines.
+ (line 203)
+* __bid_floatditd: Decimal float library routines.
+ (line 207)
+* __bid_floatsidd: Decimal float library routines.
+ (line 196)
+* __bid_floatsisd: Decimal float library routines.
+ (line 194)
+* __bid_floatsitd: Decimal float library routines.
+ (line 198)
+* __bid_floatunsdidd: Decimal float library routines.
+ (line 223)
+* __bid_floatunsdisd: Decimal float library routines.
+ (line 221)
+* __bid_floatunsditd: Decimal float library routines.
+ (line 225)
+* __bid_floatunssidd: Decimal float library routines.
+ (line 214)
+* __bid_floatunssisd: Decimal float library routines.
+ (line 212)
+* __bid_floatunssitd: Decimal float library routines.
+ (line 216)
+* __bid_gedd2: Decimal float library routines.
+ (line 277)
+* __bid_gesd2: Decimal float library routines.
+ (line 275)
+* __bid_getd2: Decimal float library routines.
+ (line 279)
+* __bid_gtdd2: Decimal float library routines.
+ (line 304)
+* __bid_gtsd2: Decimal float library routines.
+ (line 302)
+* __bid_gttd2: Decimal float library routines.
+ (line 306)
+* __bid_ledd2: Decimal float library routines.
+ (line 295)
+* __bid_lesd2: Decimal float library routines.
+ (line 293)
+* __bid_letd2: Decimal float library routines.
+ (line 297)
+* __bid_ltdd2: Decimal float library routines.
+ (line 286)
+* __bid_ltsd2: Decimal float library routines.
+ (line 284)
+* __bid_lttd2: Decimal float library routines.
+ (line 288)
+* __bid_muldd3: Decimal float library routines.
+ (line 54)
+* __bid_mulsd3: Decimal float library routines.
+ (line 50)
+* __bid_multd3: Decimal float library routines.
+ (line 58)
+* __bid_nedd2: Decimal float library routines.
+ (line 268)
+* __bid_negdd2: Decimal float library routines.
+ (line 78)
+* __bid_negsd2: Decimal float library routines.
+ (line 76)
+* __bid_negtd2: Decimal float library routines.
+ (line 80)
+* __bid_nesd2: Decimal float library routines.
+ (line 266)
+* __bid_netd2: Decimal float library routines.
+ (line 270)
+* __bid_subdd3: Decimal float library routines.
+ (line 39)
+* __bid_subsd3: Decimal float library routines.
+ (line 35)
+* __bid_subtd3: Decimal float library routines.
+ (line 43)
+* __bid_truncdddf: Decimal float library routines.
+ (line 153)
+* __bid_truncddsd2: Decimal float library routines.
+ (line 94)
+* __bid_truncddsf: Decimal float library routines.
+ (line 124)
+* __bid_truncdfsd: Decimal float library routines.
+ (line 111)
+* __bid_truncsdsf: Decimal float library routines.
+ (line 151)
+* __bid_trunctddd2: Decimal float library routines.
+ (line 98)
+* __bid_trunctddf: Decimal float library routines.
+ (line 130)
+* __bid_trunctdsd2: Decimal float library routines.
+ (line 96)
+* __bid_trunctdsf: Decimal float library routines.
+ (line 126)
+* __bid_trunctdtf: Decimal float library routines.
+ (line 155)
+* __bid_trunctdxf: Decimal float library routines.
+ (line 136)
+* __bid_trunctfdd: Decimal float library routines.
+ (line 119)
+* __bid_trunctfsd: Decimal float library routines.
+ (line 115)
+* __bid_truncxfdd: Decimal float library routines.
+ (line 117)
+* __bid_truncxfsd: Decimal float library routines.
+ (line 113)
+* __bid_unorddd2: Decimal float library routines.
+ (line 235)
+* __bid_unordsd2: Decimal float library routines.
+ (line 233)
+* __bid_unordtd2: Decimal float library routines.
+ (line 237)
+* __bswapdi2: Integer library routines.
+ (line 162)
+* __bswapsi2: Integer library routines.
+ (line 161)
+* __builtin_args_info: Varargs. (line 42)
+* __builtin_classify_type: Varargs. (line 76)
+* __builtin_next_arg: Varargs. (line 66)
+* __builtin_saveregs: Varargs. (line 24)
+* __clear_cache: Miscellaneous routines.
+ (line 10)
+* __clzdi2: Integer library routines.
+ (line 131)
+* __clzsi2: Integer library routines.
+ (line 130)
+* __clzti2: Integer library routines.
+ (line 132)
+* __cmpda2: Fixed-point fractional library routines.
+ (line 451)
+* __cmpdf2: Soft float library routines.
+ (line 164)
+* __cmpdi2: Integer library routines.
+ (line 87)
+* __cmpdq2: Fixed-point fractional library routines.
+ (line 441)
+* __cmpha2: Fixed-point fractional library routines.
+ (line 449)
+* __cmphq2: Fixed-point fractional library routines.
+ (line 438)
+* __cmpqq2: Fixed-point fractional library routines.
+ (line 437)
+* __cmpsa2: Fixed-point fractional library routines.
+ (line 450)
+* __cmpsf2: Soft float library routines.
+ (line 163)
+* __cmpsq2: Fixed-point fractional library routines.
+ (line 439)
+* __cmpta2: Fixed-point fractional library routines.
+ (line 453)
+* __cmptf2: Soft float library routines.
+ (line 165)
+* __cmpti2: Integer library routines.
+ (line 88)
+* __cmpuda2: Fixed-point fractional library routines.
+ (line 458)
+* __cmpudq2: Fixed-point fractional library routines.
+ (line 448)
+* __cmpuha2: Fixed-point fractional library routines.
+ (line 455)
+* __cmpuhq2: Fixed-point fractional library routines.
+ (line 444)
+* __cmpuqq2: Fixed-point fractional library routines.
+ (line 443)
+* __cmpusa2: Fixed-point fractional library routines.
+ (line 456)
+* __cmpusq2: Fixed-point fractional library routines.
+ (line 446)
+* __cmputa2: Fixed-point fractional library routines.
+ (line 460)
+* __CTOR_LIST__: Initialization. (line 25)
+* __ctzdi2: Integer library routines.
+ (line 138)
+* __ctzsi2: Integer library routines.
+ (line 137)
+* __ctzti2: Integer library routines.
+ (line 139)
+* __divda3: Fixed-point fractional library routines.
+ (line 227)
+* __divdc3: Soft float library routines.
+ (line 252)
+* __divdf3: Soft float library routines.
+ (line 48)
+* __divdi3: Integer library routines.
+ (line 25)
+* __divdq3: Fixed-point fractional library routines.
+ (line 223)
+* __divha3: Fixed-point fractional library routines.
+ (line 225)
+* __divhq3: Fixed-point fractional library routines.
+ (line 220)
+* __divqq3: Fixed-point fractional library routines.
+ (line 219)
+* __divsa3: Fixed-point fractional library routines.
+ (line 226)
+* __divsc3: Soft float library routines.
+ (line 250)
+* __divsf3: Soft float library routines.
+ (line 47)
+* __divsi3: Integer library routines.
+ (line 24)
+* __divsq3: Fixed-point fractional library routines.
+ (line 221)
+* __divta3: Fixed-point fractional library routines.
+ (line 229)
+* __divtc3: Soft float library routines.
+ (line 254)
+* __divtf3: Soft float library routines.
+ (line 50)
+* __divti3: Integer library routines.
+ (line 26)
+* __divxc3: Soft float library routines.
+ (line 256)
+* __divxf3: Soft float library routines.
+ (line 52)
+* __dpd_adddd3: Decimal float library routines.
+ (line 23)
+* __dpd_addsd3: Decimal float library routines.
+ (line 19)
+* __dpd_addtd3: Decimal float library routines.
+ (line 27)
+* __dpd_divdd3: Decimal float library routines.
+ (line 66)
+* __dpd_divsd3: Decimal float library routines.
+ (line 62)
+* __dpd_divtd3: Decimal float library routines.
+ (line 70)
+* __dpd_eqdd2: Decimal float library routines.
+ (line 258)
+* __dpd_eqsd2: Decimal float library routines.
+ (line 256)
+* __dpd_eqtd2: Decimal float library routines.
+ (line 260)
+* __dpd_extendddtd2: Decimal float library routines.
+ (line 91)
+* __dpd_extendddtf: Decimal float library routines.
+ (line 139)
+* __dpd_extendddxf: Decimal float library routines.
+ (line 133)
+* __dpd_extenddfdd: Decimal float library routines.
+ (line 146)
+* __dpd_extenddftd: Decimal float library routines.
+ (line 106)
+* __dpd_extendsddd2: Decimal float library routines.
+ (line 87)
+* __dpd_extendsddf: Decimal float library routines.
+ (line 127)
+* __dpd_extendsdtd2: Decimal float library routines.
+ (line 89)
+* __dpd_extendsdtf: Decimal float library routines.
+ (line 137)
+* __dpd_extendsdxf: Decimal float library routines.
+ (line 131)
+* __dpd_extendsfdd: Decimal float library routines.
+ (line 102)
+* __dpd_extendsfsd: Decimal float library routines.
+ (line 144)
+* __dpd_extendsftd: Decimal float library routines.
+ (line 104)
+* __dpd_extendtftd: Decimal float library routines.
+ (line 148)
+* __dpd_extendxftd: Decimal float library routines.
+ (line 108)
+* __dpd_fixdddi: Decimal float library routines.
+ (line 169)
+* __dpd_fixddsi: Decimal float library routines.
+ (line 161)
+* __dpd_fixsddi: Decimal float library routines.
+ (line 167)
+* __dpd_fixsdsi: Decimal float library routines.
+ (line 159)
+* __dpd_fixtddi: Decimal float library routines.
+ (line 171)
+* __dpd_fixtdsi: Decimal float library routines.
+ (line 163)
+* __dpd_fixunsdddi: Decimal float library routines.
+ (line 186)
+* __dpd_fixunsddsi: Decimal float library routines.
+ (line 177)
+* __dpd_fixunssddi: Decimal float library routines.
+ (line 184)
+* __dpd_fixunssdsi: Decimal float library routines.
+ (line 175)
+* __dpd_fixunstddi: Decimal float library routines.
+ (line 188)
+* __dpd_fixunstdsi: Decimal float library routines.
+ (line 179)
+* __dpd_floatdidd: Decimal float library routines.
+ (line 204)
+* __dpd_floatdisd: Decimal float library routines.
+ (line 202)
+* __dpd_floatditd: Decimal float library routines.
+ (line 206)
+* __dpd_floatsidd: Decimal float library routines.
+ (line 195)
+* __dpd_floatsisd: Decimal float library routines.
+ (line 193)
+* __dpd_floatsitd: Decimal float library routines.
+ (line 197)
+* __dpd_floatunsdidd: Decimal float library routines.
+ (line 222)
+* __dpd_floatunsdisd: Decimal float library routines.
+ (line 220)
+* __dpd_floatunsditd: Decimal float library routines.
+ (line 224)
+* __dpd_floatunssidd: Decimal float library routines.
+ (line 213)
+* __dpd_floatunssisd: Decimal float library routines.
+ (line 211)
+* __dpd_floatunssitd: Decimal float library routines.
+ (line 215)
+* __dpd_gedd2: Decimal float library routines.
+ (line 276)
+* __dpd_gesd2: Decimal float library routines.
+ (line 274)
+* __dpd_getd2: Decimal float library routines.
+ (line 278)
+* __dpd_gtdd2: Decimal float library routines.
+ (line 303)
+* __dpd_gtsd2: Decimal float library routines.
+ (line 301)
+* __dpd_gttd2: Decimal float library routines.
+ (line 305)
+* __dpd_ledd2: Decimal float library routines.
+ (line 294)
+* __dpd_lesd2: Decimal float library routines.
+ (line 292)
+* __dpd_letd2: Decimal float library routines.
+ (line 296)
+* __dpd_ltdd2: Decimal float library routines.
+ (line 285)
+* __dpd_ltsd2: Decimal float library routines.
+ (line 283)
+* __dpd_lttd2: Decimal float library routines.
+ (line 287)
+* __dpd_muldd3: Decimal float library routines.
+ (line 52)
+* __dpd_mulsd3: Decimal float library routines.
+ (line 48)
+* __dpd_multd3: Decimal float library routines.
+ (line 56)
+* __dpd_nedd2: Decimal float library routines.
+ (line 267)
+* __dpd_negdd2: Decimal float library routines.
+ (line 77)
+* __dpd_negsd2: Decimal float library routines.
+ (line 75)
+* __dpd_negtd2: Decimal float library routines.
+ (line 79)
+* __dpd_nesd2: Decimal float library routines.
+ (line 265)
+* __dpd_netd2: Decimal float library routines.
+ (line 269)
+* __dpd_subdd3: Decimal float library routines.
+ (line 37)
+* __dpd_subsd3: Decimal float library routines.
+ (line 33)
+* __dpd_subtd3: Decimal float library routines.
+ (line 41)
+* __dpd_truncdddf: Decimal float library routines.
+ (line 152)
+* __dpd_truncddsd2: Decimal float library routines.
+ (line 93)
+* __dpd_truncddsf: Decimal float library routines.
+ (line 123)
+* __dpd_truncdfsd: Decimal float library routines.
+ (line 110)
+* __dpd_truncsdsf: Decimal float library routines.
+ (line 150)
+* __dpd_trunctddd2: Decimal float library routines.
+ (line 97)
+* __dpd_trunctddf: Decimal float library routines.
+ (line 129)
+* __dpd_trunctdsd2: Decimal float library routines.
+ (line 95)
+* __dpd_trunctdsf: Decimal float library routines.
+ (line 125)
+* __dpd_trunctdtf: Decimal float library routines.
+ (line 154)
+* __dpd_trunctdxf: Decimal float library routines.
+ (line 135)
+* __dpd_trunctfdd: Decimal float library routines.
+ (line 118)
+* __dpd_trunctfsd: Decimal float library routines.
+ (line 114)
+* __dpd_truncxfdd: Decimal float library routines.
+ (line 116)
+* __dpd_truncxfsd: Decimal float library routines.
+ (line 112)
+* __dpd_unorddd2: Decimal float library routines.
+ (line 234)
+* __dpd_unordsd2: Decimal float library routines.
+ (line 232)
+* __dpd_unordtd2: Decimal float library routines.
+ (line 236)
+* __DTOR_LIST__: Initialization. (line 25)
+* __eqdf2: Soft float library routines.
+ (line 194)
+* __eqsf2: Soft float library routines.
+ (line 193)
+* __eqtf2: Soft float library routines.
+ (line 195)
+* __extenddftf2: Soft float library routines.
+ (line 68)
+* __extenddfxf2: Soft float library routines.
+ (line 69)
+* __extendsfdf2: Soft float library routines.
+ (line 65)
+* __extendsftf2: Soft float library routines.
+ (line 66)
+* __extendsfxf2: Soft float library routines.
+ (line 67)
+* __ffsdi2: Integer library routines.
+ (line 144)
+* __ffsti2: Integer library routines.
+ (line 145)
+* __fixdfdi: Soft float library routines.
+ (line 88)
+* __fixdfsi: Soft float library routines.
+ (line 81)
+* __fixdfti: Soft float library routines.
+ (line 94)
+* __fixsfdi: Soft float library routines.
+ (line 87)
+* __fixsfsi: Soft float library routines.
+ (line 80)
+* __fixsfti: Soft float library routines.
+ (line 93)
+* __fixtfdi: Soft float library routines.
+ (line 89)
+* __fixtfsi: Soft float library routines.
+ (line 82)
+* __fixtfti: Soft float library routines.
+ (line 95)
+* __fixunsdfdi: Soft float library routines.
+ (line 108)
+* __fixunsdfsi: Soft float library routines.
+ (line 101)
+* __fixunsdfti: Soft float library routines.
+ (line 115)
+* __fixunssfdi: Soft float library routines.
+ (line 107)
+* __fixunssfsi: Soft float library routines.
+ (line 100)
+* __fixunssfti: Soft float library routines.
+ (line 114)
+* __fixunstfdi: Soft float library routines.
+ (line 109)
+* __fixunstfsi: Soft float library routines.
+ (line 102)
+* __fixunstfti: Soft float library routines.
+ (line 116)
+* __fixunsxfdi: Soft float library routines.
+ (line 110)
+* __fixunsxfsi: Soft float library routines.
+ (line 103)
+* __fixunsxfti: Soft float library routines.
+ (line 117)
+* __fixxfdi: Soft float library routines.
+ (line 90)
+* __fixxfsi: Soft float library routines.
+ (line 83)
+* __fixxfti: Soft float library routines.
+ (line 96)
+* __floatdidf: Soft float library routines.
+ (line 128)
+* __floatdisf: Soft float library routines.
+ (line 127)
+* __floatditf: Soft float library routines.
+ (line 129)
+* __floatdixf: Soft float library routines.
+ (line 130)
+* __floatsidf: Soft float library routines.
+ (line 122)
+* __floatsisf: Soft float library routines.
+ (line 121)
+* __floatsitf: Soft float library routines.
+ (line 123)
+* __floatsixf: Soft float library routines.
+ (line 124)
+* __floattidf: Soft float library routines.
+ (line 134)
+* __floattisf: Soft float library routines.
+ (line 133)
+* __floattitf: Soft float library routines.
+ (line 135)
+* __floattixf: Soft float library routines.
+ (line 136)
+* __floatundidf: Soft float library routines.
+ (line 146)
+* __floatundisf: Soft float library routines.
+ (line 145)
+* __floatunditf: Soft float library routines.
+ (line 147)
+* __floatundixf: Soft float library routines.
+ (line 148)
+* __floatunsidf: Soft float library routines.
+ (line 140)
+* __floatunsisf: Soft float library routines.
+ (line 139)
+* __floatunsitf: Soft float library routines.
+ (line 141)
+* __floatunsixf: Soft float library routines.
+ (line 142)
+* __floatuntidf: Soft float library routines.
+ (line 152)
+* __floatuntisf: Soft float library routines.
+ (line 151)
+* __floatuntitf: Soft float library routines.
+ (line 153)
+* __floatuntixf: Soft float library routines.
+ (line 154)
+* __fractdadf: Fixed-point fractional library routines.
+ (line 636)
+* __fractdadi: Fixed-point fractional library routines.
+ (line 633)
+* __fractdadq: Fixed-point fractional library routines.
+ (line 616)
+* __fractdaha2: Fixed-point fractional library routines.
+ (line 617)
+* __fractdahi: Fixed-point fractional library routines.
+ (line 631)
+* __fractdahq: Fixed-point fractional library routines.
+ (line 614)
+* __fractdaqi: Fixed-point fractional library routines.
+ (line 630)
+* __fractdaqq: Fixed-point fractional library routines.
+ (line 613)
+* __fractdasa2: Fixed-point fractional library routines.
+ (line 618)
+* __fractdasf: Fixed-point fractional library routines.
+ (line 635)
+* __fractdasi: Fixed-point fractional library routines.
+ (line 632)
+* __fractdasq: Fixed-point fractional library routines.
+ (line 615)
+* __fractdata2: Fixed-point fractional library routines.
+ (line 619)
+* __fractdati: Fixed-point fractional library routines.
+ (line 634)
+* __fractdauda: Fixed-point fractional library routines.
+ (line 627)
+* __fractdaudq: Fixed-point fractional library routines.
+ (line 624)
+* __fractdauha: Fixed-point fractional library routines.
+ (line 625)
+* __fractdauhq: Fixed-point fractional library routines.
+ (line 621)
+* __fractdauqq: Fixed-point fractional library routines.
+ (line 620)
+* __fractdausa: Fixed-point fractional library routines.
+ (line 626)
+* __fractdausq: Fixed-point fractional library routines.
+ (line 622)
+* __fractdauta: Fixed-point fractional library routines.
+ (line 629)
+* __fractdfda: Fixed-point fractional library routines.
+ (line 1025)
+* __fractdfdq: Fixed-point fractional library routines.
+ (line 1022)
+* __fractdfha: Fixed-point fractional library routines.
+ (line 1023)
+* __fractdfhq: Fixed-point fractional library routines.
+ (line 1020)
+* __fractdfqq: Fixed-point fractional library routines.
+ (line 1019)
+* __fractdfsa: Fixed-point fractional library routines.
+ (line 1024)
+* __fractdfsq: Fixed-point fractional library routines.
+ (line 1021)
+* __fractdfta: Fixed-point fractional library routines.
+ (line 1026)
+* __fractdfuda: Fixed-point fractional library routines.
+ (line 1033)
+* __fractdfudq: Fixed-point fractional library routines.
+ (line 1030)
+* __fractdfuha: Fixed-point fractional library routines.
+ (line 1031)
+* __fractdfuhq: Fixed-point fractional library routines.
+ (line 1028)
+* __fractdfuqq: Fixed-point fractional library routines.
+ (line 1027)
+* __fractdfusa: Fixed-point fractional library routines.
+ (line 1032)
+* __fractdfusq: Fixed-point fractional library routines.
+ (line 1029)
+* __fractdfuta: Fixed-point fractional library routines.
+ (line 1034)
+* __fractdida: Fixed-point fractional library routines.
+ (line 975)
+* __fractdidq: Fixed-point fractional library routines.
+ (line 972)
+* __fractdiha: Fixed-point fractional library routines.
+ (line 973)
+* __fractdihq: Fixed-point fractional library routines.
+ (line 970)
+* __fractdiqq: Fixed-point fractional library routines.
+ (line 969)
+* __fractdisa: Fixed-point fractional library routines.
+ (line 974)
+* __fractdisq: Fixed-point fractional library routines.
+ (line 971)
+* __fractdita: Fixed-point fractional library routines.
+ (line 976)
+* __fractdiuda: Fixed-point fractional library routines.
+ (line 983)
+* __fractdiudq: Fixed-point fractional library routines.
+ (line 980)
+* __fractdiuha: Fixed-point fractional library routines.
+ (line 981)
+* __fractdiuhq: Fixed-point fractional library routines.
+ (line 978)
+* __fractdiuqq: Fixed-point fractional library routines.
+ (line 977)
+* __fractdiusa: Fixed-point fractional library routines.
+ (line 982)
+* __fractdiusq: Fixed-point fractional library routines.
+ (line 979)
+* __fractdiuta: Fixed-point fractional library routines.
+ (line 984)
+* __fractdqda: Fixed-point fractional library routines.
+ (line 544)
+* __fractdqdf: Fixed-point fractional library routines.
+ (line 566)
+* __fractdqdi: Fixed-point fractional library routines.
+ (line 563)
+* __fractdqha: Fixed-point fractional library routines.
+ (line 542)
+* __fractdqhi: Fixed-point fractional library routines.
+ (line 561)
+* __fractdqhq2: Fixed-point fractional library routines.
+ (line 540)
+* __fractdqqi: Fixed-point fractional library routines.
+ (line 560)
+* __fractdqqq2: Fixed-point fractional library routines.
+ (line 539)
+* __fractdqsa: Fixed-point fractional library routines.
+ (line 543)
+* __fractdqsf: Fixed-point fractional library routines.
+ (line 565)
+* __fractdqsi: Fixed-point fractional library routines.
+ (line 562)
+* __fractdqsq2: Fixed-point fractional library routines.
+ (line 541)
+* __fractdqta: Fixed-point fractional library routines.
+ (line 545)
+* __fractdqti: Fixed-point fractional library routines.
+ (line 564)
+* __fractdquda: Fixed-point fractional library routines.
+ (line 557)
+* __fractdqudq: Fixed-point fractional library routines.
+ (line 552)
+* __fractdquha: Fixed-point fractional library routines.
+ (line 554)
+* __fractdquhq: Fixed-point fractional library routines.
+ (line 548)
+* __fractdquqq: Fixed-point fractional library routines.
+ (line 547)
+* __fractdqusa: Fixed-point fractional library routines.
+ (line 555)
+* __fractdqusq: Fixed-point fractional library routines.
+ (line 550)
+* __fractdquta: Fixed-point fractional library routines.
+ (line 559)
+* __fracthada2: Fixed-point fractional library routines.
+ (line 572)
+* __fracthadf: Fixed-point fractional library routines.
+ (line 590)
+* __fracthadi: Fixed-point fractional library routines.
+ (line 587)
+* __fracthadq: Fixed-point fractional library routines.
+ (line 570)
+* __fracthahi: Fixed-point fractional library routines.
+ (line 585)
+* __fracthahq: Fixed-point fractional library routines.
+ (line 568)
+* __fracthaqi: Fixed-point fractional library routines.
+ (line 584)
+* __fracthaqq: Fixed-point fractional library routines.
+ (line 567)
+* __fracthasa2: Fixed-point fractional library routines.
+ (line 571)
+* __fracthasf: Fixed-point fractional library routines.
+ (line 589)
+* __fracthasi: Fixed-point fractional library routines.
+ (line 586)
+* __fracthasq: Fixed-point fractional library routines.
+ (line 569)
+* __fracthata2: Fixed-point fractional library routines.
+ (line 573)
+* __fracthati: Fixed-point fractional library routines.
+ (line 588)
+* __fracthauda: Fixed-point fractional library routines.
+ (line 581)
+* __fracthaudq: Fixed-point fractional library routines.
+ (line 578)
+* __fracthauha: Fixed-point fractional library routines.
+ (line 579)
+* __fracthauhq: Fixed-point fractional library routines.
+ (line 575)
+* __fracthauqq: Fixed-point fractional library routines.
+ (line 574)
+* __fracthausa: Fixed-point fractional library routines.
+ (line 580)
+* __fracthausq: Fixed-point fractional library routines.
+ (line 576)
+* __fracthauta: Fixed-point fractional library routines.
+ (line 583)
+* __fracthida: Fixed-point fractional library routines.
+ (line 943)
+* __fracthidq: Fixed-point fractional library routines.
+ (line 940)
+* __fracthiha: Fixed-point fractional library routines.
+ (line 941)
+* __fracthihq: Fixed-point fractional library routines.
+ (line 938)
+* __fracthiqq: Fixed-point fractional library routines.
+ (line 937)
+* __fracthisa: Fixed-point fractional library routines.
+ (line 942)
+* __fracthisq: Fixed-point fractional library routines.
+ (line 939)
+* __fracthita: Fixed-point fractional library routines.
+ (line 944)
+* __fracthiuda: Fixed-point fractional library routines.
+ (line 951)
+* __fracthiudq: Fixed-point fractional library routines.
+ (line 948)
+* __fracthiuha: Fixed-point fractional library routines.
+ (line 949)
+* __fracthiuhq: Fixed-point fractional library routines.
+ (line 946)
+* __fracthiuqq: Fixed-point fractional library routines.
+ (line 945)
+* __fracthiusa: Fixed-point fractional library routines.
+ (line 950)
+* __fracthiusq: Fixed-point fractional library routines.
+ (line 947)
+* __fracthiuta: Fixed-point fractional library routines.
+ (line 952)
+* __fracthqda: Fixed-point fractional library routines.
+ (line 498)
+* __fracthqdf: Fixed-point fractional library routines.
+ (line 514)
+* __fracthqdi: Fixed-point fractional library routines.
+ (line 511)
+* __fracthqdq2: Fixed-point fractional library routines.
+ (line 495)
+* __fracthqha: Fixed-point fractional library routines.
+ (line 496)
+* __fracthqhi: Fixed-point fractional library routines.
+ (line 509)
+* __fracthqqi: Fixed-point fractional library routines.
+ (line 508)
+* __fracthqqq2: Fixed-point fractional library routines.
+ (line 493)
+* __fracthqsa: Fixed-point fractional library routines.
+ (line 497)
+* __fracthqsf: Fixed-point fractional library routines.
+ (line 513)
+* __fracthqsi: Fixed-point fractional library routines.
+ (line 510)
+* __fracthqsq2: Fixed-point fractional library routines.
+ (line 494)
+* __fracthqta: Fixed-point fractional library routines.
+ (line 499)
+* __fracthqti: Fixed-point fractional library routines.
+ (line 512)
+* __fracthquda: Fixed-point fractional library routines.
+ (line 506)
+* __fracthqudq: Fixed-point fractional library routines.
+ (line 503)
+* __fracthquha: Fixed-point fractional library routines.
+ (line 504)
+* __fracthquhq: Fixed-point fractional library routines.
+ (line 501)
+* __fracthquqq: Fixed-point fractional library routines.
+ (line 500)
+* __fracthqusa: Fixed-point fractional library routines.
+ (line 505)
+* __fracthqusq: Fixed-point fractional library routines.
+ (line 502)
+* __fracthquta: Fixed-point fractional library routines.
+ (line 507)
+* __fractqida: Fixed-point fractional library routines.
+ (line 925)
+* __fractqidq: Fixed-point fractional library routines.
+ (line 922)
+* __fractqiha: Fixed-point fractional library routines.
+ (line 923)
+* __fractqihq: Fixed-point fractional library routines.
+ (line 920)
+* __fractqiqq: Fixed-point fractional library routines.
+ (line 919)
+* __fractqisa: Fixed-point fractional library routines.
+ (line 924)
+* __fractqisq: Fixed-point fractional library routines.
+ (line 921)
+* __fractqita: Fixed-point fractional library routines.
+ (line 926)
+* __fractqiuda: Fixed-point fractional library routines.
+ (line 934)
+* __fractqiudq: Fixed-point fractional library routines.
+ (line 931)
+* __fractqiuha: Fixed-point fractional library routines.
+ (line 932)
+* __fractqiuhq: Fixed-point fractional library routines.
+ (line 928)
+* __fractqiuqq: Fixed-point fractional library routines.
+ (line 927)
+* __fractqiusa: Fixed-point fractional library routines.
+ (line 933)
+* __fractqiusq: Fixed-point fractional library routines.
+ (line 929)
+* __fractqiuta: Fixed-point fractional library routines.
+ (line 936)
+* __fractqqda: Fixed-point fractional library routines.
+ (line 474)
+* __fractqqdf: Fixed-point fractional library routines.
+ (line 492)
+* __fractqqdi: Fixed-point fractional library routines.
+ (line 489)
+* __fractqqdq2: Fixed-point fractional library routines.
+ (line 471)
+* __fractqqha: Fixed-point fractional library routines.
+ (line 472)
+* __fractqqhi: Fixed-point fractional library routines.
+ (line 487)
+* __fractqqhq2: Fixed-point fractional library routines.
+ (line 469)
+* __fractqqqi: Fixed-point fractional library routines.
+ (line 486)
+* __fractqqsa: Fixed-point fractional library routines.
+ (line 473)
+* __fractqqsf: Fixed-point fractional library routines.
+ (line 491)
+* __fractqqsi: Fixed-point fractional library routines.
+ (line 488)
+* __fractqqsq2: Fixed-point fractional library routines.
+ (line 470)
+* __fractqqta: Fixed-point fractional library routines.
+ (line 475)
+* __fractqqti: Fixed-point fractional library routines.
+ (line 490)
+* __fractqquda: Fixed-point fractional library routines.
+ (line 483)
+* __fractqqudq: Fixed-point fractional library routines.
+ (line 480)
+* __fractqquha: Fixed-point fractional library routines.
+ (line 481)
+* __fractqquhq: Fixed-point fractional library routines.
+ (line 477)
+* __fractqquqq: Fixed-point fractional library routines.
+ (line 476)
+* __fractqqusa: Fixed-point fractional library routines.
+ (line 482)
+* __fractqqusq: Fixed-point fractional library routines.
+ (line 478)
+* __fractqquta: Fixed-point fractional library routines.
+ (line 485)
+* __fractsada2: Fixed-point fractional library routines.
+ (line 596)
+* __fractsadf: Fixed-point fractional library routines.
+ (line 612)
+* __fractsadi: Fixed-point fractional library routines.
+ (line 609)
+* __fractsadq: Fixed-point fractional library routines.
+ (line 594)
+* __fractsaha2: Fixed-point fractional library routines.
+ (line 595)
+* __fractsahi: Fixed-point fractional library routines.
+ (line 607)
+* __fractsahq: Fixed-point fractional library routines.
+ (line 592)
+* __fractsaqi: Fixed-point fractional library routines.
+ (line 606)
+* __fractsaqq: Fixed-point fractional library routines.
+ (line 591)
+* __fractsasf: Fixed-point fractional library routines.
+ (line 611)
+* __fractsasi: Fixed-point fractional library routines.
+ (line 608)
+* __fractsasq: Fixed-point fractional library routines.
+ (line 593)
+* __fractsata2: Fixed-point fractional library routines.
+ (line 597)
+* __fractsati: Fixed-point fractional library routines.
+ (line 610)
+* __fractsauda: Fixed-point fractional library routines.
+ (line 604)
+* __fractsaudq: Fixed-point fractional library routines.
+ (line 601)
+* __fractsauha: Fixed-point fractional library routines.
+ (line 602)
+* __fractsauhq: Fixed-point fractional library routines.
+ (line 599)
+* __fractsauqq: Fixed-point fractional library routines.
+ (line 598)
+* __fractsausa: Fixed-point fractional library routines.
+ (line 603)
+* __fractsausq: Fixed-point fractional library routines.
+ (line 600)
+* __fractsauta: Fixed-point fractional library routines.
+ (line 605)
+* __fractsfda: Fixed-point fractional library routines.
+ (line 1009)
+* __fractsfdq: Fixed-point fractional library routines.
+ (line 1006)
+* __fractsfha: Fixed-point fractional library routines.
+ (line 1007)
+* __fractsfhq: Fixed-point fractional library routines.
+ (line 1004)
+* __fractsfqq: Fixed-point fractional library routines.
+ (line 1003)
+* __fractsfsa: Fixed-point fractional library routines.
+ (line 1008)
+* __fractsfsq: Fixed-point fractional library routines.
+ (line 1005)
+* __fractsfta: Fixed-point fractional library routines.
+ (line 1010)
+* __fractsfuda: Fixed-point fractional library routines.
+ (line 1017)
+* __fractsfudq: Fixed-point fractional library routines.
+ (line 1014)
+* __fractsfuha: Fixed-point fractional library routines.
+ (line 1015)
+* __fractsfuhq: Fixed-point fractional library routines.
+ (line 1012)
+* __fractsfuqq: Fixed-point fractional library routines.
+ (line 1011)
+* __fractsfusa: Fixed-point fractional library routines.
+ (line 1016)
+* __fractsfusq: Fixed-point fractional library routines.
+ (line 1013)
+* __fractsfuta: Fixed-point fractional library routines.
+ (line 1018)
+* __fractsida: Fixed-point fractional library routines.
+ (line 959)
+* __fractsidq: Fixed-point fractional library routines.
+ (line 956)
+* __fractsiha: Fixed-point fractional library routines.
+ (line 957)
+* __fractsihq: Fixed-point fractional library routines.
+ (line 954)
+* __fractsiqq: Fixed-point fractional library routines.
+ (line 953)
+* __fractsisa: Fixed-point fractional library routines.
+ (line 958)
+* __fractsisq: Fixed-point fractional library routines.
+ (line 955)
+* __fractsita: Fixed-point fractional library routines.
+ (line 960)
+* __fractsiuda: Fixed-point fractional library routines.
+ (line 967)
+* __fractsiudq: Fixed-point fractional library routines.
+ (line 964)
+* __fractsiuha: Fixed-point fractional library routines.
+ (line 965)
+* __fractsiuhq: Fixed-point fractional library routines.
+ (line 962)
+* __fractsiuqq: Fixed-point fractional library routines.
+ (line 961)
+* __fractsiusa: Fixed-point fractional library routines.
+ (line 966)
+* __fractsiusq: Fixed-point fractional library routines.
+ (line 963)
+* __fractsiuta: Fixed-point fractional library routines.
+ (line 968)
+* __fractsqda: Fixed-point fractional library routines.
+ (line 520)
+* __fractsqdf: Fixed-point fractional library routines.
+ (line 538)
+* __fractsqdi: Fixed-point fractional library routines.
+ (line 535)
+* __fractsqdq2: Fixed-point fractional library routines.
+ (line 517)
+* __fractsqha: Fixed-point fractional library routines.
+ (line 518)
+* __fractsqhi: Fixed-point fractional library routines.
+ (line 533)
+* __fractsqhq2: Fixed-point fractional library routines.
+ (line 516)
+* __fractsqqi: Fixed-point fractional library routines.
+ (line 532)
+* __fractsqqq2: Fixed-point fractional library routines.
+ (line 515)
+* __fractsqsa: Fixed-point fractional library routines.
+ (line 519)
+* __fractsqsf: Fixed-point fractional library routines.
+ (line 537)
+* __fractsqsi: Fixed-point fractional library routines.
+ (line 534)
+* __fractsqta: Fixed-point fractional library routines.
+ (line 521)
+* __fractsqti: Fixed-point fractional library routines.
+ (line 536)
+* __fractsquda: Fixed-point fractional library routines.
+ (line 529)
+* __fractsqudq: Fixed-point fractional library routines.
+ (line 526)
+* __fractsquha: Fixed-point fractional library routines.
+ (line 527)
+* __fractsquhq: Fixed-point fractional library routines.
+ (line 523)
+* __fractsquqq: Fixed-point fractional library routines.
+ (line 522)
+* __fractsqusa: Fixed-point fractional library routines.
+ (line 528)
+* __fractsqusq: Fixed-point fractional library routines.
+ (line 524)
+* __fractsquta: Fixed-point fractional library routines.
+ (line 531)
+* __fracttada2: Fixed-point fractional library routines.
+ (line 643)
+* __fracttadf: Fixed-point fractional library routines.
+ (line 664)
+* __fracttadi: Fixed-point fractional library routines.
+ (line 661)
+* __fracttadq: Fixed-point fractional library routines.
+ (line 640)
+* __fracttaha2: Fixed-point fractional library routines.
+ (line 641)
+* __fracttahi: Fixed-point fractional library routines.
+ (line 659)
+* __fracttahq: Fixed-point fractional library routines.
+ (line 638)
+* __fracttaqi: Fixed-point fractional library routines.
+ (line 658)
+* __fracttaqq: Fixed-point fractional library routines.
+ (line 637)
+* __fracttasa2: Fixed-point fractional library routines.
+ (line 642)
+* __fracttasf: Fixed-point fractional library routines.
+ (line 663)
+* __fracttasi: Fixed-point fractional library routines.
+ (line 660)
+* __fracttasq: Fixed-point fractional library routines.
+ (line 639)
+* __fracttati: Fixed-point fractional library routines.
+ (line 662)
+* __fracttauda: Fixed-point fractional library routines.
+ (line 655)
+* __fracttaudq: Fixed-point fractional library routines.
+ (line 650)
+* __fracttauha: Fixed-point fractional library routines.
+ (line 652)
+* __fracttauhq: Fixed-point fractional library routines.
+ (line 646)
+* __fracttauqq: Fixed-point fractional library routines.
+ (line 645)
+* __fracttausa: Fixed-point fractional library routines.
+ (line 653)
+* __fracttausq: Fixed-point fractional library routines.
+ (line 648)
+* __fracttauta: Fixed-point fractional library routines.
+ (line 657)
+* __fracttida: Fixed-point fractional library routines.
+ (line 991)
+* __fracttidq: Fixed-point fractional library routines.
+ (line 988)
+* __fracttiha: Fixed-point fractional library routines.
+ (line 989)
+* __fracttihq: Fixed-point fractional library routines.
+ (line 986)
+* __fracttiqq: Fixed-point fractional library routines.
+ (line 985)
+* __fracttisa: Fixed-point fractional library routines.
+ (line 990)
+* __fracttisq: Fixed-point fractional library routines.
+ (line 987)
+* __fracttita: Fixed-point fractional library routines.
+ (line 992)
+* __fracttiuda: Fixed-point fractional library routines.
+ (line 1000)
+* __fracttiudq: Fixed-point fractional library routines.
+ (line 997)
+* __fracttiuha: Fixed-point fractional library routines.
+ (line 998)
+* __fracttiuhq: Fixed-point fractional library routines.
+ (line 994)
+* __fracttiuqq: Fixed-point fractional library routines.
+ (line 993)
+* __fracttiusa: Fixed-point fractional library routines.
+ (line 999)
+* __fracttiusq: Fixed-point fractional library routines.
+ (line 995)
+* __fracttiuta: Fixed-point fractional library routines.
+ (line 1002)
+* __fractudada: Fixed-point fractional library routines.
+ (line 858)
+* __fractudadf: Fixed-point fractional library routines.
+ (line 881)
+* __fractudadi: Fixed-point fractional library routines.
+ (line 878)
+* __fractudadq: Fixed-point fractional library routines.
+ (line 855)
+* __fractudaha: Fixed-point fractional library routines.
+ (line 856)
+* __fractudahi: Fixed-point fractional library routines.
+ (line 876)
+* __fractudahq: Fixed-point fractional library routines.
+ (line 852)
+* __fractudaqi: Fixed-point fractional library routines.
+ (line 875)
+* __fractudaqq: Fixed-point fractional library routines.
+ (line 851)
+* __fractudasa: Fixed-point fractional library routines.
+ (line 857)
+* __fractudasf: Fixed-point fractional library routines.
+ (line 880)
+* __fractudasi: Fixed-point fractional library routines.
+ (line 877)
+* __fractudasq: Fixed-point fractional library routines.
+ (line 853)
+* __fractudata: Fixed-point fractional library routines.
+ (line 860)
+* __fractudati: Fixed-point fractional library routines.
+ (line 879)
+* __fractudaudq: Fixed-point fractional library routines.
+ (line 868)
+* __fractudauha2: Fixed-point fractional library routines.
+ (line 870)
+* __fractudauhq: Fixed-point fractional library routines.
+ (line 864)
+* __fractudauqq: Fixed-point fractional library routines.
+ (line 862)
+* __fractudausa2: Fixed-point fractional library routines.
+ (line 872)
+* __fractudausq: Fixed-point fractional library routines.
+ (line 866)
+* __fractudauta2: Fixed-point fractional library routines.
+ (line 874)
+* __fractudqda: Fixed-point fractional library routines.
+ (line 766)
+* __fractudqdf: Fixed-point fractional library routines.
+ (line 791)
+* __fractudqdi: Fixed-point fractional library routines.
+ (line 787)
+* __fractudqdq: Fixed-point fractional library routines.
+ (line 761)
+* __fractudqha: Fixed-point fractional library routines.
+ (line 763)
+* __fractudqhi: Fixed-point fractional library routines.
+ (line 785)
+* __fractudqhq: Fixed-point fractional library routines.
+ (line 757)
+* __fractudqqi: Fixed-point fractional library routines.
+ (line 784)
+* __fractudqqq: Fixed-point fractional library routines.
+ (line 756)
+* __fractudqsa: Fixed-point fractional library routines.
+ (line 764)
+* __fractudqsf: Fixed-point fractional library routines.
+ (line 790)
+* __fractudqsi: Fixed-point fractional library routines.
+ (line 786)
+* __fractudqsq: Fixed-point fractional library routines.
+ (line 759)
+* __fractudqta: Fixed-point fractional library routines.
+ (line 768)
+* __fractudqti: Fixed-point fractional library routines.
+ (line 789)
+* __fractudquda: Fixed-point fractional library routines.
+ (line 780)
+* __fractudquha: Fixed-point fractional library routines.
+ (line 776)
+* __fractudquhq2: Fixed-point fractional library routines.
+ (line 772)
+* __fractudquqq2: Fixed-point fractional library routines.
+ (line 770)
+* __fractudqusa: Fixed-point fractional library routines.
+ (line 778)
+* __fractudqusq2: Fixed-point fractional library routines.
+ (line 774)
+* __fractudquta: Fixed-point fractional library routines.
+ (line 782)
+* __fractuhada: Fixed-point fractional library routines.
+ (line 799)
+* __fractuhadf: Fixed-point fractional library routines.
+ (line 822)
+* __fractuhadi: Fixed-point fractional library routines.
+ (line 819)
+* __fractuhadq: Fixed-point fractional library routines.
+ (line 796)
+* __fractuhaha: Fixed-point fractional library routines.
+ (line 797)
+* __fractuhahi: Fixed-point fractional library routines.
+ (line 817)
+* __fractuhahq: Fixed-point fractional library routines.
+ (line 793)
+* __fractuhaqi: Fixed-point fractional library routines.
+ (line 816)
+* __fractuhaqq: Fixed-point fractional library routines.
+ (line 792)
+* __fractuhasa: Fixed-point fractional library routines.
+ (line 798)
+* __fractuhasf: Fixed-point fractional library routines.
+ (line 821)
+* __fractuhasi: Fixed-point fractional library routines.
+ (line 818)
+* __fractuhasq: Fixed-point fractional library routines.
+ (line 794)
+* __fractuhata: Fixed-point fractional library routines.
+ (line 801)
+* __fractuhati: Fixed-point fractional library routines.
+ (line 820)
+* __fractuhauda2: Fixed-point fractional library routines.
+ (line 813)
+* __fractuhaudq: Fixed-point fractional library routines.
+ (line 809)
+* __fractuhauhq: Fixed-point fractional library routines.
+ (line 805)
+* __fractuhauqq: Fixed-point fractional library routines.
+ (line 803)
+* __fractuhausa2: Fixed-point fractional library routines.
+ (line 811)
+* __fractuhausq: Fixed-point fractional library routines.
+ (line 807)
+* __fractuhauta2: Fixed-point fractional library routines.
+ (line 815)
+* __fractuhqda: Fixed-point fractional library routines.
+ (line 702)
+* __fractuhqdf: Fixed-point fractional library routines.
+ (line 723)
+* __fractuhqdi: Fixed-point fractional library routines.
+ (line 720)
+* __fractuhqdq: Fixed-point fractional library routines.
+ (line 699)
+* __fractuhqha: Fixed-point fractional library routines.
+ (line 700)
+* __fractuhqhi: Fixed-point fractional library routines.
+ (line 718)
+* __fractuhqhq: Fixed-point fractional library routines.
+ (line 697)
+* __fractuhqqi: Fixed-point fractional library routines.
+ (line 717)
+* __fractuhqqq: Fixed-point fractional library routines.
+ (line 696)
+* __fractuhqsa: Fixed-point fractional library routines.
+ (line 701)
+* __fractuhqsf: Fixed-point fractional library routines.
+ (line 722)
+* __fractuhqsi: Fixed-point fractional library routines.
+ (line 719)
+* __fractuhqsq: Fixed-point fractional library routines.
+ (line 698)
+* __fractuhqta: Fixed-point fractional library routines.
+ (line 703)
+* __fractuhqti: Fixed-point fractional library routines.
+ (line 721)
+* __fractuhquda: Fixed-point fractional library routines.
+ (line 714)
+* __fractuhqudq2: Fixed-point fractional library routines.
+ (line 709)
+* __fractuhquha: Fixed-point fractional library routines.
+ (line 711)
+* __fractuhquqq2: Fixed-point fractional library routines.
+ (line 705)
+* __fractuhqusa: Fixed-point fractional library routines.
+ (line 712)
+* __fractuhqusq2: Fixed-point fractional library routines.
+ (line 707)
+* __fractuhquta: Fixed-point fractional library routines.
+ (line 716)
+* __fractunsdadi: Fixed-point fractional library routines.
+ (line 1555)
+* __fractunsdahi: Fixed-point fractional library routines.
+ (line 1553)
+* __fractunsdaqi: Fixed-point fractional library routines.
+ (line 1552)
+* __fractunsdasi: Fixed-point fractional library routines.
+ (line 1554)
+* __fractunsdati: Fixed-point fractional library routines.
+ (line 1556)
+* __fractunsdida: Fixed-point fractional library routines.
+ (line 1707)
+* __fractunsdidq: Fixed-point fractional library routines.
+ (line 1704)
+* __fractunsdiha: Fixed-point fractional library routines.
+ (line 1705)
+* __fractunsdihq: Fixed-point fractional library routines.
+ (line 1702)
+* __fractunsdiqq: Fixed-point fractional library routines.
+ (line 1701)
+* __fractunsdisa: Fixed-point fractional library routines.
+ (line 1706)
+* __fractunsdisq: Fixed-point fractional library routines.
+ (line 1703)
+* __fractunsdita: Fixed-point fractional library routines.
+ (line 1708)
+* __fractunsdiuda: Fixed-point fractional library routines.
+ (line 1720)
+* __fractunsdiudq: Fixed-point fractional library routines.
+ (line 1715)
+* __fractunsdiuha: Fixed-point fractional library routines.
+ (line 1717)
+* __fractunsdiuhq: Fixed-point fractional library routines.
+ (line 1711)
+* __fractunsdiuqq: Fixed-point fractional library routines.
+ (line 1710)
+* __fractunsdiusa: Fixed-point fractional library routines.
+ (line 1718)
+* __fractunsdiusq: Fixed-point fractional library routines.
+ (line 1713)
+* __fractunsdiuta: Fixed-point fractional library routines.
+ (line 1722)
+* __fractunsdqdi: Fixed-point fractional library routines.
+ (line 1539)
+* __fractunsdqhi: Fixed-point fractional library routines.
+ (line 1537)
+* __fractunsdqqi: Fixed-point fractional library routines.
+ (line 1536)
+* __fractunsdqsi: Fixed-point fractional library routines.
+ (line 1538)
+* __fractunsdqti: Fixed-point fractional library routines.
+ (line 1541)
+* __fractunshadi: Fixed-point fractional library routines.
+ (line 1545)
+* __fractunshahi: Fixed-point fractional library routines.
+ (line 1543)
+* __fractunshaqi: Fixed-point fractional library routines.
+ (line 1542)
+* __fractunshasi: Fixed-point fractional library routines.
+ (line 1544)
+* __fractunshati: Fixed-point fractional library routines.
+ (line 1546)
+* __fractunshida: Fixed-point fractional library routines.
+ (line 1663)
+* __fractunshidq: Fixed-point fractional library routines.
+ (line 1660)
+* __fractunshiha: Fixed-point fractional library routines.
+ (line 1661)
+* __fractunshihq: Fixed-point fractional library routines.
+ (line 1658)
+* __fractunshiqq: Fixed-point fractional library routines.
+ (line 1657)
+* __fractunshisa: Fixed-point fractional library routines.
+ (line 1662)
+* __fractunshisq: Fixed-point fractional library routines.
+ (line 1659)
+* __fractunshita: Fixed-point fractional library routines.
+ (line 1664)
+* __fractunshiuda: Fixed-point fractional library routines.
+ (line 1676)
+* __fractunshiudq: Fixed-point fractional library routines.
+ (line 1671)
+* __fractunshiuha: Fixed-point fractional library routines.
+ (line 1673)
+* __fractunshiuhq: Fixed-point fractional library routines.
+ (line 1667)
+* __fractunshiuqq: Fixed-point fractional library routines.
+ (line 1666)
+* __fractunshiusa: Fixed-point fractional library routines.
+ (line 1674)
+* __fractunshiusq: Fixed-point fractional library routines.
+ (line 1669)
+* __fractunshiuta: Fixed-point fractional library routines.
+ (line 1678)
+* __fractunshqdi: Fixed-point fractional library routines.
+ (line 1529)
+* __fractunshqhi: Fixed-point fractional library routines.
+ (line 1527)
+* __fractunshqqi: Fixed-point fractional library routines.
+ (line 1526)
+* __fractunshqsi: Fixed-point fractional library routines.
+ (line 1528)
+* __fractunshqti: Fixed-point fractional library routines.
+ (line 1530)
+* __fractunsqida: Fixed-point fractional library routines.
+ (line 1641)
+* __fractunsqidq: Fixed-point fractional library routines.
+ (line 1638)
+* __fractunsqiha: Fixed-point fractional library routines.
+ (line 1639)
+* __fractunsqihq: Fixed-point fractional library routines.
+ (line 1636)
+* __fractunsqiqq: Fixed-point fractional library routines.
+ (line 1635)
+* __fractunsqisa: Fixed-point fractional library routines.
+ (line 1640)
+* __fractunsqisq: Fixed-point fractional library routines.
+ (line 1637)
+* __fractunsqita: Fixed-point fractional library routines.
+ (line 1642)
+* __fractunsqiuda: Fixed-point fractional library routines.
+ (line 1654)
+* __fractunsqiudq: Fixed-point fractional library routines.
+ (line 1649)
+* __fractunsqiuha: Fixed-point fractional library routines.
+ (line 1651)
+* __fractunsqiuhq: Fixed-point fractional library routines.
+ (line 1645)
+* __fractunsqiuqq: Fixed-point fractional library routines.
+ (line 1644)
+* __fractunsqiusa: Fixed-point fractional library routines.
+ (line 1652)
+* __fractunsqiusq: Fixed-point fractional library routines.
+ (line 1647)
+* __fractunsqiuta: Fixed-point fractional library routines.
+ (line 1656)
+* __fractunsqqdi: Fixed-point fractional library routines.
+ (line 1524)
+* __fractunsqqhi: Fixed-point fractional library routines.
+ (line 1522)
+* __fractunsqqqi: Fixed-point fractional library routines.
+ (line 1521)
+* __fractunsqqsi: Fixed-point fractional library routines.
+ (line 1523)
+* __fractunsqqti: Fixed-point fractional library routines.
+ (line 1525)
+* __fractunssadi: Fixed-point fractional library routines.
+ (line 1550)
+* __fractunssahi: Fixed-point fractional library routines.
+ (line 1548)
+* __fractunssaqi: Fixed-point fractional library routines.
+ (line 1547)
+* __fractunssasi: Fixed-point fractional library routines.
+ (line 1549)
+* __fractunssati: Fixed-point fractional library routines.
+ (line 1551)
+* __fractunssida: Fixed-point fractional library routines.
+ (line 1685)
+* __fractunssidq: Fixed-point fractional library routines.
+ (line 1682)
+* __fractunssiha: Fixed-point fractional library routines.
+ (line 1683)
+* __fractunssihq: Fixed-point fractional library routines.
+ (line 1680)
+* __fractunssiqq: Fixed-point fractional library routines.
+ (line 1679)
+* __fractunssisa: Fixed-point fractional library routines.
+ (line 1684)
+* __fractunssisq: Fixed-point fractional library routines.
+ (line 1681)
+* __fractunssita: Fixed-point fractional library routines.
+ (line 1686)
+* __fractunssiuda: Fixed-point fractional library routines.
+ (line 1698)
+* __fractunssiudq: Fixed-point fractional library routines.
+ (line 1693)
+* __fractunssiuha: Fixed-point fractional library routines.
+ (line 1695)
+* __fractunssiuhq: Fixed-point fractional library routines.
+ (line 1689)
+* __fractunssiuqq: Fixed-point fractional library routines.
+ (line 1688)
+* __fractunssiusa: Fixed-point fractional library routines.
+ (line 1696)
+* __fractunssiusq: Fixed-point fractional library routines.
+ (line 1691)
+* __fractunssiuta: Fixed-point fractional library routines.
+ (line 1700)
+* __fractunssqdi: Fixed-point fractional library routines.
+ (line 1534)
+* __fractunssqhi: Fixed-point fractional library routines.
+ (line 1532)
+* __fractunssqqi: Fixed-point fractional library routines.
+ (line 1531)
+* __fractunssqsi: Fixed-point fractional library routines.
+ (line 1533)
+* __fractunssqti: Fixed-point fractional library routines.
+ (line 1535)
+* __fractunstadi: Fixed-point fractional library routines.
+ (line 1560)
+* __fractunstahi: Fixed-point fractional library routines.
+ (line 1558)
+* __fractunstaqi: Fixed-point fractional library routines.
+ (line 1557)
+* __fractunstasi: Fixed-point fractional library routines.
+ (line 1559)
+* __fractunstati: Fixed-point fractional library routines.
+ (line 1562)
+* __fractunstida: Fixed-point fractional library routines.
+ (line 1730)
+* __fractunstidq: Fixed-point fractional library routines.
+ (line 1727)
+* __fractunstiha: Fixed-point fractional library routines.
+ (line 1728)
+* __fractunstihq: Fixed-point fractional library routines.
+ (line 1724)
+* __fractunstiqq: Fixed-point fractional library routines.
+ (line 1723)
+* __fractunstisa: Fixed-point fractional library routines.
+ (line 1729)
+* __fractunstisq: Fixed-point fractional library routines.
+ (line 1725)
+* __fractunstita: Fixed-point fractional library routines.
+ (line 1732)
+* __fractunstiuda: Fixed-point fractional library routines.
+ (line 1746)
+* __fractunstiudq: Fixed-point fractional library routines.
+ (line 1740)
+* __fractunstiuha: Fixed-point fractional library routines.
+ (line 1742)
+* __fractunstiuhq: Fixed-point fractional library routines.
+ (line 1736)
+* __fractunstiuqq: Fixed-point fractional library routines.
+ (line 1734)
+* __fractunstiusa: Fixed-point fractional library routines.
+ (line 1744)
+* __fractunstiusq: Fixed-point fractional library routines.
+ (line 1738)
+* __fractunstiuta: Fixed-point fractional library routines.
+ (line 1748)
+* __fractunsudadi: Fixed-point fractional library routines.
+ (line 1622)
+* __fractunsudahi: Fixed-point fractional library routines.
+ (line 1618)
+* __fractunsudaqi: Fixed-point fractional library routines.
+ (line 1616)
+* __fractunsudasi: Fixed-point fractional library routines.
+ (line 1620)
+* __fractunsudati: Fixed-point fractional library routines.
+ (line 1624)
+* __fractunsudqdi: Fixed-point fractional library routines.
+ (line 1596)
+* __fractunsudqhi: Fixed-point fractional library routines.
+ (line 1592)
+* __fractunsudqqi: Fixed-point fractional library routines.
+ (line 1590)
+* __fractunsudqsi: Fixed-point fractional library routines.
+ (line 1594)
+* __fractunsudqti: Fixed-point fractional library routines.
+ (line 1598)
+* __fractunsuhadi: Fixed-point fractional library routines.
+ (line 1606)
+* __fractunsuhahi: Fixed-point fractional library routines.
+ (line 1602)
+* __fractunsuhaqi: Fixed-point fractional library routines.
+ (line 1600)
+* __fractunsuhasi: Fixed-point fractional library routines.
+ (line 1604)
+* __fractunsuhati: Fixed-point fractional library routines.
+ (line 1608)
+* __fractunsuhqdi: Fixed-point fractional library routines.
+ (line 1576)
+* __fractunsuhqhi: Fixed-point fractional library routines.
+ (line 1574)
+* __fractunsuhqqi: Fixed-point fractional library routines.
+ (line 1573)
+* __fractunsuhqsi: Fixed-point fractional library routines.
+ (line 1575)
+* __fractunsuhqti: Fixed-point fractional library routines.
+ (line 1578)
+* __fractunsuqqdi: Fixed-point fractional library routines.
+ (line 1570)
+* __fractunsuqqhi: Fixed-point fractional library routines.
+ (line 1566)
+* __fractunsuqqqi: Fixed-point fractional library routines.
+ (line 1564)
+* __fractunsuqqsi: Fixed-point fractional library routines.
+ (line 1568)
+* __fractunsuqqti: Fixed-point fractional library routines.
+ (line 1572)
+* __fractunsusadi: Fixed-point fractional library routines.
+ (line 1612)
+* __fractunsusahi: Fixed-point fractional library routines.
+ (line 1610)
+* __fractunsusaqi: Fixed-point fractional library routines.
+ (line 1609)
+* __fractunsusasi: Fixed-point fractional library routines.
+ (line 1611)
+* __fractunsusati: Fixed-point fractional library routines.
+ (line 1614)
+* __fractunsusqdi: Fixed-point fractional library routines.
+ (line 1586)
+* __fractunsusqhi: Fixed-point fractional library routines.
+ (line 1582)
+* __fractunsusqqi: Fixed-point fractional library routines.
+ (line 1580)
+* __fractunsusqsi: Fixed-point fractional library routines.
+ (line 1584)
+* __fractunsusqti: Fixed-point fractional library routines.
+ (line 1588)
+* __fractunsutadi: Fixed-point fractional library routines.
+ (line 1632)
+* __fractunsutahi: Fixed-point fractional library routines.
+ (line 1628)
+* __fractunsutaqi: Fixed-point fractional library routines.
+ (line 1626)
+* __fractunsutasi: Fixed-point fractional library routines.
+ (line 1630)
+* __fractunsutati: Fixed-point fractional library routines.
+ (line 1634)
+* __fractuqqda: Fixed-point fractional library routines.
+ (line 672)
+* __fractuqqdf: Fixed-point fractional library routines.
+ (line 695)
+* __fractuqqdi: Fixed-point fractional library routines.
+ (line 692)
+* __fractuqqdq: Fixed-point fractional library routines.
+ (line 669)
+* __fractuqqha: Fixed-point fractional library routines.
+ (line 670)
+* __fractuqqhi: Fixed-point fractional library routines.
+ (line 690)
+* __fractuqqhq: Fixed-point fractional library routines.
+ (line 666)
+* __fractuqqqi: Fixed-point fractional library routines.
+ (line 689)
+* __fractuqqqq: Fixed-point fractional library routines.
+ (line 665)
+* __fractuqqsa: Fixed-point fractional library routines.
+ (line 671)
+* __fractuqqsf: Fixed-point fractional library routines.
+ (line 694)
+* __fractuqqsi: Fixed-point fractional library routines.
+ (line 691)
+* __fractuqqsq: Fixed-point fractional library routines.
+ (line 667)
+* __fractuqqta: Fixed-point fractional library routines.
+ (line 674)
+* __fractuqqti: Fixed-point fractional library routines.
+ (line 693)
+* __fractuqquda: Fixed-point fractional library routines.
+ (line 686)
+* __fractuqqudq2: Fixed-point fractional library routines.
+ (line 680)
+* __fractuqquha: Fixed-point fractional library routines.
+ (line 682)
+* __fractuqquhq2: Fixed-point fractional library routines.
+ (line 676)
+* __fractuqqusa: Fixed-point fractional library routines.
+ (line 684)
+* __fractuqqusq2: Fixed-point fractional library routines.
+ (line 678)
+* __fractuqquta: Fixed-point fractional library routines.
+ (line 688)
+* __fractusada: Fixed-point fractional library routines.
+ (line 829)
+* __fractusadf: Fixed-point fractional library routines.
+ (line 850)
+* __fractusadi: Fixed-point fractional library routines.
+ (line 847)
+* __fractusadq: Fixed-point fractional library routines.
+ (line 826)
+* __fractusaha: Fixed-point fractional library routines.
+ (line 827)
+* __fractusahi: Fixed-point fractional library routines.
+ (line 845)
+* __fractusahq: Fixed-point fractional library routines.
+ (line 824)
+* __fractusaqi: Fixed-point fractional library routines.
+ (line 844)
+* __fractusaqq: Fixed-point fractional library routines.
+ (line 823)
+* __fractusasa: Fixed-point fractional library routines.
+ (line 828)
+* __fractusasf: Fixed-point fractional library routines.
+ (line 849)
+* __fractusasi: Fixed-point fractional library routines.
+ (line 846)
+* __fractusasq: Fixed-point fractional library routines.
+ (line 825)
+* __fractusata: Fixed-point fractional library routines.
+ (line 830)
+* __fractusati: Fixed-point fractional library routines.
+ (line 848)
+* __fractusauda2: Fixed-point fractional library routines.
+ (line 841)
+* __fractusaudq: Fixed-point fractional library routines.
+ (line 837)
+* __fractusauha2: Fixed-point fractional library routines.
+ (line 839)
+* __fractusauhq: Fixed-point fractional library routines.
+ (line 833)
+* __fractusauqq: Fixed-point fractional library routines.
+ (line 832)
+* __fractusausq: Fixed-point fractional library routines.
+ (line 835)
+* __fractusauta2: Fixed-point fractional library routines.
+ (line 843)
+* __fractusqda: Fixed-point fractional library routines.
+ (line 731)
+* __fractusqdf: Fixed-point fractional library routines.
+ (line 754)
+* __fractusqdi: Fixed-point fractional library routines.
+ (line 751)
+* __fractusqdq: Fixed-point fractional library routines.
+ (line 728)
+* __fractusqha: Fixed-point fractional library routines.
+ (line 729)
+* __fractusqhi: Fixed-point fractional library routines.
+ (line 749)
+* __fractusqhq: Fixed-point fractional library routines.
+ (line 725)
+* __fractusqqi: Fixed-point fractional library routines.
+ (line 748)
+* __fractusqqq: Fixed-point fractional library routines.
+ (line 724)
+* __fractusqsa: Fixed-point fractional library routines.
+ (line 730)
+* __fractusqsf: Fixed-point fractional library routines.
+ (line 753)
+* __fractusqsi: Fixed-point fractional library routines.
+ (line 750)
+* __fractusqsq: Fixed-point fractional library routines.
+ (line 726)
+* __fractusqta: Fixed-point fractional library routines.
+ (line 733)
+* __fractusqti: Fixed-point fractional library routines.
+ (line 752)
+* __fractusquda: Fixed-point fractional library routines.
+ (line 745)
+* __fractusqudq2: Fixed-point fractional library routines.
+ (line 739)
+* __fractusquha: Fixed-point fractional library routines.
+ (line 741)
+* __fractusquhq2: Fixed-point fractional library routines.
+ (line 737)
+* __fractusquqq2: Fixed-point fractional library routines.
+ (line 735)
+* __fractusqusa: Fixed-point fractional library routines.
+ (line 743)
+* __fractusquta: Fixed-point fractional library routines.
+ (line 747)
+* __fractutada: Fixed-point fractional library routines.
+ (line 893)
+* __fractutadf: Fixed-point fractional library routines.
+ (line 918)
+* __fractutadi: Fixed-point fractional library routines.
+ (line 914)
+* __fractutadq: Fixed-point fractional library routines.
+ (line 888)
+* __fractutaha: Fixed-point fractional library routines.
+ (line 890)
+* __fractutahi: Fixed-point fractional library routines.
+ (line 912)
+* __fractutahq: Fixed-point fractional library routines.
+ (line 884)
+* __fractutaqi: Fixed-point fractional library routines.
+ (line 911)
+* __fractutaqq: Fixed-point fractional library routines.
+ (line 883)
+* __fractutasa: Fixed-point fractional library routines.
+ (line 891)
+* __fractutasf: Fixed-point fractional library routines.
+ (line 917)
+* __fractutasi: Fixed-point fractional library routines.
+ (line 913)
+* __fractutasq: Fixed-point fractional library routines.
+ (line 886)
+* __fractutata: Fixed-point fractional library routines.
+ (line 895)
+* __fractutati: Fixed-point fractional library routines.
+ (line 916)
+* __fractutauda2: Fixed-point fractional library routines.
+ (line 909)
+* __fractutaudq: Fixed-point fractional library routines.
+ (line 903)
+* __fractutauha2: Fixed-point fractional library routines.
+ (line 905)
+* __fractutauhq: Fixed-point fractional library routines.
+ (line 899)
+* __fractutauqq: Fixed-point fractional library routines.
+ (line 897)
+* __fractutausa2: Fixed-point fractional library routines.
+ (line 907)
+* __fractutausq: Fixed-point fractional library routines.
+ (line 901)
+* __gedf2: Soft float library routines.
+ (line 206)
+* __gesf2: Soft float library routines.
+ (line 205)
+* __getf2: Soft float library routines.
+ (line 207)
+* __gtdf2: Soft float library routines.
+ (line 224)
+* __gtsf2: Soft float library routines.
+ (line 223)
+* __gttf2: Soft float library routines.
+ (line 225)
+* __ledf2: Soft float library routines.
+ (line 218)
+* __lesf2: Soft float library routines.
+ (line 217)
+* __letf2: Soft float library routines.
+ (line 219)
+* __lshrdi3: Integer library routines.
+ (line 31)
+* __lshrsi3: Integer library routines.
+ (line 30)
+* __lshrti3: Integer library routines.
+ (line 32)
+* __lshruda3: Fixed-point fractional library routines.
+ (line 390)
+* __lshrudq3: Fixed-point fractional library routines.
+ (line 384)
+* __lshruha3: Fixed-point fractional library routines.
+ (line 386)
+* __lshruhq3: Fixed-point fractional library routines.
+ (line 380)
+* __lshruqq3: Fixed-point fractional library routines.
+ (line 378)
+* __lshrusa3: Fixed-point fractional library routines.
+ (line 388)
+* __lshrusq3: Fixed-point fractional library routines.
+ (line 382)
+* __lshruta3: Fixed-point fractional library routines.
+ (line 392)
+* __ltdf2: Soft float library routines.
+ (line 212)
+* __ltsf2: Soft float library routines.
+ (line 211)
+* __lttf2: Soft float library routines.
+ (line 213)
+* __main: Collect2. (line 15)
+* __moddi3: Integer library routines.
+ (line 37)
+* __modsi3: Integer library routines.
+ (line 36)
+* __modti3: Integer library routines.
+ (line 38)
+* __mulda3: Fixed-point fractional library routines.
+ (line 171)
+* __muldc3: Soft float library routines.
+ (line 241)
+* __muldf3: Soft float library routines.
+ (line 40)
+* __muldi3: Integer library routines.
+ (line 43)
+* __muldq3: Fixed-point fractional library routines.
+ (line 159)
+* __mulha3: Fixed-point fractional library routines.
+ (line 169)
+* __mulhq3: Fixed-point fractional library routines.
+ (line 156)
+* __mulqq3: Fixed-point fractional library routines.
+ (line 155)
+* __mulsa3: Fixed-point fractional library routines.
+ (line 170)
+* __mulsc3: Soft float library routines.
+ (line 239)
+* __mulsf3: Soft float library routines.
+ (line 39)
+* __mulsi3: Integer library routines.
+ (line 42)
+* __mulsq3: Fixed-point fractional library routines.
+ (line 157)
+* __multa3: Fixed-point fractional library routines.
+ (line 173)
+* __multc3: Soft float library routines.
+ (line 243)
+* __multf3: Soft float library routines.
+ (line 42)
+* __multi3: Integer library routines.
+ (line 44)
+* __muluda3: Fixed-point fractional library routines.
+ (line 179)
+* __muludq3: Fixed-point fractional library routines.
+ (line 167)
+* __muluha3: Fixed-point fractional library routines.
+ (line 175)
+* __muluhq3: Fixed-point fractional library routines.
+ (line 163)
+* __muluqq3: Fixed-point fractional library routines.
+ (line 161)
+* __mulusa3: Fixed-point fractional library routines.
+ (line 177)
+* __mulusq3: Fixed-point fractional library routines.
+ (line 165)
+* __muluta3: Fixed-point fractional library routines.
+ (line 181)
+* __mulvdi3: Integer library routines.
+ (line 115)
+* __mulvsi3: Integer library routines.
+ (line 114)
+* __mulxc3: Soft float library routines.
+ (line 245)
+* __mulxf3: Soft float library routines.
+ (line 44)
+* __nedf2: Soft float library routines.
+ (line 200)
+* __negda2: Fixed-point fractional library routines.
+ (line 299)
+* __negdf2: Soft float library routines.
+ (line 56)
+* __negdi2: Integer library routines.
+ (line 47)
+* __negdq2: Fixed-point fractional library routines.
+ (line 289)
+* __negha2: Fixed-point fractional library routines.
+ (line 297)
+* __neghq2: Fixed-point fractional library routines.
+ (line 287)
+* __negqq2: Fixed-point fractional library routines.
+ (line 286)
+* __negsa2: Fixed-point fractional library routines.
+ (line 298)
+* __negsf2: Soft float library routines.
+ (line 55)
+* __negsq2: Fixed-point fractional library routines.
+ (line 288)
+* __negta2: Fixed-point fractional library routines.
+ (line 300)
+* __negtf2: Soft float library routines.
+ (line 57)
+* __negti2: Integer library routines.
+ (line 48)
+* __neguda2: Fixed-point fractional library routines.
+ (line 305)
+* __negudq2: Fixed-point fractional library routines.
+ (line 296)
+* __neguha2: Fixed-point fractional library routines.
+ (line 302)
+* __neguhq2: Fixed-point fractional library routines.
+ (line 292)
+* __neguqq2: Fixed-point fractional library routines.
+ (line 291)
+* __negusa2: Fixed-point fractional library routines.
+ (line 303)
+* __negusq2: Fixed-point fractional library routines.
+ (line 294)
+* __neguta2: Fixed-point fractional library routines.
+ (line 307)
+* __negvdi2: Integer library routines.
+ (line 119)
+* __negvsi2: Integer library routines.
+ (line 118)
+* __negxf2: Soft float library routines.
+ (line 58)
+* __nesf2: Soft float library routines.
+ (line 199)
+* __netf2: Soft float library routines.
+ (line 201)
+* __paritydi2: Integer library routines.
+ (line 151)
+* __paritysi2: Integer library routines.
+ (line 150)
+* __parityti2: Integer library routines.
+ (line 152)
+* __popcountdi2: Integer library routines.
+ (line 157)
+* __popcountsi2: Integer library routines.
+ (line 156)
+* __popcountti2: Integer library routines.
+ (line 158)
+* __powidf2: Soft float library routines.
+ (line 233)
+* __powisf2: Soft float library routines.
+ (line 232)
+* __powitf2: Soft float library routines.
+ (line 234)
+* __powixf2: Soft float library routines.
+ (line 235)
+* __satfractdadq: Fixed-point fractional library routines.
+ (line 1153)
+* __satfractdaha2: Fixed-point fractional library routines.
+ (line 1154)
+* __satfractdahq: Fixed-point fractional library routines.
+ (line 1151)
+* __satfractdaqq: Fixed-point fractional library routines.
+ (line 1150)
+* __satfractdasa2: Fixed-point fractional library routines.
+ (line 1155)
+* __satfractdasq: Fixed-point fractional library routines.
+ (line 1152)
+* __satfractdata2: Fixed-point fractional library routines.
+ (line 1156)
+* __satfractdauda: Fixed-point fractional library routines.
+ (line 1166)
+* __satfractdaudq: Fixed-point fractional library routines.
+ (line 1162)
+* __satfractdauha: Fixed-point fractional library routines.
+ (line 1164)
+* __satfractdauhq: Fixed-point fractional library routines.
+ (line 1159)
+* __satfractdauqq: Fixed-point fractional library routines.
+ (line 1158)
+* __satfractdausa: Fixed-point fractional library routines.
+ (line 1165)
+* __satfractdausq: Fixed-point fractional library routines.
+ (line 1160)
+* __satfractdauta: Fixed-point fractional library routines.
+ (line 1168)
+* __satfractdfda: Fixed-point fractional library routines.
+ (line 1506)
+* __satfractdfdq: Fixed-point fractional library routines.
+ (line 1503)
+* __satfractdfha: Fixed-point fractional library routines.
+ (line 1504)
+* __satfractdfhq: Fixed-point fractional library routines.
+ (line 1501)
+* __satfractdfqq: Fixed-point fractional library routines.
+ (line 1500)
+* __satfractdfsa: Fixed-point fractional library routines.
+ (line 1505)
+* __satfractdfsq: Fixed-point fractional library routines.
+ (line 1502)
+* __satfractdfta: Fixed-point fractional library routines.
+ (line 1507)
+* __satfractdfuda: Fixed-point fractional library routines.
+ (line 1515)
+* __satfractdfudq: Fixed-point fractional library routines.
+ (line 1512)
+* __satfractdfuha: Fixed-point fractional library routines.
+ (line 1513)
+* __satfractdfuhq: Fixed-point fractional library routines.
+ (line 1509)
+* __satfractdfuqq: Fixed-point fractional library routines.
+ (line 1508)
+* __satfractdfusa: Fixed-point fractional library routines.
+ (line 1514)
+* __satfractdfusq: Fixed-point fractional library routines.
+ (line 1510)
+* __satfractdfuta: Fixed-point fractional library routines.
+ (line 1517)
+* __satfractdida: Fixed-point fractional library routines.
+ (line 1456)
+* __satfractdidq: Fixed-point fractional library routines.
+ (line 1453)
+* __satfractdiha: Fixed-point fractional library routines.
+ (line 1454)
+* __satfractdihq: Fixed-point fractional library routines.
+ (line 1451)
+* __satfractdiqq: Fixed-point fractional library routines.
+ (line 1450)
+* __satfractdisa: Fixed-point fractional library routines.
+ (line 1455)
+* __satfractdisq: Fixed-point fractional library routines.
+ (line 1452)
+* __satfractdita: Fixed-point fractional library routines.
+ (line 1457)
+* __satfractdiuda: Fixed-point fractional library routines.
+ (line 1464)
+* __satfractdiudq: Fixed-point fractional library routines.
+ (line 1461)
+* __satfractdiuha: Fixed-point fractional library routines.
+ (line 1462)
+* __satfractdiuhq: Fixed-point fractional library routines.
+ (line 1459)
+* __satfractdiuqq: Fixed-point fractional library routines.
+ (line 1458)
+* __satfractdiusa: Fixed-point fractional library routines.
+ (line 1463)
+* __satfractdiusq: Fixed-point fractional library routines.
+ (line 1460)
+* __satfractdiuta: Fixed-point fractional library routines.
+ (line 1465)
+* __satfractdqda: Fixed-point fractional library routines.
+ (line 1098)
+* __satfractdqha: Fixed-point fractional library routines.
+ (line 1096)
+* __satfractdqhq2: Fixed-point fractional library routines.
+ (line 1094)
+* __satfractdqqq2: Fixed-point fractional library routines.
+ (line 1093)
+* __satfractdqsa: Fixed-point fractional library routines.
+ (line 1097)
+* __satfractdqsq2: Fixed-point fractional library routines.
+ (line 1095)
+* __satfractdqta: Fixed-point fractional library routines.
+ (line 1099)
+* __satfractdquda: Fixed-point fractional library routines.
+ (line 1111)
+* __satfractdqudq: Fixed-point fractional library routines.
+ (line 1106)
+* __satfractdquha: Fixed-point fractional library routines.
+ (line 1108)
+* __satfractdquhq: Fixed-point fractional library routines.
+ (line 1102)
+* __satfractdquqq: Fixed-point fractional library routines.
+ (line 1101)
+* __satfractdqusa: Fixed-point fractional library routines.
+ (line 1109)
+* __satfractdqusq: Fixed-point fractional library routines.
+ (line 1104)
+* __satfractdquta: Fixed-point fractional library routines.
+ (line 1113)
+* __satfracthada2: Fixed-point fractional library routines.
+ (line 1119)
+* __satfracthadq: Fixed-point fractional library routines.
+ (line 1117)
+* __satfracthahq: Fixed-point fractional library routines.
+ (line 1115)
+* __satfracthaqq: Fixed-point fractional library routines.
+ (line 1114)
+* __satfracthasa2: Fixed-point fractional library routines.
+ (line 1118)
+* __satfracthasq: Fixed-point fractional library routines.
+ (line 1116)
+* __satfracthata2: Fixed-point fractional library routines.
+ (line 1120)
+* __satfracthauda: Fixed-point fractional library routines.
+ (line 1132)
+* __satfracthaudq: Fixed-point fractional library routines.
+ (line 1127)
+* __satfracthauha: Fixed-point fractional library routines.
+ (line 1129)
+* __satfracthauhq: Fixed-point fractional library routines.
+ (line 1123)
+* __satfracthauqq: Fixed-point fractional library routines.
+ (line 1122)
+* __satfracthausa: Fixed-point fractional library routines.
+ (line 1130)
+* __satfracthausq: Fixed-point fractional library routines.
+ (line 1125)
+* __satfracthauta: Fixed-point fractional library routines.
+ (line 1134)
+* __satfracthida: Fixed-point fractional library routines.
+ (line 1424)
+* __satfracthidq: Fixed-point fractional library routines.
+ (line 1421)
+* __satfracthiha: Fixed-point fractional library routines.
+ (line 1422)
+* __satfracthihq: Fixed-point fractional library routines.
+ (line 1419)
+* __satfracthiqq: Fixed-point fractional library routines.
+ (line 1418)
+* __satfracthisa: Fixed-point fractional library routines.
+ (line 1423)
+* __satfracthisq: Fixed-point fractional library routines.
+ (line 1420)
+* __satfracthita: Fixed-point fractional library routines.
+ (line 1425)
+* __satfracthiuda: Fixed-point fractional library routines.
+ (line 1432)
+* __satfracthiudq: Fixed-point fractional library routines.
+ (line 1429)
+* __satfracthiuha: Fixed-point fractional library routines.
+ (line 1430)
+* __satfracthiuhq: Fixed-point fractional library routines.
+ (line 1427)
+* __satfracthiuqq: Fixed-point fractional library routines.
+ (line 1426)
+* __satfracthiusa: Fixed-point fractional library routines.
+ (line 1431)
+* __satfracthiusq: Fixed-point fractional library routines.
+ (line 1428)
+* __satfracthiuta: Fixed-point fractional library routines.
+ (line 1433)
+* __satfracthqda: Fixed-point fractional library routines.
+ (line 1064)
+* __satfracthqdq2: Fixed-point fractional library routines.
+ (line 1061)
+* __satfracthqha: Fixed-point fractional library routines.
+ (line 1062)
+* __satfracthqqq2: Fixed-point fractional library routines.
+ (line 1059)
+* __satfracthqsa: Fixed-point fractional library routines.
+ (line 1063)
+* __satfracthqsq2: Fixed-point fractional library routines.
+ (line 1060)
+* __satfracthqta: Fixed-point fractional library routines.
+ (line 1065)
+* __satfracthquda: Fixed-point fractional library routines.
+ (line 1072)
+* __satfracthqudq: Fixed-point fractional library routines.
+ (line 1069)
+* __satfracthquha: Fixed-point fractional library routines.
+ (line 1070)
+* __satfracthquhq: Fixed-point fractional library routines.
+ (line 1067)
+* __satfracthquqq: Fixed-point fractional library routines.
+ (line 1066)
+* __satfracthqusa: Fixed-point fractional library routines.
+ (line 1071)
+* __satfracthqusq: Fixed-point fractional library routines.
+ (line 1068)
+* __satfracthquta: Fixed-point fractional library routines.
+ (line 1073)
+* __satfractqida: Fixed-point fractional library routines.
+ (line 1402)
+* __satfractqidq: Fixed-point fractional library routines.
+ (line 1399)
+* __satfractqiha: Fixed-point fractional library routines.
+ (line 1400)
+* __satfractqihq: Fixed-point fractional library routines.
+ (line 1397)
+* __satfractqiqq: Fixed-point fractional library routines.
+ (line 1396)
+* __satfractqisa: Fixed-point fractional library routines.
+ (line 1401)
+* __satfractqisq: Fixed-point fractional library routines.
+ (line 1398)
+* __satfractqita: Fixed-point fractional library routines.
+ (line 1403)
+* __satfractqiuda: Fixed-point fractional library routines.
+ (line 1415)
+* __satfractqiudq: Fixed-point fractional library routines.
+ (line 1410)
+* __satfractqiuha: Fixed-point fractional library routines.
+ (line 1412)
+* __satfractqiuhq: Fixed-point fractional library routines.
+ (line 1406)
+* __satfractqiuqq: Fixed-point fractional library routines.
+ (line 1405)
+* __satfractqiusa: Fixed-point fractional library routines.
+ (line 1413)
+* __satfractqiusq: Fixed-point fractional library routines.
+ (line 1408)
+* __satfractqiuta: Fixed-point fractional library routines.
+ (line 1417)
+* __satfractqqda: Fixed-point fractional library routines.
+ (line 1043)
+* __satfractqqdq2: Fixed-point fractional library routines.
+ (line 1040)
+* __satfractqqha: Fixed-point fractional library routines.
+ (line 1041)
+* __satfractqqhq2: Fixed-point fractional library routines.
+ (line 1038)
+* __satfractqqsa: Fixed-point fractional library routines.
+ (line 1042)
+* __satfractqqsq2: Fixed-point fractional library routines.
+ (line 1039)
+* __satfractqqta: Fixed-point fractional library routines.
+ (line 1044)
+* __satfractqquda: Fixed-point fractional library routines.
+ (line 1056)
+* __satfractqqudq: Fixed-point fractional library routines.
+ (line 1051)
+* __satfractqquha: Fixed-point fractional library routines.
+ (line 1053)
+* __satfractqquhq: Fixed-point fractional library routines.
+ (line 1047)
+* __satfractqquqq: Fixed-point fractional library routines.
+ (line 1046)
+* __satfractqqusa: Fixed-point fractional library routines.
+ (line 1054)
+* __satfractqqusq: Fixed-point fractional library routines.
+ (line 1049)
+* __satfractqquta: Fixed-point fractional library routines.
+ (line 1058)
+* __satfractsada2: Fixed-point fractional library routines.
+ (line 1140)
+* __satfractsadq: Fixed-point fractional library routines.
+ (line 1138)
+* __satfractsaha2: Fixed-point fractional library routines.
+ (line 1139)
+* __satfractsahq: Fixed-point fractional library routines.
+ (line 1136)
+* __satfractsaqq: Fixed-point fractional library routines.
+ (line 1135)
+* __satfractsasq: Fixed-point fractional library routines.
+ (line 1137)
+* __satfractsata2: Fixed-point fractional library routines.
+ (line 1141)
+* __satfractsauda: Fixed-point fractional library routines.
+ (line 1148)
+* __satfractsaudq: Fixed-point fractional library routines.
+ (line 1145)
+* __satfractsauha: Fixed-point fractional library routines.
+ (line 1146)
+* __satfractsauhq: Fixed-point fractional library routines.
+ (line 1143)
+* __satfractsauqq: Fixed-point fractional library routines.
+ (line 1142)
+* __satfractsausa: Fixed-point fractional library routines.
+ (line 1147)
+* __satfractsausq: Fixed-point fractional library routines.
+ (line 1144)
+* __satfractsauta: Fixed-point fractional library routines.
+ (line 1149)
+* __satfractsfda: Fixed-point fractional library routines.
+ (line 1490)
+* __satfractsfdq: Fixed-point fractional library routines.
+ (line 1487)
+* __satfractsfha: Fixed-point fractional library routines.
+ (line 1488)
+* __satfractsfhq: Fixed-point fractional library routines.
+ (line 1485)
+* __satfractsfqq: Fixed-point fractional library routines.
+ (line 1484)
+* __satfractsfsa: Fixed-point fractional library routines.
+ (line 1489)
+* __satfractsfsq: Fixed-point fractional library routines.
+ (line 1486)
+* __satfractsfta: Fixed-point fractional library routines.
+ (line 1491)
+* __satfractsfuda: Fixed-point fractional library routines.
+ (line 1498)
+* __satfractsfudq: Fixed-point fractional library routines.
+ (line 1495)
+* __satfractsfuha: Fixed-point fractional library routines.
+ (line 1496)
+* __satfractsfuhq: Fixed-point fractional library routines.
+ (line 1493)
+* __satfractsfuqq: Fixed-point fractional library routines.
+ (line 1492)
+* __satfractsfusa: Fixed-point fractional library routines.
+ (line 1497)
+* __satfractsfusq: Fixed-point fractional library routines.
+ (line 1494)
+* __satfractsfuta: Fixed-point fractional library routines.
+ (line 1499)
+* __satfractsida: Fixed-point fractional library routines.
+ (line 1440)
+* __satfractsidq: Fixed-point fractional library routines.
+ (line 1437)
+* __satfractsiha: Fixed-point fractional library routines.
+ (line 1438)
+* __satfractsihq: Fixed-point fractional library routines.
+ (line 1435)
+* __satfractsiqq: Fixed-point fractional library routines.
+ (line 1434)
+* __satfractsisa: Fixed-point fractional library routines.
+ (line 1439)
+* __satfractsisq: Fixed-point fractional library routines.
+ (line 1436)
+* __satfractsita: Fixed-point fractional library routines.
+ (line 1441)
+* __satfractsiuda: Fixed-point fractional library routines.
+ (line 1448)
+* __satfractsiudq: Fixed-point fractional library routines.
+ (line 1445)
+* __satfractsiuha: Fixed-point fractional library routines.
+ (line 1446)
+* __satfractsiuhq: Fixed-point fractional library routines.
+ (line 1443)
+* __satfractsiuqq: Fixed-point fractional library routines.
+ (line 1442)
+* __satfractsiusa: Fixed-point fractional library routines.
+ (line 1447)
+* __satfractsiusq: Fixed-point fractional library routines.
+ (line 1444)
+* __satfractsiuta: Fixed-point fractional library routines.
+ (line 1449)
+* __satfractsqda: Fixed-point fractional library routines.
+ (line 1079)
+* __satfractsqdq2: Fixed-point fractional library routines.
+ (line 1076)
+* __satfractsqha: Fixed-point fractional library routines.
+ (line 1077)
+* __satfractsqhq2: Fixed-point fractional library routines.
+ (line 1075)
+* __satfractsqqq2: Fixed-point fractional library routines.
+ (line 1074)
+* __satfractsqsa: Fixed-point fractional library routines.
+ (line 1078)
+* __satfractsqta: Fixed-point fractional library routines.
+ (line 1080)
+* __satfractsquda: Fixed-point fractional library routines.
+ (line 1090)
+* __satfractsqudq: Fixed-point fractional library routines.
+ (line 1086)
+* __satfractsquha: Fixed-point fractional library routines.
+ (line 1088)
+* __satfractsquhq: Fixed-point fractional library routines.
+ (line 1083)
+* __satfractsquqq: Fixed-point fractional library routines.
+ (line 1082)
+* __satfractsqusa: Fixed-point fractional library routines.
+ (line 1089)
+* __satfractsqusq: Fixed-point fractional library routines.
+ (line 1084)
+* __satfractsquta: Fixed-point fractional library routines.
+ (line 1092)
+* __satfracttada2: Fixed-point fractional library routines.
+ (line 1175)
+* __satfracttadq: Fixed-point fractional library routines.
+ (line 1172)
+* __satfracttaha2: Fixed-point fractional library routines.
+ (line 1173)
+* __satfracttahq: Fixed-point fractional library routines.
+ (line 1170)
+* __satfracttaqq: Fixed-point fractional library routines.
+ (line 1169)
+* __satfracttasa2: Fixed-point fractional library routines.
+ (line 1174)
+* __satfracttasq: Fixed-point fractional library routines.
+ (line 1171)
+* __satfracttauda: Fixed-point fractional library routines.
+ (line 1187)
+* __satfracttaudq: Fixed-point fractional library routines.
+ (line 1182)
+* __satfracttauha: Fixed-point fractional library routines.
+ (line 1184)
+* __satfracttauhq: Fixed-point fractional library routines.
+ (line 1178)
+* __satfracttauqq: Fixed-point fractional library routines.
+ (line 1177)
+* __satfracttausa: Fixed-point fractional library routines.
+ (line 1185)
+* __satfracttausq: Fixed-point fractional library routines.
+ (line 1180)
+* __satfracttauta: Fixed-point fractional library routines.
+ (line 1189)
+* __satfracttida: Fixed-point fractional library routines.
+ (line 1472)
+* __satfracttidq: Fixed-point fractional library routines.
+ (line 1469)
+* __satfracttiha: Fixed-point fractional library routines.
+ (line 1470)
+* __satfracttihq: Fixed-point fractional library routines.
+ (line 1467)
+* __satfracttiqq: Fixed-point fractional library routines.
+ (line 1466)
+* __satfracttisa: Fixed-point fractional library routines.
+ (line 1471)
+* __satfracttisq: Fixed-point fractional library routines.
+ (line 1468)
+* __satfracttita: Fixed-point fractional library routines.
+ (line 1473)
+* __satfracttiuda: Fixed-point fractional library routines.
+ (line 1481)
+* __satfracttiudq: Fixed-point fractional library routines.
+ (line 1478)
+* __satfracttiuha: Fixed-point fractional library routines.
+ (line 1479)
+* __satfracttiuhq: Fixed-point fractional library routines.
+ (line 1475)
+* __satfracttiuqq: Fixed-point fractional library routines.
+ (line 1474)
+* __satfracttiusa: Fixed-point fractional library routines.
+ (line 1480)
+* __satfracttiusq: Fixed-point fractional library routines.
+ (line 1476)
+* __satfracttiuta: Fixed-point fractional library routines.
+ (line 1483)
+* __satfractudada: Fixed-point fractional library routines.
+ (line 1351)
+* __satfractudadq: Fixed-point fractional library routines.
+ (line 1347)
+* __satfractudaha: Fixed-point fractional library routines.
+ (line 1349)
+* __satfractudahq: Fixed-point fractional library routines.
+ (line 1344)
+* __satfractudaqq: Fixed-point fractional library routines.
+ (line 1343)
+* __satfractudasa: Fixed-point fractional library routines.
+ (line 1350)
+* __satfractudasq: Fixed-point fractional library routines.
+ (line 1345)
+* __satfractudata: Fixed-point fractional library routines.
+ (line 1353)
+* __satfractudaudq: Fixed-point fractional library routines.
+ (line 1361)
+* __satfractudauha2: Fixed-point fractional library routines.
+ (line 1363)
+* __satfractudauhq: Fixed-point fractional library routines.
+ (line 1357)
+* __satfractudauqq: Fixed-point fractional library routines.
+ (line 1355)
+* __satfractudausa2: Fixed-point fractional library routines.
+ (line 1365)
+* __satfractudausq: Fixed-point fractional library routines.
+ (line 1359)
+* __satfractudauta2: Fixed-point fractional library routines.
+ (line 1367)
+* __satfractudqda: Fixed-point fractional library routines.
+ (line 1276)
+* __satfractudqdq: Fixed-point fractional library routines.
+ (line 1271)
+* __satfractudqha: Fixed-point fractional library routines.
+ (line 1273)
+* __satfractudqhq: Fixed-point fractional library routines.
+ (line 1267)
+* __satfractudqqq: Fixed-point fractional library routines.
+ (line 1266)
+* __satfractudqsa: Fixed-point fractional library routines.
+ (line 1274)
+* __satfractudqsq: Fixed-point fractional library routines.
+ (line 1269)
+* __satfractudqta: Fixed-point fractional library routines.
+ (line 1278)
+* __satfractudquda: Fixed-point fractional library routines.
+ (line 1290)
+* __satfractudquha: Fixed-point fractional library routines.
+ (line 1286)
+* __satfractudquhq2: Fixed-point fractional library routines.
+ (line 1282)
+* __satfractudquqq2: Fixed-point fractional library routines.
+ (line 1280)
+* __satfractudqusa: Fixed-point fractional library routines.
+ (line 1288)
+* __satfractudqusq2: Fixed-point fractional library routines.
+ (line 1284)
+* __satfractudquta: Fixed-point fractional library routines.
+ (line 1292)
+* __satfractuhada: Fixed-point fractional library routines.
+ (line 1304)
+* __satfractuhadq: Fixed-point fractional library routines.
+ (line 1299)
+* __satfractuhaha: Fixed-point fractional library routines.
+ (line 1301)
+* __satfractuhahq: Fixed-point fractional library routines.
+ (line 1295)
+* __satfractuhaqq: Fixed-point fractional library routines.
+ (line 1294)
+* __satfractuhasa: Fixed-point fractional library routines.
+ (line 1302)
+* __satfractuhasq: Fixed-point fractional library routines.
+ (line 1297)
+* __satfractuhata: Fixed-point fractional library routines.
+ (line 1306)
+* __satfractuhauda2: Fixed-point fractional library routines.
+ (line 1318)
+* __satfractuhaudq: Fixed-point fractional library routines.
+ (line 1314)
+* __satfractuhauhq: Fixed-point fractional library routines.
+ (line 1310)
+* __satfractuhauqq: Fixed-point fractional library routines.
+ (line 1308)
+* __satfractuhausa2: Fixed-point fractional library routines.
+ (line 1316)
+* __satfractuhausq: Fixed-point fractional library routines.
+ (line 1312)
+* __satfractuhauta2: Fixed-point fractional library routines.
+ (line 1320)
+* __satfractuhqda: Fixed-point fractional library routines.
+ (line 1224)
+* __satfractuhqdq: Fixed-point fractional library routines.
+ (line 1221)
+* __satfractuhqha: Fixed-point fractional library routines.
+ (line 1222)
+* __satfractuhqhq: Fixed-point fractional library routines.
+ (line 1219)
+* __satfractuhqqq: Fixed-point fractional library routines.
+ (line 1218)
+* __satfractuhqsa: Fixed-point fractional library routines.
+ (line 1223)
+* __satfractuhqsq: Fixed-point fractional library routines.
+ (line 1220)
+* __satfractuhqta: Fixed-point fractional library routines.
+ (line 1225)
+* __satfractuhquda: Fixed-point fractional library routines.
+ (line 1236)
+* __satfractuhqudq2: Fixed-point fractional library routines.
+ (line 1231)
+* __satfractuhquha: Fixed-point fractional library routines.
+ (line 1233)
+* __satfractuhquqq2: Fixed-point fractional library routines.
+ (line 1227)
+* __satfractuhqusa: Fixed-point fractional library routines.
+ (line 1234)
+* __satfractuhqusq2: Fixed-point fractional library routines.
+ (line 1229)
+* __satfractuhquta: Fixed-point fractional library routines.
+ (line 1238)
+* __satfractunsdida: Fixed-point fractional library routines.
+ (line 1834)
+* __satfractunsdidq: Fixed-point fractional library routines.
+ (line 1831)
+* __satfractunsdiha: Fixed-point fractional library routines.
+ (line 1832)
+* __satfractunsdihq: Fixed-point fractional library routines.
+ (line 1828)
+* __satfractunsdiqq: Fixed-point fractional library routines.
+ (line 1827)
+* __satfractunsdisa: Fixed-point fractional library routines.
+ (line 1833)
+* __satfractunsdisq: Fixed-point fractional library routines.
+ (line 1829)
+* __satfractunsdita: Fixed-point fractional library routines.
+ (line 1836)
+* __satfractunsdiuda: Fixed-point fractional library routines.
+ (line 1850)
+* __satfractunsdiudq: Fixed-point fractional library routines.
+ (line 1844)
+* __satfractunsdiuha: Fixed-point fractional library routines.
+ (line 1846)
+* __satfractunsdiuhq: Fixed-point fractional library routines.
+ (line 1840)
+* __satfractunsdiuqq: Fixed-point fractional library routines.
+ (line 1838)
+* __satfractunsdiusa: Fixed-point fractional library routines.
+ (line 1848)
+* __satfractunsdiusq: Fixed-point fractional library routines.
+ (line 1842)
+* __satfractunsdiuta: Fixed-point fractional library routines.
+ (line 1852)
+* __satfractunshida: Fixed-point fractional library routines.
+ (line 1786)
+* __satfractunshidq: Fixed-point fractional library routines.
+ (line 1783)
+* __satfractunshiha: Fixed-point fractional library routines.
+ (line 1784)
+* __satfractunshihq: Fixed-point fractional library routines.
+ (line 1780)
+* __satfractunshiqq: Fixed-point fractional library routines.
+ (line 1779)
+* __satfractunshisa: Fixed-point fractional library routines.
+ (line 1785)
+* __satfractunshisq: Fixed-point fractional library routines.
+ (line 1781)
+* __satfractunshita: Fixed-point fractional library routines.
+ (line 1788)
+* __satfractunshiuda: Fixed-point fractional library routines.
+ (line 1802)
+* __satfractunshiudq: Fixed-point fractional library routines.
+ (line 1796)
+* __satfractunshiuha: Fixed-point fractional library routines.
+ (line 1798)
+* __satfractunshiuhq: Fixed-point fractional library routines.
+ (line 1792)
+* __satfractunshiuqq: Fixed-point fractional library routines.
+ (line 1790)
+* __satfractunshiusa: Fixed-point fractional library routines.
+ (line 1800)
+* __satfractunshiusq: Fixed-point fractional library routines.
+ (line 1794)
+* __satfractunshiuta: Fixed-point fractional library routines.
+ (line 1804)
+* __satfractunsqida: Fixed-point fractional library routines.
+ (line 1760)
+* __satfractunsqidq: Fixed-point fractional library routines.
+ (line 1757)
+* __satfractunsqiha: Fixed-point fractional library routines.
+ (line 1758)
+* __satfractunsqihq: Fixed-point fractional library routines.
+ (line 1754)
+* __satfractunsqiqq: Fixed-point fractional library routines.
+ (line 1753)
+* __satfractunsqisa: Fixed-point fractional library routines.
+ (line 1759)
+* __satfractunsqisq: Fixed-point fractional library routines.
+ (line 1755)
+* __satfractunsqita: Fixed-point fractional library routines.
+ (line 1762)
+* __satfractunsqiuda: Fixed-point fractional library routines.
+ (line 1776)
+* __satfractunsqiudq: Fixed-point fractional library routines.
+ (line 1770)
+* __satfractunsqiuha: Fixed-point fractional library routines.
+ (line 1772)
+* __satfractunsqiuhq: Fixed-point fractional library routines.
+ (line 1766)
+* __satfractunsqiuqq: Fixed-point fractional library routines.
+ (line 1764)
+* __satfractunsqiusa: Fixed-point fractional library routines.
+ (line 1774)
+* __satfractunsqiusq: Fixed-point fractional library routines.
+ (line 1768)
+* __satfractunsqiuta: Fixed-point fractional library routines.
+ (line 1778)
+* __satfractunssida: Fixed-point fractional library routines.
+ (line 1811)
+* __satfractunssidq: Fixed-point fractional library routines.
+ (line 1808)
+* __satfractunssiha: Fixed-point fractional library routines.
+ (line 1809)
+* __satfractunssihq: Fixed-point fractional library routines.
+ (line 1806)
+* __satfractunssiqq: Fixed-point fractional library routines.
+ (line 1805)
+* __satfractunssisa: Fixed-point fractional library routines.
+ (line 1810)
+* __satfractunssisq: Fixed-point fractional library routines.
+ (line 1807)
+* __satfractunssita: Fixed-point fractional library routines.
+ (line 1812)
+* __satfractunssiuda: Fixed-point fractional library routines.
+ (line 1824)
+* __satfractunssiudq: Fixed-point fractional library routines.
+ (line 1819)
+* __satfractunssiuha: Fixed-point fractional library routines.
+ (line 1821)
+* __satfractunssiuhq: Fixed-point fractional library routines.
+ (line 1815)
+* __satfractunssiuqq: Fixed-point fractional library routines.
+ (line 1814)
+* __satfractunssiusa: Fixed-point fractional library routines.
+ (line 1822)
+* __satfractunssiusq: Fixed-point fractional library routines.
+ (line 1817)
+* __satfractunssiuta: Fixed-point fractional library routines.
+ (line 1826)
+* __satfractunstida: Fixed-point fractional library routines.
+ (line 1864)
+* __satfractunstidq: Fixed-point fractional library routines.
+ (line 1859)
+* __satfractunstiha: Fixed-point fractional library routines.
+ (line 1861)
+* __satfractunstihq: Fixed-point fractional library routines.
+ (line 1855)
+* __satfractunstiqq: Fixed-point fractional library routines.
+ (line 1854)
+* __satfractunstisa: Fixed-point fractional library routines.
+ (line 1862)
+* __satfractunstisq: Fixed-point fractional library routines.
+ (line 1857)
+* __satfractunstita: Fixed-point fractional library routines.
+ (line 1866)
+* __satfractunstiuda: Fixed-point fractional library routines.
+ (line 1880)
+* __satfractunstiudq: Fixed-point fractional library routines.
+ (line 1874)
+* __satfractunstiuha: Fixed-point fractional library routines.
+ (line 1876)
+* __satfractunstiuhq: Fixed-point fractional library routines.
+ (line 1870)
+* __satfractunstiuqq: Fixed-point fractional library routines.
+ (line 1868)
+* __satfractunstiusa: Fixed-point fractional library routines.
+ (line 1878)
+* __satfractunstiusq: Fixed-point fractional library routines.
+ (line 1872)
+* __satfractunstiuta: Fixed-point fractional library routines.
+ (line 1882)
+* __satfractuqqda: Fixed-point fractional library routines.
+ (line 1201)
+* __satfractuqqdq: Fixed-point fractional library routines.
+ (line 1196)
+* __satfractuqqha: Fixed-point fractional library routines.
+ (line 1198)
+* __satfractuqqhq: Fixed-point fractional library routines.
+ (line 1192)
+* __satfractuqqqq: Fixed-point fractional library routines.
+ (line 1191)
+* __satfractuqqsa: Fixed-point fractional library routines.
+ (line 1199)
+* __satfractuqqsq: Fixed-point fractional library routines.
+ (line 1194)
+* __satfractuqqta: Fixed-point fractional library routines.
+ (line 1203)
+* __satfractuqquda: Fixed-point fractional library routines.
+ (line 1215)
+* __satfractuqqudq2: Fixed-point fractional library routines.
+ (line 1209)
+* __satfractuqquha: Fixed-point fractional library routines.
+ (line 1211)
+* __satfractuqquhq2: Fixed-point fractional library routines.
+ (line 1205)
+* __satfractuqqusa: Fixed-point fractional library routines.
+ (line 1213)
+* __satfractuqqusq2: Fixed-point fractional library routines.
+ (line 1207)
+* __satfractuqquta: Fixed-point fractional library routines.
+ (line 1217)
+* __satfractusada: Fixed-point fractional library routines.
+ (line 1327)
+* __satfractusadq: Fixed-point fractional library routines.
+ (line 1324)
+* __satfractusaha: Fixed-point fractional library routines.
+ (line 1325)
+* __satfractusahq: Fixed-point fractional library routines.
+ (line 1322)
+* __satfractusaqq: Fixed-point fractional library routines.
+ (line 1321)
+* __satfractusasa: Fixed-point fractional library routines.
+ (line 1326)
+* __satfractusasq: Fixed-point fractional library routines.
+ (line 1323)
+* __satfractusata: Fixed-point fractional library routines.
+ (line 1328)
+* __satfractusauda2: Fixed-point fractional library routines.
+ (line 1339)
+* __satfractusaudq: Fixed-point fractional library routines.
+ (line 1335)
+* __satfractusauha2: Fixed-point fractional library routines.
+ (line 1337)
+* __satfractusauhq: Fixed-point fractional library routines.
+ (line 1331)
+* __satfractusauqq: Fixed-point fractional library routines.
+ (line 1330)
+* __satfractusausq: Fixed-point fractional library routines.
+ (line 1333)
+* __satfractusauta2: Fixed-point fractional library routines.
+ (line 1341)
+* __satfractusqda: Fixed-point fractional library routines.
+ (line 1248)
+* __satfractusqdq: Fixed-point fractional library routines.
+ (line 1244)
+* __satfractusqha: Fixed-point fractional library routines.
+ (line 1246)
+* __satfractusqhq: Fixed-point fractional library routines.
+ (line 1241)
+* __satfractusqqq: Fixed-point fractional library routines.
+ (line 1240)
+* __satfractusqsa: Fixed-point fractional library routines.
+ (line 1247)
+* __satfractusqsq: Fixed-point fractional library routines.
+ (line 1242)
+* __satfractusqta: Fixed-point fractional library routines.
+ (line 1250)
+* __satfractusquda: Fixed-point fractional library routines.
+ (line 1262)
+* __satfractusqudq2: Fixed-point fractional library routines.
+ (line 1256)
+* __satfractusquha: Fixed-point fractional library routines.
+ (line 1258)
+* __satfractusquhq2: Fixed-point fractional library routines.
+ (line 1254)
+* __satfractusquqq2: Fixed-point fractional library routines.
+ (line 1252)
+* __satfractusqusa: Fixed-point fractional library routines.
+ (line 1260)
+* __satfractusquta: Fixed-point fractional library routines.
+ (line 1264)
+* __satfractutada: Fixed-point fractional library routines.
+ (line 1379)
+* __satfractutadq: Fixed-point fractional library routines.
+ (line 1374)
+* __satfractutaha: Fixed-point fractional library routines.
+ (line 1376)
+* __satfractutahq: Fixed-point fractional library routines.
+ (line 1370)
+* __satfractutaqq: Fixed-point fractional library routines.
+ (line 1369)
+* __satfractutasa: Fixed-point fractional library routines.
+ (line 1377)
+* __satfractutasq: Fixed-point fractional library routines.
+ (line 1372)
+* __satfractutata: Fixed-point fractional library routines.
+ (line 1381)
+* __satfractutauda2: Fixed-point fractional library routines.
+ (line 1395)
+* __satfractutaudq: Fixed-point fractional library routines.
+ (line 1389)
+* __satfractutauha2: Fixed-point fractional library routines.
+ (line 1391)
+* __satfractutauhq: Fixed-point fractional library routines.
+ (line 1385)
+* __satfractutauqq: Fixed-point fractional library routines.
+ (line 1383)
+* __satfractutausa2: Fixed-point fractional library routines.
+ (line 1393)
+* __satfractutausq: Fixed-point fractional library routines.
+ (line 1387)
+* __ssaddda3: Fixed-point fractional library routines.
+ (line 67)
+* __ssadddq3: Fixed-point fractional library routines.
+ (line 63)
+* __ssaddha3: Fixed-point fractional library routines.
+ (line 65)
+* __ssaddhq3: Fixed-point fractional library routines.
+ (line 60)
+* __ssaddqq3: Fixed-point fractional library routines.
+ (line 59)
+* __ssaddsa3: Fixed-point fractional library routines.
+ (line 66)
+* __ssaddsq3: Fixed-point fractional library routines.
+ (line 61)
+* __ssaddta3: Fixed-point fractional library routines.
+ (line 69)
+* __ssashlda3: Fixed-point fractional library routines.
+ (line 402)
+* __ssashldq3: Fixed-point fractional library routines.
+ (line 399)
+* __ssashlha3: Fixed-point fractional library routines.
+ (line 400)
+* __ssashlhq3: Fixed-point fractional library routines.
+ (line 396)
+* __ssashlsa3: Fixed-point fractional library routines.
+ (line 401)
+* __ssashlsq3: Fixed-point fractional library routines.
+ (line 397)
+* __ssashlta3: Fixed-point fractional library routines.
+ (line 404)
+* __ssdivda3: Fixed-point fractional library routines.
+ (line 261)
+* __ssdivdq3: Fixed-point fractional library routines.
+ (line 257)
+* __ssdivha3: Fixed-point fractional library routines.
+ (line 259)
+* __ssdivhq3: Fixed-point fractional library routines.
+ (line 254)
+* __ssdivqq3: Fixed-point fractional library routines.
+ (line 253)
+* __ssdivsa3: Fixed-point fractional library routines.
+ (line 260)
+* __ssdivsq3: Fixed-point fractional library routines.
+ (line 255)
+* __ssdivta3: Fixed-point fractional library routines.
+ (line 263)
+* __ssmulda3: Fixed-point fractional library routines.
+ (line 193)
+* __ssmuldq3: Fixed-point fractional library routines.
+ (line 189)
+* __ssmulha3: Fixed-point fractional library routines.
+ (line 191)
+* __ssmulhq3: Fixed-point fractional library routines.
+ (line 186)
+* __ssmulqq3: Fixed-point fractional library routines.
+ (line 185)
+* __ssmulsa3: Fixed-point fractional library routines.
+ (line 192)
+* __ssmulsq3: Fixed-point fractional library routines.
+ (line 187)
+* __ssmulta3: Fixed-point fractional library routines.
+ (line 195)
+* __ssnegda2: Fixed-point fractional library routines.
+ (line 316)
+* __ssnegdq2: Fixed-point fractional library routines.
+ (line 313)
+* __ssnegha2: Fixed-point fractional library routines.
+ (line 314)
+* __ssneghq2: Fixed-point fractional library routines.
+ (line 311)
+* __ssnegqq2: Fixed-point fractional library routines.
+ (line 310)
+* __ssnegsa2: Fixed-point fractional library routines.
+ (line 315)
+* __ssnegsq2: Fixed-point fractional library routines.
+ (line 312)
+* __ssnegta2: Fixed-point fractional library routines.
+ (line 317)
+* __sssubda3: Fixed-point fractional library routines.
+ (line 129)
+* __sssubdq3: Fixed-point fractional library routines.
+ (line 125)
+* __sssubha3: Fixed-point fractional library routines.
+ (line 127)
+* __sssubhq3: Fixed-point fractional library routines.
+ (line 122)
+* __sssubqq3: Fixed-point fractional library routines.
+ (line 121)
+* __sssubsa3: Fixed-point fractional library routines.
+ (line 128)
+* __sssubsq3: Fixed-point fractional library routines.
+ (line 123)
+* __sssubta3: Fixed-point fractional library routines.
+ (line 131)
+* __subda3: Fixed-point fractional library routines.
+ (line 107)
+* __subdf3: Soft float library routines.
+ (line 31)
+* __subdq3: Fixed-point fractional library routines.
+ (line 95)
+* __subha3: Fixed-point fractional library routines.
+ (line 105)
+* __subhq3: Fixed-point fractional library routines.
+ (line 92)
+* __subqq3: Fixed-point fractional library routines.
+ (line 91)
+* __subsa3: Fixed-point fractional library routines.
+ (line 106)
+* __subsf3: Soft float library routines.
+ (line 30)
+* __subsq3: Fixed-point fractional library routines.
+ (line 93)
+* __subta3: Fixed-point fractional library routines.
+ (line 109)
+* __subtf3: Soft float library routines.
+ (line 33)
+* __subuda3: Fixed-point fractional library routines.
+ (line 115)
+* __subudq3: Fixed-point fractional library routines.
+ (line 103)
+* __subuha3: Fixed-point fractional library routines.
+ (line 111)
+* __subuhq3: Fixed-point fractional library routines.
+ (line 99)
+* __subuqq3: Fixed-point fractional library routines.
+ (line 97)
+* __subusa3: Fixed-point fractional library routines.
+ (line 113)
+* __subusq3: Fixed-point fractional library routines.
+ (line 101)
+* __subuta3: Fixed-point fractional library routines.
+ (line 117)
+* __subvdi3: Integer library routines.
+ (line 123)
+* __subvsi3: Integer library routines.
+ (line 122)
+* __subxf3: Soft float library routines.
+ (line 35)
+* __truncdfsf2: Soft float library routines.
+ (line 76)
+* __trunctfdf2: Soft float library routines.
+ (line 73)
+* __trunctfsf2: Soft float library routines.
+ (line 75)
+* __truncxfdf2: Soft float library routines.
+ (line 72)
+* __truncxfsf2: Soft float library routines.
+ (line 74)
+* __ucmpdi2: Integer library routines.
+ (line 93)
+* __ucmpti2: Integer library routines.
+ (line 95)
+* __udivdi3: Integer library routines.
+ (line 54)
+* __udivmoddi3: Integer library routines.
+ (line 61)
+* __udivsi3: Integer library routines.
+ (line 52)
+* __udivti3: Integer library routines.
+ (line 56)
+* __udivuda3: Fixed-point fractional library routines.
+ (line 246)
+* __udivudq3: Fixed-point fractional library routines.
+ (line 240)
+* __udivuha3: Fixed-point fractional library routines.
+ (line 242)
+* __udivuhq3: Fixed-point fractional library routines.
+ (line 236)
+* __udivuqq3: Fixed-point fractional library routines.
+ (line 234)
+* __udivusa3: Fixed-point fractional library routines.
+ (line 244)
+* __udivusq3: Fixed-point fractional library routines.
+ (line 238)
+* __udivuta3: Fixed-point fractional library routines.
+ (line 248)
+* __umoddi3: Integer library routines.
+ (line 71)
+* __umodsi3: Integer library routines.
+ (line 69)
+* __umodti3: Integer library routines.
+ (line 73)
+* __unorddf2: Soft float library routines.
+ (line 173)
+* __unordsf2: Soft float library routines.
+ (line 172)
+* __unordtf2: Soft float library routines.
+ (line 174)
+* __usadduda3: Fixed-point fractional library routines.
+ (line 85)
+* __usaddudq3: Fixed-point fractional library routines.
+ (line 79)
+* __usadduha3: Fixed-point fractional library routines.
+ (line 81)
+* __usadduhq3: Fixed-point fractional library routines.
+ (line 75)
+* __usadduqq3: Fixed-point fractional library routines.
+ (line 73)
+* __usaddusa3: Fixed-point fractional library routines.
+ (line 83)
+* __usaddusq3: Fixed-point fractional library routines.
+ (line 77)
+* __usadduta3: Fixed-point fractional library routines.
+ (line 87)
+* __usashluda3: Fixed-point fractional library routines.
+ (line 421)
+* __usashludq3: Fixed-point fractional library routines.
+ (line 415)
+* __usashluha3: Fixed-point fractional library routines.
+ (line 417)
+* __usashluhq3: Fixed-point fractional library routines.
+ (line 411)
+* __usashluqq3: Fixed-point fractional library routines.
+ (line 409)
+* __usashlusa3: Fixed-point fractional library routines.
+ (line 419)
+* __usashlusq3: Fixed-point fractional library routines.
+ (line 413)
+* __usashluta3: Fixed-point fractional library routines.
+ (line 423)
+* __usdivuda3: Fixed-point fractional library routines.
+ (line 280)
+* __usdivudq3: Fixed-point fractional library routines.
+ (line 274)
+* __usdivuha3: Fixed-point fractional library routines.
+ (line 276)
+* __usdivuhq3: Fixed-point fractional library routines.
+ (line 270)
+* __usdivuqq3: Fixed-point fractional library routines.
+ (line 268)
+* __usdivusa3: Fixed-point fractional library routines.
+ (line 278)
+* __usdivusq3: Fixed-point fractional library routines.
+ (line 272)
+* __usdivuta3: Fixed-point fractional library routines.
+ (line 282)
+* __usmuluda3: Fixed-point fractional library routines.
+ (line 212)
+* __usmuludq3: Fixed-point fractional library routines.
+ (line 206)
+* __usmuluha3: Fixed-point fractional library routines.
+ (line 208)
+* __usmuluhq3: Fixed-point fractional library routines.
+ (line 202)
+* __usmuluqq3: Fixed-point fractional library routines.
+ (line 200)
+* __usmulusa3: Fixed-point fractional library routines.
+ (line 210)
+* __usmulusq3: Fixed-point fractional library routines.
+ (line 204)
+* __usmuluta3: Fixed-point fractional library routines.
+ (line 214)
+* __usneguda2: Fixed-point fractional library routines.
+ (line 331)
+* __usnegudq2: Fixed-point fractional library routines.
+ (line 326)
+* __usneguha2: Fixed-point fractional library routines.
+ (line 328)
+* __usneguhq2: Fixed-point fractional library routines.
+ (line 322)
+* __usneguqq2: Fixed-point fractional library routines.
+ (line 321)
+* __usnegusa2: Fixed-point fractional library routines.
+ (line 329)
+* __usnegusq2: Fixed-point fractional library routines.
+ (line 324)
+* __usneguta2: Fixed-point fractional library routines.
+ (line 333)
+* __ussubuda3: Fixed-point fractional library routines.
+ (line 148)
+* __ussubudq3: Fixed-point fractional library routines.
+ (line 142)
+* __ussubuha3: Fixed-point fractional library routines.
+ (line 144)
+* __ussubuhq3: Fixed-point fractional library routines.
+ (line 138)
+* __ussubuqq3: Fixed-point fractional library routines.
+ (line 136)
+* __ussubusa3: Fixed-point fractional library routines.
+ (line 146)
+* __ussubusq3: Fixed-point fractional library routines.
+ (line 140)
+* __ussubuta3: Fixed-point fractional library routines.
+ (line 150)
+* abort: Portability. (line 21)
+* abs: Arithmetic. (line 195)
+* abs and attributes: Expressions. (line 64)
+* ABS_EXPR: Expression trees. (line 6)
+* absence_set: Processor pipeline description.
+ (line 215)
+* absM2 instruction pattern: Standard Names. (line 452)
+* absolute value: Arithmetic. (line 195)
+* access to operands: Accessors. (line 6)
+* access to special operands: Special Accessors. (line 6)
+* accessors: Accessors. (line 6)
+* ACCUM_TYPE_SIZE: Type Layout. (line 88)
+* ACCUMULATE_OUTGOING_ARGS: Stack Arguments. (line 46)
+* ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line 135)
+* ADA_LONG_TYPE_SIZE: Type Layout. (line 26)
+* Adding a new GIMPLE statement code: Adding a new GIMPLE statement code.
+ (line 6)
+* ADDITIONAL_REGISTER_NAMES: Instruction Output. (line 15)
+* addM3 instruction pattern: Standard Names. (line 216)
+* addMODEcc instruction pattern: Standard Names. (line 904)
+* addr_diff_vec: Side Effects. (line 302)
+* addr_diff_vec, length of: Insn Lengths. (line 26)
+* ADDR_EXPR: Expression trees. (line 6)
+* addr_vec: Side Effects. (line 297)
+* addr_vec, length of: Insn Lengths. (line 26)
+* address constraints: Simple Constraints. (line 154)
+* address_operand <1>: Simple Constraints. (line 158)
+* address_operand: Machine-Independent Predicates.
+ (line 63)
+* addressing modes: Addressing Modes. (line 6)
+* ADJUST_FIELD_ALIGN: Storage Layout. (line 201)
+* ADJUST_INSN_LENGTH: Insn Lengths. (line 35)
+* AGGR_INIT_EXPR: Expression trees. (line 6)
+* aggregates as return values: Aggregate Return. (line 6)
+* alias: Alias analysis. (line 6)
+* ALL_COP_ADDITIONAL_REGISTER_NAMES: MIPS Coprocessors. (line 32)
+* ALL_REGS: Register Classes. (line 17)
+* allocate_stack instruction pattern: Standard Names. (line 1227)
+* alternate entry points: Insns. (line 140)
+* anchored addresses: Anchored Addresses. (line 6)
+* and: Arithmetic. (line 153)
+* and and attributes: Expressions. (line 50)
+* and, canonicalization of: Insn Canonicalizations.
+ (line 57)
+* andM3 instruction pattern: Standard Names. (line 222)
+* annotations: Annotations. (line 6)
+* APPLY_RESULT_SIZE: Scalar Return. (line 95)
+* ARG_POINTER_CFA_OFFSET: Frame Layout. (line 194)
+* ARG_POINTER_REGNUM: Frame Registers. (line 41)
+* ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line 65)
+* arg_pointer_rtx: Frame Registers. (line 85)
+* ARGS_GROW_DOWNWARD: Frame Layout. (line 35)
+* argument passing: Interface. (line 36)
+* arguments in registers: Register Arguments. (line 6)
+* arguments on stack: Stack Arguments. (line 6)
+* arithmetic library: Soft float library routines.
+ (line 6)
+* arithmetic shift: Arithmetic. (line 168)
+* arithmetic shift with signed saturation: Arithmetic. (line 168)
+* arithmetic shift with unsigned saturation: Arithmetic. (line 168)
+* arithmetic, in RTL: Arithmetic. (line 6)
+* ARITHMETIC_TYPE_P: Types. (line 76)
+* array: Types. (line 6)
+* ARRAY_RANGE_REF: Expression trees. (line 6)
+* ARRAY_REF: Expression trees. (line 6)
+* ARRAY_TYPE: Types. (line 6)
+* AS_NEEDS_DASH_FOR_PIPED_INPUT: Driver. (line 151)
+* ashift: Arithmetic. (line 168)
+* ashift and attributes: Expressions. (line 64)
+* ashiftrt: Arithmetic. (line 185)
+* ashiftrt and attributes: Expressions. (line 64)
+* ashlM3 instruction pattern: Standard Names. (line 431)
+* ashrM3 instruction pattern: Standard Names. (line 441)
+* ASM_APP_OFF: File Framework. (line 61)
+* ASM_APP_ON: File Framework. (line 54)
+* ASM_COMMENT_START: File Framework. (line 49)
+* ASM_DECLARE_CLASS_REFERENCE: Label Output. (line 436)
+* ASM_DECLARE_CONSTANT_NAME: Label Output. (line 128)
+* ASM_DECLARE_FUNCTION_NAME: Label Output. (line 87)
+* ASM_DECLARE_FUNCTION_SIZE: Label Output. (line 101)
+* ASM_DECLARE_OBJECT_NAME: Label Output. (line 114)
+* ASM_DECLARE_REGISTER_GLOBAL: Label Output. (line 143)
+* ASM_DECLARE_UNRESOLVED_REFERENCE: Label Output. (line 442)
+* ASM_FINAL_SPEC: Driver. (line 144)
+* ASM_FINISH_DECLARE_OBJECT: Label Output. (line 151)
+* ASM_FORMAT_PRIVATE_NAME: Label Output. (line 354)
+* asm_fprintf: Instruction Output. (line 123)
+* ASM_FPRINTF_EXTENSIONS: Instruction Output. (line 134)
+* ASM_GENERATE_INTERNAL_LABEL: Label Output. (line 338)
+* asm_input: Side Effects. (line 284)
+* asm_input and /v: Flags. (line 94)
+* ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX: Exception Handling. (line 82)
+* ASM_NO_SKIP_IN_TEXT: Alignment Output. (line 72)
+* asm_noperands: Insns. (line 266)
+* asm_operands and /v: Flags. (line 94)
+* asm_operands, RTL sharing: Sharing. (line 45)
+* asm_operands, usage: Assembler. (line 6)
+* ASM_OUTPUT_ADDR_DIFF_ELT: Dispatch Tables. (line 9)
+* ASM_OUTPUT_ADDR_VEC_ELT: Dispatch Tables. (line 26)
+* ASM_OUTPUT_ALIGN: Alignment Output. (line 79)
+* ASM_OUTPUT_ALIGN_WITH_NOP: Alignment Output. (line 84)
+* ASM_OUTPUT_ALIGNED_BSS: Uninitialized Data. (line 64)
+* ASM_OUTPUT_ALIGNED_COMMON: Uninitialized Data. (line 23)
+* ASM_OUTPUT_ALIGNED_DECL_COMMON: Uninitialized Data. (line 31)
+* ASM_OUTPUT_ALIGNED_DECL_LOCAL: Uninitialized Data. (line 95)
+* ASM_OUTPUT_ALIGNED_LOCAL: Uninitialized Data. (line 87)
+* ASM_OUTPUT_ASCII: Data Output. (line 50)
+* ASM_OUTPUT_BSS: Uninitialized Data. (line 39)
+* ASM_OUTPUT_CASE_END: Dispatch Tables. (line 51)
+* ASM_OUTPUT_CASE_LABEL: Dispatch Tables. (line 38)
+* ASM_OUTPUT_COMMON: Uninitialized Data. (line 10)
+* ASM_OUTPUT_DEBUG_LABEL: Label Output. (line 326)
+* ASM_OUTPUT_DEF: Label Output. (line 375)
+* ASM_OUTPUT_DEF_FROM_DECLS: Label Output. (line 383)
+* ASM_OUTPUT_DWARF_DELTA: SDB and DWARF. (line 42)
+* ASM_OUTPUT_DWARF_OFFSET: SDB and DWARF. (line 46)
+* ASM_OUTPUT_DWARF_PCREL: SDB and DWARF. (line 52)
+* ASM_OUTPUT_EXTERNAL: Label Output. (line 264)
+* ASM_OUTPUT_FDESC: Data Output. (line 59)
+* ASM_OUTPUT_IDENT: File Framework. (line 83)
+* ASM_OUTPUT_INTERNAL_LABEL: Label Output. (line 17)
+* ASM_OUTPUT_LABEL: Label Output. (line 9)
+* ASM_OUTPUT_LABEL_REF: Label Output. (line 299)
+* ASM_OUTPUT_LABELREF: Label Output. (line 285)
+* ASM_OUTPUT_LOCAL: Uninitialized Data. (line 74)
+* ASM_OUTPUT_MAX_SKIP_ALIGN: Alignment Output. (line 88)
+* ASM_OUTPUT_MEASURED_SIZE: Label Output. (line 41)
+* ASM_OUTPUT_OPCODE: Instruction Output. (line 21)
+* ASM_OUTPUT_POOL_EPILOGUE: Data Output. (line 109)
+* ASM_OUTPUT_POOL_PROLOGUE: Data Output. (line 72)
+* ASM_OUTPUT_REG_POP: Instruction Output. (line 178)
+* ASM_OUTPUT_REG_PUSH: Instruction Output. (line 173)
+* ASM_OUTPUT_SIZE_DIRECTIVE: Label Output. (line 35)
+* ASM_OUTPUT_SKIP: Alignment Output. (line 66)
+* ASM_OUTPUT_SOURCE_FILENAME: File Framework. (line 68)
+* ASM_OUTPUT_SPECIAL_POOL_ENTRY: Data Output. (line 84)
+* ASM_OUTPUT_SYMBOL_REF: Label Output. (line 292)
+* ASM_OUTPUT_TYPE_DIRECTIVE: Label Output. (line 77)
+* ASM_OUTPUT_WEAK_ALIAS: Label Output. (line 401)
+* ASM_OUTPUT_WEAKREF: Label Output. (line 203)
+* ASM_PREFERRED_EH_DATA_FORMAT: Exception Handling. (line 67)
+* ASM_SPEC: Driver. (line 136)
+* ASM_STABD_OP: DBX Options. (line 36)
+* ASM_STABN_OP: DBX Options. (line 43)
+* ASM_STABS_OP: DBX Options. (line 29)
+* ASM_WEAKEN_DECL: Label Output. (line 195)
+* ASM_WEAKEN_LABEL: Label Output. (line 182)
+* assemble_name: Label Output. (line 8)
+* assemble_name_raw: Label Output. (line 16)
+* assembler format: File Framework. (line 6)
+* assembler instructions in RTL: Assembler. (line 6)
+* ASSEMBLER_DIALECT: Instruction Output. (line 146)
+* assigning attribute values to insns: Tagging Insns. (line 6)
+* assignment operator: Function Basics. (line 6)
+* asterisk in template: Output Statement. (line 29)
+* atan2M3 instruction pattern: Standard Names. (line 522)
+* attr <1>: Tagging Insns. (line 54)
+* attr: Expressions. (line 154)
+* attr_flag: Expressions. (line 119)
+* attribute expressions: Expressions. (line 6)
+* attribute specifications: Attr Example. (line 6)
+* attribute specifications example: Attr Example. (line 6)
+* ATTRIBUTE_ALIGNED_VALUE: Storage Layout. (line 183)
+* attributes: Attributes. (line 6)
+* attributes, defining: Defining Attributes.
+ (line 6)
+* attributes, target-specific: Target Attributes. (line 6)
+* autoincrement addressing, availability: Portability. (line 21)
+* autoincrement/decrement addressing: Simple Constraints. (line 30)
+* automata_option: Processor pipeline description.
+ (line 296)
+* automaton based pipeline description: Processor pipeline description.
+ (line 6)
+* automaton based scheduler: Processor pipeline description.
+ (line 6)
+* AVOID_CCMODE_COPIES: Values in Registers.
+ (line 153)
+* backslash: Output Template. (line 46)
+* barrier: Insns. (line 160)
+* barrier and /f: Flags. (line 125)
+* barrier and /v: Flags. (line 44)
+* BASE_REG_CLASS: Register Classes. (line 107)
+* basic block: Basic Blocks. (line 6)
+* basic-block.h: Control Flow. (line 6)
+* BASIC_BLOCK: Basic Blocks. (line 19)
+* basic_block: Basic Blocks. (line 6)
+* BB_HEAD, BB_END: Maintaining the CFG.
+ (line 88)
+* bb_seq: GIMPLE sequences. (line 73)
+* bCOND instruction pattern: Standard Names. (line 941)
+* BIGGEST_ALIGNMENT: Storage Layout. (line 173)
+* BIGGEST_FIELD_ALIGNMENT: Storage Layout. (line 194)
+* BImode: Machine Modes. (line 22)
+* BIND_EXPR: Expression trees. (line 6)
+* BINFO_TYPE: Classes. (line 6)
+* bit-fields: Bit-Fields. (line 6)
+* BIT_AND_EXPR: Expression trees. (line 6)
+* BIT_IOR_EXPR: Expression trees. (line 6)
+* BIT_NOT_EXPR: Expression trees. (line 6)
+* BIT_XOR_EXPR: Expression trees. (line 6)
+* BITFIELD_NBYTES_LIMITED: Storage Layout. (line 382)
+* BITS_BIG_ENDIAN: Storage Layout. (line 12)
+* BITS_BIG_ENDIAN, effect on sign_extract: Bit-Fields. (line 8)
+* BITS_PER_UNIT: Storage Layout. (line 52)
+* BITS_PER_WORD: Storage Layout. (line 57)
+* bitwise complement: Arithmetic. (line 149)
+* bitwise exclusive-or: Arithmetic. (line 163)
+* bitwise inclusive-or: Arithmetic. (line 158)
+* bitwise logical-and: Arithmetic. (line 153)
+* BLKmode: Machine Modes. (line 183)
+* BLKmode, and function return values: Calls. (line 23)
+* block statement iterators <1>: Maintaining the CFG.
+ (line 45)
+* block statement iterators: Basic Blocks. (line 68)
+* BLOCK_FOR_INSN, bb_for_stmt: Maintaining the CFG.
+ (line 40)
+* BLOCK_REG_PADDING: Register Arguments. (line 228)
+* blockage instruction pattern: Standard Names. (line 1408)
+* Blocks: Blocks. (line 6)
+* bool <1>: Exception Region Output.
+ (line 60)
+* bool: Sections. (line 280)
+* BOOL_TYPE_SIZE: Type Layout. (line 44)
+* BOOLEAN_TYPE: Types. (line 6)
+* branch prediction: Profile information.
+ (line 24)
+* BRANCH_COST: Costs. (line 52)
+* break_out_memory_refs: Addressing Modes. (line 130)
+* BREAK_STMT: Function Bodies. (line 6)
+* bsi_commit_edge_inserts: Maintaining the CFG.
+ (line 118)
+* bsi_end_p: Maintaining the CFG.
+ (line 60)
+* bsi_insert_after: Maintaining the CFG.
+ (line 72)
+* bsi_insert_before: Maintaining the CFG.
+ (line 78)
+* bsi_insert_on_edge: Maintaining the CFG.
+ (line 118)
+* bsi_last: Maintaining the CFG.
+ (line 56)
+* bsi_next: Maintaining the CFG.
+ (line 64)
+* bsi_prev: Maintaining the CFG.
+ (line 68)
+* bsi_remove: Maintaining the CFG.
+ (line 84)
+* bsi_start: Maintaining the CFG.
+ (line 52)
+* BSS_SECTION_ASM_OP: Sections. (line 68)
+* bswap: Arithmetic. (line 232)
+* btruncM2 instruction pattern: Standard Names. (line 540)
+* builtin_longjmp instruction pattern: Standard Names. (line 1313)
+* builtin_setjmp_receiver instruction pattern: Standard Names.
+ (line 1303)
+* builtin_setjmp_setup instruction pattern: Standard Names. (line 1292)
+* byte_mode: Machine Modes. (line 336)
+* BYTES_BIG_ENDIAN: Storage Layout. (line 24)
+* BYTES_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 221)
+* C statements for assembler output: Output Statement. (line 6)
+* C/C++ Internal Representation: Trees. (line 6)
+* C99 math functions, implicit usage: Library Calls. (line 76)
+* C_COMMON_OVERRIDE_OPTIONS: Run-time Target. (line 114)
+* c_register_pragma: Misc. (line 404)
+* c_register_pragma_with_expansion: Misc. (line 406)
+* call <1>: Side Effects. (line 86)
+* call: Flags. (line 234)
+* call instruction pattern: Standard Names. (line 974)
+* call usage: Calls. (line 10)
+* call, in call_insn: Flags. (line 33)
+* call, in mem: Flags. (line 99)
+* call-clobbered register: Register Basics. (line 35)
+* call-saved register: Register Basics. (line 35)
+* call-used register: Register Basics. (line 35)
+* CALL_EXPR: Expression trees. (line 6)
+* call_insn: Insns. (line 95)
+* call_insn and /c: Flags. (line 33)
+* call_insn and /f: Flags. (line 125)
+* call_insn and /i: Flags. (line 24)
+* call_insn and /j: Flags. (line 179)
+* call_insn and /s: Flags. (line 49)
+* call_insn and /u: Flags. (line 19)
+* call_insn and /u or /i: Flags. (line 29)
+* call_insn and /v: Flags. (line 44)
+* CALL_INSN_FUNCTION_USAGE: Insns. (line 101)
+* call_pop instruction pattern: Standard Names. (line 1002)
+* CALL_POPS_ARGS: Stack Arguments. (line 130)
+* CALL_REALLY_USED_REGISTERS: Register Basics. (line 46)
+* CALL_USED_REGISTERS: Register Basics. (line 35)
+* call_used_regs: Register Basics. (line 59)
+* call_value instruction pattern: Standard Names. (line 994)
+* call_value_pop instruction pattern: Standard Names. (line 1002)
+* CALLER_SAVE_PROFITABLE: Caller Saves. (line 11)
+* calling conventions: Stack and Calling. (line 6)
+* calling functions in RTL: Calls. (line 6)
+* can_create_pseudo_p: Standard Names. (line 75)
+* CAN_DEBUG_WITHOUT_FP: Run-time Target. (line 146)
+* CAN_ELIMINATE: Elimination. (line 71)
+* can_fallthru: Basic Blocks. (line 57)
+* canadian: Configure Terms. (line 6)
+* CANNOT_CHANGE_MODE_CLASS: Register Classes. (line 481)
+* CANNOT_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory.
+ (line 280)
+* canonicalization of instructions: Insn Canonicalizations.
+ (line 6)
+* CANONICALIZE_COMPARISON: Condition Code. (line 84)
+* canonicalize_funcptr_for_compare instruction pattern: Standard Names.
+ (line 1158)
+* CASE_USE_BIT_TESTS: Misc. (line 54)
+* CASE_VALUES_THRESHOLD: Misc. (line 47)
+* CASE_VECTOR_MODE: Misc. (line 27)
+* CASE_VECTOR_PC_RELATIVE: Misc. (line 40)
+* CASE_VECTOR_SHORTEN_MODE: Misc. (line 31)
+* casesi instruction pattern: Standard Names. (line 1082)
+* cbranchMODE4 instruction pattern: Standard Names. (line 963)
+* cc0: Regs and Memory. (line 307)
+* cc0, RTL sharing: Sharing. (line 27)
+* cc0_rtx: Regs and Memory. (line 333)
+* CC1_SPEC: Driver. (line 118)
+* CC1PLUS_SPEC: Driver. (line 126)
+* cc_status: Condition Code. (line 8)
+* CC_STATUS_MDEP: Condition Code. (line 19)
+* CC_STATUS_MDEP_INIT: Condition Code. (line 25)
+* CCmode: Machine Modes. (line 176)
+* CDImode: Machine Modes. (line 202)
+* CEIL_DIV_EXPR: Expression trees. (line 6)
+* CEIL_MOD_EXPR: Expression trees. (line 6)
+* ceilM2 instruction pattern: Standard Names. (line 556)
+* CFA_FRAME_BASE_OFFSET: Frame Layout. (line 226)
+* CFG, Control Flow Graph: Control Flow. (line 6)
+* cfghooks.h: Maintaining the CFG.
+ (line 6)
+* cgraph_finalize_function: Parsing pass. (line 52)
+* chain_circular: GTY Options. (line 195)
+* chain_next: GTY Options. (line 195)
+* chain_prev: GTY Options. (line 195)
+* change_address: Standard Names. (line 47)
+* CHANGE_DYNAMIC_TYPE_EXPR: Expression trees. (line 6)
+* char <1>: Misc. (line 685)
+* char <2>: PCH Target. (line 12)
+* char <3>: Sections. (line 272)
+* char: GIMPLE_ASM. (line 53)
+* CHAR_TYPE_SIZE: Type Layout. (line 39)
+* check_stack instruction pattern: Standard Names. (line 1245)
+* CHImode: Machine Modes. (line 202)
+* class: Classes. (line 6)
+* class definitions, register: Register Classes. (line 6)
+* class preference constraints: Class Preferences. (line 6)
+* CLASS_LIKELY_SPILLED_P: Register Classes. (line 452)
+* CLASS_MAX_NREGS: Register Classes. (line 469)
+* CLASS_TYPE_P: Types. (line 80)
+* classes of RTX codes: RTL Classes. (line 6)
+* CLASSTYPE_DECLARED_CLASS: Classes. (line 6)
+* CLASSTYPE_HAS_MUTABLE: Classes. (line 80)
+* CLASSTYPE_NON_POD_P: Classes. (line 85)
+* CLEANUP_DECL: Function Bodies. (line 6)
+* CLEANUP_EXPR: Function Bodies. (line 6)
+* CLEANUP_POINT_EXPR: Expression trees. (line 6)
+* CLEANUP_STMT: Function Bodies. (line 6)
+* Cleanups: Cleanups. (line 6)
+* CLEAR_BY_PIECES_P: Costs. (line 130)
+* clear_cache instruction pattern: Standard Names. (line 1553)
+* CLEAR_INSN_CACHE: Trampolines. (line 100)
+* CLEAR_RATIO: Costs. (line 121)
+* clobber: Side Effects. (line 100)
+* clz: Arithmetic. (line 208)
+* CLZ_DEFINED_VALUE_AT_ZERO: Misc. (line 319)
+* clzM2 instruction pattern: Standard Names. (line 621)
+* cmpM instruction pattern: Standard Names. (line 654)
+* cmpmemM instruction pattern: Standard Names. (line 769)
+* cmpstrM instruction pattern: Standard Names. (line 750)
+* cmpstrnM instruction pattern: Standard Names. (line 738)
+* code generation RTL sequences: Expander Definitions.
+ (line 6)
+* code iterators in .md files: Code Iterators. (line 6)
+* code_label: Insns. (line 119)
+* code_label and /i: Flags. (line 59)
+* code_label and /v: Flags. (line 44)
+* CODE_LABEL_NUMBER: Insns. (line 119)
+* codes, RTL expression: RTL Objects. (line 47)
+* COImode: Machine Modes. (line 202)
+* COLLECT2_HOST_INITIALIZATION: Host Misc. (line 32)
+* COLLECT_EXPORT_LIST: Misc. (line 767)
+* COLLECT_SHARED_FINI_FUNC: Macros for Initialization.
+ (line 44)
+* COLLECT_SHARED_INIT_FUNC: Macros for Initialization.
+ (line 33)
+* commit_edge_insertions: Maintaining the CFG.
+ (line 118)
+* compare: Arithmetic. (line 43)
+* compare, canonicalization of: Insn Canonicalizations.
+ (line 37)
+* comparison_operator: Machine-Independent Predicates.
+ (line 111)
+* compiler passes and files: Passes. (line 6)
+* complement, bitwise: Arithmetic. (line 149)
+* COMPLEX_CST: Expression trees. (line 6)
+* COMPLEX_EXPR: Expression trees. (line 6)
+* COMPLEX_TYPE: Types. (line 6)
+* COMPONENT_REF: Expression trees. (line 6)
+* Compound Expressions: Compound Expressions.
+ (line 6)
+* Compound Lvalues: Compound Lvalues. (line 6)
+* COMPOUND_EXPR: Expression trees. (line 6)
+* COMPOUND_LITERAL_EXPR: Expression trees. (line 6)
+* COMPOUND_LITERAL_EXPR_DECL: Expression trees. (line 608)
+* COMPOUND_LITERAL_EXPR_DECL_STMT: Expression trees. (line 608)
+* computed jump: Edges. (line 128)
+* computing the length of an insn: Insn Lengths. (line 6)
+* concat: Regs and Memory. (line 385)
+* concatn: Regs and Memory. (line 391)
+* cond: Comparisons. (line 90)
+* cond and attributes: Expressions. (line 37)
+* cond_exec: Side Effects. (line 248)
+* COND_EXPR: Expression trees. (line 6)
+* condition code register: Regs and Memory. (line 307)
+* condition code status: Condition Code. (line 6)
+* condition codes: Comparisons. (line 20)
+* conditional execution: Conditional Execution.
+ (line 6)
+* Conditional Expressions: Conditional Expressions.
+ (line 6)
+* CONDITIONAL_REGISTER_USAGE: Register Basics. (line 60)
+* conditional_trap instruction pattern: Standard Names. (line 1379)
+* conditions, in patterns: Patterns. (line 43)
+* configuration file <1>: Host Misc. (line 6)
+* configuration file: Filesystem. (line 6)
+* configure terms: Configure Terms. (line 6)
+* CONJ_EXPR: Expression trees. (line 6)
+* const: Constants. (line 99)
+* CONST0_RTX: Constants. (line 119)
+* const0_rtx: Constants. (line 16)
+* CONST1_RTX: Constants. (line 119)
+* const1_rtx: Constants. (line 16)
+* CONST2_RTX: Constants. (line 119)
+* const2_rtx: Constants. (line 16)
+* CONST_DECL: Declarations. (line 6)
+* const_double: Constants. (line 32)
+* const_double, RTL sharing: Sharing. (line 29)
+* CONST_DOUBLE_LOW: Constants. (line 39)
+* CONST_DOUBLE_OK_FOR_CONSTRAINT_P: Old Constraints. (line 69)
+* CONST_DOUBLE_OK_FOR_LETTER_P: Old Constraints. (line 54)
+* const_double_operand: Machine-Independent Predicates.
+ (line 21)
+* const_fixed: Constants. (line 52)
+* const_int: Constants. (line 8)
+* const_int and attribute tests: Expressions. (line 47)
+* const_int and attributes: Expressions. (line 10)
+* const_int, RTL sharing: Sharing. (line 23)
+* const_int_operand: Machine-Independent Predicates.
+ (line 16)
+* CONST_OK_FOR_CONSTRAINT_P: Old Constraints. (line 49)
+* CONST_OK_FOR_LETTER_P: Old Constraints. (line 40)
+* const_string: Constants. (line 71)
+* const_string and attributes: Expressions. (line 20)
+* const_true_rtx: Constants. (line 26)
+* const_vector: Constants. (line 59)
+* const_vector, RTL sharing: Sharing. (line 32)
+* constant attributes: Constant Attributes.
+ (line 6)
+* constant definitions: Constant Definitions.
+ (line 6)
+* CONSTANT_ADDRESS_P: Addressing Modes. (line 29)
+* CONSTANT_ALIGNMENT: Storage Layout. (line 241)
+* CONSTANT_P: Addressing Modes. (line 35)
+* CONSTANT_POOL_ADDRESS_P: Flags. (line 10)
+* CONSTANT_POOL_BEFORE_FUNCTION: Data Output. (line 64)
+* constants in constraints: Simple Constraints. (line 60)
+* constm1_rtx: Constants. (line 16)
+* constraint modifier characters: Modifiers. (line 6)
+* constraint, matching: Simple Constraints. (line 132)
+* CONSTRAINT_LEN: Old Constraints. (line 12)
+* constraint_num: C Constraint Interface.
+ (line 38)
+* constraint_satisfied_p: C Constraint Interface.
+ (line 54)
+* constraints: Constraints. (line 6)
+* constraints, defining: Define Constraints. (line 6)
+* constraints, defining, obsolete method: Old Constraints. (line 6)
+* constraints, machine specific: Machine Constraints.
+ (line 6)
+* constraints, testing: C Constraint Interface.
+ (line 6)
+* CONSTRUCTOR: Expression trees. (line 6)
+* constructor: Function Basics. (line 6)
+* constructors, automatic calls: Collect2. (line 15)
+* constructors, output of: Initialization. (line 6)
+* container: Containers. (line 6)
+* CONTINUE_STMT: Function Bodies. (line 6)
+* contributors: Contributors. (line 6)
+* controlling register usage: Register Basics. (line 76)
+* controlling the compilation driver: Driver. (line 6)
+* conventions, run-time: Interface. (line 6)
+* conversions: Conversions. (line 6)
+* CONVERT_EXPR: Expression trees. (line 6)
+* copy constructor: Function Basics. (line 6)
+* copy_rtx: Addressing Modes. (line 182)
+* copy_rtx_if_shared: Sharing. (line 64)
+* copysignM3 instruction pattern: Standard Names. (line 602)
+* cosM2 instruction pattern: Standard Names. (line 481)
+* costs of instructions: Costs. (line 6)
+* CP_INTEGRAL_TYPE: Types. (line 72)
+* cp_namespace_decls: Namespaces. (line 44)
+* CP_TYPE_CONST_NON_VOLATILE_P: Types. (line 45)
+* CP_TYPE_CONST_P: Types. (line 36)
+* CP_TYPE_QUALS: Types. (line 6)
+* CP_TYPE_RESTRICT_P: Types. (line 42)
+* CP_TYPE_VOLATILE_P: Types. (line 39)
+* CPLUSPLUS_CPP_SPEC: Driver. (line 113)
+* CPP_SPEC: Driver. (line 106)
+* CQImode: Machine Modes. (line 202)
+* cross compilation and floating point: Floating Point. (line 6)
+* CRT_CALL_STATIC_FUNCTION: Sections. (line 112)
+* CRTSTUFF_T_CFLAGS: Target Fragment. (line 35)
+* CRTSTUFF_T_CFLAGS_S: Target Fragment. (line 39)
+* CSImode: Machine Modes. (line 202)
+* CTImode: Machine Modes. (line 202)
+* ctz: Arithmetic. (line 216)
+* CTZ_DEFINED_VALUE_AT_ZERO: Misc. (line 320)
+* ctzM2 instruction pattern: Standard Names. (line 630)
+* CUMULATIVE_ARGS: Register Arguments. (line 127)
+* current_function_epilogue_delay_list: Function Entry. (line 181)
+* current_function_is_leaf: Leaf Functions. (line 51)
+* current_function_outgoing_args_size: Stack Arguments. (line 45)
+* current_function_pops_args: Function Entry. (line 106)
+* current_function_pretend_args_size: Function Entry. (line 112)
+* current_function_uses_only_leaf_regs: Leaf Functions. (line 51)
+* current_insn_predicate: Conditional Execution.
+ (line 26)
+* DAmode: Machine Modes. (line 152)
+* data bypass: Processor pipeline description.
+ (line 106)
+* data dependence delays: Processor pipeline description.
+ (line 6)
+* Data Dependency Analysis: Dependency analysis.
+ (line 6)
+* data structures: Per-Function Data. (line 6)
+* DATA_ALIGNMENT: Storage Layout. (line 228)
+* DATA_SECTION_ASM_OP: Sections. (line 53)
+* DBR_OUTPUT_SEQEND: Instruction Output. (line 107)
+* dbr_sequence_length: Instruction Output. (line 106)
+* DBX_BLOCKS_FUNCTION_RELATIVE: DBX Options. (line 103)
+* DBX_CONTIN_CHAR: DBX Options. (line 66)
+* DBX_CONTIN_LENGTH: DBX Options. (line 56)
+* DBX_DEBUGGING_INFO: DBX Options. (line 9)
+* DBX_FUNCTION_FIRST: DBX Options. (line 97)
+* DBX_LINES_FUNCTION_RELATIVE: DBX Options. (line 109)
+* DBX_NO_XREFS: DBX Options. (line 50)
+* DBX_OUTPUT_LBRAC: DBX Hooks. (line 9)
+* DBX_OUTPUT_MAIN_SOURCE_FILE_END: File Names and DBX. (line 34)
+* DBX_OUTPUT_MAIN_SOURCE_FILENAME: File Names and DBX. (line 9)
+* DBX_OUTPUT_NFUN: DBX Hooks. (line 18)
+* DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX.
+ (line 42)
+* DBX_OUTPUT_RBRAC: DBX Hooks. (line 15)
+* DBX_OUTPUT_SOURCE_LINE: DBX Hooks. (line 22)
+* DBX_REGISTER_NUMBER: All Debuggers. (line 9)
+* DBX_REGPARM_STABS_CODE: DBX Options. (line 87)
+* DBX_REGPARM_STABS_LETTER: DBX Options. (line 92)
+* DBX_STATIC_CONST_VAR_CODE: DBX Options. (line 82)
+* DBX_STATIC_STAB_DATA_SECTION: DBX Options. (line 73)
+* DBX_TYPE_DECL_STABS_CODE: DBX Options. (line 78)
+* DBX_USE_BINCL: DBX Options. (line 115)
+* DCmode: Machine Modes. (line 197)
+* DDmode: Machine Modes. (line 90)
+* De Morgan's law: Insn Canonicalizations.
+ (line 57)
+* dead_or_set_p: define_peephole. (line 65)
+* DEBUG_SYMS_TEXT: DBX Options. (line 25)
+* DEBUGGER_ARG_OFFSET: All Debuggers. (line 37)
+* DEBUGGER_AUTO_OFFSET: All Debuggers. (line 28)
+* decimal float library: Decimal float library routines.
+ (line 6)
+* DECL_ALIGN: Declarations. (line 6)
+* DECL_ANTICIPATED: Function Basics. (line 48)
+* DECL_ARGUMENTS: Function Basics. (line 163)
+* DECL_ARRAY_DELETE_OPERATOR_P: Function Basics. (line 184)
+* DECL_ARTIFICIAL <1>: Function Basics. (line 6)
+* DECL_ARTIFICIAL: Working with declarations.
+ (line 24)
+* DECL_ASSEMBLER_NAME: Function Basics. (line 6)
+* DECL_ATTRIBUTES: Attributes. (line 22)
+* DECL_BASE_CONSTRUCTOR_P: Function Basics. (line 94)
+* DECL_CLASS_SCOPE_P: Working with declarations.
+ (line 41)
+* DECL_COMPLETE_CONSTRUCTOR_P: Function Basics. (line 90)
+* DECL_COMPLETE_DESTRUCTOR_P: Function Basics. (line 104)
+* DECL_CONST_MEMFUNC_P: Function Basics. (line 77)
+* DECL_CONSTRUCTOR_P: Function Basics. (line 6)
+* DECL_CONTEXT: Namespaces. (line 26)
+* DECL_CONV_FN_P: Function Basics. (line 6)
+* DECL_COPY_CONSTRUCTOR_P: Function Basics. (line 98)
+* DECL_DESTRUCTOR_P: Function Basics. (line 6)
+* DECL_EXTERN_C_FUNCTION_P: Function Basics. (line 52)
+* DECL_EXTERNAL <1>: Function Basics. (line 38)
+* DECL_EXTERNAL: Declarations. (line 6)
+* DECL_FUNCTION_MEMBER_P: Function Basics. (line 6)
+* DECL_FUNCTION_SCOPE_P: Working with declarations.
+ (line 44)
+* DECL_FUNCTION_SPECIFIC_OPTIMIZATION: Function Basics. (line 6)
+* DECL_FUNCTION_SPECIFIC_TARGET: Function Basics. (line 6)
+* DECL_GLOBAL_CTOR_P: Function Basics. (line 6)
+* DECL_GLOBAL_DTOR_P: Function Basics. (line 6)
+* DECL_INITIAL: Declarations. (line 6)
+* DECL_LINKONCE_P: Function Basics. (line 6)
+* DECL_LOCAL_FUNCTION_P: Function Basics. (line 44)
+* DECL_MAIN_P: Function Basics. (line 7)
+* DECL_NAME <1>: Function Basics. (line 6)
+* DECL_NAME <2>: Working with declarations.
+ (line 7)
+* DECL_NAME: Namespaces. (line 15)
+* DECL_NAMESPACE_ALIAS: Namespaces. (line 30)
+* DECL_NAMESPACE_SCOPE_P: Working with declarations.
+ (line 37)
+* DECL_NAMESPACE_STD_P: Namespaces. (line 40)
+* DECL_NON_THUNK_FUNCTION_P: Function Basics. (line 144)
+* DECL_NONCONVERTING_P: Function Basics. (line 86)
+* DECL_NONSTATIC_MEMBER_FUNCTION_P: Function Basics. (line 74)
+* DECL_OVERLOADED_OPERATOR_P: Function Basics. (line 6)
+* DECL_RESULT: Function Basics. (line 168)
+* DECL_SIZE: Declarations. (line 6)
+* DECL_STATIC_FUNCTION_P: Function Basics. (line 71)
+* DECL_STMT: Function Bodies. (line 6)
+* DECL_STMT_DECL: Function Bodies. (line 6)
+* DECL_THUNK_P: Function Basics. (line 122)
+* DECL_VOLATILE_MEMFUNC_P: Function Basics. (line 80)
+* declaration: Declarations. (line 6)
+* declarations, RTL: RTL Declarations. (line 6)
+* DECLARE_LIBRARY_RENAMES: Library Calls. (line 9)
+* decrement_and_branch_until_zero instruction pattern: Standard Names.
+ (line 1120)
+* def_optype_d: Manipulating GIMPLE statements.
+ (line 94)
+* default: GTY Options. (line 81)
+* default_file_start: File Framework. (line 9)
+* DEFAULT_GDB_EXTENSIONS: DBX Options. (line 18)
+* DEFAULT_PCC_STRUCT_RETURN: Aggregate Return. (line 34)
+* DEFAULT_SIGNED_CHAR: Type Layout. (line 154)
+* define_address_constraint: Define Constraints. (line 107)
+* define_asm_attributes: Tagging Insns. (line 73)
+* define_attr: Defining Attributes.
+ (line 6)
+* define_automaton: Processor pipeline description.
+ (line 53)
+* define_bypass: Processor pipeline description.
+ (line 197)
+* define_code_attr: Code Iterators. (line 6)
+* define_code_iterator: Code Iterators. (line 6)
+* define_cond_exec: Conditional Execution.
+ (line 13)
+* define_constants: Constant Definitions.
+ (line 6)
+* define_constraint: Define Constraints. (line 48)
+* define_cpu_unit: Processor pipeline description.
+ (line 68)
+* define_delay: Delay Slots. (line 25)
+* define_expand: Expander Definitions.
+ (line 11)
+* define_insn: Patterns. (line 6)
+* define_insn example: Example. (line 6)
+* define_insn_and_split: Insn Splitting. (line 170)
+* define_insn_reservation: Processor pipeline description.
+ (line 106)
+* define_memory_constraint: Define Constraints. (line 88)
+* define_mode_attr: Substitutions. (line 6)
+* define_mode_iterator: Defining Mode Iterators.
+ (line 6)
+* define_peephole: define_peephole. (line 6)
+* define_peephole2: define_peephole2. (line 6)
+* define_predicate: Defining Predicates.
+ (line 6)
+* define_query_cpu_unit: Processor pipeline description.
+ (line 90)
+* define_register_constraint: Define Constraints. (line 28)
+* define_reservation: Processor pipeline description.
+ (line 186)
+* define_special_predicate: Defining Predicates.
+ (line 6)
+* define_split: Insn Splitting. (line 32)
+* defining attributes and their values: Defining Attributes.
+ (line 6)
+* defining constraints: Define Constraints. (line 6)
+* defining constraints, obsolete method: Old Constraints. (line 6)
+* defining jump instruction patterns: Jump Patterns. (line 6)
+* defining looping instruction patterns: Looping Patterns. (line 6)
+* defining peephole optimizers: Peephole Definitions.
+ (line 6)
+* defining predicates: Defining Predicates.
+ (line 6)
+* defining RTL sequences for code generation: Expander Definitions.
+ (line 6)
+* delay slots, defining: Delay Slots. (line 6)
+* DELAY_SLOTS_FOR_EPILOGUE: Function Entry. (line 163)
+* deletable: GTY Options. (line 149)
+* DELETE_IF_ORDINARY: Filesystem. (line 79)
+* Dependent Patterns: Dependent Patterns. (line 6)
+* desc: GTY Options. (line 81)
+* destructor: Function Basics. (line 6)
+* destructors, output of: Initialization. (line 6)
+* deterministic finite state automaton: Processor pipeline description.
+ (line 6)
+* DF_SIZE: Type Layout. (line 130)
+* DFmode: Machine Modes. (line 73)
+* digits in constraint: Simple Constraints. (line 120)
+* DImode: Machine Modes. (line 45)
+* DIR_SEPARATOR: Filesystem. (line 18)
+* DIR_SEPARATOR_2: Filesystem. (line 19)
+* directory options .md: Including Patterns. (line 44)
+* disabling certain registers: Register Basics. (line 76)
+* dispatch table: Dispatch Tables. (line 8)
+* div: Arithmetic. (line 111)
+* div and attributes: Expressions. (line 64)
+* division: Arithmetic. (line 111)
+* divM3 instruction pattern: Standard Names. (line 222)
+* divmodM4 instruction pattern: Standard Names. (line 411)
+* DO_BODY: Function Bodies. (line 6)
+* DO_COND: Function Bodies. (line 6)
+* DO_STMT: Function Bodies. (line 6)
+* DOLLARS_IN_IDENTIFIERS: Misc. (line 488)
+* doloop_begin instruction pattern: Standard Names. (line 1151)
+* doloop_end instruction pattern: Standard Names. (line 1130)
+* DONE: Expander Definitions.
+ (line 74)
+* DONT_USE_BUILTIN_SETJMP: Exception Region Output.
+ (line 70)
+* DOUBLE_TYPE_SIZE: Type Layout. (line 53)
+* DQmode: Machine Modes. (line 115)
+* driver: Driver. (line 6)
+* DRIVER_SELF_SPECS: Driver. (line 71)
+* DUMPFILE_FORMAT: Filesystem. (line 67)
+* DWARF2_ASM_LINE_DEBUG_INFO: SDB and DWARF. (line 36)
+* DWARF2_DEBUGGING_INFO: SDB and DWARF. (line 13)
+* DWARF2_FRAME_INFO: SDB and DWARF. (line 30)
+* DWARF2_FRAME_REG_OUT: Frame Registers. (line 133)
+* DWARF2_UNWIND_INFO: Exception Region Output.
+ (line 40)
+* DWARF_ALT_FRAME_RETURN_COLUMN: Frame Layout. (line 152)
+* DWARF_CIE_DATA_ALIGNMENT: Exception Region Output.
+ (line 75)
+* DWARF_FRAME_REGISTERS: Frame Registers. (line 93)
+* DWARF_FRAME_REGNUM: Frame Registers. (line 125)
+* DWARF_REG_TO_UNWIND_COLUMN: Frame Registers. (line 117)
+* DWARF_ZERO_REG: Frame Layout. (line 163)
+* DYNAMIC_CHAIN_ADDRESS: Frame Layout. (line 92)
+* E in constraint: Simple Constraints. (line 79)
+* earlyclobber operand: Modifiers. (line 25)
+* edge: Edges. (line 6)
+* edge in the flow graph: Edges. (line 6)
+* edge iterators: Edges. (line 15)
+* edge splitting: Maintaining the CFG.
+ (line 118)
+* EDGE_ABNORMAL: Edges. (line 128)
+* EDGE_ABNORMAL, EDGE_ABNORMAL_CALL: Edges. (line 171)
+* EDGE_ABNORMAL, EDGE_EH: Edges. (line 96)
+* EDGE_ABNORMAL, EDGE_SIBCALL: Edges. (line 122)
+* EDGE_FALLTHRU, force_nonfallthru: Edges. (line 86)
+* EDOM, implicit usage: Library Calls. (line 58)
+* EH_FRAME_IN_DATA_SECTION: Exception Region Output.
+ (line 20)
+* EH_FRAME_SECTION_NAME: Exception Region Output.
+ (line 10)
+* eh_return instruction pattern: Standard Names. (line 1319)
+* EH_RETURN_DATA_REGNO: Exception Handling. (line 7)
+* EH_RETURN_HANDLER_RTX: Exception Handling. (line 39)
+* EH_RETURN_STACKADJ_RTX: Exception Handling. (line 22)
+* EH_TABLES_CAN_BE_READ_ONLY: Exception Region Output.
+ (line 29)
+* EH_USES: Function Entry. (line 158)
+* ei_edge: Edges. (line 43)
+* ei_end_p: Edges. (line 27)
+* ei_last: Edges. (line 23)
+* ei_next: Edges. (line 35)
+* ei_one_before_end_p: Edges. (line 31)
+* ei_prev: Edges. (line 39)
+* ei_safe_safe: Edges. (line 47)
+* ei_start: Edges. (line 19)
+* ELIGIBLE_FOR_EPILOGUE_DELAY: Function Entry. (line 169)
+* ELIMINABLE_REGS: Elimination. (line 44)
+* ELSE_CLAUSE: Function Bodies. (line 6)
+* Embedded C: Fixed-point fractional library routines.
+ (line 6)
+* EMIT_MODE_SET: Mode Switching. (line 74)
+* Empty Statements: Empty Statements. (line 6)
+* EMPTY_CLASS_EXPR: Function Bodies. (line 6)
+* EMPTY_FIELD_BOUNDARY: Storage Layout. (line 295)
+* Emulated TLS: Emulated TLS. (line 6)
+* ENABLE_EXECUTE_STACK: Trampolines. (line 110)
+* enabled: Disable Insn Alternatives.
+ (line 6)
+* ENDFILE_SPEC: Driver. (line 218)
+* endianness: Portability. (line 21)
+* ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR: Basic Blocks. (line 28)
+* enum machine_mode: Machine Modes. (line 6)
+* enum reg_class: Register Classes. (line 65)
+* ENUMERAL_TYPE: Types. (line 6)
+* epilogue: Function Entry. (line 6)
+* epilogue instruction pattern: Standard Names. (line 1351)
+* EPILOGUE_USES: Function Entry. (line 152)
+* eq: Comparisons. (line 52)
+* eq and attributes: Expressions. (line 64)
+* eq_attr: Expressions. (line 85)
+* EQ_EXPR: Expression trees. (line 6)
+* equal: Comparisons. (line 52)
+* errno, implicit usage: Library Calls. (line 70)
+* EXACT_DIV_EXPR: Expression trees. (line 6)
+* examining SSA_NAMEs: SSA. (line 218)
+* exception handling <1>: Exception Handling. (line 6)
+* exception handling: Edges. (line 96)
+* exception_receiver instruction pattern: Standard Names. (line 1283)
+* exclamation point: Multi-Alternative. (line 47)
+* exclusion_set: Processor pipeline description.
+ (line 215)
+* exclusive-or, bitwise: Arithmetic. (line 163)
+* EXIT_EXPR: Expression trees. (line 6)
+* EXIT_IGNORE_STACK: Function Entry. (line 140)
+* expander definitions: Expander Definitions.
+ (line 6)
+* expM2 instruction pattern: Standard Names. (line 497)
+* expr_list: Insns. (line 505)
+* EXPR_STMT: Function Bodies. (line 6)
+* EXPR_STMT_EXPR: Function Bodies. (line 6)
+* expression: Expression trees. (line 6)
+* expression codes: RTL Objects. (line 47)
+* extendMN2 instruction pattern: Standard Names. (line 826)
+* extensible constraints: Simple Constraints. (line 163)
+* EXTRA_ADDRESS_CONSTRAINT: Old Constraints. (line 123)
+* EXTRA_CONSTRAINT: Old Constraints. (line 74)
+* EXTRA_CONSTRAINT_STR: Old Constraints. (line 95)
+* EXTRA_MEMORY_CONSTRAINT: Old Constraints. (line 100)
+* EXTRA_SPECS: Driver. (line 245)
+* extv instruction pattern: Standard Names. (line 862)
+* extzv instruction pattern: Standard Names. (line 877)
+* F in constraint: Simple Constraints. (line 84)
+* FAIL: Expander Definitions.
+ (line 80)
+* fall-thru: Edges. (line 69)
+* FATAL_EXIT_CODE: Host Misc. (line 6)
+* FDL, GNU Free Documentation License: GNU Free Documentation License.
+ (line 6)
+* features, optional, in system conventions: Run-time Target.
+ (line 59)
+* ffs: Arithmetic. (line 202)
+* ffsM2 instruction pattern: Standard Names. (line 611)
+* FIELD_DECL: Declarations. (line 6)
+* file_end_indicate_exec_stack: File Framework. (line 41)
+* files and passes of the compiler: Passes. (line 6)
+* files, generated: Files. (line 6)
+* final_absence_set: Processor pipeline description.
+ (line 215)
+* FINAL_PRESCAN_INSN: Instruction Output. (line 46)
+* final_presence_set: Processor pipeline description.
+ (line 215)
+* final_scan_insn: Function Entry. (line 181)
+* final_sequence: Instruction Output. (line 117)
+* FIND_BASE_TERM: Addressing Modes. (line 110)
+* FINI_ARRAY_SECTION_ASM_OP: Sections. (line 105)
+* FINI_SECTION_ASM_OP: Sections. (line 90)
+* finite state automaton minimization: Processor pipeline description.
+ (line 296)
+* FIRST_PARM_OFFSET: Frame Layout. (line 67)
+* FIRST_PARM_OFFSET and virtual registers: Regs and Memory. (line 65)
+* FIRST_PSEUDO_REGISTER: Register Basics. (line 9)
+* FIRST_STACK_REG: Stack Registers. (line 23)
+* FIRST_VIRTUAL_REGISTER: Regs and Memory. (line 51)
+* fix: Conversions. (line 66)
+* FIX_TRUNC_EXPR: Expression trees. (line 6)
+* fix_truncMN2 instruction pattern: Standard Names. (line 813)
+* fixed register: Register Basics. (line 15)
+* fixed-point fractional library: Fixed-point fractional library routines.
+ (line 6)
+* FIXED_CONVERT_EXPR: Expression trees. (line 6)
+* FIXED_CST: Expression trees. (line 6)
+* FIXED_POINT_TYPE: Types. (line 6)
+* FIXED_REGISTERS: Register Basics. (line 15)
+* fixed_regs: Register Basics. (line 59)
+* fixMN2 instruction pattern: Standard Names. (line 793)
+* FIXUNS_TRUNC_LIKE_FIX_TRUNC: Misc. (line 100)
+* fixuns_truncMN2 instruction pattern: Standard Names. (line 817)
+* fixunsMN2 instruction pattern: Standard Names. (line 802)
+* flags in RTL expression: Flags. (line 6)
+* float: Conversions. (line 58)
+* FLOAT_EXPR: Expression trees. (line 6)
+* float_extend: Conversions. (line 33)
+* FLOAT_LIB_COMPARE_RETURNS_BOOL: Library Calls. (line 25)
+* FLOAT_STORE_FLAG_VALUE: Misc. (line 301)
+* float_truncate: Conversions. (line 53)
+* FLOAT_TYPE_SIZE: Type Layout. (line 49)
+* FLOAT_WORDS_BIG_ENDIAN: Storage Layout. (line 43)
+* FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory.
+ (line 226)
+* floating point and cross compilation: Floating Point. (line 6)
+* Floating Point Emulation: Target Fragment. (line 15)
+* floating point emulation library, US Software GOFAST: Library Calls.
+ (line 44)
+* floatMN2 instruction pattern: Standard Names. (line 785)
+* floatunsMN2 instruction pattern: Standard Names. (line 789)
+* FLOOR_DIV_EXPR: Expression trees. (line 6)
+* FLOOR_MOD_EXPR: Expression trees. (line 6)
+* floorM2 instruction pattern: Standard Names. (line 532)
+* flow-insensitive alias analysis: Alias analysis. (line 6)
+* flow-sensitive alias analysis: Alias analysis. (line 6)
+* fmodM3 instruction pattern: Standard Names. (line 463)
+* FOR_BODY: Function Bodies. (line 6)
+* FOR_COND: Function Bodies. (line 6)
+* FOR_EXPR: Function Bodies. (line 6)
+* FOR_INIT_STMT: Function Bodies. (line 6)
+* FOR_STMT: Function Bodies. (line 6)
+* FORCE_CODE_SECTION_ALIGN: Sections. (line 136)
+* force_reg: Standard Names. (line 36)
+* fract_convert: Conversions. (line 82)
+* FRACT_TYPE_SIZE: Type Layout. (line 68)
+* fractional types: Fixed-point fractional library routines.
+ (line 6)
+* fractMN2 instruction pattern: Standard Names. (line 835)
+* fractunsMN2 instruction pattern: Standard Names. (line 850)
+* frame layout: Frame Layout. (line 6)
+* FRAME_ADDR_RTX: Frame Layout. (line 116)
+* FRAME_GROWS_DOWNWARD: Frame Layout. (line 31)
+* FRAME_GROWS_DOWNWARD and virtual registers: Regs and Memory.
+ (line 69)
+* FRAME_POINTER_CFA_OFFSET: Frame Layout. (line 212)
+* frame_pointer_needed: Function Entry. (line 34)
+* FRAME_POINTER_REGNUM: Frame Registers. (line 14)
+* FRAME_POINTER_REGNUM and virtual registers: Regs and Memory.
+ (line 74)
+* FRAME_POINTER_REQUIRED: Elimination. (line 9)
+* frame_pointer_rtx: Frame Registers. (line 85)
+* frame_related: Flags. (line 242)
+* frame_related, in insn, call_insn, jump_insn, barrier, and set: Flags.
+ (line 125)
+* frame_related, in mem: Flags. (line 103)
+* frame_related, in reg: Flags. (line 112)
+* frame_related, in symbol_ref: Flags. (line 183)
+* frequency, count, BB_FREQ_BASE: Profile information.
+ (line 30)
+* ftruncM2 instruction pattern: Standard Names. (line 808)
+* function: Functions. (line 6)
+* function body: Function Bodies. (line 6)
+* function call conventions: Interface. (line 6)
+* function entry and exit: Function Entry. (line 6)
+* function entry point, alternate function entry point: Edges.
+ (line 180)
+* function-call insns: Calls. (line 6)
+* FUNCTION_ARG: Register Arguments. (line 11)
+* FUNCTION_ARG_ADVANCE: Register Arguments. (line 185)
+* FUNCTION_ARG_BOUNDARY: Register Arguments. (line 238)
+* FUNCTION_ARG_OFFSET: Register Arguments. (line 196)
+* FUNCTION_ARG_PADDING: Register Arguments. (line 203)
+* FUNCTION_ARG_REGNO_P: Register Arguments. (line 243)
+* FUNCTION_BOUNDARY: Storage Layout. (line 170)
+* FUNCTION_DECL: Functions. (line 6)
+* FUNCTION_INCOMING_ARG: Register Arguments. (line 68)
+* FUNCTION_MODE: Misc. (line 356)
+* FUNCTION_OUTGOING_VALUE: Scalar Return. (line 56)
+* FUNCTION_PROFILER: Profiling. (line 9)
+* FUNCTION_TYPE: Types. (line 6)
+* FUNCTION_VALUE: Scalar Return. (line 52)
+* FUNCTION_VALUE_REGNO_P: Scalar Return. (line 69)
+* functions, leaf: Leaf Functions. (line 6)
+* fundamental type: Types. (line 6)
+* g in constraint: Simple Constraints. (line 110)
+* G in constraint: Simple Constraints. (line 88)
+* garbage collector, invocation: Invoking the garbage collector.
+ (line 6)
+* GCC and portability: Portability. (line 6)
+* GCC_DRIVER_HOST_INITIALIZATION: Host Misc. (line 36)
+* gcov_type: Profile information.
+ (line 41)
+* ge: Comparisons. (line 72)
+* ge and attributes: Expressions. (line 64)
+* GE_EXPR: Expression trees. (line 6)
+* GEN_ERRNO_RTX: Library Calls. (line 71)
+* gencodes: RTL passes. (line 18)
+* general_operand: Machine-Independent Predicates.
+ (line 105)
+* GENERAL_REGS: Register Classes. (line 23)
+* generated files: Files. (line 6)
+* generating assembler output: Output Statement. (line 6)
+* generating insns: RTL Template. (line 6)
+* GENERIC <1>: GENERIC. (line 6)
+* GENERIC <2>: Gimplification pass.
+ (line 12)
+* GENERIC: Parsing pass. (line 6)
+* generic predicates: Machine-Independent Predicates.
+ (line 6)
+* genflags: RTL passes. (line 18)
+* get_attr: Expressions. (line 80)
+* get_attr_length: Insn Lengths. (line 46)
+* GET_CLASS_NARROWEST_MODE: Machine Modes. (line 333)
+* GET_CODE: RTL Objects. (line 47)
+* get_frame_size: Elimination. (line 31)
+* get_insns: Insns. (line 34)
+* get_last_insn: Insns. (line 34)
+* GET_MODE: Machine Modes. (line 280)
+* GET_MODE_ALIGNMENT: Machine Modes. (line 320)
+* GET_MODE_BITSIZE: Machine Modes. (line 304)
+* GET_MODE_CLASS: Machine Modes. (line 294)
+* GET_MODE_FBIT: Machine Modes. (line 311)
+* GET_MODE_IBIT: Machine Modes. (line 307)
+* GET_MODE_MASK: Machine Modes. (line 315)
+* GET_MODE_NAME: Machine Modes. (line 291)
+* GET_MODE_NUNITS: Machine Modes. (line 329)
+* GET_MODE_SIZE: Machine Modes. (line 301)
+* GET_MODE_UNIT_SIZE: Machine Modes. (line 323)
+* GET_MODE_WIDER_MODE: Machine Modes. (line 297)
+* GET_RTX_CLASS: RTL Classes. (line 6)
+* GET_RTX_FORMAT: RTL Classes. (line 130)
+* GET_RTX_LENGTH: RTL Classes. (line 127)
+* geu: Comparisons. (line 72)
+* geu and attributes: Expressions. (line 64)
+* GGC: Type Information. (line 6)
+* ggc_collect: Invoking the garbage collector.
+ (line 6)
+* GIMPLE <1>: GIMPLE. (line 6)
+* GIMPLE <2>: Gimplification pass.
+ (line 6)
+* GIMPLE: Parsing pass. (line 14)
+* GIMPLE Exception Handling: GIMPLE Exception Handling.
+ (line 6)
+* GIMPLE instruction set: GIMPLE instruction set.
+ (line 6)
+* GIMPLE sequences: GIMPLE sequences. (line 6)
+* gimple_addresses_taken: Manipulating GIMPLE statements.
+ (line 90)
+* GIMPLE_ASM: GIMPLE_ASM. (line 6)
+* gimple_asm_clear_volatile: GIMPLE_ASM. (line 63)
+* gimple_asm_clobber_op: GIMPLE_ASM. (line 46)
+* gimple_asm_input_op: GIMPLE_ASM. (line 30)
+* gimple_asm_output_op: GIMPLE_ASM. (line 38)
+* gimple_asm_set_clobber_op: GIMPLE_ASM. (line 50)
+* gimple_asm_set_input_op: GIMPLE_ASM. (line 34)
+* gimple_asm_set_output_op: GIMPLE_ASM. (line 42)
+* gimple_asm_set_volatile: GIMPLE_ASM. (line 60)
+* gimple_asm_volatile_p: GIMPLE_ASM. (line 57)
+* GIMPLE_ASSIGN: GIMPLE_ASSIGN. (line 6)
+* gimple_assign_cast_p: GIMPLE_ASSIGN. (line 89)
+* gimple_assign_lhs: GIMPLE_ASSIGN. (line 51)
+* gimple_assign_rhs1: GIMPLE_ASSIGN. (line 57)
+* gimple_assign_rhs2: GIMPLE_ASSIGN. (line 64)
+* gimple_assign_set_lhs: GIMPLE_ASSIGN. (line 71)
+* gimple_assign_set_rhs1: GIMPLE_ASSIGN. (line 74)
+* gimple_assign_set_rhs2: GIMPLE_ASSIGN. (line 85)
+* gimple_bb: Manipulating GIMPLE statements.
+ (line 18)
+* GIMPLE_BIND: GIMPLE_BIND. (line 6)
+* gimple_bind_add_seq: GIMPLE_BIND. (line 36)
+* gimple_bind_add_stmt: GIMPLE_BIND. (line 32)
+* gimple_bind_append_vars: GIMPLE_BIND. (line 19)
+* gimple_bind_block: GIMPLE_BIND. (line 40)
+* gimple_bind_body: GIMPLE_BIND. (line 23)
+* gimple_bind_set_block: GIMPLE_BIND. (line 45)
+* gimple_bind_set_body: GIMPLE_BIND. (line 28)
+* gimple_bind_set_vars: GIMPLE_BIND. (line 15)
+* gimple_bind_vars: GIMPLE_BIND. (line 12)
+* gimple_block: Manipulating GIMPLE statements.
+ (line 21)
+* gimple_build_asm: GIMPLE_ASM. (line 8)
+* gimple_build_asm_vec: GIMPLE_ASM. (line 17)
+* gimple_build_assign: GIMPLE_ASSIGN. (line 7)
+* gimple_build_assign_with_ops: GIMPLE_ASSIGN. (line 30)
+* gimple_build_bind: GIMPLE_BIND. (line 8)
+* gimple_build_call: GIMPLE_CALL. (line 8)
+* gimple_build_call_from_tree: GIMPLE_CALL. (line 16)
+* gimple_build_call_vec: GIMPLE_CALL. (line 25)
+* gimple_build_catch: GIMPLE_CATCH. (line 8)
+* gimple_build_cdt: GIMPLE_CHANGE_DYNAMIC_TYPE.
+ (line 7)
+* gimple_build_cond: GIMPLE_COND. (line 8)
+* gimple_build_cond_from_tree: GIMPLE_COND. (line 16)
+* gimple_build_eh_filter: GIMPLE_EH_FILTER. (line 8)
+* gimple_build_goto: GIMPLE_LABEL. (line 18)
+* gimple_build_label: GIMPLE_LABEL. (line 7)
+* gimple_build_nop: GIMPLE_NOP. (line 7)
+* gimple_build_omp_atomic_load: GIMPLE_OMP_ATOMIC_LOAD.
+ (line 8)
+* gimple_build_omp_atomic_store: GIMPLE_OMP_ATOMIC_STORE.
+ (line 7)
+* gimple_build_omp_continue: GIMPLE_OMP_CONTINUE.
+ (line 8)
+* gimple_build_omp_critical: GIMPLE_OMP_CRITICAL.
+ (line 8)
+* gimple_build_omp_for: GIMPLE_OMP_FOR. (line 9)
+* gimple_build_omp_master: GIMPLE_OMP_MASTER. (line 7)
+* gimple_build_omp_ordered: GIMPLE_OMP_ORDERED. (line 7)
+* gimple_build_omp_parallel: GIMPLE_OMP_PARALLEL.
+ (line 8)
+* gimple_build_omp_return: GIMPLE_OMP_RETURN. (line 7)
+* gimple_build_omp_section: GIMPLE_OMP_SECTION. (line 7)
+* gimple_build_omp_sections: GIMPLE_OMP_SECTIONS.
+ (line 8)
+* gimple_build_omp_sections_switch: GIMPLE_OMP_SECTIONS.
+ (line 14)
+* gimple_build_omp_single: GIMPLE_OMP_SINGLE. (line 8)
+* gimple_build_resx: GIMPLE_RESX. (line 7)
+* gimple_build_return: GIMPLE_RETURN. (line 7)
+* gimple_build_switch: GIMPLE_SWITCH. (line 8)
+* gimple_build_switch_vec: GIMPLE_SWITCH. (line 16)
+* gimple_build_try: GIMPLE_TRY. (line 8)
+* gimple_build_wce: GIMPLE_WITH_CLEANUP_EXPR.
+ (line 7)
+* GIMPLE_CALL: GIMPLE_CALL. (line 6)
+* gimple_call_arg: GIMPLE_CALL. (line 66)
+* gimple_call_cannot_inline_p: GIMPLE_CALL. (line 91)
+* gimple_call_chain: GIMPLE_CALL. (line 57)
+* gimple_call_copy_skip_args: GIMPLE_CALL. (line 98)
+* gimple_call_fn: GIMPLE_CALL. (line 38)
+* gimple_call_fndecl: GIMPLE_CALL. (line 46)
+* gimple_call_lhs: GIMPLE_CALL. (line 29)
+* gimple_call_mark_uninlinable: GIMPLE_CALL. (line 88)
+* gimple_call_noreturn_p: GIMPLE_CALL. (line 94)
+* gimple_call_return_type: GIMPLE_CALL. (line 54)
+* gimple_call_set_arg: GIMPLE_CALL. (line 76)
+* gimple_call_set_chain: GIMPLE_CALL. (line 60)
+* gimple_call_set_fn: GIMPLE_CALL. (line 42)
+* gimple_call_set_fndecl: GIMPLE_CALL. (line 51)
+* gimple_call_set_lhs: GIMPLE_CALL. (line 35)
+* gimple_call_set_tail: GIMPLE_CALL. (line 80)
+* gimple_call_tail_p: GIMPLE_CALL. (line 85)
+* GIMPLE_CATCH: GIMPLE_CATCH. (line 6)
+* gimple_catch_handler: GIMPLE_CATCH. (line 20)
+* gimple_catch_set_handler: GIMPLE_CATCH. (line 28)
+* gimple_catch_set_types: GIMPLE_CATCH. (line 24)
+* gimple_catch_types: GIMPLE_CATCH. (line 13)
+* gimple_cdt_location: GIMPLE_CHANGE_DYNAMIC_TYPE.
+ (line 24)
+* gimple_cdt_new_type: GIMPLE_CHANGE_DYNAMIC_TYPE.
+ (line 11)
+* gimple_cdt_set_location: GIMPLE_CHANGE_DYNAMIC_TYPE.
+ (line 32)
+* gimple_cdt_set_new_type: GIMPLE_CHANGE_DYNAMIC_TYPE.
+ (line 20)
+* GIMPLE_CHANGE_DYNAMIC_TYPE: GIMPLE_CHANGE_DYNAMIC_TYPE.
+ (line 6)
+* gimple_code: Manipulating GIMPLE statements.
+ (line 15)
+* GIMPLE_COND: GIMPLE_COND. (line 6)
+* gimple_cond_false_label: GIMPLE_COND. (line 60)
+* gimple_cond_lhs: GIMPLE_COND. (line 30)
+* gimple_cond_make_false: GIMPLE_COND. (line 64)
+* gimple_cond_make_true: GIMPLE_COND. (line 67)
+* gimple_cond_rhs: GIMPLE_COND. (line 38)
+* gimple_cond_set_code: GIMPLE_COND. (line 26)
+* gimple_cond_set_false_label: GIMPLE_COND. (line 56)
+* gimple_cond_set_lhs: GIMPLE_COND. (line 34)
+* gimple_cond_set_rhs: GIMPLE_COND. (line 42)
+* gimple_cond_set_true_label: GIMPLE_COND. (line 51)
+* gimple_cond_true_label: GIMPLE_COND. (line 46)
+* gimple_copy: Manipulating GIMPLE statements.
+ (line 147)
+* GIMPLE_EH_FILTER: GIMPLE_EH_FILTER. (line 6)
+* gimple_eh_filter_failure: GIMPLE_EH_FILTER. (line 19)
+* gimple_eh_filter_must_not_throw: GIMPLE_EH_FILTER. (line 33)
+* gimple_eh_filter_set_failure: GIMPLE_EH_FILTER. (line 29)
+* gimple_eh_filter_set_must_not_throw: GIMPLE_EH_FILTER. (line 37)
+* gimple_eh_filter_set_types: GIMPLE_EH_FILTER. (line 24)
+* gimple_eh_filter_types: GIMPLE_EH_FILTER. (line 12)
+* gimple_expr_type: Manipulating GIMPLE statements.
+ (line 24)
+* gimple_goto_dest: GIMPLE_LABEL. (line 21)
+* gimple_goto_set_dest: GIMPLE_LABEL. (line 24)
+* gimple_has_mem_ops: Manipulating GIMPLE statements.
+ (line 72)
+* gimple_has_ops: Manipulating GIMPLE statements.
+ (line 69)
+* gimple_has_volatile_ops: Manipulating GIMPLE statements.
+ (line 134)
+* GIMPLE_LABEL: GIMPLE_LABEL. (line 6)
+* gimple_label_label: GIMPLE_LABEL. (line 11)
+* gimple_label_set_label: GIMPLE_LABEL. (line 14)
+* gimple_loaded_syms: Manipulating GIMPLE statements.
+ (line 122)
+* gimple_locus: Manipulating GIMPLE statements.
+ (line 42)
+* gimple_locus_empty_p: Manipulating GIMPLE statements.
+ (line 48)
+* gimple_modified_p: Manipulating GIMPLE statements.
+ (line 130)
+* gimple_no_warning_p: Manipulating GIMPLE statements.
+ (line 51)
+* GIMPLE_NOP: GIMPLE_NOP. (line 6)
+* gimple_nop_p: GIMPLE_NOP. (line 10)
+* gimple_num_ops <1>: Manipulating GIMPLE statements.
+ (line 75)
+* gimple_num_ops: Logical Operators. (line 76)
+* GIMPLE_OMP_ATOMIC_LOAD: GIMPLE_OMP_ATOMIC_LOAD.
+ (line 6)
+* gimple_omp_atomic_load_lhs: GIMPLE_OMP_ATOMIC_LOAD.
+ (line 17)
+* gimple_omp_atomic_load_rhs: GIMPLE_OMP_ATOMIC_LOAD.
+ (line 24)
+* gimple_omp_atomic_load_set_lhs: GIMPLE_OMP_ATOMIC_LOAD.
+ (line 14)
+* gimple_omp_atomic_load_set_rhs: GIMPLE_OMP_ATOMIC_LOAD.
+ (line 21)
+* GIMPLE_OMP_ATOMIC_STORE: GIMPLE_OMP_ATOMIC_STORE.
+ (line 6)
+* gimple_omp_atomic_store_set_val: GIMPLE_OMP_ATOMIC_STORE.
+ (line 12)
+* gimple_omp_atomic_store_val: GIMPLE_OMP_ATOMIC_STORE.
+ (line 15)
+* gimple_omp_body: GIMPLE_OMP_PARALLEL.
+ (line 24)
+* GIMPLE_OMP_CONTINUE: GIMPLE_OMP_CONTINUE.
+ (line 6)
+* gimple_omp_continue_control_def: GIMPLE_OMP_CONTINUE.
+ (line 13)
+* gimple_omp_continue_control_def_ptr: GIMPLE_OMP_CONTINUE.
+ (line 17)
+* gimple_omp_continue_control_use: GIMPLE_OMP_CONTINUE.
+ (line 24)
+* gimple_omp_continue_control_use_ptr: GIMPLE_OMP_CONTINUE.
+ (line 28)
+* gimple_omp_continue_set_control_def: GIMPLE_OMP_CONTINUE.
+ (line 20)
+* gimple_omp_continue_set_control_use: GIMPLE_OMP_CONTINUE.
+ (line 31)
+* GIMPLE_OMP_CRITICAL: GIMPLE_OMP_CRITICAL.
+ (line 6)
+* gimple_omp_critical_name: GIMPLE_OMP_CRITICAL.
+ (line 13)
+* gimple_omp_critical_set_name: GIMPLE_OMP_CRITICAL.
+ (line 21)
+* GIMPLE_OMP_FOR: GIMPLE_OMP_FOR. (line 6)
+* gimple_omp_for_clauses: GIMPLE_OMP_FOR. (line 20)
+* gimple_omp_for_final: GIMPLE_OMP_FOR. (line 51)
+* gimple_omp_for_incr: GIMPLE_OMP_FOR. (line 61)
+* gimple_omp_for_index: GIMPLE_OMP_FOR. (line 31)
+* gimple_omp_for_initial: GIMPLE_OMP_FOR. (line 41)
+* gimple_omp_for_pre_body: GIMPLE_OMP_FOR. (line 70)
+* gimple_omp_for_set_clauses: GIMPLE_OMP_FOR. (line 27)
+* gimple_omp_for_set_cond: GIMPLE_OMP_FOR. (line 80)
+* gimple_omp_for_set_final: GIMPLE_OMP_FOR. (line 58)
+* gimple_omp_for_set_incr: GIMPLE_OMP_FOR. (line 67)
+* gimple_omp_for_set_index: GIMPLE_OMP_FOR. (line 38)
+* gimple_omp_for_set_initial: GIMPLE_OMP_FOR. (line 48)
+* gimple_omp_for_set_pre_body: GIMPLE_OMP_FOR. (line 75)
+* GIMPLE_OMP_MASTER: GIMPLE_OMP_MASTER. (line 6)
+* GIMPLE_OMP_ORDERED: GIMPLE_OMP_ORDERED. (line 6)
+* GIMPLE_OMP_PARALLEL: GIMPLE_OMP_PARALLEL.
+ (line 6)
+* gimple_omp_parallel_child_fn: GIMPLE_OMP_PARALLEL.
+ (line 42)
+* gimple_omp_parallel_clauses: GIMPLE_OMP_PARALLEL.
+ (line 31)
+* gimple_omp_parallel_combined_p: GIMPLE_OMP_PARALLEL.
+ (line 16)
+* gimple_omp_parallel_data_arg: GIMPLE_OMP_PARALLEL.
+ (line 54)
+* gimple_omp_parallel_set_child_fn: GIMPLE_OMP_PARALLEL.
+ (line 51)
+* gimple_omp_parallel_set_clauses: GIMPLE_OMP_PARALLEL.
+ (line 38)
+* gimple_omp_parallel_set_combined_p: GIMPLE_OMP_PARALLEL.
+ (line 20)
+* gimple_omp_parallel_set_data_arg: GIMPLE_OMP_PARALLEL.
+ (line 62)
+* GIMPLE_OMP_RETURN: GIMPLE_OMP_RETURN. (line 6)
+* gimple_omp_return_nowait_p: GIMPLE_OMP_RETURN. (line 14)
+* gimple_omp_return_set_nowait: GIMPLE_OMP_RETURN. (line 11)
+* GIMPLE_OMP_SECTION: GIMPLE_OMP_SECTION. (line 6)
+* gimple_omp_section_last_p: GIMPLE_OMP_SECTION. (line 12)
+* gimple_omp_section_set_last: GIMPLE_OMP_SECTION. (line 16)
+* GIMPLE_OMP_SECTIONS: GIMPLE_OMP_SECTIONS.
+ (line 6)
+* gimple_omp_sections_clauses: GIMPLE_OMP_SECTIONS.
+ (line 30)
+* gimple_omp_sections_control: GIMPLE_OMP_SECTIONS.
+ (line 17)
+* gimple_omp_sections_set_clauses: GIMPLE_OMP_SECTIONS.
+ (line 37)
+* gimple_omp_sections_set_control: GIMPLE_OMP_SECTIONS.
+ (line 26)
+* gimple_omp_set_body: GIMPLE_OMP_PARALLEL.
+ (line 28)
+* GIMPLE_OMP_SINGLE: GIMPLE_OMP_SINGLE. (line 6)
+* gimple_omp_single_clauses: GIMPLE_OMP_SINGLE. (line 14)
+* gimple_omp_single_set_clauses: GIMPLE_OMP_SINGLE. (line 21)
+* gimple_op <1>: Manipulating GIMPLE statements.
+ (line 81)
+* gimple_op: Logical Operators. (line 79)
+* GIMPLE_PHI: GIMPLE_PHI. (line 6)
+* gimple_phi_capacity: GIMPLE_PHI. (line 10)
+* gimple_phi_num_args: GIMPLE_PHI. (line 14)
+* gimple_phi_result: GIMPLE_PHI. (line 19)
+* gimple_phi_set_arg: GIMPLE_PHI. (line 33)
+* gimple_phi_set_result: GIMPLE_PHI. (line 25)
+* GIMPLE_RESX: GIMPLE_RESX. (line 6)
+* gimple_resx_region: GIMPLE_RESX. (line 13)
+* gimple_resx_set_region: GIMPLE_RESX. (line 16)
+* GIMPLE_RETURN: GIMPLE_RETURN. (line 6)
+* gimple_return_retval: GIMPLE_RETURN. (line 10)
+* gimple_return_set_retval: GIMPLE_RETURN. (line 14)
+* gimple_rhs_class: GIMPLE_ASSIGN. (line 46)
+* gimple_seq_add_seq: GIMPLE sequences. (line 32)
+* gimple_seq_add_stmt: GIMPLE sequences. (line 26)
+* gimple_seq_alloc: GIMPLE sequences. (line 62)
+* gimple_seq_copy: GIMPLE sequences. (line 67)
+* gimple_seq_deep_copy: GIMPLE sequences. (line 37)
+* gimple_seq_empty_p: GIMPLE sequences. (line 70)
+* gimple_seq_first: GIMPLE sequences. (line 44)
+* gimple_seq_init: GIMPLE sequences. (line 59)
+* gimple_seq_last: GIMPLE sequences. (line 47)
+* gimple_seq_reverse: GIMPLE sequences. (line 40)
+* gimple_seq_set_first: GIMPLE sequences. (line 55)
+* gimple_seq_set_last: GIMPLE sequences. (line 51)
+* gimple_seq_singleton_p: GIMPLE sequences. (line 79)
+* gimple_set_block: Manipulating GIMPLE statements.
+ (line 39)
+* gimple_set_def_ops: Manipulating GIMPLE statements.
+ (line 98)
+* gimple_set_has_volatile_ops: Manipulating GIMPLE statements.
+ (line 138)
+* gimple_set_locus: Manipulating GIMPLE statements.
+ (line 45)
+* gimple_set_op: Manipulating GIMPLE statements.
+ (line 87)
+* gimple_set_plf: Manipulating GIMPLE statements.
+ (line 62)
+* gimple_set_use_ops: Manipulating GIMPLE statements.
+ (line 105)
+* gimple_set_vdef_ops: Manipulating GIMPLE statements.
+ (line 119)
+* gimple_set_visited: Manipulating GIMPLE statements.
+ (line 55)
+* gimple_set_vuse_ops: Manipulating GIMPLE statements.
+ (line 112)
+* gimple_statement_base: Tuple representation.
+ (line 14)
+* gimple_statement_with_ops: Tuple representation.
+ (line 96)
+* gimple_stored_syms: Manipulating GIMPLE statements.
+ (line 126)
+* GIMPLE_SWITCH: GIMPLE_SWITCH. (line 6)
+* gimple_switch_default_label: GIMPLE_SWITCH. (line 46)
+* gimple_switch_index: GIMPLE_SWITCH. (line 31)
+* gimple_switch_label: GIMPLE_SWITCH. (line 37)
+* gimple_switch_num_labels: GIMPLE_SWITCH. (line 22)
+* gimple_switch_set_default_label: GIMPLE_SWITCH. (line 50)
+* gimple_switch_set_index: GIMPLE_SWITCH. (line 34)
+* gimple_switch_set_label: GIMPLE_SWITCH. (line 42)
+* gimple_switch_set_num_labels: GIMPLE_SWITCH. (line 27)
+* GIMPLE_TRY: GIMPLE_TRY. (line 6)
+* gimple_try_catch_is_cleanup: GIMPLE_TRY. (line 20)
+* gimple_try_cleanup: GIMPLE_TRY. (line 27)
+* gimple_try_eval: GIMPLE_TRY. (line 23)
+* gimple_try_flags: GIMPLE_TRY. (line 16)
+* gimple_try_set_catch_is_cleanup: GIMPLE_TRY. (line 32)
+* gimple_try_set_cleanup: GIMPLE_TRY. (line 41)
+* gimple_try_set_eval: GIMPLE_TRY. (line 36)
+* gimple_visited_p: Manipulating GIMPLE statements.
+ (line 58)
+* gimple_wce_cleanup: GIMPLE_WITH_CLEANUP_EXPR.
+ (line 11)
+* gimple_wce_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR.
+ (line 18)
+* gimple_wce_set_cleanup: GIMPLE_WITH_CLEANUP_EXPR.
+ (line 15)
+* gimple_wce_set_cleanup_eh_only: GIMPLE_WITH_CLEANUP_EXPR.
+ (line 22)
+* GIMPLE_WITH_CLEANUP_EXPR: GIMPLE_WITH_CLEANUP_EXPR.
+ (line 6)
+* gimplification <1>: Gimplification pass.
+ (line 6)
+* gimplification: Parsing pass. (line 14)
+* gimplifier: Parsing pass. (line 14)
+* gimplify_assign: GIMPLE_ASSIGN. (line 19)
+* gimplify_expr: Gimplification pass.
+ (line 18)
+* gimplify_function_tree: Gimplification pass.
+ (line 18)
+* GLOBAL_INIT_PRIORITY: Function Basics. (line 6)
+* global_regs: Register Basics. (line 59)
+* GO_IF_LEGITIMATE_ADDRESS: Addressing Modes. (line 48)
+* GO_IF_MODE_DEPENDENT_ADDRESS: Addressing Modes. (line 190)
+* GOFAST, floating point emulation library: Library Calls. (line 44)
+* gofast_maybe_init_libfuncs: Library Calls. (line 44)
+* greater than: Comparisons. (line 60)
+* gsi_after_labels: Sequence iterators. (line 76)
+* gsi_bb: Sequence iterators. (line 83)
+* gsi_commit_edge_inserts: Sequence iterators. (line 194)
+* gsi_commit_one_edge_insert: Sequence iterators. (line 190)
+* gsi_end_p: Sequence iterators. (line 60)
+* gsi_for_stmt: Sequence iterators. (line 157)
+* gsi_insert_after: Sequence iterators. (line 147)
+* gsi_insert_before: Sequence iterators. (line 136)
+* gsi_insert_on_edge: Sequence iterators. (line 174)
+* gsi_insert_on_edge_immediate: Sequence iterators. (line 185)
+* gsi_insert_seq_after: Sequence iterators. (line 154)
+* gsi_insert_seq_before: Sequence iterators. (line 143)
+* gsi_insert_seq_on_edge: Sequence iterators. (line 179)
+* gsi_last: Sequence iterators. (line 50)
+* gsi_last_bb: Sequence iterators. (line 56)
+* gsi_link_after: Sequence iterators. (line 115)
+* gsi_link_before: Sequence iterators. (line 105)
+* gsi_link_seq_after: Sequence iterators. (line 110)
+* gsi_link_seq_before: Sequence iterators. (line 99)
+* gsi_move_after: Sequence iterators. (line 161)
+* gsi_move_before: Sequence iterators. (line 166)
+* gsi_move_to_bb_end: Sequence iterators. (line 171)
+* gsi_next: Sequence iterators. (line 66)
+* gsi_one_before_end_p: Sequence iterators. (line 63)
+* gsi_prev: Sequence iterators. (line 69)
+* gsi_remove: Sequence iterators. (line 90)
+* gsi_replace: Sequence iterators. (line 130)
+* gsi_seq: Sequence iterators. (line 86)
+* gsi_split_seq_after: Sequence iterators. (line 120)
+* gsi_split_seq_before: Sequence iterators. (line 125)
+* gsi_start: Sequence iterators. (line 40)
+* gsi_start_bb: Sequence iterators. (line 46)
+* gsi_stmt: Sequence iterators. (line 72)
+* gt: Comparisons. (line 60)
+* gt and attributes: Expressions. (line 64)
+* GT_EXPR: Expression trees. (line 6)
+* gtu: Comparisons. (line 64)
+* gtu and attributes: Expressions. (line 64)
+* GTY: Type Information. (line 6)
+* H in constraint: Simple Constraints. (line 88)
+* HAmode: Machine Modes. (line 144)
+* HANDLE_PRAGMA_PACK_PUSH_POP: Misc. (line 467)
+* HANDLE_PRAGMA_PACK_WITH_EXPANSION: Misc. (line 478)
+* HANDLE_SYSV_PRAGMA: Misc. (line 438)
+* HANDLER: Function Bodies. (line 6)
+* HANDLER_BODY: Function Bodies. (line 6)
+* HANDLER_PARMS: Function Bodies. (line 6)
+* hard registers: Regs and Memory. (line 9)
+* HARD_FRAME_POINTER_REGNUM: Frame Registers. (line 20)
+* HARD_REGNO_CALL_PART_CLOBBERED: Register Basics. (line 53)
+* HARD_REGNO_CALLER_SAVE_MODE: Caller Saves. (line 20)
+* HARD_REGNO_MODE_OK: Values in Registers.
+ (line 58)
+* HARD_REGNO_NREGS: Values in Registers.
+ (line 11)
+* HARD_REGNO_NREGS_HAS_PADDING: Values in Registers.
+ (line 25)
+* HARD_REGNO_NREGS_WITH_PADDING: Values in Registers.
+ (line 43)
+* HARD_REGNO_RENAME_OK: Values in Registers.
+ (line 119)
+* HAS_INIT_SECTION: Macros for Initialization.
+ (line 19)
+* HAS_LONG_COND_BRANCH: Misc. (line 9)
+* HAS_LONG_UNCOND_BRANCH: Misc. (line 18)
+* HAVE_DOS_BASED_FILE_SYSTEM: Filesystem. (line 11)
+* HAVE_POST_DECREMENT: Addressing Modes. (line 12)
+* HAVE_POST_INCREMENT: Addressing Modes. (line 11)
+* HAVE_POST_MODIFY_DISP: Addressing Modes. (line 18)
+* HAVE_POST_MODIFY_REG: Addressing Modes. (line 24)
+* HAVE_PRE_DECREMENT: Addressing Modes. (line 10)
+* HAVE_PRE_INCREMENT: Addressing Modes. (line 9)
+* HAVE_PRE_MODIFY_DISP: Addressing Modes. (line 17)
+* HAVE_PRE_MODIFY_REG: Addressing Modes. (line 23)
+* HCmode: Machine Modes. (line 197)
+* HFmode: Machine Modes. (line 58)
+* high: Constants. (line 109)
+* HImode: Machine Modes. (line 29)
+* HImode, in insn: Insns. (line 231)
+* host configuration: Host Config. (line 6)
+* host functions: Host Common. (line 6)
+* host hooks: Host Common. (line 6)
+* host makefile fragment: Host Fragment. (line 6)
+* HOST_BIT_BUCKET: Filesystem. (line 51)
+* HOST_EXECUTABLE_SUFFIX: Filesystem. (line 45)
+* HOST_HOOKS_EXTRA_SIGNALS: Host Common. (line 12)
+* HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY: Host Common. (line 45)
+* HOST_HOOKS_GT_PCH_USE_ADDRESS: Host Common. (line 26)
+* HOST_LACKS_INODE_NUMBERS: Filesystem. (line 89)
+* HOST_LONG_LONG_FORMAT: Host Misc. (line 41)
+* HOST_OBJECT_SUFFIX: Filesystem. (line 40)
+* HOST_WIDE_INT: Anchored Addresses. (line 33)
+* HOT_TEXT_SECTION_NAME: Sections. (line 43)
+* HQmode: Machine Modes. (line 107)
+* I in constraint: Simple Constraints. (line 71)
+* i in constraint: Simple Constraints. (line 60)
+* identifier: Identifiers. (line 6)
+* IDENTIFIER_LENGTH: Identifiers. (line 20)
+* IDENTIFIER_NODE: Identifiers. (line 6)
+* IDENTIFIER_OPNAME_P: Identifiers. (line 25)
+* IDENTIFIER_POINTER: Identifiers. (line 15)
+* IDENTIFIER_TYPENAME_P: Identifiers. (line 31)
+* IEEE 754-2008: Decimal float library routines.
+ (line 6)
+* IF_COND: Function Bodies. (line 6)
+* if_marked: GTY Options. (line 155)
+* IF_STMT: Function Bodies. (line 6)
+* if_then_else: Comparisons. (line 80)
+* if_then_else and attributes: Expressions. (line 32)
+* if_then_else usage: Side Effects. (line 56)
+* IFCVT_EXTRA_FIELDS: Misc. (line 619)
+* IFCVT_INIT_EXTRA_FIELDS: Misc. (line 614)
+* IFCVT_MODIFY_CANCEL: Misc. (line 608)
+* IFCVT_MODIFY_FINAL: Misc. (line 602)
+* IFCVT_MODIFY_INSN: Misc. (line 596)
+* IFCVT_MODIFY_MULTIPLE_TESTS: Misc. (line 589)
+* IFCVT_MODIFY_TESTS: Misc. (line 578)
+* IMAGPART_EXPR: Expression trees. (line 6)
+* Immediate Uses: SSA Operands. (line 274)
+* immediate_operand: Machine-Independent Predicates.
+ (line 11)
+* IMMEDIATE_PREFIX: Instruction Output. (line 127)
+* in_struct: Flags. (line 258)
+* in_struct, in code_label and note: Flags. (line 59)
+* in_struct, in insn and jump_insn and call_insn: Flags. (line 49)
+* in_struct, in insn, jump_insn and call_insn: Flags. (line 166)
+* in_struct, in mem: Flags. (line 70)
+* in_struct, in subreg: Flags. (line 205)
+* include: Including Patterns. (line 6)
+* INCLUDE_DEFAULTS: Driver. (line 430)
+* inclusive-or, bitwise: Arithmetic. (line 158)
+* INCOMING_FRAME_SP_OFFSET: Frame Layout. (line 183)
+* INCOMING_REGNO: Register Basics. (line 91)
+* INCOMING_RETURN_ADDR_RTX: Frame Layout. (line 139)
+* INCOMING_STACK_BOUNDARY: Storage Layout. (line 165)
+* INDEX_REG_CLASS: Register Classes. (line 134)
+* indirect_jump instruction pattern: Standard Names. (line 1078)
+* indirect_operand: Machine-Independent Predicates.
+ (line 71)
+* INDIRECT_REF: Expression trees. (line 6)
+* INIT_ARRAY_SECTION_ASM_OP: Sections. (line 98)
+* INIT_CUMULATIVE_ARGS: Register Arguments. (line 149)
+* INIT_CUMULATIVE_INCOMING_ARGS: Register Arguments. (line 176)
+* INIT_CUMULATIVE_LIBCALL_ARGS: Register Arguments. (line 170)
+* INIT_ENVIRONMENT: Driver. (line 369)
+* INIT_EXPANDERS: Per-Function Data. (line 39)
+* INIT_EXPR: Expression trees. (line 6)
+* init_machine_status: Per-Function Data. (line 45)
+* init_one_libfunc: Library Calls. (line 15)
+* INIT_SECTION_ASM_OP <1>: Macros for Initialization.
+ (line 10)
+* INIT_SECTION_ASM_OP: Sections. (line 82)
+* INITIAL_ELIMINATION_OFFSET: Elimination. (line 79)
+* INITIAL_FRAME_ADDRESS_RTX: Frame Layout. (line 83)
+* INITIAL_FRAME_POINTER_OFFSET: Elimination. (line 32)
+* initialization routines: Initialization. (line 6)
+* INITIALIZE_TRAMPOLINE: Trampolines. (line 55)
+* inlining: Target Attributes. (line 86)
+* insert_insn_on_edge: Maintaining the CFG.
+ (line 118)
+* insn: Insns. (line 63)
+* insn and /f: Flags. (line 125)
+* insn and /j: Flags. (line 175)
+* insn and /s: Flags. (line 49)
+* insn and /u: Flags. (line 39)
+* insn and /v: Flags. (line 44)
+* insn attributes: Insn Attributes. (line 6)
+* insn canonicalization: Insn Canonicalizations.
+ (line 6)
+* insn includes: Including Patterns. (line 6)
+* insn lengths, computing: Insn Lengths. (line 6)
+* insn splitting: Insn Splitting. (line 6)
+* insn-attr.h: Defining Attributes.
+ (line 24)
+* INSN_ANNULLED_BRANCH_P: Flags. (line 39)
+* INSN_CODE: Insns. (line 257)
+* INSN_DELETED_P: Flags. (line 44)
+* INSN_FROM_TARGET_P: Flags. (line 49)
+* insn_list: Insns. (line 505)
+* INSN_REFERENCES_ARE_DELAYED: Misc. (line 517)
+* INSN_SETS_ARE_DELAYED: Misc. (line 506)
+* INSN_UID: Insns. (line 23)
+* insns: Insns. (line 6)
+* insns, generating: RTL Template. (line 6)
+* insns, recognizing: RTL Template. (line 6)
+* instruction attributes: Insn Attributes. (line 6)
+* instruction latency time: Processor pipeline description.
+ (line 6)
+* instruction patterns: Patterns. (line 6)
+* instruction splitting: Insn Splitting. (line 6)
+* insv instruction pattern: Standard Names. (line 880)
+* int <1>: Run-time Target. (line 56)
+* int: Manipulating GIMPLE statements.
+ (line 66)
+* INT_TYPE_SIZE: Type Layout. (line 12)
+* INTEGER_CST: Expression trees. (line 6)
+* INTEGER_TYPE: Types. (line 6)
+* Interdependence of Patterns: Dependent Patterns. (line 6)
+* interfacing to GCC output: Interface. (line 6)
+* interlock delays: Processor pipeline description.
+ (line 6)
+* intermediate representation lowering: Parsing pass. (line 14)
+* INTMAX_TYPE: Type Layout. (line 213)
+* introduction: Top. (line 6)
+* INVOKE__main: Macros for Initialization.
+ (line 51)
+* ior: Arithmetic. (line 158)
+* ior and attributes: Expressions. (line 50)
+* ior, canonicalization of: Insn Canonicalizations.
+ (line 57)
+* iorM3 instruction pattern: Standard Names. (line 222)
+* IRA_COVER_CLASSES: Register Classes. (line 516)
+* IRA_HARD_REGNO_ADD_COST_MULTIPLIER: Allocation Order. (line 37)
+* IS_ASM_LOGICAL_LINE_SEPARATOR: Data Output. (line 120)
+* is_gimple_omp: GIMPLE_OMP_PARALLEL.
+ (line 65)
+* iterators in .md files: Iterators. (line 6)
+* IV analysis on GIMPLE: Scalar evolutions. (line 6)
+* IV analysis on RTL: loop-iv. (line 6)
+* jump: Flags. (line 309)
+* jump instruction pattern: Standard Names. (line 969)
+* jump instruction patterns: Jump Patterns. (line 6)
+* jump instructions and set: Side Effects. (line 56)
+* jump, in call_insn: Flags. (line 179)
+* jump, in insn: Flags. (line 175)
+* jump, in mem: Flags. (line 79)
+* JUMP_ALIGN: Alignment Output. (line 9)
+* jump_insn: Insns. (line 73)
+* jump_insn and /f: Flags. (line 125)
+* jump_insn and /s: Flags. (line 49)
+* jump_insn and /u: Flags. (line 39)
+* jump_insn and /v: Flags. (line 44)
+* JUMP_LABEL: Insns. (line 80)
+* JUMP_TABLES_IN_TEXT_SECTION: Sections. (line 142)
+* Jumps: Jumps. (line 6)
+* LABEL_ALIGN: Alignment Output. (line 52)
+* LABEL_ALIGN_AFTER_BARRIER: Alignment Output. (line 22)
+* LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output. (line 30)
+* LABEL_ALIGN_MAX_SKIP: Alignment Output. (line 62)
+* LABEL_ALT_ENTRY_P: Insns. (line 140)
+* LABEL_ALTERNATE_NAME: Edges. (line 180)
+* LABEL_DECL: Declarations. (line 6)
+* LABEL_KIND: Insns. (line 140)
+* LABEL_NUSES: Insns. (line 136)
+* LABEL_PRESERVE_P: Flags. (line 59)
+* label_ref: Constants. (line 86)
+* label_ref and /v: Flags. (line 65)
+* label_ref, RTL sharing: Sharing. (line 35)
+* LABEL_REF_NONLOCAL_P: Flags. (line 65)
+* lang_hooks.gimplify_expr: Gimplification pass.
+ (line 18)
+* lang_hooks.parse_file: Parsing pass. (line 6)
+* language-independent intermediate representation: Parsing pass.
+ (line 14)
+* large return values: Aggregate Return. (line 6)
+* LARGEST_EXPONENT_IS_NORMAL: Storage Layout. (line 469)
+* LAST_STACK_REG: Stack Registers. (line 27)
+* LAST_VIRTUAL_REGISTER: Regs and Memory. (line 51)
+* lceilMN2: Standard Names. (line 597)
+* LCSSA: LCSSA. (line 6)
+* LD_FINI_SWITCH: Macros for Initialization.
+ (line 29)
+* LD_INIT_SWITCH: Macros for Initialization.
+ (line 25)
+* LDD_SUFFIX: Macros for Initialization.
+ (line 116)
+* le: Comparisons. (line 76)
+* le and attributes: Expressions. (line 64)
+* LE_EXPR: Expression trees. (line 6)
+* leaf functions: Leaf Functions. (line 6)
+* leaf_function_p: Standard Names. (line 1040)
+* LEAF_REG_REMAP: Leaf Functions. (line 39)
+* LEAF_REGISTERS: Leaf Functions. (line 25)
+* left rotate: Arithmetic. (line 190)
+* left shift: Arithmetic. (line 168)
+* LEGITIMATE_CONSTANT_P: Addressing Modes. (line 205)
+* LEGITIMATE_PIC_OPERAND_P: PIC. (line 31)
+* LEGITIMIZE_ADDRESS: Addressing Modes. (line 122)
+* LEGITIMIZE_RELOAD_ADDRESS: Addressing Modes. (line 145)
+* length: GTY Options. (line 50)
+* less than: Comparisons. (line 68)
+* less than or equal: Comparisons. (line 76)
+* leu: Comparisons. (line 76)
+* leu and attributes: Expressions. (line 64)
+* lfloorMN2: Standard Names. (line 592)
+* LIB2FUNCS_EXTRA: Target Fragment. (line 11)
+* LIB_SPEC: Driver. (line 170)
+* LIBCALL_VALUE: Scalar Return. (line 60)
+* libgcc.a: Library Calls. (line 6)
+* LIBGCC2_CFLAGS: Target Fragment. (line 8)
+* LIBGCC2_HAS_DF_MODE: Type Layout. (line 109)
+* LIBGCC2_HAS_TF_MODE: Type Layout. (line 123)
+* LIBGCC2_HAS_XF_MODE: Type Layout. (line 117)
+* LIBGCC2_LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 103)
+* LIBGCC2_UNWIND_ATTRIBUTE: Misc. (line 929)
+* LIBGCC2_WORDS_BIG_ENDIAN: Storage Layout. (line 36)
+* LIBGCC_SPEC: Driver. (line 178)
+* library subroutine names: Library Calls. (line 6)
+* LIBRARY_PATH_ENV: Misc. (line 557)
+* LIMIT_RELOAD_CLASS: Register Classes. (line 239)
+* Linear loop transformations framework: Lambda. (line 6)
+* LINK_COMMAND_SPEC: Driver. (line 299)
+* LINK_EH_SPEC: Driver. (line 205)
+* LINK_ELIMINATE_DUPLICATE_LDIRECTORIES: Driver. (line 309)
+* LINK_GCC_C_SEQUENCE_SPEC: Driver. (line 295)
+* LINK_LIBGCC_SPECIAL_1: Driver. (line 290)
+* LINK_SPEC: Driver. (line 163)
+* linkage: Function Basics. (line 6)
+* list: Containers. (line 6)
+* Liveness representation: Liveness information.
+ (line 6)
+* lo_sum: Arithmetic. (line 24)
+* load address instruction: Simple Constraints. (line 154)
+* LOAD_EXTEND_OP: Misc. (line 69)
+* load_multiple instruction pattern: Standard Names. (line 137)
+* LOCAL_ALIGNMENT: Storage Layout. (line 254)
+* LOCAL_CLASS_P: Classes. (line 68)
+* LOCAL_DECL_ALIGNMENT: Storage Layout. (line 278)
+* LOCAL_INCLUDE_DIR: Driver. (line 376)
+* LOCAL_LABEL_PREFIX: Instruction Output. (line 125)
+* LOCAL_REGNO: Register Basics. (line 105)
+* LOG_LINKS: Insns. (line 276)
+* Logical Operators: Logical Operators. (line 6)
+* logical-and, bitwise: Arithmetic. (line 153)
+* logM2 instruction pattern: Standard Names. (line 505)
+* LONG_ACCUM_TYPE_SIZE: Type Layout. (line 93)
+* LONG_DOUBLE_TYPE_SIZE: Type Layout. (line 58)
+* LONG_FRACT_TYPE_SIZE: Type Layout. (line 73)
+* LONG_LONG_ACCUM_TYPE_SIZE: Type Layout. (line 98)
+* LONG_LONG_FRACT_TYPE_SIZE: Type Layout. (line 78)
+* LONG_LONG_TYPE_SIZE: Type Layout. (line 33)
+* LONG_TYPE_SIZE: Type Layout. (line 22)
+* longjmp and automatic variables: Interface. (line 52)
+* Loop analysis: Loop representation.
+ (line 6)
+* Loop manipulation: Loop manipulation. (line 6)
+* Loop querying: Loop querying. (line 6)
+* Loop representation: Loop representation.
+ (line 6)
+* Loop-closed SSA form: LCSSA. (line 6)
+* LOOP_ALIGN: Alignment Output. (line 35)
+* LOOP_ALIGN_MAX_SKIP: Alignment Output. (line 48)
+* LOOP_EXPR: Expression trees. (line 6)
+* looping instruction patterns: Looping Patterns. (line 6)
+* lowering, language-dependent intermediate representation: Parsing pass.
+ (line 14)
+* lrintMN2: Standard Names. (line 582)
+* lroundMN2: Standard Names. (line 587)
+* LSHIFT_EXPR: Expression trees. (line 6)
+* lshiftrt: Arithmetic. (line 185)
+* lshiftrt and attributes: Expressions. (line 64)
+* lshrM3 instruction pattern: Standard Names. (line 441)
+* lt: Comparisons. (line 68)
+* lt and attributes: Expressions. (line 64)
+* LT_EXPR: Expression trees. (line 6)
+* LTGT_EXPR: Expression trees. (line 6)
+* ltu: Comparisons. (line 68)
+* m in constraint: Simple Constraints. (line 17)
+* machine attributes: Target Attributes. (line 6)
+* machine description macros: Target Macros. (line 6)
+* machine descriptions: Machine Desc. (line 6)
+* machine mode conversions: Conversions. (line 6)
+* machine modes: Machine Modes. (line 6)
+* machine specific constraints: Machine Constraints.
+ (line 6)
+* machine-independent predicates: Machine-Independent Predicates.
+ (line 6)
+* machine_mode: Condition Code. (line 157)
+* macros, target description: Target Macros. (line 6)
+* maddMN4 instruction pattern: Standard Names. (line 364)
+* MAKE_DECL_ONE_ONLY: Label Output. (line 218)
+* make_phi_node: GIMPLE_PHI. (line 7)
+* make_safe_from: Expander Definitions.
+ (line 148)
+* makefile fragment: Fragments. (line 6)
+* makefile targets: Makefile. (line 6)
+* MALLOC_ABI_ALIGNMENT: Storage Layout. (line 179)
+* Manipulating GIMPLE statements: Manipulating GIMPLE statements.
+ (line 6)
+* mark_hook: GTY Options. (line 170)
+* marking roots: GGC Roots. (line 6)
+* MASK_RETURN_ADDR: Exception Region Output.
+ (line 35)
+* match_dup <1>: define_peephole2. (line 28)
+* match_dup: RTL Template. (line 73)
+* match_dup and attributes: Insn Lengths. (line 16)
+* match_op_dup: RTL Template. (line 163)
+* match_operand: RTL Template. (line 16)
+* match_operand and attributes: Expressions. (line 55)
+* match_operator: RTL Template. (line 95)
+* match_par_dup: RTL Template. (line 219)
+* match_parallel: RTL Template. (line 172)
+* match_scratch <1>: define_peephole2. (line 28)
+* match_scratch: RTL Template. (line 58)
+* matching constraint: Simple Constraints. (line 132)
+* matching operands: Output Template. (line 49)
+* math library: Soft float library routines.
+ (line 6)
+* math, in RTL: Arithmetic. (line 6)
+* MATH_LIBRARY: Misc. (line 550)
+* matherr: Library Calls. (line 58)
+* MAX_BITS_PER_WORD: Storage Layout. (line 61)
+* MAX_CONDITIONAL_EXECUTE: Misc. (line 572)
+* MAX_FIXED_MODE_SIZE: Storage Layout. (line 420)
+* MAX_MOVE_MAX: Misc. (line 120)
+* MAX_OFILE_ALIGNMENT: Storage Layout. (line 216)
+* MAX_REGS_PER_ADDRESS: Addressing Modes. (line 42)
+* MAX_STACK_ALIGNMENT: Storage Layout. (line 209)
+* maxM3 instruction pattern: Standard Names. (line 234)
+* may_trap_p, tree_could_trap_p: Edges. (line 115)
+* maybe_undef: GTY Options. (line 178)
+* mcount: Profiling. (line 12)
+* MD_CAN_REDIRECT_BRANCH: Misc. (line 697)
+* MD_EXEC_PREFIX: Driver. (line 330)
+* MD_FALLBACK_FRAME_STATE_FOR: Exception Handling. (line 98)
+* MD_HANDLE_UNWABI: Exception Handling. (line 118)
+* MD_STARTFILE_PREFIX: Driver. (line 358)
+* MD_STARTFILE_PREFIX_1: Driver. (line 364)
+* MD_UNWIND_SUPPORT: Exception Handling. (line 94)
+* mem: Regs and Memory. (line 374)
+* mem and /c: Flags. (line 99)
+* mem and /f: Flags. (line 103)
+* mem and /i: Flags. (line 85)
+* mem and /j: Flags. (line 79)
+* mem and /s: Flags. (line 70)
+* mem and /u: Flags. (line 152)
+* mem and /v: Flags. (line 94)
+* mem, RTL sharing: Sharing. (line 40)
+* MEM_ALIAS_SET: Special Accessors. (line 9)
+* MEM_ALIGN: Special Accessors. (line 36)
+* MEM_EXPR: Special Accessors. (line 20)
+* MEM_IN_STRUCT_P: Flags. (line 70)
+* MEM_KEEP_ALIAS_SET_P: Flags. (line 79)
+* MEM_NOTRAP_P: Flags. (line 99)
+* MEM_OFFSET: Special Accessors. (line 28)
+* MEM_POINTER: Flags. (line 103)
+* MEM_READONLY_P: Flags. (line 152)
+* MEM_SCALAR_P: Flags. (line 85)
+* MEM_SIZE: Special Accessors. (line 31)
+* MEM_VOLATILE_P: Flags. (line 94)
+* MEMBER_TYPE_FORCES_BLK: Storage Layout. (line 400)
+* memory reference, nonoffsettable: Simple Constraints. (line 246)
+* memory references in constraints: Simple Constraints. (line 17)
+* memory_barrier instruction pattern: Standard Names. (line 1413)
+* MEMORY_MOVE_COST: Costs. (line 29)
+* memory_operand: Machine-Independent Predicates.
+ (line 58)
+* METHOD_TYPE: Types. (line 6)
+* MIN_UNITS_PER_WORD: Storage Layout. (line 71)
+* MINIMUM_ALIGNMENT: Storage Layout. (line 288)
+* MINIMUM_ATOMIC_ALIGNMENT: Storage Layout. (line 187)
+* minM3 instruction pattern: Standard Names. (line 234)
+* minus: Arithmetic. (line 36)
+* minus and attributes: Expressions. (line 64)
+* minus, canonicalization of: Insn Canonicalizations.
+ (line 27)
+* MINUS_EXPR: Expression trees. (line 6)
+* MIPS coprocessor-definition macros: MIPS Coprocessors. (line 6)
+* mod: Arithmetic. (line 131)
+* mod and attributes: Expressions. (line 64)
+* mode classes: Machine Modes. (line 219)
+* mode iterators in .md files: Mode Iterators. (line 6)
+* mode switching: Mode Switching. (line 6)
+* MODE_ACCUM: Machine Modes. (line 249)
+* MODE_AFTER: Mode Switching. (line 49)
+* MODE_BASE_REG_CLASS: Register Classes. (line 112)
+* MODE_BASE_REG_REG_CLASS: Register Classes. (line 118)
+* MODE_CC: Machine Modes. (line 268)
+* MODE_CODE_BASE_REG_CLASS: Register Classes. (line 125)
+* MODE_COMPLEX_FLOAT: Machine Modes. (line 260)
+* MODE_COMPLEX_INT: Machine Modes. (line 257)
+* MODE_DECIMAL_FLOAT: Machine Modes. (line 237)
+* MODE_ENTRY: Mode Switching. (line 54)
+* MODE_EXIT: Mode Switching. (line 60)
+* MODE_FLOAT: Machine Modes. (line 233)
+* MODE_FRACT: Machine Modes. (line 241)
+* MODE_FUNCTION: Machine Modes. (line 264)
+* MODE_INT: Machine Modes. (line 225)
+* MODE_NEEDED: Mode Switching. (line 42)
+* MODE_PARTIAL_INT: Machine Modes. (line 229)
+* MODE_PRIORITY_TO_MODE: Mode Switching. (line 66)
+* MODE_RANDOM: Machine Modes. (line 273)
+* MODE_UACCUM: Machine Modes. (line 253)
+* MODE_UFRACT: Machine Modes. (line 245)
+* MODES_TIEABLE_P: Values in Registers.
+ (line 129)
+* modifiers in constraints: Modifiers. (line 6)
+* MODIFY_EXPR: Expression trees. (line 6)
+* MODIFY_JNI_METHOD_CALL: Misc. (line 774)
+* MODIFY_TARGET_NAME: Driver. (line 385)
+* modM3 instruction pattern: Standard Names. (line 222)
+* modulo scheduling: RTL passes. (line 131)
+* MOVE_BY_PIECES_P: Costs. (line 110)
+* MOVE_MAX: Misc. (line 115)
+* MOVE_MAX_PIECES: Costs. (line 116)
+* MOVE_RATIO: Costs. (line 97)
+* movM instruction pattern: Standard Names. (line 11)
+* movmemM instruction pattern: Standard Names. (line 672)
+* movmisalignM instruction pattern: Standard Names. (line 126)
+* movMODEcc instruction pattern: Standard Names. (line 891)
+* movstr instruction pattern: Standard Names. (line 707)
+* movstrictM instruction pattern: Standard Names. (line 120)
+* msubMN4 instruction pattern: Standard Names. (line 387)
+* mulhisi3 instruction pattern: Standard Names. (line 340)
+* mulM3 instruction pattern: Standard Names. (line 222)
+* mulqihi3 instruction pattern: Standard Names. (line 344)
+* mulsidi3 instruction pattern: Standard Names. (line 344)
+* mult: Arithmetic. (line 92)
+* mult and attributes: Expressions. (line 64)
+* mult, canonicalization of: Insn Canonicalizations.
+ (line 27)
+* MULT_EXPR: Expression trees. (line 6)
+* MULTILIB_DEFAULTS: Driver. (line 315)
+* MULTILIB_DIRNAMES: Target Fragment. (line 64)
+* MULTILIB_EXCEPTIONS: Target Fragment. (line 84)
+* MULTILIB_EXTRA_OPTS: Target Fragment. (line 96)
+* MULTILIB_MATCHES: Target Fragment. (line 77)
+* MULTILIB_OPTIONS: Target Fragment. (line 44)
+* multiple alternative constraints: Multi-Alternative. (line 6)
+* MULTIPLE_SYMBOL_SPACES: Misc. (line 530)
+* multiplication: Arithmetic. (line 92)
+* multiplication with signed saturation: Arithmetic. (line 92)
+* multiplication with unsigned saturation: Arithmetic. (line 92)
+* MUST_USE_SJLJ_EXCEPTIONS: Exception Region Output.
+ (line 64)
+* n in constraint: Simple Constraints. (line 65)
+* N_REG_CLASSES: Register Classes. (line 76)
+* name: Identifiers. (line 6)
+* named patterns and conditions: Patterns. (line 47)
+* names, pattern: Standard Names. (line 6)
+* namespace: Namespaces. (line 6)
+* namespace, class, scope: Scopes. (line 6)
+* NAMESPACE_DECL <1>: Declarations. (line 6)
+* NAMESPACE_DECL: Namespaces. (line 6)
+* NATIVE_SYSTEM_HEADER_DIR: Target Fragment. (line 103)
+* ne: Comparisons. (line 56)
+* ne and attributes: Expressions. (line 64)
+* NE_EXPR: Expression trees. (line 6)
+* nearbyintM2 instruction pattern: Standard Names. (line 564)
+* neg: Arithmetic. (line 81)
+* neg and attributes: Expressions. (line 64)
+* neg, canonicalization of: Insn Canonicalizations.
+ (line 27)
+* NEGATE_EXPR: Expression trees. (line 6)
+* negation: Arithmetic. (line 81)
+* negation with signed saturation: Arithmetic. (line 81)
+* negation with unsigned saturation: Arithmetic. (line 81)
+* negM2 instruction pattern: Standard Names. (line 449)
+* nested functions, trampolines for: Trampolines. (line 6)
+* nested_ptr: GTY Options. (line 185)
+* next_bb, prev_bb, FOR_EACH_BB: Basic Blocks. (line 10)
+* next_cc0_user: Jump Patterns. (line 64)
+* NEXT_INSN: Insns. (line 30)
+* NEXT_OBJC_RUNTIME: Library Calls. (line 94)
+* nil: RTL Objects. (line 73)
+* NO_DBX_BNSYM_ENSYM: DBX Hooks. (line 39)
+* NO_DBX_FUNCTION_END: DBX Hooks. (line 33)
+* NO_DBX_GCC_MARKER: File Names and DBX. (line 28)
+* NO_DBX_MAIN_SOURCE_DIRECTORY: File Names and DBX. (line 23)
+* NO_DOLLAR_IN_LABEL: Misc. (line 494)
+* NO_DOT_IN_LABEL: Misc. (line 500)
+* NO_FUNCTION_CSE: Costs. (line 200)
+* NO_IMPLICIT_EXTERN_C: Misc. (line 376)
+* NO_PROFILE_COUNTERS: Profiling. (line 28)
+* NO_REGS: Register Classes. (line 17)
+* NON_LVALUE_EXPR: Expression trees. (line 6)
+* nondeterministic finite state automaton: Processor pipeline description.
+ (line 296)
+* nonimmediate_operand: Machine-Independent Predicates.
+ (line 101)
+* nonlocal goto handler: Edges. (line 171)
+* nonlocal_goto instruction pattern: Standard Names. (line 1255)
+* nonlocal_goto_receiver instruction pattern: Standard Names.
+ (line 1272)
+* nonmemory_operand: Machine-Independent Predicates.
+ (line 97)
+* nonoffsettable memory reference: Simple Constraints. (line 246)
+* nop instruction pattern: Standard Names. (line 1073)
+* NOP_EXPR: Expression trees. (line 6)
+* normal predicates: Predicates. (line 31)
+* not: Arithmetic. (line 149)
+* not and attributes: Expressions. (line 50)
+* not equal: Comparisons. (line 56)
+* not, canonicalization of: Insn Canonicalizations.
+ (line 27)
+* note: Insns. (line 168)
+* note and /i: Flags. (line 59)
+* note and /v: Flags. (line 44)
+* NOTE_INSN_BASIC_BLOCK, CODE_LABEL, notes: Basic Blocks. (line 41)
+* NOTE_INSN_BLOCK_BEG: Insns. (line 193)
+* NOTE_INSN_BLOCK_END: Insns. (line 193)
+* NOTE_INSN_DELETED: Insns. (line 183)
+* NOTE_INSN_DELETED_LABEL: Insns. (line 188)
+* NOTE_INSN_EH_REGION_BEG: Insns. (line 199)
+* NOTE_INSN_EH_REGION_END: Insns. (line 199)
+* NOTE_INSN_FUNCTION_BEG: Insns. (line 223)
+* NOTE_INSN_LOOP_BEG: Insns. (line 207)
+* NOTE_INSN_LOOP_CONT: Insns. (line 213)
+* NOTE_INSN_LOOP_END: Insns. (line 207)
+* NOTE_INSN_LOOP_VTOP: Insns. (line 217)
+* NOTE_LINE_NUMBER: Insns. (line 168)
+* NOTE_SOURCE_FILE: Insns. (line 168)
+* NOTICE_UPDATE_CC: Condition Code. (line 33)
+* NUM_MACHINE_MODES: Machine Modes. (line 286)
+* NUM_MODES_FOR_MODE_SWITCHING: Mode Switching. (line 30)
+* Number of iterations analysis: Number of iterations.
+ (line 6)
+* o in constraint: Simple Constraints. (line 23)
+* OBJC_GEN_METHOD_LABEL: Label Output. (line 411)
+* OBJC_JBLEN: Misc. (line 924)
+* OBJECT_FORMAT_COFF: Macros for Initialization.
+ (line 97)
+* OFFSET_TYPE: Types. (line 6)
+* offsettable address: Simple Constraints. (line 23)
+* OImode: Machine Modes. (line 51)
+* Omega a solver for linear programming problems: Omega. (line 6)
+* OMP_ATOMIC: Expression trees. (line 6)
+* OMP_CLAUSE: Expression trees. (line 6)
+* OMP_CONTINUE: Expression trees. (line 6)
+* OMP_CRITICAL: Expression trees. (line 6)
+* OMP_FOR: Expression trees. (line 6)
+* OMP_MASTER: Expression trees. (line 6)
+* OMP_ORDERED: Expression trees. (line 6)
+* OMP_PARALLEL: Expression trees. (line 6)
+* OMP_RETURN: Expression trees. (line 6)
+* OMP_SECTION: Expression trees. (line 6)
+* OMP_SECTIONS: Expression trees. (line 6)
+* OMP_SINGLE: Expression trees. (line 6)
+* one_cmplM2 instruction pattern: Standard Names. (line 651)
+* operand access: Accessors. (line 6)
+* Operand Access Routines: SSA Operands. (line 119)
+* operand constraints: Constraints. (line 6)
+* Operand Iterators: SSA Operands. (line 119)
+* operand predicates: Predicates. (line 6)
+* operand substitution: Output Template. (line 6)
+* operands <1>: Patterns. (line 53)
+* operands: SSA Operands. (line 6)
+* Operands: Operands. (line 6)
+* operator predicates: Predicates. (line 6)
+* optc-gen.awk: Options. (line 6)
+* Optimization infrastructure for GIMPLE: Tree SSA. (line 6)
+* OPTIMIZATION_OPTIONS: Run-time Target. (line 120)
+* OPTIMIZE_MODE_SWITCHING: Mode Switching. (line 9)
+* option specification files: Options. (line 6)
+* OPTION_DEFAULT_SPECS: Driver. (line 88)
+* optional hardware or system features: Run-time Target. (line 59)
+* options, directory search: Including Patterns. (line 44)
+* order of register allocation: Allocation Order. (line 6)
+* ORDER_REGS_FOR_LOCAL_ALLOC: Allocation Order. (line 23)
+* ORDERED_EXPR: Expression trees. (line 6)
+* Ordering of Patterns: Pattern Ordering. (line 6)
+* ORIGINAL_REGNO: Special Accessors. (line 40)
+* other register constraints: Simple Constraints. (line 163)
+* OUTGOING_REG_PARM_STACK_SPACE: Stack Arguments. (line 71)
+* OUTGOING_REGNO: Register Basics. (line 98)
+* output of assembler code: File Framework. (line 6)
+* output statements: Output Statement. (line 6)
+* output templates: Output Template. (line 6)
+* OUTPUT_ADDR_CONST_EXTRA: Data Output. (line 39)
+* output_asm_insn: Output Statement. (line 53)
+* OUTPUT_QUOTED_STRING: File Framework. (line 76)
+* OVERLOAD: Functions. (line 6)
+* OVERRIDE_ABI_FORMAT: Register Arguments. (line 140)
+* OVERRIDE_OPTIONS: Run-time Target. (line 104)
+* OVL_CURRENT: Functions. (line 6)
+* OVL_NEXT: Functions. (line 6)
+* p in constraint: Simple Constraints. (line 154)
+* PAD_VARARGS_DOWN: Register Arguments. (line 220)
+* parallel: Side Effects. (line 204)
+* param_is: GTY Options. (line 113)
+* parameters, c++ abi: C++ ABI. (line 6)
+* parameters, miscellaneous: Misc. (line 6)
+* parameters, precompiled headers: PCH Target. (line 6)
+* paramN_is: GTY Options. (line 131)
+* parity: Arithmetic. (line 228)
+* parityM2 instruction pattern: Standard Names. (line 645)
+* PARM_BOUNDARY: Storage Layout. (line 144)
+* PARM_DECL: Declarations. (line 6)
+* PARSE_LDD_OUTPUT: Macros for Initialization.
+ (line 121)
+* passes and files of the compiler: Passes. (line 6)
+* passing arguments: Interface. (line 36)
+* PATH_SEPARATOR: Filesystem. (line 31)
+* PATTERN: Insns. (line 247)
+* pattern conditions: Patterns. (line 43)
+* pattern names: Standard Names. (line 6)
+* Pattern Ordering: Pattern Ordering. (line 6)
+* patterns: Patterns. (line 6)
+* pc: Regs and Memory. (line 361)
+* pc and attributes: Insn Lengths. (line 20)
+* pc, RTL sharing: Sharing. (line 25)
+* PC_REGNUM: Register Basics. (line 112)
+* pc_rtx: Regs and Memory. (line 366)
+* PCC_BITFIELD_TYPE_MATTERS: Storage Layout. (line 314)
+* PCC_STATIC_STRUCT_RETURN: Aggregate Return. (line 64)
+* PDImode: Machine Modes. (line 40)
+* peephole optimization, RTL representation: Side Effects. (line 238)
+* peephole optimizer definitions: Peephole Definitions.
+ (line 6)
+* per-function data: Per-Function Data. (line 6)
+* percent sign: Output Template. (line 6)
+* PHI nodes: SSA. (line 31)
+* phi_arg_d: GIMPLE_PHI. (line 28)
+* PHI_ARG_DEF: SSA. (line 71)
+* PHI_ARG_EDGE: SSA. (line 68)
+* PHI_ARG_ELT: SSA. (line 63)
+* PHI_NUM_ARGS: SSA. (line 59)
+* PHI_RESULT: SSA. (line 56)
+* PIC: PIC. (line 6)
+* PIC_OFFSET_TABLE_REG_CALL_CLOBBERED: PIC. (line 26)
+* PIC_OFFSET_TABLE_REGNUM: PIC. (line 16)
+* pipeline hazard recognizer: Processor pipeline description.
+ (line 6)
+* plus: Arithmetic. (line 14)
+* plus and attributes: Expressions. (line 64)
+* plus, canonicalization of: Insn Canonicalizations.
+ (line 27)
+* PLUS_EXPR: Expression trees. (line 6)
+* Pmode: Misc. (line 344)
+* pmode_register_operand: Machine-Independent Predicates.
+ (line 35)
+* pointer: Types. (line 6)
+* POINTER_PLUS_EXPR: Expression trees. (line 6)
+* POINTER_SIZE: Storage Layout. (line 83)
+* POINTER_TYPE: Types. (line 6)
+* POINTERS_EXTEND_UNSIGNED: Storage Layout. (line 89)
+* pop_operand: Machine-Independent Predicates.
+ (line 88)
+* popcount: Arithmetic. (line 224)
+* popcountM2 instruction pattern: Standard Names. (line 639)
+* portability: Portability. (line 6)
+* position independent code: PIC. (line 6)
+* post_dec: Incdec. (line 25)
+* post_inc: Incdec. (line 30)
+* post_modify: Incdec. (line 33)
+* POSTDECREMENT_EXPR: Expression trees. (line 6)
+* POSTINCREMENT_EXPR: Expression trees. (line 6)
+* POWI_MAX_MULTS: Misc. (line 822)
+* powM3 instruction pattern: Standard Names. (line 513)
+* pragma: Misc. (line 381)
+* pre_dec: Incdec. (line 8)
+* PRE_GCC3_DWARF_FRAME_REGISTERS: Frame Registers. (line 110)
+* pre_inc: Incdec. (line 22)
+* pre_modify: Incdec. (line 51)
+* PREDECREMENT_EXPR: Expression trees. (line 6)
+* predefined macros: Run-time Target. (line 6)
+* predicates: Predicates. (line 6)
+* predicates and machine modes: Predicates. (line 31)
+* predication: Conditional Execution.
+ (line 6)
+* predict.def: Profile information.
+ (line 24)
+* PREFERRED_DEBUGGING_TYPE: All Debuggers. (line 42)
+* PREFERRED_OUTPUT_RELOAD_CLASS: Register Classes. (line 231)
+* PREFERRED_RELOAD_CLASS: Register Classes. (line 196)
+* PREFERRED_STACK_BOUNDARY: Storage Layout. (line 158)
+* prefetch: Side Effects. (line 312)
+* prefetch instruction pattern: Standard Names. (line 1392)
+* PREINCREMENT_EXPR: Expression trees. (line 6)
+* presence_set: Processor pipeline description.
+ (line 215)
+* preserving SSA form: SSA. (line 76)
+* preserving virtual SSA form: SSA. (line 186)
+* prev_active_insn: define_peephole. (line 60)
+* prev_cc0_setter: Jump Patterns. (line 64)
+* PREV_INSN: Insns. (line 26)
+* PRINT_OPERAND: Instruction Output. (line 68)
+* PRINT_OPERAND_ADDRESS: Instruction Output. (line 96)
+* PRINT_OPERAND_PUNCT_VALID_P: Instruction Output. (line 89)
+* processor functional units: Processor pipeline description.
+ (line 6)
+* processor pipeline description: Processor pipeline description.
+ (line 6)
+* product: Arithmetic. (line 92)
+* profile feedback: Profile information.
+ (line 14)
+* profile representation: Profile information.
+ (line 6)
+* PROFILE_BEFORE_PROLOGUE: Profiling. (line 35)
+* PROFILE_HOOK: Profiling. (line 23)
+* profiling, code generation: Profiling. (line 6)
+* program counter: Regs and Memory. (line 362)
+* prologue: Function Entry. (line 6)
+* prologue instruction pattern: Standard Names. (line 1338)
+* PROMOTE_FUNCTION_MODE: Storage Layout. (line 123)
+* PROMOTE_MODE: Storage Layout. (line 100)
+* pseudo registers: Regs and Memory. (line 9)
+* PSImode: Machine Modes. (line 32)
+* PTRDIFF_TYPE: Type Layout. (line 184)
+* PTRMEM_CST: Expression trees. (line 6)
+* PTRMEM_CST_CLASS: Expression trees. (line 6)
+* PTRMEM_CST_MEMBER: Expression trees. (line 6)
+* purge_dead_edges <1>: Maintaining the CFG.
+ (line 93)
+* purge_dead_edges: Edges. (line 104)
+* push address instruction: Simple Constraints. (line 154)
+* PUSH_ARGS: Stack Arguments. (line 18)
+* PUSH_ARGS_REVERSED: Stack Arguments. (line 26)
+* push_operand: Machine-Independent Predicates.
+ (line 81)
+* push_reload: Addressing Modes. (line 169)
+* PUSH_ROUNDING: Stack Arguments. (line 32)
+* pushM1 instruction pattern: Standard Names. (line 209)
+* PUT_CODE: RTL Objects. (line 47)
+* PUT_MODE: Machine Modes. (line 283)
+* PUT_REG_NOTE_KIND: Insns. (line 309)
+* PUT_SDB_: SDB and DWARF. (line 63)
+* QCmode: Machine Modes. (line 197)
+* QFmode: Machine Modes. (line 54)
+* QImode: Machine Modes. (line 25)
+* QImode, in insn: Insns. (line 231)
+* QQmode: Machine Modes. (line 103)
+* qualified type: Types. (line 6)
+* querying function unit reservations: Processor pipeline description.
+ (line 90)
+* question mark: Multi-Alternative. (line 41)
+* quotient: Arithmetic. (line 111)
+* r in constraint: Simple Constraints. (line 56)
+* RANGE_TEST_NON_SHORT_CIRCUIT: Costs. (line 204)
+* RDIV_EXPR: Expression trees. (line 6)
+* READONLY_DATA_SECTION_ASM_OP: Sections. (line 63)
+* real operands: SSA Operands. (line 6)
+* REAL_ARITHMETIC: Floating Point. (line 66)
+* REAL_CST: Expression trees. (line 6)
+* REAL_LIBGCC_SPEC: Driver. (line 187)
+* REAL_NM_FILE_NAME: Macros for Initialization.
+ (line 106)
+* REAL_TYPE: Types. (line 6)
+* REAL_VALUE_ABS: Floating Point. (line 82)
+* REAL_VALUE_ATOF: Floating Point. (line 50)
+* REAL_VALUE_FIX: Floating Point. (line 41)
+* REAL_VALUE_FROM_INT: Floating Point. (line 99)
+* REAL_VALUE_ISINF: Floating Point. (line 59)
+* REAL_VALUE_ISNAN: Floating Point. (line 62)
+* REAL_VALUE_NEGATE: Floating Point. (line 79)
+* REAL_VALUE_NEGATIVE: Floating Point. (line 56)
+* REAL_VALUE_TO_INT: Floating Point. (line 93)
+* REAL_VALUE_TO_TARGET_DECIMAL128: Data Output. (line 144)
+* REAL_VALUE_TO_TARGET_DECIMAL32: Data Output. (line 142)
+* REAL_VALUE_TO_TARGET_DECIMAL64: Data Output. (line 143)
+* REAL_VALUE_TO_TARGET_DOUBLE: Data Output. (line 140)
+* REAL_VALUE_TO_TARGET_LONG_DOUBLE: Data Output. (line 141)
+* REAL_VALUE_TO_TARGET_SINGLE: Data Output. (line 139)
+* REAL_VALUE_TRUNCATE: Floating Point. (line 86)
+* REAL_VALUE_TYPE: Floating Point. (line 26)
+* REAL_VALUE_UNSIGNED_FIX: Floating Point. (line 45)
+* REAL_VALUES_EQUAL: Floating Point. (line 32)
+* REAL_VALUES_LESS: Floating Point. (line 38)
+* REALPART_EXPR: Expression trees. (line 6)
+* recog_data.operand: Instruction Output. (line 39)
+* recognizing insns: RTL Template. (line 6)
+* RECORD_TYPE <1>: Classes. (line 6)
+* RECORD_TYPE: Types. (line 6)
+* redirect_edge_and_branch: Profile information.
+ (line 71)
+* redirect_edge_and_branch, redirect_jump: Maintaining the CFG.
+ (line 103)
+* reduc_smax_M instruction pattern: Standard Names. (line 240)
+* reduc_smin_M instruction pattern: Standard Names. (line 240)
+* reduc_splus_M instruction pattern: Standard Names. (line 252)
+* reduc_umax_M instruction pattern: Standard Names. (line 246)
+* reduc_umin_M instruction pattern: Standard Names. (line 246)
+* reduc_uplus_M instruction pattern: Standard Names. (line 258)
+* reference: Types. (line 6)
+* REFERENCE_TYPE: Types. (line 6)
+* reg: Regs and Memory. (line 9)
+* reg and /f: Flags. (line 112)
+* reg and /i: Flags. (line 107)
+* reg and /v: Flags. (line 116)
+* reg, RTL sharing: Sharing. (line 17)
+* REG_ALLOC_ORDER: Allocation Order. (line 9)
+* REG_BR_PRED: Insns. (line 491)
+* REG_BR_PROB: Insns. (line 485)
+* REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information.
+ (line 82)
+* REG_BR_PROB_BASE, EDGE_FREQUENCY: Profile information.
+ (line 52)
+* REG_CC_SETTER: Insns. (line 456)
+* REG_CC_USER: Insns. (line 456)
+* REG_CLASS_CONTENTS: Register Classes. (line 86)
+* reg_class_contents: Register Basics. (line 59)
+* REG_CLASS_FROM_CONSTRAINT: Old Constraints. (line 35)
+* REG_CLASS_FROM_LETTER: Old Constraints. (line 27)
+* REG_CLASS_NAMES: Register Classes. (line 81)
+* REG_CROSSING_JUMP: Insns. (line 368)
+* REG_DEAD: Insns. (line 320)
+* REG_DEAD, REG_UNUSED: Liveness information.
+ (line 32)
+* REG_DEP_ANTI: Insns. (line 478)
+* REG_DEP_OUTPUT: Insns. (line 474)
+* REG_DEP_TRUE: Insns. (line 471)
+* REG_EH_REGION, EDGE_ABNORMAL_CALL: Edges. (line 110)
+* REG_EQUAL: Insns. (line 384)
+* REG_EQUIV: Insns. (line 384)
+* REG_EXPR: Special Accessors. (line 46)
+* REG_FRAME_RELATED_EXPR: Insns. (line 497)
+* REG_FUNCTION_VALUE_P: Flags. (line 107)
+* REG_INC: Insns. (line 336)
+* reg_label and /v: Flags. (line 65)
+* REG_LABEL_OPERAND: Insns. (line 350)
+* REG_LABEL_TARGET: Insns. (line 359)
+* reg_names <1>: Instruction Output. (line 80)
+* reg_names: Register Basics. (line 59)
+* REG_NONNEG: Insns. (line 342)
+* REG_NOTE_KIND: Insns. (line 309)
+* REG_NOTES: Insns. (line 283)
+* REG_OFFSET: Special Accessors. (line 50)
+* REG_OK_STRICT: Addressing Modes. (line 67)
+* REG_PARM_STACK_SPACE: Stack Arguments. (line 56)
+* REG_PARM_STACK_SPACE, and FUNCTION_ARG: Register Arguments.
+ (line 52)
+* REG_POINTER: Flags. (line 112)
+* REG_SETJMP: Insns. (line 378)
+* REG_UNUSED: Insns. (line 329)
+* REG_USERVAR_P: Flags. (line 116)
+* regclass_for_constraint: C Constraint Interface.
+ (line 60)
+* register allocation order: Allocation Order. (line 6)
+* register class definitions: Register Classes. (line 6)
+* register class preference constraints: Class Preferences. (line 6)
+* register pairs: Values in Registers.
+ (line 69)
+* Register Transfer Language (RTL): RTL. (line 6)
+* register usage: Registers. (line 6)
+* REGISTER_MOVE_COST: Costs. (line 10)
+* REGISTER_NAMES: Instruction Output. (line 9)
+* register_operand: Machine-Independent Predicates.
+ (line 30)
+* REGISTER_PREFIX: Instruction Output. (line 124)
+* REGISTER_TARGET_PRAGMAS: Misc. (line 382)
+* registers arguments: Register Arguments. (line 6)
+* registers in constraints: Simple Constraints. (line 56)
+* REGMODE_NATURAL_SIZE: Values in Registers.
+ (line 50)
+* REGNO_MODE_CODE_OK_FOR_BASE_P: Register Classes. (line 170)
+* REGNO_MODE_OK_FOR_BASE_P: Register Classes. (line 146)
+* REGNO_MODE_OK_FOR_REG_BASE_P: Register Classes. (line 157)
+* REGNO_OK_FOR_BASE_P: Register Classes. (line 140)
+* REGNO_OK_FOR_INDEX_P: Register Classes. (line 181)
+* REGNO_REG_CLASS: Register Classes. (line 101)
+* regs_ever_live: Function Entry. (line 21)
+* regular expressions: Processor pipeline description.
+ (line 6)
+* relative costs: Costs. (line 6)
+* RELATIVE_PREFIX_NOT_LINKDIR: Driver. (line 325)
+* reload_completed: Standard Names. (line 1040)
+* reload_in instruction pattern: Standard Names. (line 99)
+* reload_in_progress: Standard Names. (line 57)
+* reload_out instruction pattern: Standard Names. (line 99)
+* reloading: RTL passes. (line 182)
+* remainder: Arithmetic. (line 131)
+* remainderM3 instruction pattern: Standard Names. (line 472)
+* reorder: GTY Options. (line 209)
+* representation of RTL: RTL. (line 6)
+* reservation delays: Processor pipeline description.
+ (line 6)
+* rest_of_decl_compilation: Parsing pass. (line 52)
+* rest_of_type_compilation: Parsing pass. (line 52)
+* restore_stack_block instruction pattern: Standard Names. (line 1174)
+* restore_stack_function instruction pattern: Standard Names.
+ (line 1174)
+* restore_stack_nonlocal instruction pattern: Standard Names.
+ (line 1174)
+* RESULT_DECL: Declarations. (line 6)
+* return: Side Effects. (line 72)
+* return instruction pattern: Standard Names. (line 1027)
+* return values in registers: Scalar Return. (line 6)
+* RETURN_ADDR_IN_PREVIOUS_FRAME: Frame Layout. (line 135)
+* RETURN_ADDR_OFFSET: Exception Handling. (line 60)
+* RETURN_ADDR_RTX: Frame Layout. (line 124)
+* RETURN_ADDRESS_POINTER_REGNUM: Frame Registers. (line 51)
+* RETURN_EXPR: Function Bodies. (line 6)
+* RETURN_POPS_ARGS: Stack Arguments. (line 90)
+* RETURN_STMT: Function Bodies. (line 6)
+* return_val: Flags. (line 294)
+* return_val, in call_insn: Flags. (line 24)
+* return_val, in mem: Flags. (line 85)
+* return_val, in reg: Flags. (line 107)
+* return_val, in symbol_ref: Flags. (line 220)
+* returning aggregate values: Aggregate Return. (line 6)
+* returning structures and unions: Interface. (line 10)
+* reverse probability: Profile information.
+ (line 66)
+* REVERSE_CONDEXEC_PREDICATES_P: Condition Code. (line 129)
+* REVERSE_CONDITION: Condition Code. (line 116)
+* REVERSIBLE_CC_MODE: Condition Code. (line 102)
+* right rotate: Arithmetic. (line 190)
+* right shift: Arithmetic. (line 185)
+* rintM2 instruction pattern: Standard Names. (line 572)
+* RISC: Processor pipeline description.
+ (line 6)
+* roots, marking: GGC Roots. (line 6)
+* rotate: Arithmetic. (line 190)
+* rotatert: Arithmetic. (line 190)
+* rotlM3 instruction pattern: Standard Names. (line 441)
+* rotrM3 instruction pattern: Standard Names. (line 441)
+* ROUND_DIV_EXPR: Expression trees. (line 6)
+* ROUND_MOD_EXPR: Expression trees. (line 6)
+* ROUND_TOWARDS_ZERO: Storage Layout. (line 460)
+* ROUND_TYPE_ALIGN: Storage Layout. (line 411)
+* roundM2 instruction pattern: Standard Names. (line 548)
+* RSHIFT_EXPR: Expression trees. (line 6)
+* RTL addition: Arithmetic. (line 14)
+* RTL addition with signed saturation: Arithmetic. (line 14)
+* RTL addition with unsigned saturation: Arithmetic. (line 14)
+* RTL classes: RTL Classes. (line 6)
+* RTL comparison: Arithmetic. (line 43)
+* RTL comparison operations: Comparisons. (line 6)
+* RTL constant expression types: Constants. (line 6)
+* RTL constants: Constants. (line 6)
+* RTL declarations: RTL Declarations. (line 6)
+* RTL difference: Arithmetic. (line 36)
+* RTL expression: RTL Objects. (line 6)
+* RTL expressions for arithmetic: Arithmetic. (line 6)
+* RTL format: RTL Classes. (line 71)
+* RTL format characters: RTL Classes. (line 76)
+* RTL function-call insns: Calls. (line 6)
+* RTL insn template: RTL Template. (line 6)
+* RTL integers: RTL Objects. (line 6)
+* RTL memory expressions: Regs and Memory. (line 6)
+* RTL object types: RTL Objects. (line 6)
+* RTL postdecrement: Incdec. (line 6)
+* RTL postincrement: Incdec. (line 6)
+* RTL predecrement: Incdec. (line 6)
+* RTL preincrement: Incdec. (line 6)
+* RTL register expressions: Regs and Memory. (line 6)
+* RTL representation: RTL. (line 6)
+* RTL side effect expressions: Side Effects. (line 6)
+* RTL strings: RTL Objects. (line 6)
+* RTL structure sharing assumptions: Sharing. (line 6)
+* RTL subtraction: Arithmetic. (line 36)
+* RTL subtraction with signed saturation: Arithmetic. (line 36)
+* RTL subtraction with unsigned saturation: Arithmetic. (line 36)
+* RTL sum: Arithmetic. (line 14)
+* RTL vectors: RTL Objects. (line 6)
+* RTL_CONST_CALL_P: Flags. (line 19)
+* RTL_CONST_OR_PURE_CALL_P: Flags. (line 29)
+* RTL_LOOPING_CONST_OR_PURE_CALL_P: Flags. (line 33)
+* RTL_PURE_CALL_P: Flags. (line 24)
+* RTX (See RTL): RTL Objects. (line 6)
+* RTX codes, classes of: RTL Classes. (line 6)
+* RTX_FRAME_RELATED_P: Flags. (line 125)
+* run-time conventions: Interface. (line 6)
+* run-time target specification: Run-time Target. (line 6)
+* s in constraint: Simple Constraints. (line 92)
+* same_type_p: Types. (line 148)
+* SAmode: Machine Modes. (line 148)
+* sat_fract: Conversions. (line 90)
+* satfractMN2 instruction pattern: Standard Names. (line 843)
+* satfractunsMN2 instruction pattern: Standard Names. (line 856)
+* satisfies_constraint_: C Constraint Interface.
+ (line 47)
+* SAVE_EXPR: Expression trees. (line 6)
+* save_stack_block instruction pattern: Standard Names. (line 1174)
+* save_stack_function instruction pattern: Standard Names. (line 1174)
+* save_stack_nonlocal instruction pattern: Standard Names. (line 1174)
+* SBSS_SECTION_ASM_OP: Sections. (line 77)
+* Scalar evolutions: Scalar evolutions. (line 6)
+* scalars, returned as values: Scalar Return. (line 6)
+* SCHED_GROUP_P: Flags. (line 166)
+* SCmode: Machine Modes. (line 197)
+* sCOND instruction pattern: Standard Names. (line 911)
+* scratch: Regs and Memory. (line 298)
+* scratch operands: Regs and Memory. (line 298)
+* scratch, RTL sharing: Sharing. (line 35)
+* scratch_operand: Machine-Independent Predicates.
+ (line 50)
+* SDATA_SECTION_ASM_OP: Sections. (line 58)
+* SDB_ALLOW_FORWARD_REFERENCES: SDB and DWARF. (line 81)
+* SDB_ALLOW_UNKNOWN_REFERENCES: SDB and DWARF. (line 76)
+* SDB_DEBUGGING_INFO: SDB and DWARF. (line 9)
+* SDB_DELIM: SDB and DWARF. (line 69)
+* SDB_OUTPUT_SOURCE_LINE: SDB and DWARF. (line 86)
+* SDmode: Machine Modes. (line 85)
+* sdot_prodM instruction pattern: Standard Names. (line 264)
+* search options: Including Patterns. (line 44)
+* SECONDARY_INPUT_RELOAD_CLASS: Register Classes. (line 335)
+* SECONDARY_MEMORY_NEEDED: Register Classes. (line 391)
+* SECONDARY_MEMORY_NEEDED_MODE: Register Classes. (line 410)
+* SECONDARY_MEMORY_NEEDED_RTX: Register Classes. (line 401)
+* SECONDARY_OUTPUT_RELOAD_CLASS: Register Classes. (line 336)
+* SECONDARY_RELOAD_CLASS: Register Classes. (line 334)
+* SELECT_CC_MODE: Condition Code. (line 68)
+* sequence: Side Effects. (line 254)
+* Sequence iterators: Sequence iterators. (line 6)
+* set: Side Effects. (line 15)
+* set and /f: Flags. (line 125)
+* SET_ASM_OP: Label Output. (line 378)
+* set_attr: Tagging Insns. (line 31)
+* set_attr_alternative: Tagging Insns. (line 49)
+* set_bb_seq: GIMPLE sequences. (line 76)
+* SET_BY_PIECES_P: Costs. (line 145)
+* SET_DEST: Side Effects. (line 69)
+* SET_IS_RETURN_P: Flags. (line 175)
+* SET_LABEL_KIND: Insns. (line 140)
+* set_optab_libfunc: Library Calls. (line 15)
+* SET_RATIO: Costs. (line 136)
+* SET_SRC: Side Effects. (line 69)
+* SET_TYPE_STRUCTURAL_EQUALITY: Types. (line 6)
+* setmemM instruction pattern: Standard Names. (line 715)
+* SETUP_FRAME_ADDRESSES: Frame Layout. (line 102)
+* SF_SIZE: Type Layout. (line 129)
+* SFmode: Machine Modes. (line 66)
+* sharing of RTL components: Sharing. (line 6)
+* shift: Arithmetic. (line 168)
+* SHIFT_COUNT_TRUNCATED: Misc. (line 127)
+* SHLIB_SUFFIX: Macros for Initialization.
+ (line 129)
+* SHORT_ACCUM_TYPE_SIZE: Type Layout. (line 83)
+* SHORT_FRACT_TYPE_SIZE: Type Layout. (line 63)
+* SHORT_IMMEDIATES_SIGN_EXTEND: Misc. (line 96)
+* SHORT_TYPE_SIZE: Type Layout. (line 16)
+* sibcall_epilogue instruction pattern: Standard Names. (line 1364)
+* sibling call: Edges. (line 122)
+* SIBLING_CALL_P: Flags. (line 179)
+* sign_extend: Conversions. (line 23)
+* sign_extract: Bit-Fields. (line 8)
+* sign_extract, canonicalization of: Insn Canonicalizations.
+ (line 96)
+* signed division: Arithmetic. (line 111)
+* signed division with signed saturation: Arithmetic. (line 111)
+* signed maximum: Arithmetic. (line 136)
+* signed minimum: Arithmetic. (line 136)
+* SImode: Machine Modes. (line 37)
+* simple constraints: Simple Constraints. (line 6)
+* sincos math function, implicit usage: Library Calls. (line 84)
+* sinM2 instruction pattern: Standard Names. (line 489)
+* SIZE_ASM_OP: Label Output. (line 23)
+* SIZE_TYPE: Type Layout. (line 168)
+* skip: GTY Options. (line 76)
+* SLOW_BYTE_ACCESS: Costs. (line 66)
+* SLOW_UNALIGNED_ACCESS: Costs. (line 81)
+* SMALL_REGISTER_CLASSES: Register Classes. (line 433)
+* smax: Arithmetic. (line 136)
+* smin: Arithmetic. (line 136)
+* sms, swing, software pipelining: RTL passes. (line 131)
+* smulM3_highpart instruction pattern: Standard Names. (line 356)
+* soft float library: Soft float library routines.
+ (line 6)
+* special: GTY Options. (line 229)
+* special predicates: Predicates. (line 31)
+* SPECS: Target Fragment. (line 108)
+* speed of instructions: Costs. (line 6)
+* split_block: Maintaining the CFG.
+ (line 110)
+* splitting instructions: Insn Splitting. (line 6)
+* SQmode: Machine Modes. (line 111)
+* sqrt: Arithmetic. (line 198)
+* sqrtM2 instruction pattern: Standard Names. (line 455)
+* square root: Arithmetic. (line 198)
+* ss_ashift: Arithmetic. (line 168)
+* ss_div: Arithmetic. (line 111)
+* ss_minus: Arithmetic. (line 36)
+* ss_mult: Arithmetic. (line 92)
+* ss_neg: Arithmetic. (line 81)
+* ss_plus: Arithmetic. (line 14)
+* ss_truncate: Conversions. (line 43)
+* SSA: SSA. (line 6)
+* SSA_NAME_DEF_STMT: SSA. (line 221)
+* SSA_NAME_VERSION: SSA. (line 226)
+* ssaddM3 instruction pattern: Standard Names. (line 222)
+* ssashlM3 instruction pattern: Standard Names. (line 431)
+* ssdivM3 instruction pattern: Standard Names. (line 222)
+* ssmaddMN4 instruction pattern: Standard Names. (line 379)
+* ssmsubMN4 instruction pattern: Standard Names. (line 403)
+* ssmulM3 instruction pattern: Standard Names. (line 222)
+* ssnegM2 instruction pattern: Standard Names. (line 449)
+* sssubM3 instruction pattern: Standard Names. (line 222)
+* ssum_widenM3 instruction pattern: Standard Names. (line 274)
+* stack arguments: Stack Arguments. (line 6)
+* stack frame layout: Frame Layout. (line 6)
+* stack smashing protection: Stack Smashing Protection.
+ (line 6)
+* STACK_ALIGNMENT_NEEDED: Frame Layout. (line 48)
+* STACK_BOUNDARY: Storage Layout. (line 150)
+* STACK_CHECK_BUILTIN: Stack Checking. (line 32)
+* STACK_CHECK_FIXED_FRAME_SIZE: Stack Checking. (line 77)
+* STACK_CHECK_MAX_FRAME_SIZE: Stack Checking. (line 68)
+* STACK_CHECK_MAX_VAR_SIZE: Stack Checking. (line 84)
+* STACK_CHECK_PROBE_INTERVAL: Stack Checking. (line 46)
+* STACK_CHECK_PROBE_LOAD: Stack Checking. (line 53)
+* STACK_CHECK_PROTECT: Stack Checking. (line 59)
+* STACK_CHECK_STATIC_BUILTIN: Stack Checking. (line 39)
+* STACK_DYNAMIC_OFFSET: Frame Layout. (line 75)
+* STACK_DYNAMIC_OFFSET and virtual registers: Regs and Memory.
+ (line 83)
+* STACK_GROWS_DOWNWARD: Frame Layout. (line 9)
+* STACK_PARMS_IN_REG_PARM_AREA: Stack Arguments. (line 81)
+* STACK_POINTER_OFFSET: Frame Layout. (line 58)
+* STACK_POINTER_OFFSET and virtual registers: Regs and Memory.
+ (line 93)
+* STACK_POINTER_REGNUM: Frame Registers. (line 9)
+* STACK_POINTER_REGNUM and virtual registers: Regs and Memory.
+ (line 83)
+* stack_pointer_rtx: Frame Registers. (line 85)
+* stack_protect_set instruction pattern: Standard Names. (line 1534)
+* stack_protect_test instruction pattern: Standard Names. (line 1544)
+* STACK_PUSH_CODE: Frame Layout. (line 17)
+* STACK_REGS: Stack Registers. (line 20)
+* STACK_SAVEAREA_MODE: Storage Layout. (line 427)
+* STACK_SIZE_MODE: Storage Layout. (line 439)
+* STACK_SLOT_ALIGNMENT: Storage Layout. (line 265)
+* standard pattern names: Standard Names. (line 6)
+* STANDARD_INCLUDE_COMPONENT: Driver. (line 425)
+* STANDARD_INCLUDE_DIR: Driver. (line 417)
+* STANDARD_STARTFILE_PREFIX: Driver. (line 337)
+* STANDARD_STARTFILE_PREFIX_1: Driver. (line 344)
+* STANDARD_STARTFILE_PREFIX_2: Driver. (line 351)
+* STARTFILE_SPEC: Driver. (line 210)
+* STARTING_FRAME_OFFSET: Frame Layout. (line 39)
+* STARTING_FRAME_OFFSET and virtual registers: Regs and Memory.
+ (line 74)
+* Statement and operand traversals: Statement and operand traversals.
+ (line 6)
+* Statement Sequences: Statement Sequences.
+ (line 6)
+* Statements: Statements. (line 6)
+* statements: Function Bodies. (line 6)
+* Static profile estimation: Profile information.
+ (line 24)
+* static single assignment: SSA. (line 6)
+* STATIC_CHAIN: Frame Registers. (line 77)
+* STATIC_CHAIN_INCOMING: Frame Registers. (line 78)
+* STATIC_CHAIN_INCOMING_REGNUM: Frame Registers. (line 64)
+* STATIC_CHAIN_REGNUM: Frame Registers. (line 63)
+* stdarg.h and register arguments: Register Arguments. (line 47)
+* STDC_0_IN_SYSTEM_HEADERS: Misc. (line 365)
+* STMT_EXPR: Expression trees. (line 6)
+* STMT_IS_FULL_EXPR_P: Function Bodies. (line 22)
+* storage layout: Storage Layout. (line 6)
+* STORE_BY_PIECES_P: Costs. (line 152)
+* STORE_FLAG_VALUE: Misc. (line 216)
+* store_multiple instruction pattern: Standard Names. (line 160)
+* strcpy: Storage Layout. (line 235)
+* STRICT_ALIGNMENT: Storage Layout. (line 309)
+* strict_low_part: RTL Declarations. (line 9)
+* strict_memory_address_p: Addressing Modes. (line 179)
+* STRING_CST: Expression trees. (line 6)
+* STRING_POOL_ADDRESS_P: Flags. (line 183)
+* strlenM instruction pattern: Standard Names. (line 778)
+* structure value address: Aggregate Return. (line 6)
+* STRUCTURE_SIZE_BOUNDARY: Storage Layout. (line 301)
+* structures, returning: Interface. (line 10)
+* subM3 instruction pattern: Standard Names. (line 222)
+* SUBOBJECT: Function Bodies. (line 6)
+* SUBOBJECT_CLEANUP: Function Bodies. (line 6)
+* subreg: Regs and Memory. (line 97)
+* subreg and /s: Flags. (line 205)
+* subreg and /u: Flags. (line 198)
+* subreg and /u and /v: Flags. (line 188)
+* subreg, in strict_low_part: RTL Declarations. (line 9)
+* SUBREG_BYTE: Regs and Memory. (line 289)
+* SUBREG_PROMOTED_UNSIGNED_P: Flags. (line 188)
+* SUBREG_PROMOTED_UNSIGNED_SET: Flags. (line 198)
+* SUBREG_PROMOTED_VAR_P: Flags. (line 205)
+* SUBREG_REG: Regs and Memory. (line 289)
+* SUCCESS_EXIT_CODE: Host Misc. (line 12)
+* SUPPORTS_INIT_PRIORITY: Macros for Initialization.
+ (line 58)
+* SUPPORTS_ONE_ONLY: Label Output. (line 227)
+* SUPPORTS_WEAK: Label Output. (line 208)
+* SWITCH_BODY: Function Bodies. (line 6)
+* SWITCH_COND: Function Bodies. (line 6)
+* SWITCH_CURTAILS_COMPILATION: Driver. (line 33)
+* SWITCH_STMT: Function Bodies. (line 6)
+* SWITCH_TAKES_ARG: Driver. (line 9)
+* SWITCHES_NEED_SPACES: Driver. (line 47)
+* SYMBOL_FLAG_ANCHOR: Special Accessors. (line 106)
+* SYMBOL_FLAG_EXTERNAL: Special Accessors. (line 88)
+* SYMBOL_FLAG_FUNCTION: Special Accessors. (line 81)
+* SYMBOL_FLAG_HAS_BLOCK_INFO: Special Accessors. (line 102)
+* SYMBOL_FLAG_LOCAL: Special Accessors. (line 84)
+* SYMBOL_FLAG_SMALL: Special Accessors. (line 93)
+* SYMBOL_FLAG_TLS_SHIFT: Special Accessors. (line 97)
+* symbol_ref: Constants. (line 76)
+* symbol_ref and /f: Flags. (line 183)
+* symbol_ref and /i: Flags. (line 220)
+* symbol_ref and /u: Flags. (line 10)
+* symbol_ref and /v: Flags. (line 224)
+* symbol_ref, RTL sharing: Sharing. (line 20)
+* SYMBOL_REF_ANCHOR_P: Special Accessors. (line 106)
+* SYMBOL_REF_BLOCK: Special Accessors. (line 119)
+* SYMBOL_REF_BLOCK_OFFSET: Special Accessors. (line 124)
+* SYMBOL_REF_CONSTANT: Special Accessors. (line 67)
+* SYMBOL_REF_DATA: Special Accessors. (line 71)
+* SYMBOL_REF_DECL: Special Accessors. (line 55)
+* SYMBOL_REF_EXTERNAL_P: Special Accessors. (line 88)
+* SYMBOL_REF_FLAG: Flags. (line 224)
+* SYMBOL_REF_FLAG, in TARGET_ENCODE_SECTION_INFO: Sections. (line 259)
+* SYMBOL_REF_FLAGS: Special Accessors. (line 75)
+* SYMBOL_REF_FUNCTION_P: Special Accessors. (line 81)
+* SYMBOL_REF_HAS_BLOCK_INFO_P: Special Accessors. (line 102)
+* SYMBOL_REF_LOCAL_P: Special Accessors. (line 84)
+* SYMBOL_REF_SMALL_P: Special Accessors. (line 93)
+* SYMBOL_REF_TLS_MODEL: Special Accessors. (line 97)
+* SYMBOL_REF_USED: Flags. (line 215)
+* SYMBOL_REF_WEAK: Flags. (line 220)
+* symbolic label: Sharing. (line 20)
+* sync_addMODE instruction pattern: Standard Names. (line 1450)
+* sync_andMODE instruction pattern: Standard Names. (line 1450)
+* sync_compare_and_swap_ccMODE instruction pattern: Standard Names.
+ (line 1437)
+* sync_compare_and_swapMODE instruction pattern: Standard Names.
+ (line 1419)
+* sync_iorMODE instruction pattern: Standard Names. (line 1450)
+* sync_lock_releaseMODE instruction pattern: Standard Names. (line 1515)
+* sync_lock_test_and_setMODE instruction pattern: Standard Names.
+ (line 1489)
+* sync_nandMODE instruction pattern: Standard Names. (line 1450)
+* sync_new_addMODE instruction pattern: Standard Names. (line 1482)
+* sync_new_andMODE instruction pattern: Standard Names. (line 1482)
+* sync_new_iorMODE instruction pattern: Standard Names. (line 1482)
+* sync_new_nandMODE instruction pattern: Standard Names. (line 1482)
+* sync_new_subMODE instruction pattern: Standard Names. (line 1482)
+* sync_new_xorMODE instruction pattern: Standard Names. (line 1482)
+* sync_old_addMODE instruction pattern: Standard Names. (line 1465)
+* sync_old_andMODE instruction pattern: Standard Names. (line 1465)
+* sync_old_iorMODE instruction pattern: Standard Names. (line 1465)
+* sync_old_nandMODE instruction pattern: Standard Names. (line 1465)
+* sync_old_subMODE instruction pattern: Standard Names. (line 1465)
+* sync_old_xorMODE instruction pattern: Standard Names. (line 1465)
+* sync_subMODE instruction pattern: Standard Names. (line 1450)
+* sync_xorMODE instruction pattern: Standard Names. (line 1450)
+* SYSROOT_HEADERS_SUFFIX_SPEC: Driver. (line 239)
+* SYSROOT_SUFFIX_SPEC: Driver. (line 234)
+* SYSTEM_INCLUDE_DIR: Driver. (line 408)
+* t-TARGET: Target Fragment. (line 6)
+* table jump: Basic Blocks. (line 57)
+* tablejump instruction pattern: Standard Names. (line 1102)
+* tag: GTY Options. (line 81)
+* tagging insns: Tagging Insns. (line 6)
+* tail calls: Tail Calls. (line 6)
+* TAmode: Machine Modes. (line 156)
+* target attributes: Target Attributes. (line 6)
+* target description macros: Target Macros. (line 6)
+* target functions: Target Structure. (line 6)
+* target hooks: Target Structure. (line 6)
+* target makefile fragment: Target Fragment. (line 6)
+* target specifications: Run-time Target. (line 6)
+* TARGET_ADDRESS_COST: Costs. (line 236)
+* TARGET_ALIGN_ANON_BITFIELD: Storage Layout. (line 386)
+* TARGET_ALLOCATE_INITIAL_VALUE: Misc. (line 712)
+* TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS: Misc. (line 945)
+* TARGET_ARG_PARTIAL_BYTES: Register Arguments. (line 83)
+* TARGET_ARM_EABI_UNWINDER: Exception Region Output.
+ (line 113)
+* TARGET_ASM_ALIGNED_DI_OP: Data Output. (line 10)
+* TARGET_ASM_ALIGNED_HI_OP: Data Output. (line 8)
+* TARGET_ASM_ALIGNED_SI_OP: Data Output. (line 9)
+* TARGET_ASM_ALIGNED_TI_OP: Data Output. (line 11)
+* TARGET_ASM_ASSEMBLE_VISIBILITY: Label Output. (line 239)
+* TARGET_ASM_BYTE_OP: Data Output. (line 7)
+* TARGET_ASM_CAN_OUTPUT_MI_THUNK: Function Entry. (line 237)
+* TARGET_ASM_CLOSE_PAREN: Data Output. (line 130)
+* TARGET_ASM_CONSTRUCTOR: Macros for Initialization.
+ (line 69)
+* TARGET_ASM_DESTRUCTOR: Macros for Initialization.
+ (line 83)
+* TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL: Dispatch Tables. (line 74)
+* TARGET_ASM_EMIT_UNWIND_LABEL: Dispatch Tables. (line 63)
+* TARGET_ASM_EXTERNAL_LIBCALL: Label Output. (line 274)
+* TARGET_ASM_FILE_END: File Framework. (line 37)
+* TARGET_ASM_FILE_START: File Framework. (line 9)
+* TARGET_ASM_FILE_START_APP_OFF: File Framework. (line 17)
+* TARGET_ASM_FILE_START_FILE_DIRECTIVE: File Framework. (line 31)
+* TARGET_ASM_FUNCTION_BEGIN_EPILOGUE: Function Entry. (line 61)
+* TARGET_ASM_FUNCTION_END_PROLOGUE: Function Entry. (line 55)
+* TARGET_ASM_FUNCTION_EPILOGUE: Function Entry. (line 68)
+* TARGET_ASM_FUNCTION_EPILOGUE and trampolines: Trampolines. (line 70)
+* TARGET_ASM_FUNCTION_PROLOGUE: Function Entry. (line 11)
+* TARGET_ASM_FUNCTION_PROLOGUE and trampolines: Trampolines. (line 70)
+* TARGET_ASM_FUNCTION_RODATA_SECTION: Sections. (line 206)
+* TARGET_ASM_GLOBALIZE_DECL_NAME: Label Output. (line 174)
+* TARGET_ASM_GLOBALIZE_LABEL: Label Output. (line 165)
+* TARGET_ASM_INIT_SECTIONS: Sections. (line 151)
+* TARGET_ASM_INTEGER: Data Output. (line 27)
+* TARGET_ASM_INTERNAL_LABEL: Label Output. (line 309)
+* TARGET_ASM_MARK_DECL_PRESERVED: Label Output. (line 280)
+* TARGET_ASM_NAMED_SECTION: File Framework. (line 89)
+* TARGET_ASM_OPEN_PAREN: Data Output. (line 129)
+* TARGET_ASM_OUTPUT_ANCHOR: Anchored Addresses. (line 44)
+* TARGET_ASM_OUTPUT_DWARF_DTPREL: SDB and DWARF. (line 58)
+* TARGET_ASM_OUTPUT_MI_THUNK: Function Entry. (line 195)
+* TARGET_ASM_RECORD_GCC_SWITCHES: File Framework. (line 122)
+* TARGET_ASM_RECORD_GCC_SWITCHES_SECTION: File Framework. (line 166)
+* TARGET_ASM_SELECT_RTX_SECTION: Sections. (line 214)
+* TARGET_ASM_SELECT_SECTION: Sections. (line 172)
+* TARGET_ASM_TTYPE: Exception Region Output.
+ (line 107)
+* TARGET_ASM_UNALIGNED_DI_OP: Data Output. (line 14)
+* TARGET_ASM_UNALIGNED_HI_OP: Data Output. (line 12)
+* TARGET_ASM_UNALIGNED_SI_OP: Data Output. (line 13)
+* TARGET_ASM_UNALIGNED_TI_OP: Data Output. (line 15)
+* TARGET_ASM_UNIQUE_SECTION: Sections. (line 193)
+* TARGET_ATTRIBUTE_TABLE: Target Attributes. (line 11)
+* TARGET_BINDS_LOCAL_P: Sections. (line 284)
+* TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc. (line 808)
+* TARGET_BRANCH_TARGET_REGISTER_CLASS: Misc. (line 800)
+* TARGET_BUILD_BUILTIN_VA_LIST: Register Arguments. (line 263)
+* TARGET_BUILTIN_RECIPROCAL: Addressing Modes. (line 240)
+* TARGET_BUILTIN_SETJMP_FRAME_VALUE: Frame Layout. (line 109)
+* TARGET_C99_FUNCTIONS: Library Calls. (line 77)
+* TARGET_CALLEE_COPIES: Register Arguments. (line 115)
+* TARGET_CAN_INLINE_P: Target Attributes. (line 126)
+* TARGET_CANNOT_FORCE_CONST_MEM: Addressing Modes. (line 221)
+* TARGET_CANNOT_MODIFY_JUMPS_P: Misc. (line 787)
+* TARGET_CANONICAL_VA_LIST_TYPE: Register Arguments. (line 272)
+* TARGET_COMMUTATIVE_P: Misc. (line 705)
+* TARGET_COMP_TYPE_ATTRIBUTES: Target Attributes. (line 19)
+* TARGET_CPU_CPP_BUILTINS: Run-time Target. (line 9)
+* TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI. (line 87)
+* TARGET_CXX_CDTOR_RETURNS_THIS: C++ ABI. (line 38)
+* TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT: C++ ABI. (line 62)
+* TARGET_CXX_COOKIE_HAS_SIZE: C++ ABI. (line 25)
+* TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI. (line 54)
+* TARGET_CXX_GET_COOKIE_SIZE: C++ ABI. (line 18)
+* TARGET_CXX_GUARD_MASK_BIT: C++ ABI. (line 12)
+* TARGET_CXX_GUARD_TYPE: C++ ABI. (line 7)
+* TARGET_CXX_IMPORT_EXPORT_CLASS: C++ ABI. (line 30)
+* TARGET_CXX_KEY_METHOD_MAY_BE_INLINE: C++ ABI. (line 43)
+* TARGET_CXX_LIBRARY_RTTI_COMDAT: C++ ABI. (line 69)
+* TARGET_CXX_USE_AEABI_ATEXIT: C++ ABI. (line 74)
+* TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT: C++ ABI. (line 80)
+* TARGET_DECIMAL_FLOAT_SUPPORTED_P: Storage Layout. (line 513)
+* TARGET_DECLSPEC: Target Attributes. (line 64)
+* TARGET_DEFAULT_PACK_STRUCT: Misc. (line 482)
+* TARGET_DEFAULT_SHORT_ENUMS: Type Layout. (line 160)
+* TARGET_DEFERRED_OUTPUT_DEFS: Label Output. (line 393)
+* TARGET_DELEGITIMIZE_ADDRESS: Addressing Modes. (line 212)
+* TARGET_DLLIMPORT_DECL_ATTRIBUTES: Target Attributes. (line 47)
+* TARGET_DWARF_CALLING_CONVENTION: SDB and DWARF. (line 18)
+* TARGET_DWARF_HANDLE_FRAME_UNSPEC: Frame Layout. (line 172)
+* TARGET_DWARF_REGISTER_SPAN: Exception Region Output.
+ (line 90)
+* TARGET_EDOM: Library Calls. (line 59)
+* TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS: Emulated TLS. (line 68)
+* TARGET_EMUTLS_GET_ADDRESS: Emulated TLS. (line 19)
+* TARGET_EMUTLS_REGISTER_COMMON: Emulated TLS. (line 24)
+* TARGET_EMUTLS_TMPL_PREFIX: Emulated TLS. (line 45)
+* TARGET_EMUTLS_TMPL_SECTION: Emulated TLS. (line 36)
+* TARGET_EMUTLS_VAR_ALIGN_FIXED: Emulated TLS. (line 63)
+* TARGET_EMUTLS_VAR_FIELDS: Emulated TLS. (line 49)
+* TARGET_EMUTLS_VAR_INIT: Emulated TLS. (line 57)
+* TARGET_EMUTLS_VAR_PREFIX: Emulated TLS. (line 41)
+* TARGET_EMUTLS_VAR_SECTION: Emulated TLS. (line 31)
+* TARGET_ENCODE_SECTION_INFO: Sections. (line 235)
+* TARGET_ENCODE_SECTION_INFO and address validation: Addressing Modes.
+ (line 91)
+* TARGET_ENCODE_SECTION_INFO usage: Instruction Output. (line 100)
+* TARGET_ENUM_VA_LIST: Scalar Return. (line 84)
+* TARGET_EXECUTABLE_SUFFIX: Misc. (line 761)
+* TARGET_EXPAND_BUILTIN: Misc. (line 657)
+* TARGET_EXPAND_BUILTIN_SAVEREGS: Varargs. (line 92)
+* TARGET_EXPAND_TO_RTL_HOOK: Storage Layout. (line 519)
+* TARGET_EXPR: Expression trees. (line 6)
+* TARGET_EXTRA_INCLUDES: Misc. (line 833)
+* TARGET_EXTRA_LIVE_ON_ENTRY: Tail Calls. (line 21)
+* TARGET_EXTRA_PRE_INCLUDES: Misc. (line 840)
+* TARGET_FIXED_CONDITION_CODE_REGS: Condition Code. (line 142)
+* TARGET_FIXED_POINT_SUPPORTED_P: Storage Layout. (line 516)
+* target_flags: Run-time Target. (line 52)
+* TARGET_FLT_EVAL_METHOD: Type Layout. (line 141)
+* TARGET_FN_ABI_VA_LIST: Register Arguments. (line 267)
+* TARGET_FOLD_BUILTIN: Misc. (line 677)
+* TARGET_FORMAT_TYPES: Misc. (line 860)
+* TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes. (line 86)
+* TARGET_FUNCTION_OK_FOR_SIBCALL: Tail Calls. (line 8)
+* TARGET_FUNCTION_VALUE: Scalar Return. (line 11)
+* TARGET_GET_DRAP_RTX: Misc. (line 940)
+* TARGET_GIMPLIFY_VA_ARG_EXPR: Register Arguments. (line 278)
+* TARGET_HANDLE_C_OPTION: Run-time Target. (line 78)
+* TARGET_HANDLE_OPTION: Run-time Target. (line 61)
+* TARGET_HARD_REGNO_SCRATCH_OK: Values in Registers.
+ (line 144)
+* TARGET_HAS_SINCOS: Library Calls. (line 85)
+* TARGET_HAVE_CTORS_DTORS: Macros for Initialization.
+ (line 64)
+* TARGET_HAVE_NAMED_SECTIONS: File Framework. (line 99)
+* TARGET_HAVE_SWITCHABLE_BSS_SECTIONS: File Framework. (line 103)
+* TARGET_HELP: Run-time Target. (line 140)
+* TARGET_IN_SMALL_DATA_P: Sections. (line 276)
+* TARGET_INIT_BUILTINS: Misc. (line 639)
+* TARGET_INIT_DWARF_REG_SIZES_EXTRA: Exception Region Output.
+ (line 99)
+* TARGET_INIT_LIBFUNCS: Library Calls. (line 16)
+* TARGET_INSERT_ATTRIBUTES: Target Attributes. (line 73)
+* TARGET_INSTANTIATE_DECLS: Storage Layout. (line 527)
+* TARGET_INVALID_BINARY_OP: Misc. (line 913)
+* TARGET_INVALID_CONVERSION: Misc. (line 900)
+* TARGET_INVALID_UNARY_OP: Misc. (line 906)
+* TARGET_IRA_COVER_CLASSES: Register Classes. (line 496)
+* TARGET_LIB_INT_CMP_BIASED: Library Calls. (line 35)
+* TARGET_LIBGCC_CMP_RETURN_MODE: Storage Layout. (line 448)
+* TARGET_LIBGCC_SDATA_SECTION: Sections. (line 123)
+* TARGET_LIBGCC_SHIFT_COUNT_MODE: Storage Layout. (line 454)
+* TARGET_MACHINE_DEPENDENT_REORG: Misc. (line 624)
+* TARGET_MANGLE_DECL_ASSEMBLER_NAME: Sections. (line 225)
+* TARGET_MANGLE_TYPE: Storage Layout. (line 531)
+* TARGET_MD_ASM_CLOBBERS: Misc. (line 540)
+* TARGET_MEM_CONSTRAINT: Addressing Modes. (line 100)
+* TARGET_MEM_REF: Expression trees. (line 6)
+* TARGET_MERGE_DECL_ATTRIBUTES: Target Attributes. (line 39)
+* TARGET_MERGE_TYPE_ATTRIBUTES: Target Attributes. (line 31)
+* TARGET_MIN_DIVISIONS_FOR_RECIP_MUL: Misc. (line 106)
+* TARGET_MODE_REP_EXTENDED: Misc. (line 191)
+* TARGET_MS_BITFIELD_LAYOUT_P: Storage Layout. (line 486)
+* TARGET_MUST_PASS_IN_STACK: Register Arguments. (line 62)
+* TARGET_MUST_PASS_IN_STACK, and FUNCTION_ARG: Register Arguments.
+ (line 52)
+* TARGET_N_FORMAT_TYPES: Misc. (line 865)
+* TARGET_NARROW_VOLATILE_BITFIELD: Storage Layout. (line 392)
+* TARGET_OBJECT_SUFFIX: Misc. (line 756)
+* TARGET_OBJFMT_CPP_BUILTINS: Run-time Target. (line 46)
+* TARGET_OPTF: Misc. (line 847)
+* TARGET_OPTION_PRAGMA_PARSE: Target Attributes. (line 120)
+* TARGET_OPTION_PRINT: Target Attributes. (line 115)
+* TARGET_OPTION_RESTORE: Target Attributes. (line 110)
+* TARGET_OPTION_SAVE: Target Attributes. (line 104)
+* TARGET_OPTION_TRANSLATE_TABLE: Driver. (line 53)
+* TARGET_OS_CPP_BUILTINS: Run-time Target. (line 42)
+* TARGET_OVERRIDES_FORMAT_ATTRIBUTES: Misc. (line 869)
+* TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc. (line 875)
+* TARGET_OVERRIDES_FORMAT_INIT: Misc. (line 879)
+* TARGET_PASS_BY_REFERENCE: Register Arguments. (line 103)
+* TARGET_POSIX_IO: Misc. (line 564)
+* TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs. (line 152)
+* TARGET_PROMOTE_FUNCTION_ARGS: Storage Layout. (line 131)
+* TARGET_PROMOTE_FUNCTION_RETURN: Storage Layout. (line 136)
+* TARGET_PROMOTE_PROTOTYPES: Stack Arguments. (line 11)
+* TARGET_PTRMEMFUNC_VBIT_LOCATION: Type Layout. (line 235)
+* TARGET_RELAXED_ORDERING: Misc. (line 884)
+* TARGET_RESOLVE_OVERLOADED_BUILTIN: Misc. (line 667)
+* TARGET_RETURN_IN_MEMORY: Aggregate Return. (line 16)
+* TARGET_RETURN_IN_MSB: Scalar Return. (line 100)
+* TARGET_RTX_COSTS: Costs. (line 210)
+* TARGET_SCALAR_MODE_SUPPORTED_P: Register Arguments. (line 290)
+* TARGET_SCHED_ADJUST_COST: Scheduling. (line 37)
+* TARGET_SCHED_ADJUST_PRIORITY: Scheduling. (line 52)
+* TARGET_SCHED_CLEAR_SCHED_CONTEXT: Scheduling. (line 261)
+* TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling. (line 89)
+* TARGET_SCHED_DFA_NEW_CYCLE: Scheduling. (line 205)
+* TARGET_SCHED_DFA_POST_CYCLE_ADVANCE: Scheduling. (line 160)
+* TARGET_SCHED_DFA_POST_CYCLE_INSN: Scheduling. (line 144)
+* TARGET_SCHED_DFA_PRE_CYCLE_ADVANCE: Scheduling. (line 153)
+* TARGET_SCHED_DFA_PRE_CYCLE_INSN: Scheduling. (line 132)
+* TARGET_SCHED_FINISH: Scheduling. (line 109)
+* TARGET_SCHED_FINISH_GLOBAL: Scheduling. (line 126)
+* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling.
+ (line 168)
+* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling.
+ (line 196)
+* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC: Scheduling.
+ (line 321)
+* TARGET_SCHED_FREE_SCHED_CONTEXT: Scheduling. (line 265)
+* TARGET_SCHED_GEN_CHECK: Scheduling. (line 309)
+* TARGET_SCHED_H_I_D_EXTENDED: Scheduling. (line 241)
+* TARGET_SCHED_INIT: Scheduling. (line 99)
+* TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling. (line 149)
+* TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN: Scheduling. (line 141)
+* TARGET_SCHED_INIT_GLOBAL: Scheduling. (line 118)
+* TARGET_SCHED_INIT_SCHED_CONTEXT: Scheduling. (line 251)
+* TARGET_SCHED_IS_COSTLY_DEPENDENCE: Scheduling. (line 219)
+* TARGET_SCHED_ISSUE_RATE: Scheduling. (line 12)
+* TARGET_SCHED_NEEDS_BLOCK_P: Scheduling. (line 302)
+* TARGET_SCHED_REORDER: Scheduling. (line 60)
+* TARGET_SCHED_REORDER2: Scheduling. (line 77)
+* TARGET_SCHED_SET_SCHED_CONTEXT: Scheduling. (line 257)
+* TARGET_SCHED_SET_SCHED_FLAGS: Scheduling. (line 332)
+* TARGET_SCHED_SMS_RES_MII: Scheduling. (line 343)
+* TARGET_SCHED_SPECULATE_INSN: Scheduling. (line 291)
+* TARGET_SCHED_VARIABLE_ISSUE: Scheduling. (line 24)
+* TARGET_SECONDARY_RELOAD: Register Classes. (line 257)
+* TARGET_SECTION_TYPE_FLAGS: File Framework. (line 109)
+* TARGET_SET_CURRENT_FUNCTION: Misc. (line 739)
+* TARGET_SET_DEFAULT_TYPE_ATTRIBUTES: Target Attributes. (line 26)
+* TARGET_SETUP_INCOMING_VARARGS: Varargs. (line 101)
+* TARGET_SHIFT_TRUNCATION_MASK: Misc. (line 154)
+* TARGET_SPLIT_COMPLEX_ARG: Register Arguments. (line 251)
+* TARGET_STACK_PROTECT_FAIL: Stack Smashing Protection.
+ (line 17)
+* TARGET_STACK_PROTECT_GUARD: Stack Smashing Protection.
+ (line 7)
+* TARGET_STRICT_ARGUMENT_NAMING: Varargs. (line 137)
+* TARGET_STRUCT_VALUE_RTX: Aggregate Return. (line 44)
+* TARGET_UNSPEC_MAY_TRAP_P: Misc. (line 731)
+* TARGET_UNWIND_EMIT: Dispatch Tables. (line 81)
+* TARGET_UNWIND_INFO: Exception Region Output.
+ (line 56)
+* TARGET_UPDATE_STACK_BOUNDARY: Misc. (line 936)
+* TARGET_USE_ANCHORS_FOR_SYMBOL_P: Anchored Addresses. (line 55)
+* TARGET_USE_BLOCKS_FOR_CONSTANT_P: Addressing Modes. (line 233)
+* TARGET_USE_JCR_SECTION: Misc. (line 918)
+* TARGET_USE_LOCAL_THUNK_ALIAS_P: Misc. (line 853)
+* TARGET_USES_WEAK_UNWIND_INFO: Exception Handling. (line 129)
+* TARGET_VALID_DLLIMPORT_ATTRIBUTE_P: Target Attributes. (line 59)
+* TARGET_VALID_OPTION_ATTRIBUTE_P: Target Attributes. (line 93)
+* TARGET_VALID_POINTER_MODE: Register Arguments. (line 284)
+* TARGET_VECTOR_MODE_SUPPORTED_P: Register Arguments. (line 302)
+* TARGET_VECTOR_OPAQUE_P: Storage Layout. (line 479)
+* TARGET_VECTORIZE_BUILTIN_CONVERSION: Addressing Modes. (line 300)
+* TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes. (line 249)
+* TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN: Addressing Modes. (line 275)
+* TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD: Addressing Modes. (line 287)
+* TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION: Addressing Modes.
+ (line 315)
+* TARGET_VERSION: Run-time Target. (line 91)
+* TARGET_VTABLE_DATA_ENTRY_DISTANCE: Type Layout. (line 288)
+* TARGET_VTABLE_ENTRY_ALIGN: Type Layout. (line 282)
+* TARGET_VTABLE_USES_DESCRIPTORS: Type Layout. (line 271)
+* TARGET_WEAK_NOT_IN_ARCHIVE_TOC: Label Output. (line 245)
+* targetm: Target Structure. (line 7)
+* targets, makefile: Makefile. (line 6)
+* TCmode: Machine Modes. (line 197)
+* TDmode: Machine Modes. (line 94)
+* TEMPLATE_DECL: Declarations. (line 6)
+* Temporaries: Temporaries. (line 6)
+* termination routines: Initialization. (line 6)
+* testing constraints: C Constraint Interface.
+ (line 6)
+* TEXT_SECTION_ASM_OP: Sections. (line 38)
+* TF_SIZE: Type Layout. (line 132)
+* TFmode: Machine Modes. (line 98)
+* THEN_CLAUSE: Function Bodies. (line 6)
+* THREAD_MODEL_SPEC: Driver. (line 225)
+* THROW_EXPR: Expression trees. (line 6)
+* THUNK_DECL: Declarations. (line 6)
+* THUNK_DELTA: Declarations. (line 6)
+* TImode: Machine Modes. (line 48)
+* TImode, in insn: Insns. (line 231)
+* tm.h macros: Target Macros. (line 6)
+* TQFmode: Machine Modes. (line 62)
+* TQmode: Machine Modes. (line 119)
+* TRAMPOLINE_ADJUST_ADDRESS: Trampolines. (line 62)
+* TRAMPOLINE_ALIGNMENT: Trampolines. (line 49)
+* TRAMPOLINE_SECTION: Trampolines. (line 40)
+* TRAMPOLINE_SIZE: Trampolines. (line 45)
+* TRAMPOLINE_TEMPLATE: Trampolines. (line 29)
+* trampolines for nested functions: Trampolines. (line 6)
+* TRANSFER_FROM_TRAMPOLINE: Trampolines. (line 124)
+* trap instruction pattern: Standard Names. (line 1374)
+* tree <1>: Macros and Functions.
+ (line 6)
+* tree: Tree overview. (line 6)
+* Tree SSA: Tree SSA. (line 6)
+* tree_code <1>: GIMPLE_OMP_FOR. (line 83)
+* tree_code <2>: GIMPLE_COND. (line 21)
+* tree_code <3>: GIMPLE_ASSIGN. (line 41)
+* tree_code: Manipulating GIMPLE statements.
+ (line 31)
+* TREE_CODE: Tree overview. (line 6)
+* TREE_FILENAME: Working with declarations.
+ (line 14)
+* tree_int_cst_equal: Expression trees. (line 6)
+* TREE_INT_CST_HIGH: Expression trees. (line 6)
+* TREE_INT_CST_LOW: Expression trees. (line 6)
+* tree_int_cst_lt: Expression trees. (line 6)
+* TREE_LINENO: Working with declarations.
+ (line 20)
+* TREE_LIST: Containers. (line 6)
+* TREE_OPERAND: Expression trees. (line 6)
+* TREE_PUBLIC: Function Basics. (line 6)
+* TREE_PURPOSE: Containers. (line 6)
+* TREE_STRING_LENGTH: Expression trees. (line 6)
+* TREE_STRING_POINTER: Expression trees. (line 6)
+* TREE_TYPE <1>: Expression trees. (line 6)
+* TREE_TYPE <2>: Function Basics. (line 171)
+* TREE_TYPE <3>: Working with declarations.
+ (line 11)
+* TREE_TYPE: Types. (line 6)
+* TREE_VALUE: Containers. (line 6)
+* TREE_VEC: Containers. (line 6)
+* TREE_VEC_ELT: Containers. (line 6)
+* TREE_VEC_LENGTH: Containers. (line 6)
+* Trees: Trees. (line 6)
+* TRULY_NOOP_TRUNCATION: Misc. (line 177)
+* TRUNC_DIV_EXPR: Expression trees. (line 6)
+* TRUNC_MOD_EXPR: Expression trees. (line 6)
+* truncate: Conversions. (line 38)
+* truncMN2 instruction pattern: Standard Names. (line 821)
+* TRUTH_AND_EXPR: Expression trees. (line 6)
+* TRUTH_ANDIF_EXPR: Expression trees. (line 6)
+* TRUTH_NOT_EXPR: Expression trees. (line 6)
+* TRUTH_OR_EXPR: Expression trees. (line 6)
+* TRUTH_ORIF_EXPR: Expression trees. (line 6)
+* TRUTH_XOR_EXPR: Expression trees. (line 6)
+* TRY_BLOCK: Function Bodies. (line 6)
+* TRY_HANDLERS: Function Bodies. (line 6)
+* TRY_STMTS: Function Bodies. (line 6)
+* tstM instruction pattern: Standard Names. (line 661)
+* Tuple specific accessors: Tuple specific accessors.
+ (line 6)
+* tuples: Tuple representation.
+ (line 6)
+* type: Types. (line 6)
+* type declaration: Declarations. (line 6)
+* TYPE_ALIGN: Types. (line 6)
+* TYPE_ARG_TYPES: Types. (line 6)
+* TYPE_ASM_OP: Label Output. (line 55)
+* TYPE_ATTRIBUTES: Attributes. (line 25)
+* TYPE_BINFO: Classes. (line 6)
+* TYPE_BUILT_IN: Types. (line 83)
+* TYPE_CANONICAL: Types. (line 6)
+* TYPE_CONTEXT: Types. (line 6)
+* TYPE_DECL: Declarations. (line 6)
+* TYPE_FIELDS <1>: Classes. (line 6)
+* TYPE_FIELDS: Types. (line 6)
+* TYPE_HAS_ARRAY_NEW_OPERATOR: Classes. (line 91)
+* TYPE_HAS_DEFAULT_CONSTRUCTOR: Classes. (line 76)
+* TYPE_HAS_MUTABLE_P: Classes. (line 81)
+* TYPE_HAS_NEW_OPERATOR: Classes. (line 88)
+* TYPE_MAIN_VARIANT: Types. (line 6)
+* TYPE_MAX_VALUE: Types. (line 6)
+* TYPE_METHOD_BASETYPE: Types. (line 6)
+* TYPE_METHODS: Classes. (line 6)
+* TYPE_MIN_VALUE: Types. (line 6)
+* TYPE_NAME: Types. (line 6)
+* TYPE_NOTHROW_P: Function Basics. (line 180)
+* TYPE_OFFSET_BASETYPE: Types. (line 6)
+* TYPE_OPERAND_FMT: Label Output. (line 66)
+* TYPE_OVERLOADS_ARRAY_REF: Classes. (line 99)
+* TYPE_OVERLOADS_ARROW: Classes. (line 102)
+* TYPE_OVERLOADS_CALL_EXPR: Classes. (line 95)
+* TYPE_POLYMORPHIC_P: Classes. (line 72)
+* TYPE_PRECISION: Types. (line 6)
+* TYPE_PTR_P: Types. (line 89)
+* TYPE_PTRFN_P: Types. (line 93)
+* TYPE_PTRMEM_P: Types. (line 6)
+* TYPE_PTROB_P: Types. (line 96)
+* TYPE_PTROBV_P: Types. (line 6)
+* TYPE_QUAL_CONST: Types. (line 6)
+* TYPE_QUAL_RESTRICT: Types. (line 6)
+* TYPE_QUAL_VOLATILE: Types. (line 6)
+* TYPE_RAISES_EXCEPTIONS: Function Basics. (line 175)
+* TYPE_SIZE: Types. (line 6)
+* TYPE_STRUCTURAL_EQUALITY_P: Types. (line 6)
+* TYPE_UNQUALIFIED: Types. (line 6)
+* TYPE_VFIELD: Classes. (line 6)
+* TYPENAME_TYPE: Types. (line 6)
+* TYPENAME_TYPE_FULLNAME: Types. (line 6)
+* TYPEOF_TYPE: Types. (line 6)
+* UDAmode: Machine Modes. (line 168)
+* udiv: Arithmetic. (line 125)
+* udivM3 instruction pattern: Standard Names. (line 222)
+* udivmodM4 instruction pattern: Standard Names. (line 428)
+* udot_prodM instruction pattern: Standard Names. (line 265)
+* UDQmode: Machine Modes. (line 136)
+* UHAmode: Machine Modes. (line 160)
+* UHQmode: Machine Modes. (line 128)
+* UINTMAX_TYPE: Type Layout. (line 224)
+* umaddMN4 instruction pattern: Standard Names. (line 375)
+* umax: Arithmetic. (line 144)
+* umaxM3 instruction pattern: Standard Names. (line 222)
+* umin: Arithmetic. (line 144)
+* uminM3 instruction pattern: Standard Names. (line 222)
+* umod: Arithmetic. (line 131)
+* umodM3 instruction pattern: Standard Names. (line 222)
+* umsubMN4 instruction pattern: Standard Names. (line 399)
+* umulhisi3 instruction pattern: Standard Names. (line 347)
+* umulM3_highpart instruction pattern: Standard Names. (line 361)
+* umulqihi3 instruction pattern: Standard Names. (line 347)
+* umulsidi3 instruction pattern: Standard Names. (line 347)
+* unchanging: Flags. (line 319)
+* unchanging, in call_insn: Flags. (line 19)
+* unchanging, in jump_insn, call_insn and insn: Flags. (line 39)
+* unchanging, in mem: Flags. (line 152)
+* unchanging, in subreg: Flags. (line 188)
+* unchanging, in symbol_ref: Flags. (line 10)
+* UNEQ_EXPR: Expression trees. (line 6)
+* UNGE_EXPR: Expression trees. (line 6)
+* UNGT_EXPR: Expression trees. (line 6)
+* UNION_TYPE <1>: Classes. (line 6)
+* UNION_TYPE: Types. (line 6)
+* unions, returning: Interface. (line 10)
+* UNITS_PER_SIMD_WORD: Storage Layout. (line 77)
+* UNITS_PER_WORD: Storage Layout. (line 67)
+* UNKNOWN_TYPE: Types. (line 6)
+* UNLE_EXPR: Expression trees. (line 6)
+* UNLIKELY_EXECUTED_TEXT_SECTION_NAME: Sections. (line 49)
+* UNLT_EXPR: Expression trees. (line 6)
+* UNORDERED_EXPR: Expression trees. (line 6)
+* unshare_all_rtl: Sharing. (line 58)
+* unsigned division: Arithmetic. (line 125)
+* unsigned division with unsigned saturation: Arithmetic. (line 125)
+* unsigned greater than: Comparisons. (line 64)
+* unsigned less than: Comparisons. (line 68)
+* unsigned minimum and maximum: Arithmetic. (line 144)
+* unsigned_fix: Conversions. (line 77)
+* unsigned_float: Conversions. (line 62)
+* unsigned_fract_convert: Conversions. (line 97)
+* unsigned_sat_fract: Conversions. (line 103)
+* unspec: Side Effects. (line 287)
+* unspec_volatile: Side Effects. (line 287)
+* untyped_call instruction pattern: Standard Names. (line 1012)
+* untyped_return instruction pattern: Standard Names. (line 1062)
+* UPDATE_PATH_HOST_CANONICALIZE (PATH): Filesystem. (line 59)
+* update_ssa: SSA. (line 76)
+* update_stmt <1>: SSA Operands. (line 6)
+* update_stmt: Manipulating GIMPLE statements.
+ (line 141)
+* update_stmt_if_modified: Manipulating GIMPLE statements.
+ (line 144)
+* UQQmode: Machine Modes. (line 123)
+* US Software GOFAST, floating point emulation library: Library Calls.
+ (line 44)
+* us_ashift: Arithmetic. (line 168)
+* us_minus: Arithmetic. (line 36)
+* us_mult: Arithmetic. (line 92)
+* us_neg: Arithmetic. (line 81)
+* us_plus: Arithmetic. (line 14)
+* US_SOFTWARE_GOFAST: Library Calls. (line 45)
+* us_truncate: Conversions. (line 48)
+* usaddM3 instruction pattern: Standard Names. (line 222)
+* USAmode: Machine Modes. (line 164)
+* usashlM3 instruction pattern: Standard Names. (line 431)
+* usdivM3 instruction pattern: Standard Names. (line 222)
+* use: Side Effects. (line 162)
+* USE_C_ALLOCA: Host Misc. (line 19)
+* USE_LD_AS_NEEDED: Driver. (line 198)
+* USE_LOAD_POST_DECREMENT: Costs. (line 165)
+* USE_LOAD_POST_INCREMENT: Costs. (line 160)
+* USE_LOAD_PRE_DECREMENT: Costs. (line 175)
+* USE_LOAD_PRE_INCREMENT: Costs. (line 170)
+* use_optype_d: Manipulating GIMPLE statements.
+ (line 101)
+* use_param: GTY Options. (line 113)
+* use_paramN: GTY Options. (line 131)
+* use_params: GTY Options. (line 139)
+* USE_SELECT_SECTION_FOR_FUNCTIONS: Sections. (line 185)
+* USE_STORE_POST_DECREMENT: Costs. (line 185)
+* USE_STORE_POST_INCREMENT: Costs. (line 180)
+* USE_STORE_PRE_DECREMENT: Costs. (line 195)
+* USE_STORE_PRE_INCREMENT: Costs. (line 190)
+* used: Flags. (line 337)
+* used, in symbol_ref: Flags. (line 215)
+* USER_LABEL_PREFIX: Instruction Output. (line 126)
+* USING_DECL: Declarations. (line 6)
+* USING_STMT: Function Bodies. (line 6)
+* usmaddMN4 instruction pattern: Standard Names. (line 383)
+* usmsubMN4 instruction pattern: Standard Names. (line 407)
+* usmulhisi3 instruction pattern: Standard Names. (line 351)
+* usmulM3 instruction pattern: Standard Names. (line 222)
+* usmulqihi3 instruction pattern: Standard Names. (line 351)
+* usmulsidi3 instruction pattern: Standard Names. (line 351)
+* usnegM2 instruction pattern: Standard Names. (line 449)
+* USQmode: Machine Modes. (line 132)
+* ussubM3 instruction pattern: Standard Names. (line 222)
+* usum_widenM3 instruction pattern: Standard Names. (line 275)
+* UTAmode: Machine Modes. (line 172)
+* UTQmode: Machine Modes. (line 140)
+* V in constraint: Simple Constraints. (line 43)
+* VA_ARG_EXPR: Expression trees. (line 6)
+* values, returned by functions: Scalar Return. (line 6)
+* VAR_DECL <1>: Expression trees. (line 6)
+* VAR_DECL: Declarations. (line 6)
+* varargs implementation: Varargs. (line 6)
+* variable: Declarations. (line 6)
+* vashlM3 instruction pattern: Standard Names. (line 445)
+* vashrM3 instruction pattern: Standard Names. (line 445)
+* vec_concat: Vector Operations. (line 25)
+* vec_duplicate: Vector Operations. (line 30)
+* VEC_EXTRACT_EVEN_EXPR: Expression trees. (line 6)
+* vec_extract_evenM instruction pattern: Standard Names. (line 176)
+* VEC_EXTRACT_ODD_EXPR: Expression trees. (line 6)
+* vec_extract_oddM instruction pattern: Standard Names. (line 183)
+* vec_extractM instruction pattern: Standard Names. (line 171)
+* vec_initM instruction pattern: Standard Names. (line 204)
+* VEC_INTERLEAVE_HIGH_EXPR: Expression trees. (line 6)
+* vec_interleave_highM instruction pattern: Standard Names. (line 190)
+* VEC_INTERLEAVE_LOW_EXPR: Expression trees. (line 6)
+* vec_interleave_lowM instruction pattern: Standard Names. (line 197)
+* VEC_LSHIFT_EXPR: Expression trees. (line 6)
+* vec_merge: Vector Operations. (line 11)
+* VEC_PACK_FIX_TRUNC_EXPR: Expression trees. (line 6)
+* VEC_PACK_SAT_EXPR: Expression trees. (line 6)
+* vec_pack_sfix_trunc_M instruction pattern: Standard Names. (line 302)
+* vec_pack_ssat_M instruction pattern: Standard Names. (line 295)
+* VEC_PACK_TRUNC_EXPR: Expression trees. (line 6)
+* vec_pack_trunc_M instruction pattern: Standard Names. (line 288)
+* vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line 302)
+* vec_pack_usat_M instruction pattern: Standard Names. (line 295)
+* VEC_RSHIFT_EXPR: Expression trees. (line 6)
+* vec_select: Vector Operations. (line 19)
+* vec_setM instruction pattern: Standard Names. (line 166)
+* vec_shl_M instruction pattern: Standard Names. (line 282)
+* vec_shr_M instruction pattern: Standard Names. (line 282)
+* VEC_UNPACK_FLOAT_HI_EXPR: Expression trees. (line 6)
+* VEC_UNPACK_FLOAT_LO_EXPR: Expression trees. (line 6)
+* VEC_UNPACK_HI_EXPR: Expression trees. (line 6)
+* VEC_UNPACK_LO_EXPR: Expression trees. (line 6)
+* vec_unpacks_float_hi_M instruction pattern: Standard Names.
+ (line 324)
+* vec_unpacks_float_lo_M instruction pattern: Standard Names.
+ (line 324)
+* vec_unpacks_hi_M instruction pattern: Standard Names. (line 309)
+* vec_unpacks_lo_M instruction pattern: Standard Names. (line 309)
+* vec_unpacku_float_hi_M instruction pattern: Standard Names.
+ (line 324)
+* vec_unpacku_float_lo_M instruction pattern: Standard Names.
+ (line 324)
+* vec_unpacku_hi_M instruction pattern: Standard Names. (line 317)
+* vec_unpacku_lo_M instruction pattern: Standard Names. (line 317)
+* VEC_WIDEN_MULT_HI_EXPR: Expression trees. (line 6)
+* VEC_WIDEN_MULT_LO_EXPR: Expression trees. (line 6)
+* vec_widen_smult_hi_M instruction pattern: Standard Names. (line 333)
+* vec_widen_smult_lo_M instruction pattern: Standard Names. (line 333)
+* vec_widen_umult_hi_M instruction pattern: Standard Names. (line 333)
+* vec_widen_umult_lo__M instruction pattern: Standard Names. (line 333)
+* vector: Containers. (line 6)
+* vector operations: Vector Operations. (line 6)
+* VECTOR_CST: Expression trees. (line 6)
+* VECTOR_STORE_FLAG_VALUE: Misc. (line 308)
+* virtual operands: SSA Operands. (line 6)
+* VIRTUAL_INCOMING_ARGS_REGNUM: Regs and Memory. (line 59)
+* VIRTUAL_OUTGOING_ARGS_REGNUM: Regs and Memory. (line 87)
+* VIRTUAL_STACK_DYNAMIC_REGNUM: Regs and Memory. (line 78)
+* VIRTUAL_STACK_VARS_REGNUM: Regs and Memory. (line 69)
+* VLIW: Processor pipeline description.
+ (line 6)
+* vlshrM3 instruction pattern: Standard Names. (line 445)
+* VMS: Filesystem. (line 37)
+* VMS_DEBUGGING_INFO: VMS Debug. (line 9)
+* VOID_TYPE: Types. (line 6)
+* VOIDmode: Machine Modes. (line 190)
+* volatil: Flags. (line 351)
+* volatil, in insn, call_insn, jump_insn, code_label, barrier, and note: Flags.
+ (line 44)
+* volatil, in label_ref and reg_label: Flags. (line 65)
+* volatil, in mem, asm_operands, and asm_input: Flags. (line 94)
+* volatil, in reg: Flags. (line 116)
+* volatil, in subreg: Flags. (line 188)
+* volatil, in symbol_ref: Flags. (line 224)
+* volatile memory references: Flags. (line 352)
+* voptype_d: Manipulating GIMPLE statements.
+ (line 108)
+* voting between constraint alternatives: Class Preferences. (line 6)
+* vrotlM3 instruction pattern: Standard Names. (line 445)
+* vrotrM3 instruction pattern: Standard Names. (line 445)
+* walk_dominator_tree: SSA. (line 256)
+* walk_gimple_op: Statement and operand traversals.
+ (line 32)
+* walk_gimple_seq: Statement and operand traversals.
+ (line 50)
+* walk_gimple_stmt: Statement and operand traversals.
+ (line 13)
+* walk_use_def_chains: SSA. (line 232)
+* WCHAR_TYPE: Type Layout. (line 192)
+* WCHAR_TYPE_SIZE: Type Layout. (line 200)
+* which_alternative: Output Statement. (line 59)
+* WHILE_BODY: Function Bodies. (line 6)
+* WHILE_COND: Function Bodies. (line 6)
+* WHILE_STMT: Function Bodies. (line 6)
+* WIDEST_HARDWARE_FP_SIZE: Type Layout. (line 147)
+* WINT_TYPE: Type Layout. (line 205)
+* word_mode: Machine Modes. (line 336)
+* WORD_REGISTER_OPERATIONS: Misc. (line 63)
+* WORD_SWITCH_TAKES_ARG: Driver. (line 20)
+* WORDS_BIG_ENDIAN: Storage Layout. (line 29)
+* WORDS_BIG_ENDIAN, effect on subreg: Regs and Memory. (line 217)
+* X in constraint: Simple Constraints. (line 114)
+* x-HOST: Host Fragment. (line 6)
+* XCmode: Machine Modes. (line 197)
+* XCOFF_DEBUGGING_INFO: DBX Options. (line 13)
+* XEXP: Accessors. (line 6)
+* XF_SIZE: Type Layout. (line 131)
+* XFmode: Machine Modes. (line 79)
+* XINT: Accessors. (line 6)
+* xm-MACHINE.h <1>: Host Misc. (line 6)
+* xm-MACHINE.h: Filesystem. (line 6)
+* xor: Arithmetic. (line 163)
+* xor, canonicalization of: Insn Canonicalizations.
+ (line 84)
+* xorM3 instruction pattern: Standard Names. (line 222)
+* XSTR: Accessors. (line 6)
+* XVEC: Accessors. (line 41)
+* XVECEXP: Accessors. (line 48)
+* XVECLEN: Accessors. (line 44)
+* XWINT: Accessors. (line 6)
+* zero_extend: Conversions. (line 28)
+* zero_extendMN2 instruction pattern: Standard Names. (line 831)
+* zero_extract: Bit-Fields. (line 30)
+* zero_extract, canonicalization of: Insn Canonicalizations.
+ (line 96)
+
+
\1f
Tag Table:
-(Indirect)
-Node: Top\7f1250
-Node: Contributing\7f3727
-Node: Portability\7f4473
-Node: Interface\7f6234
-Node: Languages\7f10479
-Node: Source Tree\7f12032
-Node: Configure Terms\7f12650
-Node: Top Level\7f15613
-Node: gcc Directory\7f17736
-Node: Subdirectories\7f18702
-Node: Configuration\7f21004
-Node: Config Fragments\7f21654
-Node: System Config\7f22746
-Node: Configuration Files\7f23036
-Node: Build\7f25711
-Node: Makefile\7f26114
-Node: Library Files\7f29505
-Node: Headers\7f30058
-Node: Documentation\7f32095
-Node: Texinfo Manuals\7f32888
-Node: Man Page Generation\7f35009
-Node: Miscellaneous Docs\7f36917
-Node: Front End\7f38261
-Node: Front End Directory\7f41550
-Node: Front End Config\7f46061
-Node: Back End\7f48415
-Node: Test Suites\7f51428
-Node: Test Idioms\7f51928
-Node: C Tests\7f54796
-Node: libgcj Tests\7f57542
-Node: Passes\7f58454
-Node: Trees\7f81772
-Node: Deficiencies\7f84501
-Node: Tree overview\7f84734
-Node: Macros and Functions\7f88872
-Node: Identifiers\7f89009
-Node: Containers\7f90529
-Node: Types\7f91676
-Node: Scopes\7f104401
-Node: Namespaces\7f105160
-Node: Classes\7f107968
-Node: Declarations\7f112570
-Node: Functions\7f118629
-Node: Function Basics\7f121162
-Node: Function Bodies\7f127912
-Node: Attributes\7f141818
-Node: Expression trees\7f143054
-Node: RTL\7f167446
-Node: RTL Objects\7f169480
-Node: RTL Classes\7f173371
-Node: Accessors\7f177932
-Node: Flags\7f180315
-Node: Machine Modes\7f195220
-Node: Constants\7f203953
-Node: Regs and Memory\7f209919
-Node: Arithmetic\7f222790
-Node: Comparisons\7f229449
-Node: Bit-Fields\7f233572
-Node: Vector Operations\7f234993
-Node: Conversions\7f236771
-Node: RTL Declarations\7f240081
-Node: Side Effects\7f240893
-Node: Incdec\7f256686
-Node: Assembler\7f260242
-Node: Insns\7f261767
-Node: Calls\7f286565
-Node: Sharing\7f289162
-Node: Reading RTL\7f292266
-Node: Machine Desc\7f293252
-Node: Overview\7f295531
-Node: Patterns\7f297573
-Node: Example\7f301006
-Node: RTL Template\7f302440
-Node: Output Template\7f314908
-Node: Output Statement\7f318893
-Node: Constraints\7f322867
-Node: Simple Constraints\7f323801
-Node: Multi-Alternative\7f336165
-Node: Class Preferences\7f339003
-Node: Modifiers\7f339886
-Node: Machine Constraints\7f343547
-Node: Standard Names\7f360144
-Ref: prologue instruction pattern\7f399527
-Ref: epilogue instruction pattern\7f400020
-Node: Pattern Ordering\7f402749
-Node: Dependent Patterns\7f403979
-Node: Jump Patterns\7f406797
-Node: Looping Patterns\7f412547
-Node: Insn Canonicalizations\7f417153
-Node: Expander Definitions\7f420654
-Node: Insn Splitting\7f428789
-Node: Including Patterns\7f438407
-Node: Peephole Definitions\7f440185
-Node: define_peephole\7f441435
-Node: define_peephole2\7f447784
-Node: Insn Attributes\7f450848
-Node: Defining Attributes\7f451934
-Node: Expressions\7f453949
-Node: Tagging Insns\7f460541
-Node: Attr Example\7f464906
-Node: Insn Lengths\7f467285
-Node: Constant Attributes\7f470547
-Node: Delay Slots\7f471710
-Node: Function Units\7f474924
-Node: Conditional Execution\7f480597
-Node: Constant Definitions\7f483456
-Node: Target Macros\7f485037
-Node: Target Structure\7f487726
-Node: Driver\7f489017
-Node: Run-time Target\7f508350
-Node: Per-Function Data\7f515840
-Node: Storage Layout\7f519105
-Node: Type Layout\7f538134
-Node: Escape Sequences\7f548486
-Node: Registers\7f549401
-Node: Register Basics\7f550324
-Node: Allocation Order\7f555929
-Node: Values in Registers\7f557345
-Node: Leaf Functions\7f562180
-Node: Stack Registers\7f564969
-Node: Register Classes\7f565769
-Node: Stack and Calling\7f586703
-Node: Frame Layout\7f587199
-Node: Exception Handling\7f594064
-Node: Stack Checking\7f598566
-Node: Frame Registers\7f602123
-Node: Elimination\7f607575
-Node: Stack Arguments\7f611548
-Node: Register Arguments\7f619104
-Node: Scalar Return\7f630974
-Node: Aggregate Return\7f635215
-Node: Caller Saves\7f638932
-Node: Function Entry\7f640472
-Node: Profiling\7f652561
-Node: Tail Calls\7f654894
-Node: Varargs\7f655485
-Node: Trampolines\7f663163
-Node: Library Calls\7f670398
-Node: Addressing Modes\7f675920
-Node: Condition Code\7f687197
-Node: Costs\7f694524
-Node: Scheduling\7f706283
-Node: Sections\7f711799
-Node: PIC\7f719954
-Node: Assembler Format\7f722755
-Node: File Framework\7f723825
-Node: Data Output\7f728685
-Node: Uninitialized Data\7f736558
-Node: Label Output\7f741958
-Node: Initialization\7f756751
-Node: Macros for Initialization\7f762732
-Node: Instruction Output\7f768901
-Node: Dispatch Tables\7f777941
-Node: Exception Region Output\7f780496
-Node: Alignment Output\7f783850
-Node: Debugging Info\7f787722
-Node: All Debuggers\7f788386
-Node: DBX Options\7f791269
-Node: DBX Hooks\7f796644
-Node: File Names and DBX\7f800468
-Node: SDB and DWARF\7f802444
-Node: VMS Debug\7f805885
-Node: Cross-compilation\7f806433
-Node: Mode Switching\7f813012
-Node: Target Attributes\7f816265
-Node: Misc\7f820102
-Node: Host Config\7f848584
-Node: Fragments\7f854620
-Node: Target Fragment\7f855763
-Node: Host Fragment\7f860258
-Node: Collect2\7f861695
-Node: Header Dirs\7f864252
-Node: Funding\7f865703
-Node: GNU Project\7f868209
-Node: Copying\7f868863
-Node: GNU Free Documentation License\7f888077
-Node: Contributors\7f907964
-Node: Option Index\7f932895
-Node: Index\7f934646
+Node: Top\7f2034
+Node: Contributing\7f5059
+Node: Portability\7f5800
+Node: Interface\7f7588
+Node: Libgcc\7f10628
+Node: Integer library routines\7f12469
+Node: Soft float library routines\7f19308
+Node: Decimal float library routines\7f31245
+Node: Fixed-point fractional library routines\7f47002
+Node: Exception handling routines\7f147400
+Node: Miscellaneous routines\7f148507
+Node: Languages\7f148890
+Node: Source Tree\7f150437
+Node: Configure Terms\7f151056
+Node: Top Level\7f154014
+Node: gcc Directory\7f156784
+Node: Subdirectories\7f157753
+Node: Configuration\7f159603
+Node: Config Fragments\7f160323
+Node: System Config\7f161552
+Node: Configuration Files\7f162488
+Node: Build\7f165063
+Node: Makefile\7f165475
+Ref: Makefile-Footnote-1\7f172193
+Ref: Makefile-Footnote-2\7f172338
+Node: Library Files\7f172410
+Node: Headers\7f172972
+Node: Documentation\7f175055
+Node: Texinfo Manuals\7f175914
+Node: Man Page Generation\7f178252
+Node: Miscellaneous Docs\7f180167
+Node: Front End\7f181466
+Node: Front End Directory\7f185167
+Node: Front End Config\7f190289
+Node: Back End\7f193203
+Node: Testsuites\7f196880
+Node: Test Idioms\7f197744
+Node: Test Directives\7f201145
+Node: Ada Tests\7f213209
+Node: C Tests\7f214501
+Node: libgcj Tests\7f218856
+Node: gcov Testing\7f219988
+Node: profopt Testing\7f222972
+Node: compat Testing\7f224415
+Node: Torture Tests\7f228659
+Node: Options\7f230291
+Node: Option file format\7f230732
+Node: Option properties\7f233481
+Node: Passes\7f239537
+Node: Parsing pass\7f240279
+Node: Gimplification pass\7f243807
+Node: Pass manager\7f245634
+Node: Tree SSA passes\7f247116
+Node: RTL passes\7f268942
+Node: Trees\7f281285
+Node: Deficiencies\7f284015
+Node: Tree overview\7f284252
+Node: Macros and Functions\7f288375
+Node: Identifiers\7f288521
+Node: Containers\7f290046
+Node: Types\7f291201
+Node: Scopes\7f306904
+Node: Namespaces\7f307666
+Node: Classes\7f310478
+Node: Declarations\7f315235
+Node: Working with declarations\7f315730
+Node: Internal structure\7f322187
+Node: Current structure hierarchy\7f322569
+Node: Adding new DECL node types\7f324661
+Node: Functions\7f328732
+Node: Function Basics\7f331135
+Node: Function Bodies\7f338865
+Node: Attributes\7f350107
+Node: Expression trees\7f351348
+Node: RTL\7f393957
+Node: RTL Objects\7f396075
+Node: RTL Classes\7f399949
+Node: Accessors\7f404901
+Node: Special Accessors\7f407295
+Node: Flags\7f412513
+Node: Machine Modes\7f428381
+Node: Constants\7f440697
+Node: Regs and Memory\7f446726
+Node: Arithmetic\7f464627
+Node: Comparisons\7f474147
+Node: Bit-Fields\7f478439
+Node: Vector Operations\7f479991
+Node: Conversions\7f481617
+Node: RTL Declarations\7f486115
+Node: Side Effects\7f486936
+Node: Incdec\7f503259
+Node: Assembler\7f506594
+Node: Insns\7f508126
+Node: Calls\7f532015
+Node: Sharing\7f534608
+Node: Reading RTL\7f537718
+Node: GENERIC\7f538708
+Node: Statements\7f540347
+Node: Blocks\7f540792
+Node: Statement Sequences\7f542045
+Node: Empty Statements\7f542378
+Node: Jumps\7f542952
+Node: Cleanups\7f543605
+Node: GIMPLE\7f545358
+Node: Tuple representation\7f548979
+Node: GIMPLE instruction set\7f557634
+Node: GIMPLE Exception Handling\7f559302
+Node: Temporaries\7f561217
+Ref: Temporaries-Footnote-1\7f562536
+Node: Operands\7f562599
+Node: Compound Expressions\7f563373
+Node: Compound Lvalues\7f563607
+Node: Conditional Expressions\7f564373
+Node: Logical Operators\7f565043
+Node: Manipulating GIMPLE statements\7f571134
+Node: Tuple specific accessors\7f577062
+Node: `GIMPLE_ASM'\7f577895
+Node: `GIMPLE_ASSIGN'\7f580500
+Node: `GIMPLE_BIND'\7f584446
+Node: `GIMPLE_CALL'\7f586253
+Node: `GIMPLE_CATCH'\7f590512
+Node: `GIMPLE_CHANGE_DYNAMIC_TYPE'\7f591670
+Node: `GIMPLE_COND'\7f593003
+Node: `GIMPLE_EH_FILTER'\7f595809
+Node: `GIMPLE_LABEL'\7f597295
+Node: `GIMPLE_NOP'\7f598270
+Node: `GIMPLE_OMP_ATOMIC_LOAD'\7f598639
+Node: `GIMPLE_OMP_ATOMIC_STORE'\7f599549
+Node: `GIMPLE_OMP_CONTINUE'\7f600188
+Node: `GIMPLE_OMP_CRITICAL'\7f601538
+Node: `GIMPLE_OMP_FOR'\7f602474
+Node: `GIMPLE_OMP_MASTER'\7f605984
+Node: `GIMPLE_OMP_ORDERED'\7f606367
+Node: `GIMPLE_OMP_PARALLEL'\7f606767
+Node: `GIMPLE_OMP_RETURN'\7f609536
+Node: `GIMPLE_OMP_SECTION'\7f610186
+Node: `GIMPLE_OMP_SECTIONS'\7f610852
+Node: `GIMPLE_OMP_SINGLE'\7f612456
+Node: `GIMPLE_PHI'\7f613392
+Node: `GIMPLE_RESX'\7f614805
+Node: `GIMPLE_RETURN'\7f615524
+Node: `GIMPLE_SWITCH'\7f616092
+Node: `GIMPLE_TRY'\7f618222
+Node: `GIMPLE_WITH_CLEANUP_EXPR'\7f620012
+Node: GIMPLE sequences\7f620895
+Node: Sequence iterators\7f624101
+Node: Adding a new GIMPLE statement code\7f632556
+Node: Statement and operand traversals\7f633836
+Node: Tree SSA\7f636446
+Node: Annotations\7f638166
+Node: SSA Operands\7f638692
+Node: SSA\7f653223
+Node: Alias analysis\7f665514
+Node: Loop Analysis and Representation\7f672970
+Node: Loop representation\7f674151
+Node: Loop querying\7f681071
+Node: Loop manipulation\7f683904
+Node: LCSSA\7f686272
+Node: Scalar evolutions\7f688344
+Node: loop-iv\7f691588
+Node: Number of iterations\7f693514
+Node: Dependency analysis\7f696323
+Node: Lambda\7f702691
+Node: Omega\7f704361
+Node: Control Flow\7f705926
+Node: Basic Blocks\7f706921
+Node: Edges\7f711489
+Node: Profile information\7f720051
+Node: Maintaining the CFG\7f724737
+Node: Liveness information\7f731619
+Node: Machine Desc\7f733746
+Node: Overview\7f736214
+Node: Patterns\7f738255
+Node: Example\7f741693
+Node: RTL Template\7f743128
+Node: Output Template\7f753783
+Node: Output Statement\7f757749
+Node: Predicates\7f761711
+Node: Machine-Independent Predicates\7f764629
+Node: Defining Predicates\7f769261
+Node: Constraints\7f775226
+Node: Simple Constraints\7f776474
+Node: Multi-Alternative\7f788680
+Node: Class Preferences\7f791521
+Node: Modifiers\7f792413
+Node: Machine Constraints\7f796545
+Node: Disable Insn Alternatives\7f829268
+Node: Define Constraints\7f832161
+Node: C Constraint Interface\7f838941
+Node: Standard Names\7f842582
+Ref: shift patterns\7f861510
+Ref: prologue instruction pattern\7f902528
+Ref: epilogue instruction pattern\7f903021
+Node: Pattern Ordering\7f912520
+Node: Dependent Patterns\7f913756
+Node: Jump Patterns\7f916570
+Node: Looping Patterns\7f922266
+Node: Insn Canonicalizations\7f926994
+Node: Expander Definitions\7f931378
+Node: Insn Splitting\7f939496
+Node: Including Patterns\7f949099
+Node: Peephole Definitions\7f950879
+Node: define_peephole\7f952132
+Node: define_peephole2\7f958463
+Node: Insn Attributes\7f961530
+Node: Defining Attributes\7f962636
+Node: Expressions\7f965156
+Node: Tagging Insns\7f971758
+Node: Attr Example\7f976111
+Node: Insn Lengths\7f978485
+Node: Constant Attributes\7f981544
+Node: Delay Slots\7f982713
+Node: Processor pipeline description\7f985937
+Ref: Processor pipeline description-Footnote-1\7f1003303
+Node: Conditional Execution\7f1003625
+Node: Constant Definitions\7f1006478
+Node: Iterators\7f1008073
+Node: Mode Iterators\7f1008520
+Node: Defining Mode Iterators\7f1009498
+Node: Substitutions\7f1010992
+Node: Examples\7f1013233
+Node: Code Iterators\7f1014681
+Node: Target Macros\7f1016938
+Node: Target Structure\7f1019961
+Node: Driver\7f1021230
+Node: Run-time Target\7f1044911
+Node: Per-Function Data\7f1052035
+Node: Storage Layout\7f1054798
+Node: Type Layout\7f1080212
+Node: Registers\7f1093169
+Node: Register Basics\7f1094143
+Node: Allocation Order\7f1099710
+Node: Values in Registers\7f1101731
+Node: Leaf Functions\7f1109220
+Node: Stack Registers\7f1112078
+Node: Register Classes\7f1113194
+Node: Old Constraints\7f1139906
+Node: Stack and Calling\7f1147057
+Node: Frame Layout\7f1147591
+Node: Exception Handling\7f1158437
+Node: Stack Checking\7f1164815
+Node: Frame Registers\7f1169202
+Node: Elimination\7f1175808
+Node: Stack Arguments\7f1179839
+Node: Register Arguments\7f1186642
+Node: Scalar Return\7f1202090
+Node: Aggregate Return\7f1207636
+Node: Caller Saves\7f1211295
+Node: Function Entry\7f1212473
+Node: Profiling\7f1225088
+Node: Tail Calls\7f1226787
+Node: Stack Smashing Protection\7f1228154
+Node: Varargs\7f1229266
+Node: Trampolines\7f1237226
+Node: Library Calls\7f1243892
+Node: Addressing Modes\7f1248742
+Node: Anchored Addresses\7f1264660
+Node: Condition Code\7f1267321
+Node: Costs\7f1275610
+Node: Scheduling\7f1288709
+Node: Sections\7f1307270
+Node: PIC\7f1321920
+Node: Assembler Format\7f1323910
+Node: File Framework\7f1325048
+Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS\7f1329954
+Node: Data Output\7f1333220
+Node: Uninitialized Data\7f1340979
+Node: Label Output\7f1346050
+Node: Initialization\7f1367717
+Node: Macros for Initialization\7f1373679
+Node: Instruction Output\7f1380131
+Node: Dispatch Tables\7f1389125
+Node: Exception Region Output\7f1392920
+Node: Alignment Output\7f1398680
+Node: Debugging Info\7f1402843
+Node: All Debuggers\7f1403513
+Node: DBX Options\7f1406368
+Node: DBX Hooks\7f1411817
+Node: File Names and DBX\7f1413743
+Node: SDB and DWARF\7f1415854
+Node: VMS Debug\7f1419846
+Node: Floating Point\7f1420416
+Node: Mode Switching\7f1425239
+Node: Target Attributes\7f1429165
+Node: Emulated TLS\7f1435929
+Node: MIPS Coprocessors\7f1439319
+Node: PCH Target\7f1440888
+Node: C++ ABI\7f1442409
+Node: Misc\7f1447028
+Ref: TARGET_SHIFT_TRUNCATION_MASK\7f1454398
+Node: Host Config\7f1494951
+Node: Host Common\7f1496019
+Node: Filesystem\7f1498398
+Node: Host Misc\7f1502513
+Node: Fragments\7f1504652
+Node: Target Fragment\7f1505847
+Node: Host Fragment\7f1511737
+Node: Collect2\7f1511977
+Node: Header Dirs\7f1514520
+Node: Type Information\7f1515943
+Node: GTY Options\7f1518234
+Node: GGC Roots\7f1528909
+Node: Files\7f1529629
+Node: Invoking the garbage collector\7f1532093
+Node: Funding\7f1533146
+Node: GNU Project\7f1535642
+Node: Copying\7f1536291
+Node: GNU Free Documentation License\7f1573822
+Node: Contributors\7f1596231
+Node: Option Index\7f1632561
+Node: Concept Index\7f1633146
\1f
End Tag Table
projects / msp430-gcc.git / blobdiff