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

Deficiencies
============

There are many places in which this document is incomplet and incorrekt. It is, as of yet, only preliminary documentation.

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.

Trees
-----

All GENERIC trees have two fields in common.  First, TREE_CHAIN is a pointer that can be used as a singly-linked list to other trees. The other is TREE_TYPE.  Many trees store the type of an expression or declaration in this field.

These are some other functions for handling trees:

tree_size
     Return the number of bytes a tree takes.

build0
build1
build2
build3
build4
build5
build6

     These functions build a tree and supply values to put in each parameter.  The basic signature is code, type, [operands]. code is the TREE_CODE, and type is a tree representing the TREE_TYPE.  These are followed by the operands, each of which is also a tree.

Identifiers
-----------

An IDENTIFIER_NODE represents a slightly more general concept than 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_NODEs representing the same identifier.  Therefore, you may use pointer equality to compare IDENTIFIER_NODEs, rather than using a routine like strcmp.  Use get_identifier to obtain the unique IDENTIFIER_NODE for a supplied string.

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.

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.

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.

The following functions and macros deal with cv-qualification of types:

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

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

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.

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.

LANG_TYPE
     This node is used to represent a language-specific type.  The front end must handle it.

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.

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.

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

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.

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

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

The various kinds of declarations include:

LABEL_DECL
     These nodes are used to represent labels in function bodies.  For more information, see 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.

DEBUG_EXPR_DECL
     Used to represent an anonymous debug-information temporary created to hold an expression as it is optimized away, so that its value can be referenced in debug bind statements.

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
     Namespaces provide a name hierarchy for other declarations.  They appear in the DECL_CONTEXT of other _DECL nodes.

Internal structure
------------------

DECL nodes are represented internally as a hierarchy of structures.

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.

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

     Reading them from the generated all-tree.def file (which in turn includes all the tree.def files), gencheck.c is used during GCC's build to generate the *_CHECK macros for all tree codes.

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.

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.

Constant expressions
--------------------

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 represented in an array of HOST_WIDE_INT.   There are enough elements in the array to represent the value without taking extra elements for redundant 0s or -1.  The number of elements used to represent e is available via TREE_INT_CST_NUNITS. Element i can be extracted by using TREE_INT_CST_ELT (e, i). TREE_INT_CST_LOW is a shorthand for TREE_INT_CST_ELT (e, 0).

     The functions tree_fits_shwi_p and tree_fits_uhwi_p can be used to tell if the value is small enough to fit in a signed HOST_WIDE_INT or an unsigned HOST_WIDE_INT respectively. The value can then be extracted using tree_to_shwi and tree_to_uhwi.

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 a 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.  Each vector constant V is treated as a specific instance of an arbitrary-length sequence that itself contains VECTOR_CST_NPATTERNS (V) interleaved patterns.  Each pattern has the form:

          { BASE0, BASE1, BASE1 + STEP, BASE1 + STEP * 2, ... }

     The first three elements in each pattern are enough to determine the values of the other elements.  However, if all STEPs are zero, only the first two elements are needed.  If in addition each BASE1 is equal to the corresponding BASE0, only the first element in each pattern is needed.  The number of encoded elements per pattern is given by VECTOR_CST_NELTS_PER_PATTERN (V).

     For example, the constant:

          { 0, 1, 2, 6, 3, 8, 4, 10, 5, 12, 6, 14, 7, 16, 8, 18 }

     is interpreted as an interleaving of the sequences:

          { 0, 2, 3, 4, 5, 6, 7, 8 }
          { 1, 6, 8, 10, 12, 14, 16, 18 }

     where the sequences are represented by the following patterns:

          BASE0 == 0, BASE1 == 2, STEP == 1
          BASE0 == 1, BASE1 == 6, STEP == 2

     In this case:

          VECTOR_CST_NPATTERNS (V) == 2
          VECTOR_CST_NELTS_PER_PATTERN (V) == 3

     The vector is therefore encoded using the first 6 elements ({ 0, 1, 2, 6, 3, 8 }), with the remaining 10 elements being implicit extensions of them.

     Sometimes this scheme can create two possible encodings of the same vector.  For example { 0, 1 } could be seen as two patterns with one element each or one pattern with two elements (BASE0 and BASE1).  The canonical encoding is always the one with the fewest patterns or (if both encodings have the same number of petterns) the one with the fewest encoded elements.

     vector_cst_encoding_nelts (V) gives the total number of encoded elements in V, which is 6 in the example above. VECTOR_CST_ENCODED_ELTS (V) gives a pointer to the elements encoded in V and VECTOR_CST_ENCODED_ELT (V, I) accesses the value of encoded element I.

     VECTOR_CST_DUPLICATE_P (V) is true if V simply contains repeated instances of VECTOR_CST_NPATTERNS (V) values.  This is a shorthand for testing VECTOR_CST_NELTS_PER_PATTERN (V) == 1.

     VECTOR_CST_STEPPED_P (V) is true if at least one pattern in V has a nonzero step.  This is a shorthand for testing VECTOR_CST_NELTS_PER_PATTERN (V) == 3.

     The utility function vector_cst_elt gives the value of an arbitrary index as a tree.  vector_cst_int_elt gives the same value as a wide_int.

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.

