OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [gnu-old/] [gcc-4.2.2/] [gcc/] [doc/] [c-tree.texi] - Blame information for rev 816

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 38 julius
@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.
5
 
6
@c ---------------------------------------------------------------------
7
@c Trees
8
@c ---------------------------------------------------------------------
9
 
10
@node Trees
11
@chapter Trees: The intermediate representation used by the C and C++ front ends
12
@cindex Trees
13
@cindex C/C++ Internal Representation
14
 
15
This chapter documents the internal representation used by GCC to
16
represent C and C++ source programs.  When presented with a C or C++
17
source program, GCC parses the program, performs semantic analysis
18
(including the generation of error messages), and then produces the
19
internal representation described here.  This representation contains a
20
complete representation for the entire translation unit provided as
21
input to the front end.  This representation is then typically processed
22
by a code-generator in order to produce machine code, but could also be
23
used in the creation of source browsers, intelligent editors, automatic
24
documentation generators, interpreters, and any other programs needing
25
the ability to process C or C++ code.
26
 
27
This chapter explains the internal representation.  In particular, it
28
documents the internal representation for C and C++ source
29
constructs, and the macros, functions, and variables that can be used to
30
access these constructs.  The C++ representation is largely a superset
31
of the representation used in the C front end.  There is only one
32
construct used in C that does not appear in the C++ front end and that
33
is the GNU ``nested function'' extension.  Many of the macros documented
34
here do not apply in C because the corresponding language constructs do
35
not appear in C@.
36
 
37
If you are developing a ``back end'', be it is a code-generator or some
38
other tool, that uses this representation, you may occasionally find
39
that you need to ask questions not easily answered by the functions and
40
macros available here.  If that situation occurs, it is quite likely
41
that GCC already supports the functionality you desire, but that the
42
interface is simply not documented here.  In that case, you should ask
43
the GCC maintainers (via mail to @email{gcc@@gcc.gnu.org}) about
44
documenting the functionality you require.  Similarly, if you find
45
yourself writing functions that do not deal directly with your back end,
46
but instead might be useful to other people using the GCC front end, you
47
should submit your patches for inclusion in GCC@.
48
 
49
@menu
50
* Deficiencies::        Topics net yet covered in this document.
51
* Tree overview::       All about @code{tree}s.
52
* Types::               Fundamental and aggregate types.
53
* Scopes::              Namespaces and classes.
54
* Functions::           Overloading, function bodies, and linkage.
55
* Declarations::        Type declarations and variables.
56
* Attributes::          Declaration and type attributes.
57
* Expression trees::    From @code{typeid} to @code{throw}.
58
@end menu
59
 
60
@c ---------------------------------------------------------------------
61
@c Deficiencies
62
@c ---------------------------------------------------------------------
63
 
64
@node Deficiencies
65
@section Deficiencies
66
 
67
There are many places in which this document is incomplet and incorrekt.
68
It is, as of yet, only @emph{preliminary} documentation.
69
 
70
@c ---------------------------------------------------------------------
71
@c Overview
72
@c ---------------------------------------------------------------------
73
 
74
@node Tree overview
75
@section Overview
76
@cindex tree
77
@findex TREE_CODE
78
 
79
The central data structure used by the internal representation is the
80
@code{tree}.  These nodes, while all of the C type @code{tree}, are of
81
many varieties.  A @code{tree} is a pointer type, but the object to
82
which it points may be of a variety of types.  From this point forward,
83
we will refer to trees in ordinary type, rather than in @code{this
84
font}, except when talking about the actual C type @code{tree}.
85
 
86
You can tell what kind of node a particular tree is by using the
87
@code{TREE_CODE} macro.  Many, many macros take trees as input and
88
return trees as output.  However, most macros require a certain kind of
89
tree node as input.  In other words, there is a type-system for trees,
90
but it is not reflected in the C type-system.
91
 
92
For safety, it is useful to configure GCC with @option{--enable-checking}.
93
Although this results in a significant performance penalty (since all
94
tree types are checked at run-time), and is therefore inappropriate in a
95
release version, it is extremely helpful during the development process.
96
 
97
Many macros behave as predicates.  Many, although not all, of these
98
predicates end in @samp{_P}.  Do not rely on the result type of these
99
macros being of any particular type.  You may, however, rely on the fact
100
that the type can be compared to @code{0}, so that statements like
101
@smallexample
102
if (TEST_P (t) && !TEST_P (y))
103
  x = 1;
104
@end smallexample
105
@noindent
106
and
107
@smallexample
108
int i = (TEST_P (t) != 0);
109
@end smallexample
110
@noindent
111
are legal.  Macros that return @code{int} values now may be changed to
112
return @code{tree} values, or other pointers in the future.  Even those
113
that continue to return @code{int} may return multiple nonzero codes
114
where previously they returned only zero and one.  Therefore, you should
115
not write code like
116
@smallexample
117
if (TEST_P (t) == 1)
118
@end smallexample
119
@noindent
120
as this code is not guaranteed to work correctly in the future.
121
 
122
You should not take the address of values returned by the macros or
123
functions described here.  In particular, no guarantee is given that the
124
values are lvalues.
125
 
126
In general, the names of macros are all in uppercase, while the names of
127
functions are entirely in lowercase.  There are rare exceptions to this
128
rule.  You should assume that any macro or function whose name is made
129
up entirely of uppercase letters may evaluate its arguments more than
130
once.  You may assume that a macro or function whose name is made up
131
entirely of lowercase letters will evaluate its arguments only once.
132
 
133
The @code{error_mark_node} is a special tree.  Its tree code is
134
@code{ERROR_MARK}, but since there is only ever one node with that code,
135
the usual practice is to compare the tree against
136
@code{error_mark_node}.  (This test is just a test for pointer
137
equality.)  If an error has occurred during front-end processing the
138
flag @code{errorcount} will be set.  If the front end has encountered
139
code it cannot handle, it will issue a message to the user and set
140
@code{sorrycount}.  When these flags are set, any macro or function
141
which normally returns a tree of a particular kind may instead return
142
the @code{error_mark_node}.  Thus, if you intend to do any processing of
143
erroneous code, you must be prepared to deal with the
144
@code{error_mark_node}.
145
 
146
Occasionally, a particular tree slot (like an operand to an expression,
147
or a particular field in a declaration) will be referred to as
148
``reserved for the back end''.  These slots are used to store RTL when
149
the tree is converted to RTL for use by the GCC back end.  However, if
150
that process is not taking place (e.g., if the front end is being hooked
151
up to an intelligent editor), then those slots may be used by the
152
back end presently in use.
153
 
154
If you encounter situations that do not match this documentation, such
155
as tree nodes of types not mentioned here, or macros documented to
156
return entities of a particular kind that instead return entities of
157
some different kind, you have found a bug, either in the front end or in
158
the documentation.  Please report these bugs as you would any other
159
bug.
160
 
161
@menu
162
* Macros and Functions::Macros and functions that can be used with all trees.
163
* Identifiers::         The names of things.
164
* Containers::          Lists and vectors.
165
@end menu
166
 
167
@c ---------------------------------------------------------------------
168
@c Trees
169
@c ---------------------------------------------------------------------
170
 
171
@node Macros and Functions
172
@subsection Trees
173
@cindex tree
174
 
175
This section is not here yet.
176
 
177
@c ---------------------------------------------------------------------
178
@c Identifiers
179
@c ---------------------------------------------------------------------
180
 
181
@node Identifiers
182
@subsection Identifiers
183
@cindex identifier
184
@cindex name
185
@tindex IDENTIFIER_NODE
186
 
187
An @code{IDENTIFIER_NODE} represents a slightly more general concept
188
that the standard C or C++ concept of identifier.  In particular, an
189
@code{IDENTIFIER_NODE} may contain a @samp{$}, or other extraordinary
190
characters.
191
 
192
There are never two distinct @code{IDENTIFIER_NODE}s representing the
193
same identifier.  Therefore, you may use pointer equality to compare
194
@code{IDENTIFIER_NODE}s, rather than using a routine like @code{strcmp}.
195
 
196
You can use the following macros to access identifiers:
197
@ftable @code
198
@item IDENTIFIER_POINTER
199
The string represented by the identifier, represented as a
200
@code{char*}.  This string is always @code{NUL}-terminated, and contains
201
no embedded @code{NUL} characters.
202
 
203
@item IDENTIFIER_LENGTH
204
The length of the string returned by @code{IDENTIFIER_POINTER}, not
205
including the trailing @code{NUL}.  This value of
206
@code{IDENTIFIER_LENGTH (x)} is always the same as @code{strlen
207
(IDENTIFIER_POINTER (x))}.
208
 
209
@item IDENTIFIER_OPNAME_P
210
This predicate holds if the identifier represents the name of an
211
overloaded operator.  In this case, you should not depend on the
212
contents of either the @code{IDENTIFIER_POINTER} or the
213
@code{IDENTIFIER_LENGTH}.
214
 
215
@item IDENTIFIER_TYPENAME_P
216
This predicate holds if the identifier represents the name of a
217
user-defined conversion operator.  In this case, the @code{TREE_TYPE} of
218
the @code{IDENTIFIER_NODE} holds the type to which the conversion
219
operator converts.
220
 
