Import gcc-4.4.1
[dragonfly.git] / contrib / gcc-4.4 / gcc / doc / c-tree.texi
1 @c Copyright (c) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008,
2 @c 2009  Free Software Foundation, Inc.
3 @c This is part of the GCC manual.
4 @c For copying conditions, see the file gcc.texi.
5
6 @c ---------------------------------------------------------------------
7 @c Trees
8 @c ---------------------------------------------------------------------
9
10 @node Trees
11 @chapter Trees: The intermediate representation used by the C and C++ front ends
12 @cindex Trees
13 @cindex C/C++ Internal Representation
14
15 This chapter documents the internal representation used by GCC to
16 represent C and C++ source programs.  When presented with a C or C++
17 source program, GCC parses the program, performs semantic analysis
18 (including the generation of error messages), and then produces the
19 internal representation described here.  This representation contains a
20 complete representation for the entire translation unit provided as
21 input to the front end.  This representation is then typically processed
22 by a code-generator in order to produce machine code, but could also be
23 used in the creation of source browsers, intelligent editors, automatic
24 documentation generators, interpreters, and any other programs needing
25 the ability to process C or C++ code.
26
27 This chapter explains the internal representation.  In particular, it
28 documents the internal representation for C and C++ source
29 constructs, and the macros, functions, and variables that can be used to
30 access these constructs.  The C++ representation is largely a superset
31 of the representation used in the C front end.  There is only one
32 construct used in C that does not appear in the C++ front end and that
33 is the GNU ``nested function'' extension.  Many of the macros documented
34 here do not apply in C because the corresponding language constructs do
35 not appear in C@.
36
37 If you are developing a ``back end'', be it is a code-generator or some
38 other tool, that uses this representation, you may occasionally find
39 that you need to ask questions not easily answered by the functions and
40 macros available here.  If that situation occurs, it is quite likely
41 that GCC already supports the functionality you desire, but that the
42 interface is simply not documented here.  In that case, you should ask
43 the GCC maintainers (via mail to @email{gcc@@gcc.gnu.org}) about
44 documenting the functionality you require.  Similarly, if you find
45 yourself writing functions that do not deal directly with your back end,
46 but instead might be useful to other people using the GCC front end, you
47 should submit your patches for inclusion in GCC@.
48
49 @menu
50 * Deficiencies::        Topics net yet covered in this document.
51 * Tree overview::       All about @code{tree}s.
52 * Types::               Fundamental and aggregate types.
53 * Scopes::              Namespaces and classes.
54 * Functions::           Overloading, function bodies, and linkage.
55 * Declarations::        Type declarations and variables.
56 * Attributes::          Declaration and type attributes.
57 * Expression trees::    From @code{typeid} to @code{throw}.
58 @end menu
59
60 @c ---------------------------------------------------------------------
61 @c Deficiencies
62 @c ---------------------------------------------------------------------
63
64 @node Deficiencies
65 @section Deficiencies
66
67 There are many places in which this document is incomplet and incorrekt.
68 It is, as of yet, only @emph{preliminary} documentation.
69
70 @c ---------------------------------------------------------------------
71 @c Overview
72 @c ---------------------------------------------------------------------
73
74 @node Tree overview
75 @section Overview
76 @cindex tree
77 @findex TREE_CODE
78
79 The central data structure used by the internal representation is the
80 @code{tree}.  These nodes, while all of the C type @code{tree}, are of
81 many varieties.  A @code{tree} is a pointer type, but the object to
82 which it points may be of a variety of types.  From this point forward,
83 we will refer to trees in ordinary type, rather than in @code{this
84 font}, except when talking about the actual C type @code{tree}.
85
86 You can tell what kind of node a particular tree is by using the
87 @code{TREE_CODE} macro.  Many, many macros take trees as input and
88 return trees as output.  However, most macros require a certain kind of
89 tree node as input.  In other words, there is a type-system for trees,
90 but it is not reflected in the C type-system.
91
92 For safety, it is useful to configure GCC with @option{--enable-checking}.
93 Although this results in a significant performance penalty (since all
94 tree types are checked at run-time), and is therefore inappropriate in a
95 release version, it is extremely helpful during the development process.
96
97 Many macros behave as predicates.  Many, although not all, of these
98 predicates end in @samp{_P}.  Do not rely on the result type of these
99 macros being of any particular type.  You may, however, rely on the fact
100 that the type can be compared to @code{0}, so that statements like
101 @smallexample
102 if (TEST_P (t) && !TEST_P (y))
103   x = 1;
104 @end smallexample
105 @noindent
106 and
107 @smallexample
108 int i = (TEST_P (t) != 0);
109 @end smallexample
110 @noindent
111 are legal.  Macros that return @code{int} values now may be changed to
112 return @code{tree} values, or other pointers in the future.  Even those
113 that continue to return @code{int} may return multiple nonzero codes
114 where previously they returned only zero and one.  Therefore, you should
115 not write code like
116 @smallexample
117 if (TEST_P (t) == 1)
118 @end smallexample
119 @noindent
120 as this code is not guaranteed to work correctly in the future.
121
122 You should not take the address of values returned by the macros or
123 functions described here.  In particular, no guarantee is given that the
124 values are lvalues.
125
126 In general, the names of macros are all in uppercase, while the names of
127 functions are entirely in lowercase.  There are rare exceptions to this
128 rule.  You should assume that any macro or function whose name is made
129 up entirely of uppercase letters may evaluate its arguments more than
130 once.  You may assume that a macro or function whose name is made up
131 entirely of lowercase letters will evaluate its arguments only once.
132
133 The @code{error_mark_node} is a special tree.  Its tree code is
134 @code{ERROR_MARK}, but since there is only ever one node with that code,
135 the usual practice is to compare the tree against
136 @code{error_mark_node}.  (This test is just a test for pointer
137 equality.)  If an error has occurred during front-end processing the
138 flag @code{errorcount} will be set.  If the front end has encountered
139 code it cannot handle, it will issue a message to the user and set
140 @code{sorrycount}.  When these flags are set, any macro or function
141 which normally returns a tree of a particular kind may instead return
142 the @code{error_mark_node}.  Thus, if you intend to do any processing of
143 erroneous code, you must be prepared to deal with the
144 @code{error_mark_node}.
145
146 Occasionally, a particular tree slot (like an operand to an expression,
147 or a particular field in a declaration) will be referred to as
148 ``reserved for the back end''.  These slots are used to store RTL when
149 the tree is converted to RTL for use by the GCC back end.  However, if
150 that process is not taking place (e.g., if the front end is being hooked
151 up to an intelligent editor), then those slots may be used by the
152 back end presently in use.
153
154 If you encounter situations that do not match this documentation, such
155 as tree nodes of types not mentioned here, or macros documented to
156 return entities of a particular kind that instead return entities of
157 some different kind, you have found a bug, either in the front end or in
158 the documentation.  Please report these bugs as you would any other
159 bug.
160
161 @menu
162 * Macros and Functions::Macros and functions that can be used with all trees.
163 * Identifiers::         The names of things.
164 * Containers::          Lists and vectors.
165 @end menu
166
167 @c ---------------------------------------------------------------------
168 @c Trees
169 @c ---------------------------------------------------------------------
170
171 @node Macros and Functions
172 @subsection Trees
173 @cindex tree
174
175 This section is not here yet.
176
177 @c ---------------------------------------------------------------------
178 @c Identifiers
179 @c ---------------------------------------------------------------------
180
181 @node Identifiers
182 @subsection Identifiers
183 @cindex identifier
184 @cindex name
185 @tindex IDENTIFIER_NODE
186
187 An @code{IDENTIFIER_NODE} represents a slightly more general concept
188 that the standard C or C++ concept of identifier.  In particular, an
189 @code{IDENTIFIER_NODE} may contain a @samp{$}, or other extraordinary
190 characters.
191
192 There are never two distinct @code{IDENTIFIER_NODE}s representing the
193 same identifier.  Therefore, you may use pointer equality to compare
194 @code{IDENTIFIER_NODE}s, rather than using a routine like @code{strcmp}.
195
196 You can use the following macros to access identifiers:
197 @ftable @code
198 @item IDENTIFIER_POINTER
199 The string represented by the identifier, represented as a
200 @code{char*}.  This string is always @code{NUL}-terminated, and contains
201 no embedded @code{NUL} characters.
202
203 @item IDENTIFIER_LENGTH
204 The length of the string returned by @code{IDENTIFIER_POINTER}, not
205 including the trailing @code{NUL}.  This value of
206 @code{IDENTIFIER_LENGTH (x)} is always the same as @code{strlen
207 (IDENTIFIER_POINTER (x))}.
208
209 @item IDENTIFIER_OPNAME_P
210 This predicate holds if the identifier represents the name of an
211 overloaded operator.  In this case, you should not depend on the
212 contents of either the @code{IDENTIFIER_POINTER} or the
213 @code{IDENTIFIER_LENGTH}.
214
215 @item IDENTIFIER_TYPENAME_P
216 This predicate holds if the identifier represents the name of a
217 user-defined conversion operator.  In this case, the @code{TREE_TYPE} of
218 the @code{IDENTIFIER_NODE} holds the type to which the conversion
219 operator converts.
220
221 @end ftable
222
223 @c ---------------------------------------------------------------------
224 @c Containers
225 @c ---------------------------------------------------------------------
226
227 @node Containers
228 @subsection Containers
229 @cindex container
230 @cindex list
231 @cindex vector
232 @tindex TREE_LIST
233 @tindex TREE_VEC
234 @findex TREE_PURPOSE
235 @findex TREE_VALUE
236 @findex TREE_VEC_LENGTH
237 @findex TREE_VEC_ELT
238
239 Two common container data structures can be represented directly with
240 tree nodes.  A @code{TREE_LIST} is a singly linked list containing two
241 trees per node.  These are the @code{TREE_PURPOSE} and @code{TREE_VALUE}
242 of each node.  (Often, the @code{TREE_PURPOSE} contains some kind of
243 tag, or additional information, while the @code{TREE_VALUE} contains the
244 majority of the payload.  In other cases, the @code{TREE_PURPOSE} is
245 simply @code{NULL_TREE}, while in still others both the
246 @code{TREE_PURPOSE} and @code{TREE_VALUE} are of equal stature.)  Given
247 one @code{TREE_LIST} node, the next node is found by following the
248 @code{TREE_CHAIN}.  If the @code{TREE_CHAIN} is @code{NULL_TREE}, then
249 you have reached the end of the list.
250
251 A @code{TREE_VEC} is a simple vector.  The @code{TREE_VEC_LENGTH} is an
252 integer (not a tree) giving the number of nodes in the vector.  The
253 nodes themselves are accessed using the @code{TREE_VEC_ELT} macro, which
254 takes two arguments.  The first is the @code{TREE_VEC} in question; the
255 second is an integer indicating which element in the vector is desired.
256 The elements are indexed from zero.
257
258 @c ---------------------------------------------------------------------
259 @c Types
260 @c ---------------------------------------------------------------------
261
262 @node Types
263 @section Types
264 @cindex type
265 @cindex pointer
266 @cindex reference
267 @cindex fundamental type
268 @cindex array
269 @tindex VOID_TYPE
270 @tindex INTEGER_TYPE
271 @tindex TYPE_MIN_VALUE
272 @tindex TYPE_MAX_VALUE
273 @tindex REAL_TYPE
274 @tindex FIXED_POINT_TYPE
275 @tindex COMPLEX_TYPE
276 @tindex ENUMERAL_TYPE
277 @tindex BOOLEAN_TYPE
278 @tindex POINTER_TYPE
279 @tindex REFERENCE_TYPE
280 @tindex FUNCTION_TYPE
281 @tindex METHOD_TYPE
282 @tindex ARRAY_TYPE
283 @tindex RECORD_TYPE
284 @tindex UNION_TYPE
285 @tindex UNKNOWN_TYPE
286 @tindex OFFSET_TYPE
287 @tindex TYPENAME_TYPE
288 @tindex TYPEOF_TYPE
289 @findex CP_TYPE_QUALS
290 @findex TYPE_UNQUALIFIED
291 @findex TYPE_QUAL_CONST
292 @findex TYPE_QUAL_VOLATILE
293 @findex TYPE_QUAL_RESTRICT
294 @findex TYPE_MAIN_VARIANT
295 @cindex qualified type
296 @findex TYPE_SIZE
297 @findex TYPE_ALIGN
298 @findex TYPE_PRECISION
299 @findex TYPE_ARG_TYPES
300 @findex TYPE_METHOD_BASETYPE
301 @findex TYPE_PTRMEM_P
302 @findex TYPE_OFFSET_BASETYPE
303 @findex TREE_TYPE
304 @findex TYPE_CONTEXT
305 @findex TYPE_NAME
306 @findex TYPENAME_TYPE_FULLNAME
307 @findex TYPE_FIELDS
308 @findex TYPE_PTROBV_P
309 @findex TYPE_CANONICAL
310 @findex TYPE_STRUCTURAL_EQUALITY_P
311 @findex SET_TYPE_STRUCTURAL_EQUALITY
312
313 All types have corresponding tree nodes.  However, you should not assume
314 that there is exactly one tree node corresponding to each type.  There
315 are often multiple nodes corresponding to the same type.
316
317 For the most part, different kinds of types have different tree codes.
318 (For example, pointer types use a @code{POINTER_TYPE} code while arrays
319 use an @code{ARRAY_TYPE} code.)  However, pointers to member functions
320 use the @code{RECORD_TYPE} code.  Therefore, when writing a
321 @code{switch} statement that depends on the code associated with a
322 particular type, you should take care to handle pointers to member
323 functions under the @code{RECORD_TYPE} case label.
324
325 In C++, an array type is not qualified; rather the type of the array
326 elements is qualified.  This situation is reflected in the intermediate
327 representation.  The macros described here will always examine the
328 qualification of the underlying element type when applied to an array
329 type.  (If the element type is itself an array, then the recursion
330 continues until a non-array type is found, and the qualification of this
331 type is examined.)  So, for example, @code{CP_TYPE_CONST_P} will hold of
332 the type @code{const int ()[7]}, denoting an array of seven @code{int}s.
333
334 The following functions and macros deal with cv-qualification of types:
335 @ftable @code
336 @item CP_TYPE_QUALS
337 This macro returns the set of type qualifiers applied to this type.
338 This value is @code{TYPE_UNQUALIFIED} if no qualifiers have been
339 applied.  The @code{TYPE_QUAL_CONST} bit is set if the type is
340 @code{const}-qualified.  The @code{TYPE_QUAL_VOLATILE} bit is set if the
341 type is @code{volatile}-qualified.  The @code{TYPE_QUAL_RESTRICT} bit is
342 set if the type is @code{restrict}-qualified.
343
344 @item CP_TYPE_CONST_P
345 This macro holds if the type is @code{const}-qualified.
346
347 @item CP_TYPE_VOLATILE_P
348 This macro holds if the type is @code{volatile}-qualified.
349
350 @item CP_TYPE_RESTRICT_P
351 This macro holds if the type is @code{restrict}-qualified.
352
353 @item CP_TYPE_CONST_NON_VOLATILE_P
354 This predicate holds for a type that is @code{const}-qualified, but
355 @emph{not} @code{volatile}-qualified; other cv-qualifiers are ignored as
356 well: only the @code{const}-ness is tested.
357
358 @item TYPE_MAIN_VARIANT
359 This macro returns the unqualified version of a type.  It may be applied
360 to an unqualified type, but it is not always the identity function in
361 that case.
362 @end ftable
363
364 A few other macros and functions are usable with all types:
365 @ftable @code
366 @item TYPE_SIZE
367 The number of bits required to represent the type, represented as an
368 @code{INTEGER_CST}.  For an incomplete type, @code{TYPE_SIZE} will be
369 @code{NULL_TREE}.
370
371 @item TYPE_ALIGN
372 The alignment of the type, in bits, represented as an @code{int}.
373
374 @item TYPE_NAME
375 This macro returns a declaration (in the form of a @code{TYPE_DECL}) for
376 the type.  (Note this macro does @emph{not} return a
377 @code{IDENTIFIER_NODE}, as you might expect, given its name!)  You can
378 look at the @code{DECL_NAME} of the @code{TYPE_DECL} to obtain the
379 actual name of the type.  The @code{TYPE_NAME} will be @code{NULL_TREE}
380 for a type that is not a built-in type, the result of a typedef, or a
381 named class type.
382
383 @item CP_INTEGRAL_TYPE
384 This predicate holds if the type is an integral type.  Notice that in
385 C++, enumerations are @emph{not} integral types.
386
387 @item ARITHMETIC_TYPE_P
388 This predicate holds if the type is an integral type (in the C++ sense)
389 or a floating point type.
390
391 @item CLASS_TYPE_P
392 This predicate holds for a class-type.
393
394 @item TYPE_BUILT_IN
395 This predicate holds for a built-in type.
396
397 @item TYPE_PTRMEM_P
398 This predicate holds if the type is a pointer to data member.
399
400 @item TYPE_PTR_P
401 This predicate holds if the type is a pointer type, and the pointee is
402 not a data member.
403
404 @item TYPE_PTRFN_P
405 This predicate holds for a pointer to function type.
406
407 @item TYPE_PTROB_P
408 This predicate holds for a pointer to object type.  Note however that it
409 does not hold for the generic pointer to object type @code{void *}.  You
410 may use @code{TYPE_PTROBV_P} to test for a pointer to object type as
411 well as @code{void *}.
412
413 @item TYPE_CANONICAL
414 This macro returns the ``canonical'' type for the given type
415 node. Canonical types are used to improve performance in the C++ and
416 Objective-C++ front ends by allowing efficient comparison between two
417 type nodes in @code{same_type_p}: if the @code{TYPE_CANONICAL} values
418 of the types are equal, the types are equivalent; otherwise, the types
419 are not equivalent. The notion of equivalence for canonical types is
420 the same as the notion of type equivalence in the language itself. For
421 instance,
422
423 When @code{TYPE_CANONICAL} is @code{NULL_TREE}, there is no canonical
424 type for the given type node. In this case, comparison between this
425 type and any other type requires the compiler to perform a deep,
426 ``structural'' comparison to see if the two type nodes have the same
427 form and properties.
428
429 The canonical type for a node is always the most fundamental type in
430 the equivalence class of types. For instance, @code{int} is its own
431 canonical type. A typedef @code{I} of @code{int} will have @code{int}
432 as its canonical type. Similarly, @code{I*}@ and a typedef @code{IP}@
433 (defined to @code{I*}) will has @code{int*} as their canonical
434 type. When building a new type node, be sure to set
435 @code{TYPE_CANONICAL} to the appropriate canonical type. If the new
436 type is a compound type (built from other types), and any of those
437 other types require structural equality, use
438 @code{SET_TYPE_STRUCTURAL_EQUALITY} to ensure that the new type also
439 requires structural equality. Finally, if for some reason you cannot
440 guarantee that @code{TYPE_CANONICAL} will point to the canonical type,
441 use @code{SET_TYPE_STRUCTURAL_EQUALITY} to make sure that the new
442 type--and any type constructed based on it--requires structural
443 equality. If you suspect that the canonical type system is
444 miscomparing types, pass @code{--param verify-canonical-types=1} to
445 the compiler or configure with @code{--enable-checking} to force the
446 compiler to verify its canonical-type comparisons against the
447 structural comparisons; the compiler will then print any warnings if
448 the canonical types miscompare.
449
450 @item TYPE_STRUCTURAL_EQUALITY_P
451 This predicate holds when the node requires structural equality
452 checks, e.g., when @code{TYPE_CANONICAL} is @code{NULL_TREE}.
453
454 @item SET_TYPE_STRUCTURAL_EQUALITY
455 This macro states that the type node it is given requires structural
456 equality checks, e.g., it sets @code{TYPE_CANONICAL} to
457 @code{NULL_TREE}.
458
459 @item same_type_p
460 This predicate takes two types as input, and holds if they are the same
461 type.  For example, if one type is a @code{typedef} for the other, or
462 both are @code{typedef}s for the same type.  This predicate also holds if
463 the two trees given as input are simply copies of one another; i.e.,
464 there is no difference between them at the source level, but, for
465 whatever reason, a duplicate has been made in the representation.  You
466 should never use @code{==} (pointer equality) to compare types; always
467 use @code{same_type_p} instead.
468 @end ftable
469
470 Detailed below are the various kinds of types, and the macros that can
471 be used to access them.  Although other kinds of types are used
472 elsewhere in G++, the types described here are the only ones that you
473 will encounter while examining the intermediate representation.
474
475 @table @code
476 @item VOID_TYPE
477 Used to represent the @code{void} type.
478
479 @item INTEGER_TYPE
480 Used to represent the various integral types, including @code{char},
481 @code{short}, @code{int}, @code{long}, and @code{long long}.  This code
482 is not used for enumeration types, nor for the @code{bool} type.
483 The @code{TYPE_PRECISION} is the number of bits used in
484 the representation, represented as an @code{unsigned int}.  (Note that
485 in the general case this is not the same value as @code{TYPE_SIZE};
486 suppose that there were a 24-bit integer type, but that alignment
487 requirements for the ABI required 32-bit alignment.  Then,
488 @code{TYPE_SIZE} would be an @code{INTEGER_CST} for 32, while
489 @code{TYPE_PRECISION} would be 24.)  The integer type is unsigned if
490 @code{TYPE_UNSIGNED} holds; otherwise, it is signed.
491
492 The @code{TYPE_MIN_VALUE} is an @code{INTEGER_CST} for the smallest
493 integer that may be represented by this type.  Similarly, the
494 @code{TYPE_MAX_VALUE} is an @code{INTEGER_CST} for the largest integer
495 that may be represented by this type.
496
497 @item REAL_TYPE
498 Used to represent the @code{float}, @code{double}, and @code{long
499 double} types.  The number of bits in the floating-point representation
500 is given by @code{TYPE_PRECISION}, as in the @code{INTEGER_TYPE} case.
501
502 @item FIXED_POINT_TYPE
503 Used to represent the @code{short _Fract}, @code{_Fract}, @code{long
504 _Fract}, @code{long long _Fract}, @code{short _Accum}, @code{_Accum},
505 @code{long _Accum}, and @code{long long _Accum} types.  The number of bits
506 in the fixed-point representation is given by @code{TYPE_PRECISION},
507 as in the @code{INTEGER_TYPE} case.  There may be padding bits, fractional
508 bits and integral bits.  The number of fractional bits is given by
509 @code{TYPE_FBIT}, and the number of integral bits is given by @code{TYPE_IBIT}.
510 The fixed-point type is unsigned if @code{TYPE_UNSIGNED} holds; otherwise,
511 it is signed.
512 The fixed-point type is saturating if @code{TYPE_SATURATING} holds; otherwise,
513 it is not saturating.
514
515 @item COMPLEX_TYPE
516 Used to represent GCC built-in @code{__complex__} data types.  The
517 @code{TREE_TYPE} is the type of the real and imaginary parts.
518
519 @item ENUMERAL_TYPE
520 Used to represent an enumeration type.  The @code{TYPE_PRECISION} gives
521 (as an @code{int}), the number of bits used to represent the type.  If
522 there are no negative enumeration constants, @code{TYPE_UNSIGNED} will
523 hold.  The minimum and maximum enumeration constants may be obtained
524 with @code{TYPE_MIN_VALUE} and @code{TYPE_MAX_VALUE}, respectively; each
525 of these macros returns an @code{INTEGER_CST}.
526
527 The actual enumeration constants themselves may be obtained by looking
528 at the @code{TYPE_VALUES}.  This macro will return a @code{TREE_LIST},
529 containing the constants.  The @code{TREE_PURPOSE} of each node will be
530 an @code{IDENTIFIER_NODE} giving the name of the constant; the
531 @code{TREE_VALUE} will be an @code{INTEGER_CST} giving the value
532 assigned to that constant.  These constants will appear in the order in
533 which they were declared.  The @code{TREE_TYPE} of each of these
534 constants will be the type of enumeration type itself.
535
536 @item BOOLEAN_TYPE
537 Used to represent the @code{bool} type.
538
539 @item POINTER_TYPE
540 Used to represent pointer types, and pointer to data member types.  The
541 @code{TREE_TYPE} gives the type to which this type points.  If the type
542 is a pointer to data member type, then @code{TYPE_PTRMEM_P} will hold.
543 For a pointer to data member type of the form @samp{T X::*},
544 @code{TYPE_PTRMEM_CLASS_TYPE} will be the type @code{X}, while
545 @code{TYPE_PTRMEM_POINTED_TO_TYPE} will be the type @code{T}.
546
547 @item REFERENCE_TYPE
548 Used to represent reference types.  The @code{TREE_TYPE} gives the type
549 to which this type refers.
550
551 @item FUNCTION_TYPE
552 Used to represent the type of non-member functions and of static member
553 functions.  The @code{TREE_TYPE} gives the return type of the function.
554 The @code{TYPE_ARG_TYPES} are a @code{TREE_LIST} of the argument types.
555 The @code{TREE_VALUE} of each node in this list is the type of the
556 corresponding argument; the @code{TREE_PURPOSE} is an expression for the
557 default argument value, if any.  If the last node in the list is
558 @code{void_list_node} (a @code{TREE_LIST} node whose @code{TREE_VALUE}
559 is the @code{void_type_node}), then functions of this type do not take
560 variable arguments.  Otherwise, they do take a variable number of
561 arguments.
562
563 Note that in C (but not in C++) a function declared like @code{void f()}
564 is an unprototyped function taking a variable number of arguments; the
565 @code{TYPE_ARG_TYPES} of such a function will be @code{NULL}.
566
567 @item METHOD_TYPE
568 Used to represent the type of a non-static member function.  Like a
569 @code{FUNCTION_TYPE}, the return type is given by the @code{TREE_TYPE}.
570 The type of @code{*this}, i.e., the class of which functions of this
571 type are a member, is given by the @code{TYPE_METHOD_BASETYPE}.  The
572 @code{TYPE_ARG_TYPES} is the parameter list, as for a
573 @code{FUNCTION_TYPE}, and includes the @code{this} argument.
574
575 @item ARRAY_TYPE
576 Used to represent array types.  The @code{TREE_TYPE} gives the type of
577 the elements in the array.  If the array-bound is present in the type,
578 the @code{TYPE_DOMAIN} is an @code{INTEGER_TYPE} whose
579 @code{TYPE_MIN_VALUE} and @code{TYPE_MAX_VALUE} will be the lower and
580 upper bounds of the array, respectively.  The @code{TYPE_MIN_VALUE} will
581 always be an @code{INTEGER_CST} for zero, while the
582 @code{TYPE_MAX_VALUE} will be one less than the number of elements in
583 the array, i.e., the highest value which may be used to index an element
584 in the array.
585
586 @item RECORD_TYPE
587 Used to represent @code{struct} and @code{class} types, as well as
588 pointers to member functions and similar constructs in other languages.
589 @code{TYPE_FIELDS} contains the items contained in this type, each of
590 which can be a @code{FIELD_DECL}, @code{VAR_DECL}, @code{CONST_DECL}, or
591 @code{TYPE_DECL}.  You may not make any assumptions about the ordering
592 of the fields in the type or whether one or more of them overlap.  If
593 @code{TYPE_PTRMEMFUNC_P} holds, then this type is a pointer-to-member
594 type.  In that case, the @code{TYPE_PTRMEMFUNC_FN_TYPE} is a
595 @code{POINTER_TYPE} pointing to a @code{METHOD_TYPE}.  The
596 @code{METHOD_TYPE} is the type of a function pointed to by the
597 pointer-to-member function.  If @code{TYPE_PTRMEMFUNC_P} does not hold,
598 this type is a class type.  For more information, see @pxref{Classes}.
599
600 @item UNION_TYPE
601 Used to represent @code{union} types.  Similar to @code{RECORD_TYPE}
602 except that all @code{FIELD_DECL} nodes in @code{TYPE_FIELD} start at
603 bit position zero.
604
605 @item QUAL_UNION_TYPE
606 Used to represent part of a variant record in Ada.  Similar to
607 @code{UNION_TYPE} except that each @code{FIELD_DECL} has a
608 @code{DECL_QUALIFIER} field, which contains a boolean expression that
609 indicates whether the field is present in the object.  The type will only
610 have one field, so each field's @code{DECL_QUALIFIER} is only evaluated
611 if none of the expressions in the previous fields in @code{TYPE_FIELDS}
612 are nonzero.  Normally these expressions will reference a field in the
613 outer object using a @code{PLACEHOLDER_EXPR}.
614
615 @item UNKNOWN_TYPE
616 This node is used to represent a type the knowledge of which is
617 insufficient for a sound processing.
618
619 @item OFFSET_TYPE
620 This node is used to represent a pointer-to-data member.  For a data
621 member @code{X::m} the @code{TYPE_OFFSET_BASETYPE} is @code{X} and the
622 @code{TREE_TYPE} is the type of @code{m}.
623
624 @item TYPENAME_TYPE
625 Used to represent a construct of the form @code{typename T::A}.  The
626 @code{TYPE_CONTEXT} is @code{T}; the @code{TYPE_NAME} is an
627 @code{IDENTIFIER_NODE} for @code{A}.  If the type is specified via a
628 template-id, then @code{TYPENAME_TYPE_FULLNAME} yields a
629 @code{TEMPLATE_ID_EXPR}.  The @code{TREE_TYPE} is non-@code{NULL} if the
630 node is implicitly generated in support for the implicit typename
631 extension; in which case the @code{TREE_TYPE} is a type node for the
632 base-class.
633
634 @item TYPEOF_TYPE
635 Used to represent the @code{__typeof__} extension.  The
636 @code{TYPE_FIELDS} is the expression the type of which is being
637 represented.
638 @end table
639
640 There are variables whose values represent some of the basic types.
641 These include:
642 @table @code
643 @item void_type_node
644 A node for @code{void}.
645
646 @item integer_type_node
647 A node for @code{int}.
648
649 @item unsigned_type_node.
650 A node for @code{unsigned int}.
651
652 @item char_type_node.
653 A node for @code{char}.
654 @end table
655 @noindent
656 It may sometimes be useful to compare one of these variables with a type
657 in hand, using @code{same_type_p}.
658
659 @c ---------------------------------------------------------------------
660 @c Scopes
661 @c ---------------------------------------------------------------------
662
663 @node Scopes
664 @section Scopes
665 @cindex namespace, class, scope
666
667 The root of the entire intermediate representation is the variable
668 @code{global_namespace}.  This is the namespace specified with @code{::}
669 in C++ source code.  All other namespaces, types, variables, functions,
670 and so forth can be found starting with this namespace.
671
672 Besides namespaces, the other high-level scoping construct in C++ is the
673 class.  (Throughout this manual the term @dfn{class} is used to mean the
674 types referred to in the ANSI/ISO C++ Standard as classes; these include
675 types defined with the @code{class}, @code{struct}, and @code{union}
676 keywords.)
677
678 @menu
679 * Namespaces::          Member functions, types, etc.
680 * Classes::             Members, bases, friends, etc.
681 @end menu
682
683 @c ---------------------------------------------------------------------
684 @c Namespaces
685 @c ---------------------------------------------------------------------
686
687 @node Namespaces
688 @subsection Namespaces
689 @cindex namespace
690 @tindex NAMESPACE_DECL
691
692 A namespace is represented by a @code{NAMESPACE_DECL} node.
693
694 However, except for the fact that it is distinguished as the root of the
695 representation, the global namespace is no different from any other
696 namespace.  Thus, in what follows, we describe namespaces generally,
697 rather than the global namespace in particular.
698
699 The following macros and functions can be used on a @code{NAMESPACE_DECL}:
700
701 @ftable @code
702 @item DECL_NAME
703 This macro is used to obtain the @code{IDENTIFIER_NODE} corresponding to
704 the unqualified name of the name of the namespace (@pxref{Identifiers}).
705 The name of the global namespace is @samp{::}, even though in C++ the
706 global namespace is unnamed.  However, you should use comparison with
707 @code{global_namespace}, rather than @code{DECL_NAME} to determine
708 whether or not a namespace is the global one.  An unnamed namespace
709 will have a @code{DECL_NAME} equal to @code{anonymous_namespace_name}.
710 Within a single translation unit, all unnamed namespaces will have the
711 same name.
712
713 @item DECL_CONTEXT
714 This macro returns the enclosing namespace.  The @code{DECL_CONTEXT} for
715 the @code{global_namespace} is @code{NULL_TREE}.
716
717 @item DECL_NAMESPACE_ALIAS
718 If this declaration is for a namespace alias, then
719 @code{DECL_NAMESPACE_ALIAS} is the namespace for which this one is an
720 alias.
721
722 Do not attempt to use @code{cp_namespace_decls} for a namespace which is
723 an alias.  Instead, follow @code{DECL_NAMESPACE_ALIAS} links until you
724 reach an ordinary, non-alias, namespace, and call
725 @code{cp_namespace_decls} there.
726
727 @item DECL_NAMESPACE_STD_P
728 This predicate holds if the namespace is the special @code{::std}
729 namespace.
730
731 @item cp_namespace_decls
732 This function will return the declarations contained in the namespace,
733 including types, overloaded functions, other namespaces, and so forth.
734 If there are no declarations, this function will return
735 @code{NULL_TREE}.  The declarations are connected through their
736 @code{TREE_CHAIN} fields.
737
738 Although most entries on this list will be declarations,
739 @code{TREE_LIST} nodes may also appear.  In this case, the
740 @code{TREE_VALUE} will be an @code{OVERLOAD}.  The value of the
741 @code{TREE_PURPOSE} is unspecified; back ends should ignore this value.
742 As with the other kinds of declarations returned by
743 @code{cp_namespace_decls}, the @code{TREE_CHAIN} will point to the next
744 declaration in this list.
745
746 For more information on the kinds of declarations that can occur on this
747 list, @xref{Declarations}.  Some declarations will not appear on this
748 list.  In particular, no @code{FIELD_DECL}, @code{LABEL_DECL}, or
749 @code{PARM_DECL} nodes will appear here.
750
751 This function cannot be used with namespaces that have
752 @code{DECL_NAMESPACE_ALIAS} set.
753
754 @end ftable
755
756 @c ---------------------------------------------------------------------
757 @c Classes
758 @c ---------------------------------------------------------------------
759
760 @node Classes
761 @subsection Classes
762 @cindex class
763 @tindex RECORD_TYPE
764 @tindex UNION_TYPE
765 @findex CLASSTYPE_DECLARED_CLASS
766 @findex TYPE_BINFO
767 @findex BINFO_TYPE
768 @findex TYPE_FIELDS
769 @findex TYPE_VFIELD
770 @findex TYPE_METHODS
771
772 A class type is represented by either a @code{RECORD_TYPE} or a
773 @code{UNION_TYPE}.  A class declared with the @code{union} tag is
774 represented by a @code{UNION_TYPE}, while classes declared with either
775 the @code{struct} or the @code{class} tag are represented by
776 @code{RECORD_TYPE}s.  You can use the @code{CLASSTYPE_DECLARED_CLASS}
777 macro to discern whether or not a particular type is a @code{class} as
778 opposed to a @code{struct}.  This macro will be true only for classes
779 declared with the @code{class} tag.
780
781 Almost all non-function members are available on the @code{TYPE_FIELDS}
782 list.  Given one member, the next can be found by following the
783 @code{TREE_CHAIN}.  You should not depend in any way on the order in
784 which fields appear on this list.  All nodes on this list will be
785 @samp{DECL} nodes.  A @code{FIELD_DECL} is used to represent a non-static
786 data member, a @code{VAR_DECL} is used to represent a static data
787 member, and a @code{TYPE_DECL} is used to represent a type.  Note that
788 the @code{CONST_DECL} for an enumeration constant will appear on this
789 list, if the enumeration type was declared in the class.  (Of course,
790 the @code{TYPE_DECL} for the enumeration type will appear here as well.)
791 There are no entries for base classes on this list.  In particular,
792 there is no @code{FIELD_DECL} for the ``base-class portion'' of an
793 object.
794
795 The @code{TYPE_VFIELD} is a compiler-generated field used to point to
796 virtual function tables.  It may or may not appear on the
797 @code{TYPE_FIELDS} list.  However, back ends should handle the
798 @code{TYPE_VFIELD} just like all the entries on the @code{TYPE_FIELDS}
799 list.
800
801 The function members are available on the @code{TYPE_METHODS} list.
802 Again, subsequent members are found by following the @code{TREE_CHAIN}
803 field.  If a function is overloaded, each of the overloaded functions
804 appears; no @code{OVERLOAD} nodes appear on the @code{TYPE_METHODS}
805 list.  Implicitly declared functions (including default constructors,
806 copy constructors, assignment operators, and destructors) will appear on
807 this list as well.
808
809 Every class has an associated @dfn{binfo}, which can be obtained with
810 @code{TYPE_BINFO}.  Binfos are used to represent base-classes.  The
811 binfo given by @code{TYPE_BINFO} is the degenerate case, whereby every
812 class is considered to be its own base-class.  The base binfos for a
813 particular binfo are held in a vector, whose length is obtained with
814 @code{BINFO_N_BASE_BINFOS}.  The base binfos themselves are obtained
815 with @code{BINFO_BASE_BINFO} and @code{BINFO_BASE_ITERATE}.  To add a
816 new binfo, use @code{BINFO_BASE_APPEND}.  The vector of base binfos can
817 be obtained with @code{BINFO_BASE_BINFOS}, but normally you do not need
818 to use that.  The class type associated with a binfo is given by
819 @code{BINFO_TYPE}.  It is not always the case that @code{BINFO_TYPE
820 (TYPE_BINFO (x))}, because of typedefs and qualified types.  Neither is
821 it the case that @code{TYPE_BINFO (BINFO_TYPE (y))} is the same binfo as
822 @code{y}.  The reason is that if @code{y} is a binfo representing a
823 base-class @code{B} of a derived class @code{D}, then @code{BINFO_TYPE
824 (y)} will be @code{B}, and @code{TYPE_BINFO (BINFO_TYPE (y))} will be
825 @code{B} as its own base-class, rather than as a base-class of @code{D}.
826
827 The access to a base type can be found with @code{BINFO_BASE_ACCESS}.
828 This will produce @code{access_public_node}, @code{access_private_node}
829 or @code{access_protected_node}.  If bases are always public,
830 @code{BINFO_BASE_ACCESSES} may be @code{NULL}.
831
832 @code{BINFO_VIRTUAL_P} is used to specify whether the binfo is inherited
833 virtually or not.  The other flags, @code{BINFO_MARKED_P} and
834 @code{BINFO_FLAG_1} to @code{BINFO_FLAG_6} can be used for language
835 specific use.
836
837 The following macros can be used on a tree node representing a class-type.
838
839 @ftable @code
840 @item LOCAL_CLASS_P
841 This predicate holds if the class is local class @emph{i.e.}@: declared
842 inside a function body.
843
844 @item TYPE_POLYMORPHIC_P
845 This predicate holds if the class has at least one virtual function
846 (declared or inherited).
847
848 @item TYPE_HAS_DEFAULT_CONSTRUCTOR
849 This predicate holds whenever its argument represents a class-type with
850 default constructor.
851
852 @item CLASSTYPE_HAS_MUTABLE
853 @itemx TYPE_HAS_MUTABLE_P
854 These predicates hold for a class-type having a mutable data member.
855
856 @item CLASSTYPE_NON_POD_P
857 This predicate holds only for class-types that are not PODs.
858
859 @item TYPE_HAS_NEW_OPERATOR
860 This predicate holds for a class-type that defines
861 @code{operator new}.
862
863 @item TYPE_HAS_ARRAY_NEW_OPERATOR
864 This predicate holds for a class-type for which
865 @code{operator new[]} is defined.
866
867 @item TYPE_OVERLOADS_CALL_EXPR
868 This predicate holds for class-type for which the function call
869 @code{operator()} is overloaded.
870
871 @item TYPE_OVERLOADS_ARRAY_REF
872 This predicate holds for a class-type that overloads
873 @code{operator[]}
874
875 @item TYPE_OVERLOADS_ARROW
876 This predicate holds for a class-type for which @code{operator->} is
877 overloaded.
878
879 @end ftable
880
881 @c ---------------------------------------------------------------------
882 @c Declarations
883 @c ---------------------------------------------------------------------
884
885 @node Declarations
886 @section Declarations
887 @cindex declaration
888 @cindex variable
889 @cindex type declaration
890 @tindex LABEL_DECL
891 @tindex CONST_DECL
892 @tindex TYPE_DECL
893 @tindex VAR_DECL
894 @tindex PARM_DECL
895 @tindex FIELD_DECL
896 @tindex NAMESPACE_DECL
897 @tindex RESULT_DECL
898 @tindex TEMPLATE_DECL
899 @tindex THUNK_DECL
900 @tindex USING_DECL
901 @findex THUNK_DELTA
902 @findex DECL_INITIAL
903 @findex DECL_SIZE
904 @findex DECL_ALIGN
905 @findex DECL_EXTERNAL
906
907 This section covers the various kinds of declarations that appear in the
908 internal representation, except for declarations of functions
909 (represented by @code{FUNCTION_DECL} nodes), which are described in
910 @ref{Functions}.
911
912 @menu
913 * Working with declarations::  Macros and functions that work on
914 declarations.
915 * Internal structure:: How declaration nodes are represented. 
916 @end menu
917
918 @node Working with declarations
919 @subsection Working with declarations
920
921 Some macros can be used with any kind of declaration.  These include:
922 @ftable @code
923 @item DECL_NAME
924 This macro returns an @code{IDENTIFIER_NODE} giving the name of the
925 entity.
926
927 @item TREE_TYPE
928 This macro returns the type of the entity declared.
929
930 @item TREE_FILENAME
931 This macro returns the name of the file in which the entity was
932 declared, as a @code{char*}.  For an entity declared implicitly by the
933 compiler (like @code{__builtin_memcpy}), this will be the string
934 @code{"<internal>"}.
935
936 @item TREE_LINENO
937 This macro returns the line number at which the entity was declared, as
938 an @code{int}.
939
940 @item DECL_ARTIFICIAL
941 This predicate holds if the declaration was implicitly generated by the
942 compiler.  For example, this predicate will hold of an implicitly
943 declared member function, or of the @code{TYPE_DECL} implicitly
944 generated for a class type.  Recall that in C++ code like:
945 @smallexample
946 struct S @{@};
947 @end smallexample
948 @noindent
949 is roughly equivalent to C code like:
950 @smallexample
951 struct S @{@};
952 typedef struct S S;
953 @end smallexample
954 The implicitly generated @code{typedef} declaration is represented by a
955 @code{TYPE_DECL} for which @code{DECL_ARTIFICIAL} holds.
956
957 @item DECL_NAMESPACE_SCOPE_P
958 This predicate holds if the entity was declared at a namespace scope.
959
960 @item DECL_CLASS_SCOPE_P
961 This predicate holds if the entity was declared at a class scope.
962
963 @item DECL_FUNCTION_SCOPE_P
964 This predicate holds if the entity was declared inside a function
965 body.
966
967 @end ftable
968
969 The various kinds of declarations include:
970 @table @code
971 @item LABEL_DECL
972 These nodes are used to represent labels in function bodies.  For more
973 information, see @ref{Functions}.  These nodes only appear in block
974 scopes.
975
976 @item CONST_DECL
977 These nodes are used to represent enumeration constants.  The value of
978 the constant is given by @code{DECL_INITIAL} which will be an
979 @code{INTEGER_CST} with the same type as the @code{TREE_TYPE} of the
980 @code{CONST_DECL}, i.e., an @code{ENUMERAL_TYPE}.
981
982 @item RESULT_DECL
983 These nodes represent the value returned by a function.  When a value is
984 assigned to a @code{RESULT_DECL}, that indicates that the value should
985 be returned, via bitwise copy, by the function.  You can use
986 @code{DECL_SIZE} and @code{DECL_ALIGN} on a @code{RESULT_DECL}, just as
987 with a @code{VAR_DECL}.
988
989 @item TYPE_DECL
990 These nodes represent @code{typedef} declarations.  The @code{TREE_TYPE}
991 is the type declared to have the name given by @code{DECL_NAME}.  In
992 some cases, there is no associated name.
993
994 @item VAR_DECL
995 These nodes represent variables with namespace or block scope, as well
996 as static data members.  The @code{DECL_SIZE} and @code{DECL_ALIGN} are
997 analogous to @code{TYPE_SIZE} and @code{TYPE_ALIGN}.  For a declaration,
998 you should always use the @code{DECL_SIZE} and @code{DECL_ALIGN} rather
999 than the @code{TYPE_SIZE} and @code{TYPE_ALIGN} given by the
1000 @code{TREE_TYPE}, since special attributes may have been applied to the
1001 variable to give it a particular size and alignment.  You may use the
1002 predicates @code{DECL_THIS_STATIC} or @code{DECL_THIS_EXTERN} to test
1003 whether the storage class specifiers @code{static} or @code{extern} were
1004 used to declare a variable.
1005
1006 If this variable is initialized (but does not require a constructor),
1007 the @code{DECL_INITIAL} will be an expression for the initializer.  The
1008 initializer should be evaluated, and a bitwise copy into the variable
1009 performed.  If the @code{DECL_INITIAL} is the @code{error_mark_node},
1010 there is an initializer, but it is given by an explicit statement later
1011 in the code; no bitwise copy is required.
1012
1013 GCC provides an extension that allows either automatic variables, or
1014 global variables, to be placed in particular registers.  This extension
1015 is being used for a particular @code{VAR_DECL} if @code{DECL_REGISTER}
1016 holds for the @code{VAR_DECL}, and if @code{DECL_ASSEMBLER_NAME} is not
1017 equal to @code{DECL_NAME}.  In that case, @code{DECL_ASSEMBLER_NAME} is
1018 the name of the register into which the variable will be placed.
1019
1020 @item PARM_DECL
1021 Used to represent a parameter to a function.  Treat these nodes
1022 similarly to @code{VAR_DECL} nodes.  These nodes only appear in the
1023 @code{DECL_ARGUMENTS} for a @code{FUNCTION_DECL}.
1024
1025 The @code{DECL_ARG_TYPE} for a @code{PARM_DECL} is the type that will
1026 actually be used when a value is passed to this function.  It may be a
1027 wider type than the @code{TREE_TYPE} of the parameter; for example, the
1028 ordinary type might be @code{short} while the @code{DECL_ARG_TYPE} is
1029 @code{int}.
1030
1031 @item FIELD_DECL
1032 These nodes represent non-static data members.  The @code{DECL_SIZE} and
1033 @code{DECL_ALIGN} behave as for @code{VAR_DECL} nodes.  
1034 The position of the field within the parent record is specified by a 
1035 combination of three attributes.  @code{DECL_FIELD_OFFSET} is the position,
1036 counting in bytes, of the @code{DECL_OFFSET_ALIGN}-bit sized word containing
1037 the bit of the field closest to the beginning of the structure.  
1038 @code{DECL_FIELD_BIT_OFFSET} is the bit offset of the first bit of the field
1039 within this word; this may be nonzero even for fields that are not bit-fields,
1040 since @code{DECL_OFFSET_ALIGN} may be greater than the natural alignment
1041 of the field's type.
1042
1043 If @code{DECL_C_BIT_FIELD} holds, this field is a bit-field.  In a bit-field,
1044 @code{DECL_BIT_FIELD_TYPE} also contains the type that was originally
1045 specified for it, while DECL_TYPE may be a modified type with lesser precision,
1046 according to the size of the bit field.
1047
1048 @item NAMESPACE_DECL
1049 @xref{Namespaces}.
1050
1051 @item TEMPLATE_DECL
1052
1053 These nodes are used to represent class, function, and variable (static
1054 data member) templates.  The @code{DECL_TEMPLATE_SPECIALIZATIONS} are a
1055 @code{TREE_LIST}.  The @code{TREE_VALUE} of each node in the list is a
1056 @code{TEMPLATE_DECL}s or @code{FUNCTION_DECL}s representing
1057 specializations (including instantiations) of this template.  Back ends
1058 can safely ignore @code{TEMPLATE_DECL}s, but should examine
1059 @code{FUNCTION_DECL} nodes on the specializations list just as they
1060 would ordinary @code{FUNCTION_DECL} nodes.
1061
1062 For a class template, the @code{DECL_TEMPLATE_INSTANTIATIONS} list
1063 contains the instantiations.  The @code{TREE_VALUE} of each node is an
1064 instantiation of the class.  The @code{DECL_TEMPLATE_SPECIALIZATIONS}
1065 contains partial specializations of the class.
1066
1067 @item USING_DECL
1068
1069 Back ends can safely ignore these nodes.
1070
1071 @end table
1072
1073 @node Internal structure
1074 @subsection Internal structure
1075
1076 @code{DECL} nodes are represented internally as a hierarchy of
1077 structures.
1078
1079 @menu
1080 * Current structure hierarchy::  The current DECL node structure
1081 hierarchy.
1082 * Adding new DECL node types:: How to add a new DECL node to a
1083 frontend.
1084 @end menu
1085
1086 @node Current structure hierarchy
1087 @subsubsection Current structure hierarchy
1088
1089 @table @code
1090
1091 @item struct tree_decl_minimal
1092 This is the minimal structure to inherit from in order for common
1093 @code{DECL} macros to work.  The fields it contains are a unique ID,
1094 source location, context, and name.
1095
1096 @item struct tree_decl_common
1097 This structure inherits from @code{struct tree_decl_minimal}.  It
1098 contains fields that most @code{DECL} nodes need, such as a field to
1099 store alignment, machine mode, size, and attributes.
1100
1101 @item struct tree_field_decl
1102 This structure inherits from @code{struct tree_decl_common}.  It is
1103 used to represent @code{FIELD_DECL}.
1104
1105 @item struct tree_label_decl
1106 This structure inherits from @code{struct tree_decl_common}.  It is
1107 used to represent @code{LABEL_DECL}.
1108
1109 @item struct tree_translation_unit_decl
1110 This structure inherits from @code{struct tree_decl_common}.  It is
1111 used to represent @code{TRANSLATION_UNIT_DECL}.
1112
1113 @item struct tree_decl_with_rtl
1114 This structure inherits from @code{struct tree_decl_common}.  It
1115 contains a field to store the low-level RTL associated with a
1116 @code{DECL} node.
1117
1118 @item struct tree_result_decl
1119 This structure inherits from @code{struct tree_decl_with_rtl}.  It is
1120 used to represent @code{RESULT_DECL}.
1121
1122 @item struct tree_const_decl
1123 This structure inherits from @code{struct tree_decl_with_rtl}.  It is
1124 used to represent @code{CONST_DECL}.
1125
1126 @item struct tree_parm_decl
1127 This structure inherits from @code{struct tree_decl_with_rtl}.  It is
1128 used to represent @code{PARM_DECL}.  
1129
1130 @item struct tree_decl_with_vis
1131 This structure inherits from @code{struct tree_decl_with_rtl}.  It
1132 contains fields necessary to store visibility information, as well as
1133 a section name and assembler name.
1134
1135 @item struct tree_var_decl
1136 This structure inherits from @code{struct tree_decl_with_vis}.  It is
1137 used to represent @code{VAR_DECL}.  
1138
1139 @item struct tree_function_decl
1140 This structure inherits from @code{struct tree_decl_with_vis}.  It is
1141 used to represent @code{FUNCTION_DECL}.  
1142
1143 @end table
1144 @node Adding new DECL node types
1145 @subsubsection Adding new DECL node types
1146
1147 Adding a new @code{DECL} tree consists of the following steps
1148
1149 @table @asis
1150
1151 @item Add a new tree code for the @code{DECL} node
1152 For language specific @code{DECL} nodes, there is a @file{.def} file
1153 in each frontend directory where the tree code should be added.
1154 For @code{DECL} nodes that are part of the middle-end, the code should
1155 be added to @file{tree.def}.
1156
1157 @item Create a new structure type for the @code{DECL} node
1158 These structures should inherit from one of the existing structures in
1159 the language hierarchy by using that structure as the first member.
1160
1161 @smallexample
1162 struct tree_foo_decl
1163 @{
1164    struct tree_decl_with_vis common;
1165 @}
1166 @end smallexample
1167
1168 Would create a structure name @code{tree_foo_decl} that inherits from
1169 @code{struct tree_decl_with_vis}.
1170
1171 For language specific @code{DECL} nodes, this new structure type
1172 should go in the appropriate @file{.h} file.
1173 For @code{DECL} nodes that are part of the middle-end, the structure
1174 type should go in @file{tree.h}.
1175
1176 @item Add a member to the tree structure enumerator for the node
1177 For garbage collection and dynamic checking purposes, each @code{DECL}
1178 node structure type is required to have a unique enumerator value
1179 specified with it.
1180 For language specific @code{DECL} nodes, this new enumerator value
1181 should go in the appropriate @file{.def} file.
1182 For @code{DECL} nodes that are part of the middle-end, the enumerator
1183 values are specified in @file{treestruct.def}.
1184
1185 @item Update @code{union tree_node}
1186 In order to make your new structure type usable, it must be added to
1187 @code{union tree_node}.
1188 For language specific @code{DECL} nodes, a new entry should be added
1189 to the appropriate @file{.h} file of the form
1190 @smallexample
1191   struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl;
1192 @end smallexample
1193 For @code{DECL} nodes that are part of the middle-end, the additional
1194 member goes directly into @code{union tree_node} in @file{tree.h}.
1195
1196 @item Update dynamic checking info
1197 In order to be able to check whether accessing a named portion of
1198 @code{union tree_node} is legal, and whether a certain @code{DECL} node
1199 contains one of the enumerated @code{DECL} node structures in the
1200 hierarchy, a simple lookup table is used.
1201 This lookup table needs to be kept up to date with the tree structure
1202 hierarchy, or else checking and containment macros will fail
1203 inappropriately.
1204
1205 For language specific @code{DECL} nodes, their is an @code{init_ts}
1206 function in an appropriate @file{.c} file, which initializes the lookup
1207 table.
1208 Code setting up the table for new @code{DECL} nodes should be added
1209 there.
1210 For each @code{DECL} tree code and enumerator value representing a
1211 member of the inheritance  hierarchy, the table should contain 1 if
1212 that tree code inherits (directly or indirectly) from that member.
1213 Thus, a @code{FOO_DECL} node derived from @code{struct decl_with_rtl},
1214 and enumerator value @code{TS_FOO_DECL}, would be set up as follows
1215 @smallexample
1216 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1;
1217 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1;
1218 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1;
1219 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1;
1220 @end smallexample
1221
1222 For @code{DECL} nodes that are part of the middle-end, the setup code
1223 goes into @file{tree.c}.
1224
1225 @item Add macros to access any new fields and flags
1226
1227 Each added field or flag should have a macro that is used to access
1228 it, that performs appropriate checking to ensure only the right type of
1229 @code{DECL} nodes access the field.
1230
1231 These macros generally take the following form
1232 @smallexample
1233 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname
1234 @end smallexample
1235 However, if the structure is simply a base class for further
1236 structures, something like the following should be used
1237 @smallexample
1238 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT)
1239 #define BASE_STRUCT_FIELDNAME(NODE) \
1240    (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname
1241 @end smallexample
1242
1243 @end table
1244
1245
1246 @c ---------------------------------------------------------------------
1247 @c Functions
1248 @c ---------------------------------------------------------------------
1249
1250 @node Functions
1251 @section Functions
1252 @cindex function
1253 @tindex FUNCTION_DECL
1254 @tindex OVERLOAD
1255 @findex OVL_CURRENT
1256 @findex OVL_NEXT
1257
1258 A function is represented by a @code{FUNCTION_DECL} node.  A set of
1259 overloaded functions is sometimes represented by a @code{OVERLOAD} node.
1260
1261 An @code{OVERLOAD} node is not a declaration, so none of the
1262 @samp{DECL_} macros should be used on an @code{OVERLOAD}.  An
1263 @code{OVERLOAD} node is similar to a @code{TREE_LIST}.  Use
1264 @code{OVL_CURRENT} to get the function associated with an
1265 @code{OVERLOAD} node; use @code{OVL_NEXT} to get the next
1266 @code{OVERLOAD} node in the list of overloaded functions.  The macros
1267 @code{OVL_CURRENT} and @code{OVL_NEXT} are actually polymorphic; you can
1268 use them to work with @code{FUNCTION_DECL} nodes as well as with
1269 overloads.  In the case of a @code{FUNCTION_DECL}, @code{OVL_CURRENT}
1270 will always return the function itself, and @code{OVL_NEXT} will always
1271 be @code{NULL_TREE}.
1272
1273 To determine the scope of a function, you can use the
1274 @code{DECL_CONTEXT} macro.  This macro will return the class
1275 (either a @code{RECORD_TYPE} or a @code{UNION_TYPE}) or namespace (a
1276 @code{NAMESPACE_DECL}) of which the function is a member.  For a virtual
1277 function, this macro returns the class in which the function was
1278 actually defined, not the base class in which the virtual declaration
1279 occurred.
1280
1281 If a friend function is defined in a class scope, the
1282 @code{DECL_FRIEND_CONTEXT} macro can be used to determine the class in
1283 which it was defined.  For example, in
1284 @smallexample
1285 class C @{ friend void f() @{@} @};
1286 @end smallexample
1287 @noindent
1288 the @code{DECL_CONTEXT} for @code{f} will be the
1289 @code{global_namespace}, but the @code{DECL_FRIEND_CONTEXT} will be the
1290 @code{RECORD_TYPE} for @code{C}.
1291
1292 In C, the @code{DECL_CONTEXT} for a function maybe another function.
1293 This representation indicates that the GNU nested function extension
1294 is in use.  For details on the semantics of nested functions, see the
1295 GCC Manual.  The nested function can refer to local variables in its
1296 containing function.  Such references are not explicitly marked in the
1297 tree structure; back ends must look at the @code{DECL_CONTEXT} for the
1298 referenced @code{VAR_DECL}.  If the @code{DECL_CONTEXT} for the
1299 referenced @code{VAR_DECL} is not the same as the function currently
1300 being processed, and neither @code{DECL_EXTERNAL} nor
1301 @code{TREE_STATIC} hold, then the reference is to a local variable in
1302 a containing function, and the back end must take appropriate action.
1303
1304 @menu
1305 * Function Basics::     Function names, linkage, and so forth.
1306 * Function Bodies::     The statements that make up a function body.
1307 @end menu
1308
1309 @c ---------------------------------------------------------------------
1310 @c Function Basics
1311 @c ---------------------------------------------------------------------
1312
1313 @node Function Basics
1314 @subsection Function Basics
1315 @cindex constructor
1316 @cindex destructor
1317 @cindex copy constructor
1318 @cindex assignment operator
1319 @cindex linkage
1320 @findex DECL_NAME
1321 @findex DECL_ASSEMBLER_NAME
1322 @findex TREE_PUBLIC
1323 @findex DECL_LINKONCE_P
1324 @findex DECL_FUNCTION_MEMBER_P
1325 @findex DECL_CONSTRUCTOR_P
1326 @findex DECL_DESTRUCTOR_P
1327 @findex DECL_OVERLOADED_OPERATOR_P
1328 @findex DECL_CONV_FN_P
1329 @findex DECL_ARTIFICIAL
1330 @findex DECL_GLOBAL_CTOR_P
1331 @findex DECL_GLOBAL_DTOR_P
1332 @findex GLOBAL_INIT_PRIORITY
1333 @findex DECL_FUNCTION_SPECIFIC_TARGET
1334 @findex DECL_FUNCTION_SPECIFIC_OPTIMIZATION
1335
1336 The following macros and functions can be used on a @code{FUNCTION_DECL}:
1337 @ftable @code
1338 @item DECL_MAIN_P
1339 This predicate holds for a function that is the program entry point
1340 @code{::code}.
1341
1342 @item DECL_NAME
1343 This macro returns the unqualified name of the function, as an
1344 @code{IDENTIFIER_NODE}.  For an instantiation of a function template,
1345 the @code{DECL_NAME} is the unqualified name of the template, not
1346 something like @code{f<int>}.  The value of @code{DECL_NAME} is
1347 undefined when used on a constructor, destructor, overloaded operator,
1348 or type-conversion operator, or any function that is implicitly
1349 generated by the compiler.  See below for macros that can be used to
1350 distinguish these cases.
1351
1352 @item DECL_ASSEMBLER_NAME
1353 This macro returns the mangled name of the function, also an
1354 @code{IDENTIFIER_NODE}.  This name does not contain leading underscores
1355 on systems that prefix all identifiers with underscores.  The mangled
1356 name is computed in the same way on all platforms; if special processing
1357 is required to deal with the object file format used on a particular
1358 platform, it is the responsibility of the back end to perform those
1359 modifications.  (Of course, the back end should not modify
1360 @code{DECL_ASSEMBLER_NAME} itself.)
1361
1362 Using @code{DECL_ASSEMBLER_NAME} will cause additional memory to be
1363 allocated (for the mangled name of the entity) so it should be used
1364 only when emitting assembly code.  It should not be used within the
1365 optimizers to determine whether or not two declarations are the same,
1366 even though some of the existing optimizers do use it in that way.
1367 These uses will be removed over time.
1368
1369 @item DECL_EXTERNAL
1370 This predicate holds if the function is undefined.
1371
1372 @item TREE_PUBLIC
1373 This predicate holds if the function has external linkage.
1374
1375 @item DECL_LOCAL_FUNCTION_P
1376 This predicate holds if the function was declared at block scope, even
1377 though it has a global scope.
1378
1379 @item DECL_ANTICIPATED
1380 This predicate holds if the function is a built-in function but its
1381 prototype is not yet explicitly declared.
1382
1383 @item DECL_EXTERN_C_FUNCTION_P
1384 This predicate holds if the function is declared as an
1385 `@code{extern "C"}' function.
1386
1387 @item DECL_LINKONCE_P
1388 This macro holds if multiple copies of this function may be emitted in
1389 various translation units.  It is the responsibility of the linker to
1390 merge the various copies.  Template instantiations are the most common
1391 example of functions for which @code{DECL_LINKONCE_P} holds; G++
1392 instantiates needed templates in all translation units which require them,
1393 and then relies on the linker to remove duplicate instantiations.
1394
1395 FIXME: This macro is not yet implemented.
1396
1397 @item DECL_FUNCTION_MEMBER_P
1398 This macro holds if the function is a member of a class, rather than a
1399 member of a namespace.
1400
1401 @item DECL_STATIC_FUNCTION_P
1402 This predicate holds if the function a static member function.
1403
1404 @item DECL_NONSTATIC_MEMBER_FUNCTION_P
1405 This macro holds for a non-static member function.
1406
1407 @item DECL_CONST_MEMFUNC_P
1408 This predicate holds for a @code{const}-member function.
1409
1410 @item DECL_VOLATILE_MEMFUNC_P
1411 This predicate holds for a @code{volatile}-member function.
1412
1413 @item DECL_CONSTRUCTOR_P
1414 This macro holds if the function is a constructor.
1415
1416 @item DECL_NONCONVERTING_P
1417 This predicate holds if the constructor is a non-converting constructor.
1418
1419 @item DECL_COMPLETE_CONSTRUCTOR_P
1420 This predicate holds for a function which is a constructor for an object
1421 of a complete type.
1422
1423 @item DECL_BASE_CONSTRUCTOR_P
1424 This predicate holds for a function which is a constructor for a base
1425 class sub-object.
1426
1427 @item DECL_COPY_CONSTRUCTOR_P
1428 This predicate holds for a function which is a copy-constructor.
1429
1430 @item DECL_DESTRUCTOR_P
1431 This macro holds if the function is a destructor.
1432
1433 @item DECL_COMPLETE_DESTRUCTOR_P
1434 This predicate holds if the function is the destructor for an object a
1435 complete type.
1436
1437 @item DECL_OVERLOADED_OPERATOR_P
1438 This macro holds if the function is an overloaded operator.
1439
1440 @item DECL_CONV_FN_P
1441 This macro holds if the function is a type-conversion operator.
1442
1443 @item DECL_GLOBAL_CTOR_P
1444 This predicate holds if the function is a file-scope initialization
1445 function.
1446
1447 @item DECL_GLOBAL_DTOR_P
1448 This predicate holds if the function is a file-scope finalization
1449 function.
1450
1451 @item DECL_THUNK_P
1452 This predicate holds if the function is a thunk.
1453
1454 These functions represent stub code that adjusts the @code{this} pointer
1455 and then jumps to another function.  When the jumped-to function
1456 returns, control is transferred directly to the caller, without
1457 returning to the thunk.  The first parameter to the thunk is always the
1458 @code{this} pointer; the thunk should add @code{THUNK_DELTA} to this
1459 value.  (The @code{THUNK_DELTA} is an @code{int}, not an
1460 @code{INTEGER_CST}.)
1461
1462 Then, if @code{THUNK_VCALL_OFFSET} (an @code{INTEGER_CST}) is nonzero
1463 the adjusted @code{this} pointer must be adjusted again.  The complete
1464 calculation is given by the following pseudo-code:
1465
1466 @smallexample
1467 this += THUNK_DELTA
1468 if (THUNK_VCALL_OFFSET)
1469   this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET]
1470 @end smallexample
1471
1472 Finally, the thunk should jump to the location given
1473 by @code{DECL_INITIAL}; this will always be an expression for the
1474 address of a function.
1475
1476 @item DECL_NON_THUNK_FUNCTION_P
1477 This predicate holds if the function is @emph{not} a thunk function.
1478
1479 @item GLOBAL_INIT_PRIORITY
1480 If either @code{DECL_GLOBAL_CTOR_P} or @code{DECL_GLOBAL_DTOR_P} holds,
1481 then this gives the initialization priority for the function.  The
1482 linker will arrange that all functions for which
1483 @code{DECL_GLOBAL_CTOR_P} holds are run in increasing order of priority
1484 before @code{main} is called.  When the program exits, all functions for
1485 which @code{DECL_GLOBAL_DTOR_P} holds are run in the reverse order.
1486
1487 @item DECL_ARTIFICIAL
1488 This macro holds if the function was implicitly generated by the
1489 compiler, rather than explicitly declared.  In addition to implicitly
1490 generated class member functions, this macro holds for the special
1491 functions created to implement static initialization and destruction, to
1492 compute run-time type information, and so forth.
1493
1494 @item DECL_ARGUMENTS
1495 This macro returns the @code{PARM_DECL} for the first argument to the
1496 function.  Subsequent @code{PARM_DECL} nodes can be obtained by
1497 following the @code{TREE_CHAIN} links.
1498
1499 @item DECL_RESULT
1500 This macro returns the @code{RESULT_DECL} for the function.
1501
1502 @item TREE_TYPE
1503 This macro returns the @code{FUNCTION_TYPE} or @code{METHOD_TYPE} for
1504 the function.
1505
1506 @item TYPE_RAISES_EXCEPTIONS
1507 This macro returns the list of exceptions that a (member-)function can
1508 raise.  The returned list, if non @code{NULL}, is comprised of nodes
1509 whose @code{TREE_VALUE} represents a type.
1510
1511 @item TYPE_NOTHROW_P
1512 This predicate holds when the exception-specification of its arguments
1513 is of the form `@code{()}'.
1514
1515 @item DECL_ARRAY_DELETE_OPERATOR_P
1516 This predicate holds if the function an overloaded
1517 @code{operator delete[]}.
1518
1519 @item DECL_FUNCTION_SPECIFIC_TARGET
1520 This macro returns a tree node that holds the target options that are
1521 to be used to compile this particular function or @code{NULL_TREE} if
1522 the function is to be compiled with the target options specified on
1523 the command line.
1524
1525 @item DECL_FUNCTION_SPECIFIC_OPTIMIZATION
1526 This macro returns a tree node that holds the optimization options
1527 that are to be used to compile this particular function or
1528 @code{NULL_TREE} if the function is to be compiled with the
1529 optimization options specified on the command line.
1530 @end ftable
1531
1532 @c ---------------------------------------------------------------------
1533 @c Function Bodies
1534 @c ---------------------------------------------------------------------
1535
1536 @node Function Bodies
1537 @subsection Function Bodies
1538 @cindex function body
1539 @cindex statements
1540 @tindex BREAK_STMT
1541 @tindex CLEANUP_STMT
1542 @findex CLEANUP_DECL
1543 @findex CLEANUP_EXPR
1544 @tindex CONTINUE_STMT
1545 @tindex DECL_STMT
1546 @findex DECL_STMT_DECL
1547 @tindex DO_STMT
1548 @findex DO_BODY
1549 @findex DO_COND
1550 @tindex EMPTY_CLASS_EXPR
1551 @tindex EXPR_STMT
1552 @findex EXPR_STMT_EXPR
1553 @tindex FOR_STMT
1554 @findex FOR_INIT_STMT
1555 @findex FOR_COND
1556 @findex FOR_EXPR
1557 @findex FOR_BODY
1558 @tindex HANDLER
1559 @tindex IF_STMT
1560 @findex IF_COND
1561 @findex THEN_CLAUSE
1562 @findex ELSE_CLAUSE
1563 @tindex RETURN_STMT
1564 @findex RETURN_EXPR
1565 @tindex SUBOBJECT
1566 @findex SUBOBJECT_CLEANUP
1567 @tindex SWITCH_STMT
1568 @findex SWITCH_COND
1569 @findex SWITCH_BODY
1570 @tindex TRY_BLOCK
1571 @findex TRY_STMTS
1572 @findex TRY_HANDLERS
1573 @findex HANDLER_PARMS
1574 @findex HANDLER_BODY
1575 @findex USING_STMT
1576 @tindex WHILE_STMT
1577 @findex WHILE_BODY
1578 @findex WHILE_COND
1579
1580 A function that has a definition in the current translation unit will
1581 have a non-@code{NULL} @code{DECL_INITIAL}.  However, back ends should not make
1582 use of the particular value given by @code{DECL_INITIAL}.
1583
1584 The @code{DECL_SAVED_TREE} macro will give the complete body of the
1585 function.
1586
1587 @subsubsection Statements
1588
1589 There are tree nodes corresponding to all of the source-level
1590 statement constructs, used within the C and C++ frontends.  These are
1591 enumerated here, together with a list of the various macros that can
1592 be used to obtain information about them.  There are a few macros that
1593 can be used with all statements:
1594
1595 @ftable @code
1596 @item STMT_IS_FULL_EXPR_P
1597 In C++, statements normally constitute ``full expressions''; temporaries
1598 created during a statement are destroyed when the statement is complete.
1599 However, G++ sometimes represents expressions by statements; these
1600 statements will not have @code{STMT_IS_FULL_EXPR_P} set.  Temporaries
1601 created during such statements should be destroyed when the innermost
1602 enclosing statement with @code{STMT_IS_FULL_EXPR_P} set is exited.
1603
1604 @end ftable
1605
1606 Here is the list of the various statement nodes, and the macros used to
1607 access them.  This documentation describes the use of these nodes in
1608 non-template functions (including instantiations of template functions).
1609 In template functions, the same nodes are used, but sometimes in
1610 slightly different ways.
1611
1612 Many of the statements have substatements.  For example, a @code{while}
1613 loop will have a body, which is itself a statement.  If the substatement
1614 is @code{NULL_TREE}, it is considered equivalent to a statement
1615 consisting of a single @code{;}, i.e., an expression statement in which
1616 the expression has been omitted.  A substatement may in fact be a list
1617 of statements, connected via their @code{TREE_CHAIN}s.  So, you should
1618 always process the statement tree by looping over substatements, like
1619 this:
1620 @smallexample
1621 void process_stmt (stmt)
1622      tree stmt;
1623 @{
1624   while (stmt)
1625     @{
1626       switch (TREE_CODE (stmt))
1627         @{
1628         case IF_STMT:
1629           process_stmt (THEN_CLAUSE (stmt));
1630           /* @r{More processing here.}  */
1631           break;
1632
1633         @dots{}
1634         @}
1635
1636       stmt = TREE_CHAIN (stmt);
1637     @}
1638 @}
1639 @end smallexample
1640 In other words, while the @code{then} clause of an @code{if} statement
1641 in C++ can be only one statement (although that one statement may be a
1642 compound statement), the intermediate representation will sometimes use
1643 several statements chained together.
1644
1645 @table @code
1646 @item ASM_EXPR
1647
1648 Used to represent an inline assembly statement.  For an inline assembly
1649 statement like:
1650 @smallexample
1651 asm ("mov x, y");
1652 @end smallexample
1653 The @code{ASM_STRING} macro will return a @code{STRING_CST} node for
1654 @code{"mov x, y"}.  If the original statement made use of the
1655 extended-assembly syntax, then @code{ASM_OUTPUTS},
1656 @code{ASM_INPUTS}, and @code{ASM_CLOBBERS} will be the outputs, inputs,
1657 and clobbers for the statement, represented as @code{STRING_CST} nodes.
1658 The extended-assembly syntax looks like:
1659 @smallexample
1660 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
1661 @end smallexample
1662 The first string is the @code{ASM_STRING}, containing the instruction
1663 template.  The next two strings are the output and inputs, respectively;
1664 this statement has no clobbers.  As this example indicates, ``plain''
1665 assembly statements are merely a special case of extended assembly
1666 statements; they have no cv-qualifiers, outputs, inputs, or clobbers.
1667 All of the strings will be @code{NUL}-terminated, and will contain no
1668 embedded @code{NUL}-characters.
1669
1670 If the assembly statement is declared @code{volatile}, or if the
1671 statement was not an extended assembly statement, and is therefore
1672 implicitly volatile, then the predicate @code{ASM_VOLATILE_P} will hold
1673 of the @code{ASM_EXPR}.
1674
1675 @item BREAK_STMT
1676
1677 Used to represent a @code{break} statement.  There are no additional
1678 fields.
1679
1680 @item CASE_LABEL_EXPR
1681
1682 Use to represent a @code{case} label, range of @code{case} labels, or a
1683 @code{default} label.  If @code{CASE_LOW} is @code{NULL_TREE}, then this is a
1684 @code{default} label.  Otherwise, if @code{CASE_HIGH} is @code{NULL_TREE}, then
1685 this is an ordinary @code{case} label.  In this case, @code{CASE_LOW} is
1686 an expression giving the value of the label.  Both @code{CASE_LOW} and
1687 @code{CASE_HIGH} are @code{INTEGER_CST} nodes.  These values will have
1688 the same type as the condition expression in the switch statement.
1689
1690 Otherwise, if both @code{CASE_LOW} and @code{CASE_HIGH} are defined, the
1691 statement is a range of case labels.  Such statements originate with the
1692 extension that allows users to write things of the form:
1693 @smallexample
1694 case 2 ... 5:
1695 @end smallexample
1696 The first value will be @code{CASE_LOW}, while the second will be
1697 @code{CASE_HIGH}.
1698
1699 @item CLEANUP_STMT
1700
1701 Used to represent an action that should take place upon exit from the
1702 enclosing scope.  Typically, these actions are calls to destructors for
1703 local objects, but back ends cannot rely on this fact.  If these nodes
1704 are in fact representing such destructors, @code{CLEANUP_DECL} will be
1705 the @code{VAR_DECL} destroyed.  Otherwise, @code{CLEANUP_DECL} will be
1706 @code{NULL_TREE}.  In any case, the @code{CLEANUP_EXPR} is the
1707 expression to execute.  The cleanups executed on exit from a scope
1708 should be run in the reverse order of the order in which the associated
1709 @code{CLEANUP_STMT}s were encountered.
1710
1711 @item CONTINUE_STMT
1712
1713 Used to represent a @code{continue} statement.  There are no additional
1714 fields.
1715
1716 @item CTOR_STMT
1717
1718 Used to mark the beginning (if @code{CTOR_BEGIN_P} holds) or end (if
1719 @code{CTOR_END_P} holds of the main body of a constructor.  See also
1720 @code{SUBOBJECT} for more information on how to use these nodes.
1721
1722 @item DECL_STMT
1723
1724 Used to represent a local declaration.  The @code{DECL_STMT_DECL} macro
1725 can be used to obtain the entity declared.  This declaration may be a
1726 @code{LABEL_DECL}, indicating that the label declared is a local label.
1727 (As an extension, GCC allows the declaration of labels with scope.)  In
1728 C, this declaration may be a @code{FUNCTION_DECL}, indicating the
1729 use of the GCC nested function extension.  For more information,
1730 @pxref{Functions}.
1731
1732 @item DO_STMT
1733
1734 Used to represent a @code{do} loop.  The body of the loop is given by
1735 @code{DO_BODY} while the termination condition for the loop is given by
1736 @code{DO_COND}.  The condition for a @code{do}-statement is always an
1737 expression.
1738
1739 @item EMPTY_CLASS_EXPR
1740
1741 Used to represent a temporary object of a class with no data whose
1742 address is never taken.  (All such objects are interchangeable.)  The
1743 @code{TREE_TYPE} represents the type of the object.
1744
1745 @item EXPR_STMT
1746
1747 Used to represent an expression statement.  Use @code{EXPR_STMT_EXPR} to
1748 obtain the expression.
1749
1750 @item FOR_STMT
1751
1752 Used to represent a @code{for} statement.  The @code{FOR_INIT_STMT} is
1753 the initialization statement for the loop.  The @code{FOR_COND} is the
1754 termination condition.  The @code{FOR_EXPR} is the expression executed
1755 right before the @code{FOR_COND} on each loop iteration; often, this
1756 expression increments a counter.  The body of the loop is given by
1757 @code{FOR_BODY}.  Note that @code{FOR_INIT_STMT} and @code{FOR_BODY}
1758 return statements, while @code{FOR_COND} and @code{FOR_EXPR} return
1759 expressions.
1760
1761 @item GOTO_EXPR
1762
1763 Used to represent a @code{goto} statement.  The @code{GOTO_DESTINATION} will
1764 usually be a @code{LABEL_DECL}.  However, if the ``computed goto'' extension
1765 has been used, the @code{GOTO_DESTINATION} will be an arbitrary expression
1766 indicating the destination.  This expression will always have pointer type.
1767
1768 @item HANDLER
1769
1770 Used to represent a C++ @code{catch} block.  The @code{HANDLER_TYPE}
1771 is the type of exception that will be caught by this handler; it is
1772 equal (by pointer equality) to @code{NULL} if this handler is for all
1773 types.  @code{HANDLER_PARMS} is the @code{DECL_STMT} for the catch
1774 parameter, and @code{HANDLER_BODY} is the code for the block itself.
1775
1776 @item IF_STMT
1777
1778 Used to represent an @code{if} statement.  The @code{IF_COND} is the
1779 expression.
1780
1781 If the condition is a @code{TREE_LIST}, then the @code{TREE_PURPOSE} is
1782 a statement (usually a @code{DECL_STMT}).  Each time the condition is
1783 evaluated, the statement should be executed.  Then, the
1784 @code{TREE_VALUE} should be used as the conditional expression itself.
1785 This representation is used to handle C++ code like this:
1786
1787 @smallexample
1788 if (int i = 7) @dots{}
1789 @end smallexample
1790
1791 where there is a new local variable (or variables) declared within the
1792 condition.
1793
1794 The @code{THEN_CLAUSE} represents the statement given by the @code{then}
1795 condition, while the @code{ELSE_CLAUSE} represents the statement given
1796 by the @code{else} condition.
1797
1798 @item LABEL_EXPR
1799
1800 Used to represent a label.  The @code{LABEL_DECL} declared by this
1801 statement can be obtained with the @code{LABEL_EXPR_LABEL} macro.  The
1802 @code{IDENTIFIER_NODE} giving the name of the label can be obtained from
1803 the @code{LABEL_DECL} with @code{DECL_NAME}.
1804
1805 @item RETURN_STMT
1806
1807 Used to represent a @code{return} statement.  The @code{RETURN_EXPR} is
1808 the expression returned; it will be @code{NULL_TREE} if the statement
1809 was just
1810 @smallexample
1811 return;
1812 @end smallexample
1813
1814 @item SUBOBJECT
1815
1816 In a constructor, these nodes are used to mark the point at which a
1817 subobject of @code{this} is fully constructed.  If, after this point, an
1818 exception is thrown before a @code{CTOR_STMT} with @code{CTOR_END_P} set
1819 is encountered, the @code{SUBOBJECT_CLEANUP} must be executed.  The
1820 cleanups must be executed in the reverse order in which they appear.
1821
1822 @item SWITCH_STMT
1823
1824 Used to represent a @code{switch} statement.  The @code{SWITCH_STMT_COND}
1825 is the expression on which the switch is occurring.  See the documentation
1826 for an @code{IF_STMT} for more information on the representation used
1827 for the condition.  The @code{SWITCH_STMT_BODY} is the body of the switch
1828 statement.   The @code{SWITCH_STMT_TYPE} is the original type of switch
1829 expression as given in the source, before any compiler conversions.
1830
1831 @item TRY_BLOCK
1832 Used to represent a @code{try} block.  The body of the try block is
1833 given by @code{TRY_STMTS}.  Each of the catch blocks is a @code{HANDLER}
1834 node.  The first handler is given by @code{TRY_HANDLERS}.  Subsequent
1835 handlers are obtained by following the @code{TREE_CHAIN} link from one
1836 handler to the next.  The body of the handler is given by
1837 @code{HANDLER_BODY}.
1838
1839 If @code{CLEANUP_P} holds of the @code{TRY_BLOCK}, then the
1840 @code{TRY_HANDLERS} will not be a @code{HANDLER} node.  Instead, it will
1841 be an expression that should be executed if an exception is thrown in
1842 the try block.  It must rethrow the exception after executing that code.
1843 And, if an exception is thrown while the expression is executing,
1844 @code{terminate} must be called.
1845
1846 @item USING_STMT
1847 Used to represent a @code{using} directive.  The namespace is given by
1848 @code{USING_STMT_NAMESPACE}, which will be a NAMESPACE_DECL@.  This node
1849 is needed inside template functions, to implement using directives
1850 during instantiation.
1851
1852 @item WHILE_STMT
1853
1854 Used to represent a @code{while} loop.  The @code{WHILE_COND} is the
1855 termination condition for the loop.  See the documentation for an
1856 @code{IF_STMT} for more information on the representation used for the
1857 condition.
1858
1859 The @code{WHILE_BODY} is the body of the loop.
1860
1861 @end table
1862
1863 @c ---------------------------------------------------------------------
1864 @c Attributes
1865 @c ---------------------------------------------------------------------
1866 @node Attributes
1867 @section Attributes in trees
1868 @cindex attributes
1869
1870 Attributes, as specified using the @code{__attribute__} keyword, are
1871 represented internally as a @code{TREE_LIST}.  The @code{TREE_PURPOSE}
1872 is the name of the attribute, as an @code{IDENTIFIER_NODE}.  The
1873 @code{TREE_VALUE} is a @code{TREE_LIST} of the arguments of the
1874 attribute, if any, or @code{NULL_TREE} if there are no arguments; the
1875 arguments are stored as the @code{TREE_VALUE} of successive entries in
1876 the list, and may be identifiers or expressions.  The @code{TREE_CHAIN}
1877 of the attribute is the next attribute in a list of attributes applying
1878 to the same declaration or type, or @code{NULL_TREE} if there are no
1879 further attributes in the list.
1880
1881 Attributes may be attached to declarations and to types; these
1882 attributes may be accessed with the following macros.  All attributes
1883 are stored in this way, and many also cause other changes to the
1884 declaration or type or to other internal compiler data structures.
1885
1886 @deftypefn {Tree Macro} tree DECL_ATTRIBUTES (tree @var{decl})
1887 This macro returns the attributes on the declaration @var{decl}.
1888 @end deftypefn
1889
1890 @deftypefn {Tree Macro} tree TYPE_ATTRIBUTES (tree @var{type})
1891 This macro returns the attributes on the type @var{type}.
1892 @end deftypefn
1893
1894 @c ---------------------------------------------------------------------
1895 @c Expressions
1896 @c ---------------------------------------------------------------------
1897
1898 @node Expression trees
1899 @section Expressions
1900 @cindex expression
1901 @findex TREE_TYPE
1902 @findex TREE_OPERAND
1903 @tindex INTEGER_CST
1904 @findex TREE_INT_CST_HIGH
1905 @findex TREE_INT_CST_LOW
1906 @findex tree_int_cst_lt
1907 @findex tree_int_cst_equal
1908 @tindex REAL_CST
1909 @tindex FIXED_CST
1910 @tindex COMPLEX_CST
1911 @tindex VECTOR_CST
1912 @tindex STRING_CST
1913 @findex TREE_STRING_LENGTH
1914 @findex TREE_STRING_POINTER
1915 @tindex PTRMEM_CST
1916 @findex PTRMEM_CST_CLASS
1917 @findex PTRMEM_CST_MEMBER
1918 @tindex VAR_DECL
1919 @tindex NEGATE_EXPR
1920 @tindex ABS_EXPR
1921 @tindex BIT_NOT_EXPR
1922 @tindex TRUTH_NOT_EXPR
1923 @tindex PREDECREMENT_EXPR
1924 @tindex PREINCREMENT_EXPR
1925 @tindex POSTDECREMENT_EXPR
1926 @tindex POSTINCREMENT_EXPR
1927 @tindex ADDR_EXPR
1928 @tindex INDIRECT_REF
1929 @tindex FIX_TRUNC_EXPR
1930 @tindex FLOAT_EXPR
1931 @tindex COMPLEX_EXPR
1932 @tindex CONJ_EXPR
1933 @tindex REALPART_EXPR
1934 @tindex IMAGPART_EXPR
1935 @tindex NON_LVALUE_EXPR
1936 @tindex NOP_EXPR
1937 @tindex CONVERT_EXPR
1938 @tindex FIXED_CONVERT_EXPR
1939 @tindex THROW_EXPR
1940 @tindex LSHIFT_EXPR
1941 @tindex RSHIFT_EXPR
1942 @tindex BIT_IOR_EXPR
1943 @tindex BIT_XOR_EXPR
1944 @tindex BIT_AND_EXPR
1945 @tindex TRUTH_ANDIF_EXPR
1946 @tindex TRUTH_ORIF_EXPR
1947 @tindex TRUTH_AND_EXPR
1948 @tindex TRUTH_OR_EXPR
1949 @tindex TRUTH_XOR_EXPR
1950 @tindex POINTER_PLUS_EXPR
1951 @tindex PLUS_EXPR
1952 @tindex MINUS_EXPR
1953 @tindex MULT_EXPR
1954 @tindex RDIV_EXPR
1955 @tindex TRUNC_DIV_EXPR
1956 @tindex FLOOR_DIV_EXPR
1957 @tindex CEIL_DIV_EXPR
1958 @tindex ROUND_DIV_EXPR
1959 @tindex TRUNC_MOD_EXPR
1960 @tindex FLOOR_MOD_EXPR
1961 @tindex CEIL_MOD_EXPR
1962 @tindex ROUND_MOD_EXPR
1963 @tindex EXACT_DIV_EXPR
1964 @tindex ARRAY_REF
1965 @tindex ARRAY_RANGE_REF
1966 @tindex TARGET_MEM_REF
1967 @tindex LT_EXPR
1968 @tindex LE_EXPR
1969 @tindex GT_EXPR
1970 @tindex GE_EXPR
1971 @tindex EQ_EXPR
1972 @tindex NE_EXPR
1973 @tindex ORDERED_EXPR
1974 @tindex UNORDERED_EXPR
1975 @tindex UNLT_EXPR
1976 @tindex UNLE_EXPR
1977 @tindex UNGT_EXPR
1978 @tindex UNGE_EXPR
1979 @tindex UNEQ_EXPR
1980 @tindex LTGT_EXPR
1981 @tindex MODIFY_EXPR
1982 @tindex INIT_EXPR
1983 @tindex COMPONENT_REF
1984 @tindex COMPOUND_EXPR
1985 @tindex COND_EXPR
1986 @tindex CALL_EXPR
1987 @tindex STMT_EXPR
1988 @tindex BIND_EXPR
1989 @tindex LOOP_EXPR
1990 @tindex EXIT_EXPR
1991 @tindex CLEANUP_POINT_EXPR
1992 @tindex CONSTRUCTOR
1993 @tindex COMPOUND_LITERAL_EXPR
1994 @tindex SAVE_EXPR
1995 @tindex TARGET_EXPR
1996 @tindex AGGR_INIT_EXPR
1997 @tindex VA_ARG_EXPR
1998 @tindex CHANGE_DYNAMIC_TYPE_EXPR
1999 @tindex OMP_PARALLEL
2000 @tindex OMP_FOR
2001 @tindex OMP_SECTIONS
2002 @tindex OMP_SINGLE
2003 @tindex OMP_SECTION
2004 @tindex OMP_MASTER
2005 @tindex OMP_ORDERED
2006 @tindex OMP_CRITICAL
2007 @tindex OMP_RETURN
2008 @tindex OMP_CONTINUE
2009 @tindex OMP_ATOMIC
2010 @tindex OMP_CLAUSE
2011 @tindex VEC_LSHIFT_EXPR
2012 @tindex VEC_RSHIFT_EXPR
2013 @tindex VEC_WIDEN_MULT_HI_EXPR
2014 @tindex VEC_WIDEN_MULT_LO_EXPR
2015 @tindex VEC_UNPACK_HI_EXPR
2016 @tindex VEC_UNPACK_LO_EXPR
2017 @tindex VEC_UNPACK_FLOAT_HI_EXPR
2018 @tindex VEC_UNPACK_FLOAT_LO_EXPR
2019 @tindex VEC_PACK_TRUNC_EXPR
2020 @tindex VEC_PACK_SAT_EXPR
2021 @tindex VEC_PACK_FIX_TRUNC_EXPR
2022 @tindex VEC_EXTRACT_EVEN_EXPR 
2023 @tindex VEC_EXTRACT_ODD_EXPR
2024 @tindex VEC_INTERLEAVE_HIGH_EXPR
2025 @tindex VEC_INTERLEAVE_LOW_EXPR
2026
2027 The internal representation for expressions is for the most part quite
2028 straightforward.  However, there are a few facts that one must bear in
2029 mind.  In particular, the expression ``tree'' is actually a directed
2030 acyclic graph.  (For example there may be many references to the integer
2031 constant zero throughout the source program; many of these will be
2032 represented by the same expression node.)  You should not rely on
2033 certain kinds of node being shared, nor should you rely on certain kinds of
2034 nodes being unshared.
2035
2036 The following macros can be used with all expression nodes:
2037
2038 @ftable @code
2039 @item TREE_TYPE
2040 Returns the type of the expression.  This value may not be precisely the
2041 same type that would be given the expression in the original program.
2042 @end ftable
2043
2044 In what follows, some nodes that one might expect to always have type
2045 @code{bool} are documented to have either integral or boolean type.  At
2046 some point in the future, the C front end may also make use of this same
2047 intermediate representation, and at this point these nodes will
2048 certainly have integral type.  The previous sentence is not meant to
2049 imply that the C++ front end does not or will not give these nodes
2050 integral type.
2051
2052 Below, we list the various kinds of expression nodes.  Except where
2053 noted otherwise, the operands to an expression are accessed using the
2054 @code{TREE_OPERAND} macro.  For example, to access the first operand to
2055 a binary plus expression @code{expr}, use:
2056
2057 @smallexample
2058 TREE_OPERAND (expr, 0)
2059 @end smallexample
2060 @noindent
2061 As this example indicates, the operands are zero-indexed.
2062
2063 All the expressions starting with @code{OMP_} represent directives and
2064 clauses used by the OpenMP API @w{@uref{http://www.openmp.org/}}.
2065
2066 The table below begins with constants, moves on to unary expressions,
2067 then proceeds to binary expressions, and concludes with various other
2068 kinds of expressions:
2069
2070 @table @code
2071 @item INTEGER_CST
2072 These nodes represent integer constants.  Note that the type of these
2073 constants is obtained with @code{TREE_TYPE}; they are not always of type
2074 @code{int}.  In particular, @code{char} constants are represented with
2075 @code{INTEGER_CST} nodes.  The value of the integer constant @code{e} is
2076 given by
2077 @smallexample
2078 ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT)
2079 + TREE_INST_CST_LOW (e))
2080 @end smallexample
2081 @noindent
2082 HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms.  Both
2083 @code{TREE_INT_CST_HIGH} and @code{TREE_INT_CST_LOW} return a
2084 @code{HOST_WIDE_INT}.  The value of an @code{INTEGER_CST} is interpreted
2085 as a signed or unsigned quantity depending on the type of the constant.
2086 In general, the expression given above will overflow, so it should not
2087 be used to calculate the value of the constant.
2088
2089 The variable @code{integer_zero_node} is an integer constant with value
2090 zero.  Similarly, @code{integer_one_node} is an integer constant with
2091 value one.  The @code{size_zero_node} and @code{size_one_node} variables
2092 are analogous, but have type @code{size_t} rather than @code{int}.
2093
2094 The function @code{tree_int_cst_lt} is a predicate which holds if its
2095 first argument is less than its second.  Both constants are assumed to
2096 have the same signedness (i.e., either both should be signed or both
2097 should be unsigned.)  The full width of the constant is used when doing
2098 the comparison; the usual rules about promotions and conversions are
2099 ignored.  Similarly, @code{tree_int_cst_equal} holds if the two
2100 constants are equal.  The @code{tree_int_cst_sgn} function returns the
2101 sign of a constant.  The value is @code{1}, @code{0}, or @code{-1}
2102 according on whether the constant is greater than, equal to, or less
2103 than zero.  Again, the signedness of the constant's type is taken into
2104 account; an unsigned constant is never less than zero, no matter what
2105 its bit-pattern.
2106
2107 @item REAL_CST
2108
2109 FIXME: Talk about how to obtain representations of this constant, do
2110 comparisons, and so forth.
2111
2112 @item FIXED_CST
2113
2114 These nodes represent fixed-point constants.  The type of these constants
2115 is obtained with @code{TREE_TYPE}.  @code{TREE_FIXED_CST_PTR} points to
2116 to struct fixed_value;  @code{TREE_FIXED_CST} returns the structure itself.
2117 Struct fixed_value contains @code{data} with the size of two
2118 HOST_BITS_PER_WIDE_INT and @code{mode} as the associated fixed-point
2119 machine mode for @code{data}.
2120
2121 @item COMPLEX_CST
2122 These nodes are used to represent complex number constants, that is a
2123 @code{__complex__} whose parts are constant nodes.  The
2124 @code{TREE_REALPART} and @code{TREE_IMAGPART} return the real and the
2125 imaginary parts respectively.
2126
2127 @item VECTOR_CST
2128 These nodes are used to represent vector constants, whose parts are
2129 constant nodes.  Each individual constant node is either an integer or a
2130 double constant node.  The first operand is a @code{TREE_LIST} of the
2131 constant nodes and is accessed through @code{TREE_VECTOR_CST_ELTS}.
2132
2133 @item STRING_CST
2134 These nodes represent string-constants.  The @code{TREE_STRING_LENGTH}
2135 returns the length of the string, as an @code{int}.  The
2136 @code{TREE_STRING_POINTER} is a @code{char*} containing the string
2137 itself.  The string may not be @code{NUL}-terminated, and it may contain
2138 embedded @code{NUL} characters.  Therefore, the
2139 @code{TREE_STRING_LENGTH} includes the trailing @code{NUL} if it is
2140 present.
2141
2142 For wide string constants, the @code{TREE_STRING_LENGTH} is the number
2143 of bytes in the string, and the @code{TREE_STRING_POINTER}
2144 points to an array of the bytes of the string, as represented on the
2145 target system (that is, as integers in the target endianness).  Wide and
2146 non-wide string constants are distinguished only by the @code{TREE_TYPE}
2147 of the @code{STRING_CST}.
2148
2149 FIXME: The formats of string constants are not well-defined when the
2150 target system bytes are not the same width as host system bytes.
2151
2152 @item PTRMEM_CST
2153 These nodes are used to represent pointer-to-member constants.  The
2154 @code{PTRMEM_CST_CLASS} is the class type (either a @code{RECORD_TYPE}
2155 or @code{UNION_TYPE} within which the pointer points), and the
2156 @code{PTRMEM_CST_MEMBER} is the declaration for the pointed to object.
2157 Note that the @code{DECL_CONTEXT} for the @code{PTRMEM_CST_MEMBER} is in
2158 general different from the @code{PTRMEM_CST_CLASS}.  For example,
2159 given:
2160 @smallexample
2161 struct B @{ int i; @};
2162 struct D : public B @{@};
2163 int D::*dp = &D::i;
2164 @end smallexample
2165 @noindent
2166 The @code{PTRMEM_CST_CLASS} for @code{&D::i} is @code{D}, even though
2167 the @code{DECL_CONTEXT} for the @code{PTRMEM_CST_MEMBER} is @code{B},
2168 since @code{B::i} is a member of @code{B}, not @code{D}.
2169
2170 @item VAR_DECL
2171
2172 These nodes represent variables, including static data members.  For
2173 more information, @pxref{Declarations}.
2174
2175 @item NEGATE_EXPR
2176 These nodes represent unary negation of the single operand, for both
2177 integer and floating-point types.  The type of negation can be
2178 determined by looking at the type of the expression.
2179
2180 The behavior of this operation on signed arithmetic overflow is
2181 controlled by the @code{flag_wrapv} and @code{flag_trapv} variables.
2182
2183 @item ABS_EXPR
2184 These nodes represent the absolute value of the single operand, for
2185 both integer and floating-point types.  This is typically used to
2186 implement the @code{abs}, @code{labs} and @code{llabs} builtins for
2187 integer types, and the @code{fabs}, @code{fabsf} and @code{fabsl}
2188 builtins for floating point types.  The type of abs operation can
2189 be determined by looking at the type of the expression.
2190
2191 This node is not used for complex types.  To represent the modulus
2192 or complex abs of a complex value, use the @code{BUILT_IN_CABS},
2193 @code{BUILT_IN_CABSF} or @code{BUILT_IN_CABSL} builtins, as used
2194 to implement the C99 @code{cabs}, @code{cabsf} and @code{cabsl}
2195 built-in functions.
2196
2197 @item BIT_NOT_EXPR
2198 These nodes represent bitwise complement, and will always have integral
2199 type.  The only operand is the value to be complemented.
2200
2201 @item TRUTH_NOT_EXPR
2202 These nodes represent logical negation, and will always have integral
2203 (or boolean) type.  The operand is the value being negated.  The type
2204 of the operand and that of the result are always of @code{BOOLEAN_TYPE}
2205 or @code{INTEGER_TYPE}.
2206
2207 @item PREDECREMENT_EXPR
2208 @itemx PREINCREMENT_EXPR
2209 @itemx POSTDECREMENT_EXPR
2210 @itemx POSTINCREMENT_EXPR
2211 These nodes represent increment and decrement expressions.  The value of
2212 the single operand is computed, and the operand incremented or
2213 decremented.  In the case of @code{PREDECREMENT_EXPR} and
2214 @code{PREINCREMENT_EXPR}, the value of the expression is the value
2215 resulting after the increment or decrement; in the case of
2216 @code{POSTDECREMENT_EXPR} and @code{POSTINCREMENT_EXPR} is the value
2217 before the increment or decrement occurs.  The type of the operand, like
2218 that of the result, will be either integral, boolean, or floating-point.
2219
2220 @item ADDR_EXPR
2221 These nodes are used to represent the address of an object.  (These
2222 expressions will always have pointer or reference type.)  The operand may
2223 be another expression, or it may be a declaration.
2224
2225 As an extension, GCC allows users to take the address of a label.  In
2226 this case, the operand of the @code{ADDR_EXPR} will be a
2227 @code{LABEL_DECL}.  The type of such an expression is @code{void*}.
2228
2229 If the object addressed is not an lvalue, a temporary is created, and
2230 the address of the temporary is used.
2231
2232 @item INDIRECT_REF
2233 These nodes are used to represent the object pointed to by a pointer.
2234 The operand is the pointer being dereferenced; it will always have
2235 pointer or reference type.
2236
2237 @item FIX_TRUNC_EXPR
2238 These nodes represent conversion of a floating-point value to an
2239 integer.  The single operand will have a floating-point type, while
2240 the complete expression will have an integral (or boolean) type.  The
2241 operand is rounded towards zero.
2242
2243 @item FLOAT_EXPR
2244 These nodes represent conversion of an integral (or boolean) value to a
2245 floating-point value.  The single operand will have integral type, while
2246 the complete expression will have a floating-point type.
2247
2248 FIXME: How is the operand supposed to be rounded?  Is this dependent on
2249 @option{-mieee}?
2250
2251 @item COMPLEX_EXPR
2252 These nodes are used to represent complex numbers constructed from two
2253 expressions of the same (integer or real) type.  The first operand is the
2254 real part and the second operand is the imaginary part.
2255
2256 @item CONJ_EXPR
2257 These nodes represent the conjugate of their operand.
2258
2259 @item REALPART_EXPR
2260 @itemx IMAGPART_EXPR
2261 These nodes represent respectively the real and the imaginary parts
2262 of complex numbers (their sole argument).
2263
2264 @item NON_LVALUE_EXPR
2265 These nodes indicate that their one and only operand is not an lvalue.
2266 A back end can treat these identically to the single operand.
2267
2268 @item NOP_EXPR
2269 These nodes are used to represent conversions that do not require any
2270 code-generation.  For example, conversion of a @code{char*} to an
2271 @code{int*} does not require any code be generated; such a conversion is
2272 represented by a @code{NOP_EXPR}.  The single operand is the expression
2273 to be converted.  The conversion from a pointer to a reference is also
2274 represented with a @code{NOP_EXPR}.
2275
2276 @item CONVERT_EXPR
2277 These nodes are similar to @code{NOP_EXPR}s, but are used in those
2278 situations where code may need to be generated.  For example, if an
2279 @code{int*} is converted to an @code{int} code may need to be generated
2280 on some platforms.  These nodes are never used for C++-specific
2281 conversions, like conversions between pointers to different classes in
2282 an inheritance hierarchy.  Any adjustments that need to be made in such
2283 cases are always indicated explicitly.  Similarly, a user-defined
2284 conversion is never represented by a @code{CONVERT_EXPR}; instead, the
2285 function calls are made explicit.
2286
2287 @item FIXED_CONVERT_EXPR
2288 These nodes are used to represent conversions that involve fixed-point
2289 values.  For example, from a fixed-point value to another fixed-point value,
2290 from an integer to a fixed-point value, from a fixed-point value to an
2291 integer, from a floating-point value to a fixed-point value, or from
2292 a fixed-point value to a floating-point value.
2293
2294 @item THROW_EXPR
2295 These nodes represent @code{throw} expressions.  The single operand is
2296 an expression for the code that should be executed to throw the
2297 exception.  However, there is one implicit action not represented in
2298 that expression; namely the call to @code{__throw}.  This function takes
2299 no arguments.  If @code{setjmp}/@code{longjmp} exceptions are used, the
2300 function @code{__sjthrow} is called instead.  The normal GCC back end
2301 uses the function @code{emit_throw} to generate this code; you can
2302 examine this function to see what needs to be done.
2303
2304 @item LSHIFT_EXPR
2305 @itemx RSHIFT_EXPR
2306 These nodes represent left and right shifts, respectively.  The first
2307 operand is the value to shift; it will always be of integral type.  The
2308 second operand is an expression for the number of bits by which to
2309 shift.  Right shift should be treated as arithmetic, i.e., the
2310 high-order bits should be zero-filled when the expression has unsigned
2311 type and filled with the sign bit when the expression has signed type.
2312 Note that the result is undefined if the second operand is larger
2313 than or equal to the first operand's type size.
2314
2315
2316 @item BIT_IOR_EXPR
2317 @itemx BIT_XOR_EXPR
2318 @itemx BIT_AND_EXPR
2319 These nodes represent bitwise inclusive or, bitwise exclusive or, and
2320 bitwise and, respectively.  Both operands will always have integral
2321 type.
2322
2323 @item TRUTH_ANDIF_EXPR
2324 @itemx TRUTH_ORIF_EXPR
2325 These nodes represent logical ``and'' and logical ``or'', respectively.
2326 These operators are not strict; i.e., the second operand is evaluated
2327 only if the value of the expression is not determined by evaluation of
2328 the first operand.  The type of the operands and that of the result are
2329 always of @code{BOOLEAN_TYPE} or @code{INTEGER_TYPE}.
2330
2331 @item TRUTH_AND_EXPR
2332 @itemx TRUTH_OR_EXPR
2333 @itemx TRUTH_XOR_EXPR
2334 These nodes represent logical and, logical or, and logical exclusive or.
2335 They are strict; both arguments are always evaluated.  There are no
2336 corresponding operators in C or C++, but the front end will sometimes
2337 generate these expressions anyhow, if it can tell that strictness does
2338 not matter.  The type of the operands and that of the result are
2339 always of @code{BOOLEAN_TYPE} or @code{INTEGER_TYPE}.
2340
2341 @itemx POINTER_PLUS_EXPR
2342 This node represents pointer arithmetic.  The first operand is always
2343 a pointer/reference type.  The second operand is always an unsigned
2344 integer type compatible with sizetype.  This is the only binary
2345 arithmetic operand that can operate on pointer types.
2346
2347 @itemx PLUS_EXPR
2348 @itemx MINUS_EXPR
2349 @itemx MULT_EXPR
2350 These nodes represent various binary arithmetic operations.
2351 Respectively, these operations are addition, subtraction (of the second
2352 operand from the first) and multiplication.  Their operands may have
2353 either integral or floating type, but there will never be case in which
2354 one operand is of floating type and the other is of integral type.
2355
2356 The behavior of these operations on signed arithmetic overflow is
2357 controlled by the @code{flag_wrapv} and @code{flag_trapv} variables.
2358
2359 @item RDIV_EXPR
2360 This node represents a floating point division operation.
2361
2362 @item TRUNC_DIV_EXPR
2363 @itemx FLOOR_DIV_EXPR
2364 @itemx CEIL_DIV_EXPR
2365 @itemx ROUND_DIV_EXPR
2366 These nodes represent integer division operations that return an integer
2367 result.  @code{TRUNC_DIV_EXPR} rounds towards zero, @code{FLOOR_DIV_EXPR}
2368 rounds towards negative infinity, @code{CEIL_DIV_EXPR} rounds towards
2369 positive infinity and @code{ROUND_DIV_EXPR} rounds to the closest integer.
2370 Integer division in C and C++ is truncating, i.e.@: @code{TRUNC_DIV_EXPR}.
2371
2372 The behavior of these operations on signed arithmetic overflow, when
2373 dividing the minimum signed integer by minus one, is controlled by the
2374 @code{flag_wrapv} and @code{flag_trapv} variables.
2375
2376 @item TRUNC_MOD_EXPR
2377 @itemx FLOOR_MOD_EXPR
2378 @itemx CEIL_MOD_EXPR
2379 @itemx ROUND_MOD_EXPR
2380 These nodes represent the integer remainder or modulus operation.
2381 The integer modulus of two operands @code{a} and @code{b} is
2382 defined as @code{a - (a/b)*b} where the division calculated using
2383 the corresponding division operator.  Hence for @code{TRUNC_MOD_EXPR}
2384 this definition assumes division using truncation towards zero, i.e.@:
2385 @code{TRUNC_DIV_EXPR}.  Integer remainder in C and C++ uses truncating
2386 division, i.e.@: @code{TRUNC_MOD_EXPR}.
2387
2388 @item EXACT_DIV_EXPR
2389 The @code{EXACT_DIV_EXPR} code is used to represent integer divisions where
2390 the numerator is known to be an exact multiple of the denominator.  This
2391 allows the backend to choose between the faster of @code{TRUNC_DIV_EXPR},
2392 @code{CEIL_DIV_EXPR} and @code{FLOOR_DIV_EXPR} for the current target.
2393
2394 @item ARRAY_REF
2395 These nodes represent array accesses.  The first operand is the array;
2396 the second is the index.  To calculate the address of the memory
2397 accessed, you must scale the index by the size of the type of the array
2398 elements.  The type of these expressions must be the type of a component of
2399 the array.  The third and fourth operands are used after gimplification
2400 to represent the lower bound and component size but should not be used
2401 directly; call @code{array_ref_low_bound} and @code{array_ref_element_size}
2402 instead.
2403
2404 @item ARRAY_RANGE_REF
2405 These nodes represent access to a range (or ``slice'') of an array.  The
2406 operands are the same as that for @code{ARRAY_REF} and have the same
2407 meanings.  The type of these expressions must be an array whose component
2408 type is the same as that of the first operand.  The range of that array
2409 type determines the amount of data these expressions access.
2410
2411 @item TARGET_MEM_REF
2412 These nodes represent memory accesses whose address directly map to
2413 an addressing mode of the target architecture.  The first argument
2414 is @code{TMR_SYMBOL} and must be a @code{VAR_DECL} of an object with
2415 a fixed address.  The second argument is @code{TMR_BASE} and the
2416 third one is @code{TMR_INDEX}.  The fourth argument is
2417 @code{TMR_STEP} and must be an @code{INTEGER_CST}.  The fifth
2418 argument is @code{TMR_OFFSET} and must be an @code{INTEGER_CST}.
2419 Any of the arguments may be NULL if the appropriate component
2420 does not appear in the address.  Address of the @code{TARGET_MEM_REF}
2421 is determined in the following way.
2422
2423 @smallexample
2424 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET
2425 @end smallexample
2426
2427 The sixth argument is the reference to the original memory access, which
2428 is preserved for the purposes of the RTL alias analysis.  The seventh
2429 argument is a tag representing the results of tree level alias analysis.
2430
2431 @item LT_EXPR
2432 @itemx LE_EXPR
2433 @itemx GT_EXPR
2434 @itemx GE_EXPR
2435 @itemx EQ_EXPR
2436 @itemx NE_EXPR
2437 These nodes represent the less than, less than or equal to, greater
2438 than, greater than or equal to, equal, and not equal comparison
2439 operators.  The first and second operand with either be both of integral
2440 type or both of floating type.  The result type of these expressions
2441 will always be of integral or boolean type.  These operations return
2442 the result type's zero value for false, and the result type's one value
2443 for true.
2444
2445 For floating point comparisons, if we honor IEEE NaNs and either operand
2446 is NaN, then @code{NE_EXPR} always returns true and the remaining operators
2447 always return false.  On some targets, comparisons against an IEEE NaN,
2448 other than equality and inequality, may generate a floating point exception.
2449
2450 @item ORDERED_EXPR
2451 @itemx UNORDERED_EXPR
2452 These nodes represent non-trapping ordered and unordered comparison
2453 operators.  These operations take two floating point operands and
2454 determine whether they are ordered or unordered relative to each other.
2455 If either operand is an IEEE NaN, their comparison is defined to be
2456 unordered, otherwise the comparison is defined to be ordered.  The
2457 result type of these expressions will always be of integral or boolean
2458 type.  These operations return the result type's zero value for false,
2459 and the result type's one value for true.
2460
2461 @item UNLT_EXPR
2462 @itemx UNLE_EXPR
2463 @itemx UNGT_EXPR
2464 @itemx UNGE_EXPR
2465 @itemx UNEQ_EXPR
2466 @itemx LTGT_EXPR
2467 These nodes represent the unordered comparison operators.
2468 These operations take two floating point operands and determine whether
2469 the operands are unordered or are less than, less than or equal to,
2470 greater than, greater than or equal to, or equal respectively.  For
2471 example, @code{UNLT_EXPR} returns true if either operand is an IEEE
2472 NaN or the first operand is less than the second.  With the possible
2473 exception of @code{LTGT_EXPR}, all of these operations are guaranteed
2474 not to generate a floating point exception.  The result
2475 type of these expressions will always be of integral or boolean type.
2476 These operations return the result type's zero value for false,
2477 and the result type's one value for true.
2478
2479 @item MODIFY_EXPR
2480 These nodes represent assignment.  The left-hand side is the first
2481 operand; the right-hand side is the second operand.  The left-hand side
2482 will be a @code{VAR_DECL}, @code{INDIRECT_REF}, @code{COMPONENT_REF}, or
2483 other lvalue.
2484
2485 These nodes are used to represent not only assignment with @samp{=} but
2486 also compound assignments (like @samp{+=}), by reduction to @samp{=}
2487 assignment.  In other words, the representation for @samp{i += 3} looks
2488 just like that for @samp{i = i + 3}.
2489
2490 @item INIT_EXPR
2491 These nodes are just like @code{MODIFY_EXPR}, but are used only when a
2492 variable is initialized, rather than assigned to subsequently.  This
2493 means that we can assume that the target of the initialization is not
2494 used in computing its own value; any reference to the lhs in computing
2495 the rhs is undefined.
2496
2497 @item COMPONENT_REF
2498 These nodes represent non-static data member accesses.  The first
2499 operand is the object (rather than a pointer to it); the second operand
2500 is the @code{FIELD_DECL} for the data member.  The third operand represents
2501 the byte offset of the field, but should not be used directly; call
2502 @code{component_ref_field_offset} instead.
2503
2504 @item COMPOUND_EXPR
2505 These nodes represent comma-expressions.  The first operand is an
2506 expression whose value is computed and thrown away prior to the
2507 evaluation of the second operand.  The value of the entire expression is
2508 the value of the second operand.
2509
2510 @item COND_EXPR
2511 These nodes represent @code{?:} expressions.  The first operand
2512 is of boolean or integral type.  If it evaluates to a nonzero value,
2513 the second operand should be evaluated, and returned as the value of the
2514 expression.  Otherwise, the third operand is evaluated, and returned as
2515 the value of the expression.
2516
2517 The second operand must have the same type as the entire expression,
2518 unless it unconditionally throws an exception or calls a noreturn
2519 function, in which case it should have void type.  The same constraints
2520 apply to the third operand.  This allows array bounds checks to be
2521 represented conveniently as @code{(i >= 0 && i < 10) ? i : abort()}.
2522
2523 As a GNU extension, the C language front-ends allow the second
2524 operand of the @code{?:} operator may be omitted in the source.
2525 For example, @code{x ? : 3} is equivalent to @code{x ? x : 3},
2526 assuming that @code{x} is an expression without side-effects.
2527 In the tree representation, however, the second operand is always
2528 present, possibly protected by @code{SAVE_EXPR} if the first
2529 argument does cause side-effects.
2530
2531 @item CALL_EXPR
2532 These nodes are used to represent calls to functions, including
2533 non-static member functions.  @code{CALL_EXPR}s are implemented as
2534 expression nodes with a variable number of operands.  Rather than using
2535 @code{TREE_OPERAND} to extract them, it is preferable to use the
2536 specialized accessor macros and functions that operate specifically on
2537 @code{CALL_EXPR} nodes.
2538
2539 @code{CALL_EXPR_FN} returns a pointer to the
2540 function to call; it is always an expression whose type is a
2541 @code{POINTER_TYPE}.
2542
2543 The number of arguments to the call is returned by @code{call_expr_nargs},
2544 while the arguments themselves can be accessed with the @code{CALL_EXPR_ARG} 
2545 macro.  The arguments are zero-indexed and numbered left-to-right.  
2546 You can iterate over the arguments using @code{FOR_EACH_CALL_EXPR_ARG}, as in:
2547
2548 @smallexample
2549 tree call, arg;
2550 call_expr_arg_iterator iter;
2551 FOR_EACH_CALL_EXPR_ARG (arg, iter, call)
2552   /* arg is bound to successive arguments of call.  */
2553   @dots{};
2554 @end smallexample
2555
2556 For non-static
2557 member functions, there will be an operand corresponding to the
2558 @code{this} pointer.  There will always be expressions corresponding to
2559 all of the arguments, even if the function is declared with default
2560 arguments and some arguments are not explicitly provided at the call
2561 sites.
2562
2563 @code{CALL_EXPR}s also have a @code{CALL_EXPR_STATIC_CHAIN} operand that
2564 is used to implement nested functions.  This operand is otherwise null.
2565
2566 @item STMT_EXPR
2567 These nodes are used to represent GCC's statement-expression extension.
2568 The statement-expression extension allows code like this:
2569 @smallexample
2570 int f() @{ return (@{ int j; j = 3; j + 7; @}); @}
2571 @end smallexample
2572 In other words, an sequence of statements may occur where a single
2573 expression would normally appear.  The @code{STMT_EXPR} node represents
2574 such an expression.  The @code{STMT_EXPR_STMT} gives the statement
2575 contained in the expression.  The value of the expression is the value
2576 of the last sub-statement in the body.  More precisely, the value is the
2577 value computed by the last statement nested inside @code{BIND_EXPR},
2578 @code{TRY_FINALLY_EXPR}, or @code{TRY_CATCH_EXPR}.  For example, in:
2579 @smallexample
2580 (@{ 3; @})
2581 @end smallexample
2582 the value is @code{3} while in:
2583 @smallexample
2584 (@{ if (x) @{ 3; @} @})
2585 @end smallexample
2586 there is no value.  If the @code{STMT_EXPR} does not yield a value,
2587 it's type will be @code{void}.
2588
2589 @item BIND_EXPR
2590 These nodes represent local blocks.  The first operand is a list of
2591 variables, connected via their @code{TREE_CHAIN} field.  These will
2592 never require cleanups.  The scope of these variables is just the body
2593 of the @code{BIND_EXPR}.  The body of the @code{BIND_EXPR} is the
2594 second operand.
2595
2596 @item LOOP_EXPR
2597 These nodes represent ``infinite'' loops.  The @code{LOOP_EXPR_BODY}
2598 represents the body of the loop.  It should be executed forever, unless
2599 an @code{EXIT_EXPR} is encountered.
2600
2601 @item EXIT_EXPR
2602 These nodes represent conditional exits from the nearest enclosing
2603 @code{LOOP_EXPR}.  The single operand is the condition; if it is
2604 nonzero, then the loop should be exited.  An @code{EXIT_EXPR} will only
2605 appear within a @code{LOOP_EXPR}.
2606
2607 @item CLEANUP_POINT_EXPR
2608 These nodes represent full-expressions.  The single operand is an
2609 expression to evaluate.  Any destructor calls engendered by the creation
2610 of temporaries during the evaluation of that expression should be
2611 performed immediately after the expression is evaluated.
2612
2613 @item CONSTRUCTOR
2614 These nodes represent the brace-enclosed initializers for a structure or
2615 array.  The first operand is reserved for use by the back end.  The
2616 second operand is a @code{TREE_LIST}.  If the @code{TREE_TYPE} of the
2617 @code{CONSTRUCTOR} is a @code{RECORD_TYPE} or @code{UNION_TYPE}, then
2618 the @code{TREE_PURPOSE} of each node in the @code{TREE_LIST} will be a
2619 @code{FIELD_DECL} and the @code{TREE_VALUE} of each node will be the
2620 expression used to initialize that field.
2621
2622 If the @code{TREE_TYPE} of the @code{CONSTRUCTOR} is an
2623 @code{ARRAY_TYPE}, then the @code{TREE_PURPOSE} of each element in the
2624 @code{TREE_LIST} will be an @code{INTEGER_CST} or a @code{RANGE_EXPR} of
2625 two @code{INTEGER_CST}s.  A single @code{INTEGER_CST} indicates which
2626 element of the array (indexed from zero) is being assigned to.  A
2627 @code{RANGE_EXPR} indicates an inclusive range of elements to
2628 initialize.  In both cases the @code{TREE_VALUE} is the corresponding
2629 initializer.  It is re-evaluated for each element of a
2630 @code{RANGE_EXPR}.  If the @code{TREE_PURPOSE} is @code{NULL_TREE}, then
2631 the initializer is for the next available array element.
2632
2633 In the front end, you should not depend on the fields appearing in any
2634 particular order.  However, in the middle end, fields must appear in
2635 declaration order.  You should not assume that all fields will be
2636 represented.  Unrepresented fields will be set to zero.
2637
2638 @item COMPOUND_LITERAL_EXPR
2639 @findex COMPOUND_LITERAL_EXPR_DECL_STMT
2640 @findex COMPOUND_LITERAL_EXPR_DECL
2641 These nodes represent ISO C99 compound literals.  The
2642 @code{COMPOUND_LITERAL_EXPR_DECL_STMT} is a @code{DECL_STMT}
2643 containing an anonymous @code{VAR_DECL} for
2644 the unnamed object represented by the compound literal; the
2645 @code{DECL_INITIAL} of that @code{VAR_DECL} is a @code{CONSTRUCTOR}
2646 representing the brace-enclosed list of initializers in the compound
2647 literal.  That anonymous @code{VAR_DECL} can also be accessed directly
2648 by the @code{COMPOUND_LITERAL_EXPR_DECL} macro.
2649
2650 @item SAVE_EXPR
2651
2652 A @code{SAVE_EXPR} represents an expression (possibly involving
2653 side-effects) that is used more than once.  The side-effects should
2654 occur only the first time the expression is evaluated.  Subsequent uses
2655 should just reuse the computed value.  The first operand to the
2656 @code{SAVE_EXPR} is the expression to evaluate.  The side-effects should
2657 be executed where the @code{SAVE_EXPR} is first encountered in a
2658 depth-first preorder traversal of the expression tree.
2659
2660 @item TARGET_EXPR
2661 A @code{TARGET_EXPR} represents a temporary object.  The first operand
2662 is a @code{VAR_DECL} for the temporary variable.  The second operand is
2663 the initializer for the temporary.  The initializer is evaluated and,
2664 if non-void, copied (bitwise) into the temporary.  If the initializer
2665 is void, that means that it will perform the initialization itself.
2666
2667 Often, a @code{TARGET_EXPR} occurs on the right-hand side of an
2668 assignment, or as the second operand to a comma-expression which is
2669 itself the right-hand side of an assignment, etc.  In this case, we say
2670 that the @code{TARGET_EXPR} is ``normal''; otherwise, we say it is
2671 ``orphaned''.  For a normal @code{TARGET_EXPR} the temporary variable
2672 should be treated as an alias for the left-hand side of the assignment,
2673 rather than as a new temporary variable.
2674
2675 The third operand to the @code{TARGET_EXPR}, if present, is a
2676 cleanup-expression (i.e., destructor call) for the temporary.  If this
2677 expression is orphaned, then this expression must be executed when the
2678 statement containing this expression is complete.  These cleanups must
2679 always be executed in the order opposite to that in which they were
2680 encountered.  Note that if a temporary is created on one branch of a
2681 conditional operator (i.e., in the second or third operand to a
2682 @code{COND_EXPR}), the cleanup must be run only if that branch is
2683 actually executed.
2684
2685 See @code{STMT_IS_FULL_EXPR_P} for more information about running these
2686 cleanups.
2687
2688 @item AGGR_INIT_EXPR
2689 An @code{AGGR_INIT_EXPR} represents the initialization as the return
2690 value of a function call, or as the result of a constructor.  An
2691 @code{AGGR_INIT_EXPR} will only appear as a full-expression, or as the
2692 second operand of a @code{TARGET_EXPR}.  @code{AGGR_INIT_EXPR}s have
2693 a representation similar to that of @code{CALL_EXPR}s.  You can use
2694 the @code{AGGR_INIT_EXPR_FN} and @code{AGGR_INIT_EXPR_ARG} macros to access
2695 the function to call and the arguments to pass.
2696
2697 If @code{AGGR_INIT_VIA_CTOR_P} holds of the @code{AGGR_INIT_EXPR}, then
2698 the initialization is via a constructor call.  The address of the
2699 @code{AGGR_INIT_EXPR_SLOT} operand, which is always a @code{VAR_DECL},
2700 is taken, and this value replaces the first argument in the argument
2701 list.
2702
2703 In either case, the expression is void.
2704
2705 @item VA_ARG_EXPR
2706 This node is used to implement support for the C/C++ variable argument-list
2707 mechanism.  It represents expressions like @code{va_arg (ap, type)}.
2708 Its @code{TREE_TYPE} yields the tree representation for @code{type} and
2709 its sole argument yields the representation for @code{ap}.
2710
2711 @item CHANGE_DYNAMIC_TYPE_EXPR
2712 Indicates the special aliasing required by C++ placement new.  It has
2713 two operands: a type and a location.  It means that the dynamic type
2714 of the location is changing to be the specified type.  The alias
2715 analysis code takes this into account when doing type based alias
2716 analysis.
2717
2718 @item OMP_PARALLEL
2719
2720 Represents @code{#pragma omp parallel [clause1 @dots{} clauseN]}. It
2721 has four operands:
2722
2723 Operand @code{OMP_PARALLEL_BODY} is valid while in GENERIC and
2724 High GIMPLE forms.  It contains the body of code to be executed
2725 by all the threads.  During GIMPLE lowering, this operand becomes
2726 @code{NULL} and the body is emitted linearly after
2727 @code{OMP_PARALLEL}.
2728
2729 Operand @code{OMP_PARALLEL_CLAUSES} is the list of clauses
2730 associated with the directive.
2731
2732 Operand @code{OMP_PARALLEL_FN} is created by
2733 @code{pass_lower_omp}, it contains the @code{FUNCTION_DECL}
2734 for the function that will contain the body of the parallel
2735 region.
2736
2737 Operand @code{OMP_PARALLEL_DATA_ARG} is also created by
2738 @code{pass_lower_omp}. If there are shared variables to be
2739 communicated to the children threads, this operand will contain
2740 the @code{VAR_DECL} that contains all the shared values and
2741 variables.
2742
2743 @item OMP_FOR
2744
2745 Represents @code{#pragma omp for [clause1 @dots{} clauseN]}.  It
2746 has 5 operands:
2747
2748 Operand @code{OMP_FOR_BODY} contains the loop body.
2749
2750 Operand @code{OMP_FOR_CLAUSES} is the list of clauses
2751 associated with the directive.
2752
2753 Operand @code{OMP_FOR_INIT} is the loop initialization code of
2754 the form @code{VAR = N1}.
2755
2756 Operand @code{OMP_FOR_COND} is the loop conditional expression
2757 of the form @code{VAR @{<,>,<=,>=@} N2}.
2758
2759 Operand @code{OMP_FOR_INCR} is the loop index increment of the
2760 form @code{VAR @{+=,-=@} INCR}.
2761
2762 Operand @code{OMP_FOR_PRE_BODY} contains side-effect code from
2763 operands @code{OMP_FOR_INIT}, @code{OMP_FOR_COND} and
2764 @code{OMP_FOR_INC}.  These side-effects are part of the
2765 @code{OMP_FOR} block but must be evaluated before the start of
2766 loop body.
2767
2768 The loop index variable @code{VAR} must be a signed integer variable,
2769 which is implicitly private to each thread.  Bounds
2770 @code{N1} and @code{N2} and the increment expression
2771 @code{INCR} are required to be loop invariant integer
2772 expressions that are evaluated without any synchronization. The
2773 evaluation order, frequency of evaluation and side-effects are
2774 unspecified by the standard.
2775
2776 @item OMP_SECTIONS
2777
2778 Represents @code{#pragma omp sections [clause1 @dots{} clauseN]}.
2779
2780 Operand @code{OMP_SECTIONS_BODY} contains the sections body,
2781 which in turn contains a set of @code{OMP_SECTION} nodes for
2782 each of the concurrent sections delimited by @code{#pragma omp
2783 section}.
2784
2785 Operand @code{OMP_SECTIONS_CLAUSES} is the list of clauses
2786 associated with the directive.
2787
2788 @item OMP_SECTION
2789
2790 Section delimiter for @code{OMP_SECTIONS}.
2791
2792 @item OMP_SINGLE
2793
2794 Represents @code{#pragma omp single}.
2795
2796 Operand @code{OMP_SINGLE_BODY} contains the body of code to be
2797 executed by a single thread.
2798
2799 Operand @code{OMP_SINGLE_CLAUSES} is the list of clauses
2800 associated with the directive.
2801
2802 @item OMP_MASTER
2803
2804 Represents @code{#pragma omp master}.
2805
2806 Operand @code{OMP_MASTER_BODY} contains the body of code to be
2807 executed by the master thread.
2808
2809 @item OMP_ORDERED
2810
2811 Represents @code{#pragma omp ordered}.
2812
2813 Operand @code{OMP_ORDERED_BODY} contains the body of code to be
2814 executed in the sequential order dictated by the loop index
2815 variable.
2816
2817 @item OMP_CRITICAL
2818
2819 Represents @code{#pragma omp critical [name]}.
2820
2821 Operand @code{OMP_CRITICAL_BODY} is the critical section.
2822
2823 Operand @code{OMP_CRITICAL_NAME} is an optional identifier to
2824 label the critical section.
2825
2826 @item OMP_RETURN
2827
2828 This does not represent any OpenMP directive, it is an artificial
2829 marker to indicate the end of the body of an OpenMP@. It is used
2830 by the flow graph (@code{tree-cfg.c}) and OpenMP region
2831 building code (@code{omp-low.c}).
2832
2833 @item OMP_CONTINUE
2834
2835 Similarly, this instruction does not represent an OpenMP
2836 directive, it is used by @code{OMP_FOR} and
2837 @code{OMP_SECTIONS} to mark the place where the code needs to
2838 loop to the next iteration (in the case of @code{OMP_FOR}) or
2839 the next section (in the case of @code{OMP_SECTIONS}).
2840
2841 In some cases, @code{OMP_CONTINUE} is placed right before
2842 @code{OMP_RETURN}.  But if there are cleanups that need to
2843 occur right after the looping body, it will be emitted between
2844 @code{OMP_CONTINUE} and @code{OMP_RETURN}.
2845
2846 @item OMP_ATOMIC
2847
2848 Represents @code{#pragma omp atomic}.
2849
2850 Operand 0 is the address at which the atomic operation is to be
2851 performed.
2852
2853 Operand 1 is the expression to evaluate.  The gimplifier tries
2854 three alternative code generation strategies.  Whenever possible,
2855 an atomic update built-in is used.  If that fails, a
2856 compare-and-swap loop is attempted.  If that also fails, a
2857 regular critical section around the expression is used.
2858
2859 @item OMP_CLAUSE
2860
2861 Represents clauses associated with one of the @code{OMP_} directives.
2862 Clauses are represented by separate sub-codes defined in
2863 @file{tree.h}.  Clauses codes can be one of:
2864 @code{OMP_CLAUSE_PRIVATE}, @code{OMP_CLAUSE_SHARED},
2865 @code{OMP_CLAUSE_FIRSTPRIVATE},
2866 @code{OMP_CLAUSE_LASTPRIVATE}, @code{OMP_CLAUSE_COPYIN},
2867 @code{OMP_CLAUSE_COPYPRIVATE}, @code{OMP_CLAUSE_IF},
2868 @code{OMP_CLAUSE_NUM_THREADS}, @code{OMP_CLAUSE_SCHEDULE},
2869 @code{OMP_CLAUSE_NOWAIT}, @code{OMP_CLAUSE_ORDERED},
2870 @code{OMP_CLAUSE_DEFAULT}, and @code{OMP_CLAUSE_REDUCTION}.  Each code
2871 represents the corresponding OpenMP clause.
2872
2873 Clauses associated with the same directive are chained together
2874 via @code{OMP_CLAUSE_CHAIN}. Those clauses that accept a list
2875 of variables are restricted to exactly one, accessed with
2876 @code{OMP_CLAUSE_VAR}.  Therefore, multiple variables under the
2877 same clause @code{C} need to be represented as multiple @code{C} clauses
2878 chained together.  This facilitates adding new clauses during
2879 compilation.
2880
2881 @item VEC_LSHIFT_EXPR
2882 @item VEC_RSHIFT_EXPR
2883 These nodes represent whole vector left and right shifts, respectively.  
2884 The first operand is the vector to shift; it will always be of vector type.  
2885 The second operand is an expression for the number of bits by which to
2886 shift.  Note that the result is undefined if the second operand is larger
2887 than or equal to the first operand's type size.
2888
2889 @item VEC_WIDEN_MULT_HI_EXPR
2890 @item VEC_WIDEN_MULT_LO_EXPR
2891 These nodes represent widening vector multiplication of the high and low
2892 parts of the two input vectors, respectively.  Their operands are vectors 
2893 that contain the same number of elements (@code{N}) of the same integral type.  
2894 The result is a vector that contains half as many elements, of an integral type 
2895 whose size is twice as wide.  In the case of @code{VEC_WIDEN_MULT_HI_EXPR} the
2896 high @code{N/2} elements of the two vector are multiplied to produce the
2897 vector of @code{N/2} products. In the case of @code{VEC_WIDEN_MULT_LO_EXPR} the
2898 low @code{N/2} elements of the two vector are multiplied to produce the
2899 vector of @code{N/2} products.
2900
2901 @item VEC_UNPACK_HI_EXPR
2902 @item VEC_UNPACK_LO_EXPR
2903 These nodes represent unpacking of the high and low parts of the input vector,
2904 respectively.  The single operand is a vector that contains @code{N} elements 
2905 of the same integral or floating point type.  The result is a vector
2906 that contains half as many elements, of an integral or floating point type
2907 whose size is twice as wide.  In the case of @code{VEC_UNPACK_HI_EXPR} the
2908 high @code{N/2} elements of the vector are extracted and widened (promoted).
2909 In the case of @code{VEC_UNPACK_LO_EXPR} the low @code{N/2} elements of the
2910 vector are extracted and widened (promoted).
2911
2912 @item VEC_UNPACK_FLOAT_HI_EXPR
2913 @item VEC_UNPACK_FLOAT_LO_EXPR
2914 These nodes represent unpacking of the high and low parts of the input vector,
2915 where the values are converted from fixed point to floating point.  The
2916 single operand is a vector that contains @code{N} elements of the same
2917 integral type.  The result is a vector that contains half as many elements
2918 of a floating point type whose size is twice as wide.  In the case of
2919 @code{VEC_UNPACK_HI_EXPR} the high @code{N/2} elements of the vector are
2920 extracted, converted and widened.  In the case of @code{VEC_UNPACK_LO_EXPR}
2921 the low @code{N/2} elements of the vector are extracted, converted and widened.
2922
2923 @item VEC_PACK_TRUNC_EXPR
2924 This node represents packing of truncated elements of the two input vectors
2925 into the output vector.  Input operands are vectors that contain the same
2926 number of elements of the same integral or floating point type.  The result
2927 is a vector that contains twice as many elements of an integral or floating
2928 point type whose size is half as wide. The elements of the two vectors are
2929 demoted and merged (concatenated) to form the output vector.
2930
2931 @item VEC_PACK_SAT_EXPR
2932 This node represents packing of elements of the two input vectors into the
2933 output vector using saturation.  Input operands are vectors that contain
2934 the same number of elements of the same integral type.  The result is a
2935 vector that contains twice as many elements of an integral type whose size
2936 is half as wide.  The elements of the two vectors are demoted and merged
2937 (concatenated) to form the output vector.
2938
2939 @item VEC_PACK_FIX_TRUNC_EXPR
2940 This node represents packing of elements of the two input vectors into the
2941 output vector, where the values are converted from floating point
2942 to fixed point.  Input operands are vectors that contain the same number
2943 of elements of a floating point type.  The result is a vector that contains
2944 twice as many elements of an integral type whose size is half as wide.  The
2945 elements of the two vectors are merged (concatenated) to form the output
2946 vector.
2947
2948 @item VEC_EXTRACT_EVEN_EXPR
2949 @item VEC_EXTRACT_ODD_EXPR
2950 These nodes represent extracting of the even/odd elements of the two input 
2951 vectors, respectively. Their operands and result are vectors that contain the 
2952 same number of elements of the same type.
2953
2954 @item VEC_INTERLEAVE_HIGH_EXPR
2955 @item VEC_INTERLEAVE_LOW_EXPR
2956 These nodes represent merging and interleaving of the high/low elements of the
2957 two input vectors, respectively. The operands and the result are vectors that 
2958 contain the same number of elements (@code{N}) of the same type.
2959 In the case of @code{VEC_INTERLEAVE_HIGH_EXPR}, the high @code{N/2} elements of 
2960 the first input vector are interleaved with the high @code{N/2} elements of the
2961 second input vector. In the case of @code{VEC_INTERLEAVE_LOW_EXPR}, the low
2962 @code{N/2} elements of the first input vector are interleaved with the low 
2963 @code{N/2} elements of the second input vector.
2964
2965 @end table