POLY_INT_CST
     These nodes represent invariants that depend on some target-specific runtime parameters.  They consist of NUM_POLY_INT_COEFFS coefficients, with the first coefficient being the constant term and the others being multipliers that are applied to the runtime parameters.

     POLY_INT_CST_ELT (X, I) references coefficient number I of POLY_INT_CST node X.  Each coefficient is an INTEGER_CST.

References to storage
---------------------

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.

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.

MEM_REF
     These nodes are used to represent the object pointed to by a pointer offset by a constant. The first operand is the pointer being dereferenced; it will always have pointer or reference type.  The second operand is a pointer constant. Its type is specifying the type to be used for type-based alias analysis.

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.

Unary and Binary Expressions
----------------------------

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.

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

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. Unlike most nodes, these can have a vector as first operand and a scalar as second operand.

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 and POINTER_DIFF_EXPR are the only binary arithmetic operators that can operate on pointer types.

POINTER_DIFF_EXPR
     This node represents pointer subtraction.  The two operands always have pointer/reference type.  It returns a signed integer of the same precision as the pointers.  The behavior is undefined if the difference of the two pointers, seen as infinite precision non-negative integers, does not fit in the result type.  The result does not depend on the pointer type, it is not divided by the size of the pointed-to type.

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.

MULT_HIGHPART_EXPR
     This node represents the ``high-part'' of a widening multiplication. For an integral type with B bits of precision, the result is the most significant B bits of the full 2B product.

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.

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 operands will either be both of integral type, both of floating type or both of vector type.  The result type of these expressions will always be of integral, boolean or signed integral vector type.  These operations return the result type's zero value for false, the result type's one value for true, and a vector whose elements are zero (false) or minus one (true) for vectors.

     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.

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_EXPRs 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_EXPRs also have a CALL_EXPR_STATIC_CHAIN operand that is used to implement nested functions.  This operand is otherwise null.

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 an array.  They contain a sequence of component values made out of a vector of constructor_elt, which is a (INDEX, VALUE) pair.

     If the TREE_TYPE of the CONSTRUCTOR is a RECORD_TYPE, UNION_TYPE or QUAL_UNION_TYPE then the INDEX of each node in the sequence will be a FIELD_DECL and the VALUE will be the expression used to initialize that field.

     If the TREE_TYPE of the CONSTRUCTOR is an ARRAY_TYPE, then the INDEX of each node in the sequence will be an INTEGER_CST or a RANGE_EXPR of two INTEGER_CSTs. A single INTEGER_CST indicates which element of the array is being assigned to.  A RANGE_EXPR indicates an inclusive range of elements to initialize.  In both cases the VALUE is the corresponding initializer.  It is re-evaluated for each element of a RANGE_EXPR.  If the INDEX 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 cleared (zeroed), unless the CONSTRUCTOR_NO_CLEARING flag is set, in which case their value becomes undefined.

COMPOUND_LITERAL_EXPR
     These nodes represent ISO C99 compound literals.  The COMPOUND_LITERAL_EXPR_DECL_EXPR is a DECL_EXPR 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.

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.

ANNOTATE_EXPR
     This node is used to attach markers to an expression. The first operand is the annotated expression, the second is an INTEGER_CST with a value from enum annot_expr_kind, the third is an INTEGER_CST.

Vectors
-------

VEC_DUPLICATE_EXPR
     This node has a single operand and represents a vector in which every element is equal to that operand.

VEC_SERIES_EXPR
     This node represents a vector formed from a scalar base and step, given as the first and second operands respectively.  Element I of the result is equal to BASE + I*STEP.

     This node is restricted to integral types, in order to avoid specifying the rounding behavior for floating-point types.

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_FLOAT_HI_EXPR the high N/2 elements of the vector are extracted, converted and widened.  In the case of VEC_UNPACK_FLOAT_LO_EXPR the low N/2 elements of the vector are extracted, converted and widened.