221
@end ftable
222
 
223
@c ---------------------------------------------------------------------
224
@c Containers
225
@c ---------------------------------------------------------------------
226
 
227
@node Containers
228
@subsection Containers
229
@cindex container
230
@cindex list
231
@cindex vector
232
@tindex TREE_LIST
233
@tindex TREE_VEC
234
@findex TREE_PURPOSE
235
@findex TREE_VALUE
236
@findex TREE_VEC_LENGTH
237
@findex TREE_VEC_ELT
238
 
239
Two common container data structures can be represented directly with
240
tree nodes.  A @code{TREE_LIST} is a singly linked list containing two
241
trees per node.  These are the @code{TREE_PURPOSE} and @code{TREE_VALUE}
242
of each node.  (Often, the @code{TREE_PURPOSE} contains some kind of
243
tag, or additional information, while the @code{TREE_VALUE} contains the
244
majority of the payload.  In other cases, the @code{TREE_PURPOSE} is
245
simply @code{NULL_TREE}, while in still others both the
246
@code{TREE_PURPOSE} and @code{TREE_VALUE} are of equal stature.)  Given
247
one @code{TREE_LIST} node, the next node is found by following the
248
@code{TREE_CHAIN}.  If the @code{TREE_CHAIN} is @code{NULL_TREE}, then
249
you have reached the end of the list.
250
 
251
A @code{TREE_VEC} is a simple vector.  The @code{TREE_VEC_LENGTH} is an
252
integer (not a tree) giving the number of nodes in the vector.  The
253
nodes themselves are accessed using the @code{TREE_VEC_ELT} macro, which
254
takes two arguments.  The first is the @code{TREE_VEC} in question; the
255
second is an integer indicating which element in the vector is desired.
256
The elements are indexed from zero.
257
 
258
@c ---------------------------------------------------------------------
259
@c Types
260
@c ---------------------------------------------------------------------
261
 
262
@node Types
263
@section Types
264
@cindex type
265
@cindex pointer
266
@cindex reference
267
@cindex fundamental type
268
@cindex array
269
@tindex VOID_TYPE
270
@tindex INTEGER_TYPE
271
@tindex TYPE_MIN_VALUE
272
@tindex TYPE_MAX_VALUE
273
@tindex REAL_TYPE
274
@tindex COMPLEX_TYPE
275
@tindex ENUMERAL_TYPE
276
@tindex BOOLEAN_TYPE
277
@tindex POINTER_TYPE
278
@tindex REFERENCE_TYPE
279
@tindex FUNCTION_TYPE
280
@tindex METHOD_TYPE
281
@tindex ARRAY_TYPE
282
@tindex RECORD_TYPE
283
@tindex UNION_TYPE
284
@tindex UNKNOWN_TYPE
285
@tindex OFFSET_TYPE
286
@tindex TYPENAME_TYPE
287
@tindex TYPEOF_TYPE
288
@findex CP_TYPE_QUALS
289
@findex TYPE_UNQUALIFIED
290
@findex TYPE_QUAL_CONST
291
@findex TYPE_QUAL_VOLATILE
292
@findex TYPE_QUAL_RESTRICT
293
@findex TYPE_MAIN_VARIANT
294
@cindex qualified type
295
@findex TYPE_SIZE
296
@findex TYPE_ALIGN
297
@findex TYPE_PRECISION
298
@findex TYPE_ARG_TYPES
299
@findex TYPE_METHOD_BASETYPE
300
@findex TYPE_PTRMEM_P
301
@findex TYPE_OFFSET_BASETYPE
302
@findex TREE_TYPE
303
@findex TYPE_CONTEXT
304
@findex TYPE_NAME
305
@findex TYPENAME_TYPE_FULLNAME
306
@findex TYPE_FIELDS
307
@findex TYPE_PTROBV_P
308
 
309
All types have corresponding tree nodes.  However, you should not assume
310
that there is exactly one tree node corresponding to each type.  There
311
are often several nodes each of which correspond to the same type.
312
 
313
For the most part, different kinds of types have different tree codes.
314
(For example, pointer types use a @code{POINTER_TYPE} code while arrays
315
use an @code{ARRAY_TYPE} code.)  However, pointers to member functions
316
use the @code{RECORD_TYPE} code.  Therefore, when writing a
317
@code{switch} statement that depends on the code associated with a
318
particular type, you should take care to handle pointers to member
319
functions under the @code{RECORD_TYPE} case label.
320
 
321
In C++, an array type is not qualified; rather the type of the array
322
elements is qualified.  This situation is reflected in the intermediate
323
representation.  The macros described here will always examine the
324
qualification of the underlying element type when applied to an array
325
type.  (If the element type is itself an array, then the recursion
326
continues until a non-array type is found, and the qualification of this
327
type is examined.)  So, for example, @code{CP_TYPE_CONST_P} will hold of
328
the type @code{const int ()[7]}, denoting an array of seven @code{int}s.
329
 
330
The following functions and macros deal with cv-qualification of types:
331
@ftable @code
332
@item CP_TYPE_QUALS
333
This macro returns the set of type qualifiers applied to this type.
334
This value is @code{TYPE_UNQUALIFIED} if no qualifiers have been
335
applied.  The @code{TYPE_QUAL_CONST} bit is set if the type is
336
@code{const}-qualified.  The @code{TYPE_QUAL_VOLATILE} bit is set if the
337
type is @code{volatile}-qualified.  The @code{TYPE_QUAL_RESTRICT} bit is
338
set if the type is @code{restrict}-qualified.
339
 
340
@item CP_TYPE_CONST_P
341
This macro holds if the type is @code{const}-qualified.
342
 
343
@item CP_TYPE_VOLATILE_P
344
This macro holds if the type is @code{volatile}-qualified.
345
 
346
@item CP_TYPE_RESTRICT_P
347
This macro holds if the type is @code{restrict}-qualified.
348
 
349
@item CP_TYPE_CONST_NON_VOLATILE_P
350
This predicate holds for a type that is @code{const}-qualified, but
351
@emph{not} @code{volatile}-qualified; other cv-qualifiers are ignored as
352
well: only the @code{const}-ness is tested.
353
 
354
@item TYPE_MAIN_VARIANT
355
This macro returns the unqualified version of a type.  It may be applied
356
to an unqualified type, but it is not always the identity function in
357
that case.
358
@end ftable
359
 
360
A few other macros and functions are usable with all types:
361
@ftable @code
362
@item TYPE_SIZE
363
The number of bits required to represent the type, represented as an
364
@code{INTEGER_CST}.  For an incomplete type, @code{TYPE_SIZE} will be
365
@code{NULL_TREE}.
366
 
367
@item TYPE_ALIGN
368
The alignment of the type, in bits, represented as an @code{int}.
369
 
370
@item TYPE_NAME
371
This macro returns a declaration (in the form of a @code{TYPE_DECL}) for
372
the type.  (Note this macro does @emph{not} return a
373
@code{IDENTIFIER_NODE}, as you might expect, given its name!)  You can
374
look at the @code{DECL_NAME} of the @code{TYPE_DECL} to obtain the
375
actual name of the type.  The @code{TYPE_NAME} will be @code{NULL_TREE}
376
for a type that is not a built-in type, the result of a typedef, or a
377
named class type.
378
 
379
@item CP_INTEGRAL_TYPE
380
This predicate holds if the type is an integral type.  Notice that in
381
C++, enumerations are @emph{not} integral types.
382
 
383
@item ARITHMETIC_TYPE_P
384
This predicate holds if the type is an integral type (in the C++ sense)
385
or a floating point type.
386
 
387
@item CLASS_TYPE_P
388
This predicate holds for a class-type.
389
 
390
@item TYPE_BUILT_IN
391
This predicate holds for a built-in type.
392
 
393
@item TYPE_PTRMEM_P
394
This predicate holds if the type is a pointer to data member.
395
 
396
@item TYPE_PTR_P
397
This predicate holds if the type is a pointer type, and the pointee is
398
not a data member.
399
 
400
@item TYPE_PTRFN_P
401
This predicate holds for a pointer to function type.
402
 
403
@item TYPE_PTROB_P
404
This predicate holds for a pointer to object type.  Note however that it
405
does not hold for the generic pointer to object type @code{void *}.  You
406
may use @code{TYPE_PTROBV_P} to test for a pointer to object type as
407
well as @code{void *}.
408
 
409
@item same_type_p
410
This predicate takes two types as input, and holds if they are the same
411
type.  For example, if one type is a @code{typedef} for the other, or
412
both are @code{typedef}s for the same type.  This predicate also holds if
413
the two trees given as input are simply copies of one another; i.e.,
414
there is no difference between them at the source level, but, for
415
whatever reason, a duplicate has been made in the representation.  You
416
should never use @code{==} (pointer equality) to compare types; always
417
use @code{same_type_p} instead.
418
@end ftable
419
 
420
Detailed below are the various kinds of types, and the macros that can
421
be used to access them.  Although other kinds of types are used
422
elsewhere in G++, the types described here are the only ones that you
423
will encounter while examining the intermediate representation.
424
 
425
@table @code
426
@item VOID_TYPE
427
Used to represent the @code{void} type.
428
 
