OSDN Git Service

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