VEC_UNPACK_FIX_TRUNC_HI_EXPR
VEC_UNPACK_FIX_TRUNC_LO_EXPR
     These nodes represent unpacking of the high and low parts of the input vector, where the values are truncated from floating point to fixed point.  The single operand is a vector that contains N elements of the same floating point 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_UNPACK_FIX_TRUNC_HI_EXPR the high N/2 elements of the vector are extracted and converted with truncation.  In the case of VEC_UNPACK_FIX_TRUNC_LO_EXPR the low N/2 elements of the vector are extracted and converted with truncation.

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_PACK_FLOAT_EXPR
     This node represents packing of elements of the two input vectors into the output vector, where the values are converted from fixed point to floating point.  Input operands are vectors that contain the same number of elements of an integral type.  The result is a vector that contains twice as many elements of floating point type whose size is half as wide.  The elements of the two vectors are merged (concatenated) to form the output vector.

VEC_COND_EXPR
     These nodes represent ?: expressions.  The three operands must be vectors of the same size and number of elements.  The second and third operands must have the same type as the entire expression.  The first operand is of signed integral vector type.  If an element of the first operand evaluates to a zero value, the corresponding element of the result is taken from the third operand. If it evaluates to a minus one value, it is taken from the second operand. It should never evaluate to any other value currently, but optimizations should not rely on that property. In contrast with a COND_EXPR, all operands are always evaluated.

SAD_EXPR
     This node represents the Sum of Absolute Differences operation.  The three operands must be vectors of integral types.  The first and second operand must have the same type.  The size of the vector element of the third operand must be at lease twice of the size of the vector element of the first and second one.  The SAD is calculated between the first and second operands, added to the third operand, and returned.

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.

Basic Statements
----------------

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.

DECL_EXPR

     Used to represent a local declaration.  The DECL_EXPR_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, see Functions.

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.

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.

RETURN_EXPR

     Used to represent a return statement.  Operand 0 represents the value to return.  It should either be the RESULT_DECL for the containing function, or a MODIFY_EXPR or INIT_EXPR setting the function's RESULT_DECL.  It will be NULL_TREE if the statement was just

          return;

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.

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.

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.

DEBUG_BEGIN_STMT

     Marks the beginning of a source statement, for purposes of debug information generation.

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 through their TREE_CHAIN field.  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.  These variables will never require cleanups.  The scope of these variables is just the body

Variable-length arrays (VLAs) complicate this process, as their size often refers to variables initialized earlier in the block and their initialization involves an explicit stack allocation.  To handle this, we add an indirection and replace them with a pointer to stack space allocated by means of alloca.  In most cases, we also arrange for this space to be reclaimed when the enclosing BIND_EXPR is exited, the exception to this being when there is an explicit call to alloca in the source code, in which case the stack is left depressed on exit of the BIND_EXPR.

A C++ program will usually contain more BIND_EXPRs 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.

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.

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.

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.

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.

OpenMP
------

All the statements starting with OMP_ represent directives and clauses used by the OpenMP API https://www.openmp.org.

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 six 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 similar codes) as well as OMP_SECTIONS to mark the place where the code needs to loop to the next iteration, or the next section, respectively.

     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 subcodes 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, OMP_CLAUSE_REDUCTION, OMP_CLAUSE_COLLAPSE, OMP_CLAUSE_UNTIED, OMP_CLAUSE_FINAL, and OMP_CLAUSE_MERGEABLE.  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.

OpenACC
-------

All the statements starting with OACC_ represent directives and clauses used by the OpenACC API https://www.openacc.org.

OACC_CACHE

     Represents #pragma acc cache (var ...).

OACC_DATA

     Represents #pragma acc data [clause1 ... clauseN].

OACC_DECLARE

     Represents #pragma acc declare [clause1 ... clauseN].

OACC_ENTER_DATA

     Represents #pragma acc enter data [clause1 ... clauseN].

OACC_EXIT_DATA

     Represents #pragma acc exit data [clause1 ... clauseN].

OACC_HOST_DATA

     Represents #pragma acc host_data [clause1 ... clauseN].

OACC_KERNELS

     Represents #pragma acc kernels [clause1 ... clauseN].

OACC_LOOP

     Represents #pragma acc loop [clause1 ... clauseN].

     See the description of the OMP_FOR code.

OACC_PARALLEL

     Represents #pragma acc parallel [clause1 ... clauseN].

OACC_UPDATE

     Represents #pragma acc update [clause1 ... clauseN].

Functions
=========

A function is represented by a FUNCTION_DECL node.  It stores the basic pieces of the function such as body, parameters, and return type as well as information on the surrounding context, visibility, and linkage.

Function Basics
---------------

A function has four core parts: the name, the parameters, the result, and the body.  The following macros and functions access these parts of a FUNCTION_DECL as well as other basic features:

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

