OSDN Git Service

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