Daily bump.
[official-gcc.git] / gcc / doc / c-tree.texi
blobb8a4faf0548f901f9559333cd51aaaad108b8adb
1 @c Copyright (c) 1999, 2000, 2001, 2002, 2003, 2004, 2005
2 @c Free Software Foundation, Inc.
3 @c This is part of the GCC manual.
4 @c For copying conditions, see the file gcc.texi.
6 @c ---------------------------------------------------------------------
7 @c Trees
8 @c ---------------------------------------------------------------------
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
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.
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@.
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@.
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
60 @c ---------------------------------------------------------------------
61 @c Deficiencies
62 @c ---------------------------------------------------------------------
64 @node Deficiencies
65 @section Deficiencies
67 There are many places in which this document is incomplet and incorrekt.
68 It is, as of yet, only @emph{preliminary} documentation.
70 @c ---------------------------------------------------------------------
71 @c Overview
72 @c ---------------------------------------------------------------------
74 @node Tree overview
75 @section Overview
76 @cindex tree
77 @findex TREE_CODE
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}.
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.
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.
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
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.
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.
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.
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}.
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.
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.
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
167 @c ---------------------------------------------------------------------
168 @c Trees
169 @c ---------------------------------------------------------------------
171 @node Macros and Functions
172 @subsection Trees
173 @cindex tree
175 This section is not here yet.
177 @c ---------------------------------------------------------------------
178 @c Identifiers
179 @c ---------------------------------------------------------------------
181 @node Identifiers
182 @subsection Identifiers
183 @cindex identifier
184 @cindex name
185 @tindex IDENTIFIER_NODE
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.
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}.
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.
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))}.
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}.
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.
221 @end ftable
223 @c ---------------------------------------------------------------------
224 @c Containers
225 @c ---------------------------------------------------------------------
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
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.
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.
258 @c ---------------------------------------------------------------------
259 @c Types
260 @c ---------------------------------------------------------------------
262 @node Types
263 @section Types
264 @cindex type
265 @cindex pointer
266 @cindex reference
267 @cindex fundamental type
268 @cindex array
269 @tindex VOID_TYPE
270 @tindex INTEGER_TYPE
271 @tindex TYPE_MIN_VALUE
272 @tindex TYPE_MAX_VALUE
273 @tindex REAL_TYPE
274 @tindex COMPLEX_TYPE
275 @tindex ENUMERAL_TYPE
276 @tindex BOOLEAN_TYPE
277 @tindex POINTER_TYPE
278 @tindex REFERENCE_TYPE
279 @tindex FUNCTION_TYPE
280 @tindex METHOD_TYPE
281 @tindex ARRAY_TYPE
282 @tindex RECORD_TYPE
283 @tindex UNION_TYPE
284 @tindex UNKNOWN_TYPE
285 @tindex OFFSET_TYPE
286 @tindex TYPENAME_TYPE
287 @tindex TYPEOF_TYPE
288 @findex CP_TYPE_QUALS
289 @findex TYPE_UNQUALIFIED
290 @findex TYPE_QUAL_CONST
291 @findex TYPE_QUAL_VOLATILE
292 @findex TYPE_QUAL_RESTRICT
293 @findex TYPE_MAIN_VARIANT
294 @cindex qualified type
295 @findex TYPE_SIZE
296 @findex TYPE_ALIGN
297 @findex TYPE_PRECISION
298 @findex TYPE_ARG_TYPES
299 @findex TYPE_METHOD_BASETYPE
300 @findex TYPE_PTRMEM_P
301 @findex TYPE_OFFSET_BASETYPE
302 @findex TREE_TYPE
303 @findex TYPE_CONTEXT
304 @findex TYPE_NAME
305 @findex TYPENAME_TYPE_FULLNAME
306 @findex TYPE_FIELDS
307 @findex TYPE_PTROBV_P
309 All types have corresponding tree nodes.  However, you should not assume
310 that there is exactly one tree node corresponding to each type.  There
311 are often several nodes each of which correspond to the same type.
313 For the most part, different kinds of types have different tree codes.
314 (For example, pointer types use a @code{POINTER_TYPE} code while arrays
315 use an @code{ARRAY_TYPE} code.)  However, pointers to member functions
316 use the @code{RECORD_TYPE} code.  Therefore, when writing a
317 @code{switch} statement that depends on the code associated with a
318 particular type, you should take care to handle pointers to member
319 functions under the @code{RECORD_TYPE} case label.
321 In C++, an array type is not qualified; rather the type of the array
322 elements is qualified.  This situation is reflected in the intermediate
323 representation.  The macros described here will always examine the
324 qualification of the underlying element type when applied to an array
325 type.  (If the element type is itself an array, then the recursion
326 continues until a non-array type is found, and the qualification of this
327 type is examined.)  So, for example, @code{CP_TYPE_CONST_P} will hold of
328 the type @code{const int ()[7]}, denoting an array of seven @code{int}s.
330 The following functions and macros deal with cv-qualification of types:
331 @ftable @code
332 @item CP_TYPE_QUALS
333 This macro returns the set of type qualifiers applied to this type.
334 This value is @code{TYPE_UNQUALIFIED} if no qualifiers have been
335 applied.  The @code{TYPE_QUAL_CONST} bit is set if the type is
336 @code{const}-qualified.  The @code{TYPE_QUAL_VOLATILE} bit is set if the
337 type is @code{volatile}-qualified.  The @code{TYPE_QUAL_RESTRICT} bit is
338 set if the type is @code{restrict}-qualified.
340 @item CP_TYPE_CONST_P
341 This macro holds if the type is @code{const}-qualified.
343 @item CP_TYPE_VOLATILE_P
344 This macro holds if the type is @code{volatile}-qualified.
346 @item CP_TYPE_RESTRICT_P
347 This macro holds if the type is @code{restrict}-qualified.
349 @item CP_TYPE_CONST_NON_VOLATILE_P
350 This predicate holds for a type that is @code{const}-qualified, but
351 @emph{not} @code{volatile}-qualified; other cv-qualifiers are ignored as
352 well: only the @code{const}-ness is tested.
354 @item TYPE_MAIN_VARIANT
355 This macro returns the unqualified version of a type.  It may be applied
356 to an unqualified type, but it is not always the identity function in
357 that case.
358 @end ftable
360 A few other macros and functions are usable with all types:
361 @ftable @code
362 @item TYPE_SIZE
363 The number of bits required to represent the type, represented as an
364 @code{INTEGER_CST}.  For an incomplete type, @code{TYPE_SIZE} will be
365 @code{NULL_TREE}.
367 @item TYPE_ALIGN
368 The alignment of the type, in bits, represented as an @code{int}.
370 @item TYPE_NAME
371 This macro returns a declaration (in the form of a @code{TYPE_DECL}) for
372 the type.  (Note this macro does @emph{not} return a
373 @code{IDENTIFIER_NODE}, as you might expect, given its name!)  You can
374 look at the @code{DECL_NAME} of the @code{TYPE_DECL} to obtain the
375 actual name of the type.  The @code{TYPE_NAME} will be @code{NULL_TREE}
376 for a type that is not a built-in type, the result of a typedef, or a
377 named class type.
379 @item CP_INTEGRAL_TYPE
380 This predicate holds if the type is an integral type.  Notice that in
381 C++, enumerations are @emph{not} integral types.
383 @item ARITHMETIC_TYPE_P
384 This predicate holds if the type is an integral type (in the C++ sense)
385 or a floating point type.
387 @item CLASS_TYPE_P
388 This predicate holds for a class-type.
390 @item TYPE_BUILT_IN
391 This predicate holds for a built-in type.
393 @item TYPE_PTRMEM_P
394 This predicate holds if the type is a pointer to data member.
396 @item TYPE_PTR_P
397 This predicate holds if the type is a pointer type, and the pointee is
398 not a data member.
400 @item TYPE_PTRFN_P
401 This predicate holds for a pointer to function type.
403 @item TYPE_PTROB_P
404 This predicate holds for a pointer to object type.  Note however that it
405 does not hold for the generic pointer to object type @code{void *}.  You
406 may use @code{TYPE_PTROBV_P} to test for a pointer to object type as
407 well as @code{void *}.
409 @item same_type_p
410 This predicate takes two types as input, and holds if they are the same
411 type.  For example, if one type is a @code{typedef} for the other, or
412 both are @code{typedef}s for the same type.  This predicate also holds if
413 the two trees given as input are simply copies of one another; i.e.,
414 there is no difference between them at the source level, but, for
415 whatever reason, a duplicate has been made in the representation.  You
416 should never use @code{==} (pointer equality) to compare types; always
417 use @code{same_type_p} instead.
418 @end ftable
420 Detailed below are the various kinds of types, and the macros that can
421 be used to access them.  Although other kinds of types are used
422 elsewhere in G++, the types described here are the only ones that you
423 will encounter while examining the intermediate representation.
425 @table @code
426 @item VOID_TYPE
427 Used to represent the @code{void} type.
429 @item INTEGER_TYPE
430 Used to represent the various integral types, including @code{char},
431 @code{short}, @code{int}, @code{long}, and @code{long long}.  This code
432 is not used for enumeration types, nor for the @code{bool} type.
433 The @code{TYPE_PRECISION} is the number of bits used in
434 the representation, represented as an @code{unsigned int}.  (Note that
435 in the general case this is not the same value as @code{TYPE_SIZE};
436 suppose that there were a 24-bit integer type, but that alignment
437 requirements for the ABI required 32-bit alignment.  Then,
438 @code{TYPE_SIZE} would be an @code{INTEGER_CST} for 32, while
439 @code{TYPE_PRECISION} would be 24.)  The integer type is unsigned if
440 @code{TYPE_UNSIGNED} holds; otherwise, it is signed.
442 The @code{TYPE_MIN_VALUE} is an @code{INTEGER_CST} for the smallest
443 integer that may be represented by this type.  Similarly, the
444 @code{TYPE_MAX_VALUE} is an @code{INTEGER_CST} for the largest integer
445 that may be represented by this type.
447 @item REAL_TYPE
448 Used to represent the @code{float}, @code{double}, and @code{long
449 double} types.  The number of bits in the floating-point representation
450 is given by @code{TYPE_PRECISION}, as in the @code{INTEGER_TYPE} case.
452 @item COMPLEX_TYPE
453 Used to represent GCC built-in @code{__complex__} data types.  The
454 @code{TREE_TYPE} is the type of the real and imaginary parts.
456 @item ENUMERAL_TYPE
457 Used to represent an enumeration type.  The @code{TYPE_PRECISION} gives
458 (as an @code{int}), the number of bits used to represent the type.  If
459 there are no negative enumeration constants, @code{TYPE_UNSIGNED} will
460 hold.  The minimum and maximum enumeration constants may be obtained
461 with @code{TYPE_MIN_VALUE} and @code{TYPE_MAX_VALUE}, respectively; each
462 of these macros returns an @code{INTEGER_CST}.
464 The actual enumeration constants themselves may be obtained by looking
465 at the @code{TYPE_VALUES}.  This macro will return a @code{TREE_LIST},
466 containing the constants.  The @code{TREE_PURPOSE} of each node will be
467 an @code{IDENTIFIER_NODE} giving the name of the constant; the
468 @code{TREE_VALUE} will be an @code{INTEGER_CST} giving the value
469 assigned to that constant.  These constants will appear in the order in
470 which they were declared.  The @code{TREE_TYPE} of each of these
471 constants will be the type of enumeration type itself.
473 @item BOOLEAN_TYPE
474 Used to represent the @code{bool} type.
476 @item POINTER_TYPE
477 Used to represent pointer types, and pointer to data member types.  The
478 @code{TREE_TYPE} gives the type to which this type points.  If the type
479 is a pointer to data member type, then @code{TYPE_PTRMEM_P} will hold.
480 For a pointer to data member type of the form @samp{T X::*},
481 @code{TYPE_PTRMEM_CLASS_TYPE} will be the type @code{X}, while
482 @code{TYPE_PTRMEM_POINTED_TO_TYPE} will be the type @code{T}.
484 @item REFERENCE_TYPE
485 Used to represent reference types.  The @code{TREE_TYPE} gives the type
486 to which this type refers.
488 @item FUNCTION_TYPE
489 Used to represent the type of non-member functions and of static member
490 functions.  The @code{TREE_TYPE} gives the return type of the function.
491 The @code{TYPE_ARG_TYPES} are a @code{TREE_LIST} of the argument types.
492 The @code{TREE_VALUE} of each node in this list is the type of the
493 corresponding argument; the @code{TREE_PURPOSE} is an expression for the
494 default argument value, if any.  If the last node in the list is
495 @code{void_list_node} (a @code{TREE_LIST} node whose @code{TREE_VALUE}
496 is the @code{void_type_node}), then functions of this type do not take
497 variable arguments.  Otherwise, they do take a variable number of
498 arguments.
500 Note that in C (but not in C++) a function declared like @code{void f()}
501 is an unprototyped function taking a variable number of arguments; the
502 @code{TYPE_ARG_TYPES} of such a function will be @code{NULL}.
504 @item METHOD_TYPE
505 Used to represent the type of a non-static member function.  Like a
506 @code{FUNCTION_TYPE}, the return type is given by the @code{TREE_TYPE}.
507 The type of @code{*this}, i.e., the class of which functions of this
508 type are a member, is given by the @code{TYPE_METHOD_BASETYPE}.  The
509 @code{TYPE_ARG_TYPES} is the parameter list, as for a
510 @code{FUNCTION_TYPE}, and includes the @code{this} argument.
512 @item ARRAY_TYPE
513 Used to represent array types.  The @code{TREE_TYPE} gives the type of
514 the elements in the array.  If the array-bound is present in the type,
515 the @code{TYPE_DOMAIN} is an @code{INTEGER_TYPE} whose
516 @code{TYPE_MIN_VALUE} and @code{TYPE_MAX_VALUE} will be the lower and
517 upper bounds of the array, respectively.  The @code{TYPE_MIN_VALUE} will
518 always be an @code{INTEGER_CST} for zero, while the
519 @code{TYPE_MAX_VALUE} will be one less than the number of elements in
520 the array, i.e., the highest value which may be used to index an element
521 in the array.
523 @item RECORD_TYPE
524 Used to represent @code{struct} and @code{class} types, as well as
525 pointers to member functions and similar constructs in other languages.
526 @code{TYPE_FIELDS} contains the items contained in this type, each of
527 which can be a @code{FIELD_DECL}, @code{VAR_DECL}, @code{CONST_DECL}, or
528 @code{TYPE_DECL}.  You may not make any assumptions about the ordering
529 of the fields in the type or whether one or more of them overlap.  If
530 @code{TYPE_PTRMEMFUNC_P} holds, then this type is a pointer-to-member
531 type.  In that case, the @code{TYPE_PTRMEMFUNC_FN_TYPE} is a
532 @code{POINTER_TYPE} pointing to a @code{METHOD_TYPE}.  The
533 @code{METHOD_TYPE} is the type of a function pointed to by the
534 pointer-to-member function.  If @code{TYPE_PTRMEMFUNC_P} does not hold,
535 this type is a class type.  For more information, see @pxref{Classes}.
537 @item UNION_TYPE
538 Used to represent @code{union} types.  Similar to @code{RECORD_TYPE}
539 except that all @code{FIELD_DECL} nodes in @code{TYPE_FIELD} start at
540 bit position zero.
542 @item QUAL_UNION_TYPE
543 Used to represent part of a variant record in Ada.  Similar to
544 @code{UNION_TYPE} except that each @code{FIELD_DECL} has a
545 @code{DECL_QUALIFIER} field, which contains a boolean expression that
546 indicates whether the field is present in the object.  The type will only
547 have one field, so each field's @code{DECL_QUALIFIER} is only evaluated
548 if none of the expressions in the previous fields in @code{TYPE_FIELDS}
549 are nonzero.  Normally these expressions will reference a field in the
550 outer object using a @code{PLACEHOLDER_EXPR}.
552 @item UNKNOWN_TYPE
553 This node is used to represent a type the knowledge of which is
554 insufficient for a sound processing.
556 @item OFFSET_TYPE
557 This node is used to represent a pointer-to-data member.  For a data
558 member @code{X::m} the @code{TYPE_OFFSET_BASETYPE} is @code{X} and the
559 @code{TREE_TYPE} is the type of @code{m}.
561 @item TYPENAME_TYPE
562 Used to represent a construct of the form @code{typename T::A}.  The
563 @code{TYPE_CONTEXT} is @code{T}; the @code{TYPE_NAME} is an
564 @code{IDENTIFIER_NODE} for @code{A}.  If the type is specified via a
565 template-id, then @code{TYPENAME_TYPE_FULLNAME} yields a
566 @code{TEMPLATE_ID_EXPR}.  The @code{TREE_TYPE} is non-@code{NULL} if the
567 node is implicitly generated in support for the implicit typename
568 extension; in which case the @code{TREE_TYPE} is a type node for the
569 base-class.
571 @item TYPEOF_TYPE
572 Used to represent the @code{__typeof__} extension.  The
573 @code{TYPE_FIELDS} is the expression the type of which is being
574 represented.
575 @end table
577 There are variables whose values represent some of the basic types.
578 These include:
579 @table @code
580 @item void_type_node
581 A node for @code{void}.
583 @item integer_type_node
584 A node for @code{int}.
586 @item unsigned_type_node.
587 A node for @code{unsigned int}.
589 @item char_type_node.
590 A node for @code{char}.
591 @end table
592 @noindent
593 It may sometimes be useful to compare one of these variables with a type
594 in hand, using @code{same_type_p}.
596 @c ---------------------------------------------------------------------
597 @c Scopes
598 @c ---------------------------------------------------------------------
600 @node Scopes
601 @section Scopes
602 @cindex namespace, class, scope
604 The root of the entire intermediate representation is the variable
605 @code{global_namespace}.  This is the namespace specified with @code{::}
606 in C++ source code.  All other namespaces, types, variables, functions,
607 and so forth can be found starting with this namespace.
609 Besides namespaces, the other high-level scoping construct in C++ is the
610 class.  (Throughout this manual the term @dfn{class} is used to mean the
611 types referred to in the ANSI/ISO C++ Standard as classes; these include
612 types defined with the @code{class}, @code{struct}, and @code{union}
613 keywords.)
615 @menu
616 * Namespaces::          Member functions, types, etc.
617 * Classes::             Members, bases, friends, etc.
618 @end menu
620 @c ---------------------------------------------------------------------
621 @c Namespaces
622 @c ---------------------------------------------------------------------
624 @node Namespaces
625 @subsection Namespaces
626 @cindex namespace
627 @tindex NAMESPACE_DECL
629 A namespace is represented by a @code{NAMESPACE_DECL} node.
631 However, except for the fact that it is distinguished as the root of the
632 representation, the global namespace is no different from any other
633 namespace.  Thus, in what follows, we describe namespaces generally,
634 rather than the global namespace in particular.
636 The following macros and functions can be used on a @code{NAMESPACE_DECL}:
638 @ftable @code
639 @item DECL_NAME
640 This macro is used to obtain the @code{IDENTIFIER_NODE} corresponding to
641 the unqualified name of the name of the namespace (@pxref{Identifiers}).
642 The name of the global namespace is @samp{::}, even though in C++ the
643 global namespace is unnamed.  However, you should use comparison with
644 @code{global_namespace}, rather than @code{DECL_NAME} to determine
645 whether or not a namespace is the global one.  An unnamed namespace
646 will have a @code{DECL_NAME} equal to @code{anonymous_namespace_name}.
647 Within a single translation unit, all unnamed namespaces will have the
648 same name.
650 @item DECL_CONTEXT
651 This macro returns the enclosing namespace.  The @code{DECL_CONTEXT} for
652 the @code{global_namespace} is @code{NULL_TREE}.
654 @item DECL_NAMESPACE_ALIAS
655 If this declaration is for a namespace alias, then
656 @code{DECL_NAMESPACE_ALIAS} is the namespace for which this one is an
657 alias.
659 Do not attempt to use @code{cp_namespace_decls} for a namespace which is
660 an alias.  Instead, follow @code{DECL_NAMESPACE_ALIAS} links until you
661 reach an ordinary, non-alias, namespace, and call
662 @code{cp_namespace_decls} there.
664 @item DECL_NAMESPACE_STD_P
665 This predicate holds if the namespace is the special @code{::std}
666 namespace.
668 @item cp_namespace_decls
669 This function will return the declarations contained in the namespace,
670 including types, overloaded functions, other namespaces, and so forth.
671 If there are no declarations, this function will return
672 @code{NULL_TREE}.  The declarations are connected through their
673 @code{TREE_CHAIN} fields.
675 Although most entries on this list will be declarations,
676 @code{TREE_LIST} nodes may also appear.  In this case, the
677 @code{TREE_VALUE} will be an @code{OVERLOAD}.  The value of the
678 @code{TREE_PURPOSE} is unspecified; back ends should ignore this value.
679 As with the other kinds of declarations returned by
680 @code{cp_namespace_decls}, the @code{TREE_CHAIN} will point to the next
681 declaration in this list.
683 For more information on the kinds of declarations that can occur on this
684 list, @xref{Declarations}.  Some declarations will not appear on this
685 list.  In particular, no @code{FIELD_DECL}, @code{LABEL_DECL}, or
686 @code{PARM_DECL} nodes will appear here.
688 This function cannot be used with namespaces that have
689 @code{DECL_NAMESPACE_ALIAS} set.
691 @end ftable
693 @c ---------------------------------------------------------------------
694 @c Classes
695 @c ---------------------------------------------------------------------
697 @node Classes
698 @subsection Classes
699 @cindex class
700 @tindex RECORD_TYPE
701 @tindex UNION_TYPE
702 @findex CLASSTYPE_DECLARED_CLASS
703 @findex TYPE_BINFO
704 @findex BINFO_TYPE
705 @findex TYPE_FIELDS
706 @findex TYPE_VFIELD
707 @findex TYPE_METHODS
709 A class type is represented by either a @code{RECORD_TYPE} or a
710 @code{UNION_TYPE}.  A class declared with the @code{union} tag is
711 represented by a @code{UNION_TYPE}, while classes declared with either
712 the @code{struct} or the @code{class} tag are represented by
713 @code{RECORD_TYPE}s.  You can use the @code{CLASSTYPE_DECLARED_CLASS}
714 macro to discern whether or not a particular type is a @code{class} as
715 opposed to a @code{struct}.  This macro will be true only for classes
716 declared with the @code{class} tag.
718 Almost all non-function members are available on the @code{TYPE_FIELDS}
719 list.  Given one member, the next can be found by following the
720 @code{TREE_CHAIN}.  You should not depend in any way on the order in
721 which fields appear on this list.  All nodes on this list will be
722 @samp{DECL} nodes.  A @code{FIELD_DECL} is used to represent a non-static
723 data member, a @code{VAR_DECL} is used to represent a static data
724 member, and a @code{TYPE_DECL} is used to represent a type.  Note that
725 the @code{CONST_DECL} for an enumeration constant will appear on this
726 list, if the enumeration type was declared in the class.  (Of course,
727 the @code{TYPE_DECL} for the enumeration type will appear here as well.)
728 There are no entries for base classes on this list.  In particular,
729 there is no @code{FIELD_DECL} for the ``base-class portion'' of an
730 object.
732 The @code{TYPE_VFIELD} is a compiler-generated field used to point to
733 virtual function tables.  It may or may not appear on the
734 @code{TYPE_FIELDS} list.  However, back ends should handle the
735 @code{TYPE_VFIELD} just like all the entries on the @code{TYPE_FIELDS}
736 list.
738 The function members are available on the @code{TYPE_METHODS} list.
739 Again, subsequent members are found by following the @code{TREE_CHAIN}
740 field.  If a function is overloaded, each of the overloaded functions
741 appears; no @code{OVERLOAD} nodes appear on the @code{TYPE_METHODS}
742 list.  Implicitly declared functions (including default constructors,
743 copy constructors, assignment operators, and destructors) will appear on
744 this list as well.
746 Every class has an associated @dfn{binfo}, which can be obtained with
747 @code{TYPE_BINFO}.  Binfos are used to represent base-classes.  The
748 binfo given by @code{TYPE_BINFO} is the degenerate case, whereby every
749 class is considered to be its own base-class.  The base binfos for a
750 particular binfo are held in a vector, whose length is obtained with
751 @code{BINFO_N_BASE_BINFOS}.  The base binfos themselves are obtained
752 with @code{BINFO_BASE_BINFO} and @code{BINFO_BASE_ITERATE}.  To add a
753 new binfo, use @code{BINFO_BASE_APPEND}.  The vector of base binfos can
754 be obtained with @code{BINFO_BASE_BINFOS}, but normally you do not need
755 to use that.  The class type associated with a binfo is given by
756 @code{BINFO_TYPE}.  It is not always the case that @code{BINFO_TYPE
757 (TYPE_BINFO (x))}, because of typedefs and qualified types.  Neither is
758 it the case that @code{TYPE_BINFO (BINFO_TYPE (y))} is the same binfo as
759 @code{y}.  The reason is that if @code{y} is a binfo representing a
760 base-class @code{B} of a derived class @code{D}, then @code{BINFO_TYPE
761 (y)} will be @code{B}, and @code{TYPE_BINFO (BINFO_TYPE (y))} will be
762 @code{B} as its own base-class, rather than as a base-class of @code{D}.
764 The access to a base type can be found with @code{BINFO_BASE_ACCESS}.
765 This will produce @code{access_public_node}, @code{access_private_node}
766 or @code{access_protected_node}.  If bases are always public,
767 @code{BINFO_BASE_ACCESSES} may be @code{NULL}.
769 @code{BINFO_VIRTUAL_P} is used to specify whether the binfo is inherited
770 virtually or not.  The other flags, @code{BINFO_MARKED_P} and
771 @code{BINFO_FLAG_1} to @code{BINFO_FLAG_6} can be used for language
772 specific use.
774 The following macros can be used on a tree node representing a class-type.
776 @ftable @code
777 @item LOCAL_CLASS_P
778 This predicate holds if the class is local class @emph{i.e.}@: declared
779 inside a function body.
781 @item TYPE_POLYMORPHIC_P
782 This predicate holds if the class has at least one virtual function
783 (declared or inherited).
785 @item TYPE_HAS_DEFAULT_CONSTRUCTOR
786 This predicate holds whenever its argument represents a class-type with
787 default constructor.
789 @item CLASSTYPE_HAS_MUTABLE
790 @itemx TYPE_HAS_MUTABLE_P
791 These predicates hold for a class-type having a mutable data member.
793 @item CLASSTYPE_NON_POD_P
794 This predicate holds only for class-types that are not PODs.
796 @item TYPE_HAS_NEW_OPERATOR
797 This predicate holds for a class-type that defines
798 @code{operator new}.
800 @item TYPE_HAS_ARRAY_NEW_OPERATOR
801 This predicate holds for a class-type for which
802 @code{operator new[]} is defined.
804 @item TYPE_OVERLOADS_CALL_EXPR
805 This predicate holds for class-type for which the function call
806 @code{operator()} is overloaded.
808 @item TYPE_OVERLOADS_ARRAY_REF
809 This predicate holds for a class-type that overloads
810 @code{operator[]}
812 @item TYPE_OVERLOADS_ARROW
813 This predicate holds for a class-type for which @code{operator->} is
814 overloaded.
816 @end ftable
818 @c ---------------------------------------------------------------------
819 @c Declarations
820 @c ---------------------------------------------------------------------
822 @node Declarations
823 @section Declarations
824 @cindex declaration
825 @cindex variable
826 @cindex type declaration
827 @tindex LABEL_DECL
828 @tindex CONST_DECL
829 @tindex TYPE_DECL
830 @tindex VAR_DECL
831 @tindex PARM_DECL
832 @tindex FIELD_DECL
833 @tindex NAMESPACE_DECL
834 @tindex RESULT_DECL
835 @tindex TEMPLATE_DECL
836 @tindex THUNK_DECL
837 @tindex USING_DECL
838 @findex THUNK_DELTA
839 @findex DECL_INITIAL
840 @findex DECL_SIZE
841 @findex DECL_ALIGN
842 @findex DECL_EXTERNAL
844 This section covers the various kinds of declarations that appear in the
845 internal representation, except for declarations of functions
846 (represented by @code{FUNCTION_DECL} nodes), which are described in
847 @ref{Functions}.
849 @menu
850 * Working with declarations::  Macros and functions that work on
851 declarations.
852 * Internal structure:: How declaration nodes are represented. 
853 @end menu
855 @node Working with declarations
856 @subsection Working with declarations
858 Some macros can be used with any kind of declaration.  These include:
859 @ftable @code
860 @item DECL_NAME
861 This macro returns an @code{IDENTIFIER_NODE} giving the name of the
862 entity.
864 @item TREE_TYPE
865 This macro returns the type of the entity declared.
867 @item TREE_FILENAME
868 This macro returns the name of the file in which the entity was
869 declared, as a @code{char*}.  For an entity declared implicitly by the
870 compiler (like @code{__builtin_memcpy}), this will be the string
871 @code{"<internal>"}.
873 @item TREE_LINENO
874 This macro returns the line number at which the entity was declared, as
875 an @code{int}.
877 @item DECL_ARTIFICIAL
878 This predicate holds if the declaration was implicitly generated by the
879 compiler.  For example, this predicate will hold of an implicitly
880 declared member function, or of the @code{TYPE_DECL} implicitly
881 generated for a class type.  Recall that in C++ code like:
882 @smallexample
883 struct S @{@};
884 @end smallexample
885 @noindent
886 is roughly equivalent to C code like:
887 @smallexample
888 struct S @{@};
889 typedef struct S S;
890 @end smallexample
891 The implicitly generated @code{typedef} declaration is represented by a
892 @code{TYPE_DECL} for which @code{DECL_ARTIFICIAL} holds.
894 @item DECL_NAMESPACE_SCOPE_P
895 This predicate holds if the entity was declared at a namespace scope.
897 @item DECL_CLASS_SCOPE_P
898 This predicate holds if the entity was declared at a class scope.
900 @item DECL_FUNCTION_SCOPE_P
901 This predicate holds if the entity was declared inside a function
902 body.
904 @end ftable
906 The various kinds of declarations include:
907 @table @code
908 @item LABEL_DECL
909 These nodes are used to represent labels in function bodies.  For more
910 information, see @ref{Functions}.  These nodes only appear in block
911 scopes.
913 @item CONST_DECL
914 These nodes are used to represent enumeration constants.  The value of
915 the constant is given by @code{DECL_INITIAL} which will be an
916 @code{INTEGER_CST} with the same type as the @code{TREE_TYPE} of the
917 @code{CONST_DECL}, i.e., an @code{ENUMERAL_TYPE}.
919 @item RESULT_DECL
920 These nodes represent the value returned by a function.  When a value is
921 assigned to a @code{RESULT_DECL}, that indicates that the value should
922 be returned, via bitwise copy, by the function.  You can use
923 @code{DECL_SIZE} and @code{DECL_ALIGN} on a @code{RESULT_DECL}, just as
924 with a @code{VAR_DECL}.
926 @item TYPE_DECL
927 These nodes represent @code{typedef} declarations.  The @code{TREE_TYPE}
928 is the type declared to have the name given by @code{DECL_NAME}.  In
929 some cases, there is no associated name.
931 @item VAR_DECL
932 These nodes represent variables with namespace or block scope, as well
933 as static data members.  The @code{DECL_SIZE} and @code{DECL_ALIGN} are
934 analogous to @code{TYPE_SIZE} and @code{TYPE_ALIGN}.  For a declaration,
935 you should always use the @code{DECL_SIZE} and @code{DECL_ALIGN} rather
936 than the @code{TYPE_SIZE} and @code{TYPE_ALIGN} given by the
937 @code{TREE_TYPE}, since special attributes may have been applied to the
938 variable to give it a particular size and alignment.  You may use the
939 predicates @code{DECL_THIS_STATIC} or @code{DECL_THIS_EXTERN} to test
940 whether the storage class specifiers @code{static} or @code{extern} were
941 used to declare a variable.
943 If this variable is initialized (but does not require a constructor),
944 the @code{DECL_INITIAL} will be an expression for the initializer.  The
945 initializer should be evaluated, and a bitwise copy into the variable
946 performed.  If the @code{DECL_INITIAL} is the @code{error_mark_node},
947 there is an initializer, but it is given by an explicit statement later
948 in the code; no bitwise copy is required.
950 GCC provides an extension that allows either automatic variables, or
951 global variables, to be placed in particular registers.  This extension
952 is being used for a particular @code{VAR_DECL} if @code{DECL_REGISTER}
953 holds for the @code{VAR_DECL}, and if @code{DECL_ASSEMBLER_NAME} is not
954 equal to @code{DECL_NAME}.  In that case, @code{DECL_ASSEMBLER_NAME} is
955 the name of the register into which the variable will be placed.
957 @item PARM_DECL
958 Used to represent a parameter to a function.  Treat these nodes
959 similarly to @code{VAR_DECL} nodes.  These nodes only appear in the
960 @code{DECL_ARGUMENTS} for a @code{FUNCTION_DECL}.
962 The @code{DECL_ARG_TYPE} for a @code{PARM_DECL} is the type that will
963 actually be used when a value is passed to this function.  It may be a
964 wider type than the @code{TREE_TYPE} of the parameter; for example, the
965 ordinary type might be @code{short} while the @code{DECL_ARG_TYPE} is
966 @code{int}.
968 @item FIELD_DECL
969 These nodes represent non-static data members.  The @code{DECL_SIZE} and
970 @code{DECL_ALIGN} behave as for @code{VAR_DECL} nodes.  
971 The position of the field within the parent record is specified by a 
972 combination of three attributes.  @code{DECL_FIELD_OFFSET} is the position,
973 counting in bytes, of the @code{DECL_OFFSET_ALIGN}-bit sized word containing
974 the bit of the field closest to the beginning of the structure.  
975 @code{DECL_FIELD_BIT_OFFSET} is the bit offset of the first bit of the field
976 within this word; this may be nonzero even for fields that are not bit-fields,
977 since @code{DECL_OFFSET_ALIGN} may be greater than the natural alignment
978 of the field's type.
980 If @code{DECL_C_BIT_FIELD} holds, this field is a bit-field.  In a bit-field,
981 @code{DECL_BIT_FIELD_TYPE} also contains the type that was originally
982 specified for it, while DECL_TYPE may be a modified type with lesser precision,
983 according to the size of the bit field.
985 @item NAMESPACE_DECL
986 @xref{Namespaces}.
988 @item TEMPLATE_DECL
990 These nodes are used to represent class, function, and variable (static
991 data member) templates.  The @code{DECL_TEMPLATE_SPECIALIZATIONS} are a
992 @code{TREE_LIST}.  The @code{TREE_VALUE} of each node in the list is a
993 @code{TEMPLATE_DECL}s or @code{FUNCTION_DECL}s representing
994 specializations (including instantiations) of this template.  Back ends
995 can safely ignore @code{TEMPLATE_DECL}s, but should examine
996 @code{FUNCTION_DECL} nodes on the specializations list just as they
997 would ordinary @code{FUNCTION_DECL} nodes.
999 For a class template, the @code{DECL_TEMPLATE_INSTANTIATIONS} list
1000 contains the instantiations.  The @code{TREE_VALUE} of each node is an
1001 instantiation of the class.  The @code{DECL_TEMPLATE_SPECIALIZATIONS}
1002 contains partial specializations of the class.
1004 @item USING_DECL
1006 Back ends can safely ignore these nodes.
1008 @end table
1010 @node Internal structure
1011 @subsection Internal structure
1013 @code{DECL} nodes are represented internally as a hierarchy of
1014 structures.
1016 @menu
1017 * Current structure hierarchy::  The current DECL node structure
1018 hierarchy.
1019 * Adding new DECL node types:: How to add a new DECL node to a
1020 frontend.
1021 @end menu
1023 @node Current structure hierarchy
1024 @subsubsection Current structure hierarchy
1026 @table @code
1028 @item struct tree_decl_minimal
1029 This is the minimal structure to inherit from in order for common
1030 @code{DECL} macros to work.  The fields it contains are a unique ID,
1031 source location, context, and name.
1033 @item struct tree_decl_common
1034 This structure inherits from @code{struct tree_decl_minimal}.  It
1035 contains fields that most @code{DECL} nodes need, such as a field to
1036 store alignment, machine mode, size, and attributes.
1038 @item struct tree_field_decl
1039 This structure inherits from @code{struct tree_decl_common}.  It is
1040 used to represent @code{FIELD_DECL}.
1042 @item struct tree_label_decl
1043 This structure inherits from @code{struct tree_decl_common}.  It is
1044 used to represent @code{LABEL_DECL}.
1046 @item struct tree_translation_unit_decl
1047 This structure inherits from @code{struct tree_decl_common}.  It is
1048 used to represent @code{TRANSLATION_UNIT_DECL}.
1050 @item struct tree_decl_with_rtl
1051 This structure inherits from @code{struct tree_decl_common}.  It
1052 contains a field to store the low-level RTL associated with a
1053 @code{DECL} node.
1055 @item struct tree_result_decl
1056 This structure inherits from @code{struct tree_decl_with_rtl}.  It is
1057 used to represent @code{RESULT_DECL}.
1059 @item struct tree_const_decl
1060 This structure inherits from @code{struct tree_decl_with_rtl}.  It is
1061 used to represent @code{CONST_DECL}.
1063 @item struct tree_parm_decl
1064 This structure inherits from @code{struct tree_decl_with_rtl}.  It is
1065 used to represent @code{PARM_DECL}.  
1067 @item struct tree_decl_with_vis
1068 This structure inherits from @code{struct tree_decl_with_rtl}.  It
1069 contains fields necessary to store visibility information, as well as
1070 a section name and assembler name.
1072 @item struct tree_var_decl
1073 This structure inherits from @code{struct tree_decl_with_vis}.  It is
1074 used to represent @code{VAR_DECL}.  
1076 @item struct tree_function_decl
1077 This structure inherits from @code{struct tree_decl_with_vis}.  It is
1078 used to represent @code{FUNCTION_DECL}.  
1080 @end table
1081 @node Adding new DECL node types
1082 @subsubsection Adding new DECL node types
1084 Adding a new @code{DECL} tree consists of the following steps
1086 @table @asis
1088 @item Add a new tree code for the @code{DECL} node
1089 For language specific @code{DECL} nodes, there is a @file{.def} file
1090 in each frontend directory where the tree code should be added.
1091 For @code{DECL} nodes that are part of the middle-end, the code should
1092 be added to @file{tree.def}.
1094 @item Create a new structure type for the @code{DECL} node
1095 These structures should inherit from one of the existing structures in
1096 the language hierarchy by using that structure as the first member.
1098 @smallexample
1099 struct tree_foo_decl
1101    struct tree_decl_with_vis common;
1103 @end smallexample
1105 Would create a structure name @code{tree_foo_decl} that inherits from
1106 @code{struct tree_decl_with_vis}.
1108 For language specific @code{DECL} nodes, this new structure type
1109 should go in the appropriate @file{.h} file.
1110 For @code{DECL} nodes that are part of the middle-end, the structure
1111 type should go in @file{tree.h}.
1113 @item Add a member to the tree structure enumerator for the node
1114 For garbage collection and dynamic checking purposes, each @code{DECL}
1115 node structure type is required to have a unique enumerator value
1116 specified with it.
1117 For language specific @code{DECL} nodes, this new enumerator value
1118 should go in the appropriate @file{.def} file.
1119 For @code{DECL} nodes that are part of the middle-end, the enumerator
1120 values are specified in @file{treestruct.def}.
1122 @item Update @code{union tree_node}
1123 In order to make your new structure type usable, it must be added to
1124 @code{union tree_node}.
1125 For language specific @code{DECL} nodes, a new entry should be added
1126 to the appropriate @file{.h} file of the form
1127 @smallexample
1128   struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl;
1129 @end smallexample
1130 For @code{DECL} nodes that are part of the middle-end, the additional
1131 member goes directly into @code{union tree_node} in @file{tree.h}.
1133 @item Update dynamic checking info
1134 In order to be able to check whether accessing a named portion of
1135 @code{union tree_node} is legal, and whether a certain @code{DECL} node
1136 contains one of the enumerated @code{DECL} node structures in the
1137 hierarchy, a simple lookup table is used.
1138 This lookup table needs to be kept up to date with the tree structure
1139 hierarchy, or else checking and containment macros will fail
1140 inappropriately.
1142 For language specific @code{DECL} nodes, their is an @code{init_ts}
1143 function in an appropriate @file{.c} file, which initializes the lookup
1144 table.
1145 Code setting up the table for new @code{DECL} nodes should be added
1146 there.
1147 For each @code{DECL} tree code and enumerator value representing a
1148 member of the inheritance  hierarchy, the table should contain 1 if
1149 that tree code inherits (directly or indirectly) from that member.
1150 Thus, a @code{FOO_DECL} node derived from @code{struct decl_with_rtl},
1151 and enumerator value @code{TS_FOO_DECL}, would be set up as follows
1152 @smallexample
1153 tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1;
1154 tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1;
1155 tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1;
1156 tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1;
1157 @end smallexample
1159 For @code{DECL} nodes that are part of the middle-end, the setup code
1160 goes into @file{tree.c}.
1162 @item Add macros to access any new fields and flags
1164 Each added field or flag should have a macro that is used to access
1165 it, that performs appropriate checking to ensure only the right type of
1166 @code{DECL} nodes access the field.
1168 These macros generally take the following form
1169 @smallexample
1170 #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname
1171 @end smallexample
1172 However, if the structure is simply a base class for further
1173 structures, something like the following should be used
1174 @smallexample
1175 #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT)
1176 #define BASE_STRUCT_FIELDNAME(NODE) \
1177    (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname
1178 @end smallexample
1180 @end table
1183 @c ---------------------------------------------------------------------
1184 @c Functions
1185 @c ---------------------------------------------------------------------
1187 @node Functions
1188 @section Functions
1189 @cindex function
1190 @tindex FUNCTION_DECL
1191 @tindex OVERLOAD
1192 @findex OVL_CURRENT
1193 @findex OVL_NEXT
1195 A function is represented by a @code{FUNCTION_DECL} node.  A set of
1196 overloaded functions is sometimes represented by a @code{OVERLOAD} node.
1198 An @code{OVERLOAD} node is not a declaration, so none of the
1199 @samp{DECL_} macros should be used on an @code{OVERLOAD}.  An
1200 @code{OVERLOAD} node is similar to a @code{TREE_LIST}.  Use
1201 @code{OVL_CURRENT} to get the function associated with an
1202 @code{OVERLOAD} node; use @code{OVL_NEXT} to get the next
1203 @code{OVERLOAD} node in the list of overloaded functions.  The macros
1204 @code{OVL_CURRENT} and @code{OVL_NEXT} are actually polymorphic; you can
1205 use them to work with @code{FUNCTION_DECL} nodes as well as with
1206 overloads.  In the case of a @code{FUNCTION_DECL}, @code{OVL_CURRENT}
1207 will always return the function itself, and @code{OVL_NEXT} will always
1208 be @code{NULL_TREE}.
1210 To determine the scope of a function, you can use the
1211 @code{DECL_CONTEXT} macro.  This macro will return the class
1212 (either a @code{RECORD_TYPE} or a @code{UNION_TYPE}) or namespace (a
1213 @code{NAMESPACE_DECL}) of which the function is a member.  For a virtual
1214 function, this macro returns the class in which the function was
1215 actually defined, not the base class in which the virtual declaration
1216 occurred.
1218 If a friend function is defined in a class scope, the
1219 @code{DECL_FRIEND_CONTEXT} macro can be used to determine the class in
1220 which it was defined.  For example, in
1221 @smallexample
1222 class C @{ friend void f() @{@} @};
1223 @end smallexample
1224 @noindent
1225 the @code{DECL_CONTEXT} for @code{f} will be the
1226 @code{global_namespace}, but the @code{DECL_FRIEND_CONTEXT} will be the
1227 @code{RECORD_TYPE} for @code{C}.
1229 In C, the @code{DECL_CONTEXT} for a function maybe another function.
1230 This representation indicates that the GNU nested function extension
1231 is in use.  For details on the semantics of nested functions, see the
1232 GCC Manual.  The nested function can refer to local variables in its
1233 containing function.  Such references are not explicitly marked in the
1234 tree structure; back ends must look at the @code{DECL_CONTEXT} for the
1235 referenced @code{VAR_DECL}.  If the @code{DECL_CONTEXT} for the
1236 referenced @code{VAR_DECL} is not the same as the function currently
1237 being processed, and neither @code{DECL_EXTERNAL} nor
1238 @code{DECL_STATIC} hold, then the reference is to a local variable in
1239 a containing function, and the back end must take appropriate action.
1241 @menu
1242 * Function Basics::     Function names, linkage, and so forth.
1243 * Function Bodies::     The statements that make up a function body.
1244 @end menu
1246 @c ---------------------------------------------------------------------
1247 @c Function Basics
1248 @c ---------------------------------------------------------------------
1250 @node Function Basics
1251 @subsection Function Basics
1252 @cindex constructor
1253 @cindex destructor
1254 @cindex copy constructor
1255 @cindex assignment operator
1256 @cindex linkage
1257 @findex DECL_NAME
1258 @findex DECL_ASSEMBLER_NAME
1259 @findex TREE_PUBLIC
1260 @findex DECL_LINKONCE_P
1261 @findex DECL_FUNCTION_MEMBER_P
1262 @findex DECL_CONSTRUCTOR_P
1263 @findex DECL_DESTRUCTOR_P
1264 @findex DECL_OVERLOADED_OPERATOR_P
1265 @findex DECL_CONV_FN_P
1266 @findex DECL_ARTIFICIAL
1267 @findex DECL_GLOBAL_CTOR_P
1268 @findex DECL_GLOBAL_DTOR_P
1269 @findex GLOBAL_INIT_PRIORITY
1271 The following macros and functions can be used on a @code{FUNCTION_DECL}:
1272 @ftable @code
1273 @item DECL_MAIN_P
1274 This predicate holds for a function that is the program entry point
1275 @code{::code}.
1277 @item DECL_NAME
1278 This macro returns the unqualified name of the function, as an
1279 @code{IDENTIFIER_NODE}.  For an instantiation of a function template,
1280 the @code{DECL_NAME} is the unqualified name of the template, not
1281 something like @code{f<int>}.  The value of @code{DECL_NAME} is
1282 undefined when used on a constructor, destructor, overloaded operator,
1283 or type-conversion operator, or any function that is implicitly
1284 generated by the compiler.  See below for macros that can be used to
1285 distinguish these cases.
1287 @item DECL_ASSEMBLER_NAME
1288 This macro returns the mangled name of the function, also an
1289 @code{IDENTIFIER_NODE}.  This name does not contain leading underscores
1290 on systems that prefix all identifiers with underscores.  The mangled
1291 name is computed in the same way on all platforms; if special processing
1292 is required to deal with the object file format used on a particular
1293 platform, it is the responsibility of the back end to perform those
1294 modifications.  (Of course, the back end should not modify
1295 @code{DECL_ASSEMBLER_NAME} itself.)
1297 Using @code{DECL_ASSEMBLER_NAME} will cause additional memory to be
1298 allocated (for the mangled name of the entity) so it should be used
1299 only when emitting assembly code.  It should not be used within the
1300 optimizers to determine whether or not two declarations are the same,
1301 even though some of the existing optimizers do use it in that way.
1302 These uses will be removed over time.
1304 @item DECL_EXTERNAL
1305 This predicate holds if the function is undefined.
1307 @item TREE_PUBLIC
1308 This predicate holds if the function has external linkage.
1310 @item DECL_LOCAL_FUNCTION_P
1311 This predicate holds if the function was declared at block scope, even
1312 though it has a global scope.
1314 @item DECL_ANTICIPATED
1315 This predicate holds if the function is a built-in function but its
1316 prototype is not yet explicitly declared.
1318 @item DECL_EXTERN_C_FUNCTION_P
1319 This predicate holds if the function is declared as an
1320 `@code{extern "C"}' function.
1322 @item DECL_LINKONCE_P
1323 This macro holds if multiple copies of this function may be emitted in
1324 various translation units.  It is the responsibility of the linker to
1325 merge the various copies.  Template instantiations are the most common
1326 example of functions for which @code{DECL_LINKONCE_P} holds; G++
1327 instantiates needed templates in all translation units which require them,
1328 and then relies on the linker to remove duplicate instantiations.
1330 FIXME: This macro is not yet implemented.
1332 @item DECL_FUNCTION_MEMBER_P
1333 This macro holds if the function is a member of a class, rather than a
1334 member of a namespace.
1336 @item DECL_STATIC_FUNCTION_P
1337 This predicate holds if the function a static member function.
1339 @item DECL_NONSTATIC_MEMBER_FUNCTION_P
1340 This macro holds for a non-static member function.
1342 @item DECL_CONST_MEMFUNC_P
1343 This predicate holds for a @code{const}-member function.
1345 @item DECL_VOLATILE_MEMFUNC_P
1346 This predicate holds for a @code{volatile}-member function.
1348 @item DECL_CONSTRUCTOR_P
1349 This macro holds if the function is a constructor.
1351 @item DECL_NONCONVERTING_P
1352 This predicate holds if the constructor is a non-converting constructor.
1354 @item DECL_COMPLETE_CONSTRUCTOR_P
1355 This predicate holds for a function which is a constructor for an object
1356 of a complete type.
1358 @item DECL_BASE_CONSTRUCTOR_P
1359 This predicate holds for a function which is a constructor for a base
1360 class sub-object.
1362 @item DECL_COPY_CONSTRUCTOR_P
1363 This predicate holds for a function which is a copy-constructor.
1365 @item DECL_DESTRUCTOR_P
1366 This macro holds if the function is a destructor.
1368 @item DECL_COMPLETE_DESTRUCTOR_P
1369 This predicate holds if the function is the destructor for an object a
1370 complete type.
1372 @item DECL_OVERLOADED_OPERATOR_P
1373 This macro holds if the function is an overloaded operator.
1375 @item DECL_CONV_FN_P
1376 This macro holds if the function is a type-conversion operator.
1378 @item DECL_GLOBAL_CTOR_P
1379 This predicate holds if the function is a file-scope initialization
1380 function.
1382 @item DECL_GLOBAL_DTOR_P
1383 This predicate holds if the function is a file-scope finalization
1384 function.
1386 @item DECL_THUNK_P
1387 This predicate holds if the function is a thunk.
1389 These functions represent stub code that adjusts the @code{this} pointer
1390 and then jumps to another function.  When the jumped-to function
1391 returns, control is transferred directly to the caller, without
1392 returning to the thunk.  The first parameter to the thunk is always the
1393 @code{this} pointer; the thunk should add @code{THUNK_DELTA} to this
1394 value.  (The @code{THUNK_DELTA} is an @code{int}, not an
1395 @code{INTEGER_CST}.)
1397 Then, if @code{THUNK_VCALL_OFFSET} (an @code{INTEGER_CST}) is nonzero
1398 the adjusted @code{this} pointer must be adjusted again.  The complete
1399 calculation is given by the following pseudo-code:
1401 @smallexample
1402 this += THUNK_DELTA
1403 if (THUNK_VCALL_OFFSET)
1404   this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET]
1405 @end smallexample
1407 Finally, the thunk should jump to the location given
1408 by @code{DECL_INITIAL}; this will always be an expression for the
1409 address of a function.
1411 @item DECL_NON_THUNK_FUNCTION_P
1412 This predicate holds if the function is @emph{not} a thunk function.
1414 @item GLOBAL_INIT_PRIORITY
1415 If either @code{DECL_GLOBAL_CTOR_P} or @code{DECL_GLOBAL_DTOR_P} holds,
1416 then this gives the initialization priority for the function.  The
1417 linker will arrange that all functions for which
1418 @code{DECL_GLOBAL_CTOR_P} holds are run in increasing order of priority
1419 before @code{main} is called.  When the program exits, all functions for
1420 which @code{DECL_GLOBAL_DTOR_P} holds are run in the reverse order.
1422 @item DECL_ARTIFICIAL
1423 This macro holds if the function was implicitly generated by the
1424 compiler, rather than explicitly declared.  In addition to implicitly
1425 generated class member functions, this macro holds for the special
1426 functions created to implement static initialization and destruction, to
1427 compute run-time type information, and so forth.
1429 @item DECL_ARGUMENTS
1430 This macro returns the @code{PARM_DECL} for the first argument to the
1431 function.  Subsequent @code{PARM_DECL} nodes can be obtained by
1432 following the @code{TREE_CHAIN} links.
1434 @item DECL_RESULT
1435 This macro returns the @code{RESULT_DECL} for the function.
1437 @item TREE_TYPE
1438 This macro returns the @code{FUNCTION_TYPE} or @code{METHOD_TYPE} for
1439 the function.
1441 @item TYPE_RAISES_EXCEPTIONS
1442 This macro returns the list of exceptions that a (member-)function can
1443 raise.  The returned list, if non @code{NULL}, is comprised of nodes
1444 whose @code{TREE_VALUE} represents a type.
1446 @item TYPE_NOTHROW_P
1447 This predicate holds when the exception-specification of its arguments
1448 if of the form `@code{()}'.
1450 @item DECL_ARRAY_DELETE_OPERATOR_P
1451 This predicate holds if the function an overloaded
1452 @code{operator delete[]}.
1454 @end ftable
1456 @c ---------------------------------------------------------------------
1457 @c Function Bodies
1458 @c ---------------------------------------------------------------------
1460 @node Function Bodies
1461 @subsection Function Bodies
1462 @cindex function body
1463 @cindex statements
1464 @tindex BREAK_STMT
1465 @tindex CLEANUP_STMT
1466 @findex CLEANUP_DECL
1467 @findex CLEANUP_EXPR
1468 @tindex CONTINUE_STMT
1469 @tindex DECL_STMT
1470 @findex DECL_STMT_DECL
1471 @tindex DO_STMT
1472 @findex DO_BODY
1473 @findex DO_COND
1474 @tindex EMPTY_CLASS_EXPR
1475 @tindex EXPR_STMT
1476 @findex EXPR_STMT_EXPR
1477 @tindex FOR_STMT
1478 @findex FOR_INIT_STMT
1479 @findex FOR_COND
1480 @findex FOR_EXPR
1481 @findex FOR_BODY
1482 @tindex HANDLER
1483 @tindex IF_STMT
1484 @findex IF_COND
1485 @findex THEN_CLAUSE
1486 @findex ELSE_CLAUSE
1487 @tindex RETURN_STMT
1488 @findex RETURN_EXPR
1489 @tindex SUBOBJECT
1490 @findex SUBOBJECT_CLEANUP
1491 @tindex SWITCH_STMT
1492 @findex SWITCH_COND
1493 @findex SWITCH_BODY
1494 @tindex TRY_BLOCK
1495 @findex TRY_STMTS
1496 @findex TRY_HANDLERS
1497 @findex HANDLER_PARMS
1498 @findex HANDLER_BODY
1499 @findex USING_STMT
1500 @tindex WHILE_STMT
1501 @findex WHILE_BODY
1502 @findex WHILE_COND
1504 A function that has a definition in the current translation unit will
1505 have a non-@code{NULL} @code{DECL_INITIAL}.  However, back ends should not make
1506 use of the particular value given by @code{DECL_INITIAL}.
1508 The @code{DECL_SAVED_TREE} macro will give the complete body of the
1509 function.
1511 @subsubsection Statements
1513 There are tree nodes corresponding to all of the source-level
1514 statement constructs, used within the C and C++ frontends.  These are
1515 enumerated here, together with a list of the various macros that can
1516 be used to obtain information about them.  There are a few macros that
1517 can be used with all statements:
1519 @ftable @code
1520 @item STMT_IS_FULL_EXPR_P
1521 In C++, statements normally constitute ``full expressions''; temporaries
1522 created during a statement are destroyed when the statement is complete.
1523 However, G++ sometimes represents expressions by statements; these
1524 statements will not have @code{STMT_IS_FULL_EXPR_P} set.  Temporaries
1525 created during such statements should be destroyed when the innermost
1526 enclosing statement with @code{STMT_IS_FULL_EXPR_P} set is exited.
1528 @end ftable
1530 Here is the list of the various statement nodes, and the macros used to
1531 access them.  This documentation describes the use of these nodes in
1532 non-template functions (including instantiations of template functions).
1533 In template functions, the same nodes are used, but sometimes in
1534 slightly different ways.
1536 Many of the statements have substatements.  For example, a @code{while}
1537 loop will have a body, which is itself a statement.  If the substatement
1538 is @code{NULL_TREE}, it is considered equivalent to a statement
1539 consisting of a single @code{;}, i.e., an expression statement in which
1540 the expression has been omitted.  A substatement may in fact be a list
1541 of statements, connected via their @code{TREE_CHAIN}s.  So, you should
1542 always process the statement tree by looping over substatements, like
1543 this:
1544 @smallexample
1545 void process_stmt (stmt)
1546      tree stmt;
1548   while (stmt)
1549     @{
1550       switch (TREE_CODE (stmt))
1551         @{
1552         case IF_STMT:
1553           process_stmt (THEN_CLAUSE (stmt));
1554           /* @r{More processing here.}  */
1555           break;
1557         @dots{}
1558         @}
1560       stmt = TREE_CHAIN (stmt);
1561     @}
1563 @end smallexample
1564 In other words, while the @code{then} clause of an @code{if} statement
1565 in C++ can be only one statement (although that one statement may be a
1566 compound statement), the intermediate representation will sometimes use
1567 several statements chained together.
1569 @table @code
1570 @item ASM_EXPR
1572 Used to represent an inline assembly statement.  For an inline assembly
1573 statement like:
1574 @smallexample
1575 asm ("mov x, y");
1576 @end smallexample
1577 The @code{ASM_STRING} macro will return a @code{STRING_CST} node for
1578 @code{"mov x, y"}.  If the original statement made use of the
1579 extended-assembly syntax, then @code{ASM_OUTPUTS},
1580 @code{ASM_INPUTS}, and @code{ASM_CLOBBERS} will be the outputs, inputs,
1581 and clobbers for the statement, represented as @code{STRING_CST} nodes.
1582 The extended-assembly syntax looks like:
1583 @smallexample
1584 asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
1585 @end smallexample
1586 The first string is the @code{ASM_STRING}, containing the instruction
1587 template.  The next two strings are the output and inputs, respectively;
1588 this statement has no clobbers.  As this example indicates, ``plain''
1589 assembly statements are merely a special case of extended assembly
1590 statements; they have no cv-qualifiers, outputs, inputs, or clobbers.
1591 All of the strings will be @code{NUL}-terminated, and will contain no
1592 embedded @code{NUL}-characters.
1594 If the assembly statement is declared @code{volatile}, or if the
1595 statement was not an extended assembly statement, and is therefore
1596 implicitly volatile, then the predicate @code{ASM_VOLATILE_P} will hold
1597 of the @code{ASM_EXPR}.
1599 @item BREAK_STMT
1601 Used to represent a @code{break} statement.  There are no additional
1602 fields.
1604 @item CASE_LABEL_EXPR
1606 Use to represent a @code{case} label, range of @code{case} labels, or a
1607 @code{default} label.  If @code{CASE_LOW} is @code{NULL_TREE}, then this is a
1608 @code{default} label.  Otherwise, if @code{CASE_HIGH} is @code{NULL_TREE}, then
1609 this is an ordinary @code{case} label.  In this case, @code{CASE_LOW} is
1610 an expression giving the value of the label.  Both @code{CASE_LOW} and
1611 @code{CASE_HIGH} are @code{INTEGER_CST} nodes.  These values will have
1612 the same type as the condition expression in the switch statement.
1614 Otherwise, if both @code{CASE_LOW} and @code{CASE_HIGH} are defined, the
1615 statement is a range of case labels.  Such statements originate with the
1616 extension that allows users to write things of the form:
1617 @smallexample
1618 case 2 ... 5:
1619 @end smallexample
1620 The first value will be @code{CASE_LOW}, while the second will be
1621 @code{CASE_HIGH}.
1623 @item CLEANUP_STMT
1625 Used to represent an action that should take place upon exit from the
1626 enclosing scope.  Typically, these actions are calls to destructors for
1627 local objects, but back ends cannot rely on this fact.  If these nodes
1628 are in fact representing such destructors, @code{CLEANUP_DECL} will be
1629 the @code{VAR_DECL} destroyed.  Otherwise, @code{CLEANUP_DECL} will be
1630 @code{NULL_TREE}.  In any case, the @code{CLEANUP_EXPR} is the
1631 expression to execute.  The cleanups executed on exit from a scope
1632 should be run in the reverse order of the order in which the associated
1633 @code{CLEANUP_STMT}s were encountered.
1635 @item CONTINUE_STMT
1637 Used to represent a @code{continue} statement.  There are no additional
1638 fields.
1640 @item CTOR_STMT
1642 Used to mark the beginning (if @code{CTOR_BEGIN_P} holds) or end (if
1643 @code{CTOR_END_P} holds of the main body of a constructor.  See also
1644 @code{SUBOBJECT} for more information on how to use these nodes.
1646 @item DECL_STMT
1648 Used to represent a local declaration.  The @code{DECL_STMT_DECL} macro
1649 can be used to obtain the entity declared.  This declaration may be a
1650 @code{LABEL_DECL}, indicating that the label declared is a local label.
1651 (As an extension, GCC allows the declaration of labels with scope.)  In
1652 C, this declaration may be a @code{FUNCTION_DECL}, indicating the
1653 use of the GCC nested function extension.  For more information,
1654 @pxref{Functions}.
1656 @item DO_STMT
1658 Used to represent a @code{do} loop.  The body of the loop is given by
1659 @code{DO_BODY} while the termination condition for the loop is given by
1660 @code{DO_COND}.  The condition for a @code{do}-statement is always an
1661 expression.
1663 @item EMPTY_CLASS_EXPR
1665 Used to represent a temporary object of a class with no data whose
1666 address is never taken.  (All such objects are interchangeable.)  The
1667 @code{TREE_TYPE} represents the type of the object.
1669 @item EXPR_STMT
1671 Used to represent an expression statement.  Use @code{EXPR_STMT_EXPR} to
1672 obtain the expression.
1674 @item FOR_STMT
1676 Used to represent a @code{for} statement.  The @code{FOR_INIT_STMT} is
1677 the initialization statement for the loop.  The @code{FOR_COND} is the
1678 termination condition.  The @code{FOR_EXPR} is the expression executed
1679 right before the @code{FOR_COND} on each loop iteration; often, this
1680 expression increments a counter.  The body of the loop is given by
1681 @code{FOR_BODY}.  Note that @code{FOR_INIT_STMT} and @code{FOR_BODY}
1682 return statements, while @code{FOR_COND} and @code{FOR_EXPR} return
1683 expressions.
1685 @item GOTO_EXPR
1687 Used to represent a @code{goto} statement.  The @code{GOTO_DESTINATION} will
1688 usually be a @code{LABEL_DECL}.  However, if the ``computed goto'' extension
1689 has been used, the @code{GOTO_DESTINATION} will be an arbitrary expression
1690 indicating the destination.  This expression will always have pointer type.
1692 @item HANDLER
1694 Used to represent a C++ @code{catch} block.  The @code{HANDLER_TYPE}
1695 is the type of exception that will be caught by this handler; it is
1696 equal (by pointer equality) to @code{NULL} if this handler is for all
1697 types.  @code{HANDLER_PARMS} is the @code{DECL_STMT} for the catch
1698 parameter, and @code{HANDLER_BODY} is the code for the block itself.
1700 @item IF_STMT
1702 Used to represent an @code{if} statement.  The @code{IF_COND} is the
1703 expression.
1705 If the condition is a @code{TREE_LIST}, then the @code{TREE_PURPOSE} is
1706 a statement (usually a @code{DECL_STMT}).  Each time the condition is
1707 evaluated, the statement should be executed.  Then, the
1708 @code{TREE_VALUE} should be used as the conditional expression itself.
1709 This representation is used to handle C++ code like this:
1711 @smallexample
1712 if (int i = 7) @dots{}
1713 @end smallexample
1715 where there is a new local variable (or variables) declared within the
1716 condition.
1718 The @code{THEN_CLAUSE} represents the statement given by the @code{then}
1719 condition, while the @code{ELSE_CLAUSE} represents the statement given
1720 by the @code{else} condition.
1722 @item LABEL_EXPR
1724 Used to represent a label.  The @code{LABEL_DECL} declared by this
1725 statement can be obtained with the @code{LABEL_EXPR_LABEL} macro.  The
1726 @code{IDENTIFIER_NODE} giving the name of the label can be obtained from
1727 the @code{LABEL_DECL} with @code{DECL_NAME}.
1729 @item RETURN_STMT
1731 Used to represent a @code{return} statement.  The @code{RETURN_EXPR} is
1732 the expression returned; it will be @code{NULL_TREE} if the statement
1733 was just
1734 @smallexample
1735 return;
1736 @end smallexample
1738 @item SUBOBJECT
1740 In a constructor, these nodes are used to mark the point at which a
1741 subobject of @code{this} is fully constructed.  If, after this point, an
1742 exception is thrown before a @code{CTOR_STMT} with @code{CTOR_END_P} set
1743 is encountered, the @code{SUBOBJECT_CLEANUP} must be executed.  The
1744 cleanups must be executed in the reverse order in which they appear.
1746 @item SWITCH_STMT
1748 Used to represent a @code{switch} statement.  The @code{SWITCH_STMT_COND}
1749 is the expression on which the switch is occurring.  See the documentation
1750 for an @code{IF_STMT} for more information on the representation used
1751 for the condition.  The @code{SWITCH_STMT_BODY} is the body of the switch
1752 statement.   The @code{SWITCH_STMT_TYPE} is the original type of switch
1753 expression as given in the source, before any compiler conversions.
1755 @item TRY_BLOCK
1756 Used to represent a @code{try} block.  The body of the try block is
1757 given by @code{TRY_STMTS}.  Each of the catch blocks is a @code{HANDLER}
1758 node.  The first handler is given by @code{TRY_HANDLERS}.  Subsequent
1759 handlers are obtained by following the @code{TREE_CHAIN} link from one
1760 handler to the next.  The body of the handler is given by
1761 @code{HANDLER_BODY}.
1763 If @code{CLEANUP_P} holds of the @code{TRY_BLOCK}, then the
1764 @code{TRY_HANDLERS} will not be a @code{HANDLER} node.  Instead, it will
1765 be an expression that should be executed if an exception is thrown in
1766 the try block.  It must rethrow the exception after executing that code.
1767 And, if an exception is thrown while the expression is executing,
1768 @code{terminate} must be called.
1770 @item USING_STMT
1771 Used to represent a @code{using} directive.  The namespace is given by
1772 @code{USING_STMT_NAMESPACE}, which will be a NAMESPACE_DECL@.  This node
1773 is needed inside template functions, to implement using directives
1774 during instantiation.
1776 @item WHILE_STMT
1778 Used to represent a @code{while} loop.  The @code{WHILE_COND} is the
1779 termination condition for the loop.  See the documentation for an
1780 @code{IF_STMT} for more information on the representation used for the
1781 condition.
1783 The @code{WHILE_BODY} is the body of the loop.
1785 @end table
1787 @c ---------------------------------------------------------------------
1788 @c Attributes
1789 @c ---------------------------------------------------------------------
1790 @node Attributes
1791 @section Attributes in trees
1792 @cindex attributes
1794 Attributes, as specified using the @code{__attribute__} keyword, are
1795 represented internally as a @code{TREE_LIST}.  The @code{TREE_PURPOSE}
1796 is the name of the attribute, as an @code{IDENTIFIER_NODE}.  The
1797 @code{TREE_VALUE} is a @code{TREE_LIST} of the arguments of the
1798 attribute, if any, or @code{NULL_TREE} if there are no arguments; the
1799 arguments are stored as the @code{TREE_VALUE} of successive entries in
1800 the list, and may be identifiers or expressions.  The @code{TREE_CHAIN}
1801 of the attribute is the next attribute in a list of attributes applying
1802 to the same declaration or type, or @code{NULL_TREE} if there are no
1803 further attributes in the list.
1805 Attributes may be attached to declarations and to types; these
1806 attributes may be accessed with the following macros.  All attributes
1807 are stored in this way, and many also cause other changes to the
1808 declaration or type or to other internal compiler data structures.
1810 @deftypefn {Tree Macro} tree DECL_ATTRIBUTES (tree @var{decl})
1811 This macro returns the attributes on the declaration @var{decl}.
1812 @end deftypefn
1814 @deftypefn {Tree Macro} tree TYPE_ATTRIBUTES (tree @var{type})
1815 This macro returns the attributes on the type @var{type}.
1816 @end deftypefn
1818 @c ---------------------------------------------------------------------
1819 @c Expressions
1820 @c ---------------------------------------------------------------------
1822 @node Expression trees
1823 @section Expressions
1824 @cindex expression
1825 @findex TREE_TYPE
1826 @findex TREE_OPERAND
1827 @tindex INTEGER_CST
1828 @findex TREE_INT_CST_HIGH
1829 @findex TREE_INT_CST_LOW
1830 @findex tree_int_cst_lt
1831 @findex tree_int_cst_equal
1832 @tindex REAL_CST
1833 @tindex COMPLEX_CST
1834 @tindex VECTOR_CST
1835 @tindex STRING_CST
1836 @findex TREE_STRING_LENGTH
1837 @findex TREE_STRING_POINTER
1838 @tindex PTRMEM_CST
1839 @findex PTRMEM_CST_CLASS
1840 @findex PTRMEM_CST_MEMBER
1841 @tindex VAR_DECL
1842 @tindex NEGATE_EXPR
1843 @tindex ABS_EXPR
1844 @tindex BIT_NOT_EXPR
1845 @tindex TRUTH_NOT_EXPR
1846 @tindex PREDECREMENT_EXPR
1847 @tindex PREINCREMENT_EXPR
1848 @tindex POSTDECREMENT_EXPR
1849 @tindex POSTINCREMENT_EXPR
1850 @tindex ADDR_EXPR
1851 @tindex INDIRECT_REF
1852 @tindex FIX_TRUNC_EXPR
1853 @tindex FLOAT_EXPR
1854 @tindex COMPLEX_EXPR
1855 @tindex CONJ_EXPR
1856 @tindex REALPART_EXPR
1857 @tindex IMAGPART_EXPR
1858 @tindex NON_LVALUE_EXPR
1859 @tindex NOP_EXPR
1860 @tindex CONVERT_EXPR
1861 @tindex THROW_EXPR
1862 @tindex LSHIFT_EXPR
1863 @tindex RSHIFT_EXPR
1864 @tindex BIT_IOR_EXPR
1865 @tindex BIT_XOR_EXPR
1866 @tindex BIT_AND_EXPR
1867 @tindex TRUTH_ANDIF_EXPR
1868 @tindex TRUTH_ORIF_EXPR
1869 @tindex TRUTH_AND_EXPR
1870 @tindex TRUTH_OR_EXPR
1871 @tindex TRUTH_XOR_EXPR
1872 @tindex PLUS_EXPR
1873 @tindex MINUS_EXPR
1874 @tindex MULT_EXPR
1875 @tindex RDIV_EXPR
1876 @tindex TRUNC_DIV_EXPR
1877 @tindex FLOOR_DIV_EXPR
1878 @tindex CEIL_DIV_EXPR
1879 @tindex ROUND_DIV_EXPR
1880 @tindex TRUNC_MOD_EXPR
1881 @tindex FLOOR_MOD_EXPR
1882 @tindex CEIL_MOD_EXPR
1883 @tindex ROUND_MOD_EXPR
1884 @tindex EXACT_DIV_EXPR
1885 @tindex ARRAY_REF
1886 @tindex ARRAY_RANGE_REF
1887 @tindex TARGET_MEM_REF
1888 @tindex LT_EXPR
1889 @tindex LE_EXPR
1890 @tindex GT_EXPR
1891 @tindex GE_EXPR
1892 @tindex EQ_EXPR
1893 @tindex NE_EXPR
1894 @tindex ORDERED_EXPR
1895 @tindex UNORDERED_EXPR
1896 @tindex UNLT_EXPR
1897 @tindex UNLE_EXPR
1898 @tindex UNGT_EXPR
1899 @tindex UNGE_EXPR
1900 @tindex UNEQ_EXPR
1901 @tindex LTGT_EXPR
1902 @tindex MODIFY_EXPR
1903 @tindex INIT_EXPR
1904 @tindex COMPONENT_REF
1905 @tindex COMPOUND_EXPR
1906 @tindex COND_EXPR
1907 @tindex CALL_EXPR
1908 @tindex STMT_EXPR
1909 @tindex BIND_EXPR
1910 @tindex LOOP_EXPR
1911 @tindex EXIT_EXPR
1912 @tindex CLEANUP_POINT_EXPR
1913 @tindex CONSTRUCTOR
1914 @tindex COMPOUND_LITERAL_EXPR
1915 @tindex SAVE_EXPR
1916 @tindex TARGET_EXPR
1917 @tindex AGGR_INIT_EXPR
1918 @tindex VA_ARG_EXPR
1919 @tindex OMP_PARALLEL
1920 @tindex OMP_FOR
1921 @tindex OMP_SECTIONS
1922 @tindex OMP_SINGLE
1923 @tindex OMP_SECTION
1924 @tindex OMP_MASTER
1925 @tindex OMP_ORDERED
1926 @tindex OMP_CRITICAL
1927 @tindex OMP_RETURN
1928 @tindex OMP_CONTINUE
1929 @tindex OMP_ATOMIC
1930 @tindex OMP_CLAUSE
1931 @tindex VEC_LSHIFT_EXPR
1932 @tindex VEC_RSHIFT_EXPR
1933 @tindex VEC_WIDEN_MULT_HI_EXPR
1934 @tindex VEC_WIDEN_MULT_LO_EXPR
1935 @tindex VEC_UNPACK_HI_EXPR
1936 @tindex VEC_UNPACK_LO_EXPR
1937 @tindex VEC_PACK_MOD_EXPR
1938 @tindex VEC_PACK_SAT_EXPR
1939 @tindex VEC_EXTRACT_EVEN_EXPR 
1940 @tindex VEC_EXTRACT_ODD_EXPR
1941 @tindex VEC_INTERLEAVE_HIGH_EXPR
1942 @tindex VEC_INTERLEAVE_LOW_EXPR
1944 The internal representation for expressions is for the most part quite
1945 straightforward.  However, there are a few facts that one must bear in
1946 mind.  In particular, the expression ``tree'' is actually a directed
1947 acyclic graph.  (For example there may be many references to the integer
1948 constant zero throughout the source program; many of these will be
1949 represented by the same expression node.)  You should not rely on
1950 certain kinds of node being shared, nor should rely on certain kinds of
1951 nodes being unshared.
1953 The following macros can be used with all expression nodes:
1955 @ftable @code
1956 @item TREE_TYPE
1957 Returns the type of the expression.  This value may not be precisely the
1958 same type that would be given the expression in the original program.
1959 @end ftable
1961 In what follows, some nodes that one might expect to always have type
1962 @code{bool} are documented to have either integral or boolean type.  At
1963 some point in the future, the C front end may also make use of this same
1964 intermediate representation, and at this point these nodes will
1965 certainly have integral type.  The previous sentence is not meant to
1966 imply that the C++ front end does not or will not give these nodes
1967 integral type.
1969 Below, we list the various kinds of expression nodes.  Except where
1970 noted otherwise, the operands to an expression are accessed using the
1971 @code{TREE_OPERAND} macro.  For example, to access the first operand to
1972 a binary plus expression @code{expr}, use:
1974 @smallexample
1975 TREE_OPERAND (expr, 0)
1976 @end smallexample
1977 @noindent
1978 As this example indicates, the operands are zero-indexed.
1980 All the expressions starting with @code{OMP_} represent directives and
1981 clauses used by the OpenMP API @w{@uref{http://www.openmp.org/}}.
1983 The table below begins with constants, moves on to unary expressions,
1984 then proceeds to binary expressions, and concludes with various other
1985 kinds of expressions:
1987 @table @code
1988 @item INTEGER_CST
1989 These nodes represent integer constants.  Note that the type of these
1990 constants is obtained with @code{TREE_TYPE}; they are not always of type
1991 @code{int}.  In particular, @code{char} constants are represented with
1992 @code{INTEGER_CST} nodes.  The value of the integer constant @code{e} is
1993 given by
1994 @smallexample
1995 ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT)
1996 + TREE_INST_CST_LOW (e))
1997 @end smallexample
1998 @noindent
1999 HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms.  Both
2000 @code{TREE_INT_CST_HIGH} and @code{TREE_INT_CST_LOW} return a
2001 @code{HOST_WIDE_INT}.  The value of an @code{INTEGER_CST} is interpreted
2002 as a signed or unsigned quantity depending on the type of the constant.
2003 In general, the expression given above will overflow, so it should not
2004 be used to calculate the value of the constant.
2006 The variable @code{integer_zero_node} is an integer constant with value
2007 zero.  Similarly, @code{integer_one_node} is an integer constant with
2008 value one.  The @code{size_zero_node} and @code{size_one_node} variables
2009 are analogous, but have type @code{size_t} rather than @code{int}.
2011 The function @code{tree_int_cst_lt} is a predicate which holds if its
2012 first argument is less than its second.  Both constants are assumed to
2013 have the same signedness (i.e., either both should be signed or both
2014 should be unsigned.)  The full width of the constant is used when doing
2015 the comparison; the usual rules about promotions and conversions are
2016 ignored.  Similarly, @code{tree_int_cst_equal} holds if the two
2017 constants are equal.  The @code{tree_int_cst_sgn} function returns the
2018 sign of a constant.  The value is @code{1}, @code{0}, or @code{-1}
2019 according on whether the constant is greater than, equal to, or less
2020 than zero.  Again, the signedness of the constant's type is taken into
2021 account; an unsigned constant is never less than zero, no matter what
2022 its bit-pattern.
2024 @item REAL_CST
2026 FIXME: Talk about how to obtain representations of this constant, do
2027 comparisons, and so forth.
2029 @item COMPLEX_CST
2030 These nodes are used to represent complex number constants, that is a
2031 @code{__complex__} whose parts are constant nodes.  The
2032 @code{TREE_REALPART} and @code{TREE_IMAGPART} return the real and the
2033 imaginary parts respectively.
2035 @item VECTOR_CST
2036 These nodes are used to represent vector constants, whose parts are
2037 constant nodes.  Each individual constant node is either an integer or a
2038 double constant node.  The first operand is a @code{TREE_LIST} of the
2039 constant nodes and is accessed through @code{TREE_VECTOR_CST_ELTS}.
2041 @item STRING_CST
2042 These nodes represent string-constants.  The @code{TREE_STRING_LENGTH}
2043 returns the length of the string, as an @code{int}.  The
2044 @code{TREE_STRING_POINTER} is a @code{char*} containing the string
2045 itself.  The string may not be @code{NUL}-terminated, and it may contain
2046 embedded @code{NUL} characters.  Therefore, the
2047 @code{TREE_STRING_LENGTH} includes the trailing @code{NUL} if it is
2048 present.
2050 For wide string constants, the @code{TREE_STRING_LENGTH} is the number
2051 of bytes in the string, and the @code{TREE_STRING_POINTER}
2052 points to an array of the bytes of the string, as represented on the
2053 target system (that is, as integers in the target endianness).  Wide and
2054 non-wide string constants are distinguished only by the @code{TREE_TYPE}
2055 of the @code{STRING_CST}.
2057 FIXME: The formats of string constants are not well-defined when the
2058 target system bytes are not the same width as host system bytes.
2060 @item PTRMEM_CST
2061 These nodes are used to represent pointer-to-member constants.  The
2062 @code{PTRMEM_CST_CLASS} is the class type (either a @code{RECORD_TYPE}
2063 or @code{UNION_TYPE} within which the pointer points), and the
2064 @code{PTRMEM_CST_MEMBER} is the declaration for the pointed to object.
2065 Note that the @code{DECL_CONTEXT} for the @code{PTRMEM_CST_MEMBER} is in
2066 general different from the @code{PTRMEM_CST_CLASS}.  For example,
2067 given:
2068 @smallexample
2069 struct B @{ int i; @};
2070 struct D : public B @{@};
2071 int D::*dp = &D::i;
2072 @end smallexample
2073 @noindent
2074 The @code{PTRMEM_CST_CLASS} for @code{&D::i} is @code{D}, even though
2075 the @code{DECL_CONTEXT} for the @code{PTRMEM_CST_MEMBER} is @code{B},
2076 since @code{B::i} is a member of @code{B}, not @code{D}.
2078 @item VAR_DECL
2080 These nodes represent variables, including static data members.  For
2081 more information, @pxref{Declarations}.
2083 @item NEGATE_EXPR
2084 These nodes represent unary negation of the single operand, for both
2085 integer and floating-point types.  The type of negation can be
2086 determined by looking at the type of the expression.
2088 The behavior of this operation on signed arithmetic overflow is
2089 controlled by the @code{flag_wrapv} and @code{flag_trapv} variables.
2091 @item ABS_EXPR
2092 These nodes represent the absolute value of the single operand, for
2093 both integer and floating-point types.  This is typically used to
2094 implement the @code{abs}, @code{labs} and @code{llabs} builtins for
2095 integer types, and the @code{fabs}, @code{fabsf} and @code{fabsl}
2096 builtins for floating point types.  The type of abs operation can
2097 be determined by looking at the type of the expression.
2099 This node is not used for complex types.  To represent the modulus
2100 or complex abs of a complex value, use the @code{BUILT_IN_CABS},
2101 @code{BUILT_IN_CABSF} or @code{BUILT_IN_CABSL} builtins, as used
2102 to implement the C99 @code{cabs}, @code{cabsf} and @code{cabsl}
2103 built-in functions.
2105 @item BIT_NOT_EXPR
2106 These nodes represent bitwise complement, and will always have integral
2107 type.  The only operand is the value to be complemented.
2109 @item TRUTH_NOT_EXPR
2110 These nodes represent logical negation, and will always have integral
2111 (or boolean) type.  The operand is the value being negated.  The type
2112 of the operand and that of the result are always of @code{BOOLEAN_TYPE}
2113 or @code{INTEGER_TYPE}.
2115 @item PREDECREMENT_EXPR
2116 @itemx PREINCREMENT_EXPR
2117 @itemx POSTDECREMENT_EXPR
2118 @itemx POSTINCREMENT_EXPR
2119 These nodes represent increment and decrement expressions.  The value of
2120 the single operand is computed, and the operand incremented or
2121 decremented.  In the case of @code{PREDECREMENT_EXPR} and
2122 @code{PREINCREMENT_EXPR}, the value of the expression is the value
2123 resulting after the increment or decrement; in the case of
2124 @code{POSTDECREMENT_EXPR} and @code{POSTINCREMENT_EXPR} is the value
2125 before the increment or decrement occurs.  The type of the operand, like
2126 that of the result, will be either integral, boolean, or floating-point.
2128 @item ADDR_EXPR
2129 These nodes are used to represent the address of an object.  (These
2130 expressions will always have pointer or reference type.)  The operand may
2131 be another expression, or it may be a declaration.
2133 As an extension, GCC allows users to take the address of a label.  In
2134 this case, the operand of the @code{ADDR_EXPR} will be a
2135 @code{LABEL_DECL}.  The type of such an expression is @code{void*}.
2137 If the object addressed is not an lvalue, a temporary is created, and
2138 the address of the temporary is used.
2140 @item INDIRECT_REF
2141 These nodes are used to represent the object pointed to by a pointer.
2142 The operand is the pointer being dereferenced; it will always have
2143 pointer or reference type.
2145 @item FIX_TRUNC_EXPR
2146 These nodes represent conversion of a floating-point value to an
2147 integer.  The single operand will have a floating-point type, while the
2148 the complete expression will have an integral (or boolean) type.  The
2149 operand is rounded towards zero.
2151 @item FLOAT_EXPR
2152 These nodes represent conversion of an integral (or boolean) value to a
2153 floating-point value.  The single operand will have integral type, while
2154 the complete expression will have a floating-point type.
2156 FIXME: How is the operand supposed to be rounded?  Is this dependent on
2157 @option{-mieee}?
2159 @item COMPLEX_EXPR
2160 These nodes are used to represent complex numbers constructed from two
2161 expressions of the same (integer or real) type.  The first operand is the
2162 real part and the second operand is the imaginary part.
2164 @item CONJ_EXPR
2165 These nodes represent the conjugate of their operand.
2167 @item REALPART_EXPR
2168 @itemx IMAGPART_EXPR
2169 These nodes represent respectively the real and the imaginary parts
2170 of complex numbers (their sole argument).
2172 @item NON_LVALUE_EXPR
2173 These nodes indicate that their one and only operand is not an lvalue.
2174 A back end can treat these identically to the single operand.
2176 @item NOP_EXPR
2177 These nodes are used to represent conversions that do not require any
2178 code-generation.  For example, conversion of a @code{char*} to an
2179 @code{int*} does not require any code be generated; such a conversion is
2180 represented by a @code{NOP_EXPR}.  The single operand is the expression
2181 to be converted.  The conversion from a pointer to a reference is also
2182 represented with a @code{NOP_EXPR}.
2184 @item CONVERT_EXPR
2185 These nodes are similar to @code{NOP_EXPR}s, but are used in those
2186 situations where code may need to be generated.  For example, if an
2187 @code{int*} is converted to an @code{int} code may need to be generated
2188 on some platforms.  These nodes are never used for C++-specific
2189 conversions, like conversions between pointers to different classes in
2190 an inheritance hierarchy.  Any adjustments that need to be made in such
2191 cases are always indicated explicitly.  Similarly, a user-defined
2192 conversion is never represented by a @code{CONVERT_EXPR}; instead, the
2193 function calls are made explicit.
2195 @item THROW_EXPR
2196 These nodes represent @code{throw} expressions.  The single operand is
2197 an expression for the code that should be executed to throw the
2198 exception.  However, there is one implicit action not represented in
2199 that expression; namely the call to @code{__throw}.  This function takes
2200 no arguments.  If @code{setjmp}/@code{longjmp} exceptions are used, the
2201 function @code{__sjthrow} is called instead.  The normal GCC back end
2202 uses the function @code{emit_throw} to generate this code; you can
2203 examine this function to see what needs to be done.
2205 @item LSHIFT_EXPR
2206 @itemx RSHIFT_EXPR
2207 These nodes represent left and right shifts, respectively.  The first
2208 operand is the value to shift; it will always be of integral type.  The
2209 second operand is an expression for the number of bits by which to
2210 shift.  Right shift should be treated as arithmetic, i.e., the
2211 high-order bits should be zero-filled when the expression has unsigned
2212 type and filled with the sign bit when the expression has signed type.
2213 Note that the result is undefined if the second operand is larger
2214 than or equal to the first operand's type size.
2217 @item BIT_IOR_EXPR
2218 @itemx BIT_XOR_EXPR
2219 @itemx BIT_AND_EXPR
2220 These nodes represent bitwise inclusive or, bitwise exclusive or, and
2221 bitwise and, respectively.  Both operands will always have integral
2222 type.
2224 @item TRUTH_ANDIF_EXPR
2225 @itemx TRUTH_ORIF_EXPR
2226 These nodes represent logical and and logical or, respectively.  These
2227 operators are not strict; i.e., the second operand is evaluated only if
2228 the value of the expression is not determined by evaluation of the first
2229 operand.  The type of the operands and that of the result are always of
2230 @code{BOOLEAN_TYPE} or @code{INTEGER_TYPE}.
2232 @item TRUTH_AND_EXPR
2233 @itemx TRUTH_OR_EXPR
2234 @itemx TRUTH_XOR_EXPR
2235 These nodes represent logical and, logical or, and logical exclusive or.
2236 They are strict; both arguments are always evaluated.  There are no
2237 corresponding operators in C or C++, but the front end will sometimes
2238 generate these expressions anyhow, if it can tell that strictness does
2239 not matter.  The type of the operands and that of the result are
2240 always of @code{BOOLEAN_TYPE} or @code{INTEGER_TYPE}.
2242 @itemx PLUS_EXPR
2243 @itemx MINUS_EXPR
2244 @itemx MULT_EXPR
2245 These nodes represent various binary arithmetic operations.
2246 Respectively, these operations are addition, subtraction (of the second
2247 operand from the first) and multiplication.  Their operands may have
2248 either integral or floating type, but there will never be case in which
2249 one operand is of floating type and the other is of integral type.
2251 The behavior of these operations on signed arithmetic overflow is
2252 controlled by the @code{flag_wrapv} and @code{flag_trapv} variables.
2254 @item RDIV_EXPR
2255 This node represents a floating point division operation.
2257 @item TRUNC_DIV_EXPR
2258 @itemx FLOOR_DIV_EXPR
2259 @itemx CEIL_DIV_EXPR
2260 @itemx ROUND_DIV_EXPR
2261 These nodes represent integer division operations that return an integer
2262 result.  @code{TRUNC_DIV_EXPR} rounds towards zero, @code{FLOOR_DIV_EXPR}
2263 rounds towards negative infinity, @code{CEIL_DIV_EXPR} rounds towards
2264 positive infinity and @code{ROUND_DIV_EXPR} rounds to the closest integer.
2265 Integer division in C and C++ is truncating, i.e.@: @code{TRUNC_DIV_EXPR}.
2267 The behavior of these operations on signed arithmetic overflow, when
2268 dividing the minimum signed integer by minus one, is controlled by the
2269 @code{flag_wrapv} and @code{flag_trapv} variables.
2271 @item TRUNC_MOD_EXPR
2272 @itemx FLOOR_MOD_EXPR
2273 @itemx CEIL_MOD_EXPR
2274 @itemx ROUND_MOD_EXPR
2275 These nodes represent the integer remainder or modulus operation.
2276 The integer modulus of two operands @code{a} and @code{b} is
2277 defined as @code{a - (a/b)*b} where the division calculated using
2278 the corresponding division operator.  Hence for @code{TRUNC_MOD_EXPR}
2279 this definition assumes division using truncation towards zero, i.e.@:
2280 @code{TRUNC_DIV_EXPR}.  Integer remainder in C and C++ uses truncating
2281 division, i.e.@: @code{TRUNC_MOD_EXPR}.
2283 @item EXACT_DIV_EXPR
2284 The @code{EXACT_DIV_EXPR} code is used to represent integer divisions where
2285 the numerator is known to be an exact multiple of the denominator.  This
2286 allows the backend to choose between the faster of @code{TRUNC_DIV_EXPR},
2287 @code{CEIL_DIV_EXPR} and @code{FLOOR_DIV_EXPR} for the current target.
2289 @item ARRAY_REF
2290 These nodes represent array accesses.  The first operand is the array;
2291 the second is the index.  To calculate the address of the memory
2292 accessed, you must scale the index by the size of the type of the array
2293 elements.  The type of these expressions must be the type of a component of
2294 the array.  The third and fourth operands are used after gimplification
2295 to represent the lower bound and component size but should not be used
2296 directly; call @code{array_ref_low_bound} and @code{array_ref_element_size}
2297 instead.
2299 @item ARRAY_RANGE_REF
2300 These nodes represent access to a range (or ``slice'') of an array.  The
2301 operands are the same as that for @code{ARRAY_REF} and have the same
2302 meanings.  The type of these expressions must be an array whose component
2303 type is the same as that of the first operand.  The range of that array
2304 type determines the amount of data these expressions access.
2306 @item TARGET_MEM_REF
2307 These nodes represent memory accesses whose address directly map to
2308 an addressing mode of the target architecture.  The first argument
2309 is @code{TMR_SYMBOL} and must be a @code{VAR_DECL} of an object with
2310 a fixed address.  The second argument is @code{TMR_BASE} and the
2311 third one is @code{TMR_INDEX}.  The fourth argument is
2312 @code{TMR_STEP} and must be an @code{INTEGER_CST}.  The fifth
2313 argument is @code{TMR_OFFSET} and must be an @code{INTEGER_CST}.
2314 Any of the arguments may be NULL if the appropriate component
2315 does not appear in the address.  Address of the @code{TARGET_MEM_REF}
2316 is determined in the following way.
2318 @smallexample
2319 &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET
2320 @end smallexample
2322 The sixth argument is the reference to the original memory access, which
2323 is preserved for the purposes of the RTL alias analysis.  The seventh
2324 argument is a tag representing the results of tree level alias analysis.
2326 @item LT_EXPR
2327 @itemx LE_EXPR
2328 @itemx GT_EXPR
2329 @itemx GE_EXPR
2330 @itemx EQ_EXPR
2331 @itemx NE_EXPR
2332 These nodes represent the less than, less than or equal to, greater
2333 than, greater than or equal to, equal, and not equal comparison
2334 operators.  The first and second operand with either be both of integral
2335 type or both of floating type.  The result type of these expressions
2336 will always be of integral or boolean type.  These operations return
2337 the result type's zero value for false, and the result type's one value
2338 for true.
2340 For floating point comparisons, if we honor IEEE NaNs and either operand
2341 is NaN, then @code{NE_EXPR} always returns true and the remaining operators
2342 always return false.  On some targets, comparisons against an IEEE NaN,
2343 other than equality and inequality, may generate a floating point exception.
2345 @item ORDERED_EXPR
2346 @itemx UNORDERED_EXPR
2347 These nodes represent non-trapping ordered and unordered comparison
2348 operators.  These operations take two floating point operands and
2349 determine whether they are ordered or unordered relative to each other.
2350 If either operand is an IEEE NaN, their comparison is defined to be
2351 unordered, otherwise the comparison is defined to be ordered.  The
2352 result type of these expressions will always be of integral or boolean
2353 type.  These operations return the result type's zero value for false,
2354 and the result type's one value for true.
2356 @item UNLT_EXPR
2357 @itemx UNLE_EXPR
2358 @itemx UNGT_EXPR
2359 @itemx UNGE_EXPR
2360 @itemx UNEQ_EXPR
2361 @itemx LTGT_EXPR
2362 These nodes represent the unordered comparison operators.
2363 These operations take two floating point operands and determine whether
2364 the operands are unordered or are less than, less than or equal to,
2365 greater than, greater than or equal to, or equal respectively.  For
2366 example, @code{UNLT_EXPR} returns true if either operand is an IEEE
2367 NaN or the first operand is less than the second.  With the possible
2368 exception of @code{LTGT_EXPR}, all of these operations are guaranteed
2369 not to generate a floating point exception.  The result
2370 type of these expressions will always be of integral or boolean type.
2371 These operations return the result type's zero value for false,
2372 and the result type's one value for true.
2374 @item MODIFY_EXPR
2375 These nodes represent assignment.  The left-hand side is the first
2376 operand; the right-hand side is the second operand.  The left-hand side
2377 will be a @code{VAR_DECL}, @code{INDIRECT_REF}, @code{COMPONENT_REF}, or
2378 other lvalue.
2380 These nodes are used to represent not only assignment with @samp{=} but
2381 also compound assignments (like @samp{+=}), by reduction to @samp{=}
2382 assignment.  In other words, the representation for @samp{i += 3} looks
2383 just like that for @samp{i = i + 3}.
2385 @item INIT_EXPR
2386 These nodes are just like @code{MODIFY_EXPR}, but are used only when a
2387 variable is initialized, rather than assigned to subsequently.  This
2388 means that we can assume that the target of the initialization is not
2389 used in computing its own value; any reference to the lhs in computing
2390 the rhs is undefined.
2392 @item COMPONENT_REF
2393 These nodes represent non-static data member accesses.  The first
2394 operand is the object (rather than a pointer to it); the second operand
2395 is the @code{FIELD_DECL} for the data member.  The third operand represents
2396 the byte offset of the field, but should not be used directly; call
2397 @code{component_ref_field_offset} instead.
2399 @item COMPOUND_EXPR
2400 These nodes represent comma-expressions.  The first operand is an
2401 expression whose value is computed and thrown away prior to the
2402 evaluation of the second operand.  The value of the entire expression is
2403 the value of the second operand.
2405 @item COND_EXPR
2406 These nodes represent @code{?:} expressions.  The first operand
2407 is of boolean or integral type.  If it evaluates to a nonzero value,
2408 the second operand should be evaluated, and returned as the value of the
2409 expression.  Otherwise, the third operand is evaluated, and returned as
2410 the value of the expression.
2412 The second operand must have the same type as the entire expression,
2413 unless it unconditionally throws an exception or calls a noreturn
2414 function, in which case it should have void type.  The same constraints
2415 apply to the third operand.  This allows array bounds checks to be
2416 represented conveniently as @code{(i >= 0 && i < 10) ? i : abort()}.
2418 As a GNU extension, the C language front-ends allow the second
2419 operand of the @code{?:} operator may be omitted in the source.
2420 For example, @code{x ? : 3} is equivalent to @code{x ? x : 3},
2421 assuming that @code{x} is an expression without side-effects.
2422 In the tree representation, however, the second operand is always
2423 present, possibly protected by @code{SAVE_EXPR} if the first
2424 argument does cause side-effects.
2426 @item CALL_EXPR
2427 These nodes are used to represent calls to functions, including
2428 non-static member functions.  The first operand is a pointer to the
2429 function to call; it is always an expression whose type is a
2430 @code{POINTER_TYPE}.  The second argument is a @code{TREE_LIST}.  The
2431 arguments to the call appear left-to-right in the list.  The
2432 @code{TREE_VALUE} of each list node contains the expression
2433 corresponding to that argument.  (The value of @code{TREE_PURPOSE} for
2434 these nodes is unspecified, and should be ignored.)  For non-static
2435 member functions, there will be an operand corresponding to the
2436 @code{this} pointer.  There will always be expressions corresponding to
2437 all of the arguments, even if the function is declared with default
2438 arguments and some arguments are not explicitly provided at the call
2439 sites.
2441 @item STMT_EXPR
2442 These nodes are used to represent GCC's statement-expression extension.
2443 The statement-expression extension allows code like this:
2444 @smallexample
2445 int f() @{ return (@{ int j; j = 3; j + 7; @}); @}
2446 @end smallexample
2447 In other words, an sequence of statements may occur where a single
2448 expression would normally appear.  The @code{STMT_EXPR} node represents
2449 such an expression.  The @code{STMT_EXPR_STMT} gives the statement
2450 contained in the expression.  The value of the expression is the value
2451 of the last sub-statement in the body.  More precisely, the value is the
2452 value computed by the last statement nested inside @code{BIND_EXPR},
2453 @code{TRY_FINALLY_EXPR}, or @code{TRY_CATCH_EXPR}.  For example, in:
2454 @smallexample
2455 (@{ 3; @})
2456 @end smallexample
2457 the value is @code{3} while in:
2458 @smallexample
2459 (@{ if (x) @{ 3; @} @})
2460 @end smallexample
2461 there is no value.  If the @code{STMT_EXPR} does not yield a value,
2462 it's type will be @code{void}.
2464 @item BIND_EXPR
2465 These nodes represent local blocks.  The first operand is a list of
2466 variables, connected via their @code{TREE_CHAIN} field.  These will
2467 never require cleanups.  The scope of these variables is just the body
2468 of the @code{BIND_EXPR}.  The body of the @code{BIND_EXPR} is the
2469 second operand.
2471 @item LOOP_EXPR
2472 These nodes represent ``infinite'' loops.  The @code{LOOP_EXPR_BODY}
2473 represents the body of the loop.  It should be executed forever, unless
2474 an @code{EXIT_EXPR} is encountered.
2476 @item EXIT_EXPR
2477 These nodes represent conditional exits from the nearest enclosing
2478 @code{LOOP_EXPR}.  The single operand is the condition; if it is
2479 nonzero, then the loop should be exited.  An @code{EXIT_EXPR} will only
2480 appear within a @code{LOOP_EXPR}.
2482 @item CLEANUP_POINT_EXPR
2483 These nodes represent full-expressions.  The single operand is an
2484 expression to evaluate.  Any destructor calls engendered by the creation
2485 of temporaries during the evaluation of that expression should be
2486 performed immediately after the expression is evaluated.
2488 @item CONSTRUCTOR
2489 These nodes represent the brace-enclosed initializers for a structure or
2490 array.  The first operand is reserved for use by the back end.  The
2491 second operand is a @code{TREE_LIST}.  If the @code{TREE_TYPE} of the
2492 @code{CONSTRUCTOR} is a @code{RECORD_TYPE} or @code{UNION_TYPE}, then
2493 the @code{TREE_PURPOSE} of each node in the @code{TREE_LIST} will be a
2494 @code{FIELD_DECL} and the @code{TREE_VALUE} of each node will be the
2495 expression used to initialize that field.
2497 If the @code{TREE_TYPE} of the @code{CONSTRUCTOR} is an
2498 @code{ARRAY_TYPE}, then the @code{TREE_PURPOSE} of each element in the
2499 @code{TREE_LIST} will be an @code{INTEGER_CST} or a @code{RANGE_EXPR} of
2500 two @code{INTEGER_CST}s.  A single @code{INTEGER_CST} indicates which
2501 element of the array (indexed from zero) is being assigned to.  A
2502 @code{RANGE_EXPR} indicates an inclusive range of elements to
2503 initialize.  In both cases the @code{TREE_VALUE} is the corresponding
2504 initializer.  It is re-evaluated for each element of a
2505 @code{RANGE_EXPR}.  If the @code{TREE_PURPOSE} is @code{NULL_TREE}, then
2506 the initializer is for the next available array element.
2508 In the front end, you should not depend on the fields appearing in any
2509 particular order.  However, in the middle end, fields must appear in
2510 declaration order.  You should not assume that all fields will be
2511 represented.  Unrepresented fields will be set to zero.
2513 @item COMPOUND_LITERAL_EXPR
2514 @findex COMPOUND_LITERAL_EXPR_DECL_STMT
2515 @findex COMPOUND_LITERAL_EXPR_DECL
2516 These nodes represent ISO C99 compound literals.  The
2517 @code{COMPOUND_LITERAL_EXPR_DECL_STMT} is a @code{DECL_STMT}
2518 containing an anonymous @code{VAR_DECL} for
2519 the unnamed object represented by the compound literal; the
2520 @code{DECL_INITIAL} of that @code{VAR_DECL} is a @code{CONSTRUCTOR}
2521 representing the brace-enclosed list of initializers in the compound
2522 literal.  That anonymous @code{VAR_DECL} can also be accessed directly
2523 by the @code{COMPOUND_LITERAL_EXPR_DECL} macro.
2525 @item SAVE_EXPR
2527 A @code{SAVE_EXPR} represents an expression (possibly involving
2528 side-effects) that is used more than once.  The side-effects should
2529 occur only the first time the expression is evaluated.  Subsequent uses
2530 should just reuse the computed value.  The first operand to the
2531 @code{SAVE_EXPR} is the expression to evaluate.  The side-effects should
2532 be executed where the @code{SAVE_EXPR} is first encountered in a
2533 depth-first preorder traversal of the expression tree.
2535 @item TARGET_EXPR
2536 A @code{TARGET_EXPR} represents a temporary object.  The first operand
2537 is a @code{VAR_DECL} for the temporary variable.  The second operand is
2538 the initializer for the temporary.  The initializer is evaluated and,
2539 if non-void, copied (bitwise) into the temporary.  If the initializer
2540 is void, that means that it will perform the initialization itself.
2542 Often, a @code{TARGET_EXPR} occurs on the right-hand side of an
2543 assignment, or as the second operand to a comma-expression which is
2544 itself the right-hand side of an assignment, etc.  In this case, we say
2545 that the @code{TARGET_EXPR} is ``normal''; otherwise, we say it is
2546 ``orphaned''.  For a normal @code{TARGET_EXPR} the temporary variable
2547 should be treated as an alias for the left-hand side of the assignment,
2548 rather than as a new temporary variable.
2550 The third operand to the @code{TARGET_EXPR}, if present, is a
2551 cleanup-expression (i.e., destructor call) for the temporary.  If this
2552 expression is orphaned, then this expression must be executed when the
2553 statement containing this expression is complete.  These cleanups must
2554 always be executed in the order opposite to that in which they were
2555 encountered.  Note that if a temporary is created on one branch of a
2556 conditional operator (i.e., in the second or third operand to a
2557 @code{COND_EXPR}), the cleanup must be run only if that branch is
2558 actually executed.
2560 See @code{STMT_IS_FULL_EXPR_P} for more information about running these
2561 cleanups.
2563 @item AGGR_INIT_EXPR
2564 An @code{AGGR_INIT_EXPR} represents the initialization as the return
2565 value of a function call, or as the result of a constructor.  An
2566 @code{AGGR_INIT_EXPR} will only appear as a full-expression, or as the
2567 second operand of a @code{TARGET_EXPR}.  The first operand to the
2568 @code{AGGR_INIT_EXPR} is the address of a function to call, just as in
2569 a @code{CALL_EXPR}.  The second operand are the arguments to pass that
2570 function, as a @code{TREE_LIST}, again in a manner similar to that of
2571 a @code{CALL_EXPR}.
2573 If @code{AGGR_INIT_VIA_CTOR_P} holds of the @code{AGGR_INIT_EXPR}, then
2574 the initialization is via a constructor call.  The address of the third
2575 operand of the @code{AGGR_INIT_EXPR}, which is always a @code{VAR_DECL},
2576 is taken, and this value replaces the first argument in the argument
2577 list.
2579 In either case, the expression is void.
2581 @item VA_ARG_EXPR
2582 This node is used to implement support for the C/C++ variable argument-list
2583 mechanism.  It represents expressions like @code{va_arg (ap, type)}.
2584 Its @code{TREE_TYPE} yields the tree representation for @code{type} and
2585 its sole argument yields the representation for @code{ap}.
2587 @item OMP_PARALLEL
2589 Represents @code{#pragma omp parallel [clause1 ... clauseN]}. It
2590 has four operands:
2592 Operand @code{OMP_PARALLEL_BODY} is valid while in GENERIC and
2593 High GIMPLE forms.  It contains the body of code to be executed
2594 by all the threads.  During GIMPLE lowering, this operand becomes
2595 @code{NULL} and the body is emitted linearly after
2596 @code{OMP_PARALLEL}.
2598 Operand @code{OMP_PARALLEL_CLAUSES} is the list of clauses
2599 associated with the directive.
2601 Operand @code{OMP_PARALLEL_FN} is created by
2602 @code{pass_lower_omp}, it contains the @code{FUNCTION_DECL}
2603 for the function that will contain the body of the parallel
2604 region.
2606 Operand @code{OMP_PARALLEL_DATA_ARG} is also created by
2607 @code{pass_lower_omp}. If there are shared variables to be
2608 communicated to the children threads, this operand will contain
2609 the @code{VAR_DECL} that contains all the shared values and
2610 variables.
2612 @item OMP_FOR
2614 Represents @code{#pragma omp for [clause1 ... clauseN]}.  It
2615 has 5 operands:
2617 Operand @code{OMP_FOR_BODY} contains the loop body.
2619 Operand @code{OMP_FOR_CLAUSES} is the list of clauses
2620 associated with the directive.
2622 Operand @code{OMP_FOR_INIT} is the loop initialization code of
2623 the form @code{VAR = N1}.
2625 Operand @code{OMP_FOR_COND} is the loop conditional expression
2626 of the form @code{VAR @{<,>,<=,>=@} N2}.
2628 Operand @code{OMP_FOR_INCR} is the loop index increment of the
2629 form @code{VAR @{+=,-=@} INCR}.
2631 Operand @code{OMP_FOR_PRE_BODY} contains side-effect code from
2632 operands @code{OMP_FOR_INIT}, @code{OMP_FOR_COND} and
2633 @code{OMP_FOR_INC}.  These side-effects are part of the
2634 @code{OMP_FOR} block but must be evaluated before the start of
2635 loop body.
2637 The loop index variable @code{VAR} must be a signed integer variable,
2638 which is implicitly private to each thread.  Bounds
2639 @code{N1} and @code{N2} and the increment expression
2640 @code{INCR} are required to be loop invariant integer
2641 expressions that are evaluated without any synchronization. The
2642 evaluation order, frequency of evaluation and side-effects are
2643 unspecified by the standard.
2645 @item OMP_SECTIONS
2647 Represents @code{#pragma omp sections [clause1 ... clauseN]}.
2649 Operand @code{OMP_SECTIONS_BODY} contains the sections body,
2650 which in turn contains a set of @code{OMP_SECTION} nodes for
2651 each of the concurrent sections delimited by @code{#pragma omp
2652 section}.
2654 Operand @code{OMP_SECTIONS_CLAUSES} is the list of clauses
2655 associated with the directive.
2657 @item OMP_SECTION
2659 Section delimiter for @code{OMP_SECTIONS}.
2661 @item OMP_SINGLE
2663 Represents @code{#pragma omp single}.
2665 Operand @code{OMP_SINGLE_BODY} contains the body of code to be
2666 executed by a single thread.
2668 Operand @code{OMP_SINGLE_CLAUSES} is the list of clauses
2669 associated with the directive.
2671 @item OMP_MASTER
2673 Represents @code{#pragma omp master}.
2675 Operand @code{OMP_MASTER_BODY} contains the body of code to be
2676 executed by the master thread.
2678 @item OMP_ORDERED
2680 Represents @code{#pragma omp ordered}.
2682 Operand @code{OMP_ORDERED_BODY} contains the body of code to be
2683 executed in the sequential order dictated by the loop index
2684 variable.
2686 @item OMP_CRITICAL
2688 Represents @code{#pragma omp critical [name]}.
2690 Operand @code{OMP_CRITICAL_BODY} is the critical section.
2692 Operand @code{OMP_CRITICAL_NAME} is an optional identifier to
2693 label the critical section.
2695 @item OMP_RETURN
2697 This does not represent any OpenMP directive, it is an artificial
2698 marker to indicate the end of the body of an OpenMP. It is used
2699 by the flow graph (@code{tree-cfg.c}) and OpenMP region
2700 building code (@code{omp-low.c}).
2702 @item OMP_CONTINUE
2704 Similarly, this instruction does not represent an OpenMP
2705 directive, it is used by @code{OMP_FOR} and
2706 @code{OMP_SECTIONS} to mark the place where the code needs to
2707 loop to the next iteration (in the case of @code{OMP_FOR}) or
2708 the next section (in the case of @code{OMP_SECTIONS}).
2710 In some cases, @code{OMP_CONTINUE} is placed right before
2711 @code{OMP_RETURN}.  But if there are cleanups that need to
2712 occur right after the looping body, it will be emitted between
2713 @code{OMP_CONTINUE} and @code{OMP_RETURN}.
2715 @item OMP_ATOMIC
2717 Represents @code{#pragma omp atomic}.
2719 Operand 0 is the address at which the atomic operation is to be
2720 performed.
2722 Operand 1 is the expression to evaluate.  The gimplifier tries
2723 three alternative code generation strategies.  Whenever possible,
2724 an atomic update built-in is used.  If that fails, a
2725 compare-and-swap loop is attempted.  If that also fails, a
2726 regular critical section around the expression is used.
2728 @item OMP_CLAUSE
2730 Represents clauses associated with one of the @code{OMP_} directives.
2731 Clauses are represented by separate sub-codes defined in
2732 @file{tree.h}.  Clauses codes can be one of:
2733 @code{OMP_CLAUSE_PRIVATE}, @code{OMP_CLAUSE_SHARED},
2734 @code{OMP_CLAUSE_FIRSTPRIVATE},
2735 @code{OMP_CLAUSE_LASTPRIVATE}, @code{OMP_CLAUSE_COPYIN},
2736 @code{OMP_CLAUSE_COPYPRIVATE}, @code{OMP_CLAUSE_IF},
2737 @code{OMP_CLAUSE_NUM_THREADS}, @code{OMP_CLAUSE_SCHEDULE},
2738 @code{OMP_CLAUSE_NOWAIT}, @code{OMP_CLAUSE_ORDERED},
2739 @code{OMP_CLAUSE_DEFAULT}, and @code{OMP_CLAUSE_REDUCTION}.  Each code
2740 represents the corresponding OpenMP clause.
2742 Clauses associated with the same directive are chained together
2743 via @code{OMP_CLAUSE_CHAIN}. Those clauses that accept a list
2744 of variables are restricted to exactly one, accessed with
2745 @code{OMP_CLAUSE_VAR}.  Therefore, multiple variables under the
2746 same clause @code{C} need to be represented as multiple @code{C} clauses
2747 chained together.  This facilitates adding new clauses during
2748 compilation.
2750 @item VEC_LSHIFT_EXPR
2751 @item VEC_RSHIFT_EXPR
2752 These nodes represent whole vector left and right shifts, respectively.  
2753 The first operand is the vector to shift; it will always be of vector type.  
2754 The second operand is an expression for the number of bits by which to
2755 shift.  Note that the result is undefined if the second operand is larger
2756 than or equal to the first operand's type size.
2758 @item VEC_WIDEN_MULT_HI_EXPR
2759 @item VEC_WIDEN_MULT_LO_EXPR
2760 These nodes represent widening vector multiplication of the high and low
2761 parts of the two input vectors, respectively.  Their operands are vectors 
2762 that contain the same number of elements (@code{N}) of the same integral type.  
2763 The result is a vector that contains half as many elements, of an integral type 
2764 whose size is twice as wide.  In the case of @code{VEC_WIDEN_MULT_HI_EXPR} the
2765 high @code{N/2} elements of the two vector are multiplied to produce the
2766 vector of @code{N/2} products. In the case of @code{VEC_WIDEN_MULT_LO_EXPR} the
2767 low @code{N/2} elements of the two vector are multiplied to produce the
2768 vector of @code{N/2} products.
2770 @item VEC_UNPACK_HI_EXPR
2771 @item VEC_UNPACK_LO_EXPR
2772 These nodes represent unpacking of the high and low parts of the input vector, 
2773 respectively.  The single operand is a vector that contains @code{N} elements 
2774 of the same integral type.  The result is a vector that contains half as many 
2775 elements, of an integral type whose size is twice as wide.  In the case of 
2776 @code{VEC_UNPACK_HI_EXPR} the high @code{N/2} elements of the vector are 
2777 extracted and widened (promoted).  In the case of @code{VEC_UNPACK_LO_EXPR} the 
2778 low @code{N/2} elements of the vector are extracted and widened (promoted).
2780 @item VEC_PACK_MOD_EXPR
2781 @item VEC_PACK_SAT_EXPR
2782 These nodes represent packing of elements of the two input vectors into the
2783 output vector, using modulo or saturating arithmetic, respectively.
2784 Their operands are vectors that contain the same number of elements 
2785 of the same integral type.  The result is a vector that contains twice as many 
2786 elements, of an integral type whose size is half as wide.  In both cases
2787 the elements of the two vectors are demoted and merged (concatenated) to form
2788 the output vector.
2790 @item VEC_EXTRACT_EVEN_EXPR
2791 @item VEC_EXTRACT_ODD_EXPR
2792 These nodes represent extracting of the even/odd elements of the two input 
2793 vectors, respectively. Their operands and result are vectors that contain the 
2794 same number of elements of the same type.
2796 @item VEC_INTERLEAVE_HIGH_EXPR
2797 @item VEC_INTERLEAVE_LOW_EXPR
2798 These nodes represent merging and interleaving of the high/low elements of the
2799 two input vectors, respectively. The operands and the result are vectors that 
2800 contain the same number of elements (@code{N}) of the same type.
2801 In the case of @code{VEC_INTERLEAVE_HIGH_EXPR}, the high @code{N/2} elements of 
2802 the first input vector are interleaved with the high @code{N/2} elements of the
2803 second input vector. In the case of @code{VEC_INTERLEAVE_LOW_EXPR}, the low
2804 @code{N/2} elements of the first input vector are interleaved with the low 
2805 @code{N/2} elements of the second input vector.
2807 @end table