1 @c Copyright (C) 2004-2013 Free Software Foundation, Inc.
2 @c This is part of the GCC manual.
3 @c For copying conditions, see the file gcc.texi.
5 @c ---------------------------------------------------------------------
7 @c ---------------------------------------------------------------------
13 The purpose of GENERIC is simply to provide a
14 language-independent way of representing an entire function in
15 trees. To this end, it was necessary to add a few new tree codes
16 to the back end, but most everything was already there. If you
17 can express it with the codes in @code{gcc/tree.def}, it's
20 Early on, there was a great deal of debate about how to think
21 about statements in a tree IL@. In GENERIC, a statement is
22 defined as any expression whose value, if any, is ignored. A
23 statement will always have @code{TREE_SIDE_EFFECTS} set (or it
24 will be discarded), but a non-statement expression may also have
25 side effects. A @code{CALL_EXPR}, for instance.
27 It would be possible for some local optimizations to work on the
28 GENERIC form of a function; indeed, the adapted tree inliner
29 works fine on GENERIC, but the current compiler performs inlining
30 after lowering to GIMPLE (a restricted form described in the next
31 section). Indeed, currently the frontends perform this lowering
32 before handing off to @code{tree_rest_of_compilation}, but this
36 * Deficiencies:: Topics net yet covered in this document.
37 * Tree overview:: All about @code{tree}s.
38 * Types:: Fundamental and aggregate types.
39 * Declarations:: Type declarations and variables.
40 * Attributes:: Declaration and type attributes.
41 * Expressions: Expression trees. Operating on data.
42 * Statements:: Control flow and related trees.
43 * Functions:: Function bodies, linkage, and other aspects.
44 * Language-dependent trees:: Topics and trees specific to language front ends.
45 * C and C++ Trees:: Trees specific to C and C++.
46 * Java Trees:: Trees specific to Java.
49 @c ---------------------------------------------------------------------
51 @c ---------------------------------------------------------------------
56 There are many places in which this document is incomplet and incorrekt.
57 It is, as of yet, only @emph{preliminary} documentation.
59 @c ---------------------------------------------------------------------
61 @c ---------------------------------------------------------------------
68 The central data structure used by the internal representation is the
69 @code{tree}. These nodes, while all of the C type @code{tree}, are of
70 many varieties. A @code{tree} is a pointer type, but the object to
71 which it points may be of a variety of types. From this point forward,
72 we will refer to trees in ordinary type, rather than in @code{this
73 font}, except when talking about the actual C type @code{tree}.
75 You can tell what kind of node a particular tree is by using the
76 @code{TREE_CODE} macro. Many, many macros take trees as input and
77 return trees as output. However, most macros require a certain kind of
78 tree node as input. In other words, there is a type-system for trees,
79 but it is not reflected in the C type-system.
81 For safety, it is useful to configure GCC with @option{--enable-checking}.
82 Although this results in a significant performance penalty (since all
83 tree types are checked at run-time), and is therefore inappropriate in a
84 release version, it is extremely helpful during the development process.
86 Many macros behave as predicates. Many, although not all, of these
87 predicates end in @samp{_P}. Do not rely on the result type of these
88 macros being of any particular type. You may, however, rely on the fact
89 that the type can be compared to @code{0}, so that statements like
91 if (TEST_P (t) && !TEST_P (y))
97 int i = (TEST_P (t) != 0);
100 are legal. Macros that return @code{int} values now may be changed to
101 return @code{tree} values, or other pointers in the future. Even those
102 that continue to return @code{int} may return multiple nonzero codes
103 where previously they returned only zero and one. Therefore, you should
109 as this code is not guaranteed to work correctly in the future.
111 You should not take the address of values returned by the macros or
112 functions described here. In particular, no guarantee is given that the
115 In general, the names of macros are all in uppercase, while the names of
116 functions are entirely in lowercase. There are rare exceptions to this
117 rule. You should assume that any macro or function whose name is made
118 up entirely of uppercase letters may evaluate its arguments more than
119 once. You may assume that a macro or function whose name is made up
120 entirely of lowercase letters will evaluate its arguments only once.
122 The @code{error_mark_node} is a special tree. Its tree code is
123 @code{ERROR_MARK}, but since there is only ever one node with that code,
124 the usual practice is to compare the tree against
125 @code{error_mark_node}. (This test is just a test for pointer
126 equality.) If an error has occurred during front-end processing the
127 flag @code{errorcount} will be set. If the front end has encountered
128 code it cannot handle, it will issue a message to the user and set
129 @code{sorrycount}. When these flags are set, any macro or function
130 which normally returns a tree of a particular kind may instead return
131 the @code{error_mark_node}. Thus, if you intend to do any processing of
132 erroneous code, you must be prepared to deal with the
133 @code{error_mark_node}.
135 Occasionally, a particular tree slot (like an operand to an expression,
136 or a particular field in a declaration) will be referred to as
137 ``reserved for the back end''. These slots are used to store RTL when
138 the tree is converted to RTL for use by the GCC back end. However, if
139 that process is not taking place (e.g., if the front end is being hooked
140 up to an intelligent editor), then those slots may be used by the
141 back end presently in use.
143 If you encounter situations that do not match this documentation, such
144 as tree nodes of types not mentioned here, or macros documented to
145 return entities of a particular kind that instead return entities of
146 some different kind, you have found a bug, either in the front end or in
147 the documentation. Please report these bugs as you would any other
151 * Macros and Functions::Macros and functions that can be used with all trees.
152 * Identifiers:: The names of things.
153 * Containers:: Lists and vectors.
156 @c ---------------------------------------------------------------------
158 @c ---------------------------------------------------------------------
160 @node Macros and Functions
166 All GENERIC trees have two fields in common. First, @code{TREE_CHAIN}
167 is a pointer that can be used as a singly-linked list to other trees.
168 The other is @code{TREE_TYPE}. Many trees store the type of an
169 expression or declaration in this field.
171 These are some other functions for handling trees:
176 Return the number of bytes a tree takes.
186 These functions build a tree and supply values to put in each
187 parameter. The basic signature is @samp{@w{code, type, [operands]}}.
188 @code{code} is the @code{TREE_CODE}, and @code{type} is a tree
189 representing the @code{TREE_TYPE}. These are followed by the
190 operands, each of which is also a tree.
195 @c ---------------------------------------------------------------------
197 @c ---------------------------------------------------------------------
200 @subsection Identifiers
203 @tindex IDENTIFIER_NODE
205 An @code{IDENTIFIER_NODE} represents a slightly more general concept
206 that the standard C or C++ concept of identifier. In particular, an
207 @code{IDENTIFIER_NODE} may contain a @samp{$}, or other extraordinary
210 There are never two distinct @code{IDENTIFIER_NODE}s representing the
211 same identifier. Therefore, you may use pointer equality to compare
212 @code{IDENTIFIER_NODE}s, rather than using a routine like
213 @code{strcmp}. Use @code{get_identifier} to obtain the unique
214 @code{IDENTIFIER_NODE} for a supplied string.
216 You can use the following macros to access identifiers:
218 @item IDENTIFIER_POINTER
219 The string represented by the identifier, represented as a
220 @code{char*}. This string is always @code{NUL}-terminated, and contains
221 no embedded @code{NUL} characters.
223 @item IDENTIFIER_LENGTH
224 The length of the string returned by @code{IDENTIFIER_POINTER}, not
225 including the trailing @code{NUL}. This value of
226 @code{IDENTIFIER_LENGTH (x)} is always the same as @code{strlen
227 (IDENTIFIER_POINTER (x))}.
229 @item IDENTIFIER_OPNAME_P
230 This predicate holds if the identifier represents the name of an
231 overloaded operator. In this case, you should not depend on the
232 contents of either the @code{IDENTIFIER_POINTER} or the
233 @code{IDENTIFIER_LENGTH}.
235 @item IDENTIFIER_TYPENAME_P
236 This predicate holds if the identifier represents the name of a
237 user-defined conversion operator. In this case, the @code{TREE_TYPE} of
238 the @code{IDENTIFIER_NODE} holds the type to which the conversion
243 @c ---------------------------------------------------------------------
245 @c ---------------------------------------------------------------------
248 @subsection Containers
256 @findex TREE_VEC_LENGTH
259 Two common container data structures can be represented directly with
260 tree nodes. A @code{TREE_LIST} is a singly linked list containing two
261 trees per node. These are the @code{TREE_PURPOSE} and @code{TREE_VALUE}
262 of each node. (Often, the @code{TREE_PURPOSE} contains some kind of
263 tag, or additional information, while the @code{TREE_VALUE} contains the
264 majority of the payload. In other cases, the @code{TREE_PURPOSE} is
265 simply @code{NULL_TREE}, while in still others both the
266 @code{TREE_PURPOSE} and @code{TREE_VALUE} are of equal stature.) Given
267 one @code{TREE_LIST} node, the next node is found by following the
268 @code{TREE_CHAIN}. If the @code{TREE_CHAIN} is @code{NULL_TREE}, then
269 you have reached the end of the list.
271 A @code{TREE_VEC} is a simple vector. The @code{TREE_VEC_LENGTH} is an
272 integer (not a tree) giving the number of nodes in the vector. The
273 nodes themselves are accessed using the @code{TREE_VEC_ELT} macro, which
274 takes two arguments. The first is the @code{TREE_VEC} in question; the
275 second is an integer indicating which element in the vector is desired.
276 The elements are indexed from zero.
278 @c ---------------------------------------------------------------------
280 @c ---------------------------------------------------------------------
287 @cindex fundamental type
291 @tindex TYPE_MIN_VALUE
292 @tindex TYPE_MAX_VALUE
294 @tindex FIXED_POINT_TYPE
296 @tindex ENUMERAL_TYPE
299 @tindex REFERENCE_TYPE
300 @tindex FUNCTION_TYPE
307 @findex TYPE_UNQUALIFIED
308 @findex TYPE_QUAL_CONST
309 @findex TYPE_QUAL_VOLATILE
310 @findex TYPE_QUAL_RESTRICT
311 @findex TYPE_MAIN_VARIANT
312 @cindex qualified type
315 @findex TYPE_PRECISION
316 @findex TYPE_ARG_TYPES
317 @findex TYPE_METHOD_BASETYPE
318 @findex TYPE_OFFSET_BASETYPE
322 @findex TYPENAME_TYPE_FULLNAME
324 @findex TYPE_CANONICAL
325 @findex TYPE_STRUCTURAL_EQUALITY_P
326 @findex SET_TYPE_STRUCTURAL_EQUALITY
328 All types have corresponding tree nodes. However, you should not assume
329 that there is exactly one tree node corresponding to each type. There
330 are often multiple nodes corresponding to the same type.
332 For the most part, different kinds of types have different tree codes.
333 (For example, pointer types use a @code{POINTER_TYPE} code while arrays
334 use an @code{ARRAY_TYPE} code.) However, pointers to member functions
335 use the @code{RECORD_TYPE} code. Therefore, when writing a
336 @code{switch} statement that depends on the code associated with a
337 particular type, you should take care to handle pointers to member
338 functions under the @code{RECORD_TYPE} case label.
340 The following functions and macros deal with cv-qualification of types:
342 @item TYPE_MAIN_VARIANT
343 This macro returns the unqualified version of a type. It may be applied
344 to an unqualified type, but it is not always the identity function in
348 A few other macros and functions are usable with all types:
351 The number of bits required to represent the type, represented as an
352 @code{INTEGER_CST}. For an incomplete type, @code{TYPE_SIZE} will be
356 The alignment of the type, in bits, represented as an @code{int}.
359 This macro returns a declaration (in the form of a @code{TYPE_DECL}) for
360 the type. (Note this macro does @emph{not} return an
361 @code{IDENTIFIER_NODE}, as you might expect, given its name!) You can
362 look at the @code{DECL_NAME} of the @code{TYPE_DECL} to obtain the
363 actual name of the type. The @code{TYPE_NAME} will be @code{NULL_TREE}
364 for a type that is not a built-in type, the result of a typedef, or a
368 This macro returns the ``canonical'' type for the given type
369 node. Canonical types are used to improve performance in the C++ and
370 Objective-C++ front ends by allowing efficient comparison between two
371 type nodes in @code{same_type_p}: if the @code{TYPE_CANONICAL} values
372 of the types are equal, the types are equivalent; otherwise, the types
373 are not equivalent. The notion of equivalence for canonical types is
374 the same as the notion of type equivalence in the language itself. For
377 When @code{TYPE_CANONICAL} is @code{NULL_TREE}, there is no canonical
378 type for the given type node. In this case, comparison between this
379 type and any other type requires the compiler to perform a deep,
380 ``structural'' comparison to see if the two type nodes have the same
383 The canonical type for a node is always the most fundamental type in
384 the equivalence class of types. For instance, @code{int} is its own
385 canonical type. A typedef @code{I} of @code{int} will have @code{int}
386 as its canonical type. Similarly, @code{I*}@ and a typedef @code{IP}@
387 (defined to @code{I*}) will has @code{int*} as their canonical
388 type. When building a new type node, be sure to set
389 @code{TYPE_CANONICAL} to the appropriate canonical type. If the new
390 type is a compound type (built from other types), and any of those
391 other types require structural equality, use
392 @code{SET_TYPE_STRUCTURAL_EQUALITY} to ensure that the new type also
393 requires structural equality. Finally, if for some reason you cannot
394 guarantee that @code{TYPE_CANONICAL} will point to the canonical type,
395 use @code{SET_TYPE_STRUCTURAL_EQUALITY} to make sure that the new
396 type--and any type constructed based on it--requires structural
397 equality. If you suspect that the canonical type system is
398 miscomparing types, pass @code{--param verify-canonical-types=1} to
399 the compiler or configure with @code{--enable-checking} to force the
400 compiler to verify its canonical-type comparisons against the
401 structural comparisons; the compiler will then print any warnings if
402 the canonical types miscompare.
404 @item TYPE_STRUCTURAL_EQUALITY_P
405 This predicate holds when the node requires structural equality
406 checks, e.g., when @code{TYPE_CANONICAL} is @code{NULL_TREE}.
408 @item SET_TYPE_STRUCTURAL_EQUALITY
409 This macro states that the type node it is given requires structural
410 equality checks, e.g., it sets @code{TYPE_CANONICAL} to
414 This predicate takes two types as input, and holds if they are the same
415 type. For example, if one type is a @code{typedef} for the other, or
416 both are @code{typedef}s for the same type. This predicate also holds if
417 the two trees given as input are simply copies of one another; i.e.,
418 there is no difference between them at the source level, but, for
419 whatever reason, a duplicate has been made in the representation. You
420 should never use @code{==} (pointer equality) to compare types; always
421 use @code{same_type_p} instead.
424 Detailed below are the various kinds of types, and the macros that can
425 be used to access them. Although other kinds of types are used
426 elsewhere in G++, the types described here are the only ones that you
427 will encounter while examining the intermediate representation.
431 Used to represent the @code{void} type.
434 Used to represent the various integral types, including @code{char},
435 @code{short}, @code{int}, @code{long}, and @code{long long}. This code
436 is not used for enumeration types, nor for the @code{bool} type.
437 The @code{TYPE_PRECISION} is the number of bits used in
438 the representation, represented as an @code{unsigned int}. (Note that
439 in the general case this is not the same value as @code{TYPE_SIZE};
440 suppose that there were a 24-bit integer type, but that alignment
441 requirements for the ABI required 32-bit alignment. Then,
442 @code{TYPE_SIZE} would be an @code{INTEGER_CST} for 32, while
443 @code{TYPE_PRECISION} would be 24.) The integer type is unsigned if
444 @code{TYPE_UNSIGNED} holds; otherwise, it is signed.
446 The @code{TYPE_MIN_VALUE} is an @code{INTEGER_CST} for the smallest
447 integer that may be represented by this type. Similarly, the
448 @code{TYPE_MAX_VALUE} is an @code{INTEGER_CST} for the largest integer
449 that may be represented by this type.
452 Used to represent the @code{float}, @code{double}, and @code{long
453 double} types. The number of bits in the floating-point representation
454 is given by @code{TYPE_PRECISION}, as in the @code{INTEGER_TYPE} case.
456 @item FIXED_POINT_TYPE
457 Used to represent the @code{short _Fract}, @code{_Fract}, @code{long
458 _Fract}, @code{long long _Fract}, @code{short _Accum}, @code{_Accum},
459 @code{long _Accum}, and @code{long long _Accum} types. The number of bits
460 in the fixed-point representation is given by @code{TYPE_PRECISION},
461 as in the @code{INTEGER_TYPE} case. There may be padding bits, fractional
462 bits and integral bits. The number of fractional bits is given by
463 @code{TYPE_FBIT}, and the number of integral bits is given by @code{TYPE_IBIT}.
464 The fixed-point type is unsigned if @code{TYPE_UNSIGNED} holds; otherwise,
466 The fixed-point type is saturating if @code{TYPE_SATURATING} holds; otherwise,
467 it is not saturating.
470 Used to represent GCC built-in @code{__complex__} data types. The
471 @code{TREE_TYPE} is the type of the real and imaginary parts.
474 Used to represent an enumeration type. The @code{TYPE_PRECISION} gives
475 (as an @code{int}), the number of bits used to represent the type. If
476 there are no negative enumeration constants, @code{TYPE_UNSIGNED} will
477 hold. The minimum and maximum enumeration constants may be obtained
478 with @code{TYPE_MIN_VALUE} and @code{TYPE_MAX_VALUE}, respectively; each
479 of these macros returns an @code{INTEGER_CST}.
481 The actual enumeration constants themselves may be obtained by looking
482 at the @code{TYPE_VALUES}. This macro will return a @code{TREE_LIST},
483 containing the constants. The @code{TREE_PURPOSE} of each node will be
484 an @code{IDENTIFIER_NODE} giving the name of the constant; the
485 @code{TREE_VALUE} will be an @code{INTEGER_CST} giving the value
486 assigned to that constant. These constants will appear in the order in
487 which they were declared. The @code{TREE_TYPE} of each of these
488 constants will be the type of enumeration type itself.
491 Used to represent the @code{bool} type.
494 Used to represent pointer types, and pointer to data member types. The
495 @code{TREE_TYPE} gives the type to which this type points.
498 Used to represent reference types. The @code{TREE_TYPE} gives the type
499 to which this type refers.
502 Used to represent the type of non-member functions and of static member
503 functions. The @code{TREE_TYPE} gives the return type of the function.
504 The @code{TYPE_ARG_TYPES} are a @code{TREE_LIST} of the argument types.
505 The @code{TREE_VALUE} of each node in this list is the type of the
506 corresponding argument; the @code{TREE_PURPOSE} is an expression for the
507 default argument value, if any. If the last node in the list is
508 @code{void_list_node} (a @code{TREE_LIST} node whose @code{TREE_VALUE}
509 is the @code{void_type_node}), then functions of this type do not take
510 variable arguments. Otherwise, they do take a variable number of
513 Note that in C (but not in C++) a function declared like @code{void f()}
514 is an unprototyped function taking a variable number of arguments; the
515 @code{TYPE_ARG_TYPES} of such a function will be @code{NULL}.
518 Used to represent the type of a non-static member function. Like a
519 @code{FUNCTION_TYPE}, the return type is given by the @code{TREE_TYPE}.
520 The type of @code{*this}, i.e., the class of which functions of this
521 type are a member, is given by the @code{TYPE_METHOD_BASETYPE}. The
522 @code{TYPE_ARG_TYPES} is the parameter list, as for a
523 @code{FUNCTION_TYPE}, and includes the @code{this} argument.
526 Used to represent array types. The @code{TREE_TYPE} gives the type of
527 the elements in the array. If the array-bound is present in the type,
528 the @code{TYPE_DOMAIN} is an @code{INTEGER_TYPE} whose
529 @code{TYPE_MIN_VALUE} and @code{TYPE_MAX_VALUE} will be the lower and
530 upper bounds of the array, respectively. The @code{TYPE_MIN_VALUE} will
531 always be an @code{INTEGER_CST} for zero, while the
532 @code{TYPE_MAX_VALUE} will be one less than the number of elements in
533 the array, i.e., the highest value which may be used to index an element
537 Used to represent @code{struct} and @code{class} types, as well as
538 pointers to member functions and similar constructs in other languages.
539 @code{TYPE_FIELDS} contains the items contained in this type, each of
540 which can be a @code{FIELD_DECL}, @code{VAR_DECL}, @code{CONST_DECL}, or
541 @code{TYPE_DECL}. You may not make any assumptions about the ordering
542 of the fields in the type or whether one or more of them overlap.
545 Used to represent @code{union} types. Similar to @code{RECORD_TYPE}
546 except that all @code{FIELD_DECL} nodes in @code{TYPE_FIELD} start at
549 @item QUAL_UNION_TYPE
550 Used to represent part of a variant record in Ada. Similar to
551 @code{UNION_TYPE} except that each @code{FIELD_DECL} has a
552 @code{DECL_QUALIFIER} field, which contains a boolean expression that
553 indicates whether the field is present in the object. The type will only
554 have one field, so each field's @code{DECL_QUALIFIER} is only evaluated
555 if none of the expressions in the previous fields in @code{TYPE_FIELDS}
556 are nonzero. Normally these expressions will reference a field in the
557 outer object using a @code{PLACEHOLDER_EXPR}.
560 This node is used to represent a language-specific type. The front
564 This node is used to represent a pointer-to-data member. For a data
565 member @code{X::m} the @code{TYPE_OFFSET_BASETYPE} is @code{X} and the
566 @code{TREE_TYPE} is the type of @code{m}.
570 There are variables whose values represent some of the basic types.
574 A node for @code{void}.
576 @item integer_type_node
577 A node for @code{int}.
579 @item unsigned_type_node.
580 A node for @code{unsigned int}.
582 @item char_type_node.
583 A node for @code{char}.
586 It may sometimes be useful to compare one of these variables with a type
587 in hand, using @code{same_type_p}.
589 @c ---------------------------------------------------------------------
591 @c ---------------------------------------------------------------------
594 @section Declarations
597 @cindex type declaration
603 @tindex DEBUG_EXPR_DECL
605 @tindex NAMESPACE_DECL
607 @tindex TEMPLATE_DECL
613 @findex DECL_EXTERNAL
615 This section covers the various kinds of declarations that appear in the
616 internal representation, except for declarations of functions
617 (represented by @code{FUNCTION_DECL} nodes), which are described in
621 * Working with declarations:: Macros and functions that work on
623 * Internal structure:: How declaration nodes are represented.
626 @node Working with declarations
627 @subsection Working with declarations
629 Some macros can be used with any kind of declaration. These include:
632 This macro returns an @code{IDENTIFIER_NODE} giving the name of the
636 This macro returns the type of the entity declared.
639 This macro returns the name of the file in which the entity was
640 declared, as a @code{char*}. For an entity declared implicitly by the
641 compiler (like @code{__builtin_memcpy}), this will be the string
645 This macro returns the line number at which the entity was declared, as
648 @item DECL_ARTIFICIAL
649 This predicate holds if the declaration was implicitly generated by the
650 compiler. For example, this predicate will hold of an implicitly
651 declared member function, or of the @code{TYPE_DECL} implicitly
652 generated for a class type. Recall that in C++ code like:
657 is roughly equivalent to C code like:
662 The implicitly generated @code{typedef} declaration is represented by a
663 @code{TYPE_DECL} for which @code{DECL_ARTIFICIAL} holds.
667 The various kinds of declarations include:
670 These nodes are used to represent labels in function bodies. For more
671 information, see @ref{Functions}. These nodes only appear in block
675 These nodes are used to represent enumeration constants. The value of
676 the constant is given by @code{DECL_INITIAL} which will be an
677 @code{INTEGER_CST} with the same type as the @code{TREE_TYPE} of the
678 @code{CONST_DECL}, i.e., an @code{ENUMERAL_TYPE}.
681 These nodes represent the value returned by a function. When a value is
682 assigned to a @code{RESULT_DECL}, that indicates that the value should
683 be returned, via bitwise copy, by the function. You can use
684 @code{DECL_SIZE} and @code{DECL_ALIGN} on a @code{RESULT_DECL}, just as
685 with a @code{VAR_DECL}.
688 These nodes represent @code{typedef} declarations. The @code{TREE_TYPE}
689 is the type declared to have the name given by @code{DECL_NAME}. In
690 some cases, there is no associated name.
693 These nodes represent variables with namespace or block scope, as well
694 as static data members. The @code{DECL_SIZE} and @code{DECL_ALIGN} are
695 analogous to @code{TYPE_SIZE} and @code{TYPE_ALIGN}. For a declaration,
696 you should always use the @code{DECL_SIZE} and @code{DECL_ALIGN} rather
697 than the @code{TYPE_SIZE} and @code{TYPE_ALIGN} given by the
698 @code{TREE_TYPE}, since special attributes may have been applied to the
699 variable to give it a particular size and alignment. You may use the
700 predicates @code{DECL_THIS_STATIC} or @code{DECL_THIS_EXTERN} to test
701 whether the storage class specifiers @code{static} or @code{extern} were
702 used to declare a variable.
704 If this variable is initialized (but does not require a constructor),
705 the @code{DECL_INITIAL} will be an expression for the initializer. The
706 initializer should be evaluated, and a bitwise copy into the variable
707 performed. If the @code{DECL_INITIAL} is the @code{error_mark_node},
708 there is an initializer, but it is given by an explicit statement later
709 in the code; no bitwise copy is required.
711 GCC provides an extension that allows either automatic variables, or
712 global variables, to be placed in particular registers. This extension
713 is being used for a particular @code{VAR_DECL} if @code{DECL_REGISTER}
714 holds for the @code{VAR_DECL}, and if @code{DECL_ASSEMBLER_NAME} is not
715 equal to @code{DECL_NAME}. In that case, @code{DECL_ASSEMBLER_NAME} is
716 the name of the register into which the variable will be placed.
719 Used to represent a parameter to a function. Treat these nodes
720 similarly to @code{VAR_DECL} nodes. These nodes only appear in the
721 @code{DECL_ARGUMENTS} for a @code{FUNCTION_DECL}.
723 The @code{DECL_ARG_TYPE} for a @code{PARM_DECL} is the type that will
724 actually be used when a value is passed to this function. It may be a
725 wider type than the @code{TREE_TYPE} of the parameter; for example, the
726 ordinary type might be @code{short} while the @code{DECL_ARG_TYPE} is
729 @item DEBUG_EXPR_DECL
730 Used to represent an anonymous debug-information temporary created to
731 hold an expression as it is optimized away, so that its value can be
732 referenced in debug bind statements.
735 These nodes represent non-static data members. The @code{DECL_SIZE} and
736 @code{DECL_ALIGN} behave as for @code{VAR_DECL} nodes.
737 The position of the field within the parent record is specified by a
738 combination of three attributes. @code{DECL_FIELD_OFFSET} is the position,
739 counting in bytes, of the @code{DECL_OFFSET_ALIGN}-bit sized word containing
740 the bit of the field closest to the beginning of the structure.
741 @code{DECL_FIELD_BIT_OFFSET} is the bit offset of the first bit of the field
742 within this word; this may be nonzero even for fields that are not bit-fields,
743 since @code{DECL_OFFSET_ALIGN} may be greater than the natural alignment
746 If @code{DECL_C_BIT_FIELD} holds, this field is a bit-field. In a bit-field,
747 @code{DECL_BIT_FIELD_TYPE} also contains the type that was originally
748 specified for it, while DECL_TYPE may be a modified type with lesser precision,
749 according to the size of the bit field.
752 Namespaces provide a name hierarchy for other declarations. They
753 appear in the @code{DECL_CONTEXT} of other @code{_DECL} nodes.
757 @node Internal structure
758 @subsection Internal structure
760 @code{DECL} nodes are represented internally as a hierarchy of
764 * Current structure hierarchy:: The current DECL node structure
766 * Adding new DECL node types:: How to add a new DECL node to a
770 @node Current structure hierarchy
771 @subsubsection Current structure hierarchy
775 @item struct tree_decl_minimal
776 This is the minimal structure to inherit from in order for common
777 @code{DECL} macros to work. The fields it contains are a unique ID,
778 source location, context, and name.
780 @item struct tree_decl_common
781 This structure inherits from @code{struct tree_decl_minimal}. It
782 contains fields that most @code{DECL} nodes need, such as a field to
783 store alignment, machine mode, size, and attributes.
785 @item struct tree_field_decl
786 This structure inherits from @code{struct tree_decl_common}. It is
787 used to represent @code{FIELD_DECL}.
789 @item struct tree_label_decl
790 This structure inherits from @code{struct tree_decl_common}. It is
791 used to represent @code{LABEL_DECL}.
793 @item struct tree_translation_unit_decl
794 This structure inherits from @code{struct tree_decl_common}. It is
795 used to represent @code{TRANSLATION_UNIT_DECL}.
797 @item struct tree_decl_with_rtl
798 This structure inherits from @code{struct tree_decl_common}. It
799 contains a field to store the low-level RTL associated with a
802 @item struct tree_result_decl
803 This structure inherits from @code{struct tree_decl_with_rtl}. It is
804 used to represent @code{RESULT_DECL}.
806 @item struct tree_const_decl
807 This structure inherits from @code{struct tree_decl_with_rtl}. It is
808 used to represent @code{CONST_DECL}.
810 @item struct tree_parm_decl
811 This structure inherits from @code{struct tree_decl_with_rtl}. It is
812 used to represent @code{PARM_DECL}.
814 @item struct tree_decl_with_vis
815 This structure inherits from @code{struct tree_decl_with_rtl}. It
816 contains fields necessary to store visibility information, as well as
817 a section name and assembler name.
819 @item struct tree_var_decl
820 This structure inherits from @code{struct tree_decl_with_vis}. It is
821 used to represent @code{VAR_DECL}.
823 @item struct tree_function_decl
824 This structure inherits from @code{struct tree_decl_with_vis}. It is
825 used to represent @code{FUNCTION_DECL}.
828 @node Adding new DECL node types
829 @subsubsection Adding new DECL node types
831 Adding a new @code{DECL} tree consists of the following steps
835 @item Add a new tree code for the @code{DECL} node
836 For language specific @code{DECL} nodes, there is a @file{.def} file
837 in each frontend directory where the tree code should be added.
838 For @code{DECL} nodes that are part of the middle-end, the code should
839 be added to @file{tree.def}.
841 @item Create a new structure type for the @code{DECL} node
842 These structures should inherit from one of the existing structures in
843 the language hierarchy by using that structure as the first member.
848 struct tree_decl_with_vis common;
852 Would create a structure name @code{tree_foo_decl} that inherits from
853 @code{struct tree_decl_with_vis}.
855 For language specific @code{DECL} nodes, this new structure type
856 should go in the appropriate @file{.h} file.
857 For @code{DECL} nodes that are part of the middle-end, the structure
858 type should go in @file{tree.h}.
860 @item Add a member to the tree structure enumerator for the node
861 For garbage collection and dynamic checking purposes, each @code{DECL}
862 node structure type is required to have a unique enumerator value
864 For language specific @code{DECL} nodes, this new enumerator value
865 should go in the appropriate @file{.def} file.
866 For @code{DECL} nodes that are part of the middle-end, the enumerator
867 values are specified in @file{treestruct.def}.
869 @item Update @code{union tree_node}
870 In order to make your new structure type usable, it must be added to
871 @code{union tree_node}.
872 For language specific @code{DECL} nodes, a new entry should be added
873 to the appropriate @file{.h} file of the form
875 struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl;
877 For @code{DECL} nodes that are part of the middle-end, the additional
878 member goes directly into @code{union tree_node} in @file{tree.h}.
880 @item Update dynamic checking info
881 In order to be able to check whether accessing a named portion of
882 @code{union tree_node} is legal, and whether a certain @code{DECL} node
883 contains one of the enumerated @code{DECL} node structures in the
884 hierarchy, a simple lookup table is used.
885 This lookup table needs to be kept up to date with the tree structure
886 hierarchy, or else checking and containment macros will fail
889 For language specific @code{DECL} nodes, their is an @code{init_ts}
890 function in an appropriate @file{.c} file, which initializes the lookup
892 Code setting up the table for new @code{DECL} nodes should be added
894 For each @code{DECL} tree code and enumerator value representing a
895 member of the inheritance hierarchy, the table should contain 1 if
896 that tree code inherits (directly or indirectly) from that member.
897 Thus, a @code{FOO_DECL} node derived from @code{struct decl_with_rtl},
898 and enumerator value @code{TS_FOO_DECL}, would be set up as follows
900 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1;
901 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1;
902 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1;
903 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1;
906 For @code{DECL} nodes that are part of the middle-end, the setup code
907 goes into @file{tree.c}.
909 @item Add macros to access any new fields and flags
911 Each added field or flag should have a macro that is used to access
912 it, that performs appropriate checking to ensure only the right type of
913 @code{DECL} nodes access the field.
915 These macros generally take the following form
917 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname
919 However, if the structure is simply a base class for further
920 structures, something like the following should be used
922 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT)
923 #define BASE_STRUCT_FIELDNAME(NODE) \
924 (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname
930 @c ---------------------------------------------------------------------
932 @c ---------------------------------------------------------------------
934 @section Attributes in trees
937 Attributes, as specified using the @code{__attribute__} keyword, are
938 represented internally as a @code{TREE_LIST}. The @code{TREE_PURPOSE}
939 is the name of the attribute, as an @code{IDENTIFIER_NODE}. The
940 @code{TREE_VALUE} is a @code{TREE_LIST} of the arguments of the
941 attribute, if any, or @code{NULL_TREE} if there are no arguments; the
942 arguments are stored as the @code{TREE_VALUE} of successive entries in
943 the list, and may be identifiers or expressions. The @code{TREE_CHAIN}
944 of the attribute is the next attribute in a list of attributes applying
945 to the same declaration or type, or @code{NULL_TREE} if there are no
946 further attributes in the list.
948 Attributes may be attached to declarations and to types; these
949 attributes may be accessed with the following macros. All attributes
950 are stored in this way, and many also cause other changes to the
951 declaration or type or to other internal compiler data structures.
953 @deftypefn {Tree Macro} tree DECL_ATTRIBUTES (tree @var{decl})
954 This macro returns the attributes on the declaration @var{decl}.
957 @deftypefn {Tree Macro} tree TYPE_ATTRIBUTES (tree @var{type})
958 This macro returns the attributes on the type @var{type}.
962 @c ---------------------------------------------------------------------
964 @c ---------------------------------------------------------------------
966 @node Expression trees
972 The internal representation for expressions is for the most part quite
973 straightforward. However, there are a few facts that one must bear in
974 mind. In particular, the expression ``tree'' is actually a directed
975 acyclic graph. (For example there may be many references to the integer
976 constant zero throughout the source program; many of these will be
977 represented by the same expression node.) You should not rely on
978 certain kinds of node being shared, nor should you rely on certain kinds of
979 nodes being unshared.
981 The following macros can be used with all expression nodes:
985 Returns the type of the expression. This value may not be precisely the
986 same type that would be given the expression in the original program.
989 In what follows, some nodes that one might expect to always have type
990 @code{bool} are documented to have either integral or boolean type. At
991 some point in the future, the C front end may also make use of this same
992 intermediate representation, and at this point these nodes will
993 certainly have integral type. The previous sentence is not meant to
994 imply that the C++ front end does not or will not give these nodes
997 Below, we list the various kinds of expression nodes. Except where
998 noted otherwise, the operands to an expression are accessed using the
999 @code{TREE_OPERAND} macro. For example, to access the first operand to
1000 a binary plus expression @code{expr}, use:
1003 TREE_OPERAND (expr, 0)
1007 As this example indicates, the operands are zero-indexed.
1011 * Constants: Constant expressions.
1012 * Storage References::
1013 * Unary and Binary Expressions::
1017 @node Constant expressions
1018 @subsection Constant expressions
1020 @findex TREE_INT_CST_HIGH
1021 @findex TREE_INT_CST_LOW
1022 @findex tree_int_cst_lt
1023 @findex tree_int_cst_equal
1029 @findex TREE_STRING_LENGTH
1030 @findex TREE_STRING_POINTER
1032 The table below begins with constants, moves on to unary expressions,
1033 then proceeds to binary expressions, and concludes with various other
1034 kinds of expressions:
1038 These nodes represent integer constants. Note that the type of these
1039 constants is obtained with @code{TREE_TYPE}; they are not always of type
1040 @code{int}. In particular, @code{char} constants are represented with
1041 @code{INTEGER_CST} nodes. The value of the integer constant @code{e} is
1044 ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT)
1045 + TREE_INST_CST_LOW (e))
1048 HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms. Both
1049 @code{TREE_INT_CST_HIGH} and @code{TREE_INT_CST_LOW} return a
1050 @code{HOST_WIDE_INT}. The value of an @code{INTEGER_CST} is interpreted
1051 as a signed or unsigned quantity depending on the type of the constant.
1052 In general, the expression given above will overflow, so it should not
1053 be used to calculate the value of the constant.
1055 The variable @code{integer_zero_node} is an integer constant with value
1056 zero. Similarly, @code{integer_one_node} is an integer constant with
1057 value one. The @code{size_zero_node} and @code{size_one_node} variables
1058 are analogous, but have type @code{size_t} rather than @code{int}.
1060 The function @code{tree_int_cst_lt} is a predicate which holds if its
1061 first argument is less than its second. Both constants are assumed to
1062 have the same signedness (i.e., either both should be signed or both
1063 should be unsigned.) The full width of the constant is used when doing
1064 the comparison; the usual rules about promotions and conversions are
1065 ignored. Similarly, @code{tree_int_cst_equal} holds if the two
1066 constants are equal. The @code{tree_int_cst_sgn} function returns the
1067 sign of a constant. The value is @code{1}, @code{0}, or @code{-1}
1068 according on whether the constant is greater than, equal to, or less
1069 than zero. Again, the signedness of the constant's type is taken into
1070 account; an unsigned constant is never less than zero, no matter what
1075 FIXME: Talk about how to obtain representations of this constant, do
1076 comparisons, and so forth.
1080 These nodes represent fixed-point constants. The type of these constants
1081 is obtained with @code{TREE_TYPE}. @code{TREE_FIXED_CST_PTR} points to
1082 a @code{struct fixed_value}; @code{TREE_FIXED_CST} returns the structure
1083 itself. @code{struct fixed_value} contains @code{data} with the size of two
1084 @code{HOST_BITS_PER_WIDE_INT} and @code{mode} as the associated fixed-point
1085 machine mode for @code{data}.
1088 These nodes are used to represent complex number constants, that is a
1089 @code{__complex__} whose parts are constant nodes. The
1090 @code{TREE_REALPART} and @code{TREE_IMAGPART} return the real and the
1091 imaginary parts respectively.
1094 These nodes are used to represent vector constants, whose parts are
1095 constant nodes. Each individual constant node is either an integer or a
1096 double constant node. The first operand is a @code{TREE_LIST} of the
1097 constant nodes and is accessed through @code{TREE_VECTOR_CST_ELTS}.
1100 These nodes represent string-constants. The @code{TREE_STRING_LENGTH}
1101 returns the length of the string, as an @code{int}. The
1102 @code{TREE_STRING_POINTER} is a @code{char*} containing the string
1103 itself. The string may not be @code{NUL}-terminated, and it may contain
1104 embedded @code{NUL} characters. Therefore, the
1105 @code{TREE_STRING_LENGTH} includes the trailing @code{NUL} if it is
1108 For wide string constants, the @code{TREE_STRING_LENGTH} is the number
1109 of bytes in the string, and the @code{TREE_STRING_POINTER}
1110 points to an array of the bytes of the string, as represented on the
1111 target system (that is, as integers in the target endianness). Wide and
1112 non-wide string constants are distinguished only by the @code{TREE_TYPE}
1113 of the @code{STRING_CST}.
1115 FIXME: The formats of string constants are not well-defined when the
1116 target system bytes are not the same width as host system bytes.
1120 @node Storage References
1121 @subsection References to storage
1123 @tindex INDIRECT_REF
1126 @tindex ARRAY_RANGE_REF
1127 @tindex TARGET_MEM_REF
1128 @tindex COMPONENT_REF
1132 These nodes represent array accesses. The first operand is the array;
1133 the second is the index. To calculate the address of the memory
1134 accessed, you must scale the index by the size of the type of the array
1135 elements. The type of these expressions must be the type of a component of
1136 the array. The third and fourth operands are used after gimplification
1137 to represent the lower bound and component size but should not be used
1138 directly; call @code{array_ref_low_bound} and @code{array_ref_element_size}
1141 @item ARRAY_RANGE_REF
1142 These nodes represent access to a range (or ``slice'') of an array. The
1143 operands are the same as that for @code{ARRAY_REF} and have the same
1144 meanings. The type of these expressions must be an array whose component
1145 type is the same as that of the first operand. The range of that array
1146 type determines the amount of data these expressions access.
1148 @item TARGET_MEM_REF
1149 These nodes represent memory accesses whose address directly map to
1150 an addressing mode of the target architecture. The first argument
1151 is @code{TMR_SYMBOL} and must be a @code{VAR_DECL} of an object with
1152 a fixed address. The second argument is @code{TMR_BASE} and the
1153 third one is @code{TMR_INDEX}. The fourth argument is
1154 @code{TMR_STEP} and must be an @code{INTEGER_CST}. The fifth
1155 argument is @code{TMR_OFFSET} and must be an @code{INTEGER_CST}.
1156 Any of the arguments may be NULL if the appropriate component
1157 does not appear in the address. Address of the @code{TARGET_MEM_REF}
1158 is determined in the following way.
1161 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET
1164 The sixth argument is the reference to the original memory access, which
1165 is preserved for the purposes of the RTL alias analysis. The seventh
1166 argument is a tag representing the results of tree level alias analysis.
1169 These nodes are used to represent the address of an object. (These
1170 expressions will always have pointer or reference type.) The operand may
1171 be another expression, or it may be a declaration.
1173 As an extension, GCC allows users to take the address of a label. In
1174 this case, the operand of the @code{ADDR_EXPR} will be a
1175 @code{LABEL_DECL}. The type of such an expression is @code{void*}.
1177 If the object addressed is not an lvalue, a temporary is created, and
1178 the address of the temporary is used.
1181 These nodes are used to represent the object pointed to by a pointer.
1182 The operand is the pointer being dereferenced; it will always have
1183 pointer or reference type.
1186 These nodes are used to represent the object pointed to by a pointer
1187 offset by a constant.
1188 The first operand is the pointer being dereferenced; it will always have
1189 pointer or reference type. The second operand is a pointer constant.
1190 Its type is specifying the type to be used for type-based alias analysis.
1193 These nodes represent non-static data member accesses. The first
1194 operand is the object (rather than a pointer to it); the second operand
1195 is the @code{FIELD_DECL} for the data member. The third operand represents
1196 the byte offset of the field, but should not be used directly; call
1197 @code{component_ref_field_offset} instead.
1202 @node Unary and Binary Expressions
1203 @subsection Unary and Binary Expressions
1206 @tindex BIT_NOT_EXPR
1207 @tindex TRUTH_NOT_EXPR
1208 @tindex PREDECREMENT_EXPR
1209 @tindex PREINCREMENT_EXPR
1210 @tindex POSTDECREMENT_EXPR
1211 @tindex POSTINCREMENT_EXPR
1212 @tindex FIX_TRUNC_EXPR
1214 @tindex COMPLEX_EXPR
1216 @tindex REALPART_EXPR
1217 @tindex IMAGPART_EXPR
1218 @tindex NON_LVALUE_EXPR
1220 @tindex CONVERT_EXPR
1221 @tindex FIXED_CONVERT_EXPR
1225 @tindex BIT_IOR_EXPR
1226 @tindex BIT_XOR_EXPR
1227 @tindex BIT_AND_EXPR
1228 @tindex TRUTH_ANDIF_EXPR
1229 @tindex TRUTH_ORIF_EXPR
1230 @tindex TRUTH_AND_EXPR
1231 @tindex TRUTH_OR_EXPR
1232 @tindex TRUTH_XOR_EXPR
1233 @tindex POINTER_PLUS_EXPR
1237 @tindex MULT_HIGHPART_EXPR
1239 @tindex TRUNC_DIV_EXPR
1240 @tindex FLOOR_DIV_EXPR
1241 @tindex CEIL_DIV_EXPR
1242 @tindex ROUND_DIV_EXPR
1243 @tindex TRUNC_MOD_EXPR
1244 @tindex FLOOR_MOD_EXPR
1245 @tindex CEIL_MOD_EXPR
1246 @tindex ROUND_MOD_EXPR
1247 @tindex EXACT_DIV_EXPR
1254 @tindex ORDERED_EXPR
1255 @tindex UNORDERED_EXPR
1264 @tindex COMPOUND_EXPR
1271 @tindex CLEANUP_POINT_EXPR
1273 @tindex COMPOUND_LITERAL_EXPR
1280 These nodes represent unary negation of the single operand, for both
1281 integer and floating-point types. The type of negation can be
1282 determined by looking at the type of the expression.
1284 The behavior of this operation on signed arithmetic overflow is
1285 controlled by the @code{flag_wrapv} and @code{flag_trapv} variables.
1288 These nodes represent the absolute value of the single operand, for
1289 both integer and floating-point types. This is typically used to
1290 implement the @code{abs}, @code{labs} and @code{llabs} builtins for
1291 integer types, and the @code{fabs}, @code{fabsf} and @code{fabsl}
1292 builtins for floating point types. The type of abs operation can
1293 be determined by looking at the type of the expression.
1295 This node is not used for complex types. To represent the modulus
1296 or complex abs of a complex value, use the @code{BUILT_IN_CABS},
1297 @code{BUILT_IN_CABSF} or @code{BUILT_IN_CABSL} builtins, as used
1298 to implement the C99 @code{cabs}, @code{cabsf} and @code{cabsl}
1302 These nodes represent bitwise complement, and will always have integral
1303 type. The only operand is the value to be complemented.
1305 @item TRUTH_NOT_EXPR
1306 These nodes represent logical negation, and will always have integral
1307 (or boolean) type. The operand is the value being negated. The type
1308 of the operand and that of the result are always of @code{BOOLEAN_TYPE}
1309 or @code{INTEGER_TYPE}.
1311 @item PREDECREMENT_EXPR
1312 @itemx PREINCREMENT_EXPR
1313 @itemx POSTDECREMENT_EXPR
1314 @itemx POSTINCREMENT_EXPR
1315 These nodes represent increment and decrement expressions. The value of
1316 the single operand is computed, and the operand incremented or
1317 decremented. In the case of @code{PREDECREMENT_EXPR} and
1318 @code{PREINCREMENT_EXPR}, the value of the expression is the value
1319 resulting after the increment or decrement; in the case of
1320 @code{POSTDECREMENT_EXPR} and @code{POSTINCREMENT_EXPR} is the value
1321 before the increment or decrement occurs. The type of the operand, like
1322 that of the result, will be either integral, boolean, or floating-point.
1324 @item FIX_TRUNC_EXPR
1325 These nodes represent conversion of a floating-point value to an
1326 integer. The single operand will have a floating-point type, while
1327 the complete expression will have an integral (or boolean) type. The
1328 operand is rounded towards zero.
1331 These nodes represent conversion of an integral (or boolean) value to a
1332 floating-point value. The single operand will have integral type, while
1333 the complete expression will have a floating-point type.
1335 FIXME: How is the operand supposed to be rounded? Is this dependent on
1339 These nodes are used to represent complex numbers constructed from two
1340 expressions of the same (integer or real) type. The first operand is the
1341 real part and the second operand is the imaginary part.
1344 These nodes represent the conjugate of their operand.
1347 @itemx IMAGPART_EXPR
1348 These nodes represent respectively the real and the imaginary parts
1349 of complex numbers (their sole argument).
1351 @item NON_LVALUE_EXPR
1352 These nodes indicate that their one and only operand is not an lvalue.
1353 A back end can treat these identically to the single operand.
1356 These nodes are used to represent conversions that do not require any
1357 code-generation. For example, conversion of a @code{char*} to an
1358 @code{int*} does not require any code be generated; such a conversion is
1359 represented by a @code{NOP_EXPR}. The single operand is the expression
1360 to be converted. The conversion from a pointer to a reference is also
1361 represented with a @code{NOP_EXPR}.
1364 These nodes are similar to @code{NOP_EXPR}s, but are used in those
1365 situations where code may need to be generated. For example, if an
1366 @code{int*} is converted to an @code{int} code may need to be generated
1367 on some platforms. These nodes are never used for C++-specific
1368 conversions, like conversions between pointers to different classes in
1369 an inheritance hierarchy. Any adjustments that need to be made in such
1370 cases are always indicated explicitly. Similarly, a user-defined
1371 conversion is never represented by a @code{CONVERT_EXPR}; instead, the
1372 function calls are made explicit.
1374 @item FIXED_CONVERT_EXPR
1375 These nodes are used to represent conversions that involve fixed-point
1376 values. For example, from a fixed-point value to another fixed-point value,
1377 from an integer to a fixed-point value, from a fixed-point value to an
1378 integer, from a floating-point value to a fixed-point value, or from
1379 a fixed-point value to a floating-point value.
1383 These nodes represent left and right shifts, respectively. The first
1384 operand is the value to shift; it will always be of integral type. The
1385 second operand is an expression for the number of bits by which to
1386 shift. Right shift should be treated as arithmetic, i.e., the
1387 high-order bits should be zero-filled when the expression has unsigned
1388 type and filled with the sign bit when the expression has signed type.
1389 Note that the result is undefined if the second operand is larger
1390 than or equal to the first operand's type size. Unlike most nodes, these
1391 can have a vector as first operand and a scalar as second operand.
1397 These nodes represent bitwise inclusive or, bitwise exclusive or, and
1398 bitwise and, respectively. Both operands will always have integral
1401 @item TRUTH_ANDIF_EXPR
1402 @itemx TRUTH_ORIF_EXPR
1403 These nodes represent logical ``and'' and logical ``or'', respectively.
1404 These operators are not strict; i.e., the second operand is evaluated
1405 only if the value of the expression is not determined by evaluation of
1406 the first operand. The type of the operands and that of the result are
1407 always of @code{BOOLEAN_TYPE} or @code{INTEGER_TYPE}.
1409 @item TRUTH_AND_EXPR
1410 @itemx TRUTH_OR_EXPR
1411 @itemx TRUTH_XOR_EXPR
1412 These nodes represent logical and, logical or, and logical exclusive or.
1413 They are strict; both arguments are always evaluated. There are no
1414 corresponding operators in C or C++, but the front end will sometimes
1415 generate these expressions anyhow, if it can tell that strictness does
1416 not matter. The type of the operands and that of the result are
1417 always of @code{BOOLEAN_TYPE} or @code{INTEGER_TYPE}.
1419 @item POINTER_PLUS_EXPR
1420 This node represents pointer arithmetic. The first operand is always
1421 a pointer/reference type. The second operand is always an unsigned
1422 integer type compatible with sizetype. This is the only binary
1423 arithmetic operand that can operate on pointer types.
1428 These nodes represent various binary arithmetic operations.
1429 Respectively, these operations are addition, subtraction (of the second
1430 operand from the first) and multiplication. Their operands may have
1431 either integral or floating type, but there will never be case in which
1432 one operand is of floating type and the other is of integral type.
1434 The behavior of these operations on signed arithmetic overflow is
1435 controlled by the @code{flag_wrapv} and @code{flag_trapv} variables.
1437 @item MULT_HIGHPART_EXPR
1438 This node represents the ``high-part'' of a widening multiplication.
1439 For an integral type with @var{b} bits of precision, the result is
1440 the most significant @var{b} bits of the full @math{2@var{b}} product.
1443 This node represents a floating point division operation.
1445 @item TRUNC_DIV_EXPR
1446 @itemx FLOOR_DIV_EXPR
1447 @itemx CEIL_DIV_EXPR
1448 @itemx ROUND_DIV_EXPR
1449 These nodes represent integer division operations that return an integer
1450 result. @code{TRUNC_DIV_EXPR} rounds towards zero, @code{FLOOR_DIV_EXPR}
1451 rounds towards negative infinity, @code{CEIL_DIV_EXPR} rounds towards
1452 positive infinity and @code{ROUND_DIV_EXPR} rounds to the closest integer.
1453 Integer division in C and C++ is truncating, i.e.@: @code{TRUNC_DIV_EXPR}.
1455 The behavior of these operations on signed arithmetic overflow, when
1456 dividing the minimum signed integer by minus one, is controlled by the
1457 @code{flag_wrapv} and @code{flag_trapv} variables.
1459 @item TRUNC_MOD_EXPR
1460 @itemx FLOOR_MOD_EXPR
1461 @itemx CEIL_MOD_EXPR
1462 @itemx ROUND_MOD_EXPR
1463 These nodes represent the integer remainder or modulus operation.
1464 The integer modulus of two operands @code{a} and @code{b} is
1465 defined as @code{a - (a/b)*b} where the division calculated using
1466 the corresponding division operator. Hence for @code{TRUNC_MOD_EXPR}
1467 this definition assumes division using truncation towards zero, i.e.@:
1468 @code{TRUNC_DIV_EXPR}. Integer remainder in C and C++ uses truncating
1469 division, i.e.@: @code{TRUNC_MOD_EXPR}.
1471 @item EXACT_DIV_EXPR
1472 The @code{EXACT_DIV_EXPR} code is used to represent integer divisions where
1473 the numerator is known to be an exact multiple of the denominator. This
1474 allows the backend to choose between the faster of @code{TRUNC_DIV_EXPR},
1475 @code{CEIL_DIV_EXPR} and @code{FLOOR_DIV_EXPR} for the current target.
1483 These nodes represent the less than, less than or equal to, greater
1484 than, greater than or equal to, equal, and not equal comparison
1485 operators. The first and second operands will either be both of integral
1486 type, both of floating type or both of vector type. The result type of
1487 these expressions will always be of integral, boolean or signed integral
1488 vector type. These operations return the result type's zero value for
1489 false, the result type's one value for true, and a vector whose elements
1490 are zero (false) or minus one (true) for vectors.
1492 For floating point comparisons, if we honor IEEE NaNs and either operand
1493 is NaN, then @code{NE_EXPR} always returns true and the remaining operators
1494 always return false. On some targets, comparisons against an IEEE NaN,
1495 other than equality and inequality, may generate a floating point exception.
1498 @itemx UNORDERED_EXPR
1499 These nodes represent non-trapping ordered and unordered comparison
1500 operators. These operations take two floating point operands and
1501 determine whether they are ordered or unordered relative to each other.
1502 If either operand is an IEEE NaN, their comparison is defined to be
1503 unordered, otherwise the comparison is defined to be ordered. The
1504 result type of these expressions will always be of integral or boolean
1505 type. These operations return the result type's zero value for false,
1506 and the result type's one value for true.
1514 These nodes represent the unordered comparison operators.
1515 These operations take two floating point operands and determine whether
1516 the operands are unordered or are less than, less than or equal to,
1517 greater than, greater than or equal to, or equal respectively. For
1518 example, @code{UNLT_EXPR} returns true if either operand is an IEEE
1519 NaN or the first operand is less than the second. With the possible
1520 exception of @code{LTGT_EXPR}, all of these operations are guaranteed
1521 not to generate a floating point exception. The result
1522 type of these expressions will always be of integral or boolean type.
1523 These operations return the result type's zero value for false,
1524 and the result type's one value for true.
1527 These nodes represent assignment. The left-hand side is the first
1528 operand; the right-hand side is the second operand. The left-hand side
1529 will be a @code{VAR_DECL}, @code{INDIRECT_REF}, @code{COMPONENT_REF}, or
1532 These nodes are used to represent not only assignment with @samp{=} but
1533 also compound assignments (like @samp{+=}), by reduction to @samp{=}
1534 assignment. In other words, the representation for @samp{i += 3} looks
1535 just like that for @samp{i = i + 3}.
1538 These nodes are just like @code{MODIFY_EXPR}, but are used only when a
1539 variable is initialized, rather than assigned to subsequently. This
1540 means that we can assume that the target of the initialization is not
1541 used in computing its own value; any reference to the lhs in computing
1542 the rhs is undefined.
1545 These nodes represent comma-expressions. The first operand is an
1546 expression whose value is computed and thrown away prior to the
1547 evaluation of the second operand. The value of the entire expression is
1548 the value of the second operand.
1551 These nodes represent @code{?:} expressions. The first operand
1552 is of boolean or integral type. If it evaluates to a nonzero value,
1553 the second operand should be evaluated, and returned as the value of the
1554 expression. Otherwise, the third operand is evaluated, and returned as
1555 the value of the expression.
1557 The second operand must have the same type as the entire expression,
1558 unless it unconditionally throws an exception or calls a noreturn
1559 function, in which case it should have void type. The same constraints
1560 apply to the third operand. This allows array bounds checks to be
1561 represented conveniently as @code{(i >= 0 && i < 10) ? i : abort()}.
1563 As a GNU extension, the C language front-ends allow the second
1564 operand of the @code{?:} operator may be omitted in the source.
1565 For example, @code{x ? : 3} is equivalent to @code{x ? x : 3},
1566 assuming that @code{x} is an expression without side-effects.
1567 In the tree representation, however, the second operand is always
1568 present, possibly protected by @code{SAVE_EXPR} if the first
1569 argument does cause side-effects.
1572 These nodes are used to represent calls to functions, including
1573 non-static member functions. @code{CALL_EXPR}s are implemented as
1574 expression nodes with a variable number of operands. Rather than using
1575 @code{TREE_OPERAND} to extract them, it is preferable to use the
1576 specialized accessor macros and functions that operate specifically on
1577 @code{CALL_EXPR} nodes.
1579 @code{CALL_EXPR_FN} returns a pointer to the
1580 function to call; it is always an expression whose type is a
1581 @code{POINTER_TYPE}.
1583 The number of arguments to the call is returned by @code{call_expr_nargs},
1584 while the arguments themselves can be accessed with the @code{CALL_EXPR_ARG}
1585 macro. The arguments are zero-indexed and numbered left-to-right.
1586 You can iterate over the arguments using @code{FOR_EACH_CALL_EXPR_ARG}, as in:
1590 call_expr_arg_iterator iter;
1591 FOR_EACH_CALL_EXPR_ARG (arg, iter, call)
1592 /* arg is bound to successive arguments of call. */
1597 member functions, there will be an operand corresponding to the
1598 @code{this} pointer. There will always be expressions corresponding to
1599 all of the arguments, even if the function is declared with default
1600 arguments and some arguments are not explicitly provided at the call
1603 @code{CALL_EXPR}s also have a @code{CALL_EXPR_STATIC_CHAIN} operand that
1604 is used to implement nested functions. This operand is otherwise null.
1606 @item CLEANUP_POINT_EXPR
1607 These nodes represent full-expressions. The single operand is an
1608 expression to evaluate. Any destructor calls engendered by the creation
1609 of temporaries during the evaluation of that expression should be
1610 performed immediately after the expression is evaluated.
1613 These nodes represent the brace-enclosed initializers for a structure or
1614 array. The first operand is reserved for use by the back end. The
1615 second operand is a @code{TREE_LIST}. If the @code{TREE_TYPE} of the
1616 @code{CONSTRUCTOR} is a @code{RECORD_TYPE} or @code{UNION_TYPE}, then
1617 the @code{TREE_PURPOSE} of each node in the @code{TREE_LIST} will be a
1618 @code{FIELD_DECL} and the @code{TREE_VALUE} of each node will be the
1619 expression used to initialize that field.
1621 If the @code{TREE_TYPE} of the @code{CONSTRUCTOR} is an
1622 @code{ARRAY_TYPE}, then the @code{TREE_PURPOSE} of each element in the
1623 @code{TREE_LIST} will be an @code{INTEGER_CST} or a @code{RANGE_EXPR} of
1624 two @code{INTEGER_CST}s. A single @code{INTEGER_CST} indicates which
1625 element of the array (indexed from zero) is being assigned to. A
1626 @code{RANGE_EXPR} indicates an inclusive range of elements to
1627 initialize. In both cases the @code{TREE_VALUE} is the corresponding
1628 initializer. It is re-evaluated for each element of a
1629 @code{RANGE_EXPR}. If the @code{TREE_PURPOSE} is @code{NULL_TREE}, then
1630 the initializer is for the next available array element.
1632 In the front end, you should not depend on the fields appearing in any
1633 particular order. However, in the middle end, fields must appear in
1634 declaration order. You should not assume that all fields will be
1635 represented. Unrepresented fields will be set to zero.
1637 @item COMPOUND_LITERAL_EXPR
1638 @findex COMPOUND_LITERAL_EXPR_DECL_EXPR
1639 @findex COMPOUND_LITERAL_EXPR_DECL
1640 These nodes represent ISO C99 compound literals. The
1641 @code{COMPOUND_LITERAL_EXPR_DECL_EXPR} is a @code{DECL_EXPR}
1642 containing an anonymous @code{VAR_DECL} for
1643 the unnamed object represented by the compound literal; the
1644 @code{DECL_INITIAL} of that @code{VAR_DECL} is a @code{CONSTRUCTOR}
1645 representing the brace-enclosed list of initializers in the compound
1646 literal. That anonymous @code{VAR_DECL} can also be accessed directly
1647 by the @code{COMPOUND_LITERAL_EXPR_DECL} macro.
1651 A @code{SAVE_EXPR} represents an expression (possibly involving
1652 side-effects) that is used more than once. The side-effects should
1653 occur only the first time the expression is evaluated. Subsequent uses
1654 should just reuse the computed value. The first operand to the
1655 @code{SAVE_EXPR} is the expression to evaluate. The side-effects should
1656 be executed where the @code{SAVE_EXPR} is first encountered in a
1657 depth-first preorder traversal of the expression tree.
1660 A @code{TARGET_EXPR} represents a temporary object. The first operand
1661 is a @code{VAR_DECL} for the temporary variable. The second operand is
1662 the initializer for the temporary. The initializer is evaluated and,
1663 if non-void, copied (bitwise) into the temporary. If the initializer
1664 is void, that means that it will perform the initialization itself.
1666 Often, a @code{TARGET_EXPR} occurs on the right-hand side of an
1667 assignment, or as the second operand to a comma-expression which is
1668 itself the right-hand side of an assignment, etc. In this case, we say
1669 that the @code{TARGET_EXPR} is ``normal''; otherwise, we say it is
1670 ``orphaned''. For a normal @code{TARGET_EXPR} the temporary variable
1671 should be treated as an alias for the left-hand side of the assignment,
1672 rather than as a new temporary variable.
1674 The third operand to the @code{TARGET_EXPR}, if present, is a
1675 cleanup-expression (i.e., destructor call) for the temporary. If this
1676 expression is orphaned, then this expression must be executed when the
1677 statement containing this expression is complete. These cleanups must
1678 always be executed in the order opposite to that in which they were
1679 encountered. Note that if a temporary is created on one branch of a
1680 conditional operator (i.e., in the second or third operand to a
1681 @code{COND_EXPR}), the cleanup must be run only if that branch is
1685 This node is used to implement support for the C/C++ variable argument-list
1686 mechanism. It represents expressions like @code{va_arg (ap, type)}.
1687 Its @code{TREE_TYPE} yields the tree representation for @code{type} and
1688 its sole argument yields the representation for @code{ap}.
1694 @tindex VEC_LSHIFT_EXPR
1695 @tindex VEC_RSHIFT_EXPR
1696 @tindex VEC_WIDEN_MULT_HI_EXPR
1697 @tindex VEC_WIDEN_MULT_LO_EXPR
1698 @tindex VEC_UNPACK_HI_EXPR
1699 @tindex VEC_UNPACK_LO_EXPR
1700 @tindex VEC_UNPACK_FLOAT_HI_EXPR
1701 @tindex VEC_UNPACK_FLOAT_LO_EXPR
1702 @tindex VEC_PACK_TRUNC_EXPR
1703 @tindex VEC_PACK_SAT_EXPR
1704 @tindex VEC_PACK_FIX_TRUNC_EXPR
1707 @item VEC_LSHIFT_EXPR
1708 @itemx VEC_RSHIFT_EXPR
1709 These nodes represent whole vector left and right shifts, respectively.
1710 The first operand is the vector to shift; it will always be of vector type.
1711 The second operand is an expression for the number of bits by which to
1712 shift. Note that the result is undefined if the second operand is larger
1713 than or equal to the first operand's type size.
1715 @item VEC_WIDEN_MULT_HI_EXPR
1716 @itemx VEC_WIDEN_MULT_LO_EXPR
1717 These nodes represent widening vector multiplication of the high and low
1718 parts of the two input vectors, respectively. Their operands are vectors
1719 that contain the same number of elements (@code{N}) of the same integral type.
1720 The result is a vector that contains half as many elements, of an integral type
1721 whose size is twice as wide. In the case of @code{VEC_WIDEN_MULT_HI_EXPR} the
1722 high @code{N/2} elements of the two vector are multiplied to produce the
1723 vector of @code{N/2} products. In the case of @code{VEC_WIDEN_MULT_LO_EXPR} the
1724 low @code{N/2} elements of the two vector are multiplied to produce the
1725 vector of @code{N/2} products.
1727 @item VEC_UNPACK_HI_EXPR
1728 @itemx VEC_UNPACK_LO_EXPR
1729 These nodes represent unpacking of the high and low parts of the input vector,
1730 respectively. The single operand is a vector that contains @code{N} elements
1731 of the same integral or floating point type. The result is a vector
1732 that contains half as many elements, of an integral or floating point type
1733 whose size is twice as wide. In the case of @code{VEC_UNPACK_HI_EXPR} the
1734 high @code{N/2} elements of the vector are extracted and widened (promoted).
1735 In the case of @code{VEC_UNPACK_LO_EXPR} the low @code{N/2} elements of the
1736 vector are extracted and widened (promoted).
1738 @item VEC_UNPACK_FLOAT_HI_EXPR
1739 @itemx VEC_UNPACK_FLOAT_LO_EXPR
1740 These nodes represent unpacking of the high and low parts of the input vector,
1741 where the values are converted from fixed point to floating point. The
1742 single operand is a vector that contains @code{N} elements of the same
1743 integral type. The result is a vector that contains half as many elements
1744 of a floating point type whose size is twice as wide. In the case of
1745 @code{VEC_UNPACK_HI_EXPR} the high @code{N/2} elements of the vector are
1746 extracted, converted and widened. In the case of @code{VEC_UNPACK_LO_EXPR}
1747 the low @code{N/2} elements of the vector are extracted, converted and widened.
1749 @item VEC_PACK_TRUNC_EXPR
1750 This node represents packing of truncated elements of the two input vectors
1751 into the output vector. Input operands are vectors that contain the same
1752 number of elements of the same integral or floating point type. The result
1753 is a vector that contains twice as many elements of an integral or floating
1754 point type whose size is half as wide. The elements of the two vectors are
1755 demoted and merged (concatenated) to form the output vector.
1757 @item VEC_PACK_SAT_EXPR
1758 This node represents packing of elements of the two input vectors into the
1759 output vector using saturation. Input operands are vectors that contain
1760 the same number of elements of the same integral type. The result is a
1761 vector that contains twice as many elements of an integral type whose size
1762 is half as wide. The elements of the two vectors are demoted and merged
1763 (concatenated) to form the output vector.
1765 @item VEC_PACK_FIX_TRUNC_EXPR
1766 This node represents packing of elements of the two input vectors into the
1767 output vector, where the values are converted from floating point
1768 to fixed point. Input operands are vectors that contain the same number
1769 of elements of a floating point type. The result is a vector that contains
1770 twice as many elements of an integral type whose size is half as wide. The
1771 elements of the two vectors are merged (concatenated) to form the output
1775 These nodes represent @code{?:} expressions. The three operands must be
1776 vectors of the same size and number of elements. The second and third
1777 operands must have the same type as the entire expression. The first
1778 operand is of signed integral vector type. If an element of the first
1779 operand evaluates to a zero value, the corresponding element of the
1780 result is taken from the third operand. If it evaluates to a minus one
1781 value, it is taken from the second operand. It should never evaluate to
1782 any other value currently, but optimizations should not rely on that
1783 property. In contrast with a @code{COND_EXPR}, all operands are always
1788 @c ---------------------------------------------------------------------
1790 @c ---------------------------------------------------------------------
1796 Most statements in GIMPLE are assignment statements, represented by
1797 @code{GIMPLE_ASSIGN}. No other C expressions can appear at statement level;
1798 a reference to a volatile object is converted into a
1799 @code{GIMPLE_ASSIGN}.
1801 There are also several varieties of complex statements.
1804 * Basic Statements::
1806 * Statement Sequences::
1807 * Empty Statements::
1813 @node Basic Statements
1814 @subsection Basic Statements
1815 @cindex Basic Statements
1820 Used to represent an inline assembly statement. For an inline assembly
1825 The @code{ASM_STRING} macro will return a @code{STRING_CST} node for
1826 @code{"mov x, y"}. If the original statement made use of the
1827 extended-assembly syntax, then @code{ASM_OUTPUTS},
1828 @code{ASM_INPUTS}, and @code{ASM_CLOBBERS} will be the outputs, inputs,
1829 and clobbers for the statement, represented as @code{STRING_CST} nodes.
1830 The extended-assembly syntax looks like:
1832 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
1834 The first string is the @code{ASM_STRING}, containing the instruction
1835 template. The next two strings are the output and inputs, respectively;
1836 this statement has no clobbers. As this example indicates, ``plain''
1837 assembly statements are merely a special case of extended assembly
1838 statements; they have no cv-qualifiers, outputs, inputs, or clobbers.
1839 All of the strings will be @code{NUL}-terminated, and will contain no
1840 embedded @code{NUL}-characters.
1842 If the assembly statement is declared @code{volatile}, or if the
1843 statement was not an extended assembly statement, and is therefore
1844 implicitly volatile, then the predicate @code{ASM_VOLATILE_P} will hold
1845 of the @code{ASM_EXPR}.
1849 Used to represent a local declaration. The @code{DECL_EXPR_DECL} macro
1850 can be used to obtain the entity declared. This declaration may be a
1851 @code{LABEL_DECL}, indicating that the label declared is a local label.
1852 (As an extension, GCC allows the declaration of labels with scope.) In
1853 C, this declaration may be a @code{FUNCTION_DECL}, indicating the
1854 use of the GCC nested function extension. For more information,
1859 Used to represent a label. The @code{LABEL_DECL} declared by this
1860 statement can be obtained with the @code{LABEL_EXPR_LABEL} macro. The
1861 @code{IDENTIFIER_NODE} giving the name of the label can be obtained from
1862 the @code{LABEL_DECL} with @code{DECL_NAME}.
1866 Used to represent a @code{goto} statement. The @code{GOTO_DESTINATION} will
1867 usually be a @code{LABEL_DECL}. However, if the ``computed goto'' extension
1868 has been used, the @code{GOTO_DESTINATION} will be an arbitrary expression
1869 indicating the destination. This expression will always have pointer type.
1873 Used to represent a @code{return} statement. Operand 0 represents the
1874 value to return. It should either be the @code{RESULT_DECL} for the
1875 containing function, or a @code{MODIFY_EXPR} or @code{INIT_EXPR}
1876 setting the function's @code{RESULT_DECL}. It will be
1877 @code{NULL_TREE} if the statement was just
1883 These nodes represent ``infinite'' loops. The @code{LOOP_EXPR_BODY}
1884 represents the body of the loop. It should be executed forever, unless
1885 an @code{EXIT_EXPR} is encountered.
1888 These nodes represent conditional exits from the nearest enclosing
1889 @code{LOOP_EXPR}. The single operand is the condition; if it is
1890 nonzero, then the loop should be exited. An @code{EXIT_EXPR} will only
1891 appear within a @code{LOOP_EXPR}.
1895 Used to represent a @code{switch} statement. The @code{SWITCH_STMT_COND}
1896 is the expression on which the switch is occurring. See the documentation
1897 for an @code{IF_STMT} for more information on the representation used
1898 for the condition. The @code{SWITCH_STMT_BODY} is the body of the switch
1899 statement. The @code{SWITCH_STMT_TYPE} is the original type of switch
1900 expression as given in the source, before any compiler conversions.
1902 @item CASE_LABEL_EXPR
1904 Use to represent a @code{case} label, range of @code{case} labels, or a
1905 @code{default} label. If @code{CASE_LOW} is @code{NULL_TREE}, then this is a
1906 @code{default} label. Otherwise, if @code{CASE_HIGH} is @code{NULL_TREE}, then
1907 this is an ordinary @code{case} label. In this case, @code{CASE_LOW} is
1908 an expression giving the value of the label. Both @code{CASE_LOW} and
1909 @code{CASE_HIGH} are @code{INTEGER_CST} nodes. These values will have
1910 the same type as the condition expression in the switch statement.
1912 Otherwise, if both @code{CASE_LOW} and @code{CASE_HIGH} are defined, the
1913 statement is a range of case labels. Such statements originate with the
1914 extension that allows users to write things of the form:
1918 The first value will be @code{CASE_LOW}, while the second will be
1928 Block scopes and the variables they declare in GENERIC are
1929 expressed using the @code{BIND_EXPR} code, which in previous
1930 versions of GCC was primarily used for the C statement-expression
1933 Variables in a block are collected into @code{BIND_EXPR_VARS} in
1934 declaration order through their @code{TREE_CHAIN} field. Any runtime
1935 initialization is moved out of @code{DECL_INITIAL} and into a
1936 statement in the controlled block. When gimplifying from C or C++,
1937 this initialization replaces the @code{DECL_STMT}. These variables
1938 will never require cleanups. The scope of these variables is just the
1941 Variable-length arrays (VLAs) complicate this process, as their
1942 size often refers to variables initialized earlier in the block.
1943 To handle this, we currently split the block at that point, and
1944 move the VLA into a new, inner @code{BIND_EXPR}. This strategy
1945 may change in the future.
1947 A C++ program will usually contain more @code{BIND_EXPR}s than
1948 there are syntactic blocks in the source code, since several C++
1949 constructs have implicit scopes associated with them. On the
1950 other hand, although the C++ front end uses pseudo-scopes to
1951 handle cleanups for objects with destructors, these don't
1952 translate into the GIMPLE form; multiple declarations at the same
1953 level use the same @code{BIND_EXPR}.
1955 @node Statement Sequences
1956 @subsection Statement Sequences
1957 @cindex Statement Sequences
1959 Multiple statements at the same nesting level are collected into
1960 a @code{STATEMENT_LIST}. Statement lists are modified and
1961 traversed using the interface in @samp{tree-iterator.h}.
1963 @node Empty Statements
1964 @subsection Empty Statements
1965 @cindex Empty Statements
1967 Whenever possible, statements with no effect are discarded. But
1968 if they are nested within another construct which cannot be
1969 discarded for some reason, they are instead replaced with an
1970 empty statement, generated by @code{build_empty_stmt}.
1971 Initially, all empty statements were shared, after the pattern of
1972 the Java front end, but this caused a lot of trouble in practice.
1974 An empty statement is represented as @code{(void)0}.
1980 Other jumps are expressed by either @code{GOTO_EXPR} or
1983 The operand of a @code{GOTO_EXPR} must be either a label or a
1984 variable containing the address to jump to.
1986 The operand of a @code{RETURN_EXPR} is either @code{NULL_TREE},
1987 @code{RESULT_DECL}, or a @code{MODIFY_EXPR} which sets the return
1988 value. It would be nice to move the @code{MODIFY_EXPR} into a
1989 separate statement, but the special return semantics in
1990 @code{expand_return} make that difficult. It may still happen in
1991 the future, perhaps by moving most of that logic into
1992 @code{expand_assignment}.
1995 @subsection Cleanups
1998 Destructors for local C++ objects and similar dynamic cleanups are
1999 represented in GIMPLE by a @code{TRY_FINALLY_EXPR}.
2000 @code{TRY_FINALLY_EXPR} has two operands, both of which are a sequence
2001 of statements to execute. The first sequence is executed. When it
2002 completes the second sequence is executed.
2004 The first sequence may complete in the following ways:
2008 @item Execute the last statement in the sequence and fall off the
2011 @item Execute a goto statement (@code{GOTO_EXPR}) to an ordinary
2012 label outside the sequence.
2014 @item Execute a return statement (@code{RETURN_EXPR}).
2016 @item Throw an exception. This is currently not explicitly represented in
2021 The second sequence is not executed if the first sequence completes by
2022 calling @code{setjmp} or @code{exit} or any other function that does
2023 not return. The second sequence is also not executed if the first
2024 sequence completes via a non-local goto or a computed goto (in general
2025 the compiler does not know whether such a goto statement exits the
2026 first sequence or not, so we assume that it doesn't).
2028 After the second sequence is executed, if it completes normally by
2029 falling off the end, execution continues wherever the first sequence
2030 would have continued, by falling off the end, or doing a goto, etc.
2032 @code{TRY_FINALLY_EXPR} complicates the flow graph, since the cleanup
2033 needs to appear on every edge out of the controlled block; this
2034 reduces the freedom to move code across these edges. Therefore, the
2035 EH lowering pass which runs before most of the optimization passes
2036 eliminates these expressions by explicitly adding the cleanup to each
2037 edge. Rethrowing the exception is represented using @code{RESX_EXPR}.
2041 @tindex OMP_PARALLEL
2043 @tindex OMP_SECTIONS
2048 @tindex OMP_CRITICAL
2050 @tindex OMP_CONTINUE
2054 All the statements starting with @code{OMP_} represent directives and
2055 clauses used by the OpenMP API @w{@uref{http://www.openmp.org/}}.
2060 Represents @code{#pragma omp parallel [clause1 @dots{} clauseN]}. It
2063 Operand @code{OMP_PARALLEL_BODY} is valid while in GENERIC and
2064 High GIMPLE forms. It contains the body of code to be executed
2065 by all the threads. During GIMPLE lowering, this operand becomes
2066 @code{NULL} and the body is emitted linearly after
2067 @code{OMP_PARALLEL}.
2069 Operand @code{OMP_PARALLEL_CLAUSES} is the list of clauses
2070 associated with the directive.
2072 Operand @code{OMP_PARALLEL_FN} is created by
2073 @code{pass_lower_omp}, it contains the @code{FUNCTION_DECL}
2074 for the function that will contain the body of the parallel
2077 Operand @code{OMP_PARALLEL_DATA_ARG} is also created by
2078 @code{pass_lower_omp}. If there are shared variables to be
2079 communicated to the children threads, this operand will contain
2080 the @code{VAR_DECL} that contains all the shared values and
2085 Represents @code{#pragma omp for [clause1 @dots{} clauseN]}. It
2088 Operand @code{OMP_FOR_BODY} contains the loop body.
2090 Operand @code{OMP_FOR_CLAUSES} is the list of clauses
2091 associated with the directive.
2093 Operand @code{OMP_FOR_INIT} is the loop initialization code of
2094 the form @code{VAR = N1}.
2096 Operand @code{OMP_FOR_COND} is the loop conditional expression
2097 of the form @code{VAR @{<,>,<=,>=@} N2}.
2099 Operand @code{OMP_FOR_INCR} is the loop index increment of the
2100 form @code{VAR @{+=,-=@} INCR}.
2102 Operand @code{OMP_FOR_PRE_BODY} contains side-effect code from
2103 operands @code{OMP_FOR_INIT}, @code{OMP_FOR_COND} and
2104 @code{OMP_FOR_INC}. These side-effects are part of the
2105 @code{OMP_FOR} block but must be evaluated before the start of
2108 The loop index variable @code{VAR} must be a signed integer variable,
2109 which is implicitly private to each thread. Bounds
2110 @code{N1} and @code{N2} and the increment expression
2111 @code{INCR} are required to be loop invariant integer
2112 expressions that are evaluated without any synchronization. The
2113 evaluation order, frequency of evaluation and side-effects are
2114 unspecified by the standard.
2118 Represents @code{#pragma omp sections [clause1 @dots{} clauseN]}.
2120 Operand @code{OMP_SECTIONS_BODY} contains the sections body,
2121 which in turn contains a set of @code{OMP_SECTION} nodes for
2122 each of the concurrent sections delimited by @code{#pragma omp
2125 Operand @code{OMP_SECTIONS_CLAUSES} is the list of clauses
2126 associated with the directive.
2130 Section delimiter for @code{OMP_SECTIONS}.
2134 Represents @code{#pragma omp single}.
2136 Operand @code{OMP_SINGLE_BODY} contains the body of code to be
2137 executed by a single thread.
2139 Operand @code{OMP_SINGLE_CLAUSES} is the list of clauses
2140 associated with the directive.
2144 Represents @code{#pragma omp master}.
2146 Operand @code{OMP_MASTER_BODY} contains the body of code to be
2147 executed by the master thread.
2151 Represents @code{#pragma omp ordered}.
2153 Operand @code{OMP_ORDERED_BODY} contains the body of code to be
2154 executed in the sequential order dictated by the loop index
2159 Represents @code{#pragma omp critical [name]}.
2161 Operand @code{OMP_CRITICAL_BODY} is the critical section.
2163 Operand @code{OMP_CRITICAL_NAME} is an optional identifier to
2164 label the critical section.
2168 This does not represent any OpenMP directive, it is an artificial
2169 marker to indicate the end of the body of an OpenMP@. It is used
2170 by the flow graph (@code{tree-cfg.c}) and OpenMP region
2171 building code (@code{omp-low.c}).
2175 Similarly, this instruction does not represent an OpenMP
2176 directive, it is used by @code{OMP_FOR} and
2177 @code{OMP_SECTIONS} to mark the place where the code needs to
2178 loop to the next iteration (in the case of @code{OMP_FOR}) or
2179 the next section (in the case of @code{OMP_SECTIONS}).
2181 In some cases, @code{OMP_CONTINUE} is placed right before
2182 @code{OMP_RETURN}. But if there are cleanups that need to
2183 occur right after the looping body, it will be emitted between
2184 @code{OMP_CONTINUE} and @code{OMP_RETURN}.
2188 Represents @code{#pragma omp atomic}.
2190 Operand 0 is the address at which the atomic operation is to be
2193 Operand 1 is the expression to evaluate. The gimplifier tries
2194 three alternative code generation strategies. Whenever possible,
2195 an atomic update built-in is used. If that fails, a
2196 compare-and-swap loop is attempted. If that also fails, a
2197 regular critical section around the expression is used.
2201 Represents clauses associated with one of the @code{OMP_} directives.
2202 Clauses are represented by separate sub-codes defined in
2203 @file{tree.h}. Clauses codes can be one of:
2204 @code{OMP_CLAUSE_PRIVATE}, @code{OMP_CLAUSE_SHARED},
2205 @code{OMP_CLAUSE_FIRSTPRIVATE},
2206 @code{OMP_CLAUSE_LASTPRIVATE}, @code{OMP_CLAUSE_COPYIN},
2207 @code{OMP_CLAUSE_COPYPRIVATE}, @code{OMP_CLAUSE_IF},
2208 @code{OMP_CLAUSE_NUM_THREADS}, @code{OMP_CLAUSE_SCHEDULE},
2209 @code{OMP_CLAUSE_NOWAIT}, @code{OMP_CLAUSE_ORDERED},
2210 @code{OMP_CLAUSE_DEFAULT}, @code{OMP_CLAUSE_REDUCTION},
2211 @code{OMP_CLAUSE_COLLAPSE}, @code{OMP_CLAUSE_UNTIED},
2212 @code{OMP_CLAUSE_FINAL}, and @code{OMP_CLAUSE_MERGEABLE}. Each code
2213 represents the corresponding OpenMP clause.
2215 Clauses associated with the same directive are chained together
2216 via @code{OMP_CLAUSE_CHAIN}. Those clauses that accept a list
2217 of variables are restricted to exactly one, accessed with
2218 @code{OMP_CLAUSE_VAR}. Therefore, multiple variables under the
2219 same clause @code{C} need to be represented as multiple @code{C} clauses
2220 chained together. This facilitates adding new clauses during
2225 @c ---------------------------------------------------------------------
2227 @c ---------------------------------------------------------------------
2232 @tindex FUNCTION_DECL
2234 A function is represented by a @code{FUNCTION_DECL} node. It stores
2235 the basic pieces of the function such as body, parameters, and return
2236 type as well as information on the surrounding context, visibility,
2240 * Function Basics:: Function names, body, and parameters.
2241 * Function Properties:: Context, linkage, etc.
2244 @c ---------------------------------------------------------------------
2246 @c ---------------------------------------------------------------------
2248 @node Function Basics
2249 @subsection Function Basics
2251 @findex DECL_ASSEMBLER_NAME
2253 @findex DECL_ARTIFICIAL
2254 @findex DECL_FUNCTION_SPECIFIC_TARGET
2255 @findex DECL_FUNCTION_SPECIFIC_OPTIMIZATION
2257 A function has four core parts: the name, the parameters, the result,
2258 and the body. The following macros and functions access these parts
2259 of a @code{FUNCTION_DECL} as well as other basic features:
2262 This macro returns the unqualified name of the function, as an
2263 @code{IDENTIFIER_NODE}. For an instantiation of a function template,
2264 the @code{DECL_NAME} is the unqualified name of the template, not
2265 something like @code{f<int>}. The value of @code{DECL_NAME} is
2266 undefined when used on a constructor, destructor, overloaded operator,
2267 or type-conversion operator, or any function that is implicitly
2268 generated by the compiler. See below for macros that can be used to
2269 distinguish these cases.
2271 @item DECL_ASSEMBLER_NAME
2272 This macro returns the mangled name of the function, also an
2273 @code{IDENTIFIER_NODE}. This name does not contain leading underscores
2274 on systems that prefix all identifiers with underscores. The mangled
2275 name is computed in the same way on all platforms; if special processing
2276 is required to deal with the object file format used on a particular
2277 platform, it is the responsibility of the back end to perform those
2278 modifications. (Of course, the back end should not modify
2279 @code{DECL_ASSEMBLER_NAME} itself.)
2281 Using @code{DECL_ASSEMBLER_NAME} will cause additional memory to be
2282 allocated (for the mangled name of the entity) so it should be used
2283 only when emitting assembly code. It should not be used within the
2284 optimizers to determine whether or not two declarations are the same,
2285 even though some of the existing optimizers do use it in that way.
2286 These uses will be removed over time.
2288 @item DECL_ARGUMENTS
2289 This macro returns the @code{PARM_DECL} for the first argument to the
2290 function. Subsequent @code{PARM_DECL} nodes can be obtained by
2291 following the @code{TREE_CHAIN} links.
2294 This macro returns the @code{RESULT_DECL} for the function.
2296 @item DECL_SAVED_TREE
2297 This macro returns the complete body of the function.
2300 This macro returns the @code{FUNCTION_TYPE} or @code{METHOD_TYPE} for
2304 A function that has a definition in the current translation unit will
2305 have a non-@code{NULL} @code{DECL_INITIAL}. However, back ends should not make
2306 use of the particular value given by @code{DECL_INITIAL}.
2308 It should contain a tree of @code{BLOCK} nodes that mirrors the scopes
2309 that variables are bound in the function. Each block contains a list
2310 of decls declared in a basic block, a pointer to a chain of blocks at
2311 the next lower scope level, then a pointer to the next block at the
2312 same level and a backpointer to the parent @code{BLOCK} or
2313 @code{FUNCTION_DECL}. So given a function as follows:
2326 you would get the following:
2329 tree foo = FUNCTION_DECL;
2330 tree decl_a = VAR_DECL;
2331 tree decl_b = VAR_DECL;
2332 tree decl_c = VAR_DECL;
2333 tree block_a = BLOCK;
2334 tree block_b = BLOCK;
2335 tree block_c = BLOCK;
2336 BLOCK_VARS(block_a) = decl_a;
2337 BLOCK_SUBBLOCKS(block_a) = block_b;
2338 BLOCK_CHAIN(block_a) = block_c;
2339 BLOCK_SUPERCONTEXT(block_a) = foo;
2340 BLOCK_VARS(block_b) = decl_b;
2341 BLOCK_SUPERCONTEXT(block_b) = block_a;
2342 BLOCK_VARS(block_c) = decl_c;
2343 BLOCK_SUPERCONTEXT(block_c) = foo;
2344 DECL_INITIAL(foo) = block_a;
2349 @c ---------------------------------------------------------------------
2350 @c Function Properties
2351 @c ---------------------------------------------------------------------
2353 @node Function Properties
2354 @subsection Function Properties
2355 @cindex function properties
2358 To determine the scope of a function, you can use the
2359 @code{DECL_CONTEXT} macro. This macro will return the class
2360 (either a @code{RECORD_TYPE} or a @code{UNION_TYPE}) or namespace (a
2361 @code{NAMESPACE_DECL}) of which the function is a member. For a virtual
2362 function, this macro returns the class in which the function was
2363 actually defined, not the base class in which the virtual declaration
2366 In C, the @code{DECL_CONTEXT} for a function maybe another function.
2367 This representation indicates that the GNU nested function extension
2368 is in use. For details on the semantics of nested functions, see the
2369 GCC Manual. The nested function can refer to local variables in its
2370 containing function. Such references are not explicitly marked in the
2371 tree structure; back ends must look at the @code{DECL_CONTEXT} for the
2372 referenced @code{VAR_DECL}. If the @code{DECL_CONTEXT} for the
2373 referenced @code{VAR_DECL} is not the same as the function currently
2374 being processed, and neither @code{DECL_EXTERNAL} nor
2375 @code{TREE_STATIC} hold, then the reference is to a local variable in
2376 a containing function, and the back end must take appropriate action.
2380 This predicate holds if the function is undefined.
2383 This predicate holds if the function has external linkage.
2386 This predicate holds if the function has been defined.
2388 @item TREE_THIS_VOLATILE
2389 This predicate holds if the function does not return normally.
2392 This predicate holds if the function can only read its arguments.
2395 This predicate holds if the function can only read its arguments, but
2396 may also read global memory.
2398 @item DECL_VIRTUAL_P
2399 This predicate holds if the function is virtual.
2401 @item DECL_ARTIFICIAL
2402 This macro holds if the function was implicitly generated by the
2403 compiler, rather than explicitly declared. In addition to implicitly
2404 generated class member functions, this macro holds for the special
2405 functions created to implement static initialization and destruction, to
2406 compute run-time type information, and so forth.
2408 @item DECL_FUNCTION_SPECIFIC_TARGET
2409 This macro returns a tree node that holds the target options that are
2410 to be used to compile this particular function or @code{NULL_TREE} if
2411 the function is to be compiled with the target options specified on
2414 @item DECL_FUNCTION_SPECIFIC_OPTIMIZATION
2415 This macro returns a tree node that holds the optimization options
2416 that are to be used to compile this particular function or
2417 @code{NULL_TREE} if the function is to be compiled with the
2418 optimization options specified on the command line.
2422 @c ---------------------------------------------------------------------
2423 @c Language-dependent trees
2424 @c ---------------------------------------------------------------------
2426 @node Language-dependent trees
2427 @section Language-dependent trees
2428 @cindex language-dependent trees
2430 Front ends may wish to keep some state associated with various GENERIC
2431 trees while parsing. To support this, trees provide a set of flags
2432 that may be used by the front end. They are accessed using
2433 @code{TREE_LANG_FLAG_n} where @samp{n} is currently 0 through 6.
2435 If necessary, a front end can use some language-dependent tree
2436 codes in its GENERIC representation, so long as it provides a
2437 hook for converting them to GIMPLE and doesn't expect them to
2438 work with any (hypothetical) optimizers that run before the
2439 conversion to GIMPLE@. The intermediate representation used while
2440 parsing C and C++ looks very little like GENERIC, but the C and
2441 C++ gimplifier hooks are perfectly happy to take it as input and
2446 @node C and C++ Trees
2447 @section C and C++ Trees
2449 This section documents the internal representation used by GCC to
2450 represent C and C++ source programs. When presented with a C or C++
2451 source program, GCC parses the program, performs semantic analysis
2452 (including the generation of error messages), and then produces the
2453 internal representation described here. This representation contains a
2454 complete representation for the entire translation unit provided as
2455 input to the front end. This representation is then typically processed
2456 by a code-generator in order to produce machine code, but could also be
2457 used in the creation of source browsers, intelligent editors, automatic
2458 documentation generators, interpreters, and any other programs needing
2459 the ability to process C or C++ code.
2461 This section explains the internal representation. In particular, it
2462 documents the internal representation for C and C++ source
2463 constructs, and the macros, functions, and variables that can be used to
2464 access these constructs. The C++ representation is largely a superset
2465 of the representation used in the C front end. There is only one
2466 construct used in C that does not appear in the C++ front end and that
2467 is the GNU ``nested function'' extension. Many of the macros documented
2468 here do not apply in C because the corresponding language constructs do
2471 The C and C++ front ends generate a mix of GENERIC trees and ones
2472 specific to C and C++. These language-specific trees are higher-level
2473 constructs than the ones in GENERIC to make the parser's job easier.
2474 This section describes those trees that aren't part of GENERIC as well
2475 as aspects of GENERIC trees that are treated in a language-specific
2478 If you are developing a ``back end'', be it is a code-generator or some
2479 other tool, that uses this representation, you may occasionally find
2480 that you need to ask questions not easily answered by the functions and
2481 macros available here. If that situation occurs, it is quite likely
2482 that GCC already supports the functionality you desire, but that the
2483 interface is simply not documented here. In that case, you should ask
2484 the GCC maintainers (via mail to @email{gcc@@gcc.gnu.org}) about
2485 documenting the functionality you require. Similarly, if you find
2486 yourself writing functions that do not deal directly with your back end,
2487 but instead might be useful to other people using the GCC front end, you
2488 should submit your patches for inclusion in GCC@.
2491 * Types for C++:: Fundamental and aggregate types.
2492 * Namespaces:: Namespaces.
2493 * Classes:: Classes.
2494 * Functions for C++:: Overloading and accessors for C++.
2495 * Statements for C++:: Statements specific to C and C++.
2496 * C++ Expressions:: From @code{typeid} to @code{throw}.
2500 @subsection Types for C++
2501 @tindex UNKNOWN_TYPE
2502 @tindex TYPENAME_TYPE
2504 @findex cp_type_quals
2505 @findex TYPE_UNQUALIFIED
2506 @findex TYPE_QUAL_CONST
2507 @findex TYPE_QUAL_VOLATILE
2508 @findex TYPE_QUAL_RESTRICT
2509 @findex TYPE_MAIN_VARIANT
2510 @cindex qualified type
2513 @findex TYPE_PRECISION
2514 @findex TYPE_ARG_TYPES
2515 @findex TYPE_METHOD_BASETYPE
2516 @findex TYPE_PTRDATAMEM_P
2517 @findex TYPE_OFFSET_BASETYPE
2519 @findex TYPE_CONTEXT
2521 @findex TYPENAME_TYPE_FULLNAME
2523 @findex TYPE_PTROBV_P
2525 In C++, an array type is not qualified; rather the type of the array
2526 elements is qualified. This situation is reflected in the intermediate
2527 representation. The macros described here will always examine the
2528 qualification of the underlying element type when applied to an array
2529 type. (If the element type is itself an array, then the recursion
2530 continues until a non-array type is found, and the qualification of this
2531 type is examined.) So, for example, @code{CP_TYPE_CONST_P} will hold of
2532 the type @code{const int ()[7]}, denoting an array of seven @code{int}s.
2534 The following functions and macros deal with cv-qualification of types:
2537 This function returns the set of type qualifiers applied to this type.
2538 This value is @code{TYPE_UNQUALIFIED} if no qualifiers have been
2539 applied. The @code{TYPE_QUAL_CONST} bit is set if the type is
2540 @code{const}-qualified. The @code{TYPE_QUAL_VOLATILE} bit is set if the
2541 type is @code{volatile}-qualified. The @code{TYPE_QUAL_RESTRICT} bit is
2542 set if the type is @code{restrict}-qualified.
2544 @item CP_TYPE_CONST_P
2545 This macro holds if the type is @code{const}-qualified.
2547 @item CP_TYPE_VOLATILE_P
2548 This macro holds if the type is @code{volatile}-qualified.
2550 @item CP_TYPE_RESTRICT_P
2551 This macro holds if the type is @code{restrict}-qualified.
2553 @item CP_TYPE_CONST_NON_VOLATILE_P
2554 This predicate holds for a type that is @code{const}-qualified, but
2555 @emph{not} @code{volatile}-qualified; other cv-qualifiers are ignored as
2556 well: only the @code{const}-ness is tested.
2560 A few other macros and functions are usable with all types:
2563 The number of bits required to represent the type, represented as an
2564 @code{INTEGER_CST}. For an incomplete type, @code{TYPE_SIZE} will be
2568 The alignment of the type, in bits, represented as an @code{int}.
2571 This macro returns a declaration (in the form of a @code{TYPE_DECL}) for
2572 the type. (Note this macro does @emph{not} return an
2573 @code{IDENTIFIER_NODE}, as you might expect, given its name!) You can
2574 look at the @code{DECL_NAME} of the @code{TYPE_DECL} to obtain the
2575 actual name of the type. The @code{TYPE_NAME} will be @code{NULL_TREE}
2576 for a type that is not a built-in type, the result of a typedef, or a
2579 @item CP_INTEGRAL_TYPE
2580 This predicate holds if the type is an integral type. Notice that in
2581 C++, enumerations are @emph{not} integral types.
2583 @item ARITHMETIC_TYPE_P
2584 This predicate holds if the type is an integral type (in the C++ sense)
2585 or a floating point type.
2588 This predicate holds for a class-type.
2591 This predicate holds for a built-in type.
2593 @item TYPE_PTRDATAMEM_P
2594 This predicate holds if the type is a pointer to data member.
2597 This predicate holds if the type is a pointer type, and the pointee is
2601 This predicate holds for a pointer to function type.
2604 This predicate holds for a pointer to object type. Note however that it
2605 does not hold for the generic pointer to object type @code{void *}. You
2606 may use @code{TYPE_PTROBV_P} to test for a pointer to object type as
2607 well as @code{void *}.
2611 The table below describes types specific to C and C++ as well as
2612 language-dependent info about GENERIC types.
2617 Used to represent pointer types, and pointer to data member types. If
2619 is a pointer to data member type, then @code{TYPE_PTRDATAMEM_P} will hold.
2620 For a pointer to data member type of the form @samp{T X::*},
2621 @code{TYPE_PTRMEM_CLASS_TYPE} will be the type @code{X}, while
2622 @code{TYPE_PTRMEM_POINTED_TO_TYPE} will be the type @code{T}.
2625 Used to represent @code{struct} and @code{class} types in C and C++. If
2626 @code{TYPE_PTRMEMFUNC_P} holds, then this type is a pointer-to-member
2627 type. In that case, the @code{TYPE_PTRMEMFUNC_FN_TYPE} is a
2628 @code{POINTER_TYPE} pointing to a @code{METHOD_TYPE}. The
2629 @code{METHOD_TYPE} is the type of a function pointed to by the
2630 pointer-to-member function. If @code{TYPE_PTRMEMFUNC_P} does not hold,
2631 this type is a class type. For more information, @pxref{Classes}.
2634 This node is used to represent a type the knowledge of which is
2635 insufficient for a sound processing.
2638 Used to represent a construct of the form @code{typename T::A}. The
2639 @code{TYPE_CONTEXT} is @code{T}; the @code{TYPE_NAME} is an
2640 @code{IDENTIFIER_NODE} for @code{A}. If the type is specified via a
2641 template-id, then @code{TYPENAME_TYPE_FULLNAME} yields a
2642 @code{TEMPLATE_ID_EXPR}. The @code{TREE_TYPE} is non-@code{NULL} if the
2643 node is implicitly generated in support for the implicit typename
2644 extension; in which case the @code{TREE_TYPE} is a type node for the
2648 Used to represent the @code{__typeof__} extension. The
2649 @code{TYPE_FIELDS} is the expression the type of which is being
2655 @c ---------------------------------------------------------------------
2657 @c ---------------------------------------------------------------------
2660 @subsection Namespaces
2661 @cindex namespace, scope
2662 @tindex NAMESPACE_DECL
2664 The root of the entire intermediate representation is the variable
2665 @code{global_namespace}. This is the namespace specified with @code{::}
2666 in C++ source code. All other namespaces, types, variables, functions,
2667 and so forth can be found starting with this namespace.
2669 However, except for the fact that it is distinguished as the root of the
2670 representation, the global namespace is no different from any other
2671 namespace. Thus, in what follows, we describe namespaces generally,
2672 rather than the global namespace in particular.
2674 A namespace is represented by a @code{NAMESPACE_DECL} node.
2676 The following macros and functions can be used on a @code{NAMESPACE_DECL}:
2680 This macro is used to obtain the @code{IDENTIFIER_NODE} corresponding to
2681 the unqualified name of the name of the namespace (@pxref{Identifiers}).
2682 The name of the global namespace is @samp{::}, even though in C++ the
2683 global namespace is unnamed. However, you should use comparison with
2684 @code{global_namespace}, rather than @code{DECL_NAME} to determine
2685 whether or not a namespace is the global one. An unnamed namespace
2686 will have a @code{DECL_NAME} equal to @code{anonymous_namespace_name}.
2687 Within a single translation unit, all unnamed namespaces will have the
2691 This macro returns the enclosing namespace. The @code{DECL_CONTEXT} for
2692 the @code{global_namespace} is @code{NULL_TREE}.
2694 @item DECL_NAMESPACE_ALIAS
2695 If this declaration is for a namespace alias, then
2696 @code{DECL_NAMESPACE_ALIAS} is the namespace for which this one is an
2699 Do not attempt to use @code{cp_namespace_decls} for a namespace which is
2700 an alias. Instead, follow @code{DECL_NAMESPACE_ALIAS} links until you
2701 reach an ordinary, non-alias, namespace, and call
2702 @code{cp_namespace_decls} there.
2704 @item DECL_NAMESPACE_STD_P
2705 This predicate holds if the namespace is the special @code{::std}
2708 @item cp_namespace_decls
2709 This function will return the declarations contained in the namespace,
2710 including types, overloaded functions, other namespaces, and so forth.
2711 If there are no declarations, this function will return
2712 @code{NULL_TREE}. The declarations are connected through their
2713 @code{TREE_CHAIN} fields.
2715 Although most entries on this list will be declarations,
2716 @code{TREE_LIST} nodes may also appear. In this case, the
2717 @code{TREE_VALUE} will be an @code{OVERLOAD}. The value of the
2718 @code{TREE_PURPOSE} is unspecified; back ends should ignore this value.
2719 As with the other kinds of declarations returned by
2720 @code{cp_namespace_decls}, the @code{TREE_CHAIN} will point to the next
2721 declaration in this list.
2723 For more information on the kinds of declarations that can occur on this
2724 list, @xref{Declarations}. Some declarations will not appear on this
2725 list. In particular, no @code{FIELD_DECL}, @code{LABEL_DECL}, or
2726 @code{PARM_DECL} nodes will appear here.
2728 This function cannot be used with namespaces that have
2729 @code{DECL_NAMESPACE_ALIAS} set.
2733 @c ---------------------------------------------------------------------
2735 @c ---------------------------------------------------------------------
2739 @cindex class, scope
2742 @findex CLASSTYPE_DECLARED_CLASS
2747 @findex TYPE_METHODS
2749 Besides namespaces, the other high-level scoping construct in C++ is the
2750 class. (Throughout this manual the term @dfn{class} is used to mean the
2751 types referred to in the ANSI/ISO C++ Standard as classes; these include
2752 types defined with the @code{class}, @code{struct}, and @code{union}
2755 A class type is represented by either a @code{RECORD_TYPE} or a
2756 @code{UNION_TYPE}. A class declared with the @code{union} tag is
2757 represented by a @code{UNION_TYPE}, while classes declared with either
2758 the @code{struct} or the @code{class} tag are represented by
2759 @code{RECORD_TYPE}s. You can use the @code{CLASSTYPE_DECLARED_CLASS}
2760 macro to discern whether or not a particular type is a @code{class} as
2761 opposed to a @code{struct}. This macro will be true only for classes
2762 declared with the @code{class} tag.
2764 Almost all non-function members are available on the @code{TYPE_FIELDS}
2765 list. Given one member, the next can be found by following the
2766 @code{TREE_CHAIN}. You should not depend in any way on the order in
2767 which fields appear on this list. All nodes on this list will be
2768 @samp{DECL} nodes. A @code{FIELD_DECL} is used to represent a non-static
2769 data member, a @code{VAR_DECL} is used to represent a static data
2770 member, and a @code{TYPE_DECL} is used to represent a type. Note that
2771 the @code{CONST_DECL} for an enumeration constant will appear on this
2772 list, if the enumeration type was declared in the class. (Of course,
2773 the @code{TYPE_DECL} for the enumeration type will appear here as well.)
2774 There are no entries for base classes on this list. In particular,
2775 there is no @code{FIELD_DECL} for the ``base-class portion'' of an
2778 The @code{TYPE_VFIELD} is a compiler-generated field used to point to
2779 virtual function tables. It may or may not appear on the
2780 @code{TYPE_FIELDS} list. However, back ends should handle the
2781 @code{TYPE_VFIELD} just like all the entries on the @code{TYPE_FIELDS}
2784 The function members are available on the @code{TYPE_METHODS} list.
2785 Again, subsequent members are found by following the @code{TREE_CHAIN}
2786 field. If a function is overloaded, each of the overloaded functions
2787 appears; no @code{OVERLOAD} nodes appear on the @code{TYPE_METHODS}
2788 list. Implicitly declared functions (including default constructors,
2789 copy constructors, assignment operators, and destructors) will appear on
2792 Every class has an associated @dfn{binfo}, which can be obtained with
2793 @code{TYPE_BINFO}. Binfos are used to represent base-classes. The
2794 binfo given by @code{TYPE_BINFO} is the degenerate case, whereby every
2795 class is considered to be its own base-class. The base binfos for a
2796 particular binfo are held in a vector, whose length is obtained with
2797 @code{BINFO_N_BASE_BINFOS}. The base binfos themselves are obtained
2798 with @code{BINFO_BASE_BINFO} and @code{BINFO_BASE_ITERATE}. To add a
2799 new binfo, use @code{BINFO_BASE_APPEND}. The vector of base binfos can
2800 be obtained with @code{BINFO_BASE_BINFOS}, but normally you do not need
2801 to use that. The class type associated with a binfo is given by
2802 @code{BINFO_TYPE}. It is not always the case that @code{BINFO_TYPE
2803 (TYPE_BINFO (x))}, because of typedefs and qualified types. Neither is
2804 it the case that @code{TYPE_BINFO (BINFO_TYPE (y))} is the same binfo as
2805 @code{y}. The reason is that if @code{y} is a binfo representing a
2806 base-class @code{B} of a derived class @code{D}, then @code{BINFO_TYPE
2807 (y)} will be @code{B}, and @code{TYPE_BINFO (BINFO_TYPE (y))} will be
2808 @code{B} as its own base-class, rather than as a base-class of @code{D}.
2810 The access to a base type can be found with @code{BINFO_BASE_ACCESS}.
2811 This will produce @code{access_public_node}, @code{access_private_node}
2812 or @code{access_protected_node}. If bases are always public,
2813 @code{BINFO_BASE_ACCESSES} may be @code{NULL}.
2815 @code{BINFO_VIRTUAL_P} is used to specify whether the binfo is inherited
2816 virtually or not. The other flags, @code{BINFO_MARKED_P} and
2817 @code{BINFO_FLAG_1} to @code{BINFO_FLAG_6} can be used for language
2820 The following macros can be used on a tree node representing a class-type.
2824 This predicate holds if the class is local class @emph{i.e.}@: declared
2825 inside a function body.
2827 @item TYPE_POLYMORPHIC_P
2828 This predicate holds if the class has at least one virtual function
2829 (declared or inherited).
2831 @item TYPE_HAS_DEFAULT_CONSTRUCTOR
2832 This predicate holds whenever its argument represents a class-type with
2833 default constructor.
2835 @item CLASSTYPE_HAS_MUTABLE
2836 @itemx TYPE_HAS_MUTABLE_P
2837 These predicates hold for a class-type having a mutable data member.
2839 @item CLASSTYPE_NON_POD_P
2840 This predicate holds only for class-types that are not PODs.
2842 @item TYPE_HAS_NEW_OPERATOR
2843 This predicate holds for a class-type that defines
2844 @code{operator new}.
2846 @item TYPE_HAS_ARRAY_NEW_OPERATOR
2847 This predicate holds for a class-type for which
2848 @code{operator new[]} is defined.
2850 @item TYPE_OVERLOADS_CALL_EXPR
2851 This predicate holds for class-type for which the function call
2852 @code{operator()} is overloaded.
2854 @item TYPE_OVERLOADS_ARRAY_REF
2855 This predicate holds for a class-type that overloads
2858 @item TYPE_OVERLOADS_ARROW
2859 This predicate holds for a class-type for which @code{operator->} is
2864 @node Functions for C++
2865 @subsection Functions for C++
2867 @tindex FUNCTION_DECL
2872 A function is represented by a @code{FUNCTION_DECL} node. A set of
2873 overloaded functions is sometimes represented by an @code{OVERLOAD} node.
2875 An @code{OVERLOAD} node is not a declaration, so none of the
2876 @samp{DECL_} macros should be used on an @code{OVERLOAD}. An
2877 @code{OVERLOAD} node is similar to a @code{TREE_LIST}. Use
2878 @code{OVL_CURRENT} to get the function associated with an
2879 @code{OVERLOAD} node; use @code{OVL_NEXT} to get the next
2880 @code{OVERLOAD} node in the list of overloaded functions. The macros
2881 @code{OVL_CURRENT} and @code{OVL_NEXT} are actually polymorphic; you can
2882 use them to work with @code{FUNCTION_DECL} nodes as well as with
2883 overloads. In the case of a @code{FUNCTION_DECL}, @code{OVL_CURRENT}
2884 will always return the function itself, and @code{OVL_NEXT} will always
2885 be @code{NULL_TREE}.
2887 To determine the scope of a function, you can use the
2888 @code{DECL_CONTEXT} macro. This macro will return the class
2889 (either a @code{RECORD_TYPE} or a @code{UNION_TYPE}) or namespace (a
2890 @code{NAMESPACE_DECL}) of which the function is a member. For a virtual
2891 function, this macro returns the class in which the function was
2892 actually defined, not the base class in which the virtual declaration
2895 If a friend function is defined in a class scope, the
2896 @code{DECL_FRIEND_CONTEXT} macro can be used to determine the class in
2897 which it was defined. For example, in
2899 class C @{ friend void f() @{@} @};
2902 the @code{DECL_CONTEXT} for @code{f} will be the
2903 @code{global_namespace}, but the @code{DECL_FRIEND_CONTEXT} will be the
2904 @code{RECORD_TYPE} for @code{C}.
2907 The following macros and functions can be used on a @code{FUNCTION_DECL}:
2910 This predicate holds for a function that is the program entry point
2913 @item DECL_LOCAL_FUNCTION_P
2914 This predicate holds if the function was declared at block scope, even
2915 though it has a global scope.
2917 @item DECL_ANTICIPATED
2918 This predicate holds if the function is a built-in function but its
2919 prototype is not yet explicitly declared.
2921 @item DECL_EXTERN_C_FUNCTION_P
2922 This predicate holds if the function is declared as an
2923 `@code{extern "C"}' function.
2925 @item DECL_LINKONCE_P
2926 This macro holds if multiple copies of this function may be emitted in
2927 various translation units. It is the responsibility of the linker to
2928 merge the various copies. Template instantiations are the most common
2929 example of functions for which @code{DECL_LINKONCE_P} holds; G++
2930 instantiates needed templates in all translation units which require them,
2931 and then relies on the linker to remove duplicate instantiations.
2933 FIXME: This macro is not yet implemented.
2935 @item DECL_FUNCTION_MEMBER_P
2936 This macro holds if the function is a member of a class, rather than a
2937 member of a namespace.
2939 @item DECL_STATIC_FUNCTION_P
2940 This predicate holds if the function a static member function.
2942 @item DECL_NONSTATIC_MEMBER_FUNCTION_P
2943 This macro holds for a non-static member function.
2945 @item DECL_CONST_MEMFUNC_P
2946 This predicate holds for a @code{const}-member function.
2948 @item DECL_VOLATILE_MEMFUNC_P
2949 This predicate holds for a @code{volatile}-member function.
2951 @item DECL_CONSTRUCTOR_P
2952 This macro holds if the function is a constructor.
2954 @item DECL_NONCONVERTING_P
2955 This predicate holds if the constructor is a non-converting constructor.
2957 @item DECL_COMPLETE_CONSTRUCTOR_P
2958 This predicate holds for a function which is a constructor for an object
2961 @item DECL_BASE_CONSTRUCTOR_P
2962 This predicate holds for a function which is a constructor for a base
2965 @item DECL_COPY_CONSTRUCTOR_P
2966 This predicate holds for a function which is a copy-constructor.
2968 @item DECL_DESTRUCTOR_P
2969 This macro holds if the function is a destructor.
2971 @item DECL_COMPLETE_DESTRUCTOR_P
2972 This predicate holds if the function is the destructor for an object a
2975 @item DECL_OVERLOADED_OPERATOR_P
2976 This macro holds if the function is an overloaded operator.
2978 @item DECL_CONV_FN_P
2979 This macro holds if the function is a type-conversion operator.
2981 @item DECL_GLOBAL_CTOR_P
2982 This predicate holds if the function is a file-scope initialization
2985 @item DECL_GLOBAL_DTOR_P
2986 This predicate holds if the function is a file-scope finalization
2990 This predicate holds if the function is a thunk.
2992 These functions represent stub code that adjusts the @code{this} pointer
2993 and then jumps to another function. When the jumped-to function
2994 returns, control is transferred directly to the caller, without
2995 returning to the thunk. The first parameter to the thunk is always the
2996 @code{this} pointer; the thunk should add @code{THUNK_DELTA} to this
2997 value. (The @code{THUNK_DELTA} is an @code{int}, not an
2998 @code{INTEGER_CST}.)
3000 Then, if @code{THUNK_VCALL_OFFSET} (an @code{INTEGER_CST}) is nonzero
3001 the adjusted @code{this} pointer must be adjusted again. The complete
3002 calculation is given by the following pseudo-code:
3006 if (THUNK_VCALL_OFFSET)
3007 this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET]
3010 Finally, the thunk should jump to the location given
3011 by @code{DECL_INITIAL}; this will always be an expression for the
3012 address of a function.
3014 @item DECL_NON_THUNK_FUNCTION_P
3015 This predicate holds if the function is @emph{not} a thunk function.
3017 @item GLOBAL_INIT_PRIORITY
3018 If either @code{DECL_GLOBAL_CTOR_P} or @code{DECL_GLOBAL_DTOR_P} holds,
3019 then this gives the initialization priority for the function. The
3020 linker will arrange that all functions for which
3021 @code{DECL_GLOBAL_CTOR_P} holds are run in increasing order of priority
3022 before @code{main} is called. When the program exits, all functions for
3023 which @code{DECL_GLOBAL_DTOR_P} holds are run in the reverse order.
3025 @item TYPE_RAISES_EXCEPTIONS
3026 This macro returns the list of exceptions that a (member-)function can
3027 raise. The returned list, if non @code{NULL}, is comprised of nodes
3028 whose @code{TREE_VALUE} represents a type.
3030 @item TYPE_NOTHROW_P
3031 This predicate holds when the exception-specification of its arguments
3032 is of the form `@code{()}'.
3034 @item DECL_ARRAY_DELETE_OPERATOR_P
3035 This predicate holds if the function an overloaded
3036 @code{operator delete[]}.
3040 @c ---------------------------------------------------------------------
3042 @c ---------------------------------------------------------------------
3044 @node Statements for C++
3045 @subsection Statements for C++
3048 @tindex CLEANUP_STMT
3049 @findex CLEANUP_DECL
3050 @findex CLEANUP_EXPR
3051 @tindex CONTINUE_STMT
3053 @findex DECL_STMT_DECL
3057 @tindex EMPTY_CLASS_EXPR
3059 @findex EXPR_STMT_EXPR
3061 @findex FOR_INIT_STMT
3073 @findex SUBOBJECT_CLEANUP
3079 @findex TRY_HANDLERS
3080 @findex HANDLER_PARMS
3081 @findex HANDLER_BODY
3087 A function that has a definition in the current translation unit will
3088 have a non-@code{NULL} @code{DECL_INITIAL}. However, back ends should not make
3089 use of the particular value given by @code{DECL_INITIAL}.
3091 The @code{DECL_SAVED_TREE} macro will give the complete body of the
3094 @subsubsection Statements
3096 There are tree nodes corresponding to all of the source-level
3097 statement constructs, used within the C and C++ frontends. These are
3098 enumerated here, together with a list of the various macros that can
3099 be used to obtain information about them. There are a few macros that
3100 can be used with all statements:
3103 @item STMT_IS_FULL_EXPR_P
3104 In C++, statements normally constitute ``full expressions''; temporaries
3105 created during a statement are destroyed when the statement is complete.
3106 However, G++ sometimes represents expressions by statements; these
3107 statements will not have @code{STMT_IS_FULL_EXPR_P} set. Temporaries
3108 created during such statements should be destroyed when the innermost
3109 enclosing statement with @code{STMT_IS_FULL_EXPR_P} set is exited.
3113 Here is the list of the various statement nodes, and the macros used to
3114 access them. This documentation describes the use of these nodes in
3115 non-template functions (including instantiations of template functions).
3116 In template functions, the same nodes are used, but sometimes in
3117 slightly different ways.
3119 Many of the statements have substatements. For example, a @code{while}
3120 loop will have a body, which is itself a statement. If the substatement
3121 is @code{NULL_TREE}, it is considered equivalent to a statement
3122 consisting of a single @code{;}, i.e., an expression statement in which
3123 the expression has been omitted. A substatement may in fact be a list
3124 of statements, connected via their @code{TREE_CHAIN}s. So, you should
3125 always process the statement tree by looping over substatements, like
3128 void process_stmt (stmt)
3133 switch (TREE_CODE (stmt))
3136 process_stmt (THEN_CLAUSE (stmt));
3137 /* @r{More processing here.} */
3143 stmt = TREE_CHAIN (stmt);
3147 In other words, while the @code{then} clause of an @code{if} statement
3148 in C++ can be only one statement (although that one statement may be a
3149 compound statement), the intermediate representation will sometimes use
3150 several statements chained together.
3155 Used to represent a @code{break} statement. There are no additional
3160 Used to represent an action that should take place upon exit from the
3161 enclosing scope. Typically, these actions are calls to destructors for
3162 local objects, but back ends cannot rely on this fact. If these nodes
3163 are in fact representing such destructors, @code{CLEANUP_DECL} will be
3164 the @code{VAR_DECL} destroyed. Otherwise, @code{CLEANUP_DECL} will be
3165 @code{NULL_TREE}. In any case, the @code{CLEANUP_EXPR} is the
3166 expression to execute. The cleanups executed on exit from a scope
3167 should be run in the reverse order of the order in which the associated
3168 @code{CLEANUP_STMT}s were encountered.
3172 Used to represent a @code{continue} statement. There are no additional
3177 Used to mark the beginning (if @code{CTOR_BEGIN_P} holds) or end (if
3178 @code{CTOR_END_P} holds of the main body of a constructor. See also
3179 @code{SUBOBJECT} for more information on how to use these nodes.
3183 Used to represent a @code{do} loop. The body of the loop is given by
3184 @code{DO_BODY} while the termination condition for the loop is given by
3185 @code{DO_COND}. The condition for a @code{do}-statement is always an
3188 @item EMPTY_CLASS_EXPR
3190 Used to represent a temporary object of a class with no data whose
3191 address is never taken. (All such objects are interchangeable.) The
3192 @code{TREE_TYPE} represents the type of the object.
3196 Used to represent an expression statement. Use @code{EXPR_STMT_EXPR} to
3197 obtain the expression.
3201 Used to represent a @code{for} statement. The @code{FOR_INIT_STMT} is
3202 the initialization statement for the loop. The @code{FOR_COND} is the
3203 termination condition. The @code{FOR_EXPR} is the expression executed
3204 right before the @code{FOR_COND} on each loop iteration; often, this
3205 expression increments a counter. The body of the loop is given by
3206 @code{FOR_BODY}. Note that @code{FOR_INIT_STMT} and @code{FOR_BODY}
3207 return statements, while @code{FOR_COND} and @code{FOR_EXPR} return
3212 Used to represent a C++ @code{catch} block. The @code{HANDLER_TYPE}
3213 is the type of exception that will be caught by this handler; it is
3214 equal (by pointer equality) to @code{NULL} if this handler is for all
3215 types. @code{HANDLER_PARMS} is the @code{DECL_STMT} for the catch
3216 parameter, and @code{HANDLER_BODY} is the code for the block itself.
3220 Used to represent an @code{if} statement. The @code{IF_COND} is the
3223 If the condition is a @code{TREE_LIST}, then the @code{TREE_PURPOSE} is
3224 a statement (usually a @code{DECL_STMT}). Each time the condition is
3225 evaluated, the statement should be executed. Then, the
3226 @code{TREE_VALUE} should be used as the conditional expression itself.
3227 This representation is used to handle C++ code like this:
3229 C++ distinguishes between this and @code{COND_EXPR} for handling templates.
3232 if (int i = 7) @dots{}
3235 where there is a new local variable (or variables) declared within the
3238 The @code{THEN_CLAUSE} represents the statement given by the @code{then}
3239 condition, while the @code{ELSE_CLAUSE} represents the statement given
3240 by the @code{else} condition.
3244 In a constructor, these nodes are used to mark the point at which a
3245 subobject of @code{this} is fully constructed. If, after this point, an
3246 exception is thrown before a @code{CTOR_STMT} with @code{CTOR_END_P} set
3247 is encountered, the @code{SUBOBJECT_CLEANUP} must be executed. The
3248 cleanups must be executed in the reverse order in which they appear.
3252 Used to represent a @code{switch} statement. The @code{SWITCH_STMT_COND}
3253 is the expression on which the switch is occurring. See the documentation
3254 for an @code{IF_STMT} for more information on the representation used
3255 for the condition. The @code{SWITCH_STMT_BODY} is the body of the switch
3256 statement. The @code{SWITCH_STMT_TYPE} is the original type of switch
3257 expression as given in the source, before any compiler conversions.
3260 Used to represent a @code{try} block. The body of the try block is
3261 given by @code{TRY_STMTS}. Each of the catch blocks is a @code{HANDLER}
3262 node. The first handler is given by @code{TRY_HANDLERS}. Subsequent
3263 handlers are obtained by following the @code{TREE_CHAIN} link from one
3264 handler to the next. The body of the handler is given by
3265 @code{HANDLER_BODY}.
3267 If @code{CLEANUP_P} holds of the @code{TRY_BLOCK}, then the
3268 @code{TRY_HANDLERS} will not be a @code{HANDLER} node. Instead, it will
3269 be an expression that should be executed if an exception is thrown in
3270 the try block. It must rethrow the exception after executing that code.
3271 And, if an exception is thrown while the expression is executing,
3272 @code{terminate} must be called.
3275 Used to represent a @code{using} directive. The namespace is given by
3276 @code{USING_STMT_NAMESPACE}, which will be a NAMESPACE_DECL@. This node
3277 is needed inside template functions, to implement using directives
3278 during instantiation.
3282 Used to represent a @code{while} loop. The @code{WHILE_COND} is the
3283 termination condition for the loop. See the documentation for an
3284 @code{IF_STMT} for more information on the representation used for the
3287 The @code{WHILE_BODY} is the body of the loop.
3291 @node C++ Expressions
3292 @subsection C++ Expressions
3294 This section describes expressions specific to the C and C++ front
3300 Used to represent a @code{typeid} expression.
3305 Used to represent a call to @code{new} and @code{new[]} respectively.
3308 @itemx VEC_DELETE_EXPR
3310 Used to represent a call to @code{delete} and @code{delete[]} respectively.
3314 Represents a reference to a member of a class.
3318 Represents an instance of @code{throw} in the program. Operand 0,
3319 which is the expression to throw, may be @code{NULL_TREE}.
3322 @item AGGR_INIT_EXPR
3323 An @code{AGGR_INIT_EXPR} represents the initialization as the return
3324 value of a function call, or as the result of a constructor. An
3325 @code{AGGR_INIT_EXPR} will only appear as a full-expression, or as the
3326 second operand of a @code{TARGET_EXPR}. @code{AGGR_INIT_EXPR}s have
3327 a representation similar to that of @code{CALL_EXPR}s. You can use
3328 the @code{AGGR_INIT_EXPR_FN} and @code{AGGR_INIT_EXPR_ARG} macros to access
3329 the function to call and the arguments to pass.
3331 If @code{AGGR_INIT_VIA_CTOR_P} holds of the @code{AGGR_INIT_EXPR}, then
3332 the initialization is via a constructor call. The address of the
3333 @code{AGGR_INIT_EXPR_SLOT} operand, which is always a @code{VAR_DECL},
3334 is taken, and this value replaces the first argument in the argument
3337 In either case, the expression is void.