429
@item INTEGER_TYPE
430
Used to represent the various integral types, including @code{char},
431
@code{short}, @code{int}, @code{long}, and @code{long long}.  This code
432
is not used for enumeration types, nor for the @code{bool} type.
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.
441
 
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.
446
 
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.
451
 
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.
455
 
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}.
463
 
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.
472
 
473
@item BOOLEAN_TYPE
474
Used to represent the @code{bool} type.
475
 
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}.
483
 
484
@item REFERENCE_TYPE
485
Used to represent reference types.  The @code{TREE_TYPE} gives the type
486
to which this type refers.
487
 
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.
499
 
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}.
503
 
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.
511
 
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.
522
 
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}.
536
 
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.
541
 
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}.
551
 
552
@item UNKNOWN_TYPE
553
This node is used to represent a type the knowledge of which is
554
insufficient for a sound processing.
555
 
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}.
560
 
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.
570
 
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
576
 
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}.
582
 
583
@item integer_type_node
584
A node for @code{int}.
585
 
586
@item unsigned_type_node.
587
A node for @code{unsigned int}.
588
 
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}.
595
 
596
@c ---------------------------------------------------------------------
597
@c Scopes
598
@c ---------------------------------------------------------------------
599
 
600
@node Scopes
601
@section Scopes
602
@cindex namespace, class, scope
603
 
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.
608
 
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.)
614
 
615
@menu
616
* Namespaces::          Member functions, types, etc.
617
* Classes::             Members, bases, friends, etc.
618
@end menu
619
 
620
@c ---------------------------------------------------------------------
621
@c Namespaces
622
@c ---------------------------------------------------------------------
623
 
624
@node Namespaces
625
@subsection Namespaces
626
@cindex namespace
627
@tindex NAMESPACE_DECL
628
 
629
A namespace is represented by a @code{NAMESPACE_DECL} node.
630
 
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.
635
 
636
The following macros and functions can be used on a @code{NAMESPACE_DECL}:
637
 
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.
649
 
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}.
653
 
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.
658
 
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.
663
 
664
@item DECL_NAMESPACE_STD_P
665
This predicate holds if the namespace is the special @code{::std}
666
namespace.
667
 
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.
674
 
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.
682
 
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.
687
 
688
This function cannot be used with namespaces that have
689
@code{DECL_NAMESPACE_ALIAS} set.
690
 
691
@end ftable
692
 
693
@c ---------------------------------------------------------------------
694
@c Classes
695
@c ---------------------------------------------------------------------
696
 
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
708
 
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.
717
 
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.
731
 
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.
737
 
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.
745
 
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}.
763
 
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}.
768
 
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.
773
 
774
The following macros can be used on a tree node representing a class-type.
775
 
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.
780
 
781
@item TYPE_POLYMORPHIC_P
782
This predicate holds if the class has at least one virtual function
783
(declared or inherited).
784
 
785
@item TYPE_HAS_DEFAULT_CONSTRUCTOR
786
This predicate holds whenever its argument represents a class-type with
787
default constructor.
788
 
789
@item CLASSTYPE_HAS_MUTABLE
790
@itemx TYPE_HAS_MUTABLE_P
791
These predicates hold for a class-type having a mutable data member.
792
 
793
@item CLASSTYPE_NON_POD_P
794
This predicate holds only for class-types that are not PODs.
795
 
796
@item TYPE_HAS_NEW_OPERATOR
797
This predicate holds for a class-type that defines
798
@code{operator new}.
799
 
800
@item TYPE_HAS_ARRAY_NEW_OPERATOR
801
This predicate holds for a class-type for which
802
@code{operator new[]} is defined.
803
 
804
@item TYPE_OVERLOADS_CALL_EXPR
805
This predicate holds for class-type for which the function call
806
@code{operator()} is overloaded.
807
 
808
@item TYPE_OVERLOADS_ARRAY_REF
809
This predicate holds for a class-type that overloads
810
@code{operator[]}
811
 
812
@item TYPE_OVERLOADS_ARROW
813
This predicate holds for a class-type for which @code{operator->} is
814
overloaded.
815
 
816
@end ftable
817
 
818
@c ---------------------------------------------------------------------
819
@c Declarations
820
@c ---------------------------------------------------------------------
821
 
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
843
 
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}.
848
 
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
854
 
855
@node Working with declarations
856
@subsection Working with declarations
857
 
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.
863
 
864
@item TREE_TYPE
865
This macro returns the type of the entity declared.
866
 
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>"}.
872
 
873
@item TREE_LINENO
874
This macro returns the line number at which the entity was declared, as
875
an @code{int}.
876
 
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.
893
 
894
@item DECL_NAMESPACE_SCOPE_P
895
This predicate holds if the entity was declared at a namespace scope.
896
 
897
@item DECL_CLASS_SCOPE_P
898
This predicate holds if the entity was declared at a class scope.
899
 
900
@item DECL_FUNCTION_SCOPE_P
901
This predicate holds if the entity was declared inside a function
902
body.
903
 
904
@end ftable
905
 
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.
912
 
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}.
918
 
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}.
925
 
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.
930
 
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.
942
 
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.
949
 
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.
956
 
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}.
961
 
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}.
967
 
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.
979
 
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.
984
 
985
@item NAMESPACE_DECL
986
@xref{Namespaces}.
987
 
988
@item TEMPLATE_DECL
989
 
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.
998
 
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.
1003
 
1004
@item USING_DECL
1005
 
1006
Back ends can safely ignore these nodes.
1007
 
1008
@end table
1009
 
1010
@node Internal structure
1011
@subsection Internal structure
1012
 
1013
@code{DECL} nodes are represented internally as a hierarchy of
1014
structures.
1015
 
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
1022
 
1023
@node Current structure hierarchy
1024
@subsubsection Current structure hierarchy
1025
 
1026
@table @code
1027
 
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.
1032
 
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.
1037
 
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}.
1041
 
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}.
1045
 
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}.
1049
 
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.
1054
 
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}.
1058
 
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}.
1062
 
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}.
1066
 
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.
1071
 
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}.
1075
 
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}.
1079
 
1080
@end table
1081
@node Adding new DECL node types
1082
@subsubsection Adding new DECL node types
1083
 
1084
Adding a new @code{DECL} tree consists of the following steps
1085
 
1086
@table @asis
1087
 
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}.
1093
 
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.
1097
 
1098
@smallexample
1099
struct tree_foo_decl
1100
@{
1101
   struct tree_decl_with_vis common;
1102
@}
1103
@end smallexample
1104
 
1105
Would create a structure name @code{tree_foo_decl} that inherits from
1106
@code{struct tree_decl_with_vis}.
1107
 
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}.
1112
 
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}.
1121
 
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}.
1132
 
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.
1141
 
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
1158
 
1159
For @code{DECL} nodes that are part of the middle-end, the setup code
1160
goes into @file{tree.c}.
1161
 
1162
@item Add macros to access any new fields and flags
1163
 
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.
1167
 
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
1179
 
1180
@end table
1181
 
1182
 
1183
@c ---------------------------------------------------------------------
1184
@c Functions
1185
@c ---------------------------------------------------------------------
1186
 
1187
@node Functions
1188
@section Functions
1189
@cindex function
1190
@tindex FUNCTION_DECL
1191
@tindex OVERLOAD
1192
@findex OVL_CURRENT
1193
@findex OVL_NEXT
1194
 
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.
1197
 
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}.
1209
 
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.
1217
 
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}.
1228
 
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.
1240
 
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
1245
 
1246
@c ---------------------------------------------------------------------
1247
@c Function Basics
1248
@c ---------------------------------------------------------------------
1249
 
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
1270
 
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}.
1276
 
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.
1286
 
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.)
1296
 
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.
1303
 
1304
@item DECL_EXTERNAL
1305
This predicate holds if the function is undefined.
1306
 
1307
@item TREE_PUBLIC
1308
This predicate holds if the function has external linkage.
1309
 
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.
1313
 
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.
1317
 
