| @c Copyright (C) 2004-2022 Free Software Foundation, Inc. |
| @c This is part of the GCC manual. |
| @c For copying conditions, see the file gcc.texi. |
| |
| @c --------------------------------------------------------------------- |
| @c GENERIC |
| @c --------------------------------------------------------------------- |
| |
| @node GENERIC |
| @chapter GENERIC |
| @cindex 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 @code{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 @code{TREE_SIDE_EFFECTS} set (or it |
| will be discarded), but a non-statement expression may also have |
| side effects. A @code{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 @code{tree_rest_of_compilation}, but this |
| seems inelegant. |
| |
| @menu |
| * Deficiencies:: Topics not yet covered in this document. |
| * Tree overview:: All about @code{tree}s. |
| * Types:: Fundamental and aggregate types. |
| * Declarations:: Type declarations and variables. |
| * Attributes:: Declaration and type attributes. |
| * Expressions: Expression trees. Operating on data. |
| * Statements:: Control flow and related trees. |
| * Functions:: Function bodies, linkage, and other aspects. |
| * Language-dependent trees:: Topics and trees specific to language front ends. |
| * C and C++ Trees:: Trees specific to C and C++. |
| @end menu |
| |
| @c --------------------------------------------------------------------- |
| @c Deficiencies |
| @c --------------------------------------------------------------------- |
| |
| @node Deficiencies |
| @section Deficiencies |
| |
| @c The spelling of "incomplet" and "incorrekt" below is intentional. |
| There are many places in which this document is incomplet and incorrekt. |
| It is, as of yet, only @emph{preliminary} documentation. |
| |
| @c --------------------------------------------------------------------- |
| @c Overview |
| @c --------------------------------------------------------------------- |
| |
| @node Tree overview |
| @section Overview |
| @cindex tree |
| @findex TREE_CODE |
| |
| The central data structure used by the internal representation is the |
| @code{tree}. These nodes, while all of the C type @code{tree}, are of |
| many varieties. A @code{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 @code{this |
| font}, except when talking about the actual C type @code{tree}. |
| |
| You can tell what kind of node a particular tree is by using the |
| @code{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 @option{--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 @samp{_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 @code{0}, so that statements like |
| @smallexample |
| if (TEST_P (t) && !TEST_P (y)) |
| x = 1; |
| @end smallexample |
| @noindent |
| and |
| @smallexample |
| int i = (TEST_P (t) != 0); |
| @end smallexample |
| @noindent |
| are legal. Macros that return @code{int} values now may be changed to |
| return @code{tree} values, or other pointers in the future. Even those |
| that continue to return @code{int} may return multiple nonzero codes |
| where previously they returned only zero and one. Therefore, you should |
| not write code like |
| @smallexample |
| if (TEST_P (t) == 1) |
| @end smallexample |
| @noindent |
| 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 @code{error_mark_node} is a special tree. Its tree code is |
| @code{ERROR_MARK}, but since there is only ever one node with that code, |
| the usual practice is to compare the tree against |
| @code{error_mark_node}. (This test is just a test for pointer |
| equality.) If an error has occurred during front-end processing the |
| flag @code{errorcount} will be set. If the front end has encountered |
| code it cannot handle, it will issue a message to the user and set |
| @code{sorrycount}. When these flags are set, any macro or function |
| which normally returns a tree of a particular kind may instead return |
| the @code{error_mark_node}. Thus, if you intend to do any processing of |
| erroneous code, you must be prepared to deal with the |
| @code{error_mark_node}. |
| |
| Occasionally, a particular tree slot (like an operand to an expression, |
| or a particular field in a declaration) will be referred to as |
| ``reserved for the back end''. These slots are used to store RTL when |
| the tree is converted to RTL for use by the GCC back end. However, if |
| that process is not taking place (e.g., if the front end is being hooked |
| up to an intelligent editor), then those slots may be used by the |
| back end presently in use. |
| |
| If you encounter situations that do not match this documentation, such |
| as tree nodes of types not mentioned here, or macros documented to |
| return entities of a particular kind that instead return entities of |
| some different kind, you have found a bug, either in the front end or in |
| the documentation. Please report these bugs as you would any other |
| bug. |
| |
| @menu |
| * Macros and Functions::Macros and functions that can be used with all trees. |
| * Identifiers:: The names of things. |
| * Containers:: Lists and vectors. |
| @end menu |
| |
| @c --------------------------------------------------------------------- |
| @c Trees |
| @c --------------------------------------------------------------------- |
| |
| @node Macros and Functions |
| @subsection Trees |
| @cindex tree |
| @findex TREE_CHAIN |
| @findex TREE_TYPE |
| |
| All GENERIC trees have two fields in common. First, @code{TREE_CHAIN} |
| is a pointer that can be used as a singly-linked list to other trees. |
| The other is @code{TREE_TYPE}. Many trees store the type of an |
| expression or declaration in this field. |
| |
| These are some other functions for handling trees: |
| |
| @ftable @code |
| |
| @item tree_size |
| Return the number of bytes a tree takes. |
| |
| @item build0 |
| @itemx build1 |
| @itemx build2 |
| @itemx build3 |
| @itemx build4 |
| @itemx build5 |
| @itemx build6 |
| |
| These functions build a tree and supply values to put in each |
| parameter. The basic signature is @samp{@w{code, type, [operands]}}. |
| @code{code} is the @code{TREE_CODE}, and @code{type} is a tree |
| representing the @code{TREE_TYPE}. These are followed by the |
| operands, each of which is also a tree. |
| |
| @end ftable |
| |
| |
| @c --------------------------------------------------------------------- |
| @c Identifiers |
| @c --------------------------------------------------------------------- |
| |
| @node Identifiers |
| @subsection Identifiers |
| @cindex identifier |
| @cindex name |
| @tindex IDENTIFIER_NODE |
| |
| An @code{IDENTIFIER_NODE} represents a slightly more general concept |
| than the standard C or C++ concept of identifier. In particular, an |
| @code{IDENTIFIER_NODE} may contain a @samp{$}, or other extraordinary |
| characters. |
| |
| There are never two distinct @code{IDENTIFIER_NODE}s representing the |
| same identifier. Therefore, you may use pointer equality to compare |
| @code{IDENTIFIER_NODE}s, rather than using a routine like |
| @code{strcmp}. Use @code{get_identifier} to obtain the unique |
| @code{IDENTIFIER_NODE} for a supplied string. |
| |
| You can use the following macros to access identifiers: |
| @ftable @code |
| @item IDENTIFIER_POINTER |
| The string represented by the identifier, represented as a |
| @code{char*}. This string is always @code{NUL}-terminated, and contains |
| no embedded @code{NUL} characters. |
| |
| @item IDENTIFIER_LENGTH |
| The length of the string returned by @code{IDENTIFIER_POINTER}, not |
| including the trailing @code{NUL}. This value of |
| @code{IDENTIFIER_LENGTH (x)} is always the same as @code{strlen |
| (IDENTIFIER_POINTER (x))}. |
| |
| @item 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 @code{IDENTIFIER_POINTER} or the |
| @code{IDENTIFIER_LENGTH}. |
| |
| @item IDENTIFIER_TYPENAME_P |
| This predicate holds if the identifier represents the name of a |
| user-defined conversion operator. In this case, the @code{TREE_TYPE} of |
| the @code{IDENTIFIER_NODE} holds the type to which the conversion |
| operator converts. |
| |
| @end ftable |
| |
| @c --------------------------------------------------------------------- |
| @c Containers |
| @c --------------------------------------------------------------------- |
| |
| @node Containers |
| @subsection Containers |
| @cindex container |
| @cindex list |
| @cindex vector |
| @tindex TREE_LIST |
| @tindex TREE_VEC |
| @findex TREE_PURPOSE |
| @findex TREE_VALUE |
| @findex TREE_VEC_LENGTH |
| @findex TREE_VEC_ELT |
| |
| Two common container data structures can be represented directly with |
| tree nodes. A @code{TREE_LIST} is a singly linked list containing two |
| trees per node. These are the @code{TREE_PURPOSE} and @code{TREE_VALUE} |
| of each node. (Often, the @code{TREE_PURPOSE} contains some kind of |
| tag, or additional information, while the @code{TREE_VALUE} contains the |
| majority of the payload. In other cases, the @code{TREE_PURPOSE} is |
| simply @code{NULL_TREE}, while in still others both the |
| @code{TREE_PURPOSE} and @code{TREE_VALUE} are of equal stature.) Given |
| one @code{TREE_LIST} node, the next node is found by following the |
| @code{TREE_CHAIN}. If the @code{TREE_CHAIN} is @code{NULL_TREE}, then |
| you have reached the end of the list. |
| |
| A @code{TREE_VEC} is a simple vector. The @code{TREE_VEC_LENGTH} is an |
| integer (not a tree) giving the number of nodes in the vector. The |
| nodes themselves are accessed using the @code{TREE_VEC_ELT} macro, which |
| takes two arguments. The first is the @code{TREE_VEC} in question; the |
| second is an integer indicating which element in the vector is desired. |
| The elements are indexed from zero. |
| |
| @c --------------------------------------------------------------------- |
| @c Types |
| @c --------------------------------------------------------------------- |
| |
| @node Types |
| @section Types |
| @cindex type |
| @cindex pointer |
| @cindex reference |
| @cindex fundamental type |
| @cindex array |
| @tindex VOID_TYPE |
| @tindex INTEGER_TYPE |
| @tindex TYPE_MIN_VALUE |
| @tindex TYPE_MAX_VALUE |
| @tindex REAL_TYPE |
| @tindex FIXED_POINT_TYPE |
| @tindex COMPLEX_TYPE |
| @tindex ENUMERAL_TYPE |
| @tindex BOOLEAN_TYPE |
| @tindex POINTER_TYPE |
| @tindex REFERENCE_TYPE |
| @tindex FUNCTION_TYPE |
| @tindex METHOD_TYPE |
| @tindex ARRAY_TYPE |
| @tindex RECORD_TYPE |
| @tindex UNION_TYPE |
| @tindex OPAQUE_TYPE |
| @tindex UNKNOWN_TYPE |
| @tindex OFFSET_TYPE |
| @findex TYPE_UNQUALIFIED |
| @findex TYPE_QUAL_CONST |
| @findex TYPE_QUAL_VOLATILE |
| @findex TYPE_QUAL_RESTRICT |
| @findex TYPE_MAIN_VARIANT |
| @cindex qualified type |
| @findex TYPE_SIZE |
| @findex TYPE_ALIGN |
| @findex TYPE_PRECISION |
| @findex TYPE_ARG_TYPES |
| @findex TYPE_METHOD_BASETYPE |
| @findex TYPE_OFFSET_BASETYPE |
| @findex TREE_TYPE |
| @findex TYPE_CONTEXT |
| @findex TYPE_NAME |
| @findex TYPENAME_TYPE_FULLNAME |
| @findex TYPE_FIELDS |
| @findex TYPE_CANONICAL |
| @findex TYPE_STRUCTURAL_EQUALITY_P |
| @findex SET_TYPE_STRUCTURAL_EQUALITY |
| |
| 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 @code{POINTER_TYPE} code while arrays |
| use an @code{ARRAY_TYPE} code.) However, pointers to member functions |
| use the @code{RECORD_TYPE} code. Therefore, when writing a |
| @code{switch} statement that depends on the code associated with a |
| particular type, you should take care to handle pointers to member |
| functions under the @code{RECORD_TYPE} case label. |
| |
| The following functions and macros deal with cv-qualification of types: |
| @ftable @code |
| @item 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. |
| @end ftable |
| |
| A few other macros and functions are usable with all types: |
| @ftable @code |
| @item TYPE_SIZE |
| The number of bits required to represent the type, represented as an |
| @code{INTEGER_CST}. For an incomplete type, @code{TYPE_SIZE} will be |
| @code{NULL_TREE}. |
| |
| @item TYPE_ALIGN |
| The alignment of the type, in bits, represented as an @code{int}. |
| |
| @item TYPE_NAME |
| This macro returns a declaration (in the form of a @code{TYPE_DECL}) for |
| the type. (Note this macro does @emph{not} return an |
| @code{IDENTIFIER_NODE}, as you might expect, given its name!) You can |
| look at the @code{DECL_NAME} of the @code{TYPE_DECL} to obtain the |
| actual name of the type. The @code{TYPE_NAME} will be @code{NULL_TREE} |
| for a type that is not a built-in type, the result of a typedef, or a |
| named class type. |
| |
| @item 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 @code{same_type_p}: if the @code{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 @code{TYPE_CANONICAL} is @code{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, @code{int} is its own |
| canonical type. A typedef @code{I} of @code{int} will have @code{int} |
| as its canonical type. Similarly, @code{I*}@ and a typedef @code{IP}@ |
| (defined to @code{I*}) will has @code{int*} as their canonical |
| type. When building a new type node, be sure to set |
| @code{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 |
| @code{SET_TYPE_STRUCTURAL_EQUALITY} to ensure that the new type also |
| requires structural equality. Finally, if for some reason you cannot |
| guarantee that @code{TYPE_CANONICAL} will point to the canonical type, |
| use @code{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 @code{--param verify-canonical-types=1} to |
| the compiler or configure with @code{--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. |
| |
| @item TYPE_STRUCTURAL_EQUALITY_P |
| This predicate holds when the node requires structural equality |
| checks, e.g., when @code{TYPE_CANONICAL} is @code{NULL_TREE}. |
| |
| @item SET_TYPE_STRUCTURAL_EQUALITY |
| This macro states that the type node it is given requires structural |
| equality checks, e.g., it sets @code{TYPE_CANONICAL} to |
| @code{NULL_TREE}. |
| |
| @item 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 @code{typedef} for the other, or |
| both are @code{typedef}s for the same type. This predicate also holds if |
| the two trees given as input are simply copies of one another; i.e., |
| there is no difference between them at the source level, but, for |
| whatever reason, a duplicate has been made in the representation. You |
| should never use @code{==} (pointer equality) to compare types; always |
| use @code{same_type_p} instead. |
| @end ftable |
| |
| 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. |
| |
| @table @code |
| @item VOID_TYPE |
| Used to represent the @code{void} type. |
| |
| @item INTEGER_TYPE |
| Used to represent the various integral types, including @code{char}, |
| @code{short}, @code{int}, @code{long}, and @code{long long}. This code |
| is not used for enumeration types, nor for the @code{bool} type. |
| The @code{TYPE_PRECISION} is the number of bits used in |
| the representation, represented as an @code{unsigned int}. (Note that |
| in the general case this is not the same value as @code{TYPE_SIZE}; |
| suppose that there were a 24-bit integer type, but that alignment |
| requirements for the ABI required 32-bit alignment. Then, |
| @code{TYPE_SIZE} would be an @code{INTEGER_CST} for 32, while |
| @code{TYPE_PRECISION} would be 24.) The integer type is unsigned if |
| @code{TYPE_UNSIGNED} holds; otherwise, it is signed. |
| |
| The @code{TYPE_MIN_VALUE} is an @code{INTEGER_CST} for the smallest |
| integer that may be represented by this type. Similarly, the |
| @code{TYPE_MAX_VALUE} is an @code{INTEGER_CST} for the largest integer |
| that may be represented by this type. |
| |
| @item REAL_TYPE |
| Used to represent the @code{float}, @code{double}, and @code{long |
| double} types. The number of bits in the floating-point representation |
| is given by @code{TYPE_PRECISION}, as in the @code{INTEGER_TYPE} case. |
| |
| @item FIXED_POINT_TYPE |
| Used to represent the @code{short _Fract}, @code{_Fract}, @code{long |
| _Fract}, @code{long long _Fract}, @code{short _Accum}, @code{_Accum}, |
| @code{long _Accum}, and @code{long long _Accum} types. The number of bits |
| in the fixed-point representation is given by @code{TYPE_PRECISION}, |
| as in the @code{INTEGER_TYPE} case. There may be padding bits, fractional |
| bits and integral bits. The number of fractional bits is given by |
| @code{TYPE_FBIT}, and the number of integral bits is given by @code{TYPE_IBIT}. |
| The fixed-point type is unsigned if @code{TYPE_UNSIGNED} holds; otherwise, |
| it is signed. |
| The fixed-point type is saturating if @code{TYPE_SATURATING} holds; otherwise, |
| it is not saturating. |
| |
| @item COMPLEX_TYPE |
| Used to represent GCC built-in @code{__complex__} data types. The |
| @code{TREE_TYPE} is the type of the real and imaginary parts. |
| |
| @item ENUMERAL_TYPE |
| Used to represent an enumeration type. The @code{TYPE_PRECISION} gives |
| (as an @code{int}), the number of bits used to represent the type. If |
| there are no negative enumeration constants, @code{TYPE_UNSIGNED} will |
| hold. The minimum and maximum enumeration constants may be obtained |
| with @code{TYPE_MIN_VALUE} and @code{TYPE_MAX_VALUE}, respectively; each |
| of these macros returns an @code{INTEGER_CST}. |
| |
| The actual enumeration constants themselves may be obtained by looking |
| at the @code{TYPE_VALUES}. This macro will return a @code{TREE_LIST}, |
| containing the constants. The @code{TREE_PURPOSE} of each node will be |
| an @code{IDENTIFIER_NODE} giving the name of the constant; the |
| @code{TREE_VALUE} will be an @code{INTEGER_CST} giving the value |
| assigned to that constant. These constants will appear in the order in |
| which they were declared. The @code{TREE_TYPE} of each of these |
| constants will be the type of enumeration type itself. |
| |
| @item OPAQUE_TYPE |
| Used for things that have a @code{MODE_OPAQUE} mode class in the |
| backend. Opaque types have a size and precision, and can be held in |
| memory or registers. They are used when we do not want the compiler to |
| make assumptions about the availability of other operations as would |
| happen with integer types. |
| |
| @item BOOLEAN_TYPE |
| Used to represent the @code{bool} type. |
| |
| @item POINTER_TYPE |
| Used to represent pointer types, and pointer to data member types. The |
| @code{TREE_TYPE} gives the type to which this type points. |
| |
| @item REFERENCE_TYPE |
| Used to represent reference types. The @code{TREE_TYPE} gives the type |
| to which this type refers. |
| |
| @item FUNCTION_TYPE |
| Used to represent the type of non-member functions and of static member |
| functions. The @code{TREE_TYPE} gives the return type of the function. |
| The @code{TYPE_ARG_TYPES} are a @code{TREE_LIST} of the argument types. |
| The @code{TREE_VALUE} of each node in this list is the type of the |
| corresponding argument; the @code{TREE_PURPOSE} is an expression for the |
| default argument value, if any. If the last node in the list is |
| @code{void_list_node} (a @code{TREE_LIST} node whose @code{TREE_VALUE} |
| is the @code{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 @code{void f()} |
| is an unprototyped function taking a variable number of arguments; the |
| @code{TYPE_ARG_TYPES} of such a function will be @code{NULL}. |
| |
| @item METHOD_TYPE |
| Used to represent the type of a non-static member function. Like a |
| @code{FUNCTION_TYPE}, the return type is given by the @code{TREE_TYPE}. |
| The type of @code{*this}, i.e., the class of which functions of this |
| type are a member, is given by the @code{TYPE_METHOD_BASETYPE}. The |
| @code{TYPE_ARG_TYPES} is the parameter list, as for a |
| @code{FUNCTION_TYPE}, and includes the @code{this} argument. |
| |
| @item ARRAY_TYPE |
| Used to represent array types. The @code{TREE_TYPE} gives the type of |
| the elements in the array. If the array-bound is present in the type, |
| the @code{TYPE_DOMAIN} is an @code{INTEGER_TYPE} whose |
| @code{TYPE_MIN_VALUE} and @code{TYPE_MAX_VALUE} will be the lower and |
| upper bounds of the array, respectively. The @code{TYPE_MIN_VALUE} will |
| always be an @code{INTEGER_CST} for zero, while the |
| @code{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. |
| |
| @item RECORD_TYPE |
| Used to represent @code{struct} and @code{class} types, as well as |
| pointers to member functions and similar constructs in other languages. |
| @code{TYPE_FIELDS} contains the items contained in this type, each of |
| which can be a @code{FIELD_DECL}, @code{VAR_DECL}, @code{CONST_DECL}, or |
| @code{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. |
| |
| @item UNION_TYPE |
| Used to represent @code{union} types. Similar to @code{RECORD_TYPE} |
| except that all @code{FIELD_DECL} nodes in @code{TYPE_FIELD} start at |
| bit position zero. |
| |
| @item QUAL_UNION_TYPE |
| Used to represent part of a variant record in Ada. Similar to |
| @code{UNION_TYPE} except that each @code{FIELD_DECL} has a |
| @code{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 @code{DECL_QUALIFIER} is only evaluated |
| if none of the expressions in the previous fields in @code{TYPE_FIELDS} |
| are nonzero. Normally these expressions will reference a field in the |
| outer object using a @code{PLACEHOLDER_EXPR}. |
| |
| @item LANG_TYPE |
| This node is used to represent a language-specific type. The front |
| end must handle it. |
| |
| @item OFFSET_TYPE |
| This node is used to represent a pointer-to-data member. For a data |
| member @code{X::m} the @code{TYPE_OFFSET_BASETYPE} is @code{X} and the |
| @code{TREE_TYPE} is the type of @code{m}. |
| |
| @end table |
| |
| There are variables whose values represent some of the basic types. |
| These include: |
| @table @code |
| @item void_type_node |
| A node for @code{void}. |
| |
| @item integer_type_node |
| A node for @code{int}. |
| |
| @item unsigned_type_node. |
| A node for @code{unsigned int}. |
| |
| @item char_type_node. |
| A node for @code{char}. |
| @end table |
| @noindent |
| It may sometimes be useful to compare one of these variables with a type |
| in hand, using @code{same_type_p}. |
| |
| @c --------------------------------------------------------------------- |
| @c Declarations |
| @c --------------------------------------------------------------------- |
| |
| @node Declarations |
| @section Declarations |
| @cindex declaration |
| @cindex variable |
| @cindex type declaration |
| @tindex LABEL_DECL |
| @tindex CONST_DECL |
| @tindex TYPE_DECL |
| @tindex VAR_DECL |
| @tindex PARM_DECL |
| @tindex DEBUG_EXPR_DECL |
| @tindex FIELD_DECL |
| @tindex NAMESPACE_DECL |
| @tindex RESULT_DECL |
| @tindex TEMPLATE_DECL |
| @tindex THUNK_DECL |
| @findex THUNK_DELTA |
| @findex DECL_INITIAL |
| @findex DECL_SIZE |
| @findex DECL_ALIGN |
| @findex DECL_EXTERNAL |
| |
| This section covers the various kinds of declarations that appear in the |
| internal representation, except for declarations of functions |
| (represented by @code{FUNCTION_DECL} nodes), which are described in |
| @ref{Functions}. |
| |
| @menu |
| * Working with declarations:: Macros and functions that work on |
| declarations. |
| * Internal structure:: How declaration nodes are represented. |
| @end menu |
| |
| @node Working with declarations |
| @subsection Working with declarations |
| |
| Some macros can be used with any kind of declaration. These include: |
| @ftable @code |
| @item DECL_NAME |
| This macro returns an @code{IDENTIFIER_NODE} giving the name of the |
| entity. |
| |
| @item TREE_TYPE |
| This macro returns the type of the entity declared. |
| |
| @item EXPR_FILENAME |
| This macro returns the name of the file in which the entity was |
| declared, as a @code{char*}. For an entity declared implicitly by the |
| compiler (like @code{__builtin_memcpy}), this will be the string |
| @code{"<internal>"}. |
| |
| @item EXPR_LINENO |
| This macro returns the line number at which the entity was declared, as |
| an @code{int}. |
| |
| @item 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 @code{TYPE_DECL} implicitly |
| generated for a class type. Recall that in C++ code like: |
| @smallexample |
| struct S @{@}; |
| @end smallexample |
| @noindent |
| is roughly equivalent to C code like: |
| @smallexample |
| struct S @{@}; |
| typedef struct S S; |
| @end smallexample |
| The implicitly generated @code{typedef} declaration is represented by a |
| @code{TYPE_DECL} for which @code{DECL_ARTIFICIAL} holds. |
| |
| @end ftable |
| |
| The various kinds of declarations include: |
| @table @code |
| @item LABEL_DECL |
| These nodes are used to represent labels in function bodies. For more |
| information, see @ref{Functions}. These nodes only appear in block |
| scopes. |
| |
| @item CONST_DECL |
| These nodes are used to represent enumeration constants. The value of |
| the constant is given by @code{DECL_INITIAL} which will be an |
| @code{INTEGER_CST} with the same type as the @code{TREE_TYPE} of the |
| @code{CONST_DECL}, i.e., an @code{ENUMERAL_TYPE}. |
| |
| @item RESULT_DECL |
| These nodes represent the value returned by a function. When a value is |
| assigned to a @code{RESULT_DECL}, that indicates that the value should |
| be returned, via bitwise copy, by the function. You can use |
| @code{DECL_SIZE} and @code{DECL_ALIGN} on a @code{RESULT_DECL}, just as |
| with a @code{VAR_DECL}. |
| |
| @item TYPE_DECL |
| These nodes represent @code{typedef} declarations. The @code{TREE_TYPE} |
| is the type declared to have the name given by @code{DECL_NAME}. In |
| some cases, there is no associated name. |
| |
| @item VAR_DECL |
| These nodes represent variables with namespace or block scope, as well |
| as static data members. The @code{DECL_SIZE} and @code{DECL_ALIGN} are |
| analogous to @code{TYPE_SIZE} and @code{TYPE_ALIGN}. For a declaration, |
| you should always use the @code{DECL_SIZE} and @code{DECL_ALIGN} rather |
| than the @code{TYPE_SIZE} and @code{TYPE_ALIGN} given by the |
| @code{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 @code{DECL_THIS_STATIC} or @code{DECL_THIS_EXTERN} to test |
| whether the storage class specifiers @code{static} or @code{extern} were |
| used to declare a variable. |
| |
| If this variable is initialized (but does not require a constructor), |
| the @code{DECL_INITIAL} will be an expression for the initializer. The |
| initializer should be evaluated, and a bitwise copy into the variable |
| performed. If the @code{DECL_INITIAL} is the @code{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 @code{VAR_DECL} if @code{DECL_REGISTER} |
| holds for the @code{VAR_DECL}, and if @code{DECL_ASSEMBLER_NAME} is not |
| equal to @code{DECL_NAME}. In that case, @code{DECL_ASSEMBLER_NAME} is |
| the name of the register into which the variable will be placed. |
| |
| @item PARM_DECL |
| Used to represent a parameter to a function. Treat these nodes |
| similarly to @code{VAR_DECL} nodes. These nodes only appear in the |
| @code{DECL_ARGUMENTS} for a @code{FUNCTION_DECL}. |
| |
| The @code{DECL_ARG_TYPE} for a @code{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 @code{TREE_TYPE} of the parameter; for example, the |
| ordinary type might be @code{short} while the @code{DECL_ARG_TYPE} is |
| @code{int}. |
| |
| @item 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. |
| |
| @item FIELD_DECL |
| These nodes represent non-static data members. The @code{DECL_SIZE} and |
| @code{DECL_ALIGN} behave as for @code{VAR_DECL} nodes. |
| The position of the field within the parent record is specified by a |
| combination of three attributes. @code{DECL_FIELD_OFFSET} is the position, |
| counting in bytes, of the @code{DECL_OFFSET_ALIGN}-bit sized word containing |
| the bit of the field closest to the beginning of the structure. |
| @code{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 @code{DECL_OFFSET_ALIGN} may be greater than the natural alignment |
| of the field's type. |
| |
| If @code{DECL_C_BIT_FIELD} holds, this field is a bit-field. In a bit-field, |
| @code{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. |
| |
| @item NAMESPACE_DECL |
| Namespaces provide a name hierarchy for other declarations. They |
| appear in the @code{DECL_CONTEXT} of other @code{_DECL} nodes. |
| |
| @end table |
| |
| @node Internal structure |
| @subsection Internal structure |
| |
| @code{DECL} nodes are represented internally as a hierarchy of |
| structures. |
| |
| @menu |
| * Current structure hierarchy:: The current DECL node structure |
| hierarchy. |
| * Adding new DECL node types:: How to add a new DECL node to a |
| frontend. |
| @end menu |
| |
| @node Current structure hierarchy |
| @subsubsection Current structure hierarchy |
| |
| @table @code |
| |
| @item struct tree_decl_minimal |
| This is the minimal structure to inherit from in order for common |
| @code{DECL} macros to work. The fields it contains are a unique ID, |
| source location, context, and name. |
| |
| @item struct tree_decl_common |
| This structure inherits from @code{struct tree_decl_minimal}. It |
| contains fields that most @code{DECL} nodes need, such as a field to |
| store alignment, machine mode, size, and attributes. |
| |
| @item struct tree_field_decl |
| This structure inherits from @code{struct tree_decl_common}. It is |
| used to represent @code{FIELD_DECL}. |
| |
| @item struct tree_label_decl |
| This structure inherits from @code{struct tree_decl_common}. It is |
| used to represent @code{LABEL_DECL}. |
| |
| @item struct tree_translation_unit_decl |
| This structure inherits from @code{struct tree_decl_common}. It is |
| used to represent @code{TRANSLATION_UNIT_DECL}. |
| |
| @item struct tree_decl_with_rtl |
| This structure inherits from @code{struct tree_decl_common}. It |
| contains a field to store the low-level RTL associated with a |
| @code{DECL} node. |
| |
| @item struct tree_result_decl |
| This structure inherits from @code{struct tree_decl_with_rtl}. It is |
| used to represent @code{RESULT_DECL}. |
| |
| @item struct tree_const_decl |
| This structure inherits from @code{struct tree_decl_with_rtl}. It is |
| used to represent @code{CONST_DECL}. |
| |
| @item struct tree_parm_decl |
| This structure inherits from @code{struct tree_decl_with_rtl}. It is |
| used to represent @code{PARM_DECL}. |
| |
| @item struct tree_decl_with_vis |
| This structure inherits from @code{struct tree_decl_with_rtl}. It |
| contains fields necessary to store visibility information, as well as |
| a section name and assembler name. |
| |
| @item struct tree_var_decl |
| This structure inherits from @code{struct tree_decl_with_vis}. It is |
| used to represent @code{VAR_DECL}. |
| |
| @item struct tree_function_decl |
| This structure inherits from @code{struct tree_decl_with_vis}. It is |
| used to represent @code{FUNCTION_DECL}. |
| |
| @end table |
| @node Adding new DECL node types |
| @subsubsection Adding new DECL node types |
| |
| Adding a new @code{DECL} tree consists of the following steps |
| |
| @table @asis |
| |
| @item Add a new tree code for the @code{DECL} node |
| For language specific @code{DECL} nodes, there is a @file{.def} file |
| in each frontend directory where the tree code should be added. |
| For @code{DECL} nodes that are part of the middle-end, the code should |
| be added to @file{tree.def}. |
| |
| @item Create a new structure type for the @code{DECL} node |
| These structures should inherit from one of the existing structures in |
| the language hierarchy by using that structure as the first member. |
| |
| @smallexample |
| struct tree_foo_decl |
| @{ |
| struct tree_decl_with_vis common; |
| @} |
| @end smallexample |
| |
| Would create a structure name @code{tree_foo_decl} that inherits from |
| @code{struct tree_decl_with_vis}. |
| |
| For language specific @code{DECL} nodes, this new structure type |
| should go in the appropriate @file{.h} file. |
| For @code{DECL} nodes that are part of the middle-end, the structure |
| type should go in @file{tree.h}. |
| |
| @item Add a member to the tree structure enumerator for the node |
| For garbage collection and dynamic checking purposes, each @code{DECL} |
| node structure type is required to have a unique enumerator value |
| specified with it. |
| For language specific @code{DECL} nodes, this new enumerator value |
| should go in the appropriate @file{.def} file. |
| For @code{DECL} nodes that are part of the middle-end, the enumerator |
| values are specified in @file{treestruct.def}. |
| |
| @item Update @code{union tree_node} |
| In order to make your new structure type usable, it must be added to |
| @code{union tree_node}. |
| For language specific @code{DECL} nodes, a new entry should be added |
| to the appropriate @file{.h} file of the form |
| @smallexample |
| struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl; |
| @end smallexample |
| For @code{DECL} nodes that are part of the middle-end, the additional |
| member goes directly into @code{union tree_node} in @file{tree.h}. |
| |
| @item Update dynamic checking info |
| In order to be able to check whether accessing a named portion of |
| @code{union tree_node} is legal, and whether a certain @code{DECL} node |
| contains one of the enumerated @code{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 @code{DECL} nodes, there is an @code{init_ts} |
| function in an appropriate @file{.c} file, which initializes the lookup |
| table. |
| Code setting up the table for new @code{DECL} nodes should be added |
| there. |
| For each @code{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 @code{FOO_DECL} node derived from @code{struct decl_with_rtl}, |
| and enumerator value @code{TS_FOO_DECL}, would be set up as follows |
| @smallexample |
| 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; |
| @end smallexample |
| |
| For @code{DECL} nodes that are part of the middle-end, the setup code |
| goes into @file{tree.cc}. |
| |
| @item 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 |
| @code{DECL} nodes access the field. |
| |
| These macros generally take the following form |
| @smallexample |
| #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname |
| @end smallexample |
| However, if the structure is simply a base class for further |
| structures, something like the following should be used |
| @smallexample |
| #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT) |
| #define BASE_STRUCT_FIELDNAME(NODE) \ |
| (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname |
| @end smallexample |
| |
| Reading them from the generated @file{all-tree.def} file (which in |
| turn includes all the @file{tree.def} files), @file{gencheck.cc} is |
| used during GCC's build to generate the @code{*_CHECK} macros for all |
| tree codes. |
| |
| @end table |
| |
| |
| @c --------------------------------------------------------------------- |
| @c Attributes |
| @c --------------------------------------------------------------------- |
| @node Attributes |
| @section Attributes in trees |
| @cindex attributes |
| |
| Attributes, as specified using the @code{__attribute__} keyword, are |
| represented internally as a @code{TREE_LIST}. The @code{TREE_PURPOSE} |
| is the name of the attribute, as an @code{IDENTIFIER_NODE}. The |
| @code{TREE_VALUE} is a @code{TREE_LIST} of the arguments of the |
| attribute, if any, or @code{NULL_TREE} if there are no arguments; the |
| arguments are stored as the @code{TREE_VALUE} of successive entries in |
| the list, and may be identifiers or expressions. The @code{TREE_CHAIN} |
| of the attribute is the next attribute in a list of attributes applying |
| to the same declaration or type, or @code{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. |
| |
| @deftypefn {Tree Macro} tree DECL_ATTRIBUTES (tree @var{decl}) |
| This macro returns the attributes on the declaration @var{decl}. |
| @end deftypefn |
| |
| @deftypefn {Tree Macro} tree TYPE_ATTRIBUTES (tree @var{type}) |
| This macro returns the attributes on the type @var{type}. |
| @end deftypefn |
| |
| |
| @c --------------------------------------------------------------------- |
| @c Expressions |
| @c --------------------------------------------------------------------- |
| |
| @node Expression trees |
| @section Expressions |
| @cindex expression |
| @findex TREE_TYPE |
| @findex TREE_OPERAND |
| |
| 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: |
| |
| @ftable @code |
| @item 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. |
| @end ftable |
| |
| In what follows, some nodes that one might expect to always have type |
| @code{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 |
| @code{TREE_OPERAND} macro. For example, to access the first operand to |
| a binary plus expression @code{expr}, use: |
| |
| @smallexample |
| TREE_OPERAND (expr, 0) |
| @end smallexample |
| @noindent |
| |
| As this example indicates, the operands are zero-indexed. |
| |
| |
| @menu |
| * Constants: Constant expressions. |
| * Storage References:: |
| * Unary and Binary Expressions:: |
| * Vectors:: |
| @end menu |
| |
| @node Constant expressions |
| @subsection Constant expressions |
| @tindex INTEGER_CST |
| @findex tree_int_cst_lt |
| @findex tree_int_cst_equal |
| @tindex tree_fits_uhwi_p |
| @tindex tree_fits_shwi_p |
| @tindex tree_to_uhwi |
| @tindex tree_to_shwi |
| @tindex TREE_INT_CST_NUNITS |
| @tindex TREE_INT_CST_ELT |
| @tindex TREE_INT_CST_LOW |
| @tindex REAL_CST |
| @tindex FIXED_CST |
| @tindex COMPLEX_CST |
| @tindex VECTOR_CST |
| @tindex STRING_CST |
| @tindex POLY_INT_CST |
| @findex TREE_STRING_LENGTH |
| @findex TREE_STRING_POINTER |
| |
| The table below begins with constants, moves on to unary expressions, |
| then proceeds to binary expressions, and concludes with various other |
| kinds of expressions: |
| |
| @table @code |
| @item INTEGER_CST |
| These nodes represent integer constants. Note that the type of these |
| constants is obtained with @code{TREE_TYPE}; they are not always of type |
| @code{int}. In particular, @code{char} constants are represented with |
| @code{INTEGER_CST} nodes. The value of the integer constant @code{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 @code{e} |
| is available via @code{TREE_INT_CST_NUNITS}. Element @code{i} can be |
| extracted by using @code{TREE_INT_CST_ELT (e, i)}. |
| @code{TREE_INT_CST_LOW} is a shorthand for @code{TREE_INT_CST_ELT (e, 0)}. |
| |
| The functions @code{tree_fits_shwi_p} and @code{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 @code{tree_to_shwi} and |
| @code{tree_to_uhwi}. |
| |
| @item REAL_CST |
| |
| FIXME: Talk about how to obtain representations of this constant, do |
| comparisons, and so forth. |
| |
| @item FIXED_CST |
| |
| These nodes represent fixed-point constants. The type of these constants |
| is obtained with @code{TREE_TYPE}. @code{TREE_FIXED_CST_PTR} points to |
| a @code{struct fixed_value}; @code{TREE_FIXED_CST} returns the structure |
| itself. @code{struct fixed_value} contains @code{data} with the size of two |
| @code{HOST_BITS_PER_WIDE_INT} and @code{mode} as the associated fixed-point |
| machine mode for @code{data}. |
| |
| @item COMPLEX_CST |
| These nodes are used to represent complex number constants, that is a |
| @code{__complex__} whose parts are constant nodes. The |
| @code{TREE_REALPART} and @code{TREE_IMAGPART} return the real and the |
| imaginary parts respectively. |
| |
| @item VECTOR_CST |
| These nodes are used to represent vector constants. Each vector |
| constant @var{v} is treated as a specific instance of an arbitrary-length |
| sequence that itself contains @samp{VECTOR_CST_NPATTERNS (@var{v})} |
| interleaved patterns. Each pattern has the form: |
| |
| @smallexample |
| @{ @var{base0}, @var{base1}, @var{base1} + @var{step}, @var{base1} + @var{step} * 2, @dots{} @} |
| @end smallexample |
| |
| The first three elements in each pattern are enough to determine the |
| values of the other elements. However, if all @var{step}s are zero, |
| only the first two elements are needed. If in addition each @var{base1} |
| is equal to the corresponding @var{base0}, only the first element in |
| each pattern is needed. The number of encoded elements per pattern |
| is given by @samp{VECTOR_CST_NELTS_PER_PATTERN (@var{v})}. |
| |
| For example, the constant: |
| |
| @smallexample |
| @{ 0, 1, 2, 6, 3, 8, 4, 10, 5, 12, 6, 14, 7, 16, 8, 18 @} |
| @end smallexample |
| |
| is interpreted as an interleaving of the sequences: |
| |
| @smallexample |
| @{ 0, 2, 3, 4, 5, 6, 7, 8 @} |
| @{ 1, 6, 8, 10, 12, 14, 16, 18 @} |
| @end smallexample |
| |
| where the sequences are represented by the following patterns: |
| |
| @smallexample |
| @var{base0} == 0, @var{base1} == 2, @var{step} == 1 |
| @var{base0} == 1, @var{base1} == 6, @var{step} == 2 |
| @end smallexample |
| |
| In this case: |
| |
| @smallexample |
| VECTOR_CST_NPATTERNS (@var{v}) == 2 |
| VECTOR_CST_NELTS_PER_PATTERN (@var{v}) == 3 |
| @end smallexample |
| |
| The vector is therefore encoded using the first 6 elements |
| (@samp{@{ 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 (@var{base0} and |
| @var{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. |
| |
| @samp{vector_cst_encoding_nelts (@var{v})} gives the total number of |
| encoded elements in @var{v}, which is 6 in the example above. |
| @code{VECTOR_CST_ENCODED_ELTS (@var{v})} gives a pointer to the elements |
| encoded in @var{v} and @code{VECTOR_CST_ENCODED_ELT (@var{v}, @var{i})} |
| accesses the value of encoded element @var{i}. |
| |
| @samp{VECTOR_CST_DUPLICATE_P (@var{v})} is true if @var{v} simply contains |
| repeated instances of @samp{VECTOR_CST_NPATTERNS (@var{v})} values. This is |
| a shorthand for testing @samp{VECTOR_CST_NELTS_PER_PATTERN (@var{v}) == 1}. |
| |
| @samp{VECTOR_CST_STEPPED_P (@var{v})} is true if at least one |
| pattern in @var{v} has a nonzero step. This is a shorthand for |
| testing @samp{VECTOR_CST_NELTS_PER_PATTERN (@var{v}) == 3}. |
| |
| The utility function @code{vector_cst_elt} gives the value of an |
| arbitrary index as a @code{tree}. @code{vector_cst_int_elt} gives |
| the same value as a @code{wide_int}. |
| |
| @item STRING_CST |
| These nodes represent string-constants. The @code{TREE_STRING_LENGTH} |
| returns the length of the string, as an @code{int}. The |
| @code{TREE_STRING_POINTER} is a @code{char*} containing the string |
| itself. The string may not be @code{NUL}-terminated, and it may contain |
| embedded @code{NUL} characters. Therefore, the |
| @code{TREE_STRING_LENGTH} includes the trailing @code{NUL} if it is |
| present. |
| |
| For wide string constants, the @code{TREE_STRING_LENGTH} is the number |
| of bytes in the string, and the @code{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 @code{TREE_TYPE} |
| of the @code{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. |
| |
| @item POLY_INT_CST |
| These nodes represent invariants that depend on some target-specific |
| runtime parameters. They consist of @code{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. |
| |
| @code{POLY_INT_CST_ELT (@var{x}, @var{i})} references coefficient number |
| @var{i} of @code{POLY_INT_CST} node @var{x}. Each coefficient is an |
| @code{INTEGER_CST}. |
| |
| @end table |
| |
| @node Storage References |
| @subsection References to storage |
| @tindex ADDR_EXPR |
| @tindex INDIRECT_REF |
| @tindex MEM_REF |
| @tindex ARRAY_REF |
| @tindex ARRAY_RANGE_REF |
| @tindex TARGET_MEM_REF |
| @tindex COMPONENT_REF |
| |
| @table @code |
| @item 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 @code{array_ref_low_bound} and @code{array_ref_element_size} |
| instead. |
| |
| @item ARRAY_RANGE_REF |
| These nodes represent access to a range (or ``slice'') of an array. The |
| operands are the same as that for @code{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. |
| |
| @item 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 @code{FIELD_DECL} for the data member. The third operand represents |
| the byte offset of the field, but should not be used directly; call |
| @code{component_ref_field_offset} instead. |
| |
| @item 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 @code{ADDR_EXPR} will be a |
| @code{LABEL_DECL}. The type of such an expression is @code{void*}. |
| |
| If the object addressed is not an lvalue, a temporary is created, and |
| the address of the temporary is used. |
| |
| @item 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. |
| |
| @item 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 |
| serving as constant offset applied to the pointer being dereferenced |
| with its type specifying the type to be used for type-based alias analysis. |
| The type of the node specifies the alignment of the access. |
| |
| @item TARGET_MEM_REF |
| These nodes represent memory accesses whose address directly map to |
| an addressing mode of the target architecture. The first argument |
| is @code{TMR_BASE} and is a pointer to the object being accessed. |
| The second argument is @code{TMR_OFFSET} which is a pointer constant |
| with dual purpose serving both as constant offset and holder of |
| the type used for type-based alias analysis. The first two operands |
| have exactly the same semantics as @code{MEM_REF}. The third |
| and fourth operand are @code{TMR_INDEX} and @code{TMR_STEP} where |
| the former is an integer and the latter an integer constant. The |
| fifth and last operand is @code{TMR_INDEX2} which is an alternate |
| non-constant offset. Any of the third to last operands may be |
| @code{NULL} if the corresponding component does not appear in |
| the address, but @code{TMR_INDEX} and @code{TMR_STEP} shall be |
| always supplied in pair. The Address of the @code{TARGET_MEM_REF} |
| is determined in the following way. |
| |
| @smallexample |
| TMR_BASE + TMR_OFFSET + TMR_INDEX * TMR_STEP + TMR_INDEX2 |
| @end smallexample |
| |
| The type of the node specifies the alignment of the access. |
| |
| @end table |
| |
| @node Unary and Binary Expressions |
| @subsection Unary and Binary Expressions |
| @tindex NEGATE_EXPR |
| @tindex ABS_EXPR |
| @tindex ABSU_EXPR |
| @tindex BIT_NOT_EXPR |
| @tindex TRUTH_NOT_EXPR |
| @tindex PREDECREMENT_EXPR |
| @tindex PREINCREMENT_EXPR |
| @tindex POSTDECREMENT_EXPR |
| @tindex POSTINCREMENT_EXPR |
| @tindex FIX_TRUNC_EXPR |
| @tindex FLOAT_EXPR |
| @tindex COMPLEX_EXPR |
| @tindex CONJ_EXPR |
| @tindex REALPART_EXPR |
| @tindex IMAGPART_EXPR |
| @tindex NON_LVALUE_EXPR |
| @tindex NOP_EXPR |
| @tindex CONVERT_EXPR |
| @tindex FIXED_CONVERT_EXPR |
| @tindex THROW_EXPR |
| @tindex LSHIFT_EXPR |
| @tindex RSHIFT_EXPR |
| @tindex BIT_IOR_EXPR |
| @tindex BIT_XOR_EXPR |
| @tindex BIT_AND_EXPR |
| @tindex TRUTH_ANDIF_EXPR |
| @tindex TRUTH_ORIF_EXPR |
| @tindex TRUTH_AND_EXPR |
| @tindex TRUTH_OR_EXPR |
| @tindex TRUTH_XOR_EXPR |
| @tindex POINTER_PLUS_EXPR |
| @tindex POINTER_DIFF_EXPR |
| @tindex PLUS_EXPR |
| @tindex MINUS_EXPR |
| @tindex MULT_EXPR |
| @tindex WIDEN_MULT_EXPR |
| @tindex MULT_HIGHPART_EXPR |
| @tindex RDIV_EXPR |
| @tindex TRUNC_DIV_EXPR |
| @tindex FLOOR_DIV_EXPR |
| @tindex CEIL_DIV_EXPR |
| @tindex ROUND_DIV_EXPR |
| @tindex TRUNC_MOD_EXPR |
| @tindex FLOOR_MOD_EXPR |
| @tindex CEIL_MOD_EXPR |
| @tindex ROUND_MOD_EXPR |
| @tindex EXACT_DIV_EXPR |
| @tindex LT_EXPR |
| @tindex LE_EXPR |
| @tindex GT_EXPR |
| @tindex GE_EXPR |
| @tindex EQ_EXPR |
| @tindex NE_EXPR |
| @tindex ORDERED_EXPR |
| @tindex UNORDERED_EXPR |
| @tindex UNLT_EXPR |
| @tindex UNLE_EXPR |
| @tindex UNGT_EXPR |
| @tindex UNGE_EXPR |
| @tindex UNEQ_EXPR |
| @tindex LTGT_EXPR |
| @tindex MODIFY_EXPR |
| @tindex INIT_EXPR |
| @tindex COMPOUND_EXPR |
| @tindex COND_EXPR |
| @tindex CALL_EXPR |
| @tindex STMT_EXPR |
| @tindex BIND_EXPR |
| @tindex LOOP_EXPR |
| @tindex EXIT_EXPR |
| @tindex CLEANUP_POINT_EXPR |
| @tindex CONSTRUCTOR |
| @tindex COMPOUND_LITERAL_EXPR |
| @tindex SAVE_EXPR |
| @tindex TARGET_EXPR |
| @tindex VA_ARG_EXPR |
| @tindex ANNOTATE_EXPR |
| |
| @table @code |
| @item 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 @code{flag_wrapv} and @code{flag_trapv} variables. |
| |
| @item 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 @code{abs}, @code{labs} and @code{llabs} builtins for |
| integer types, and the @code{fabs}, @code{fabsf} and @code{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 @code{BUILT_IN_CABS}, |
| @code{BUILT_IN_CABSF} or @code{BUILT_IN_CABSL} builtins, as used |
| to implement the C99 @code{cabs}, @code{cabsf} and @code{cabsl} |
| built-in functions. |
| |
| @item ABSU_EXPR |
| These nodes represent the absolute value of the single operand in |
| equivalent unsigned type such that @code{ABSU_EXPR} of @code{TYPE_MIN} |
| is well defined. |
| |
| @item BIT_NOT_EXPR |
| These nodes represent bitwise complement, and will always have integral |
| type. The only operand is the value to be complemented. |
| |
| @item 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 @code{BOOLEAN_TYPE} |
| or @code{INTEGER_TYPE}. |
| |
| @item PREDECREMENT_EXPR |
| @itemx PREINCREMENT_EXPR |
| @itemx POSTDECREMENT_EXPR |
| @itemx 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 @code{PREDECREMENT_EXPR} and |
| @code{PREINCREMENT_EXPR}, the value of the expression is the value |
| resulting after the increment or decrement; in the case of |
| @code{POSTDECREMENT_EXPR} and @code{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. |
| |
| @item 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. |
| |
| @item 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 |
| @option{-mieee}? |
| |
| @item 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. |
| |
| @item CONJ_EXPR |
| These nodes represent the conjugate of their operand. |
| |
| @item REALPART_EXPR |
| @itemx IMAGPART_EXPR |
| These nodes represent respectively the real and the imaginary parts |
| of complex numbers (their sole argument). |
| |
| @item 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. |
| |
| @item NOP_EXPR |
| These nodes are used to represent conversions that do not require any |
| code-generation. For example, conversion of a @code{char*} to an |
| @code{int*} does not require any code be generated; such a conversion is |
| represented by a @code{NOP_EXPR}. The single operand is the expression |
| to be converted. The conversion from a pointer to a reference is also |
| represented with a @code{NOP_EXPR}. |
| |
| @item CONVERT_EXPR |
| These nodes are similar to @code{NOP_EXPR}s, but are used in those |
| situations where code may need to be generated. For example, if an |
| @code{int*} is converted to an @code{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 @code{CONVERT_EXPR}; instead, the |
| function calls are made explicit. |
| |
| @item 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. |
| |
| @item LSHIFT_EXPR |
| @itemx 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. |
| |
| |
| @item BIT_IOR_EXPR |
| @itemx BIT_XOR_EXPR |
| @itemx BIT_AND_EXPR |
| These nodes represent bitwise inclusive or, bitwise exclusive or, and |
| bitwise and, respectively. Both operands will always have integral |
| type. |
| |
| @item TRUTH_ANDIF_EXPR |
| @itemx 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 @code{BOOLEAN_TYPE} or @code{INTEGER_TYPE}. |
| |
| @item TRUTH_AND_EXPR |
| @itemx TRUTH_OR_EXPR |
| @itemx 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 @code{BOOLEAN_TYPE} or @code{INTEGER_TYPE}. |
| |
| @item 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. |
| |
| @item 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. |
| |
| @item PLUS_EXPR |
| @itemx MINUS_EXPR |
| @itemx 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 @code{flag_wrapv} and @code{flag_trapv} variables. |
| |
| @item WIDEN_MULT_EXPR |
| This node represents a widening multiplication. The operands have |
| integral types with same @var{b} bits of precision, producing an |
| integral type result with at least @math{2@var{b}} bits of precision. |
| The behaviour is equivalent to extending both operands, possibly of |
| different signedness, to the result type, then multiplying them. |
| |
| @item MULT_HIGHPART_EXPR |
| This node represents the ``high-part'' of a widening multiplication. |
| For an integral type with @var{b} bits of precision, the result is |
| the most significant @var{b} bits of the full @math{2@var{b}} product. |
| Both operands must have the same precision and same signedness. |
| |
| @item RDIV_EXPR |
| This node represents a floating point division operation. |
| |
| @item TRUNC_DIV_EXPR |
| @itemx FLOOR_DIV_EXPR |
| @itemx CEIL_DIV_EXPR |
| @itemx ROUND_DIV_EXPR |
| These nodes represent integer division operations that return an integer |
| result. @code{TRUNC_DIV_EXPR} rounds towards zero, @code{FLOOR_DIV_EXPR} |
| rounds towards negative infinity, @code{CEIL_DIV_EXPR} rounds towards |
| positive infinity and @code{ROUND_DIV_EXPR} rounds to the closest integer. |
| Integer division in C and C++ is truncating, i.e.@: @code{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 |
| @code{flag_wrapv} and @code{flag_trapv} variables. |
| |
| @item TRUNC_MOD_EXPR |
| @itemx FLOOR_MOD_EXPR |
| @itemx CEIL_MOD_EXPR |
| @itemx ROUND_MOD_EXPR |
| These nodes represent the integer remainder or modulus operation. |
| The integer modulus of two operands @code{a} and @code{b} is |
| defined as @code{a - (a/b)*b} where the division calculated using |
| the corresponding division operator. Hence for @code{TRUNC_MOD_EXPR} |
| this definition assumes division using truncation towards zero, i.e.@: |
| @code{TRUNC_DIV_EXPR}. Integer remainder in C and C++ uses truncating |
| division, i.e.@: @code{TRUNC_MOD_EXPR}. |
| |
| @item EXACT_DIV_EXPR |
| The @code{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 @code{TRUNC_DIV_EXPR}, |
| @code{CEIL_DIV_EXPR} and @code{FLOOR_DIV_EXPR} for the current target. |
| |
| @item LT_EXPR |
| @itemx LE_EXPR |
| @itemx GT_EXPR |
| @itemx GE_EXPR |
| @itemx LTGT_EXPR |
| @itemx EQ_EXPR |
| @itemx NE_EXPR |
| These nodes represent the less than, less than or equal to, greater than, |
| greater than or equal to, less or greater than, 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, except for |
| LTGT_EXPR where they will only be both of floating 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 @code{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. |
| |
| @item ORDERED_EXPR |
| @itemx 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. |
| |
| @item UNLT_EXPR |
| @itemx UNLE_EXPR |
| @itemx UNGT_EXPR |
| @itemx UNGE_EXPR |
| @itemx UNEQ_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, @code{UNLT_EXPR} returns true if either operand is an IEEE |
| NaN or the first operand is less than the second. All 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. |
| |
| @item 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 @code{VAR_DECL}, @code{INDIRECT_REF}, @code{COMPONENT_REF}, or |
| other lvalue. |
| |
| These nodes are used to represent not only assignment with @samp{=} but |
| also compound assignments (like @samp{+=}), by reduction to @samp{=} |
| assignment. In other words, the representation for @samp{i += 3} looks |
| just like that for @samp{i = i + 3}. |
| |
| @item INIT_EXPR |
| These nodes are just like @code{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. |
| |
| @item 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. |
| |
| @item COND_EXPR |
| These nodes represent @code{?:} 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 @code{(i >= 0 && i < 10) ? i : abort()}. |
| |
| As a GNU extension, the C language front-ends allow the second |
| operand of the @code{?:} operator may be omitted in the source. |
| For example, @code{x ? : 3} is equivalent to @code{x ? x : 3}, |
| assuming that @code{x} is an expression without side effects. |
| In the tree representation, however, the second operand is always |
| present, possibly protected by @code{SAVE_EXPR} if the first |
| argument does cause side effects. |
| |
| @item CALL_EXPR |
| These nodes are used to represent calls to functions, including |
| non-static member functions. @code{CALL_EXPR}s are implemented as |
| expression nodes with a variable number of operands. Rather than using |
| @code{TREE_OPERAND} to extract them, it is preferable to use the |
| specialized accessor macros and functions that operate specifically on |
| @code{CALL_EXPR} nodes. |
| |
| @code{CALL_EXPR_FN} returns a pointer to the |
| function to call; it is always an expression whose type is a |
| @code{POINTER_TYPE}. |
| |
| The number of arguments to the call is returned by @code{call_expr_nargs}, |
| while the arguments themselves can be accessed with the @code{CALL_EXPR_ARG} |
| macro. The arguments are zero-indexed and numbered left-to-right. |
| You can iterate over the arguments using @code{FOR_EACH_CALL_EXPR_ARG}, as in: |
| |
| @smallexample |
| tree call, arg; |
| call_expr_arg_iterator iter; |
| FOR_EACH_CALL_EXPR_ARG (arg, iter, call) |
| /* arg is bound to successive arguments of call. */ |
| @dots{}; |
| @end smallexample |
| |
| For non-static |
| member functions, there will be an operand corresponding to the |
| @code{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. |
| |
| @code{CALL_EXPR}s also have a @code{CALL_EXPR_STATIC_CHAIN} operand that |
| is used to implement nested functions. This operand is otherwise null. |
| |
| @item 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. |
| |
| @item 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 (@code{INDEX}, @code{VALUE}) pair. |
| |
| If the @code{TREE_TYPE} of the @code{CONSTRUCTOR} is a @code{RECORD_TYPE}, |
| @code{UNION_TYPE} or @code{QUAL_UNION_TYPE} then the @code{INDEX} of each |
| node in the sequence will be a @code{FIELD_DECL} and the @code{VALUE} will |
| be the expression used to initialize that field. |
| |
| If the @code{TREE_TYPE} of the @code{CONSTRUCTOR} is an @code{ARRAY_TYPE}, |
| then the @code{INDEX} of each node in the sequence will be an |
| @code{INTEGER_CST} or a @code{RANGE_EXPR} of two @code{INTEGER_CST}s. |
| A single @code{INTEGER_CST} indicates which element of the array is being |
| assigned to. A @code{RANGE_EXPR} indicates an inclusive range of elements |
| to initialize. In both cases the @code{VALUE} is the corresponding |
| initializer. It is re-evaluated for each element of a |
| @code{RANGE_EXPR}. If the @code{INDEX} is @code{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. |
| |
| @item COMPOUND_LITERAL_EXPR |
| @findex COMPOUND_LITERAL_EXPR_DECL_EXPR |
| @findex COMPOUND_LITERAL_EXPR_DECL |
| These nodes represent ISO C99 compound literals. The |
| @code{COMPOUND_LITERAL_EXPR_DECL_EXPR} is a @code{DECL_EXPR} |
| containing an anonymous @code{VAR_DECL} for |
| the unnamed object represented by the compound literal; the |
| @code{DECL_INITIAL} of that @code{VAR_DECL} is a @code{CONSTRUCTOR} |
| representing the brace-enclosed list of initializers in the compound |
| literal. That anonymous @code{VAR_DECL} can also be accessed directly |
| by the @code{COMPOUND_LITERAL_EXPR_DECL} macro. |
| |
| @item SAVE_EXPR |
| |
| A @code{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 |
| @code{SAVE_EXPR} is the expression to evaluate. The side effects should |
| be executed where the @code{SAVE_EXPR} is first encountered in a |
| depth-first preorder traversal of the expression tree. |
| |
| @item TARGET_EXPR |
| A @code{TARGET_EXPR} represents a temporary object. The first operand |
| is a @code{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 @code{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 @code{TARGET_EXPR} is ``normal''; otherwise, we say it is |
| ``orphaned''. For a normal @code{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 @code{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 |
| @code{COND_EXPR}), the cleanup must be run only if that branch is |
| actually executed. |
| |
| @item VA_ARG_EXPR |
| This node is used to implement support for the C/C++ variable argument-list |
| mechanism. It represents expressions like @code{va_arg (ap, type)}. |
| Its @code{TREE_TYPE} yields the tree representation for @code{type} and |
| its sole argument yields the representation for @code{ap}. |
| |
| @item ANNOTATE_EXPR |
| This node is used to attach markers to an expression. The first operand |
| is the annotated expression, the second is an @code{INTEGER_CST} with |
| a value from @code{enum annot_expr_kind}, the third is an @code{INTEGER_CST}. |
| @end table |
| |
| |
| @node Vectors |
| @subsection Vectors |
| @tindex VEC_DUPLICATE_EXPR |
| @tindex VEC_SERIES_EXPR |
| @tindex VEC_LSHIFT_EXPR |
| @tindex VEC_RSHIFT_EXPR |
| @tindex VEC_WIDEN_MULT_HI_EXPR |
| @tindex VEC_WIDEN_MULT_LO_EXPR |
| @tindex VEC_WIDEN_PLUS_HI_EXPR |
| @tindex VEC_WIDEN_PLUS_LO_EXPR |
| @tindex VEC_WIDEN_MINUS_HI_EXPR |
| @tindex VEC_WIDEN_MINUS_LO_EXPR |
| @tindex VEC_UNPACK_HI_EXPR |
| @tindex VEC_UNPACK_LO_EXPR |
| @tindex VEC_UNPACK_FLOAT_HI_EXPR |
| @tindex VEC_UNPACK_FLOAT_LO_EXPR |
| @tindex VEC_UNPACK_FIX_TRUNC_HI_EXPR |
| @tindex VEC_UNPACK_FIX_TRUNC_LO_EXPR |
| @tindex VEC_PACK_TRUNC_EXPR |
| @tindex VEC_PACK_SAT_EXPR |
| @tindex VEC_PACK_FIX_TRUNC_EXPR |
| @tindex VEC_PACK_FLOAT_EXPR |
| @tindex VEC_COND_EXPR |
| @tindex SAD_EXPR |
| |
| @table @code |
| @item VEC_DUPLICATE_EXPR |
| This node has a single operand and represents a vector in which every |
| element is equal to that operand. |
| |
| @item VEC_SERIES_EXPR |
| This node represents a vector formed from a scalar base and step, |
| given as the first and second operands respectively. Element @var{i} |
| of the result is equal to @samp{@var{base} + @var{i}*@var{step}}. |
| |
| This node is restricted to integral types, in order to avoid |
| specifying the rounding behavior for floating-point types. |
| |
| @item VEC_LSHIFT_EXPR |
| @itemx 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. |
| |
| @item VEC_WIDEN_MULT_HI_EXPR |
| @itemx 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 (@code{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 @code{VEC_WIDEN_MULT_HI_EXPR} the |
| high @code{N/2} elements of the two vector are multiplied to produce the |
| vector of @code{N/2} products. In the case of @code{VEC_WIDEN_MULT_LO_EXPR} the |
| low @code{N/2} elements of the two vector are multiplied to produce the |
| vector of @code{N/2} products. |
| |
| @item VEC_WIDEN_PLUS_HI_EXPR |
| @itemx VEC_WIDEN_PLUS_LO_EXPR |
| These nodes represent widening vector addition of the high and low parts of |
| the two input vectors, respectively. Their operands are vectors that contain |
| the same number of elements (@code{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 @code{VEC_WIDEN_PLUS_HI_EXPR} the high |
| @code{N/2} elements of the two vectors are added to produce the vector of |
| @code{N/2} products. In the case of @code{VEC_WIDEN_PLUS_LO_EXPR} the low |
| @code{N/2} elements of the two vectors are added to produce the vector of |
| @code{N/2} products. |
| |
| @item VEC_WIDEN_MINUS_HI_EXPR |
| @itemx VEC_WIDEN_MINUS_LO_EXPR |
| These nodes represent widening vector subtraction of the high and low parts of |
| the two input vectors, respectively. Their operands are vectors that contain |
| the same number of elements (@code{N}) of the same integral type. The high/low |
| elements of the second vector are subtracted from the high/low elements of the |
| first. 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 |
| @code{VEC_WIDEN_MINUS_HI_EXPR} the high @code{N/2} elements of the second |
| vector are subtracted from the high @code{N/2} of the first to produce the |
| vector of @code{N/2} products. In the case of |
| @code{VEC_WIDEN_MINUS_LO_EXPR} the low @code{N/2} elements of the second |
| vector are subtracted from the low @code{N/2} of the first to produce the |
| vector of @code{N/2} products. |
| |
| @item VEC_UNPACK_HI_EXPR |
| @itemx 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 @code{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 @code{VEC_UNPACK_HI_EXPR} the |
| high @code{N/2} elements of the vector are extracted and widened (promoted). |
| In the case of @code{VEC_UNPACK_LO_EXPR} the low @code{N/2} elements of the |
| vector are extracted and widened (promoted). |
| |
| @item VEC_UNPACK_FLOAT_HI_EXPR |
| @itemx 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 @code{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 |
| @code{VEC_UNPACK_FLOAT_HI_EXPR} the high @code{N/2} elements of the vector are |
| extracted, converted and widened. In the case of @code{VEC_UNPACK_FLOAT_LO_EXPR} |
| the low @code{N/2} elements of the vector are extracted, converted and widened. |
| |
| @item VEC_UNPACK_FIX_TRUNC_HI_EXPR |
| @itemx 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 @code{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 |
| @code{VEC_UNPACK_FIX_TRUNC_HI_EXPR} the high @code{N/2} elements of the |
| vector are extracted and converted with truncation. In the case of |
| @code{VEC_UNPACK_FIX_TRUNC_LO_EXPR} the low @code{N/2} elements of the |
| vector are extracted and converted with truncation. |
| |
| @item 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. |
| |
| @item 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. |
| |
| @item 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. |
| |
| @item 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. |
| |
| @item VEC_COND_EXPR |
| These nodes represent @code{?:} 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 @code{COND_EXPR}, all operands are always |
| evaluated. |
| |
| @item 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. |
| |
| @end table |
| |
| |
| @c --------------------------------------------------------------------- |
| @c Statements |
| @c --------------------------------------------------------------------- |
| |
| @node Statements |
| @section Statements |
| @cindex Statements |
| |
| Most statements in GIMPLE are assignment statements, represented by |
| @code{GIMPLE_ASSIGN}. No other C expressions can appear at statement level; |
| a reference to a volatile object is converted into a |
| @code{GIMPLE_ASSIGN}. |
| |
| There are also several varieties of complex statements. |
| |
| @menu |
| * Basic Statements:: |
| * Blocks:: |
| * Statement Sequences:: |
| * Empty Statements:: |
| * Jumps:: |
| * Cleanups:: |
| * OpenMP:: |
| * OpenACC:: |
| @end menu |
| |
| @node Basic Statements |
| @subsection Basic Statements |
| @cindex Basic Statements |
| |
| @table @code |
| @item ASM_EXPR |
| |
| Used to represent an inline assembly statement. For an inline assembly |
| statement like: |
| @smallexample |
| asm ("mov x, y"); |
| @end smallexample |
| The @code{ASM_STRING} macro will return a @code{STRING_CST} node for |
| @code{"mov x, y"}. If the original statement made use of the |
| extended-assembly syntax, then @code{ASM_OUTPUTS}, |
| @code{ASM_INPUTS}, and @code{ASM_CLOBBERS} will be the outputs, inputs, |
| and clobbers for the statement, represented as @code{STRING_CST} nodes. |
| The extended-assembly syntax looks like: |
| @smallexample |
| asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); |
| @end smallexample |
| The first string is the @code{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 @code{NUL}-terminated, and will contain no |
| embedded @code{NUL}-characters. |
| |
| If the assembly statement is declared @code{volatile}, or if the |
| statement was not an extended assembly statement, and is therefore |
| implicitly volatile, then the predicate @code{ASM_VOLATILE_P} will hold |
| of the @code{ASM_EXPR}. |
| |
| @item DECL_EXPR |
| |
| Used to represent a local declaration. The @code{DECL_EXPR_DECL} macro |
| can be used to obtain the entity declared. This declaration may be a |
| @code{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 @code{FUNCTION_DECL}, indicating the |
| use of the GCC nested function extension. For more information, |
| @pxref{Functions}. |
| |
| @item LABEL_EXPR |
| |
| Used to represent a label. The @code{LABEL_DECL} declared by this |
| statement can be obtained with the @code{LABEL_EXPR_LABEL} macro. The |
| @code{IDENTIFIER_NODE} giving the name of the label can be obtained from |
| the @code{LABEL_DECL} with @code{DECL_NAME}. |
| |
| @item GOTO_EXPR |
| |
| Used to represent a @code{goto} statement. The @code{GOTO_DESTINATION} will |
| usually be a @code{LABEL_DECL}. However, if the ``computed goto'' extension |
| has been used, the @code{GOTO_DESTINATION} will be an arbitrary expression |
| indicating the destination. This expression will always have pointer type. |
| |
| @item RETURN_EXPR |
| |
| Used to represent a @code{return} statement. Operand 0 represents the |
| value to return. It should either be the @code{RESULT_DECL} for the |
| containing function, or a @code{MODIFY_EXPR} or @code{INIT_EXPR} |
| setting the function's @code{RESULT_DECL}. It will be |
| @code{NULL_TREE} if the statement was just |
| @smallexample |
| return; |
| @end smallexample |
| |
| @item LOOP_EXPR |
| These nodes represent ``infinite'' loops. The @code{LOOP_EXPR_BODY} |
| represents the body of the loop. It should be executed forever, unless |
| an @code{EXIT_EXPR} is encountered. |
| |
| @item EXIT_EXPR |
| These nodes represent conditional exits from the nearest enclosing |
| @code{LOOP_EXPR}. The single operand is the condition; if it is |
| nonzero, then the loop should be exited. An @code{EXIT_EXPR} will only |
| appear within a @code{LOOP_EXPR}. |
| |
| @item SWITCH_EXPR |
| |
| Used to represent a @code{switch} statement. The @code{SWITCH_COND} |
| is the expression on which the switch is occurring. The |
| @code{SWITCH_BODY} is the body of the switch statement. |
| @code{SWITCH_ALL_CASES_P} is true if the switch includes a default |
| label or the case label ranges cover all possible values of the |
| condition expression. |
| |
| Note that @code{TREE_TYPE} for a @code{SWITCH_EXPR} represents the |
| original type of switch expression as given in the source, before any |
| compiler conversions, instead of the type of the switch expression |
| itself (which is not meaningful). |
| |
| @item CASE_LABEL_EXPR |
| |
| Use to represent a @code{case} label, range of @code{case} labels, or a |
| @code{default} label. If @code{CASE_LOW} is @code{NULL_TREE}, then this is a |
| @code{default} label. Otherwise, if @code{CASE_HIGH} is @code{NULL_TREE}, then |
| this is an ordinary @code{case} label. In this case, @code{CASE_LOW} is |
| an expression giving the value of the label. Both @code{CASE_LOW} and |
| @code{CASE_HIGH} are @code{INTEGER_CST} nodes. These values will have |
| the same type as the condition expression in the switch statement. |
| |
| Otherwise, if both @code{CASE_LOW} and @code{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: |
| @smallexample |
| case 2 ... 5: |
| @end smallexample |
| The first value will be @code{CASE_LOW}, while the second will be |
| @code{CASE_HIGH}. |
| |
| @item DEBUG_BEGIN_STMT |
| |
| Marks the beginning of a source statement, for purposes of debug |
| information generation. |
| |
| @end table |
| |
| |
| @node Blocks |
| @subsection Blocks |
| @cindex Blocks |
| |
| Block scopes and the variables they declare in GENERIC are |
| expressed using the @code{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 @code{BIND_EXPR_VARS} in |
| declaration order through their @code{TREE_CHAIN} field. Any runtime |
| initialization is moved out of @code{DECL_INITIAL} and into a |
| statement in the controlled block. When gimplifying from C or C++, |
| this initialization replaces the @code{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 @code{alloca}. In most cases, we also arrange |
| for this space to be reclaimed when the enclosing @code{BIND_EXPR} is |
| exited, the exception to this being when there is an explicit call to |
| @code{alloca} in the source code, in which case the stack is left |
| depressed on exit of the @code{BIND_EXPR}. |
| |
| A C++ program will usually contain more @code{BIND_EXPR}s than |
| there are syntactic blocks in the source code, since several C++ |
| constructs have implicit scopes associated with them. On the |
| other hand, although the C++ front end uses pseudo-scopes to |
| handle cleanups for objects with destructors, these don't |
| translate into the GIMPLE form; multiple declarations at the same |
| level use the same @code{BIND_EXPR}. |
| |
| @node Statement Sequences |
| @subsection Statement Sequences |
| @cindex Statement Sequences |
| |
| Multiple statements at the same nesting level are collected into |
| a @code{STATEMENT_LIST}. Statement lists are modified and |
| traversed using the interface in @samp{tree-iterator.h}. |
| |
| @node Empty Statements |
| @subsection Empty Statements |
| @cindex 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 @code{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 @code{(void)0}. |
| |
| @node Jumps |
| @subsection Jumps |
| @cindex Jumps |
| |
| Other jumps are expressed by either @code{GOTO_EXPR} or |
| @code{RETURN_EXPR}. |
| |
| The operand of a @code{GOTO_EXPR} must be either a label or a |
| variable containing the address to jump to. |
| |
| The operand of a @code{RETURN_EXPR} is either @code{NULL_TREE}, |
| @code{RESULT_DECL}, or a @code{MODIFY_EXPR} which sets the return |
| value. It would be nice to move the @code{MODIFY_EXPR} into a |
| separate statement, but the special return semantics in |
| @code{expand_return} make that difficult. It may still happen in |
| the future, perhaps by moving most of that logic into |
| @code{expand_assignment}. |
| |
| @node Cleanups |
| @subsection Cleanups |
| @cindex Cleanups |
| |
| Destructors for local C++ objects and similar dynamic cleanups are |
| represented in GIMPLE by a @code{TRY_FINALLY_EXPR}. |
| @code{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: |
| |
| @enumerate |
| |
| @item Execute the last statement in the sequence and fall off the |
| end. |
| |
| @item Execute a goto statement (@code{GOTO_EXPR}) to an ordinary |
| label outside the sequence. |
| |
| @item Execute a return statement (@code{RETURN_EXPR}). |
| |
| @item Throw an exception. This is currently not explicitly represented in |
| GIMPLE. |
| |
| @end enumerate |
| |
| The second sequence is not executed if the first sequence completes by |
| calling @code{setjmp} or @code{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. |
| |
| If the second sequence is an @code{EH_ELSE_EXPR} selector, then the |
| sequence in its first operand is used when the first sequence completes |
| normally, and that in its second operand is used for exceptional |
| cleanups, i.e., when an exception propagates out of the first sequence. |
| |
| @code{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 @code{RESX_EXPR}. |
| |
| @node OpenMP |
| @subsection OpenMP |
| @tindex OMP_PARALLEL |
| @tindex OMP_FOR |
| @tindex OMP_SECTIONS |
| @tindex OMP_SINGLE |
| @tindex OMP_SECTION |
| @tindex OMP_MASTER |
| @tindex OMP_ORDERED |
| @tindex OMP_CRITICAL |
| @tindex OMP_RETURN |
| @tindex OMP_CONTINUE |
| @tindex OMP_ATOMIC |
| @tindex OMP_CLAUSE |
| |
| All the statements starting with @code{OMP_} represent directives and |
| clauses used by the OpenMP API @w{@uref{https://www.openmp.org}}. |
| |
| @table @code |
| @item OMP_PARALLEL |
| |
| Represents @code{#pragma omp parallel [clause1 @dots{} clauseN]}. It |
| has four operands: |
| |
| Operand @code{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 |
| @code{NULL} and the body is emitted linearly after |
| @code{OMP_PARALLEL}. |
| |
| Operand @code{OMP_PARALLEL_CLAUSES} is the list of clauses |
| associated with the directive. |
| |
| Operand @code{OMP_PARALLEL_FN} is created by |
| @code{pass_lower_omp}, it contains the @code{FUNCTION_DECL} |
| for the function that will contain the body of the parallel |
| region. |
| |
| Operand @code{OMP_PARALLEL_DATA_ARG} is also created by |
| @code{pass_lower_omp}. If there are shared variables to be |
| communicated to the children threads, this operand will contain |
| the @code{VAR_DECL} that contains all the shared values and |
| variables. |
| |
| @item OMP_FOR |
| |
| Represents @code{#pragma omp for [clause1 @dots{} clauseN]}. It has |
| six operands: |
| |
| Operand @code{OMP_FOR_BODY} contains the loop body. |
| |
| Operand @code{OMP_FOR_CLAUSES} is the list of clauses |
| associated with the directive. |
| |
| Operand @code{OMP_FOR_INIT} is the loop initialization code of |
| the form @code{VAR = N1}. |
| |
| Operand @code{OMP_FOR_COND} is the loop conditional expression |
| of the form @code{VAR @{<,>,<=,>=@} N2}. |
| |
| Operand @code{OMP_FOR_INCR} is the loop index increment of the |
| form @code{VAR @{+=,-=@} INCR}. |
| |
| Operand @code{OMP_FOR_PRE_BODY} contains side effect code from |
| operands @code{OMP_FOR_INIT}, @code{OMP_FOR_COND} and |
| @code{OMP_FOR_INC}. These side effects are part of the |
| @code{OMP_FOR} block but must be evaluated before the start of |
| loop body. |
| |
| The loop index variable @code{VAR} must be a signed integer variable, |
| which is implicitly private to each thread. Bounds |
| @code{N1} and @code{N2} and the increment expression |
| @code{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. |
| |
| @item OMP_SECTIONS |
| |
| Represents @code{#pragma omp sections [clause1 @dots{} clauseN]}. |
| |
| Operand @code{OMP_SECTIONS_BODY} contains the sections body, |
| which in turn contains a set of @code{OMP_SECTION} nodes for |
| each of the concurrent sections delimited by @code{#pragma omp |
| section}. |
| |
| Operand @code{OMP_SECTIONS_CLAUSES} is the list of clauses |
| associated with the directive. |
| |
| @item OMP_SECTION |
| |
| Section delimiter for @code{OMP_SECTIONS}. |
| |
| @item OMP_SINGLE |
| |
| Represents @code{#pragma omp single}. |
| |
| Operand @code{OMP_SINGLE_BODY} contains the body of code to be |
| executed by a single thread. |
| |
| Operand @code{OMP_SINGLE_CLAUSES} is the list of clauses |
| associated with the directive. |
| |
| @item OMP_MASTER |
| |
| Represents @code{#pragma omp master}. |
| |
| Operand @code{OMP_MASTER_BODY} contains the body of code to be |
| executed by the master thread. |
| |
| @item OMP_ORDERED |
| |
| Represents @code{#pragma omp ordered}. |
| |
| Operand @code{OMP_ORDERED_BODY} contains the body of code to be |
| executed in the sequential order dictated by the loop index |
| variable. |
| |
| @item OMP_CRITICAL |
| |
| Represents @code{#pragma omp critical [name]}. |
| |
| Operand @code{OMP_CRITICAL_BODY} is the critical section. |
| |
| Operand @code{OMP_CRITICAL_NAME} is an optional identifier to |
| label the critical section. |
| |
| @item 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 (@code{tree-cfg.cc}) and OpenMP region |
| building code (@code{omp-low.cc}). |
| |
| @item OMP_CONTINUE |
| |
| Similarly, this instruction does not represent an OpenMP |
| directive, it is used by @code{OMP_FOR} (and similar codes) as well as |
| @code{OMP_SECTIONS} to mark the place where the code needs to |
| loop to the next iteration, or the next section, respectively. |
| |
| In some cases, @code{OMP_CONTINUE} is placed right before |
| @code{OMP_RETURN}. But if there are cleanups that need to |
| occur right after the looping body, it will be emitted between |
| @code{OMP_CONTINUE} and @code{OMP_RETURN}. |
| |
| @item OMP_ATOMIC |
| |
| Represents @code{#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. |
| |
| @item OMP_CLAUSE |
| |
| Represents clauses associated with one of the @code{OMP_} directives. |
| Clauses are represented by separate subcodes defined in |
| @file{tree.h}. Clauses codes can be one of: |
| @code{OMP_CLAUSE_PRIVATE}, @code{OMP_CLAUSE_SHARED}, |
| @code{OMP_CLAUSE_FIRSTPRIVATE}, |
| @code{OMP_CLAUSE_LASTPRIVATE}, @code{OMP_CLAUSE_COPYIN}, |
| @code{OMP_CLAUSE_COPYPRIVATE}, @code{OMP_CLAUSE_IF}, |
| @code{OMP_CLAUSE_NUM_THREADS}, @code{OMP_CLAUSE_SCHEDULE}, |
| @code{OMP_CLAUSE_NOWAIT}, @code{OMP_CLAUSE_ORDERED}, |
| @code{OMP_CLAUSE_DEFAULT}, @code{OMP_CLAUSE_REDUCTION}, |
| @code{OMP_CLAUSE_COLLAPSE}, @code{OMP_CLAUSE_UNTIED}, |
| @code{OMP_CLAUSE_FINAL}, and @code{OMP_CLAUSE_MERGEABLE}. Each code |
| represents the corresponding OpenMP clause. |
| |
| Clauses associated with the same directive are chained together |
| via @code{OMP_CLAUSE_CHAIN}. Those clauses that accept a list |
| of variables are restricted to exactly one, accessed with |
| @code{OMP_CLAUSE_VAR}. Therefore, multiple variables under the |
| same clause @code{C} need to be represented as multiple @code{C} clauses |
| chained together. This facilitates adding new clauses during |
| compilation. |
| |
| @end table |
| |
| @node OpenACC |
| @subsection OpenACC |
| @tindex OACC_CACHE |
| @tindex OACC_DATA |
| @tindex OACC_DECLARE |
| @tindex OACC_ENTER_DATA |
| @tindex OACC_EXIT_DATA |
| @tindex OACC_HOST_DATA |
| @tindex OACC_KERNELS |
| @tindex OACC_LOOP |
| @tindex OACC_PARALLEL |
| @tindex OACC_SERIAL |
| @tindex OACC_UPDATE |
| |
| All the statements starting with @code{OACC_} represent directives and |
| clauses used by the OpenACC API @w{@uref{https://www.openacc.org}}. |
| |
| @table @code |
| @item OACC_CACHE |
| |
| Represents @code{#pragma acc cache (var @dots{})}. |
| |
| @item OACC_DATA |
| |
| Represents @code{#pragma acc data [clause1 @dots{} clauseN]}. |
| |
| @item OACC_DECLARE |
| |
| Represents @code{#pragma acc declare [clause1 @dots{} clauseN]}. |
| |
| @item OACC_ENTER_DATA |
| |
| Represents @code{#pragma acc enter data [clause1 @dots{} clauseN]}. |
| |
| @item OACC_EXIT_DATA |
| |
| Represents @code{#pragma acc exit data [clause1 @dots{} clauseN]}. |
| |
| @item OACC_HOST_DATA |
| |
| Represents @code{#pragma acc host_data [clause1 @dots{} clauseN]}. |
| |
| @item OACC_KERNELS |
| |
| Represents @code{#pragma acc kernels [clause1 @dots{} clauseN]}. |
| |
| @item OACC_LOOP |
| |
| Represents @code{#pragma acc loop [clause1 @dots{} clauseN]}. |
| |
| See the description of the @code{OMP_FOR} code. |
| |
| @item OACC_PARALLEL |
| |
| Represents @code{#pragma acc parallel [clause1 @dots{} clauseN]}. |
| |
| @item OACC_SERIAL |
| |
| Represents @code{#pragma acc serial [clause1 @dots{} clauseN]}. |
| |
| @item OACC_UPDATE |
| |
| Represents @code{#pragma acc update [clause1 @dots{} clauseN]}. |
| |
| @end table |
| |
| @c --------------------------------------------------------------------- |
| @c Functions |
| @c --------------------------------------------------------------------- |
| |
| @node Functions |
| @section Functions |
| @cindex function |
| @tindex FUNCTION_DECL |
| |
| A function is represented by a @code{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. |
| |
| @menu |
| * Function Basics:: Function names, body, and parameters. |
| * Function Properties:: Context, linkage, etc. |
| @end menu |
| |
| @c --------------------------------------------------------------------- |
| @c Function Basics |
| @c --------------------------------------------------------------------- |
| |
| @node Function Basics |
| @subsection Function Basics |
| @findex DECL_NAME |
| @findex DECL_ASSEMBLER_NAME |
| @findex TREE_PUBLIC |
| @findex DECL_ARTIFICIAL |
| @findex DECL_FUNCTION_SPECIFIC_TARGET |
| @findex DECL_FUNCTION_SPECIFIC_OPTIMIZATION |
| |
| 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 @code{FUNCTION_DECL} as well as other basic features: |
| @ftable @code |
| @item DECL_NAME |
| This macro returns the unqualified name of the function, as an |
| @code{IDENTIFIER_NODE}. For an instantiation of a function template, |
| the @code{DECL_NAME} is the unqualified name of the template, not |
| something like @code{f<int>}. The value of @code{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. |
| |
| @item DECL_ASSEMBLER_NAME |
| This macro returns the mangled name of the function, also an |
| @code{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 |
| @code{DECL_ASSEMBLER_NAME} itself.) |
| |
| Using @code{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. |
| |
| @item DECL_ARGUMENTS |
| This macro returns the @code{PARM_DECL} for the first argument to the |
| function. Subsequent @code{PARM_DECL} nodes can be obtained by |
| following the @code{TREE_CHAIN} links. |
| |
| @item DECL_RESULT |
| This macro returns the @code{RESULT_DECL} for the function. |
| |
| @item DECL_SAVED_TREE |
| This macro returns the complete body of the function. |
| |
| @item TREE_TYPE |
| This macro returns the @code{FUNCTION_TYPE} or @code{METHOD_TYPE} for |
| the function. |
| |
| @item DECL_INITIAL |
| A function that has a definition in the current translation unit will |
| have a non-@code{NULL} @code{DECL_INITIAL}. However, back ends should not make |
| use of the particular value given by @code{DECL_INITIAL}. |
| |
| It should contain a tree of @code{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 @code{BLOCK} or |
| @code{FUNCTION_DECL}. So given a function as follows: |
| |
| @smallexample |
| void foo() |
| @{ |
| int a; |
| @{ |
| int b; |
| @} |
| int c; |
| @} |
| @end smallexample |
| |
| you would get the following: |
| |
| @smallexample |
| 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; |
| @end smallexample |
| |
| @end ftable |
| |
| @c --------------------------------------------------------------------- |
| @c Function Properties |
| @c --------------------------------------------------------------------- |
| |
| @node Function Properties |
| @subsection Function Properties |
| @cindex function properties |
| @cindex statements |
| |
| To determine the scope of a function, you can use the |
| @code{DECL_CONTEXT} macro. This macro will return the class |
| (either a @code{RECORD_TYPE} or a @code{UNION_TYPE}) or namespace (a |
| @code{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 @code{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 @code{DECL_CONTEXT} for the |
| referenced @code{VAR_DECL}. If the @code{DECL_CONTEXT} for the |
| referenced @code{VAR_DECL} is not the same as the function currently |
| being processed, and neither @code{DECL_EXTERNAL} nor |
| @code{TREE_STATIC} hold, then the reference is to a local variable in |
| a containing function, and the back end must take appropriate action. |
| |
| @ftable @code |
| @item DECL_EXTERNAL |
| This predicate holds if the function is undefined. |
| |
| @item TREE_PUBLIC |
| This predicate holds if the function has external linkage. |
| |
| @item TREE_STATIC |
| This predicate holds if the function has been defined. |
| |
| @item TREE_THIS_VOLATILE |
| This predicate holds if the function does not return normally. |
| |
| @item TREE_READONLY |
| This predicate holds if the function can only read its arguments. |
| |
| @item DECL_PURE_P |
| This predicate holds if the function can only read its arguments, but |
| may also read global memory. |
| |
| @item DECL_VIRTUAL_P |
| This predicate holds if the function is virtual. |
| |
| @item 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. |
| |
| @item 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 @code{NULL_TREE} if |
| the function is to be compiled with the target options specified on |
| the command line. |
| |
| @item 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 |
| @code{NULL_TREE} if the function is to be compiled with the |
| optimization options specified on the command line. |
| |
| @end ftable |
| |
| @c --------------------------------------------------------------------- |
| @c Language-dependent trees |
| @c --------------------------------------------------------------------- |
| |
| @node Language-dependent trees |
| @section Language-dependent trees |
| @cindex 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 |
| @code{TREE_LANG_FLAG_n} where @samp{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@. |
| |
| |
| |
| @node C and C++ Trees |
| @section 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 @email{gcc@@gcc.gnu.org}) about |
| documenting the functionality you require. Similarly, if you find |
| yourself writing functions that do not deal directly with your back end, |
| but instead might be useful to other people using the GCC front end, you |
| should submit your patches for inclusion in GCC@. |
| |
| @menu |
| * Types for C++:: Fundamental and aggregate types. |
| * Namespaces:: Namespaces. |
| * Classes:: Classes. |
| * Functions for C++:: Overloading and accessors for C++. |
| * Statements for C and C++:: Statements specific to C and C++. |
| * C++ Expressions:: From @code{typeid} to @code{throw}. |
| @end menu |
| |
| @node Types for C++ |
| @subsection Types for C++ |
| @tindex UNKNOWN_TYPE |
| @tindex TYPENAME_TYPE |
| @tindex TYPEOF_TYPE |
| @findex cp_type_quals |
| @findex TYPE_UNQUALIFIED |
| @findex TYPE_QUAL_CONST |
| @findex TYPE_QUAL_VOLATILE |
| @findex TYPE_QUAL_RESTRICT |
| @findex TYPE_MAIN_VARIANT |
| @cindex qualified type |
| @findex TYPE_SIZE |
| @findex TYPE_ALIGN |
| @findex TYPE_PRECISION |
| @findex TYPE_ARG_TYPES |
| @findex TYPE_METHOD_BASETYPE |
| @findex TYPE_PTRDATAMEM_P |
| @findex TYPE_OFFSET_BASETYPE |
| @findex TREE_TYPE |
| @findex TYPE_CONTEXT |
| @findex TYPE_NAME |
| @findex TYPENAME_TYPE_FULLNAME |
| @findex TYPE_FIELDS |
| @findex TYPE_PTROBV_P |
| |
| 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, @code{CP_TYPE_CONST_P} will hold of |
| the type @code{const int ()[7]}, denoting an array of seven @code{int}s. |
| |
| The following functions and macros deal with cv-qualification of types: |
| @ftable @code |
| @item cp_type_quals |
| This function returns the set of type qualifiers applied to this type. |
| This value is @code{TYPE_UNQUALIFIED} if no qualifiers have been |
| applied. The @code{TYPE_QUAL_CONST} bit is set if the type is |
| @code{const}-qualified. The @code{TYPE_QUAL_VOLATILE} bit is set if the |
| type is @code{volatile}-qualified. The @code{TYPE_QUAL_RESTRICT} bit is |
| set if the type is @code{restrict}-qualified. |
| |
| @item CP_TYPE_CONST_P |
| This macro holds if the type is @code{const}-qualified. |
| |
| @item CP_TYPE_VOLATILE_P |
| This macro holds if the type is @code{volatile}-qualified. |
| |
| @item CP_TYPE_RESTRICT_P |
| This macro holds if the type is @code{restrict}-qualified. |
| |
| @item CP_TYPE_CONST_NON_VOLATILE_P |
| This predicate holds for a type that is @code{const}-qualified, but |
| @emph{not} @code{volatile}-qualified; other cv-qualifiers are ignored as |
| well: only the @code{const}-ness is tested. |
| |
| @end ftable |
| |
| A few other macros and functions are usable with all types: |
| @ftable @code |
| @item TYPE_SIZE |
| The number of bits required to represent the type, represented as an |
| @code{INTEGER_CST}. For an incomplete type, @code{TYPE_SIZE} will be |
| @code{NULL_TREE}. |
| |
| @item TYPE_ALIGN |
| The alignment of the type, in bits, represented as an @code{int}. |
| |
| @item TYPE_NAME |
| This macro returns a declaration (in the form of a @code{TYPE_DECL}) for |
| the type. (Note this macro does @emph{not} return an |
| @code{IDENTIFIER_NODE}, as you might expect, given its name!) You can |
| look at the @code{DECL_NAME} of the @code{TYPE_DECL} to obtain the |
| actual name of the type. The @code{TYPE_NAME} will be @code{NULL_TREE} |
| for a type that is not a built-in type, the result of a typedef, or a |
| named class type. |
| |
| @item CP_INTEGRAL_TYPE |
| This predicate holds if the type is an integral type. Notice that in |
| C++, enumerations are @emph{not} integral types. |
| |
| @item ARITHMETIC_TYPE_P |
| This predicate holds if the type is an integral type (in the C++ sense) |
| or a floating point type. |
| |
| @item CLASS_TYPE_P |
| This predicate holds for a class-type. |
| |
| @item TYPE_BUILT_IN |
| This predicate holds for a built-in type. |
| |
| @item TYPE_PTRDATAMEM_P |
| This predicate holds if the type is a pointer to data member. |
| |
| @item TYPE_PTR_P |
| This predicate holds if the type is a pointer type, and the pointee is |
| not a data member. |
| |
| @item TYPE_PTRFN_P |
| This predicate holds for a pointer to function type. |
| |
| @item 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 @code{void *}. You |
| may use @code{TYPE_PTROBV_P} to test for a pointer to object type as |
| well as @code{void *}. |
| |
| @end ftable |
| |
| The table below describes types specific to C and C++ as well as |
| language-dependent info about GENERIC types. |
| |
| @table @code |
| |
| @item POINTER_TYPE |
| Used to represent pointer types, and pointer to data member types. If |
| @code{TREE_TYPE} |
| is a pointer to data member type, then @code{TYPE_PTRDATAMEM_P} will hold. |
| For a pointer to data member type of the form @samp{T X::*}, |
| @code{TYPE_PTRMEM_CLASS_TYPE} will be the type @code{X}, while |
| @code{TYPE_PTRMEM_POINTED_TO_TYPE} will be the type @code{T}. |
| |
| @item RECORD_TYPE |
| Used to represent @code{struct} and @code{class} types in C and C++. If |
| @code{TYPE_PTRMEMFUNC_P} holds, then this type is a pointer-to-member |
| type. In that case, the @code{TYPE_PTRMEMFUNC_FN_TYPE} is a |
| @code{POINTER_TYPE} pointing to a @code{METHOD_TYPE}. The |
| @code{METHOD_TYPE} is the type of a function pointed to by the |
| pointer-to-member function. If @code{TYPE_PTRMEMFUNC_P} does not hold, |
| this type is a class type. For more information, @pxref{Classes}. |
| |
| @item UNKNOWN_TYPE |
| This node is used to represent a type the knowledge of which is |
| insufficient for a sound processing. |
| |
| @item TYPENAME_TYPE |
| Used to represent a construct of the form @code{typename T::A}. The |
| @code{TYPE_CONTEXT} is @code{T}; the @code{TYPE_NAME} is an |
| @code{IDENTIFIER_NODE} for @code{A}. If the type is specified via a |
| template-id, then @code{TYPENAME_TYPE_FULLNAME} yields a |
| @code{TEMPLATE_ID_EXPR}. The @code{TREE_TYPE} is non-@code{NULL} if the |
| node is implicitly generated in support for the implicit typename |
| extension; in which case the @code{TREE_TYPE} is a type node for the |
| base-class. |
| |
| @item TYPEOF_TYPE |
| Used to represent the @code{__typeof__} extension. The |
| @code{TYPE_FIELDS} is the expression the type of which is being |
| represented. |
| |
| @end table |
| |
| |
| @c --------------------------------------------------------------------- |
| @c Namespaces |
| @c --------------------------------------------------------------------- |
| |
| @node Namespaces |
| @subsection Namespaces |
| @cindex namespace, scope |
| @tindex NAMESPACE_DECL |
| |
| The root of the entire intermediate representation is the variable |
| @code{global_namespace}. This is the namespace specified with @code{::} |
| 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 @code{NAMESPACE_DECL} node. |
| |
| The following macros and functions can be used on a @code{NAMESPACE_DECL}: |
| |
| @ftable @code |
| @item DECL_NAME |
| This macro is used to obtain the @code{IDENTIFIER_NODE} corresponding to |
| the unqualified name of the name of the namespace (@pxref{Identifiers}). |
| The name of the global namespace is @samp{::}, even though in C++ the |
| global namespace is unnamed. However, you should use comparison with |
| @code{global_namespace}, rather than @code{DECL_NAME} to determine |
| whether or not a namespace is the global one. An unnamed namespace |
| will have a @code{DECL_NAME} equal to @code{anonymous_namespace_name}. |
| Within a single translation unit, all unnamed namespaces will have the |
| same name. |
| |
| @item DECL_CONTEXT |
| This macro returns the enclosing namespace. The @code{DECL_CONTEXT} for |
| the @code{global_namespace} is @code{NULL_TREE}. |
| |
| @item DECL_NAMESPACE_ALIAS |
| If this declaration is for a namespace alias, then |
| @code{DECL_NAMESPACE_ALIAS} is the namespace for which this one is an |
| alias. |
| |
| Do not attempt to use @code{cp_namespace_decls} for a namespace which is |
| an alias. Instead, follow @code{DECL_NAMESPACE_ALIAS} links until you |
| reach an ordinary, non-alias, namespace, and call |
| @code{cp_namespace_decls} there. |
| |
| @item DECL_NAMESPACE_STD_P |
| This predicate holds if the namespace is the special @code{::std} |
| namespace. |
| |
| @item 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 |
| @code{NULL_TREE}. The declarations are connected through their |
| @code{TREE_CHAIN} fields. |
| |
| Although most entries on this list will be declarations, |
| @code{TREE_LIST} nodes may also appear. In this case, the |
| @code{TREE_VALUE} will be an @code{OVERLOAD}. The value of the |
| @code{TREE_PURPOSE} is unspecified; back ends should ignore this value. |
| As with the other kinds of declarations returned by |
| @code{cp_namespace_decls}, the @code{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, @xref{Declarations}. Some declarations will not appear on this |
| list. In particular, no @code{FIELD_DECL}, @code{LABEL_DECL}, or |
| @code{PARM_DECL} nodes will appear here. |
| |
| This function cannot be used with namespaces that have |
| @code{DECL_NAMESPACE_ALIAS} set. |
| |
| @end ftable |
| |
| @c --------------------------------------------------------------------- |
| @c Classes |
| @c --------------------------------------------------------------------- |
| |
| @node Classes |
| @subsection Classes |
| @cindex class, scope |
| @tindex RECORD_TYPE |
| @tindex UNION_TYPE |
| @findex CLASSTYPE_DECLARED_CLASS |
| @findex TYPE_BINFO |
| @findex BINFO_TYPE |
| @findex TYPE_FIELDS |
| @findex TYPE_VFIELD |
| |
| Besides namespaces, the other high-level scoping construct in C++ is the |
| class. (Throughout this manual the term @dfn{class} is used to mean the |
| types referred to in the ANSI/ISO C++ Standard as classes; these include |
| types defined with the @code{class}, @code{struct}, and @code{union} |
| keywords.) |
| |
| A class type is represented by either a @code{RECORD_TYPE} or a |
| @code{UNION_TYPE}. A class declared with the @code{union} tag is |
| represented by a @code{UNION_TYPE}, while classes declared with either |
| the @code{struct} or the @code{class} tag are represented by |
| @code{RECORD_TYPE}s. You can use the @code{CLASSTYPE_DECLARED_CLASS} |
| macro to discern whether or not a particular type is a @code{class} as |
| opposed to a @code{struct}. This macro will be true only for classes |
| declared with the @code{class} tag. |
| |
| Almost all members are available on the @code{TYPE_FIELDS} |
| list. Given one member, the next can be found by following the |
| @code{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 |
| @samp{DECL} nodes. A @code{FIELD_DECL} is used to represent a non-static |
| data member, a @code{VAR_DECL} is used to represent a static data |
| member, and a @code{TYPE_DECL} is used to represent a type. Note that |
| the @code{CONST_DECL} for an enumeration constant will appear on this |
| list, if the enumeration type was declared in the class. (Of course, |
| the @code{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 @code{FIELD_DECL} for the ``base-class portion'' of an |
| object. If a function member is overloaded, each of the overloaded |
| functions appears; no @code{OVERLOAD} nodes appear on the @code{TYPE_FIELDS} |
| list. Implicitly declared functions (including default constructors, |
| copy constructors, assignment operators, and destructors) will appear on |
| this list as well. |
| |
| The @code{TYPE_VFIELD} is a compiler-generated field used to point to |
| virtual function tables. It may or may not appear on the |
| @code{TYPE_FIELDS} list. However, back ends should handle the |
| @code{TYPE_VFIELD} just like all the entries on the @code{TYPE_FIELDS} |
| list. |
| |
| Every class has an associated @dfn{binfo}, which can be obtained with |
| @code{TYPE_BINFO}. Binfos are used to represent base-classes. The |
| binfo given by @code{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 |
| @code{BINFO_N_BASE_BINFOS}. The base binfos themselves are obtained |
| with @code{BINFO_BASE_BINFO} and @code{BINFO_BASE_ITERATE}. To add a |
| new binfo, use @code{BINFO_BASE_APPEND}. The vector of base binfos can |
| be obtained with @code{BINFO_BASE_BINFOS}, but normally you do not need |
| to use that. The class type associated with a binfo is given by |
| @code{BINFO_TYPE}. It is not always the case that @code{BINFO_TYPE |
| (TYPE_BINFO (x))}, because of typedefs and qualified types. Neither is |
| it the case that @code{TYPE_BINFO (BINFO_TYPE (y))} is the same binfo as |
| @code{y}. The reason is that if @code{y} is a binfo representing a |
| base-class @code{B} of a derived class @code{D}, then @code{BINFO_TYPE |
| (y)} will be @code{B}, and @code{TYPE_BINFO (BINFO_TYPE (y))} will be |
| @code{B} as its own base-class, rather than as a base-class of @code{D}. |
| |
| The access to a base type can be found with @code{BINFO_BASE_ACCESS}. |
| This will produce @code{access_public_node}, @code{access_private_node} |
| or @code{access_protected_node}. If bases are always public, |
| @code{BINFO_BASE_ACCESSES} may be @code{NULL}. |
| |
| @code{BINFO_VIRTUAL_P} is used to specify whether the binfo is inherited |
| virtually or not. The other flags, @code{BINFO_FLAG_0} to |
| @code{BINFO_FLAG_6}, can be used for language specific use. |
| |
| The following macros can be used on a tree node representing a class-type. |
| |
| @ftable @code |
| @item LOCAL_CLASS_P |
| This predicate holds if the class is local class @emph{i.e.}@: declared |
| inside a function body. |
| |
| @item TYPE_POLYMORPHIC_P |
| This predicate holds if the class has at least one virtual function |
| (declared or inherited). |
| |
| @item TYPE_HAS_DEFAULT_CONSTRUCTOR |
| This predicate holds whenever its argument represents a class-type with |
| default constructor. |
| |
| @item CLASSTYPE_HAS_MUTABLE |
| @itemx TYPE_HAS_MUTABLE_P |
| These predicates hold for a class-type having a mutable data member. |
| |
| @item CLASSTYPE_NON_POD_P |
| This predicate holds only for class-types that are not PODs. |
| |
| @item TYPE_HAS_NEW_OPERATOR |
| This predicate holds for a class-type that defines |
| @code{operator new}. |
| |
| @item TYPE_HAS_ARRAY_NEW_OPERATOR |
| This predicate holds for a class-type for which |
| @code{operator new[]} is defined. |
| |
| @item TYPE_OVERLOADS_CALL_EXPR |
| This predicate holds for class-type for which the function call |
| @code{operator()} is overloaded. |
| |
| @item TYPE_OVERLOADS_ARRAY_REF |
| This predicate holds for a class-type that overloads |
| @code{operator[]} |
| |
| @item TYPE_OVERLOADS_ARROW |
| This predicate holds for a class-type for which @code{operator->} is |
| overloaded. |
| |
| @end ftable |
| |
| @node Functions for C++ |
| @subsection Functions for C++ |
| @cindex function |
| @tindex FUNCTION_DECL |
| @tindex OVERLOAD |
| @findex OVL_CURRENT |
| @findex OVL_NEXT |
| |
| A function is represented by a @code{FUNCTION_DECL} node. A set of |
| overloaded functions is sometimes represented by an @code{OVERLOAD} node. |
| |
| An @code{OVERLOAD} node is not a declaration, so none of the |
| @samp{DECL_} macros should be used on an @code{OVERLOAD}. An |
| @code{OVERLOAD} node is similar to a @code{TREE_LIST}. Use |
| @code{OVL_CURRENT} to get the function associated with an |
| @code{OVERLOAD} node; use @code{OVL_NEXT} to get the next |
| @code{OVERLOAD} node in the list of overloaded functions. The macros |
| @code{OVL_CURRENT} and @code{OVL_NEXT} are actually polymorphic; you can |
| use them to work with @code{FUNCTION_DECL} nodes as well as with |
| overloads. In the case of a @code{FUNCTION_DECL}, @code{OVL_CURRENT} |
| will always return the function itself, and @code{OVL_NEXT} will always |
| be @code{NULL_TREE}. |
| |
| To determine the scope of a function, you can use the |
| @code{DECL_CONTEXT} macro. This macro will return the class |
| (either a @code{RECORD_TYPE} or a @code{UNION_TYPE}) or namespace (a |
| @code{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 |
| @code{DECL_FRIEND_CONTEXT} macro can be used to determine the class in |
| which it was defined. For example, in |
| @smallexample |
| class C @{ friend void f() @{@} @}; |
| @end smallexample |
| @noindent |
| the @code{DECL_CONTEXT} for @code{f} will be the |
| @code{global_namespace}, but the @code{DECL_FRIEND_CONTEXT} will be the |
| @code{RECORD_TYPE} for @code{C}. |
| |
| |
| The following macros and functions can be used on a @code{FUNCTION_DECL}: |
| @ftable @code |
| @item DECL_MAIN_P |
| This predicate holds for a function that is the program entry point |
| @code{::code}. |
| |
| @item DECL_LOCAL_FUNCTION_P |
| This predicate holds if the function was declared at block scope, even |
| though it has a global scope. |
| |
| @item DECL_ANTICIPATED |
| This predicate holds if the function is a built-in function but its |
| prototype is not yet explicitly declared. |
| |
| @item DECL_EXTERN_C_FUNCTION_P |
| This predicate holds if the function is declared as an |
| `@code{extern "C"}' function. |
| |
| @item 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 @code{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. |
| |
| @item DECL_FUNCTION_MEMBER_P |
| This macro holds if the function is a member of a class, rather than a |
| member of a namespace. |
| |
| @item DECL_STATIC_FUNCTION_P |
| This predicate holds if the function a static member function. |
| |
| @item DECL_NONSTATIC_MEMBER_FUNCTION_P |
| This macro holds for a non-static member function. |
| |
| @item DECL_CONST_MEMFUNC_P |
| This predicate holds for a @code{const}-member function. |
| |
| @item DECL_VOLATILE_MEMFUNC_P |
| This predicate holds for a @code{volatile}-member function. |
| |
| @item DECL_CONSTRUCTOR_P |
| This macro holds if the function is a constructor. |
| |
| @item DECL_NONCONVERTING_P |
| This predicate holds if the constructor is a non-converting constructor. |
| |
| @item DECL_COMPLETE_CONSTRUCTOR_P |
| This predicate holds for a function which is a constructor for an object |
| of a complete type. |
| |
| @item DECL_BASE_CONSTRUCTOR_P |
| This predicate holds for a function which is a constructor for a base |
| class sub-object. |
| |
| @item DECL_COPY_CONSTRUCTOR_P |
| This predicate holds for a function which is a copy-constructor. |
| |
| @item DECL_DESTRUCTOR_P |
| This macro holds if the function is a destructor. |
| |
| @item DECL_COMPLETE_DESTRUCTOR_P |
| This predicate holds if the function is the destructor for an object a |
| complete type. |
| |
| @item DECL_OVERLOADED_OPERATOR_P |
| This macro holds if the function is an overloaded operator. |
| |
| @item DECL_CONV_FN_P |
| This macro holds if the function is a type-conversion operator. |
| |
| @item DECL_GLOBAL_CTOR_P |
| This predicate holds if the function is a file-scope initialization |
| function. |
| |
| @item DECL_GLOBAL_DTOR_P |
| This predicate holds if the function is a file-scope finalization |
| function. |
| |
| @item DECL_THUNK_P |
| This predicate holds if the function is a thunk. |
| |
| These functions represent stub code that adjusts the @code{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 |
| @code{this} pointer; the thunk should add @code{THUNK_DELTA} to this |
| value. (The @code{THUNK_DELTA} is an @code{int}, not an |
| @code{INTEGER_CST}.) |
| |
| Then, if @code{THUNK_VCALL_OFFSET} (an @code{INTEGER_CST}) is nonzero |
| the adjusted @code{this} pointer must be adjusted again. The complete |
| calculation is given by the following pseudo-code: |
| |
| @smallexample |
| this += THUNK_DELTA |
| if (THUNK_VCALL_OFFSET) |
| this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET] |
| @end smallexample |
| |
| Finally, the thunk should jump to the location given |
| by @code{DECL_INITIAL}; this will always be an expression for the |
| address of a function. |
| |
| @item DECL_NON_THUNK_FUNCTION_P |
| This predicate holds if the function is @emph{not} a thunk function. |
| |
| @item GLOBAL_INIT_PRIORITY |
| If either @code{DECL_GLOBAL_CTOR_P} or @code{DECL_GLOBAL_DTOR_P} holds, |
| then this gives the initialization priority for the function. The |
| linker will arrange that all functions for which |
| @code{DECL_GLOBAL_CTOR_P} holds are run in increasing order of priority |
| before @code{main} is called. When the program exits, all functions for |
| which @code{DECL_GLOBAL_DTOR_P} holds are run in the reverse order. |
| |
| @item TYPE_RAISES_EXCEPTIONS |
| This macro returns the list of exceptions that a (member-)function can |
| raise. The returned list, if non @code{NULL}, is comprised of nodes |
| whose @code{TREE_VALUE} represents a type. |
| |
| @item TYPE_NOTHROW_P |
| This predicate holds when the exception-specification of its arguments |
| is of the form `@code{()}'. |
| |
| @item DECL_ARRAY_DELETE_OPERATOR_P |
| This predicate holds if the function an overloaded |
| @code{operator delete[]}. |
| |
| @end ftable |
| |
| @c --------------------------------------------------------------------- |
| @c Function Bodies |
| @c --------------------------------------------------------------------- |
| |
| @node Statements for C and C++ |
| @subsection Statements for C and C++ |
| @cindex statements |
| @tindex BREAK_STMT |
| @tindex CLEANUP_STMT |
| @findex CLEANUP_DECL |
| @findex CLEANUP_EXPR |
| @tindex CONTINUE_STMT |
| @tindex DECL_STMT |
| @findex DECL_STMT_DECL |
| @tindex DO_STMT |
| @findex DO_BODY |
| @findex DO_COND |
| @tindex EMPTY_CLASS_EXPR |
| @tindex EXPR_STMT |
| @findex EXPR_STMT_EXPR |
| @tindex FOR_STMT |
| @findex FOR_INIT_STMT |
| @findex FOR_COND |
| @findex FOR_EXPR |
| @findex FOR_BODY |
| @tindex HANDLER |
| @tindex IF_STMT |
| @findex IF_COND |
| @findex THEN_CLAUSE |
| @findex ELSE_CLAUSE |
| @tindex RETURN_STMT |
| @findex RETURN_EXPR |
| @tindex SUBOBJECT |
| @findex SUBOBJECT_CLEANUP |
| @tindex SWITCH_STMT |
| @findex SWITCH_COND |
| @findex SWITCH_BODY |
| @tindex TRY_BLOCK |
| @findex TRY_STMTS |
| @findex TRY_HANDLERS |
| @findex HANDLER_PARMS |
| @findex HANDLER_BODY |
| @findex USING_STMT |
| @tindex WHILE_STMT |
| @findex WHILE_BODY |
| @findex WHILE_COND |
| |
| A function that has a definition in the current translation unit has |
| a non-@code{NULL} @code{DECL_INITIAL}. However, back ends should not make |
| use of the particular value given by @code{DECL_INITIAL}. |
| |
| The @code{DECL_SAVED_TREE} gives the complete body of the |
| function. |
| |
| 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: |
| |
| @ftable @code |
| @item 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 @code{STMT_IS_FULL_EXPR_P} set. Temporaries |
| created during such statements should be destroyed when the innermost |
| enclosing statement with @code{STMT_IS_FULL_EXPR_P} set is exited. |
| |
| @end ftable |
| |
| 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 @code{while} |
| loop has a body, which is itself a statement. If the substatement |
| is @code{NULL_TREE}, it is considered equivalent to a statement |
| consisting of a single @code{;}, 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 @code{TREE_CHAIN}s. So, you should |
| always process the statement tree by looping over substatements, like |
| this: |
| @smallexample |
| void process_stmt (stmt) |
| tree stmt; |
| @{ |
| while (stmt) |
| @{ |
| switch (TREE_CODE (stmt)) |
| @{ |
| case IF_STMT: |
| process_stmt (THEN_CLAUSE (stmt)); |
| /* @r{More processing here.} */ |
| break; |
| |
| @dots{} |
| @} |
| |
| stmt = TREE_CHAIN (stmt); |
| @} |
| @} |
| @end smallexample |
| In other words, while the @code{then} clause of an @code{if} statement |
| in C++ can be only one statement (although that one statement may be a |
| compound statement), the intermediate representation sometimes uses |
| several statements chained together. |
| |
| @table @code |
| @item BREAK_STMT |
| |
| Used to represent a @code{break} statement. There are no additional |
| fields. |
| |
| @item 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, @code{CLEANUP_DECL} will be |
| the @code{VAR_DECL} destroyed. Otherwise, @code{CLEANUP_DECL} will be |
| @code{NULL_TREE}. In any case, the @code{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 |
| @code{CLEANUP_STMT}s were encountered. |
| |
| @item CONTINUE_STMT |
| |
| Used to represent a @code{continue} statement. There are no additional |
| fields. |
| |
| @item CTOR_STMT |
| |
| Used to mark the beginning (if @code{CTOR_BEGIN_P} holds) or end (if |
| @code{CTOR_END_P} holds of the main body of a constructor. See also |
| @code{SUBOBJECT} for more information on how to use these nodes. |
| |
| @item DO_STMT |
| |
| Used to represent a @code{do} loop. The body of the loop is given by |
| @code{DO_BODY} while the termination condition for the loop is given by |
| @code{DO_COND}. The condition for a @code{do}-statement is always an |
| expression. |
| |
| @item 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 |
| @code{TREE_TYPE} represents the type of the object. |
| |
| @item EXPR_STMT |
| |
| Used to represent an expression statement. Use @code{EXPR_STMT_EXPR} to |
| obtain the expression. |
| |
| @item FOR_STMT |
| |
| Used to represent a @code{for} statement. The @code{FOR_INIT_STMT} is |
| the initialization statement for the loop. The @code{FOR_COND} is the |
| termination condition. The @code{FOR_EXPR} is the expression executed |
| right before the @code{FOR_COND} on each loop iteration; often, this |
| expression increments a counter. The body of the loop is given by |
| @code{FOR_BODY}. @code{FOR_SCOPE} holds the scope of the @code{for} |
| statement (used in the C++ front end only). Note that |
| @code{FOR_INIT_STMT} and @code{FOR_BODY} return statements, while |
| @code{FOR_COND} and @code{FOR_EXPR} return expressions. |
| |
| @item HANDLER |
| |
| Used to represent a C++ @code{catch} block. The @code{HANDLER_TYPE} |
| is the type of exception that will be caught by this handler; it is |
| equal (by pointer equality) to @code{NULL} if this handler is for all |
| types. @code{HANDLER_PARMS} is the @code{DECL_STMT} for the catch |
| parameter, and @code{HANDLER_BODY} is the code for the block itself. |
| |
| @item IF_STMT |
| |
| Used to represent an @code{if} statement. The @code{IF_COND} is the |
| expression. |
| |
| If the condition is a @code{TREE_LIST}, then the @code{TREE_PURPOSE} is |
| a statement (usually a @code{DECL_STMT}). Each time the condition is |
| evaluated, the statement should be executed. Then, the |
| @code{TREE_VALUE} should be used as the conditional expression itself. |
| This representation is used to handle C++ code like this: |
| |
| @smallexample |
| if (int i = 7) @dots{} |
| @end smallexample |
| |
| where there is a new local variable (or variables) declared within the |
| condition. |
| |
| The @code{THEN_CLAUSE} represents the statement given by the @code{then} |
| condition, while the @code{ELSE_CLAUSE} represents the statement given |
| by the @code{else} condition. |
| |
| C++ distinguishes between this and @code{COND_EXPR} for handling templates. |
| |
| @item SUBOBJECT |
| |
| In a constructor, these nodes are used to mark the point at which a |
| subobject of @code{this} is fully constructed. If, after this point, an |
| exception is thrown before a @code{CTOR_STMT} with @code{CTOR_END_P} set |
| is encountered, the @code{SUBOBJECT_CLEANUP} must be executed. The |
| cleanups must be executed in the reverse order in which they appear. |
| |
| @item SWITCH_STMT |
| |
| Used to represent a @code{switch} statement. The @code{SWITCH_STMT_COND} |
| is the expression on which the switch is occurring. See the documentation |
| for an @code{IF_STMT} for more information on the representation used |
| for the condition. The @code{SWITCH_STMT_BODY} is the body of the switch |
| statement. The @code{SWITCH_STMT_TYPE} is the original type of switch |
| expression as given in the source, before any compiler conversions. |
| The @code{SWITCH_STMT_SCOPE} is the statement scope (used in the |
| C++ front end only). |
| |
| There are also two boolean flags used with @code{SWITCH_STMT}. |
| @code{SWITCH_STMT_ALL_CASES_P} is true if the switch includes a default label |
| or the case label ranges cover all possible values of the condition |
| expression. @code{SWITCH_STMT_NO_BREAK_P} is true if there are no |
| @code{break} statements in the switch. |
| |
| @item TRY_BLOCK |
| Used to represent a @code{try} block. The body of the try block is |
| given by @code{TRY_STMTS}. Each of the catch blocks is a @code{HANDLER} |
| node. The first handler is given by @code{TRY_HANDLERS}. Subsequent |
| handlers are obtained by following the @code{TREE_CHAIN} link from one |
| handler to the next. The body of the handler is given by |
| @code{HANDLER_BODY}. |
| |
| If @code{CLEANUP_P} holds of the @code{TRY_BLOCK}, then the |
| @code{TRY_HANDLERS} will not be a @code{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, |
| @code{terminate} must be called. |
| |
| @item USING_STMT |
| Used to represent a @code{using} directive. The namespace is given by |
| @code{USING_STMT_NAMESPACE}, which will be a NAMESPACE_DECL@. This node |
| is needed inside template functions, to implement using directives |
| during instantiation. |
| |
| @item WHILE_STMT |
| |
| Used to represent a @code{while} loop. The @code{WHILE_COND} is the |
| termination condition for the loop. See the documentation for an |
| @code{IF_STMT} for more information on the representation used for the |
| condition. |
| |
| The @code{WHILE_BODY} is the body of the loop. |
| |
| @end table |
| |
| @node C++ Expressions |
| @subsection C++ Expressions |
| |
| This section describes expressions specific to the C and C++ front |
| ends. |
| |
| @table @code |
| @item TYPEID_EXPR |
| |
| Used to represent a @code{typeid} expression. |
| |
| @item NEW_EXPR |
| @itemx VEC_NEW_EXPR |
| |
| Used to represent a call to @code{new} and @code{new[]} respectively. |
| |
| @item DELETE_EXPR |
| @itemx VEC_DELETE_EXPR |
| |
| Used to represent a call to @code{delete} and @code{delete[]} respectively. |
| |
| @item MEMBER_REF |
| |
| Represents a reference to a member of a class. |
| |
| @item THROW_EXPR |
| |
| Represents an instance of @code{throw} in the program. Operand 0, |
| which is the expression to throw, may be @code{NULL_TREE}. |
| |
| |
| @item AGGR_INIT_EXPR |
| An @code{AGGR_INIT_EXPR} represents the initialization as the return |
| value of a function call, or as the result of a constructor. An |
| @code{AGGR_INIT_EXPR} will only appear as a full-expression, or as the |
| second operand of a @code{TARGET_EXPR}. @code{AGGR_INIT_EXPR}s have |
| a representation similar to that of @code{CALL_EXPR}s. You can use |
| the @code{AGGR_INIT_EXPR_FN} and @code{AGGR_INIT_EXPR_ARG} macros to access |
| the function to call and the arguments to pass. |
| |
| If @code{AGGR_INIT_VIA_CTOR_P} holds of the @code{AGGR_INIT_EXPR}, then |
| the initialization is via a constructor call. The address of the |
| @code{AGGR_INIT_EXPR_SLOT} operand, which is always a @code{VAR_DECL}, |
| is taken, and this value replaces the first argument in the argument |
| list. |
| |
| In either case, the expression is void. |
| |
| |
| @end table |