DECL_SAVED_TREE
     This macro returns the complete body of the function.

TREE_TYPE
     This macro returns the FUNCTION_TYPE or METHOD_TYPE for the function.

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

     It should contain a tree of BLOCK nodes that mirrors the scopes that variables are bound in the function.  Each block contains a list of decls declared in a basic block, a pointer to a chain of blocks at the next lower scope level, then a pointer to the next block at the same level and a backpointer to the parent BLOCK or FUNCTION_DECL.  So given a function as follows:

          void foo()
          {
            int a;
            {
              int b;
            }
            int c;
          }

     you would get the following:

          tree foo = FUNCTION_DECL;
          tree decl_a = VAR_DECL;
          tree decl_b = VAR_DECL;
          tree decl_c = VAR_DECL;
          tree block_a = BLOCK;
          tree block_b = BLOCK;
          tree block_c = BLOCK;
          BLOCK_VARS(block_a) = decl_a;
          BLOCK_SUBBLOCKS(block_a) = block_b;
          BLOCK_CHAIN(block_a) = block_c;
          BLOCK_SUPERCONTEXT(block_a) = foo;
          BLOCK_VARS(block_b) = decl_b;
          BLOCK_SUPERCONTEXT(block_b) = block_a;
          BLOCK_VARS(block_c) = decl_c;
          BLOCK_SUPERCONTEXT(block_c) = foo;
          DECL_INITIAL(foo) = block_a;

Function Properties
-------------------

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.

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.

DECL_EXTERNAL
     This predicate holds if the function is undefined.

TREE_PUBLIC
     This predicate holds if the function has external linkage.

TREE_STATIC
     This predicate holds if the function has been defined.

TREE_THIS_VOLATILE
     This predicate holds if the function does not return normally.

TREE_READONLY
     This predicate holds if the function can only read its arguments.

DECL_PURE_P
     This predicate holds if the function can only read its arguments, but may also read global memory.

DECL_VIRTUAL_P
     This predicate holds if the function is virtual.

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

Language-dependent trees
========================

Front ends may wish to keep some state associated with various GENERIC trees while parsing.  To support this, trees provide a set of flags that may be used by the front end.  They are accessed using TREE_LANG_FLAG_n where n is currently 0 through 6.

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.

C and C++ Trees
===============

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

The C and C++ front ends generate a mix of GENERIC trees and ones specific to C and C++.  These language-specific trees are higher-level constructs than the ones in GENERIC to make the parser's job easier. This section describes those trees that aren't part of GENERIC as well as aspects of GENERIC trees that are treated in a language-specific manner.

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.

Types for C++
-------------

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

The following functions and macros deal with cv-qualification of types:

cp_type_quals
     This function 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.

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 an 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_PTRDATAMEM_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 *.

The table below describes types specific to C and C++ as well as language-dependent info about GENERIC types.

POINTER_TYPE
     Used to represent pointer types, and pointer to data member types.  If TREE_TYPE is a pointer to data member type, then TYPE_PTRDATAMEM_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.

RECORD_TYPE
     Used to represent struct and class types in C and C++.  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 Classes.

UNKNOWN_TYPE
     This node is used to represent a type the knowledge of which is insufficient for a sound processing.

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.

Namespaces
----------

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.

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.

A namespace is represented by a NAMESPACE_DECL node.

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 (see 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, see 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.

Classes
-------

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

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_TYPEs.  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 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.  If a function member is overloaded, each of the overloaded functions appears; no OVERLOAD nodes appear on the TYPE_FIELDS list.  Implicitly declared functions (including default constructors, copy constructors, assignment operators, and destructors) will appear on this list as well.

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.

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

Functions for C++
-----------------

A function is represented by a FUNCTION_DECL node.  A set of overloaded functions is sometimes represented by an 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.

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

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

Statements for C++
------------------

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.

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

BREAK_STMT

     Used to represent a break statement.  There are no additional fields.

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

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.

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:

     C++ distinguishes between this and COND_EXPR for handling templates.

          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.

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.

C++ Expressions
---------------

This section describes expressions specific to the C and C++ front ends.

TYPEID_EXPR

     Used to represent a typeid expression.

NEW_EXPR
VEC_NEW_EXPR

     Used to represent a call to new and new[] respectively.

DELETE_EXPR
VEC_DELETE_EXPR

     Used to represent a call to delete and delete[] respectively.

MEMBER_REF

     Represents a reference to a member of a class.

THROW_EXPR

     Represents an instance of throw in the program.  Operand 0, which is the expression to throw, may be NULL_TREE.

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_EXPRs have a representation similar to that of CALL_EXPRs.  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.

Java Trees
==========