1318
@item DECL_EXTERN_C_FUNCTION_P
1319
This predicate holds if the function is declared as an
1320
`@code{extern "C"}' function.
1321
 
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.
1329
 
1330
FIXME: This macro is not yet implemented.
1331
 
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.
1335
 
1336
@item DECL_STATIC_FUNCTION_P
1337
This predicate holds if the function a static member function.
1338
 
1339
@item DECL_NONSTATIC_MEMBER_FUNCTION_P
1340
This macro holds for a non-static member function.
1341
 
1342
@item DECL_CONST_MEMFUNC_P
1343
This predicate holds for a @code{const}-member function.
1344
 
1345
@item DECL_VOLATILE_MEMFUNC_P
1346
This predicate holds for a @code{volatile}-member function.
1347
 
1348
@item DECL_CONSTRUCTOR_P
1349
This macro holds if the function is a constructor.
1350
 
1351
@item DECL_NONCONVERTING_P
1352
This predicate holds if the constructor is a non-converting constructor.
1353
 
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.
1357
 
1358
@item DECL_BASE_CONSTRUCTOR_P
1359
This predicate holds for a function which is a constructor for a base
1360
class sub-object.
1361
 
1362
@item DECL_COPY_CONSTRUCTOR_P
1363
This predicate holds for a function which is a copy-constructor.
1364
 
1365
@item DECL_DESTRUCTOR_P
1366
This macro holds if the function is a destructor.
1367
 
1368
@item DECL_COMPLETE_DESTRUCTOR_P
1369
This predicate holds if the function is the destructor for an object a
1370
complete type.
1371
 
1372
@item DECL_OVERLOADED_OPERATOR_P
1373
This macro holds if the function is an overloaded operator.
1374
 
1375
@item DECL_CONV_FN_P
1376
This macro holds if the function is a type-conversion operator.
1377
 
1378
@item DECL_GLOBAL_CTOR_P
1379
This predicate holds if the function is a file-scope initialization
1380
function.
1381
 
1382
@item DECL_GLOBAL_DTOR_P
1383
This predicate holds if the function is a file-scope finalization
1384
function.
1385
 
1386
@item DECL_THUNK_P
1387
This predicate holds if the function is a thunk.
1388
 
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}.)
1396
 
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:
1400
 
1401
@smallexample
1402
this += THUNK_DELTA
1403
if (THUNK_VCALL_OFFSET)
1404
  this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET]
1405
@end smallexample
1406
 
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.
1410
 
1411
@item DECL_NON_THUNK_FUNCTION_P
1412
This predicate holds if the function is @emph{not} a thunk function.
1413
 
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.
1421
 
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.
1428
 
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.
1433
 
1434
@item DECL_RESULT
1435
This macro returns the @code{RESULT_DECL} for the function.
1436
 
1437
@item TREE_TYPE
1438
This macro returns the @code{FUNCTION_TYPE} or @code{METHOD_TYPE} for
1439
the function.
1440
 
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.
1445
 
1446
@item TYPE_NOTHROW_P
1447
This predicate holds when the exception-specification of its arguments
1448
if of the form `@code{()}'.
1449
 
1450
@item DECL_ARRAY_DELETE_OPERATOR_P
1451
This predicate holds if the function an overloaded
1452
@code{operator delete[]}.
1453
 
1454
@end ftable
1455
 
1456
@c ---------------------------------------------------------------------
1457
@c Function Bodies
1458
@c ---------------------------------------------------------------------
1459
 
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
1503
 
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}.
1507
 
1508
The @code{DECL_SAVED_TREE} macro will give the complete body of the
1509
function.
1510
 
1511
@subsubsection Statements
1512
 
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:
1518
 
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.
1527
 
1528
@end ftable
1529
 
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.
1535
 
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;
1547
@{
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;
1556
 
1557
        @dots{}
1558
        @}
1559
 
1560
      stmt = TREE_CHAIN (stmt);
1561
    @}
1562
@}
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.
1568
 
1569
@table @code
1570
@item ASM_EXPR
1571
 
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.
1593
 
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}.
1598
 
1599
@item BREAK_STMT
1600
 
1601
Used to represent a @code{break} statement.  There are no additional
1602
fields.
1603
 
1604
@item CASE_LABEL_EXPR
1605
 
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.
1613
 
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}.
1622
 
1623
@item CLEANUP_STMT
1624
 
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.
1634
 
1635
@item CONTINUE_STMT
1636
 
1637
Used to represent a @code{continue} statement.  There are no additional
1638
fields.
1639
 
1640
@item CTOR_STMT
1641
 
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.
1645
 
1646
@item DECL_STMT
1647
 
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}.
1655
 
1656
@item DO_STMT
1657
 
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.
1662
 
1663
@item EMPTY_CLASS_EXPR
1664
 
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.
1668
 
1669
@item EXPR_STMT
1670
 
1671
Used to represent an expression statement.  Use @code{EXPR_STMT_EXPR} to
1672
obtain the expression.
1673
 
1674
@item FOR_STMT
1675
 
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.
1684
 
1685
@item GOTO_EXPR
1686
 
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.
1691
 
1692
@item HANDLER
1693
 
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.
1699
 
1700
@item IF_STMT
1701
 
1702
Used to represent an @code{if} statement.  The @code{IF_COND} is the
1703
expression.
1704
 
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:
1710
 
1711
@smallexample
1712
if (int i = 7) @dots{}
1713
@end smallexample
1714
 
1715
where there is a new local variable (or variables) declared within the
1716
condition.
1717
 
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.
1721
 
1722
@item LABEL_EXPR
1723
 
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}.
1728
 
1729
@item RETURN_STMT
1730
 
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
1737
 
1738
@item SUBOBJECT
1739
 
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.
1745
 
1746
@item SWITCH_STMT
1747
 
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.
1754
 
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}.
1762
 
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.
1769
 
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.
1775
 
1776
@item WHILE_STMT
1777
 
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.
1782
 
1783
The @code{WHILE_BODY} is the body of the loop.
1784
 
1785
@end table
1786
 
1787
@c ---------------------------------------------------------------------
1788
@c Attributes
1789
@c ---------------------------------------------------------------------
1790
@node Attributes
1791
@section Attributes in trees
1792
@cindex attributes
1793
 
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.
1804
 
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.
1809
 
1810
@deftypefn {Tree Macro} tree DECL_ATTRIBUTES (tree @var{decl})
1811
This macro returns the attributes on the declaration @var{decl}.
1812
@end deftypefn
1813
 
1814
@deftypefn {Tree Macro} tree TYPE_ATTRIBUTES (tree @var{type})
1815
This macro returns the attributes on the type @var{type}.
1816
@end deftypefn
1817
 
1818
@c ---------------------------------------------------------------------
1819
@c Expressions
1820
@c ---------------------------------------------------------------------
1821
 
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
 
1932
The internal representation for expressions is for the most part quite
1933
straightforward.  However, there are a few facts that one must bear in
1934
mind.  In particular, the expression ``tree'' is actually a directed
1935
acyclic graph.  (For example there may be many references to the integer
1936
constant zero throughout the source program; many of these will be
1937
represented by the same expression node.)  You should not rely on
1938
certain kinds of node being shared, nor should rely on certain kinds of
1939
nodes being unshared.
1940
 
1941
The following macros can be used with all expression nodes:
1942
 
1943
@ftable @code
1944
@item TREE_TYPE
1945
Returns the type of the expression.  This value may not be precisely the
1946
same type that would be given the expression in the original program.
1947
@end ftable
1948
 
1949
In what follows, some nodes that one might expect to always have type
1950
@code{bool} are documented to have either integral or boolean type.  At
1951
some point in the future, the C front end may also make use of this same
1952
intermediate representation, and at this point these nodes will
1953
certainly have integral type.  The previous sentence is not meant to
1954
imply that the C++ front end does not or will not give these nodes
1955
integral type.
1956
 
1957
Below, we list the various kinds of expression nodes.  Except where
1958
noted otherwise, the operands to an expression are accessed using the
1959
@code{TREE_OPERAND} macro.  For example, to access the first operand to
1960
a binary plus expression @code{expr}, use:
1961
 
1962
@smallexample
1963
TREE_OPERAND (expr, 0)
1964
@end smallexample
1965
@noindent
1966
As this example indicates, the operands are zero-indexed.
1967
 
