OSDN Git Service

a5c5fecd892f8ab2d4166977df47c735d9c8ac07
[pf3gnuchains/gcc-fork.git] / gcc / doc / c-tree.texi
1 @c Copyright (c) 1999, 2000, 2001 Free Software Foundation, Inc.
2 @c Free Software Foundation, Inc.
3 @c This is part of the GCC manual.
4 @c For copying conditions, see the file gcc.texi.
5
6 @c ---------------------------------------------------------------------
7 @c Trees
8 @c ---------------------------------------------------------------------
9
10 @node Trees
11 @chapter Trees: The intermediate representation used by the C and C++ front ends
12 @cindex Trees
13 @cindex C/C++ Internal Representation
14
15 This chapter documents the internal representation used by GCC and C++ to
16 represent C and C++ source programs.  When presented with a C or C++
17 source program, GCC parses the program, performs semantic analysis
18 (including the generation of error messages), and then produces the
19 internal representation described here.  This representation contains a
20 complete representation for the entire translation unit provided as
21 input to the front end.  This representation is then typically processed
22 by a code-generator in order to produce machine code, but could also be
23 used in the creation of source browsers, intelligent editors, automatic
24 documentation generators, interpreters, and any other programs needing
25 the ability to process C or C++ code.
26
27 This chapter explains the internal representation.  In particular, it
28 documents the internal representation for C and C++ source
29 constructs, and the macros, functions, and variables that can be used to
30 access these constructs.  The C++ representation which is largely a superset
31 of the representation used in the C front end.  There is only one
32 construct used in C that does not appear in the C++ front end and that
33 is the GNU ``nested function'' extension.  Many of the macros documented
34 here do not apply in C because the corresponding language constructs do
35 not appear in C@.
36
37 If you are developing a ``back end'', be it is a code-generator or some
38 other tool, that uses this representation, you may occasionally find
39 that you need to ask questions not easily answered by the functions and
40 macros available here.  If that situation occurs, it is quite likely
41 that GCC already supports the functionality you desire, but that the
42 interface is simply not documented here.  In that case, you should ask
43 the GCC maintainers (via mail to @email{gcc@@gcc.gnu.org}) about
44 documenting the functionality you require.  Similarly, if you find
45 yourself writing functions that do not deal directly with your back end,
46 but instead might be useful to other people using the GCC front end, you
47 should submit your patches for inclusion in GCC@.
48
49 @menu
50 * Deficiencies::        Topics net yet covered in this document.
51 * Tree overview::       All about @code{tree}s.
52 * Types::               Fundamental and aggregate types.
53 * Scopes::              Namespaces and classes.
54 * Functions::           Overloading, function bodies, and linkage.
55 * Declarations::        Type declarations and variables.
56 * Attributes::          Declaration and type attributes.
57 * Expression trees::    From @code{typeid} to @code{throw}.
58 @end menu
59
60 @c ---------------------------------------------------------------------
61 @c Deficiencies
62 @c ---------------------------------------------------------------------
63
64 @node Deficiencies
65 @section Deficiencies
66
67 There are many places in which this document is incomplet and incorrekt.
68 It is, as of yet, only @emph{preliminary} documentation.
69
70 @c ---------------------------------------------------------------------
71 @c Overview
72 @c ---------------------------------------------------------------------
73
74 @node Tree overview
75 @section Overview
76 @cindex tree
77 @findex TREE_CODE
78
79 The central data structure used by the internal representation is the
80 @code{tree}.  These nodes, while all of the C type @code{tree}, are of
81 many varieties.  A @code{tree} is a pointer type, but the object to
82 which it points may be of a variety of types.  From this point forward,
83 we will refer to trees in ordinary type, rather than in @code{this
84 font}, except when talking about the actual C type @code{tree}.
85
86 You can tell what kind of node a particular tree is by using the
87 @code{TREE_CODE} macro.  Many, many macros take a trees as input and
88 return trees as output.  However, most macros require a certain kinds of
89 tree node as input.  In other words, there is a type-system for trees,
90 but it is not reflected in the C type-system.
91
92 For safety, it is useful to configure GCC with @option{--enable-checking}.
93 Although this results in a significant performance penalty (since all
94 tree types are checked at run-time), and is therefore inappropriate in a
95 release version, it is extremely helpful during the development process.
96
97 Many macros behave as predicates.  Many, although not all, of these
98 predicates end in @samp{_P}.  Do not rely on the result type of these
99 macros being of any particular type.  You may, however, rely on the fact
100 that the type can be compared to @code{0}, so that statements like
101 @example
102 if (TEST_P (t) && !TEST_P (y))
103   x = 1;
104 @end example
105 @noindent
106 and
107 @example
108 int i = (TEST_P (t) != 0);
109 @end example
110 @noindent
111 are legal.  Macros that return @code{int} values now may be changed to
112 return @code{tree} values, or other pointers in the future.  Even those
113 that continue to return @code{int} may return multiple non-zero codes
114 where previously they returned only zero and one.  Therefore, you should
115 not write code like
116 @example
117 if (TEST_P (t) == 1)
118 @end example
119 @noindent
120 as this code is not guaranteed to work correctly in the future.
121
122 You should not take the address of values returned by the macros or
123 functions described here.  In particular, no guarantee is given that the
124 values are lvalues.
125
126 In general, the names of macros are all in uppercase, while the names of
127 functions are entirely in lower case.  There are rare exceptions to this
128 rule.  You should assume that any macro or function whose name is made
129 up entirely of uppercase letters may evaluate its arguments more than
130 once.  You may assume that a macro or function whose name is made up
131 entirely of lowercase letters will evaluate its arguments only once.
132
133 The @code{error_mark_node} is a special tree.  Its tree code is
134 @code{ERROR_MARK}, but since there is only ever one node with that code,
135 the usual practice is to compare the tree against
136 @code{error_mark_node}.  (This test is just a test for pointer
137 equality.)  If an error has occurred during front-end processing the
138 flag @code{errorcount} will be set.  If the front end has encountered
139 code it cannot handle, it will issue a message to the user and set
140 @code{sorrycount}.  When these flags are set, any macro or function
141 which normally returns a tree of a particular kind may instead return
142 the @code{error_mark_node}.  Thus, if you intend to do any processing of
143 erroneous code, you must be prepared to deal with the
144 @code{error_mark_node}.
145
146 Occasionally, a particular tree slot (like an operand to an expression,
147 or a particular field in a declaration) will be referred to as
148 ``reserved for the back end.''  These slots are used to store RTL when
149 the tree is converted to RTL for use by the GCC back end.  However, if
150 that process is not taking place (e.g., if the front end is being hooked
151 up to an intelligent editor), then those slots may be used by the
152 back end presently in use.
153
154 If you encounter situations that do not match this documentation, such
155 as tree nodes of types not mentioned here, or macros documented to
156 return entities of a particular kind that instead return entities of
157 some different kind, you have found a bug, either in the front end or in
158 the documentation.  Please report these bugs as you would any other
159 bug.
160
161 @menu
162 * Macros and Functions::Macros and functions that can be used with all trees.
163 * Identifiers::         The names of things.
164 * Containers::          Lists and vectors.
165 @end menu
166
167 @c ---------------------------------------------------------------------
168 @c Trees
169 @c ---------------------------------------------------------------------
170
171 @node Macros and Functions
172 @subsection Trees
173 @cindex tree
174
175 This section is not here yet.
176
177 @c ---------------------------------------------------------------------
178 @c Identifiers
179 @c ---------------------------------------------------------------------
180
181 @node Identifiers
182 @subsection Identifiers
183 @cindex identifier
184 @cindex name
185 @tindex IDENTIFIER_NODE
186
187 An @code{IDENTIFIER_NODE} represents a slightly more general concept
188 that the standard C or C++ concept of identifier.  In particular, an
189 @code{IDENTIFIER_NODE} may contain a @samp{$}, or other extraordinary
190 characters.
191
192 There are never two distinct @code{IDENTIFIER_NODE}s representing the
193 same identifier.  Therefore, you may use pointer equality to compare
194 @code{IDENTIFIER_NODE}s, rather than using a routine like @code{strcmp}.
195
196 You can use the following macros to access identifiers:
197 @ftable @code
198 @item IDENTIFIER_POINTER
199 The string represented by the identifier, represented as a
200 @code{char*}.  This string is always @code{NUL}-terminated, and contains
201 no embedded @code{NUL} characters.
202
203 @item IDENTIFIER_LENGTH
204 The length of the string returned by @code{IDENTIFIER_POINTER}, not
205 including the trailing @code{NUL}.  This value of
206 @code{IDENTIFIER_LENGTH (x)} is always the same as @code{strlen
207 (IDENTIFIER_POINTER (x))}.
208
209 @item IDENTIFIER_OPNAME_P
210 This predicate holds if the identifier represents the name of an
211 overloaded operator.  In this case, you should not depend on the
212 contents of either the @code{IDENTIFIER_POINTER} or the
213 @code{IDENTIFIER_LENGTH}.
214
215 @item IDENTIFIER_TYPENAME_P
216 This predicate holds if the identifier represents the name of a
217 user-defined conversion operator.  In this case, the @code{TREE_TYPE} of
218 the @code{IDENTIFIER_NODE} holds the type to which the conversion
219 operator converts.
220
221 @end ftable
222
223 @c ---------------------------------------------------------------------
224 @c Containers
225 @c ---------------------------------------------------------------------
226
227 @node Containers
228 @subsection Containers
229 @cindex container
230 @cindex list
231 @cindex vector
232 @tindex TREE_LIST
233 @tindex TREE_VEC
234 @findex TREE_PURPOSE
235 @findex TREE_VALUE
236 @findex TREE_VEC_LENGTH
237 @findex TREE_VEC_ELT
238
239 Two common container data structures can be represented directly with
240 tree nodes.  A @code{TREE_LIST} is a singly linked list containing two
241 trees per node.  These are the @code{TREE_PURPOSE} and @code{TREE_VALUE}
242 of each node.  (Often, the @code{TREE_PURPOSE} contains some kind of
243 tag, or additional information, while the @code{TREE_VALUE} contains the
244 majority of the payload.  In other cases, the @code{TREE_PURPOSE} is
245 simply @code{NULL_TREE}, while in still others both the
246 @code{TREE_PURPOSE} and @code{TREE_VALUE} are of equal stature.)  Given
247 one @code{TREE_LIST} node, the next node is found by following the
248 @code{TREE_CHAIN}.  If the @code{TREE_CHAIN} is @code{NULL_TREE}, then
249 you have reached the end of the list.
250
251 A @code{TREE_VEC} is a simple vector.  The @code{TREE_VEC_LENGTH} is an
252 integer (not a tree) giving the number of nodes in the vector.  The
253 nodes themselves are accessed using the @code{TREE_VEC_ELT} macro, which
254 takes two arguments.  The first is the @code{TREE_VEC} in question; the
255 second is an integer indicating which element in the vector is desired.
256 The elements are indexed from zero.
257
258 @c ---------------------------------------------------------------------
259 @c Types
260 @c ---------------------------------------------------------------------
261
262 @node Types
263 @section Types
264 @cindex type
265 @cindex pointer
266 @cindex reference
267 @cindex fundamental type
268 @cindex array
269 @tindex VOID_TYPE
270 @tindex INTEGER_TYPE
271 @tindex TYPE_MIN_VALUE
272 @tindex TYPE_MAX_VALUE
273 @tindex REAL_TYPE
274 @tindex COMPLEX_TYPE
275 @tindex ENUMERAL_TYPE
276 @tindex BOOLEAN_TYPE
277 @tindex POINTER_TYPE
278 @tindex REFERENCE_TYPE
279 @tindex FUNCTION_TYPE
280 @tindex METHOD_TYPE
281 @tindex ARRAY_TYPE
282 @tindex RECORD_TYPE
283 @tindex UNION_TYPE
284 @tindex UNKNOWN_TYPE
285 @tindex OFFSET_TYPE
286 @tindex TYPENAME_TYPE
287 @tindex TYPEOF_TYPE
288 @findex CP_TYPE_QUALS
289 @findex TYPE_UNQUALIFIED
290 @findex TYPE_QUAL_CONST
291 @findex TYPE_QUAL_VOLATILE
292 @findex TYPE_QUAL_RESTRICT
293 @findex TYPE_MAIN_VARIANT
294 @cindex qualified type
295 @findex TYPE_SIZE
296 @findex TYPE_ALIGN
297 @findex TYPE_PRECISION
298 @findex TYPE_ARG_TYPES
299 @findex TYPE_METHOD_BASETYPE
300 @findex TYPE_PTRMEM_P
301 @findex TYPE_OFFSET_BASETYPE
302 @findex TREE_TYPE
303 @findex TYPE_CONTEXT
304 @findex TYPE_NAME
305 @findex TYPENAME_TYPE_FULLNAME
306 @findex TYPE_FIELDS
307 @findex TYPE_PTROBV_P
308
309 All types have corresponding tree nodes.  However, you should not assume
310 that there is exactly one tree node corresponding to each type.  There
311 are often several nodes each of which correspond to the same type.
312
313 For the most part, different kinds of types have different tree codes.
314 (For example, pointer types use a @code{POINTER_TYPE} code while arrays
315 use an @code{ARRAY_TYPE} code.)  However, pointers to member functions
316 use the @code{RECORD_TYPE} code.  Therefore, when writing a
317 @code{switch} statement that depends on the code associated with a
318 particular type, you should take care to handle pointers to member
319 functions under the @code{RECORD_TYPE} case label.
320
321 In C++, an array type is not qualified; rather the type of the array
322 elements is qualified.  This situation is reflected in the intermediate
323 representation.  The macros described here will always examine the
324 qualification of the underlying element type when applied to an array
325 type.  (If the element type is itself an array, then the recursion
326 continues until a non-array type is found, and the qualification of this
327 type is examined.)  So, for example, @code{CP_TYPE_CONST_P} will hold of
328 the type @code{const int ()[7]}, denoting an array of seven @code{int}s.
329
330 The following functions and macros deal with cv-qualification of types:
331 @ftable @code
332 @item CP_TYPE_QUALS
333 This macro returns the set of type qualifiers applied to this type.
334 This value is @code{TYPE_UNQUALIFIED} if no qualifiers have been
335 applied.  The @code{TYPE_QUAL_CONST} bit is set if the type is
336 @code{const}-qualified.  The @code{TYPE_QUAL_VOLATILE} bit is set if the
337 type is @code{volatile}-qualified.  The @code{TYPE_QUAL_RESTRICT} bit is
338 set if the type is @code{restrict}-qualified.
339
340 @item CP_TYPE_CONST_P
341 This macro holds if the type is @code{const}-qualified.
342
343 @item CP_TYPE_VOLATILE_P
344 This macro holds if the type is @code{volatile}-qualified.
345
346 @item CP_TYPE_RESTRICT_P
347 This macro holds if the type is @code{restrict}-qualified.
348
349 @item CP_TYPE_CONST_NON_VOLATILE_P
350 This predicate holds for a type that is @code{const}-qualified, but
351 @emph{not} @code{volatile}-qualified; other cv-qualifiers are ignored as
352 well: only the @code{const}-ness is tested.
353
354 @item TYPE_MAIN_VARIANT
355 This macro returns the unqualified version of a type.  It may be applied
356 to an unqualified type, but it is not always the identity function in
357 that case.
358 @end ftable
359
360 A few other macros and functions are usable with all types:
361 @ftable @code
362 @item TYPE_SIZE
363 The number of bits required to represent the type, represented as an
364 @code{INTEGER_CST}.  For an incomplete type, @code{TYPE_SIZE} will be
365 @code{NULL_TREE}.
366
367 @item TYPE_ALIGN
368 The alignment of the type, in bits, represented as an @code{int}.
369
370 @item TYPE_NAME
371 This macro returns a declaration (in the form of a @code{TYPE_DECL}) for
372 the type.  (Note this macro does @emph{not} return a
373 @code{IDENTIFIER_NODE}, as you might expect, given its name!)  You can
374 look at the @code{DECL_NAME} of the @code{TYPE_DECL} to obtain the
375 actual name of the type.  The @code{TYPE_NAME} will be @code{NULL_TREE}
376 for a type that is not a built-in type, the result of a typedef, or a
377 named class type.
378
379 @item CP_INTEGRAL_TYPE
380 This predicate holds if the type is an integral type.  Notice that in
381 C++, enumerations are @emph{not} integral types.
382
383 @item ARITHMETIC_TYPE_P
384 This predicate holds if the type is an integral type (in the C++ sense)
385 or a floating point type.
386
387 @item CLASS_TYPE_P
388 This predicate holds for a class-type.
389
390 @item TYPE_BUILT_IN
391 This predicate holds for a built-in type.
392
393 @item TYPE_PTRMEM_P
394 This predicate holds if the type is a pointer to data member.
395
396 @item TYPE_PTR_P
397 This predicate holds if the type is a pointer type, and the pointee is
398 not a data member.
399
400 @item TYPE_PTRFN_P
401 This predicate holds for a pointer to function type.
402
403 @item TYPE_PTROB_P
404 This predicate holds for a pointer to object type.  Note however that it
405 does not hold for the generic pointer to object type @code{void *}.  You
406 may use @code{TYPE_PTROBV_P} to test for a pointer to object type as
407 well as @code{void *}.
408
409 @item same_type_p
410 This predicate takes two types as input, and holds if they are the same
411 type.  For example, if one type is a @code{typedef} for the other, or
412 both are @code{typedef}s for the same type.  This predicate also holds if
413 the two trees given as input are simply copies of one another; i.e.,
414 there is no difference between them at the source level, but, for
415 whatever reason, a duplicate has been made in the representation.  You
416 should never use @code{==} (pointer equality) to compare types; always
417 use @code{same_type_p} instead.
418 @end ftable
419
420 Detailed below are the various kinds of types, and the macros that can
421 be used to access them.  Although other kinds of types are used
422 elsewhere in G++, the types described here are the only ones that you
423 will encounter while examining the intermediate representation.
424
425 @table @code
426 @item VOID_TYPE
427 Used to represent the @code{void} type.
428
429 @item INTEGER_TYPE
430 Used to represent the various integral types, including @code{char},
431 @code{short}, @code{int}, @code{long}, and @code{long long}.  This code
432 is not used for enumeration types, nor for the @code{bool} type.  Note
433 that GCC's @code{CHAR_TYPE} node is @emph{not} used to represent
434 @code{char}.  The @code{TYPE_PRECISION} is the number of bits used in
435 the representation, represented as an @code{unsigned int}.  (Note that
436 in the general case this is not the same value as @code{TYPE_SIZE};
437 suppose that there were a 24-bit integer type, but that alignment
438 requirements for the ABI required 32-bit alignment.  Then,
439 @code{TYPE_SIZE} would be an @code{INTEGER_CST} for 32, while
440 @code{TYPE_PRECISION} would be 24.)  The integer type is unsigned if
441 @code{TREE_UNSIGNED} holds; otherwise, it is signed.
442
443 The @code{TYPE_MIN_VALUE} is an @code{INTEGER_CST} for the smallest
444 integer that may be represented by this type.  Similarly, the
445 @code{TYPE_MAX_VALUE} is an @code{INTEGER_CST} for the largest integer
446 that may be represented by this type.
447
448 @item REAL_TYPE
449 Used to represent the @code{float}, @code{double}, and @code{long
450 double} types.  The number of bits in the floating-point representation
451 is given by @code{TYPE_PRECISION}, as in the @code{INTEGER_TYPE} case.
452
453 @item COMPLEX_TYPE
454 Used to represent GCC built-in @code{__complex__} data types.  The
455 @code{TREE_TYPE} is the type of the real and imaginary parts.
456
457 @item ENUMERAL_TYPE
458 Used to represent an enumeration type.  The @code{TYPE_PRECISION} gives
459 (as an @code{int}), the number of bits used to represent the type.  If
460 there are no negative enumeration constants, @code{TREE_UNSIGNED} will
461 hold.  The minimum and maximum enumeration constants may be obtained
462 with @code{TYPE_MIN_VALUE} and @code{TYPE_MAX_VALUE}, respectively; each
463 of these macros returns an @code{INTEGER_CST}.
464
465 The actual enumeration constants themselves may be obtained by looking
466 at the @code{TYPE_VALUES}.  This macro will return a @code{TREE_LIST},
467 containing the constants.  The @code{TREE_PURPOSE} of each node will be
468 an @code{IDENTIFIER_NODE} giving the name of the constant; the
469 @code{TREE_VALUE} will be an @code{INTEGER_CST} giving the value
470 assigned to that constant.  These constants will appear in the order in
471 which they were declared.  The @code{TREE_TYPE} of each of these
472 constants will be the type of enumeration type itself.
473
474 @item BOOLEAN_TYPE
475 Used to represent the @code{bool} type.
476
477 @item POINTER_TYPE
478 Used to represent pointer types, and pointer to data member types.  The
479 @code{TREE_TYPE} gives the type to which this type points.  If the type
480 is a pointer to data member type, then @code{TYPE_PTRMEM_P} will hold.
481 For a pointer to data member type of the form @samp{T X::*},
482 @code{TYPE_PTRMEM_CLASS_TYPE} will be the type @code{X}, while
483 @code{TYPE_PTRMEM_POINTED_TO_TYPE} will be the type @code{T}.
484
485 @item REFERENCE_TYPE
486 Used to represent reference types.  The @code{TREE_TYPE} gives the type
487 to which this type refers.
488
489 @item FUNCTION_TYPE
490 Used to represent the type of non-member functions and of static member
491 functions.  The @code{TREE_TYPE} gives the return type of the function.
492 The @code{TYPE_ARG_TYPES} are a @code{TREE_LIST} of the argument types.
493 The @code{TREE_VALUE} of each node in this list is the type of the
494 corresponding argument; the @code{TREE_PURPOSE} is an expression for the
495 default argument value, if any.  If the last node in the list is
496 @code{void_list_node} (a @code{TREE_LIST} node whose @code{TREE_VALUE}
497 is the @code{void_type_node}), then functions of this type do not take
498 variable arguments.  Otherwise, they do take a variable number of
499 arguments.
500
501 Note that in C (but not in C++) a function declared like @code{void f()}
502 is an unprototyped function taking a variable number of arguments; the
503 @code{TYPE_ARG_TYPES} of such a function will be @code{NULL}.
504
505 @item METHOD_TYPE
506 Used to represent the type of a non-static member function.  Like a
507 @code{FUNCTION_TYPE}, the return type is given by the @code{TREE_TYPE}.
508 The type of @code{*this}, i.e., the class of which functions of this
509 type are a member, is given by the @code{TYPE_METHOD_BASETYPE}.  The
510 @code{TYPE_ARG_TYPES} is the parameter list, as for a
511 @code{FUNCTION_TYPE}, and includes the @code{this} argument.
512
513 @item ARRAY_TYPE
514 Used to represent array types.  The @code{TREE_TYPE} gives the type of
515 the elements in the array.  If the array-bound is present in the type,
516 the @code{TYPE_DOMAIN} is an @code{INTEGER_TYPE} whose
517 @code{TYPE_MIN_VALUE} and @code{TYPE_MAX_VALUE} will be the lower and
518 upper bounds of the array, respectively.  The @code{TYPE_MIN_VALUE} will
519 always be an @code{INTEGER_CST} for zero, while the
520 @code{TYPE_MAX_VALUE} will be one less than the number of elements in
521 the array, i.e., the highest value which may be used to index an element
522 in the array.
523
524 @item RECORD_TYPE
525 Used to represent @code{struct} and @code{class} types, as well as
526 pointers to member functions.  If @code{TYPE_PTRMEMFUNC_P} holds, then
527 this type is a pointer-to-member type.  In that case, the
528 @code{TYPE_PTRMEMFUNC_FN_TYPE} is a @code{POINTER_TYPE} pointing to a
529 @code{METHOD_TYPE}.  The @code{METHOD_TYPE} is the type of a function
530 pointed to by the pointer-to-member function.  If
531 @code{TYPE_PTRMEMFUNC_P} does not hold, this type is a class type.  For
532 more information, see @pxref{Classes}.
533
534 @item UNKNOWN_TYPE
535 This node is used to represent a type the knowledge of which is
536 insufficient for a sound processing.
537
538 @item OFFSET_TYPE
539 This node is used to represent a data member; for example a
540 pointer-to-data-member is represented by a @code{POINTER_TYPE} whose
541 @code{TREE_TYPE} is an @code{OFFSET_TYPE}.  For a data member @code{X::m}
542 the @code{TYPE_OFFSET_BASETYPE} is @code{X} and the @code{TREE_TYPE} is
543 the type of @code{m}.
544
545 @item TYPENAME_TYPE
546 Used to represent a construct of the form @code{typename T::A}.  The
547 @code{TYPE_CONTEXT} is @code{T}; the @code{TYPE_NAME} is an
548 @code{IDENTIFIER_NODE} for @code{A}.  If the type is specified via a
549 template-id, then @code{TYPENAME_TYPE_FULLNAME} yields a
550 @code{TEMPLATE_ID_EXPR}.  The @code{TREE_TYPE} is non-@code{NULL} if the
551 node is implicitly generated in support for the implicit typename
552 extension; in which case the @code{TREE_TYPE} is a type node for the
553 base-class.
554
555 @item TYPEOF_TYPE
556 Used to represent the @code{__typeof__} extension.  The
557 @code{TYPE_FIELDS} is the expression the type of which is being
558 represented.
559
560 @item UNION_TYPE
561 Used to represent @code{union} types.  For more information, @pxref{Classes}.
562 @end table
563
564 There are variables whose values represent some of the basic types.
565 These include:
566 @table @code
567 @item void_type_node
568 A node for @code{void}.
569
570 @item integer_type_node
571 A node for @code{int}.
572
573 @item unsigned_type_node.
574 A node for @code{unsigned int}.
575
576 @item char_type_node.
577 A node for @code{char}.
578 @end table
579 @noindent
580 It may sometimes be useful to compare one of these variables with a type
581 in hand, using @code{same_type_p}.
582
583 @c ---------------------------------------------------------------------
584 @c Scopes
585 @c ---------------------------------------------------------------------
586
587 @node Scopes
588 @section Scopes
589 @cindex namespace, class, scope
590
591 The root of the entire intermediate representation is the variable
592 @code{global_namespace}.  This is the namespace specified with @code{::}
593 in C++ source code.  All other namespaces, types, variables, functions,
594 and so forth can be found starting with this namespace.
595
596 Besides namespaces, the other high-level scoping construct in C++ is the
597 class.  (Throughout this manual the term @dfn{class} is used to mean the
598 types referred to in the ANSI/ISO C++ Standard as classes; these include
599 types defined with the @code{class}, @code{struct}, and @code{union}
600 keywords.)
601
602 @menu
603 * Namespaces::          Member functions, types, etc.
604 * Classes::             Members, bases, friends, etc.
605 @end menu
606
607 @c ---------------------------------------------------------------------
608 @c Namespaces
609 @c ---------------------------------------------------------------------
610
611 @node Namespaces
612 @subsection Namespaces
613 @cindex namespace
614 @tindex NAMESPACE_DECL
615
616 A namespace is represented by a @code{NAMESPACE_DECL} node.
617
618 However, except for the fact that it is distinguished as the root of the
619 representation, the global namespace is no different from any other
620 namespace.  Thus, in what follows, we describe namespaces generally,
621 rather than the global namespace in particular.
622
623 The following macros and functions can be used on a @code{NAMESPACE_DECL}:
624
625 @ftable @code
626 @item DECL_NAME
627 This macro is used to obtain the @code{IDENTIFIER_NODE} corresponding to
628 the unqualified name of the name of the namespace (@pxref{Identifiers}).
629 The name of the global namespace is @samp{::}, even though in C++ the
630 global namespace is unnamed.  However, you should use comparison with
631 @code{global_namespace}, rather than @code{DECL_NAME} to determine
632 whether or not a namespaces is the global one.  An unnamed namespace
633 will have a @code{DECL_NAME} equal to @code{anonymous_namespace_name}.
634 Within a single translation unit, all unnamed namespaces will have the
635 same name.
636
637 @item DECL_CONTEXT
638 This macro returns the enclosing namespace.  The @code{DECL_CONTEXT} for
639 the @code{global_namespace} is @code{NULL_TREE}.
640
641 @item DECL_NAMESPACE_ALIAS
642 If this declaration is for a namespace alias, then
643 @code{DECL_NAMESPACE_ALIAS} is the namespace for which this one is an
644 alias.
645
646 Do not attempt to use @code{cp_namespace_decls} for a namespace which is
647 an alias.  Instead, follow @code{DECL_NAMESPACE_ALIAS} links until you
648 reach an ordinary, non-alias, namespace, and call
649 @code{cp_namespace_decls} there.
650
651 @item DECL_NAMESPACE_STD_P
652 This predicate holds if the namespace is the special @code{::std}
653 namespace.
654
655 @item cp_namespace_decls
656 This function will return the declarations contained in the namespace,
657 including types, overloaded functions, other namespaces, and so forth.
658 If there are no declarations, this function will return
659 @code{NULL_TREE}.  The declarations are connected through their
660 @code{TREE_CHAIN} fields.
661
662 Although most entries on this list will be declarations,
663 @code{TREE_LIST} nodes may also appear.  In this case, the
664 @code{TREE_VALUE} will be an @code{OVERLOAD}.  The value of the
665 @code{TREE_PURPOSE} is unspecified; back ends should ignore this value.
666 As with the other kinds of declarations returned by
667 @code{cp_namespace_decls}, the @code{TREE_CHAIN} will point to the next
668 declaration in this list.
669
670 For more information on the kinds of declarations that can occur on this
671 list, @xref{Declarations}.  Some declarations will not appear on this
672 list.  In particular, no @code{FIELD_DECL}, @code{LABEL_DECL}, or
673 @code{PARM_DECL} nodes will appear here.
674
675 This function cannot be used with namespaces that have
676 @code{DECL_NAMESPACE_ALIAS} set.
677
678 @end ftable
679
680 @c ---------------------------------------------------------------------
681 @c Classes
682 @c ---------------------------------------------------------------------
683
684 @node Classes
685 @subsection Classes
686 @cindex class
687 @tindex RECORD_TYPE
688 @tindex UNION_TYPE
689 @findex CLASSTYPE_DECLARED_CLASS
690 @findex TYPE_BINFO
691 @findex BINFO_TYPE
692 @findex TREE_VIA_PUBLIC
693 @findex TREE_VIA_PROTECTED
694 @findex TREE_VIA_PRIVATE
695 @findex TYPE_FIELDS
696 @findex TYPE_VFIELD
697 @findex TYPE_METHODS
698
699 A class type is represented by either a @code{RECORD_TYPE} or a
700 @code{UNION_TYPE}.  A class declared with the @code{union} tag is
701 represented by a @code{UNION_TYPE}, while classes declared with either
702 the @code{struct} or the @code{class} tag are represented by
703 @code{RECORD_TYPE}s.  You can use the @code{CLASSTYPE_DECLARED_CLASS}
704 macro to discern whether or not a particular type is a @code{class} as
705 opposed to a @code{struct}.  This macro will be true only for classes
706 declared with the @code{class} tag.
707
708 Almost all non-function members are available on the @code{TYPE_FIELDS}
709 list.  Given one member, the next can be found by following the
710 @code{TREE_CHAIN}.  You should not depend in any way on the order in
711 which fields appear on this list.  All nodes on this list will be
712 @samp{DECL} nodes.  A @code{FIELD_DECL} is used to represent a non-static
713 data member, a @code{VAR_DECL} is used to represent a static data
714 member, and a @code{TYPE_DECL} is used to represent a type.  Note that
715 the @code{CONST_DECL} for an enumeration constant will appear on this
716 list, if the enumeration type was declared in the class.  (Of course,
717 the @code{TYPE_DECL} for the enumeration type will appear here as well.)
718 There are no entries for base classes on this list.  In particular,
719 there is no @code{FIELD_DECL} for the ``base-class portion'' of an
720 object.
721
722 The @code{TYPE_VFIELD} is a compiler-generated field used to point to
723 virtual function tables.  It may or may not appear on the
724 @code{TYPE_FIELDS} list.  However, back ends should handle the
725 @code{TYPE_VFIELD} just like all the entries on the @code{TYPE_FIELDS}
726 list.
727
728 The function members are available on the @code{TYPE_METHODS} list.
729 Again, subsequent members are found by following the @code{TREE_CHAIN}
730 field.  If a function is overloaded, each of the overloaded functions
731 appears; no @code{OVERLOAD} nodes appear on the @code{TYPE_METHODS}
732 list.  Implicitly declared functions (including default constructors,
733 copy constructors, assignment operators, and destructors) will appear on
734 this list as well.
735
736 Every class has an associated @dfn{binfo}, which can be obtained with
737 @code{TYPE_BINFO}.  Binfos are used to represent base-classes.  The
738 binfo given by @code{TYPE_BINFO} is the degenerate case, whereby every
739 class is considered to be its own base-class.  The base classes for a
740 particular binfo can be obtained with @code{BINFO_BASETYPES}.  These
741 base-classes are themselves binfos.  The class type associated with a
742 binfo is given by @code{BINFO_TYPE}.  It is always the case that
743 @code{BINFO_TYPE (TYPE_BINFO (x))} is the same type as @code{x}, up to
744 qualifiers.  However, it is not always the case that @code{TYPE_BINFO
745 (BINFO_TYPE (y))} is always the same binfo as @code{y}.  The reason is
746 that if @code{y} is a binfo representing a base-class @code{B} of a
747 derived class @code{D}, then @code{BINFO_TYPE (y)} will be @code{B}, and
748 @code{TYPE_INFO (BINFO_TYPE (y))} will be @code{B} as its own
749 base-class, rather than as a base-class of @code{D}.
750
751 The @code{BINFO_BASETYPES} is a @code{TREE_VEC} (@pxref{Containers}).
752 Base types appear in left-to-right order in this vector.  You can tell
753 whether or @code{public}, @code{protected}, or @code{private}
754 inheritance was used by using the @code{TREE_VIA_PUBLIC},
755 @code{TREE_VIA_PROTECTED}, and @code{TREE_VIA_PRIVATE} macros.  Each of
756 these macros takes a @code{BINFO} and is true if and only if the
757 indicated kind of inheritance was used.  If @code{TREE_VIA_VIRTUAL}
758 holds of a binfo, then its @code{BINFO_TYPE} was inherited from
759 virtually.
760
761 The following macros can be used on a tree node representing a class-type.
762
763 @ftable @code
764 @item LOCAL_CLASS_P
765 This predicate holds if the class is local class @emph{i.e.} declared
766 inside a function body.
767
768 @item TYPE_POLYMORPHIC_P
769 This predicate holds if the class has at least one virtual function
770 (declared or inherited).
771
772 @item TYPE_HAS_DEFAULT_CONSTRUCTOR
773 This predicate holds whenever its argument represents a class-type with
774 default constructor.
775
776 @item CLASSTYPE_HAS_MUTABLE
777 @item TYPE_HAS_MUTABLE_P
778 These predicates hold for a class-type having a mutable data member.
779
780 @item CLASSTYPE_NON_POD_P
781 This predicate holds only for class-types that are not PODs.
782
783 @item TYPE_HAS_NEW_OPERATOR
784 This predicate holds for a class-type that defines
785 @code{operator new}.
786
787 @item TYPE_HAS_ARRAY_NEW_OPERATOR
788 This predicate holds for a class-type for which
789 @code{operator new[]} is defined.
790
791 @item TYPE_OVERLOADS_CALL_EXPR
792 This predicate holds for class-type for which the function call
793 @code{operator()} is overloaded.
794
795 @item TYPE_OVERLOADS_ARRAY_REF
796 This predicate holds for a class-type that overloads
797 @code{operator[]}
798
799 @item TYPE_OVERLOADS_ARROW
800 This predicate holds for a class-type for which @code{operator->} is
801 overloaded.
802
803 @end ftable
804
805 @c ---------------------------------------------------------------------
806 @c Declarations
807 @c ---------------------------------------------------------------------
808
809 @node Declarations
810 @section Declarations
811 @cindex declaration
812 @cindex variable
813 @cindex type declaration
814 @tindex LABEL_DECL
815 @tindex CONST_DECL
816 @tindex TYPE_DECL
817 @tindex VAR_DECL
818 @tindex PARM_DECL
819 @tindex FIELD_DECL
820 @tindex NAMESPACE_DECL
821 @tindex RESULT_DECL
822 @tindex TEMPLATE_DECL
823 @tindex THUNK_DECL
824 @tindex USING_DECL
825 @findex THUNK_DELTA
826 @findex DECL_INITIAL
827 @findex DECL_SIZE
828 @findex DECL_ALIGN
829 @findex DECL_EXTERNAL
830
831 This section covers the various kinds of declarations that appear in the
832 internal representation, except for declarations of functions
833 (represented by @code{FUNCTION_DECL} nodes), which are described in
834 @ref{Functions}.
835
836 Some macros can be used with any kind of declaration.  These include:
837 @ftable @code
838 @item DECL_NAME
839 This macro returns an @code{IDENTIFIER_NODE} giving the name of the
840 entity.
841
842 @item TREE_TYPE
843 This macro returns the type of the entity declared.
844
845 @item DECL_SOURCE_FILE
846 This macro returns the name of the file in which the entity was
847 declared, as a @code{char*}.  For an entity declared implicitly by the
848 compiler (like @code{__builtin_memcpy}), this will be the string
849 @code{"<internal>"}.
850
851 @item DECL_SOURCE_LINE
852 This macro returns the line number at which the entity was declared, as
853 an @code{int}.
854
855 @item DECL_ARTIFICIAL
856 This predicate holds if the declaration was implicitly generated by the
857 compiler.  For example, this predicate will hold of an implicitly
858 declared member function, or of the @code{TYPE_DECL} implicitly
859 generated for a class type.  Recall that in C++ code like:
860 @example
861 struct S @{@};
862 @end example
863 @noindent
864 is roughly equivalent to C code like:
865 @example
866 struct S @{@};
867 typedef struct S S;
868 @end example
869 The implicitly generated @code{typedef} declaration is represented by a
870 @code{TYPE_DECL} for which @code{DECL_ARTIFICIAL} holds.
871
872 @item DECL_NAMESPACE_SCOPE_P
873 This predicate holds if the entity was declared at a namespace scope.
874
875 @item DECL_CLASS_SCOPE_P
876 This predicate holds if the entity was declared at a class scope.
877
878 @item DECL_FUNCTION_SCOPE_P
879 This predicate holds if the entity was declared inside a function
880 body.
881
882 @end ftable
883
884 The various kinds of declarations include:
885 @table @code
886 @item LABEL_DECL
887 These nodes are used to represent labels in function bodies.  For more
888 information, see @ref{Functions}.  These nodes only appear in block
889 scopes.
890
891 @item CONST_DECL
892 These nodes are used to represent enumeration constants.  The value of
893 the constant is given by @code{DECL_INITIAL} which will be an
894 @code{INTEGER_CST} with the same type as the @code{TREE_TYPE} of the
895 @code{CONST_DECL}, i.e., an @code{ENUMERAL_TYPE}.
896
897 @item RESULT_DECL
898 These nodes represent the value returned by a function.  When a value is
899 assigned to a @code{RESULT_DECL}, that indicates that the value should
900 be returned, via bitwise copy, by the function.  You can use
901 @code{DECL_SIZE} and @code{DECL_ALIGN} on a @code{RESULT_DECL}, just as
902 with a @code{VAR_DECL}.
903
904 @item TYPE_DECL
905 These nodes represent @code{typedef} declarations.  The @code{TREE_TYPE}
906 is the type declared to have the name given by @code{DECL_NAME}.  In
907 some cases, there is no associated name.
908
909 @item VAR_DECL
910 These nodes represent variables with namespace or block scope, as well
911 as static data members.  The @code{DECL_SIZE} and @code{DECL_ALIGN} are
912 analogous to @code{TYPE_SIZE} and @code{TYPE_ALIGN}.  For a declaration,
913 you should always use the @code{DECL_SIZE} and @code{DECL_ALIGN} rather
914 than the @code{TYPE_SIZE} and @code{TYPE_ALIGN} given by the
915 @code{TREE_TYPE}, since special attributes may have been applied to the
916 variable to give it a particular size and alignment.  You may use the
917 predicates @code{DECL_THIS_STATIC} or @code{DECL_THIS_EXTERN} to test
918 whether the storage class specifiers @code{static} or @code{extern} were
919 used to declare a variable.
920
921 If this variable is initialized (but does not require a constructor),
922 the @code{DECL_INITIAL} will be an expression for the initializer.  The
923 initializer should be evaluated, and a bitwise copy into the variable
924 performed.  If the @code{DECL_INITIAL} is the @code{error_mark_node},
925 there is an initializer, but it is given by an explicit statement later
926 in the code; no bitwise copy is required.
927
928 GCC provides an extension that allows either automatic variables, or
929 global variables, to be placed in particular registers.  This extension
930 is being used for a particular @code{VAR_DECL} if @code{DECL_REGISTER}
931 holds for the @code{VAR_DECL}, and if @code{DECL_ASSEMBLER_NAME} is not
932 equal to @code{DECL_NAME}.  In that case, @code{DECL_ASSEMBLER_NAME} is
933 the name of the register into which the variable will be placed.
934
935 @item PARM_DECL
936 Used to represent a parameter to a function.  Treat these nodes
937 similarly to @code{VAR_DECL} nodes.  These nodes only appear in the
938 @code{DECL_ARGUMENTS} for a @code{FUNCTION_DECL}.
939
940 The @code{DECL_ARG_TYPE} for a @code{PARM_DECL} is the type that will
941 actually be used when a value is passed to this function.  It may be a
942 wider type than the @code{TREE_TYPE} of the parameter; for example, the
943 ordinary type might be @code{short} while the @code{DECL_ARG_TYPE} is
944 @code{int}.
945
946 @item FIELD_DECL
947 These nodes represent non-static data members.  The @code{DECL_SIZE} and
948 @code{DECL_ALIGN} behave as for @code{VAR_DECL} nodes.  The
949 @code{DECL_FIELD_BITPOS} gives the first bit used for this field, as an
950 @code{INTEGER_CST}.  These values are indexed from zero, where zero
951 indicates the first bit in the object.
952
953 If @code{DECL_C_BIT_FIELD} holds, this field is a bit-field.
954
955 @item NAMESPACE_DECL
956 @xref{Namespaces}.
957
958 @item TEMPLATE_DECL
959
960 These nodes are used to represent class, function, and variable (static
961 data member) templates.  The @code{DECL_TEMPLATE_SPECIALIZATIONS} are a
962 @code{TREE_LIST}.  The @code{TREE_VALUE} of each node in the list is a
963 @code{TEMPLATE_DECL}s or @code{FUNCTION_DECL}s representing
964 specializations (including instantiations) of this template.  Back ends
965 can safely ignore @code{TEMPLATE_DECL}s, but should examine
966 @code{FUNCTION_DECL} nodes on the specializations list just as they
967 would ordinary @code{FUNCTION_DECL} nodes.
968
969 For a class template, the @code{DECL_TEMPLATE_INSTANTIATIONS} list
970 contains the instantiations.  The @code{TREE_VALUE} of each node is an
971 instantiation of the class.  The @code{DECL_TEMPLATE_SPECIALIZATIONS}
972 contains partial specializations of the class.
973
974 @item USING_DECL
975
976 Back ends can safely ignore these nodes.
977
978 @end table
979
980 @c ---------------------------------------------------------------------
981 @c Functions
982 @c ---------------------------------------------------------------------
983
984 @node Functions
985 @section Functions
986 @cindex function
987 @tindex FUNCTION_DECL
988 @tindex OVERLOAD
989 @findex OVL_CURRENT
990 @findex OVL_NEXT
991
992 A function is represented by a @code{FUNCTION_DECL} node.  A set of
993 overloaded functions is sometimes represented by a @code{OVERLOAD} node.
994
995 An @code{OVERLOAD} node is not a declaration, so none of the
996 @samp{DECL_} macros should be used on an @code{OVERLOAD}.  An
997 @code{OVERLOAD} node is similar to a @code{TREE_LIST}.  Use
998 @code{OVL_CURRENT} to get the function associated with an
999 @code{OVERLOAD} node; use @code{OVL_NEXT} to get the next
1000 @code{OVERLOAD} node in the list of overloaded functions.  The macros
1001 @code{OVL_CURRENT} and @code{OVL_NEXT} are actually polymorphic; you can
1002 use them to work with @code{FUNCTION_DECL} nodes as well as with
1003 overloads.  In the case of a @code{FUNCTION_DECL}, @code{OVL_CURRENT}
1004 will always return the function itself, and @code{OVL_NEXT} will always
1005 be @code{NULL_TREE}.
1006
1007 To determine the scope of a function, you can use the
1008 @code{DECL_REAL_CONTEXT} macro.  This macro will return the class
1009 (either a @code{RECORD_TYPE} or a @code{UNION_TYPE}) or namespace (a
1010 @code{NAMESPACE_DECL}) of which the function is a member.  For a virtual
1011 function, this macro returns the class in which the function was
1012 actually defined, not the base class in which the virtual declaration
1013 occurred.  If a friend function is defined in a class scope, the
1014 @code{DECL_CLASS_CONTEXT} macro can be used to determine the class in
1015 which it was defined.  For example, in
1016 @example
1017 class C @{ friend void f() @{@} @};
1018 @end example
1019 the @code{DECL_REAL_CONTEXT} for @code{f} will be the
1020 @code{global_namespace}, but the @code{DECL_CLASS_CONTEXT} will be the
1021 @code{RECORD_TYPE} for @code{C}.
1022
1023 The @code{DECL_REAL_CONTEXT} and @code{DECL_CLASS_CONTEXT} are not
1024 available in C; instead you should simply use @code{DECL_CONTEXT}.  In C,
1025 the @code{DECL_CONTEXT} for a function maybe another function.  This
1026 representation indicates that the GNU nested function extension is in
1027 use.  For details on the semantics of nested functions, see the GCC
1028 Manual.  The nested function can refer to local variables in its
1029 containing function.  Such references are not explicitly marked in the
1030 tree structure; back ends must look at the @code{DECL_CONTEXT} for the
1031 referenced @code{VAR_DECL}.  If the @code{DECL_CONTEXT} for the
1032 referenced @code{VAR_DECL} is not the same as the function currently
1033 being processed, and neither @code{DECL_EXTERNAL} nor @code{DECL_STATIC}
1034 hold, then the reference is to a local variable in a containing
1035 function, and the back end must take appropriate action.
1036
1037 @menu
1038 * Function Basics::     Function names, linkage, and so forth.
1039 * Function Bodies::     The statements that make up a function body.
1040 @end menu
1041
1042 @c ---------------------------------------------------------------------
1043 @c Function Basics
1044 @c ---------------------------------------------------------------------
1045
1046 @node Function Basics
1047 @subsection Function Basics
1048 @cindex constructor
1049 @cindex destructor
1050 @cindex copy constructor
1051 @cindex assignment operator
1052 @cindex linkage
1053 @findex DECL_NAME
1054 @findex DECL_ASSEMBLER_NAME
1055 @findex TREE_PUBLIC
1056 @findex DECL_LINKONCE_P
1057 @findex DECL_FUNCTION_MEMBER_P
1058 @findex DECL_CONSTRUCTOR_P
1059 @findex DECL_DESTRUCTOR_P
1060 @findex DECL_OVERLOADED_OPERATOR_P
1061 @findex DECL_CONV_FN_P
1062 @findex DECL_ARTIFICIAL
1063 @findex DECL_GLOBAL_CTOR_P
1064 @findex DECL_GLOBAL_DTOR_P
1065 @findex GLOBAL_INIT_PRIORITY
1066
1067 The following macros and functions can be used on a @code{FUNCTION_DECL}:
1068 @ftable @code
1069 @item DECL_MAIN_P
1070 This predicate holds for a function that is the program entry point
1071 @code{::code}.
1072
1073 @item DECL_NAME
1074 This macro returns the unqualified name of the function, as an
1075 @code{IDENTIFIER_NODE}.  For an instantiation of a function template,
1076 the @code{DECL_NAME} is the unqualified name of the template, not
1077 something like @code{f<int>}.  The value of @code{DECL_NAME} is
1078 undefined when used on a constructor, destructor, overloaded operator,
1079 or type-conversion operator, or any function that is implicitly
1080 generated by the compiler.  See below for macros that can be used to
1081 distinguish these cases.
1082
1083 @item DECL_ASSEMBLER_NAME
1084 This macro returns the mangled name of the function, also an
1085 @code{IDENTIFIER_NODE}.  This name does not contain leading underscores
1086 on systems that prefix all identifiers with underscores.  The mangled
1087 name is computed in the same way on all platforms; if special processing
1088 is required to deal with the object file format used on a particular
1089 platform, it is the responsibility of the back end to perform those
1090 modifications.  (Of course, the back end should not modify
1091 @code{DECL_ASSEMBLER_NAME} itself.)
1092
1093 @item DECL_EXTERNAL
1094 This predicate holds if the function is undefined.
1095
1096 @item TREE_PUBLIC
1097 This predicate holds if the function has external linkage.
1098
1099 @item DECL_LOCAL_FUNCTION_P
1100 This predicate holds if the function was declared at block scope, even
1101 though it has a global scope.
1102
1103 @item DECL_ANTICIPATED
1104 This predicate holds if the function is a built-in function but its
1105 prototype is not yet explicitly declared.
1106
1107 @item DECL_EXTERN_C_FUNCTION_P
1108 This predicate holds if the function is declared as an
1109 `@code{extern "C"}' function.
1110
1111 @item DECL_LINKONCE_P
1112 This macro holds if multiple copies of this function may be emitted in
1113 various translation units.  It is the responsibility of the linker to
1114 merge the various copies.  Template instantiations are the most common
1115 example of functions for which @code{DECL_LINKONCE_P} holds; G++
1116 instantiates needed templates in all translation units which require them,
1117 and then relies on the linker to remove duplicate instantiations.
1118
1119 FIXME: This macro is not yet implemented.
1120
1121 @item DECL_FUNCTION_MEMBER_P
1122 This macro holds if the function is a member of a class, rather than a
1123 member of a namespace.
1124
1125 @item DECL_STATIC_FUNCTION_P
1126 This predicate holds if the function a static member function.
1127
1128 @item DECL_NONSTATIC_MEMBER_FUNCTION_P
1129 This macro holds for a non-static member function.
1130
1131 @item DECL_CONST_MEMFUNC_P
1132 This predicate holds for a @code{const}-member function.
1133
1134 @item DECL_VOLATILE_MEMFUNC_P
1135 This predicate holds for a @code{volatile}-member function.
1136
1137 @item DECL_CONSTRUCTOR_P
1138 This macro holds if the function is a constructor.
1139
1140 @item DECL_NONCONVERTING_P
1141 This predicate holds if the constructor is a non-converting constructor.
1142
1143 @item DECL_COMPLETE_CONSTRUCTOR_P
1144 This predicate holds for a function which is a constructor for an object
1145 of a complete type.
1146
1147 @item DECL_BASE_CONSTRUCTOR_P
1148 This predicate holds for a function which is a constructor for a base
1149 class sub-object.
1150
1151 @item DECL_COPY_CONSTRUCTOR_P
1152 This predicate holds for a function which is a copy-constructor.
1153
1154 @item DECL_DESTRUCTOR_P
1155 This macro holds if the function is a destructor.
1156
1157 @item DECL_COMPLETE_DESTRUCTOR_P
1158 This predicate holds if the function is the destructor for an object a
1159 complete type.
1160
1161 @item DECL_OVERLOADED_OPERATOR_P
1162 This macro holds if the function is an overloaded operator.
1163
1164 @item DECL_CONV_FN_P
1165 This macro holds if the function is a type-conversion operator.
1166
1167 @item DECL_GLOBAL_CTOR_P
1168 This predicate holds if the function is a file-scope initialization
1169 function.
1170
1171 @item DECL_GLOBAL_DTOR_P
1172 This predicate holds if the function is a file-scope finalization
1173 function.
1174
1175 @item DECL_THUNK_P
1176 This predicate holds if the function is a thunk.
1177
1178 These functions represent stub code that adjusts the @code{this} pointer
1179 and then jumps to another function.  When the jumped-to function
1180 returns, control is transferred directly to the caller, without
1181 returning to the thunk.  The first parameter to the thunk is always the
1182 @code{this} pointer; the thunk should add @code{THUNK_DELTA} to this
1183 value.  (The @code{THUNK_DELTA} is an @code{int}, not an
1184 @code{INTEGER_CST}.)
1185
1186 Then, if @code{THUNK_VCALL_OFFSET} (an @code{INTEGER_CST}) is non-zero
1187 the adjusted @code{this} pointer must be adjusted again.  The complete
1188 calculation is given by the following pseudo-code:
1189
1190 @example
1191 this += THUNK_DELTA
1192 if (THUNK_VCALL_OFFSET)
1193   this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET]
1194 @end example
1195
1196 Finally, the thunk should jump to the location given
1197 by @code{DECL_INITIAL}; this will always be an expression for the
1198 address of a function.
1199
1200 @item DECL_NON_THUNK_FUNCTION_P
1201 This predicate holds if the function is @emph{not} a thunk function.
1202
1203 @item GLOBAL_INIT_PRIORITY
1204 If either @code{DECL_GLOBAL_CTOR_P} or @code{DECL_GLOBAL_DTOR_P} holds,
1205 then this gives the initialization priority for the function.  The
1206 linker will arrange that all functions for which
1207 @code{DECL_GLOBAL_CTOR_P} holds are run in increasing order of priority
1208 before @code{main} is called.  When the program exits, all functions for
1209 which @code{DECL_GLOBAL_DTOR_P} holds are run in the reverse order.
1210
1211 @item DECL_ARTIFICIAL
1212 This macro holds if the function was implicitly generated by the
1213 compiler, rather than explicitly declared.  In addition to implicitly
1214 generated class member functions, this macro holds for the special
1215 functions created to implement static initialization and destruction, to
1216 compute run-time type information, and so forth.
1217
1218 @item DECL_ARGUMENTS
1219 This macro returns the @code{PARM_DECL} for the first argument to the
1220 function.  Subsequent @code{PARM_DECL} nodes can be obtained by
1221 following the @code{TREE_CHAIN} links.
1222
1223 @item DECL_RESULT
1224 This macro returns the @code{RESULT_DECL} for the function.
1225
1226 @item TREE_TYPE
1227 This macro returns the @code{FUNCTION_TYPE} or @code{METHOD_TYPE} for
1228 the function.
1229
1230 @item TYPE_RAISES_EXCEPTIONS
1231 This macro returns the list of exceptions that a (member-)function can
1232 raise.  The returned list, if non @code{NULL}, is comprised of nodes
1233 whose @code{TREE_VALUE} represents a type.
1234
1235 @item TYPE_NOTHROW_P
1236 This predicate holds when the exception-specification of its arguments
1237 if of the form `@code{()}'.
1238
1239 @item DECL_ARRAY_DELETE_OPERATOR_P
1240 This predicate holds if the function an overloaded
1241 @code{operator delete[]}.
1242
1243 @end ftable
1244
1245 @c ---------------------------------------------------------------------
1246 @c Function Bodies
1247 @c ---------------------------------------------------------------------
1248
1249 @node Function Bodies
1250 @subsection Function Bodies
1251 @cindex function body
1252 @cindex statements
1253 @tindex ASM_STMT
1254 @findex ASM_STRING
1255 @findex ASM_CV_QUAL
1256 @findex ASM_INPUTS
1257 @findex ASM_OUTPUTS
1258 @findex ASM_CLOBBERS
1259 @tindex BREAK_STMT
1260 @tindex CLEANUP_STMT
1261 @findex CLEANUP_DECL
1262 @findex CLEANUP_EXPR
1263 @tindex COMPOUND_STMT
1264 @findex COMPOUND_BODY
1265 @tindex CONTINUE_STMT
1266 @tindex DECL_STMT
1267 @findex DECL_STMT_DECL
1268 @tindex DO_STMT
1269 @findex DO_BODY
1270 @findex DO_COND
1271 @tindex EMPTY_CLASS_EXPR
1272 @tindex EXPR_STMT
1273 @findex EXPR_STMT_EXPR
1274 @tindex FOR_STMT
1275 @findex FOR_INIT_STMT
1276 @findex FOR_COND
1277 @findex FOR_EXPR
1278 @findex FOR_BODY
1279 @tindex GOTO_STMT
1280 @findex GOTO_DESTINATION
1281 @tindex HANDLER
1282 @tindex IF_STMT
1283 @findex IF_COND
1284 @findex THEN_CLAUSE
1285 @findex ELSE_CLAUSE
1286 @tindex LABEL_STMT
1287 @tindex LABEL_STMT_LABEL
1288 @tindex RETURN_INIT
1289 @tindex RETURN_STMT
1290 @findex RETURN_EXPR
1291 @tindex SCOPE_STMT
1292 @findex SCOPE_BEGIN_P
1293 @findex SCOPE_END_P
1294 @findex SCOPE_NULLIFIED_P
1295 @tindex SUBOBJECT
1296 @findex SUBOBJECT_CLEANUP
1297 @tindex SWITCH_STMT
1298 @findex SWITCH_COND
1299 @findex SWITCH_BODY
1300 @tindex TRY_BLOCK
1301 @findex TRY_STMTS
1302 @findex TRY_HANDLERS
1303 @findex HANDLER_PARMS
1304 @findex HANDLER_BODY
1305 @findex USING_STMT
1306 @tindex WHILE_STMT
1307 @findex WHILE_BODY
1308 @findex WHILE_COND
1309
1310 A function that has a definition in the current translation unit will
1311 have a non-@code{NULL} @code{DECL_INITIAL}.  However, back ends should not make
1312 use of the particular value given by @code{DECL_INITIAL}.
1313
1314 The @code{DECL_SAVED_TREE} macro will give the complete body of the
1315 function.  This node will usually be a @code{COMPOUND_STMT} representing
1316 the outermost block of the function, but it may also be a
1317 @code{TRY_BLOCK}, a @code{RETURN_INIT}, or any other valid statement.
1318
1319 @subsubsection Statements
1320
1321 There are tree nodes corresponding to all of the source-level statement
1322 constructs.  These are enumerated here, together with a list of the
1323 various macros that can be used to obtain information about them.  There
1324 are a few macros that can be used with all statements:
1325
1326 @ftable @code
1327 @item STMT_LINENO
1328 This macro returns the line number for the statement.  If the statement
1329 spans multiple lines, this value will be the number of the first line on
1330 which the statement occurs.  Although we mention @code{CASE_LABEL} below
1331 as if it were a statement, they do not allow the use of
1332 @code{STMT_LINENO}.  There is no way to obtain the line number for a
1333 @code{CASE_LABEL}.
1334
1335 Statements do not contain information about
1336 the file from which they came; that information is implicit in the
1337 @code{FUNCTION_DECL} from which the statements originate.
1338
1339 @item STMT_IS_FULL_EXPR_P
1340 In C++, statements normally constitute ``full expressions''; temporaries
1341 created during a statement are destroyed when the statement is complete.
1342 However, G++ sometimes represents expressions by statements; these
1343 statements will not have @code{STMT_IS_FULL_EXPR_P} set.  Temporaries
1344 created during such statements should be destroyed when the innermost
1345 enclosing statement with @code{STMT_IS_FULL_EXPR_P} set is exited.
1346
1347 @end ftable
1348
1349 Here is the list of the various statement nodes, and the macros used to
1350 access them.  This documentation describes the use of these nodes in
1351 non-template functions (including instantiations of template functions).
1352 In template functions, the same nodes are used, but sometimes in
1353 slightly different ways.
1354
1355 Many of the statements have substatements.  For example, a @code{while}
1356 loop will have a body, which is itself a statement.  If the substatement
1357 is @code{NULL_TREE}, it is considered equivalent to a statement
1358 consisting of a single @code{;}, i.e., an expression statement in which
1359 the expression has been omitted.  A substatement may in fact be a list
1360 of statements, connected via their @code{TREE_CHAIN}s.  So, you should
1361 always process the statement tree by looping over substatements, like
1362 this:
1363 @example
1364 void process_stmt (stmt)
1365      tree stmt;
1366 @{
1367   while (stmt)
1368     @{
1369       switch (TREE_CODE (stmt))
1370         @{
1371         case IF_STMT:
1372           process_stmt (THEN_CLAUSE (stmt));
1373           /* More processing here.  */
1374           break;
1375
1376         @dots{}
1377         @}
1378
1379       stmt = TREE_CHAIN (stmt);
1380     @}
1381 @}
1382 @end example
1383 In other words, while the @code{then} clause of an @code{if} statement
1384 in C++ can be only one statement (although that one statement may be a
1385 compound statement), the intermediate representation will sometimes use
1386 several statements chained together.
1387
1388 @table @code
1389 @item ASM_STMT
1390
1391 Used to represent an inline assembly statement.  For an inline assembly
1392 statement like:
1393 @example
1394 asm ("mov x, y");
1395 @end example
1396 The @code{ASM_STRING} macro will return a @code{STRING_CST} node for
1397 @code{"mov x, y"}.  If the original statement made use of the
1398 extended-assembly syntax, then @code{ASM_OUTPUTS},
1399 @code{ASM_INPUTS}, and @code{ASM_CLOBBERS} will be the outputs, inputs,
1400 and clobbers for the statement, represented as @code{STRING_CST} nodes.
1401 The extended-assembly syntax looks like:
1402 @example
1403 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
1404 @end example
1405 The first string is the @code{ASM_STRING}, containing the instruction
1406 template.  The next two strings are the output and inputs, respectively;
1407 this statement has no clobbers.  As this example indicates, ``plain''
1408 assembly statements are merely a special case of extended assembly
1409 statements; they have no cv-qualifiers, outputs, inputs, or clobbers.
1410 All of the strings will be @code{NUL}-terminated, and will contain no
1411 embedded @code{NUL}-characters.
1412
1413 If the assembly statement is declared @code{volatile}, or if the
1414 statement was not an extended assembly statement, and is therefore
1415 implicitly volatile, then the predicate @code{ASM_VOLATILE_P} will hold
1416 of the @code{ASM_STMT}.
1417
1418 @item BREAK_STMT
1419
1420 Used to represent a @code{break} statement.  There are no additional
1421 fields.
1422
1423 @item CASE_LABEL
1424
1425 Use to represent a @code{case} label, range of @code{case} labels, or a
1426 @code{default} label.  If @code{CASE_LOW} is @code{NULL_TREE}, then this is a
1427 @code{default} label.  Otherwise, if @code{CASE_HIGH} is @code{NULL_TREE}, then
1428 this is an ordinary @code{case} label.  In this case, @code{CASE_LOW} is
1429 an expression giving the value of the label.  Both @code{CASE_LOW} and
1430 @code{CASE_HIGH} are @code{INTEGER_CST} nodes.  These values will have
1431 the same type as the condition expression in the switch statement.
1432
1433 Otherwise, if both @code{CASE_LOW} and @code{CASE_HIGH} are defined, the
1434 statement is a range of case labels.  Such statements originate with the
1435 extension that allows users to write things of the form:
1436 @example
1437 case 2 ... 5:
1438 @end example
1439 The first value will be @code{CASE_LOW}, while the second will be
1440 @code{CASE_HIGH}.
1441
1442 @item CLEANUP_STMT
1443
1444 Used to represent an action that should take place upon exit from the
1445 enclosing scope.  Typically, these actions are calls to destructors for
1446 local objects, but back ends cannot rely on this fact.  If these nodes
1447 are in fact representing such destructors, @code{CLEANUP_DECL} will be
1448 the @code{VAR_DECL} destroyed.  Otherwise, @code{CLEANUP_DECL} will be
1449 @code{NULL_TREE}.  In any case, the @code{CLEANUP_EXPR} is the
1450 expression to execute.  The cleanups executed on exit from a scope
1451 should be run in the reverse order of the order in which the associated
1452 @code{CLEANUP_STMT}s were encountered.
1453
1454 @item COMPOUND_STMT
1455
1456 Used to represent a brace-enclosed block.  The first substatement is
1457 given by @code{COMPOUND_BODY}.  Subsequent substatements are found by
1458 following the @code{TREE_CHAIN} link from one substatement to the next.
1459 The @code{COMPOUND_BODY} will be @code{NULL_TREE} if there are no
1460 substatements.
1461
1462 @item CONTINUE_STMT
1463
1464 Used to represent a @code{continue} statement.  There are no additional
1465 fields.
1466
1467 @item CTOR_STMT
1468
1469 Used to mark the beginning (if @code{CTOR_BEGIN_P} holds) or end (if
1470 @code{CTOR_END_P} holds of the main body of a constructor.  See also
1471 @code{SUBOBJECT} for more information on how to use these nodes.
1472
1473 @item DECL_STMT
1474
1475 Used to represent a local declaration.  The @code{DECL_STMT_DECL} macro
1476 can be used to obtain the entity declared.  This declaration may be a
1477 @code{LABEL_DECL}, indicating that the label declared is a local label.
1478 (As an extension, GCC allows the declaration of labels with scope.)  In
1479 C, this declaration may be a @code{FUNCTION_DECL}, indicating the
1480 use of the GCC nested function extension.  For more information,
1481 @pxref{Functions}.
1482
1483 @item DO_STMT
1484
1485 Used to represent a @code{do} loop.  The body of the loop is given by
1486 @code{DO_BODY} while the termination condition for the loop is given by
1487 @code{DO_COND}.  The condition for a @code{do}-statement is always an
1488 expression.
1489
1490 @item EMPTY_CLASS_EXPR
1491
1492 Used to represent a temporary object of a class with no data whose
1493 address is never taken.  (All such objects are interchangeable.)  The
1494 @code{TREE_TYPE} represents the type of the object.
1495
1496 @item EXPR_STMT
1497
1498 Used to represent an expression statement.  Use @code{EXPR_STMT_EXPR} to
1499 obtain the expression.
1500
1501 @item FOR_STMT
1502
1503 Used to represent a @code{for} statement.  The @code{FOR_INIT_STMT} is
1504 the initialization statement for the loop.  The @code{FOR_COND} is the
1505 termination condition.  The @code{FOR_EXPR} is the expression executed
1506 right before the @code{FOR_COND} on each loop iteration; often, this
1507 expression increments a counter.  The body of the loop is given by
1508 @code{FOR_BODY}.  Note that @code{FOR_INIT_STMT} and @code{FOR_BODY}
1509 return statements, while @code{FOR_COND} and @code{FOR_EXPR} return
1510 expressions.
1511
1512 @item GOTO_STMT
1513
1514 Used to represent a @code{goto} statement.  The @code{GOTO_DESTINATION}
1515 will usually be a @code{LABEL_DECL}.  However, if the ``computed
1516 goto'' extension has been used, the @code{GOTO_DESTINATION} will be an
1517 arbitrary expression indicating the destination.  This expression will
1518 always have pointer type.
1519
1520 @item HANDLER
1521
1522 Used to represent a C++ @code{catch} block.  The @code{HANDLER_TYPE}
1523 is the type of exception that will be caught by this handler; it is
1524 equal (by pointer equality) to @code{CATCH_ALL_TYPE} if this handler
1525 is for all types.  @code{HANDLER_PARMS} is the @code{DECL_STMT} for
1526 the catch parameter, and @code{HANDLER_BODY} is the
1527 @code{COMPOUND_STMT} for the block itself.
1528
1529 @item IF_STMT
1530
1531 Used to represent an @code{if} statement.  The @code{IF_COND} is the
1532 expression.
1533
1534 If the condition is a @code{TREE_LIST}, then the @code{TREE_PURPOSE} is
1535 a statement (usually a @code{DECL_STMT}).  Each time the condition is
1536 evaluated, the statement should be executed.  Then, the
1537 @code{TREE_VALUE} should be used as the conditional expression itself.
1538 This representation is used to handle C++ code like this:
1539
1540 @example
1541 if (int i = 7) @dots{}
1542 @end example
1543
1544 where there is a new local variable (or variables) declared within the
1545 condition.
1546
1547 The @code{THEN_CLAUSE} represents the statement given by the @code{then}
1548 condition, while the @code{ELSE_CLAUSE} represents the statement given
1549 by the @code{else} condition.
1550
1551 @item LABEL_STMT
1552
1553 Used to represent a label.  The @code{LABEL_DECL} declared by this
1554 statement can be obtained with the @code{LABEL_STMT_LABEL} macro.  The
1555 @code{IDENTIFIER_NODE} giving the name of the label can be obtained from
1556 the @code{LABEL_DECL} with @code{DECL_NAME}.
1557
1558 @item RETURN_INIT
1559
1560 If the function uses the G++ ``named return value'' extension, meaning
1561 that the function has been defined like:
1562 @example
1563 S f(int) return s @{@dots{}@}
1564 @end example
1565 then there will be a @code{RETURN_INIT}.  There is never a named
1566 returned value for a constructor.  The first argument to the
1567 @code{RETURN_INIT} is the name of the object returned; the second
1568 argument is the initializer for the object.  The object is initialized
1569 when the @code{RETURN_INIT} is encountered.  The object referred to is
1570 the actual object returned; this extension is a manual way of doing the
1571 ``return-value optimization.''  Therefore, the object must actually be
1572 constructed in the place where the object will be returned.
1573
1574 @item RETURN_STMT
1575
1576 Used to represent a @code{return} statement.  The @code{RETURN_EXPR} is
1577 the expression returned; it will be @code{NULL_TREE} if the statement
1578 was just
1579 @example
1580 return;
1581 @end example
1582
1583 @item SCOPE_STMT
1584
1585 A scope-statement represents the beginning or end of a scope.  If
1586 @code{SCOPE_BEGIN_P} holds, this statement represents the beginning of a
1587 scope; if @code{SCOPE_END_P} holds this statement represents the end of
1588 a scope.  On exit from a scope, all cleanups from @code{CLEANUP_STMT}s
1589 occurring in the scope must be run, in reverse order to the order in
1590 which they were encountered.  If @code{SCOPE_NULLIFIED_P} or
1591 @code{SCOPE_NO_CLEANUPS_P} holds of the scope, back ends should behave
1592 as if the @code{SCOPE_STMT} were not present at all.
1593
1594 @item SUBOBJECT
1595
1596 In a constructor, these nodes are used to mark the point at which a
1597 subobject of @code{this} is fully constructed.  If, after this point, an
1598 exception is thrown before a @code{CTOR_STMT} with @code{CTOR_END_P} set
1599 is encountered, the @code{SUBOBJECT_CLEANUP} must be executed.  The
1600 cleanups must be executed in the reverse order in which they appear.
1601
1602 @item SWITCH_STMT
1603
1604 Used to represent a @code{switch} statement.  The @code{SWITCH_COND} is
1605 the expression on which the switch is occurring.  See the documentation
1606 for an @code{IF_STMT} for more information on the representation used
1607 for the condition.  The @code{SWITCH_BODY} is the body of the switch
1608 statement.
1609
1610 @item TRY_BLOCK
1611 Used to represent a @code{try} block.  The body of the try block is
1612 given by @code{TRY_STMTS}.  Each of the catch blocks is a @code{HANDLER}
1613 node.  The first handler is given by @code{TRY_HANDLERS}.  Subsequent
1614 handlers are obtained by following the @code{TREE_CHAIN} link from one
1615 handler to the next.  The body of the handler is given by
1616 @code{HANDLER_BODY}.
1617
1618 If @code{CLEANUP_P} holds of the @code{TRY_BLOCK}, then the
1619 @code{TRY_HANDLERS} will not be a @code{HANDLER} node.  Instead, it will
1620 be an expression that should be executed if an exception is thrown in
1621 the try block.  It must rethrow the exception after executing that code.
1622 And, if an exception is thrown while the expression is executing,
1623 @code{terminate} must be called.
1624
1625 @item USING_STMT
1626 Used to represent a @code{using} directive.  The namespace is given by
1627 @code{USING_STMT_NAMESPACE}, which will be a NAMESPACE_DECL@.  This node
1628 is needed inside template functions, to implement using directives
1629 during instantiation.
1630
1631 @item WHILE_STMT
1632
1633 Used to represent a @code{while} loop.  The @code{WHILE_COND} is the
1634 termination condition for the loop.  See the documentation for an
1635 @code{IF_STMT} for more information on the representation used for the
1636 condition.
1637
1638 The @code{WHILE_BODY} is the body of the loop.
1639
1640 @end table
1641
1642 @c ---------------------------------------------------------------------
1643 @c Attributes
1644 @c ---------------------------------------------------------------------
1645 @node Attributes
1646 @section Attributes in trees
1647 @cindex attributes
1648
1649 Attributes, as specified using the @code{__attribute__} keyword, are
1650 represented internally as a @code{TREE_LIST}.  The @code{TREE_PURPOSE}
1651 is the name of the attribute, as an @code{IDENTIFIER_NODE}.  The
1652 @code{TREE_VALUE} is a @code{TREE_LIST} of the arguments of the
1653 attribute, if any, or @code{NULL_TREE} if there are no arguments; the
1654 arguments are stored as the @code{TREE_VALUE} of successive entries in
1655 the list, and may be identifiers or expressions.  The @code{TREE_CHAIN}
1656 of the attribute is the next attribute in a list of attributes applying
1657 to the same declaration or type, or @code{NULL_TREE} if there are no
1658 further attributes in the list.
1659
1660 Attributes may be attached to declarations and to types; these
1661 attributes may be accessed with the following macros.  All attributes
1662 are stored in this way, and many also cause other changes to the
1663 declaration or type or to other internal compiler data structures.
1664
1665 @deftypefn {Tree Macro} tree DECL_ATTRIBUTES (tree @var{decl})
1666 This macro returns the attributes on the declaration @var{decl}.
1667 @end deftypefn
1668
1669 @deftypefn {Tree Macro} tree TYPE_ATTRIBUTES (tree @var{type})
1670 This macro returns the attributes on the type @var{type}.
1671 @end deftypefn
1672
1673 @c ---------------------------------------------------------------------
1674 @c Expressions
1675 @c ---------------------------------------------------------------------
1676
1677 @node Expression trees
1678 @section Expressions
1679 @cindex expression
1680 @findex TREE_OPERAND
1681 @tindex INTEGER_CST
1682 @findex TREE_INT_CST_HIGH
1683 @findex TREE_INT_CST_LOW
1684 @findex tree_int_cst_lt
1685 @findex tree_int_cst_equal
1686 @tindex REAL_CST
1687 @tindex COMPLEX_CST
1688 @tindex STRING_CST
1689 @findex TREE_STRING_LENGTH
1690 @findex TREE_STRING_POINTER
1691 @tindex PTRMEM_CST
1692 @findex PTRMEM_CST_CLASS
1693 @findex PTRMEM_CST_MEMBER
1694 @tindex VAR_DECL
1695 @tindex NEGATE_EXPR
1696 @tindex BIT_NOT_EXPR
1697 @tindex TRUTH_NOT_EXPR
1698 @tindex ADDR_EXPR
1699 @tindex INDIRECT_REF
1700 @tindex FIX_TRUNC_EXPR
1701 @tindex FLOAT_EXPR
1702 @tindex COMPLEX_EXPR
1703 @tindex CONJ_EXPR
1704 @tindex REALPART_EXPR
1705 @tindex IMAGPART_EXPR
1706 @tindex NOP_EXPR
1707 @tindex CONVERT_EXPR
1708 @tindex THROW_EXPR
1709 @tindex LSHIFT_EXPR
1710 @tindex RSHIFT_EXPR
1711 @tindex BIT_IOR_EXPR
1712 @tindex BIT_XOR_EXPR
1713 @tindex BIT_AND_EXPR
1714 @tindex TRUTH_ANDIF_EXPR
1715 @tindex TRUTH_ORIF_EXPR
1716 @tindex TRUTH_AND_EXPR
1717 @tindex TRUTH_OR_EXPR
1718 @tindex TRUTH_XOR_EXPR
1719 @tindex PLUS_EXPR
1720 @tindex MINUS_EXPR
1721 @tindex MULT_EXPR
1722 @tindex TRUNC_DIV_EXPR
1723 @tindex TRUNC_MOD_EXPR
1724 @tindex RDIV_EXPR
1725 @tindex LT_EXPR
1726 @tindex LE_EXPR
1727 @tindex GT_EXPR
1728 @tindex GE_EXPR
1729 @tindex EQ_EXPR
1730 @tindex NE_EXPR
1731 @tindex INIT_EXPR
1732 @tindex MODIFY_EXPR
1733 @tindex COMPONENT_REF
1734 @tindex COMPOUND_EXPR
1735 @tindex COND_EXPR
1736 @tindex CALL_EXPR
1737 @tindex CONSTRUCTOR
1738 @tindex STMT_EXPR
1739 @tindex BIND_EXPR
1740 @tindex LOOP_EXPR
1741 @tindex EXIT_EXPR
1742 @tindex CLEANUP_POINT_EXPR
1743 @tindex ARRAY_REF
1744
1745 The internal representation for expressions is for the most part quite
1746 straightforward.  However, there are a few facts that one must bear in
1747 mind.  In particular, the expression ``tree'' is actually a directed
1748 acyclic graph.  (For example there may be many references to the integer
1749 constant zero throughout the source program; many of these will be
1750 represented by the same expression node.)  You should not rely on
1751 certain kinds of node being shared, nor should rely on certain kinds of
1752 nodes being unshared.
1753
1754 The following macros can be used with all expression nodes:
1755
1756 @ftable @code
1757 @item TREE_TYPE
1758 Returns the type of the expression.  This value may not be precisely the
1759 same type that would be given the expression in the original program.
1760 @end ftable
1761
1762 In what follows, some nodes that one might expect to always have type
1763 @code{bool} are documented to have either integral or boolean type.  At
1764 some point in the future, the C front end may also make use of this same
1765 intermediate representation, and at this point these nodes will
1766 certainly have integral type.  The previous sentence is not meant to
1767 imply that the C++ front end does not or will not give these nodes
1768 integral type.
1769
1770 Below, we list the various kinds of expression nodes.  Except where
1771 noted otherwise, the operands to an expression are accessed using the
1772 @code{TREE_OPERAND} macro.  For example, to access the first operand to
1773 a binary plus expression @code{expr}, use:
1774
1775 @example
1776 TREE_OPERAND (expr, 0)
1777 @end example
1778 @noindent
1779 As this example indicates, the operands are zero-indexed.
1780
1781 The table below begins with constants, moves on to unary expressions,
1782 then proceeds to binary expressions, and concludes with various other
1783 kinds of expressions:
1784
1785 @table @code
1786 @item INTEGER_CST
1787 These nodes represent integer constants.  Note that the type of these
1788 constants is obtained with @code{TREE_TYPE}; they are not always of type
1789 @code{int}.  In particular, @code{char} constants are represented with
1790 @code{INTEGER_CST} nodes.  The value of the integer constant @code{e} is
1791 given by @example
1792 ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT)
1793 + TREE_INST_CST_LOW (e))
1794 @end example
1795 @noindent
1796 HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms.  Both
1797 @code{TREE_INT_CST_HIGH} and @code{TREE_INT_CST_LOW} return a
1798 @code{HOST_WIDE_INT}.  The value of an @code{INTEGER_CST} is interpreted
1799 as a signed or unsigned quantity depending on the type of the constant.
1800 In general, the expression given above will overflow, so it should not
1801 be used to calculate the value of the constant.
1802
1803 The variable @code{integer_zero_node} is an integer constant with value
1804 zero.  Similarly, @code{integer_one_node} is an integer constant with
1805 value one.  The @code{size_zero_node} and @code{size_one_node} variables
1806 are analogous, but have type @code{size_t} rather than @code{int}.
1807
1808 The function @code{tree_int_cst_lt} is a predicate which holds if its
1809 first argument is less than its second.  Both constants are assumed to
1810 have the same signedness (i.e., either both should be signed or both
1811 should be unsigned.)  The full width of the constant is used when doing
1812 the comparison; the usual rules about promotions and conversions are
1813 ignored.  Similarly, @code{tree_int_cst_equal} holds if the two
1814 constants are equal.  The @code{tree_int_cst_sgn} function returns the
1815 sign of a constant.  The value is @code{1}, @code{0}, or @code{-1}
1816 according on whether the constant is greater than, equal to, or less
1817 than zero.  Again, the signedness of the constant's type is taken into
1818 account; an unsigned constant is never less than zero, no matter what
1819 its bit-pattern.
1820
1821 @item REAL_CST
1822
1823 FIXME: Talk about how to obtain representations of this constant, do
1824 comparisons, and so forth.
1825
1826 @item COMPLEX_CST
1827 These nodes are used to represent complex number constants, that is a
1828 @code{__complex__} whose parts are constant nodes.  The
1829 @code{TREE_REALPART} and @code{TREE_IMAGPART} return the real and the
1830 imaginary parts respectively.
1831
1832 @item STRING_CST
1833 These nodes represent string-constants.  The @code{TREE_STRING_LENGTH}
1834 returns the length of the string, as an @code{int}.  The
1835 @code{TREE_STRING_POINTER} is a @code{char*} containing the string
1836 itself.  The string may not be @code{NUL}-terminated, and it may contain
1837 embedded @code{NUL} characters.  Therefore, the
1838 @code{TREE_STRING_LENGTH} includes the trailing @code{NUL} if it is
1839 present.
1840
1841 For wide string constants, the @code{TREE_STRING_LENGTH} is the number
1842 of bytes in the string, and the @code{TREE_STRING_POINTER}
1843 points to an array of the bytes of the string, as represented on the
1844 target system (that is, as integers in the target endianness).  Wide and
1845 non-wide string constants are distinguished only by the @code{TREE_TYPE}
1846 of the @code{STRING_CST}.
1847
1848 FIXME: The formats of string constants are not well-defined when the
1849 target system bytes are not the same width as host system bytes.
1850
1851 @item PTRMEM_CST
1852 These nodes are used to represent pointer-to-member constants.  The
1853 @code{PTRMEM_CST_CLASS} is the class type (either a @code{RECORD_TYPE}
1854 or @code{UNION_TYPE} within which the pointer points), and the
1855 @code{PTRMEM_CST_MEMBER} is the declaration for the pointed to object.
1856 Note that the @code{DECL_CONTEXT} for the @code{PTRMEM_CST_MEMBER} is in
1857 general different from from the @code{PTRMEM_CST_CLASS}.  For example,
1858 given:
1859 @example
1860 struct B @{ int i; @};
1861 struct D : public B @{@};
1862 int D::*dp = &D::i;
1863 @end example
1864 @noindent
1865 The @code{PTRMEM_CST_CLASS} for @code{&D::i} is @code{D}, even though
1866 the @code{DECL_CONTEXT} for the @code{PTRMEM_CST_MEMBER} is @code{B},
1867 since @code{B::i} is a member of @code{B}, not @code{D}.
1868
1869 @item VAR_DECL
1870
1871 These nodes represent variables, including static data members.  For
1872 more information, @pxref{Declarations}.
1873
1874 @item NEGATE_EXPR
1875 These nodes represent unary negation of the single operand, for both
1876 integer and floating-point types.  The type of negation can be
1877 determined by looking at the type of the expression.
1878
1879 @item BIT_NOT_EXPR
1880 These nodes represent bitwise complement, and will always have integral
1881 type.  The only operand is the value to be complemented.
1882
1883 @item TRUTH_NOT_EXPR
1884 These nodes represent logical negation, and will always have integral
1885 (or boolean) type.  The operand is the value being negated.
1886
1887 @item PREDECREMENT_EXPR
1888 @itemx PREINCREMENT_EXPR
1889 @itemx POSTDECREMENT_EXPR
1890 @itemx POSTINCREMENT_EXPR
1891 These nodes represent increment and decrement expressions.  The value of
1892 the single operand is computed, and the operand incremented or
1893 decremented.  In the case of @code{PREDECREMENT_EXPR} and
1894 @code{PREINCREMENT_EXPR}, the value of the expression is the value
1895 resulting after the increment or decrement; in the case of
1896 @code{POSTDECREMENT_EXPR} and @code{POSTINCREMENT_EXPR} is the value
1897 before the increment or decrement occurs.  The type of the operand, like
1898 that of the result, will be either integral, boolean, or floating-point.
1899
1900 @item ADDR_EXPR
1901 These nodes are used to represent the address of an object.  (These
1902 expressions will always have pointer or reference type.)  The operand may
1903 be another expression, or it may be a declaration.
1904
1905 As an extension, GCC allows users to take the address of a label.  In
1906 this case, the operand of the @code{ADDR_EXPR} will be a
1907 @code{LABEL_DECL}.  The type of such an expression is @code{void*}.
1908
1909 If the object addressed is not an lvalue, a temporary is created, and
1910 the address of the temporary is used.
1911
1912 @item INDIRECT_REF
1913 These nodes are used to represent the object pointed to by a pointer.
1914 The operand is the pointer being dereferenced; it will always have
1915 pointer or reference type.
1916
1917 @item FIX_TRUNC_EXPR
1918 These nodes represent conversion of a floating-point value to an
1919 integer.  The single operand will have a floating-point type, while the
1920 the complete expression will have an integral (or boolean) type.  The
1921 operand is rounded towards zero.
1922
1923 @item FLOAT_EXPR
1924 These nodes represent conversion of an integral (or boolean) value to a
1925 floating-point value.  The single operand will have integral type, while
1926 the complete expression will have a floating-point type.
1927
1928 FIXME: How is the operand supposed to be rounded?  Is this dependent on
1929 @option{-mieee}?
1930
1931 @item COMPLEX_EXPR
1932 These nodes are used to represent complex numbers constructed from two
1933 expressions of the same (integer or real) type.  The first operand is the
1934 real part and the second operand is the imaginary part.
1935
1936 @item CONJ_EXPR
1937 These nodes represent the conjugate of their operand.
1938
1939 @item REALPART_EXPR
1940 @item IMAGPART_EXPR
1941 These nodes represent respectively the real and the imaginary parts
1942 of complex numbers (their sole argument).
1943
1944 @item NON_LVALUE_EXPR
1945 These nodes indicate that their one and only operand is not an lvalue.
1946 A back end can treat these identically to the single operand.
1947
1948 @item NOP_EXPR
1949 These nodes are used to represent conversions that do not require any
1950 code-generation.  For example, conversion of a @code{char*} to an
1951 @code{int*} does not require any code be generated; such a conversion is
1952 represented by a @code{NOP_EXPR}.  The single operand is the expression
1953 to be converted.  The conversion from a pointer to a reference is also
1954 represented with a @code{NOP_EXPR}.
1955
1956 @item CONVERT_EXPR
1957 These nodes are similar to @code{NOP_EXPR}s, but are used in those
1958 situations where code may need to be generated.  For example, if an
1959 @code{int*} is converted to an @code{int} code may need to be generated
1960 on some platforms.  These nodes are never used for C++-specific
1961 conversions, like conversions between pointers to different classes in
1962 an inheritance hierarchy.  Any adjustments that need to be made in such
1963 cases are always indicated explicitly.  Similarly, a user-defined
1964 conversion is never represented by a @code{CONVERT_EXPR}; instead, the
1965 function calls are made explicit.
1966
1967 @item THROW_EXPR
1968 These nodes represent @code{throw} expressions.  The single operand is
1969 an expression for the code that should be executed to throw the
1970 exception.  However, there is one implicit action not represented in
1971 that expression; namely the call to @code{__throw}.  This function takes
1972 no arguments.  If @code{setjmp}/@code{longjmp} exceptions are used, the
1973 function @code{__sjthrow} is called instead.  The normal GCC back end
1974 uses the function @code{emit_throw} to generate this code; you can
1975 examine this function to see what needs to be done.
1976
1977 @item LSHIFT_EXPR
1978 @itemx RSHIFT_EXPR
1979 These nodes represent left and right shifts, respectively.  The first
1980 operand is the value to shift; it will always be of integral type.  The
1981 second operand is an expression for the number of bits by which to
1982 shift.  Right shift should be treated as arithmetic, i.e., the
1983 high-order bits should be zero-filled when the expression has unsigned
1984 type and filled with the sign bit when the expression has signed type.
1985 Note that the result is undefined if the second operand is larger
1986 than the first operand's type size.
1987
1988
1989 @item BIT_IOR_EXPR
1990 @itemx BIT_XOR_EXPR
1991 @itemx BIT_AND_EXPR
1992 These nodes represent bitwise inclusive or, bitwise exclusive or, and
1993 bitwise and, respectively.  Both operands will always have integral
1994 type.
1995
1996 @item TRUTH_ANDIF_EXPR
1997 @itemx TRUTH_ORIF_EXPR
1998 These nodes represent logical and and logical or, respectively.  These
1999 operators are not strict; i.e., the second operand is evaluated only if
2000 the value of the expression is not determined by evaluation of the first
2001 operand.  The type of the operands, and the result type, is always of
2002 boolean or integral type.
2003
2004 @item TRUTH_AND_EXPR
2005 @itemx TRUTH_OR_EXPR
2006 @itemx TRUTH_XOR_EXPR
2007 These nodes represent logical and, logical or, and logical exclusive or.
2008 They are strict; both arguments are always evaluated.  There are no
2009 corresponding operators in C or C++, but the front end will sometimes
2010 generate these expressions anyhow, if it can tell that strictness does
2011 not matter.
2012
2013 @itemx PLUS_EXPR
2014 @itemx MINUS_EXPR
2015 @itemx MULT_EXPR
2016 @itemx TRUNC_DIV_EXPR
2017 @itemx TRUNC_MOD_EXPR
2018 @itemx RDIV_EXPR
2019 These nodes represent various binary arithmetic operations.
2020 Respectively, these operations are addition, subtraction (of the second
2021 operand from the first), multiplication, integer division, integer
2022 remainder, and floating-point division.  The operands to the first three
2023 of these may have either integral or floating type, but there will never
2024 be case in which one operand is of floating type and the other is of
2025 integral type.
2026
2027 The result of a @code{TRUNC_DIV_EXPR} is always rounded towards zero.
2028 The @code{TRUNC_MOD_EXPR} of two operands @code{a} and @code{b} is
2029 always @code{a - a/b} where the division is as if computed by a
2030 @code{TRUNC_DIV_EXPR}.
2031
2032 @item ARRAY_REF
2033 These nodes represent array accesses.  The first operand is the array;
2034 the second is the index.  To calculate the address of the memory
2035 accessed, you must scale the index by the size of the type of the array
2036 elements.  The type of these expressions must be the type of a component of
2037 the array.
2038
2039 @item ARRAY_RANGE_REF
2040 These nodes represent access to a range (or ``slice'') of an array.  The
2041 operands are the same as that for @code{ARRAY_REF} and have the same
2042 meanings.  The type of these expressions must be an array whose component
2043 type is the same as that of the first operand.  The range of that array
2044 type determines the amount of data these expressions access.
2045
2046 @item EXACT_DIV_EXPR
2047 Document.
2048
2049 @item LT_EXPR
2050 @itemx LE_EXPR
2051 @itemx GT_EXPR
2052 @itemx GE_EXPR
2053 @itemx EQ_EXPR
2054 @itemx NE_EXPR
2055
2056 These nodes represent the less than, less than or equal to, greater
2057 than, greater than or equal to, equal, and not equal comparison
2058 operators.  The first and second operand with either be both of integral
2059 type or both of floating type.  The result type of these expressions
2060 will always be of integral or boolean type.
2061
2062 @item MODIFY_EXPR
2063 These nodes represent assignment.  The left-hand side is the first
2064 operand; the right-hand side is the second operand.  The left-hand side
2065 will be a @code{VAR_DECL}, @code{INDIRECT_REF}, @code{COMPONENT_REF}, or
2066 other lvalue.
2067
2068 These nodes are used to represent not only assignment with @samp{=} but
2069 also compound assignments (like @samp{+=}), by reduction to @samp{=}
2070 assignment.  In other words, the representation for @samp{i += 3} looks
2071 just like that for @samp{i = i + 3}.
2072
2073 @item INIT_EXPR
2074 These nodes are just like @code{MODIFY_EXPR}, but are used only when a
2075 variable is initialized, rather than assigned to subsequently.
2076
2077 @item COMPONENT_REF
2078 These nodes represent non-static data member accesses.  The first
2079 operand is the object (rather than a pointer to it); the second operand
2080 is the @code{FIELD_DECL} for the data member.
2081
2082 @item COMPOUND_EXPR
2083 These nodes represent comma-expressions.  The first operand is an
2084 expression whose value is computed and thrown away prior to the
2085 evaluation of the second operand.  The value of the entire expression is
2086 the value of the second operand.
2087
2088 @item COND_EXPR
2089 These nodes represent @code{?:} expressions.  The first operand
2090 is of boolean or integral type.  If it evaluates to a non-zero value,
2091 the second operand should be evaluated, and returned as the value of the
2092 expression.  Otherwise, the third operand is evaluated, and returned as
2093 the value of the expression.  As a GNU extension, the middle operand of
2094 the @code{?:} operator may be omitted in the source, like this:
2095
2096 @example
2097 x ? : 3
2098 @end example
2099 @noindent
2100 which is equivalent to
2101
2102 @example
2103 x ? x : 3
2104 @end example
2105
2106 @noindent
2107 assuming that @code{x} is an expression without side-effects.  However,
2108 in the case that the first operation causes side effects, the
2109 side-effects occur only once.  Consumers of the internal representation
2110 do not need to worry about this oddity; the second operand will be
2111 always be present in the internal representation.
2112
2113 @item CALL_EXPR
2114 These nodes are used to represent calls to functions, including
2115 non-static member functions.  The first operand is a pointer to the
2116 function to call; it is always an expression whose type is a
2117 @code{POINTER_TYPE}.  The second argument is a @code{TREE_LIST}.  The
2118 arguments to the call appear left-to-right in the list.  The
2119 @code{TREE_VALUE} of each list node contains the expression
2120 corresponding to that argument.  (The value of @code{TREE_PURPOSE} for
2121 these nodes is unspecified, and should be ignored.)  For non-static
2122 member functions, there will be an operand corresponding to the
2123 @code{this} pointer.  There will always be expressions corresponding to
2124 all of the arguments, even if the function is declared with default
2125 arguments and some arguments are not explicitly provided at the call
2126 sites.
2127
2128 @item STMT_EXPR
2129 These nodes are used to represent GCC's statement-expression extension.
2130 The statement-expression extension allows code like this:
2131 @example
2132 int f() @{ return (@{ int j; j = 3; j + 7; @}); @}
2133 @end example
2134 In other words, an sequence of statements may occur where a single
2135 expression would normally appear.  The @code{STMT_EXPR} node represents
2136 such an expression.  The @code{STMT_EXPR_STMT} gives the statement
2137 contained in the expression; this is always a @code{COMPOUND_STMT}.  The
2138 value of the expression is the value of the last sub-statement in the
2139 @code{COMPOUND_STMT}.  More precisely, the value is the value computed
2140 by the last @code{EXPR_STMT} in the outermost scope of the
2141 @code{COMPOUND_STMT}.  For example, in:
2142 @example
2143 (@{ 3; @})
2144 @end example
2145 the value is @code{3} while in:
2146 @example
2147 (@{ if (x) @{ 3; @} @})
2148 @end example
2149 (represented by a nested @code{COMPOUND_STMT}), there is no value.  If
2150 the @code{STMT_EXPR} does not yield a value, it's type will be
2151 @code{void}.
2152
2153 @item BIND_EXPR
2154 These nodes represent local blocks.  The first operand is a list of
2155 temporary variables, connected via their @code{TREE_CHAIN} field.  These
2156 will never require cleanups.  The scope of these variables is just the
2157 body of the @code{BIND_EXPR}.  The body of the @code{BIND_EXPR} is the
2158 second operand.
2159
2160 @item LOOP_EXPR
2161 These nodes represent ``infinite'' loops.  The @code{LOOP_EXPR_BODY}
2162 represents the body of the loop.  It should be executed forever, unless
2163 an @code{EXIT_EXPR} is encountered.
2164
2165 @item EXIT_EXPR
2166 These nodes represent conditional exits from the nearest enclosing
2167 @code{LOOP_EXPR}.  The single operand is the condition; if it is
2168 non-zero, then the loop should be exited.  An @code{EXIT_EXPR} will only
2169 appear within a @code{LOOP_EXPR}.
2170
2171 @item CLEANUP_POINT_EXPR
2172 These nodes represent full-expressions.  The single operand is an
2173 expression to evaluate.  Any destructor calls engendered by the creation
2174 of temporaries during the evaluation of that expression should be
2175 performed immediately after the expression is evaluated.
2176
2177 @item CONSTRUCTOR
2178 These nodes represent the brace-enclosed initializers for a structure or
2179 array.  The first operand is reserved for use by the back end.  The
2180 second operand is a @code{TREE_LIST}.  If the @code{TREE_TYPE} of the
2181 @code{CONSTRUCTOR} is a @code{RECORD_TYPE} or @code{UNION_TYPE}, then
2182 the @code{TREE_PURPOSE} of each node in the @code{TREE_LIST} will be a
2183 @code{FIELD_DECL} and the @code{TREE_VALUE} of each node will be the
2184 expression used to initialize that field.  You should not depend on the
2185 fields appearing in any particular order, nor should you assume that all
2186 fields will be represented.  Unrepresented fields may be assigned any
2187 value.
2188
2189 If the @code{TREE_TYPE} of the @code{CONSTRUCTOR} is an
2190 @code{ARRAY_TYPE}, then the @code{TREE_PURPOSE} of each element in the
2191 @code{TREE_LIST} will be an @code{INTEGER_CST}.  This constant indicates
2192 which element of the array (indexed from zero) is being assigned to;
2193 again, the @code{TREE_VALUE} is the corresponding initializer.  If the
2194 @code{TREE_PURPOSE} is @code{NULL_TREE}, then the initializer is for the
2195 next available array element.
2196
2197 Conceptually, before any initialization is done, the entire area of
2198 storage is initialized to zero.
2199
2200 @item SAVE_EXPR
2201
2202 A @code{SAVE_EXPR} represents an expression (possibly involving
2203 side-effects) that is used more than once.  The side-effects should
2204 occur only the first time the expression is evaluated.  Subsequent uses
2205 should just reuse the computed value.  The first operand to the
2206 @code{SAVE_EXPR} is the expression to evaluate.  The side-effects should
2207 be executed where the @code{SAVE_EXPR} is first encountered in a
2208 depth-first preorder traversal of the expression tree.
2209
2210 @item TARGET_EXPR
2211 A @code{TARGET_EXPR} represents a temporary object.  The first operand
2212 is a @code{VAR_DECL} for the temporary variable.  The second operand is
2213 the initializer for the temporary.  The initializer is evaluated, and
2214 copied (bitwise) into the temporary.
2215
2216 Often, a @code{TARGET_EXPR} occurs on the right-hand side of an
2217 assignment, or as the second operand to a comma-expression which is
2218 itself the right-hand side of an assignment, etc.  In this case, we say
2219 that the @code{TARGET_EXPR} is ``normal''; otherwise, we say it is
2220 ``orphaned''.  For a normal @code{TARGET_EXPR} the temporary variable
2221 should be treated as an alias for the left-hand side of the assignment,
2222 rather than as a new temporary variable.
2223
2224 The third operand to the @code{TARGET_EXPR}, if present, is a
2225 cleanup-expression (i.e., destructor call) for the temporary.  If this
2226 expression is orphaned, then this expression must be executed when the
2227 statement containing this expression is complete.  These cleanups must
2228 always be executed in the order opposite to that in which they were
2229 encountered.  Note that if a temporary is created on one branch of a
2230 conditional operator (i.e., in the second or third operand to a
2231 @code{COND_EXPR}), the cleanup must be run only if that branch is
2232 actually executed.
2233
2234 See @code{STMT_IS_FULL_EXPR_P} for more information about running these
2235 cleanups.
2236
2237 @item AGGR_INIT_EXPR
2238 An @code{AGGR_INIT_EXPR} represents the initialization as the return
2239 value of a function call, or as the result of a constructor.  An
2240 @code{AGGR_INIT_EXPR} will only appear as the second operand of a
2241 @code{TARGET_EXPR}.  The first operand to the @code{AGGR_INIT_EXPR} is
2242 the address of a function to call, just as in a @code{CALL_EXPR}.  The
2243 second operand are the arguments to pass that function, as a
2244 @code{TREE_LIST}, again in a manner similar to that of a
2245 @code{CALL_EXPR}.  The value of the expression is that returned by the
2246 function.
2247
2248 If @code{AGGR_INIT_VIA_CTOR_P} holds of the @code{AGGR_INIT_EXPR}, then
2249 the initialization is via a constructor call.  The address of the third
2250 operand of the @code{AGGR_INIT_EXPR}, which is always a @code{VAR_DECL},
2251 is taken, and this value replaces the first argument in the argument
2252 list.  In this case, the value of the expression is the @code{VAR_DECL}
2253 given by the third operand to the @code{AGGR_INIT_EXPR}; constructors do
2254 not return a value.
2255
2256 @end table