1968
All the expressions starting with @code{OMP_} represent directives and
1969
clauses used by the OpenMP API @w{@uref{http://www.openmp.org/}}.
1970
 
1971
The table below begins with constants, moves on to unary expressions,
1972
then proceeds to binary expressions, and concludes with various other
1973
kinds of expressions:
1974
 
1975
@table @code
1976
@item INTEGER_CST
1977
These nodes represent integer constants.  Note that the type of these
1978
constants is obtained with @code{TREE_TYPE}; they are not always of type
1979
@code{int}.  In particular, @code{char} constants are represented with
1980
@code{INTEGER_CST} nodes.  The value of the integer constant @code{e} is
1981
given by
1982
@smallexample
1983
((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT)
1984
+ TREE_INST_CST_LOW (e))
1985
@end smallexample
1986
@noindent
1987
HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms.  Both
1988
@code{TREE_INT_CST_HIGH} and @code{TREE_INT_CST_LOW} return a
1989
@code{HOST_WIDE_INT}.  The value of an @code{INTEGER_CST} is interpreted
1990
as a signed or unsigned quantity depending on the type of the constant.
1991
In general, the expression given above will overflow, so it should not
1992
be used to calculate the value of the constant.
1993
 
1994
The variable @code{integer_zero_node} is an integer constant with value
1995
zero.  Similarly, @code{integer_one_node} is an integer constant with
1996
value one.  The @code{size_zero_node} and @code{size_one_node} variables
1997
are analogous, but have type @code{size_t} rather than @code{int}.
1998
 
1999
The function @code{tree_int_cst_lt} is a predicate which holds if its
2000
first argument is less than its second.  Both constants are assumed to
2001
have the same signedness (i.e., either both should be signed or both
2002
should be unsigned.)  The full width of the constant is used when doing
2003
the comparison; the usual rules about promotions and conversions are
2004
ignored.  Similarly, @code{tree_int_cst_equal} holds if the two
2005
constants are equal.  The @code{tree_int_cst_sgn} function returns the
2006
sign of a constant.  The value is @code{1}, @code{0}, or @code{-1}
2007
according on whether the constant is greater than, equal to, or less
2008
than zero.  Again, the signedness of the constant's type is taken into
2009
account; an unsigned constant is never less than zero, no matter what
2010
its bit-pattern.
2011
 
2012
@item REAL_CST
2013
 
2014
FIXME: Talk about how to obtain representations of this constant, do
2015
comparisons, and so forth.
2016
 
2017
@item COMPLEX_CST
2018
These nodes are used to represent complex number constants, that is a
2019
@code{__complex__} whose parts are constant nodes.  The
2020
@code{TREE_REALPART} and @code{TREE_IMAGPART} return the real and the
2021
imaginary parts respectively.
2022
 
2023
@item VECTOR_CST
2024
These nodes are used to represent vector constants, whose parts are
2025
constant nodes.  Each individual constant node is either an integer or a
2026
double constant node.  The first operand is a @code{TREE_LIST} of the
2027
constant nodes and is accessed through @code{TREE_VECTOR_CST_ELTS}.
2028
 
2029
@item STRING_CST
2030
These nodes represent string-constants.  The @code{TREE_STRING_LENGTH}
2031
returns the length of the string, as an @code{int}.  The
2032
@code{TREE_STRING_POINTER} is a @code{char*} containing the string
2033
itself.  The string may not be @code{NUL}-terminated, and it may contain
2034
embedded @code{NUL} characters.  Therefore, the
2035
@code{TREE_STRING_LENGTH} includes the trailing @code{NUL} if it is
2036
present.
2037
 
2038
For wide string constants, the @code{TREE_STRING_LENGTH} is the number
2039
of bytes in the string, and the @code{TREE_STRING_POINTER}
2040
points to an array of the bytes of the string, as represented on the
2041
target system (that is, as integers in the target endianness).  Wide and
2042
non-wide string constants are distinguished only by the @code{TREE_TYPE}
2043
of the @code{STRING_CST}.
2044
 
2045
FIXME: The formats of string constants are not well-defined when the
2046
target system bytes are not the same width as host system bytes.
2047
 
2048
@item PTRMEM_CST
2049
These nodes are used to represent pointer-to-member constants.  The
2050
@code{PTRMEM_CST_CLASS} is the class type (either a @code{RECORD_TYPE}
2051
or @code{UNION_TYPE} within which the pointer points), and the
2052
@code{PTRMEM_CST_MEMBER} is the declaration for the pointed to object.
2053
Note that the @code{DECL_CONTEXT} for the @code{PTRMEM_CST_MEMBER} is in
2054
general different from the @code{PTRMEM_CST_CLASS}.  For example,
2055
given:
2056
@smallexample
2057
struct B @{ int i; @};
2058
struct D : public B @{@};
2059
int D::*dp = &D::i;
2060
@end smallexample
2061
@noindent
2062
The @code{PTRMEM_CST_CLASS} for @code{&D::i} is @code{D}, even though
2063
the @code{DECL_CONTEXT} for the @code{PTRMEM_CST_MEMBER} is @code{B},
2064
since @code{B::i} is a member of @code{B}, not @code{D}.
2065
 
2066
@item VAR_DECL
2067
 
2068
These nodes represent variables, including static data members.  For
2069
more information, @pxref{Declarations}.
2070
 
2071
@item NEGATE_EXPR
2072
These nodes represent unary negation of the single operand, for both
2073
integer and floating-point types.  The type of negation can be
2074
determined by looking at the type of the expression.
2075
 
2076
The behavior of this operation on signed arithmetic overflow is
2077
controlled by the @code{flag_wrapv} and @code{flag_trapv} variables.
2078
 
2079
@item ABS_EXPR
2080
These nodes represent the absolute value of the single operand, for
2081
both integer and floating-point types.  This is typically used to
2082
implement the @code{abs}, @code{labs} and @code{llabs} builtins for
2083
integer types, and the @code{fabs}, @code{fabsf} and @code{fabsl}
2084
builtins for floating point types.  The type of abs operation can
2085
be determined by looking at the type of the expression.
2086
 
2087
This node is not used for complex types.  To represent the modulus
2088
or complex abs of a complex value, use the @code{BUILT_IN_CABS},
2089
@code{BUILT_IN_CABSF} or @code{BUILT_IN_CABSL} builtins, as used
2090
to implement the C99 @code{cabs}, @code{cabsf} and @code{cabsl}
2091
built-in functions.
2092
 
2093
@item BIT_NOT_EXPR
2094
These nodes represent bitwise complement, and will always have integral
2095
type.  The only operand is the value to be complemented.
2096
 
2097
@item TRUTH_NOT_EXPR
2098
These nodes represent logical negation, and will always have integral
2099
(or boolean) type.  The operand is the value being negated.  The type
2100
of the operand and that of the result are always of @code{BOOLEAN_TYPE}
2101
or @code{INTEGER_TYPE}.
2102
 
2103
@item PREDECREMENT_EXPR
2104
@itemx PREINCREMENT_EXPR
2105
@itemx POSTDECREMENT_EXPR
2106
@itemx POSTINCREMENT_EXPR
2107
These nodes represent increment and decrement expressions.  The value of
2108
the single operand is computed, and the operand incremented or
2109
decremented.  In the case of @code{PREDECREMENT_EXPR} and
2110
@code{PREINCREMENT_EXPR}, the value of the expression is the value
2111
resulting after the increment or decrement; in the case of
2112
@code{POSTDECREMENT_EXPR} and @code{POSTINCREMENT_EXPR} is the value
2113
before the increment or decrement occurs.  The type of the operand, like
2114
that of the result, will be either integral, boolean, or floating-point.
2115
 
2116
@item ADDR_EXPR
2117
These nodes are used to represent the address of an object.  (These
2118
expressions will always have pointer or reference type.)  The operand may
2119
be another expression, or it may be a declaration.
2120
 
2121
As an extension, GCC allows users to take the address of a label.  In
2122
this case, the operand of the @code{ADDR_EXPR} will be a
2123
@code{LABEL_DECL}.  The type of such an expression is @code{void*}.
2124
 
2125
If the object addressed is not an lvalue, a temporary is created, and
2126
the address of the temporary is used.
2127
 
2128
@item INDIRECT_REF
2129
These nodes are used to represent the object pointed to by a pointer.
2130
The operand is the pointer being dereferenced; it will always have
2131
pointer or reference type.
2132
 
2133
@item FIX_TRUNC_EXPR
2134
These nodes represent conversion of a floating-point value to an
2135
integer.  The single operand will have a floating-point type, while
2136
the complete expression will have an integral (or boolean) type.  The
2137
operand is rounded towards zero.
2138
 
2139
@item FLOAT_EXPR
2140
These nodes represent conversion of an integral (or boolean) value to a
2141
floating-point value.  The single operand will have integral type, while
2142
the complete expression will have a floating-point type.
2143
 
2144
FIXME: How is the operand supposed to be rounded?  Is this dependent on
2145
@option{-mieee}?
2146
 
2147
@item COMPLEX_EXPR
2148
These nodes are used to represent complex numbers constructed from two
2149
expressions of the same (integer or real) type.  The first operand is the
2150
real part and the second operand is the imaginary part.
2151
 
2152
@item CONJ_EXPR
2153
These nodes represent the conjugate of their operand.
2154
 
2155
@item REALPART_EXPR
2156
@itemx IMAGPART_EXPR
2157
These nodes represent respectively the real and the imaginary parts
2158
of complex numbers (their sole argument).
2159
 
2160
@item NON_LVALUE_EXPR
2161
These nodes indicate that their one and only operand is not an lvalue.
2162
A back end can treat these identically to the single operand.
2163
 
2164
@item NOP_EXPR
2165
These nodes are used to represent conversions that do not require any
2166
code-generation.  For example, conversion of a @code{char*} to an
2167
@code{int*} does not require any code be generated; such a conversion is
2168
represented by a @code{NOP_EXPR}.  The single operand is the expression
2169
to be converted.  The conversion from a pointer to a reference is also
2170
represented with a @code{NOP_EXPR}.
2171
 
2172
@item CONVERT_EXPR
2173
These nodes are similar to @code{NOP_EXPR}s, but are used in those
2174
situations where code may need to be generated.  For example, if an
2175
@code{int*} is converted to an @code{int} code may need to be generated
2176
on some platforms.  These nodes are never used for C++-specific
2177
conversions, like conversions between pointers to different classes in
2178
an inheritance hierarchy.  Any adjustments that need to be made in such
2179
cases are always indicated explicitly.  Similarly, a user-defined
2180
conversion is never represented by a @code{CONVERT_EXPR}; instead, the
2181
function calls are made explicit.
2182
 
2183
@item THROW_EXPR
2184
These nodes represent @code{throw} expressions.  The single operand is
2185
an expression for the code that should be executed to throw the
2186
exception.  However, there is one implicit action not represented in
2187
that expression; namely the call to @code{__throw}.  This function takes
2188
no arguments.  If @code{setjmp}/@code{longjmp} exceptions are used, the
2189
function @code{__sjthrow} is called instead.  The normal GCC back end
2190
uses the function @code{emit_throw} to generate this code; you can
2191
examine this function to see what needs to be done.
2192
 
2193
@item LSHIFT_EXPR
2194
@itemx RSHIFT_EXPR
2195
These nodes represent left and right shifts, respectively.  The first
2196
operand is the value to shift; it will always be of integral type.  The
2197
second operand is an expression for the number of bits by which to
2198
shift.  Right shift should be treated as arithmetic, i.e., the
2199
high-order bits should be zero-filled when the expression has unsigned
2200
type and filled with the sign bit when the expression has signed type.
2201
Note that the result is undefined if the second operand is larger
2202
than or equal to the first operand's type size.
2203
 
2204
 
2205
@item BIT_IOR_EXPR
2206
@itemx BIT_XOR_EXPR
2207
@itemx BIT_AND_EXPR
2208
These nodes represent bitwise inclusive or, bitwise exclusive or, and
2209
bitwise and, respectively.  Both operands will always have integral
2210
type.
2211
 
2212
@item TRUTH_ANDIF_EXPR
2213
@itemx TRUTH_ORIF_EXPR
2214
These nodes represent logical and and logical or, respectively.  These
2215
operators are not strict; i.e., the second operand is evaluated only if
2216
the value of the expression is not determined by evaluation of the first
2217
operand.  The type of the operands and that of the result are always of
2218
@code{BOOLEAN_TYPE} or @code{INTEGER_TYPE}.
2219
 
2220
@item TRUTH_AND_EXPR
2221
@itemx TRUTH_OR_EXPR
2222
@itemx TRUTH_XOR_EXPR
2223
These nodes represent logical and, logical or, and logical exclusive or.
2224
They are strict; both arguments are always evaluated.  There are no
2225
corresponding operators in C or C++, but the front end will sometimes
2226
generate these expressions anyhow, if it can tell that strictness does
2227
not matter.  The type of the operands and that of the result are
2228
always of @code{BOOLEAN_TYPE} or @code{INTEGER_TYPE}.
2229
 
2230
@itemx PLUS_EXPR
2231
@itemx MINUS_EXPR
2232
@itemx MULT_EXPR
2233
These nodes represent various binary arithmetic operations.
2234
Respectively, these operations are addition, subtraction (of the second
2235
operand from the first) and multiplication.  Their operands may have
2236
either integral or floating type, but there will never be case in which
2237
one operand is of floating type and the other is of integral type.
2238
 
2239
The behavior of these operations on signed arithmetic overflow is
2240
controlled by the @code{flag_wrapv} and @code{flag_trapv} variables.
2241
 
2242
@item RDIV_EXPR
2243
This node represents a floating point division operation.
2244
 
2245
@item TRUNC_DIV_EXPR
2246
@itemx FLOOR_DIV_EXPR
2247
@itemx CEIL_DIV_EXPR
2248
@itemx ROUND_DIV_EXPR
2249
These nodes represent integer division operations that return an integer
2250
result.  @code{TRUNC_DIV_EXPR} rounds towards zero, @code{FLOOR_DIV_EXPR}
2251
rounds towards negative infinity, @code{CEIL_DIV_EXPR} rounds towards
2252
positive infinity and @code{ROUND_DIV_EXPR} rounds to the closest integer.
2253
Integer division in C and C++ is truncating, i.e.@: @code{TRUNC_DIV_EXPR}.
2254
 
2255
The behavior of these operations on signed arithmetic overflow, when
2256
dividing the minimum signed integer by minus one, is controlled by the
2257
@code{flag_wrapv} and @code{flag_trapv} variables.
2258
 
2259
@item TRUNC_MOD_EXPR
2260
@itemx FLOOR_MOD_EXPR
2261
@itemx CEIL_MOD_EXPR
2262
@itemx ROUND_MOD_EXPR
2263
These nodes represent the integer remainder or modulus operation.
2264
The integer modulus of two operands @code{a} and @code{b} is
2265
defined as @code{a - (a/b)*b} where the division calculated using
2266
the corresponding division operator.  Hence for @code{TRUNC_MOD_EXPR}
2267
this definition assumes division using truncation towards zero, i.e.@:
2268
@code{TRUNC_DIV_EXPR}.  Integer remainder in C and C++ uses truncating
2269
division, i.e.@: @code{TRUNC_MOD_EXPR}.
2270
 
2271
@item EXACT_DIV_EXPR
2272
The @code{EXACT_DIV_EXPR} code is used to represent integer divisions where
2273
the numerator is known to be an exact multiple of the denominator.  This
2274
allows the backend to choose between the faster of @code{TRUNC_DIV_EXPR},
2275
@code{CEIL_DIV_EXPR} and @code{FLOOR_DIV_EXPR} for the current target.
2276
 
2277
@item ARRAY_REF
2278
These nodes represent array accesses.  The first operand is the array;
2279
the second is the index.  To calculate the address of the memory
2280
accessed, you must scale the index by the size of the type of the array
2281
elements.  The type of these expressions must be the type of a component of
2282
the array.  The third and fourth operands are used after gimplification
2283
to represent the lower bound and component size but should not be used
2284
directly; call @code{array_ref_low_bound} and @code{array_ref_element_size}
2285
instead.
2286
 
2287
@item ARRAY_RANGE_REF
2288
These nodes represent access to a range (or ``slice'') of an array.  The
2289
operands are the same as that for @code{ARRAY_REF} and have the same
2290
meanings.  The type of these expressions must be an array whose component
2291
type is the same as that of the first operand.  The range of that array
2292
type determines the amount of data these expressions access.
2293
 
2294
@item TARGET_MEM_REF
2295
These nodes represent memory accesses whose address directly map to
2296
an addressing mode of the target architecture.  The first argument
2297
is @code{TMR_SYMBOL} and must be a @code{VAR_DECL} of an object with
2298
a fixed address.  The second argument is @code{TMR_BASE} and the
2299
third one is @code{TMR_INDEX}.  The fourth argument is
2300
@code{TMR_STEP} and must be an @code{INTEGER_CST}.  The fifth
2301
argument is @code{TMR_OFFSET} and must be an @code{INTEGER_CST}.
2302
Any of the arguments may be NULL if the appropriate component
2303
does not appear in the address.  Address of the @code{TARGET_MEM_REF}
2304
is determined in the following way.
2305
 
2306
@smallexample
2307
&TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET
2308
@end smallexample
2309
 
2310
The sixth argument is the reference to the original memory access, which
2311
is preserved for the purposes of the RTL alias analysis.  The seventh
2312
argument is a tag representing the results of tree level alias analysis.
2313
 
2314
@item LT_EXPR
2315
@itemx LE_EXPR
2316
@itemx GT_EXPR
2317
@itemx GE_EXPR
2318
@itemx EQ_EXPR
2319
@itemx NE_EXPR
2320
These nodes represent the less than, less than or equal to, greater
2321
than, greater than or equal to, equal, and not equal comparison
2322
operators.  The first and second operand with either be both of integral
2323
type or both of floating type.  The result type of these expressions
2324
will always be of integral or boolean type.  These operations return
2325
the result type's zero value for false, and the result type's one value
2326
for true.
2327
 
2328
For floating point comparisons, if we honor IEEE NaNs and either operand
2329
is NaN, then @code{NE_EXPR} always returns true and the remaining operators
2330
always return false.  On some targets, comparisons against an IEEE NaN,
2331
other than equality and inequality, may generate a floating point exception.
2332
 
2333
@item ORDERED_EXPR
2334
@itemx UNORDERED_EXPR
2335
These nodes represent non-trapping ordered and unordered comparison
2336
operators.  These operations take two floating point operands and
2337
determine whether they are ordered or unordered relative to each other.
2338
If either operand is an IEEE NaN, their comparison is defined to be
2339
unordered, otherwise the comparison is defined to be ordered.  The
2340
result type of these expressions will always be of integral or boolean
2341
type.  These operations return the result type's zero value for false,
2342
and the result type's one value for true.
2343
 
2344
@item UNLT_EXPR
2345
@itemx UNLE_EXPR
2346
@itemx UNGT_EXPR
2347
@itemx UNGE_EXPR
2348
@itemx UNEQ_EXPR
2349
@itemx LTGT_EXPR
2350
These nodes represent the unordered comparison operators.
2351
These operations take two floating point operands and determine whether
2352
the operands are unordered or are less than, less than or equal to,
2353
greater than, greater than or equal to, or equal respectively.  For
2354
example, @code{UNLT_EXPR} returns true if either operand is an IEEE
2355
NaN or the first operand is less than the second.  With the possible
2356
exception of @code{LTGT_EXPR}, all of these operations are guaranteed
2357
not to generate a floating point exception.  The result
2358
type of these expressions will always be of integral or boolean type.
2359
These operations return the result type's zero value for false,
2360
and the result type's one value for true.
2361
 
2362
@item MODIFY_EXPR
2363
These nodes represent assignment.  The left-hand side is the first
2364
operand; the right-hand side is the second operand.  The left-hand side
2365
will be a @code{VAR_DECL}, @code{INDIRECT_REF}, @code{COMPONENT_REF}, or
2366
other lvalue.
2367
 
2368
These nodes are used to represent not only assignment with @samp{=} but
2369
also compound assignments (like @samp{+=}), by reduction to @samp{=}
2370
assignment.  In other words, the representation for @samp{i += 3} looks
2371
just like that for @samp{i = i + 3}.
2372
 
2373
@item INIT_EXPR
2374
These nodes are just like @code{MODIFY_EXPR}, but are used only when a
2375
variable is initialized, rather than assigned to subsequently.  This
2376
means that we can assume that the target of the initialization is not
2377
used in computing its own value; any reference to the lhs in computing
2378
the rhs is undefined.
2379
 
2380
@item COMPONENT_REF
2381
These nodes represent non-static data member accesses.  The first
2382
operand is the object (rather than a pointer to it); the second operand
2383
is the @code{FIELD_DECL} for the data member.  The third operand represents
2384
the byte offset of the field, but should not be used directly; call
2385
@code{component_ref_field_offset} instead.
2386
 
2387
@item COMPOUND_EXPR
2388
These nodes represent comma-expressions.  The first operand is an
2389
expression whose value is computed and thrown away prior to the
2390
evaluation of the second operand.  The value of the entire expression is
2391
the value of the second operand.
2392
 
2393
@item COND_EXPR
2394
These nodes represent @code{?:} expressions.  The first operand
2395
is of boolean or integral type.  If it evaluates to a nonzero value,
2396
the second operand should be evaluated, and returned as the value of the
2397
expression.  Otherwise, the third operand is evaluated, and returned as
2398
the value of the expression.
2399
 
2400
The second operand must have the same type as the entire expression,
2401
unless it unconditionally throws an exception or calls a noreturn
2402
function, in which case it should have void type.  The same constraints
2403
apply to the third operand.  This allows array bounds checks to be
2404
represented conveniently as @code{(i >= 0 && i < 10) ? i : abort()}.
2405
 
2406
As a GNU extension, the C language front-ends allow the second
2407
operand of the @code{?:} operator may be omitted in the source.
2408
For example, @code{x ? : 3} is equivalent to @code{x ? x : 3},
2409
assuming that @code{x} is an expression without side-effects.
2410
In the tree representation, however, the second operand is always
2411
present, possibly protected by @code{SAVE_EXPR} if the first
2412
argument does cause side-effects.
2413
 
2414
@item CALL_EXPR
2415
These nodes are used to represent calls to functions, including
2416
non-static member functions.  The first operand is a pointer to the
2417
function to call; it is always an expression whose type is a
2418
@code{POINTER_TYPE}.  The second argument is a @code{TREE_LIST}.  The
2419
arguments to the call appear left-to-right in the list.  The
2420
@code{TREE_VALUE} of each list node contains the expression
2421
corresponding to that argument.  (The value of @code{TREE_PURPOSE} for
2422
these nodes is unspecified, and should be ignored.)  For non-static
2423
member functions, there will be an operand corresponding to the
2424
@code{this} pointer.  There will always be expressions corresponding to
2425
all of the arguments, even if the function is declared with default
2426
arguments and some arguments are not explicitly provided at the call
2427
sites.
2428
 
2429
@item STMT_EXPR
2430
These nodes are used to represent GCC's statement-expression extension.
2431
The statement-expression extension allows code like this:
2432
@smallexample
2433
int f() @{ return (@{ int j; j = 3; j + 7; @}); @}
2434
@end smallexample
2435
In other words, an sequence of statements may occur where a single
2436
expression would normally appear.  The @code{STMT_EXPR} node represents
2437
such an expression.  The @code{STMT_EXPR_STMT} gives the statement
2438
contained in the expression.  The value of the expression is the value
2439
of the last sub-statement in the body.  More precisely, the value is the
2440
value computed by the last statement nested inside @code{BIND_EXPR},
2441
@code{TRY_FINALLY_EXPR}, or @code{TRY_CATCH_EXPR}.  For example, in:
2442
@smallexample
2443
(@{ 3; @})
2444
@end smallexample
2445
the value is @code{3} while in:
2446
@smallexample
2447
(@{ if (x) @{ 3; @} @})
2448
@end smallexample
2449
there is no value.  If the @code{STMT_EXPR} does not yield a value,
2450
it's type will be @code{void}.
2451
 
2452
@item BIND_EXPR
2453
These nodes represent local blocks.  The first operand is a list of
2454
variables, connected via their @code{TREE_CHAIN} field.  These will
2455
never require cleanups.  The scope of these variables is just the body
2456
of the @code{BIND_EXPR}.  The body of the @code{BIND_EXPR} is the
2457
second operand.
2458
 
2459
@item LOOP_EXPR
2460
These nodes represent ``infinite'' loops.  The @code{LOOP_EXPR_BODY}
2461
represents the body of the loop.  It should be executed forever, unless
2462
an @code{EXIT_EXPR} is encountered.
2463
 
2464
@item EXIT_EXPR
2465
These nodes represent conditional exits from the nearest enclosing
2466
@code{LOOP_EXPR}.  The single operand is the condition; if it is
2467
nonzero, then the loop should be exited.  An @code{EXIT_EXPR} will only
2468
appear within a @code{LOOP_EXPR}.
2469
 
2470
@item CLEANUP_POINT_EXPR
2471
These nodes represent full-expressions.  The single operand is an
2472
expression to evaluate.  Any destructor calls engendered by the creation
2473
of temporaries during the evaluation of that expression should be
2474
performed immediately after the expression is evaluated.
2475
 
2476
@item CONSTRUCTOR
2477
These nodes represent the brace-enclosed initializers for a structure or
2478
array.  The first operand is reserved for use by the back end.  The
2479
second operand is a @code{TREE_LIST}.  If the @code{TREE_TYPE} of the
2480
@code{CONSTRUCTOR} is a @code{RECORD_TYPE} or @code{UNION_TYPE}, then
2481
the @code{TREE_PURPOSE} of each node in the @code{TREE_LIST} will be a
2482
@code{FIELD_DECL} and the @code{TREE_VALUE} of each node will be the
2483
expression used to initialize that field.
2484
 
2485
If the @code{TREE_TYPE} of the @code{CONSTRUCTOR} is an
2486
@code{ARRAY_TYPE}, then the @code{TREE_PURPOSE} of each element in the
2487
@code{TREE_LIST} will be an @code{INTEGER_CST} or a @code{RANGE_EXPR} of
2488
two @code{INTEGER_CST}s.  A single @code{INTEGER_CST} indicates which
2489
element of the array (indexed from zero) is being assigned to.  A
2490
@code{RANGE_EXPR} indicates an inclusive range of elements to
2491
initialize.  In both cases the @code{TREE_VALUE} is the corresponding
2492
initializer.  It is re-evaluated for each element of a
2493
@code{RANGE_EXPR}.  If the @code{TREE_PURPOSE} is @code{NULL_TREE}, then
2494
the initializer is for the next available array element.
2495
 
2496
In the front end, you should not depend on the fields appearing in any
2497
particular order.  However, in the middle end, fields must appear in
2498
declaration order.  You should not assume that all fields will be
2499
represented.  Unrepresented fields will be set to zero.
2500
 
2501
@item COMPOUND_LITERAL_EXPR
2502
@findex COMPOUND_LITERAL_EXPR_DECL_STMT
2503
@findex COMPOUND_LITERAL_EXPR_DECL
2504
These nodes represent ISO C99 compound literals.  The
2505
@code{COMPOUND_LITERAL_EXPR_DECL_STMT} is a @code{DECL_STMT}
2506
containing an anonymous @code{VAR_DECL} for
2507
the unnamed object represented by the compound literal; the
2508
@code{DECL_INITIAL} of that @code{VAR_DECL} is a @code{CONSTRUCTOR}
2509
representing the brace-enclosed list of initializers in the compound
2510
literal.  That anonymous @code{VAR_DECL} can also be accessed directly
2511
by the @code{COMPOUND_LITERAL_EXPR_DECL} macro.
2512
 
2513
@item SAVE_EXPR
2514
 
2515
A @code{SAVE_EXPR} represents an expression (possibly involving
2516
side-effects) that is used more than once.  The side-effects should
2517
occur only the first time the expression is evaluated.  Subsequent uses
2518
should just reuse the computed value.  The first operand to the
2519
@code{SAVE_EXPR} is the expression to evaluate.  The side-effects should
2520
be executed where the @code{SAVE_EXPR} is first encountered in a
2521
depth-first preorder traversal of the expression tree.
2522
 
2523
@item TARGET_EXPR
2524
A @code{TARGET_EXPR} represents a temporary object.  The first operand
2525
is a @code{VAR_DECL} for the temporary variable.  The second operand is
2526
the initializer for the temporary.  The initializer is evaluated and,
2527
if non-void, copied (bitwise) into the temporary.  If the initializer
2528
is void, that means that it will perform the initialization itself.
2529
 
2530
Often, a @code{TARGET_EXPR} occurs on the right-hand side of an
2531
assignment, or as the second operand to a comma-expression which is
2532
itself the right-hand side of an assignment, etc.  In this case, we say
2533
that the @code{TARGET_EXPR} is ``normal''; otherwise, we say it is
2534
``orphaned''.  For a normal @code{TARGET_EXPR} the temporary variable
2535
should be treated as an alias for the left-hand side of the assignment,
2536
rather than as a new temporary variable.
2537
 
2538
The third operand to the @code{TARGET_EXPR}, if present, is a
2539
cleanup-expression (i.e., destructor call) for the temporary.  If this
2540
expression is orphaned, then this expression must be executed when the
2541
statement containing this expression is complete.  These cleanups must
2542
always be executed in the order opposite to that in which they were
2543
encountered.  Note that if a temporary is created on one branch of a
2544
conditional operator (i.e., in the second or third operand to a
2545
@code{COND_EXPR}), the cleanup must be run only if that branch is
2546
actually executed.
2547
 
2548
See @code{STMT_IS_FULL_EXPR_P} for more information about running these
2549
cleanups.
2550
 
2551
@item AGGR_INIT_EXPR
2552
An @code{AGGR_INIT_EXPR} represents the initialization as the return
2553
value of a function call, or as the result of a constructor.  An
2554
@code{AGGR_INIT_EXPR} will only appear as a full-expression, or as the
2555
second operand of a @code{TARGET_EXPR}.  The first operand to the
2556
@code{AGGR_INIT_EXPR} is the address of a function to call, just as in
2557
a @code{CALL_EXPR}.  The second operand are the arguments to pass that
2558
function, as a @code{TREE_LIST}, again in a manner similar to that of
2559
a @code{CALL_EXPR}.
2560
 
2561
If @code{AGGR_INIT_VIA_CTOR_P} holds of the @code{AGGR_INIT_EXPR}, then
2562
the initialization is via a constructor call.  The address of the third
2563
operand of the @code{AGGR_INIT_EXPR}, which is always a @code{VAR_DECL},
2564
is taken, and this value replaces the first argument in the argument
2565
list.
2566
 
2567
In either case, the expression is void.
2568
 
2569
@item VA_ARG_EXPR
2570
This node is used to implement support for the C/C++ variable argument-list
2571
mechanism.  It represents expressions like @code{va_arg (ap, type)}.
2572
Its @code{TREE_TYPE} yields the tree representation for @code{type} and
2573
its sole argument yields the representation for @code{ap}.
2574
 
2575
@item OMP_PARALLEL
2576
 
2577
Represents @code{#pragma omp parallel [clause1 ... clauseN]}. It
2578
has four operands:
2579
 
2580
Operand @code{OMP_PARALLEL_BODY} is valid while in GENERIC and
2581
High GIMPLE forms.  It contains the body of code to be executed
2582
by all the threads.  During GIMPLE lowering, this operand becomes
2583
@code{NULL} and the body is emitted linearly after
2584
@code{OMP_PARALLEL}.
2585
 
2586
Operand @code{OMP_PARALLEL_CLAUSES} is the list of clauses
2587
associated with the directive.
2588
 
2589
Operand @code{OMP_PARALLEL_FN} is created by
2590
@code{pass_lower_omp}, it contains the @code{FUNCTION_DECL}
2591
for the function that will contain the body of the parallel
2592
region.
2593
 
2594
Operand @code{OMP_PARALLEL_DATA_ARG} is also created by
2595
@code{pass_lower_omp}. If there are shared variables to be
2596
communicated to the children threads, this operand will contain
2597
the @code{VAR_DECL} that contains all the shared values and
2598
variables.
2599
 
2600
@item OMP_FOR
2601
 
2602
Represents @code{#pragma omp for [clause1 ... clauseN]}.  It
2603
has 5 operands:
2604
 
2605
Operand @code{OMP_FOR_BODY} contains the loop body.
2606
 
2607
Operand @code{OMP_FOR_CLAUSES} is the list of clauses
2608
associated with the directive.
2609
 
2610
Operand @code{OMP_FOR_INIT} is the loop initialization code of
2611
the form @code{VAR = N1}.
2612
 
2613
Operand @code{OMP_FOR_COND} is the loop conditional expression
2614
of the form @code{VAR @{<,>,<=,>=@} N2}.
2615
 
2616
Operand @code{OMP_FOR_INCR} is the loop index increment of the
2617
form @code{VAR @{+=,-=@} INCR}.
2618
 
2619
Operand @code{OMP_FOR_PRE_BODY} contains side-effect code from
2620
operands @code{OMP_FOR_INIT}, @code{OMP_FOR_COND} and
2621
@code{OMP_FOR_INC}.  These side-effects are part of the
2622
@code{OMP_FOR} block but must be evaluated before the start of
2623
loop body.
2624
 
2625
The loop index variable @code{VAR} must be a signed integer variable,
2626
which is implicitly private to each thread.  Bounds
2627
@code{N1} and @code{N2} and the increment expression
2628
@code{INCR} are required to be loop invariant integer
2629
expressions that are evaluated without any synchronization. The
2630
evaluation order, frequency of evaluation and side-effects are
2631
unspecified by the standard.
2632
 
2633
@item OMP_SECTIONS
2634
 
2635
Represents @code{#pragma omp sections [clause1 ... clauseN]}.
2636
 
2637
Operand @code{OMP_SECTIONS_BODY} contains the sections body,
2638
which in turn contains a set of @code{OMP_SECTION} nodes for
2639
each of the concurrent sections delimited by @code{#pragma omp
2640
section}.
2641
 
2642
Operand @code{OMP_SECTIONS_CLAUSES} is the list of clauses
2643
associated with the directive.
2644
 
2645
@item OMP_SECTION
2646
 
2647
Section delimiter for @code{OMP_SECTIONS}.
2648
 
2649
@item OMP_SINGLE
2650
 
2651
Represents @code{#pragma omp single}.
2652
 
2653
Operand @code{OMP_SINGLE_BODY} contains the body of code to be
2654
executed by a single thread.
2655
 
2656
Operand @code{OMP_SINGLE_CLAUSES} is the list of clauses
2657
associated with the directive.
2658
 
2659
@item OMP_MASTER
2660
 
2661
Represents @code{#pragma omp master}.
2662
 
2663
Operand @code{OMP_MASTER_BODY} contains the body of code to be
2664
executed by the master thread.
2665
 
2666
@item OMP_ORDERED
2667
 
2668
Represents @code{#pragma omp ordered}.
2669
 
2670
Operand @code{OMP_ORDERED_BODY} contains the body of code to be
2671
executed in the sequential order dictated by the loop index
2672
variable.
2673
 
2674
@item OMP_CRITICAL
2675
 
2676
Represents @code{#pragma omp critical [name]}.
2677
 
2678
Operand @code{OMP_CRITICAL_BODY} is the critical section.
2679
 
2680
Operand @code{OMP_CRITICAL_NAME} is an optional identifier to
2681
label the critical section.
2682
 
2683
@item OMP_RETURN
2684
 
2685
This does not represent any OpenMP directive, it is an artificial
2686
marker to indicate the end of the body of an OpenMP. It is used
2687
by the flow graph (@code{tree-cfg.c}) and OpenMP region
2688
building code (@code{omp-low.c}).
2689
 
2690
@item OMP_CONTINUE
2691
 
2692
Similarly, this instruction does not represent an OpenMP
2693
directive, it is used by @code{OMP_FOR} and
2694
@code{OMP_SECTIONS} to mark the place where the code needs to
2695
loop to the next iteration (in the case of @code{OMP_FOR}) or
2696
the next section (in the case of @code{OMP_SECTIONS}).
2697
 
2698
In some cases, @code{OMP_CONTINUE} is placed right before
2699
@code{OMP_RETURN}.  But if there are cleanups that need to
2700
occur right after the looping body, it will be emitted between
2701
@code{OMP_CONTINUE} and @code{OMP_RETURN}.
2702
 
2703
@item OMP_ATOMIC
2704
 
2705
Represents @code{#pragma omp atomic}.
2706
 
2707
Operand 0 is the address at which the atomic operation is to be
2708
performed.
2709
 
2710
Operand 1 is the expression to evaluate.  The gimplifier tries
2711
three alternative code generation strategies.  Whenever possible,
2712
an atomic update built-in is used.  If that fails, a
2713
compare-and-swap loop is attempted.  If that also fails, a
2714
regular critical section around the expression is used.
2715
 
2716
@item OMP_CLAUSE
2717
 
2718
Represents clauses associated with one of the @code{OMP_} directives.
2719
Clauses are represented by separate sub-codes defined in
2720
@file{tree.h}.  Clauses codes can be one of:
2721
@code{OMP_CLAUSE_PRIVATE}, @code{OMP_CLAUSE_SHARED},
2722
@code{OMP_CLAUSE_FIRSTPRIVATE},
2723
@code{OMP_CLAUSE_LASTPRIVATE}, @code{OMP_CLAUSE_COPYIN},
2724
@code{OMP_CLAUSE_COPYPRIVATE}, @code{OMP_CLAUSE_IF},
2725
@code{OMP_CLAUSE_NUM_THREADS}, @code{OMP_CLAUSE_SCHEDULE},
2726
@code{OMP_CLAUSE_NOWAIT}, @code{OMP_CLAUSE_ORDERED},
2727
@code{OMP_CLAUSE_DEFAULT}, and @code{OMP_CLAUSE_REDUCTION}.  Each code
2728
represents the corresponding OpenMP clause.
2729
 
2730
Clauses associated with the same directive are chained together
2731
via @code{OMP_CLAUSE_CHAIN}. Those clauses that accept a list
2732
of variables are restricted to exactly one, accessed with
2733
@code{OMP_CLAUSE_VAR}.  Therefore, multiple variables under the
2734
same clause @code{C} need to be represented as multiple @code{C} clauses
2735
chained together.  This facilitates adding new clauses during
2736
compilation.
2737
 
2738
@end table

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.