]>
Commit | Line | Data |
---|---|---|
c63539ff ML |
1 | .. |
2 | Copyright 1988-2022 Free Software Foundation, Inc. | |
3 | This is part of the GCC manual. | |
4 | For copying conditions, see the copyright.rst file. | |
5 | ||
6 | .. _c-and-c++-trees: | |
7 | ||
8 | C and C++ Trees | |
9 | *************** | |
10 | ||
11 | This section documents the internal representation used by GCC to | |
12 | represent C and C++ source programs. When presented with a C or C++ | |
13 | source program, GCC parses the program, performs semantic analysis | |
14 | (including the generation of error messages), and then produces the | |
15 | internal representation described here. This representation contains a | |
16 | complete representation for the entire translation unit provided as | |
17 | input to the front end. This representation is then typically processed | |
18 | by a code-generator in order to produce machine code, but could also be | |
19 | used in the creation of source browsers, intelligent editors, automatic | |
20 | documentation generators, interpreters, and any other programs needing | |
21 | the ability to process C or C++ code. | |
22 | ||
23 | This section explains the internal representation. In particular, it | |
24 | documents the internal representation for C and C++ source | |
25 | constructs, and the macros, functions, and variables that can be used to | |
26 | access these constructs. The C++ representation is largely a superset | |
27 | of the representation used in the C front end. There is only one | |
28 | construct used in C that does not appear in the C++ front end and that | |
29 | is the GNU 'nested function' extension. Many of the macros documented | |
30 | here do not apply in C because the corresponding language constructs do | |
31 | not appear in C. | |
32 | ||
33 | The C and C++ front ends generate a mix of GENERIC trees and ones | |
34 | specific to C and C++. These language-specific trees are higher-level | |
35 | constructs than the ones in GENERIC to make the parser's job easier. | |
36 | This section describes those trees that aren't part of GENERIC as well | |
37 | as aspects of GENERIC trees that are treated in a language-specific | |
38 | manner. | |
39 | ||
40 | If you are developing a 'back end', be it is a code-generator or some | |
41 | other tool, that uses this representation, you may occasionally find | |
42 | that you need to ask questions not easily answered by the functions and | |
43 | macros available here. If that situation occurs, it is quite likely | |
44 | that GCC already supports the functionality you desire, but that the | |
45 | interface is simply not documented here. In that case, you should ask | |
46 | the GCC maintainers (via mail to gcc@gcc.gnu.org) about | |
47 | documenting the functionality you require. Similarly, if you find | |
48 | yourself writing functions that do not deal directly with your back end, | |
49 | but instead might be useful to other people using the GCC front end, you | |
50 | should submit your patches for inclusion in GCC. | |
51 | ||
52 | .. toctree:: | |
53 | :maxdepth: 2 | |
54 | ||
55 | ||
56 | .. _types-for-c++: | |
57 | ||
58 | Types for C++ | |
59 | ^^^^^^^^^^^^^ | |
60 | ||
61 | .. index:: UNKNOWN_TYPE, TYPENAME_TYPE, TYPEOF_TYPE, cp_type_quals, TYPE_UNQUALIFIED, TYPE_QUAL_CONST, TYPE_QUAL_VOLATILE, TYPE_QUAL_RESTRICT, TYPE_MAIN_VARIANT, qualified type, TYPE_SIZE, TYPE_ALIGN, TYPE_PRECISION, TYPE_ARG_TYPES, TYPE_METHOD_BASETYPE, TYPE_PTRDATAMEM_P, TYPE_OFFSET_BASETYPE, TREE_TYPE, TYPE_CONTEXT, TYPE_NAME, TYPENAME_TYPE_FULLNAME, TYPE_FIELDS, TYPE_PTROBV_P | |
62 | ||
63 | In C++, an array type is not qualified; rather the type of the array | |
64 | elements is qualified. This situation is reflected in the intermediate | |
65 | representation. The macros described here will always examine the | |
66 | qualification of the underlying element type when applied to an array | |
67 | type. (If the element type is itself an array, then the recursion | |
68 | continues until a non-array type is found, and the qualification of this | |
69 | type is examined.) So, for example, ``CP_TYPE_CONST_P`` will hold of | |
70 | the type ``const int ()[7]``, denoting an array of seven ``int`` s. | |
71 | ||
72 | The following functions and macros deal with cv-qualification of types: | |
73 | ||
74 | ``cp_type_quals`` | |
75 | This function returns the set of type qualifiers applied to this type. | |
76 | This value is ``TYPE_UNQUALIFIED`` if no qualifiers have been | |
77 | applied. The ``TYPE_QUAL_CONST`` bit is set if the type is | |
78 | ``const`` -qualified. The ``TYPE_QUAL_VOLATILE`` bit is set if the | |
79 | type is ``volatile`` -qualified. The ``TYPE_QUAL_RESTRICT`` bit is | |
80 | set if the type is ``restrict`` -qualified. | |
81 | ||
82 | .. envvar:: CP_TYPE_CONST_P | |
83 | ||
84 | This macro holds if the type is ``const`` -qualified. | |
85 | ||
86 | .. envvar:: CP_TYPE_VOLATILE_P | |
87 | ||
88 | This macro holds if the type is ``volatile`` -qualified. | |
89 | ||
90 | .. envvar:: CP_TYPE_RESTRICT_P | |
91 | ||
92 | This macro holds if the type is ``restrict`` -qualified. | |
93 | ||
94 | .. envvar:: CP_TYPE_CONST_NON_VOLATILE_P | |
95 | ||
96 | This predicate holds for a type that is ``const`` -qualified, but | |
97 | *not* ``volatile`` -qualified; other cv-qualifiers are ignored as | |
98 | well: only the ``const`` -ness is tested. | |
99 | ||
100 | A few other macros and functions are usable with all types: | |
101 | ||
102 | .. envvar:: TYPE_SIZE | |
103 | ||
104 | The number of bits required to represent the type, represented as an | |
105 | ``INTEGER_CST``. For an incomplete type, ``TYPE_SIZE`` will be | |
106 | ``NULL_TREE``. | |
107 | ||
108 | .. envvar:: TYPE_ALIGN | |
109 | ||
110 | The alignment of the type, in bits, represented as an ``int``. | |
111 | ||
112 | .. envvar:: TYPE_NAME | |
113 | ||
114 | This macro returns a declaration (in the form of a ``TYPE_DECL``) for | |
115 | the type. (Note this macro does *not* return an | |
116 | ``IDENTIFIER_NODE``, as you might expect, given its name!) You can | |
117 | look at the ``DECL_NAME`` of the ``TYPE_DECL`` to obtain the | |
118 | actual name of the type. The ``TYPE_NAME`` will be ``NULL_TREE`` | |
119 | for a type that is not a built-in type, the result of a typedef, or a | |
120 | named class type. | |
121 | ||
122 | .. envvar:: CP_INTEGRAL_TYPE | |
123 | ||
124 | This predicate holds if the type is an integral type. Notice that in | |
125 | C++, enumerations are *not* integral types. | |
126 | ||
127 | .. envvar:: ARITHMETIC_TYPE_P | |
128 | ||
129 | This predicate holds if the type is an integral type (in the C++ sense) | |
130 | or a floating point type. | |
131 | ||
132 | .. envvar:: CLASS_TYPE_P | |
133 | ||
134 | This predicate holds for a class-type. | |
135 | ||
136 | .. envvar:: TYPE_BUILT_IN | |
137 | ||
138 | This predicate holds for a built-in type. | |
139 | ||
140 | .. envvar:: TYPE_PTRDATAMEM_P | |
141 | ||
142 | This predicate holds if the type is a pointer to data member. | |
143 | ||
144 | .. envvar:: TYPE_PTR_P | |
145 | ||
146 | This predicate holds if the type is a pointer type, and the pointee is | |
147 | not a data member. | |
148 | ||
149 | .. envvar:: TYPE_PTRFN_P | |
150 | ||
151 | This predicate holds for a pointer to function type. | |
152 | ||
153 | .. envvar:: TYPE_PTROB_P | |
154 | ||
155 | This predicate holds for a pointer to object type. Note however that it | |
156 | does not hold for the generic pointer to object type ``void *``. You | |
157 | may use ``TYPE_PTROBV_P`` to test for a pointer to object type as | |
158 | well as ``void *``. | |
159 | ||
160 | The table below describes types specific to C and C++ as well as | |
161 | language-dependent info about GENERIC types. | |
162 | ||
163 | .. envvar:: POINTER_TYPE | |
164 | ||
165 | Used to represent pointer types, and pointer to data member types. If | |
166 | ``TREE_TYPE`` | |
167 | is a pointer to data member type, then ``TYPE_PTRDATAMEM_P`` will hold. | |
168 | For a pointer to data member type of the form :samp:`T X::*`, | |
169 | ``TYPE_PTRMEM_CLASS_TYPE`` will be the type ``X``, while | |
170 | ``TYPE_PTRMEM_POINTED_TO_TYPE`` will be the type ``T``. | |
171 | ||
172 | .. envvar:: RECORD_TYPE | |
173 | ||
174 | Used to represent ``struct`` and ``class`` types in C and C++. If | |
175 | ``TYPE_PTRMEMFUNC_P`` holds, then this type is a pointer-to-member | |
176 | type. In that case, the ``TYPE_PTRMEMFUNC_FN_TYPE`` is a | |
177 | ``POINTER_TYPE`` pointing to a ``METHOD_TYPE``. The | |
178 | ``METHOD_TYPE`` is the type of a function pointed to by the | |
179 | pointer-to-member function. If ``TYPE_PTRMEMFUNC_P`` does not hold, | |
180 | this type is a class type. For more information, see :ref:`classes`. | |
181 | ||
182 | .. envvar:: UNKNOWN_TYPE | |
183 | ||
184 | This node is used to represent a type the knowledge of which is | |
185 | insufficient for a sound processing. | |
186 | ||
187 | .. envvar:: TYPENAME_TYPE | |
188 | ||
189 | Used to represent a construct of the form ``typename T::A``. The | |
190 | ``TYPE_CONTEXT`` is ``T`` ; the ``TYPE_NAME`` is an | |
191 | ``IDENTIFIER_NODE`` for ``A``. If the type is specified via a | |
192 | template-id, then ``TYPENAME_TYPE_FULLNAME`` yields a | |
193 | ``TEMPLATE_ID_EXPR``. The ``TREE_TYPE`` is non- ``NULL`` if the | |
194 | node is implicitly generated in support for the implicit typename | |
195 | extension; in which case the ``TREE_TYPE`` is a type node for the | |
196 | base-class. | |
197 | ||
198 | .. envvar:: TYPEOF_TYPE | |
199 | ||
200 | Used to represent the ``__typeof__`` extension. The | |
201 | ``TYPE_FIELDS`` is the expression the type of which is being | |
202 | represented. | |
203 | ||
204 | .. - | |
205 | Namespaces | |
206 | - | |
207 | ||
208 | .. index:: namespace, scope | |
209 | ||
210 | .. _namespaces: | |
211 | ||
212 | Namespaces | |
213 | ^^^^^^^^^^ | |
214 | ||
215 | .. index:: NAMESPACE_DECL | |
216 | ||
217 | The root of the entire intermediate representation is the variable | |
218 | ``global_namespace``. This is the namespace specified with ``::`` | |
219 | in C++ source code. All other namespaces, types, variables, functions, | |
220 | and so forth can be found starting with this namespace. | |
221 | ||
222 | However, except for the fact that it is distinguished as the root of the | |
223 | representation, the global namespace is no different from any other | |
224 | namespace. Thus, in what follows, we describe namespaces generally, | |
225 | rather than the global namespace in particular. | |
226 | ||
227 | A namespace is represented by a ``NAMESPACE_DECL`` node. | |
228 | ||
229 | The following macros and functions can be used on a ``NAMESPACE_DECL`` : | |
230 | ||
231 | .. envvar:: DECL_NAME | |
232 | ||
233 | This macro is used to obtain the ``IDENTIFIER_NODE`` corresponding to | |
234 | the unqualified name of the name of the namespace (see :ref:`identifiers`). | |
235 | The name of the global namespace is :samp:`::`, even though in C++ the | |
236 | global namespace is unnamed. However, you should use comparison with | |
237 | ``global_namespace``, rather than ``DECL_NAME`` to determine | |
238 | whether or not a namespace is the global one. An unnamed namespace | |
239 | will have a ``DECL_NAME`` equal to ``anonymous_namespace_name``. | |
240 | Within a single translation unit, all unnamed namespaces will have the | |
241 | same name. | |
242 | ||
243 | .. envvar:: DECL_CONTEXT | |
244 | ||
245 | This macro returns the enclosing namespace. The ``DECL_CONTEXT`` for | |
246 | the ``global_namespace`` is ``NULL_TREE``. | |
247 | ||
248 | .. envvar:: DECL_NAMESPACE_ALIAS | |
249 | ||
250 | If this declaration is for a namespace alias, then | |
251 | ``DECL_NAMESPACE_ALIAS`` is the namespace for which this one is an | |
252 | alias. | |
253 | ||
254 | Do not attempt to use ``cp_namespace_decls`` for a namespace which is | |
255 | an alias. Instead, follow ``DECL_NAMESPACE_ALIAS`` links until you | |
256 | reach an ordinary, non-alias, namespace, and call | |
257 | ``cp_namespace_decls`` there. | |
258 | ||
259 | .. envvar:: DECL_NAMESPACE_STD_P | |
260 | ||
261 | This predicate holds if the namespace is the special ``::std`` | |
262 | namespace. | |
263 | ||
264 | ``cp_namespace_decls`` | |
265 | This function will return the declarations contained in the namespace, | |
266 | including types, overloaded functions, other namespaces, and so forth. | |
267 | If there are no declarations, this function will return | |
268 | ``NULL_TREE``. The declarations are connected through their | |
269 | ``TREE_CHAIN`` fields. | |
270 | ||
271 | Although most entries on this list will be declarations, | |
272 | ``TREE_LIST`` nodes may also appear. In this case, the | |
273 | ``TREE_VALUE`` will be an ``OVERLOAD``. The value of the | |
274 | ``TREE_PURPOSE`` is unspecified; back ends should ignore this value. | |
275 | As with the other kinds of declarations returned by | |
276 | ``cp_namespace_decls``, the ``TREE_CHAIN`` will point to the next | |
277 | declaration in this list. | |
278 | ||
279 | For more information on the kinds of declarations that can occur on this | |
280 | list, See :ref:`declarations`. Some declarations will not appear on this | |
281 | list. In particular, no ``FIELD_DECL``, ``LABEL_DECL``, or | |
282 | ``PARM_DECL`` nodes will appear here. | |
283 | ||
284 | This function cannot be used with namespaces that have | |
285 | ``DECL_NAMESPACE_ALIAS`` set. | |
286 | ||
287 | .. - | |
288 | Classes | |
289 | - | |
290 | ||
291 | .. index:: class, scope | |
292 | ||
293 | .. _classes: | |
294 | ||
295 | Classes | |
296 | ^^^^^^^ | |
297 | ||
298 | .. index:: RECORD_TYPE, UNION_TYPE, CLASSTYPE_DECLARED_CLASS, TYPE_BINFO, BINFO_TYPE, TYPE_FIELDS, TYPE_VFIELD | |
299 | ||
300 | Besides namespaces, the other high-level scoping construct in C++ is the | |
301 | class. (Throughout this manual the term :dfn:`class` is used to mean the | |
302 | types referred to in the ANSI/ISO C++ Standard as classes; these include | |
303 | types defined with the ``class``, ``struct``, and ``union`` | |
304 | keywords.) | |
305 | ||
306 | A class type is represented by either a ``RECORD_TYPE`` or a | |
307 | ``UNION_TYPE``. A class declared with the ``union`` tag is | |
308 | represented by a ``UNION_TYPE``, while classes declared with either | |
309 | the ``struct`` or the ``class`` tag are represented by | |
310 | ``RECORD_TYPE`` s. You can use the ``CLASSTYPE_DECLARED_CLASS`` | |
311 | macro to discern whether or not a particular type is a ``class`` as | |
312 | opposed to a ``struct``. This macro will be true only for classes | |
313 | declared with the ``class`` tag. | |
314 | ||
315 | Almost all members are available on the ``TYPE_FIELDS`` | |
316 | list. Given one member, the next can be found by following the | |
317 | ``TREE_CHAIN``. You should not depend in any way on the order in | |
318 | which fields appear on this list. All nodes on this list will be | |
319 | :samp:`DECL` nodes. A ``FIELD_DECL`` is used to represent a non-static | |
320 | data member, a ``VAR_DECL`` is used to represent a static data | |
321 | member, and a ``TYPE_DECL`` is used to represent a type. Note that | |
322 | the ``CONST_DECL`` for an enumeration constant will appear on this | |
323 | list, if the enumeration type was declared in the class. (Of course, | |
324 | the ``TYPE_DECL`` for the enumeration type will appear here as well.) | |
325 | There are no entries for base classes on this list. In particular, | |
326 | there is no ``FIELD_DECL`` for the 'base-class portion' of an | |
327 | object. If a function member is overloaded, each of the overloaded | |
328 | functions appears; no ``OVERLOAD`` nodes appear on the ``TYPE_FIELDS`` | |
329 | list. Implicitly declared functions (including default constructors, | |
330 | copy constructors, assignment operators, and destructors) will appear on | |
331 | this list as well. | |
332 | ||
333 | The ``TYPE_VFIELD`` is a compiler-generated field used to point to | |
334 | virtual function tables. It may or may not appear on the | |
335 | ``TYPE_FIELDS`` list. However, back ends should handle the | |
336 | ``TYPE_VFIELD`` just like all the entries on the ``TYPE_FIELDS`` | |
337 | list. | |
338 | ||
339 | Every class has an associated :dfn:`binfo`, which can be obtained with | |
340 | ``TYPE_BINFO``. Binfos are used to represent base-classes. The | |
341 | binfo given by ``TYPE_BINFO`` is the degenerate case, whereby every | |
342 | class is considered to be its own base-class. The base binfos for a | |
343 | particular binfo are held in a vector, whose length is obtained with | |
344 | ``BINFO_N_BASE_BINFOS``. The base binfos themselves are obtained | |
345 | with ``BINFO_BASE_BINFO`` and ``BINFO_BASE_ITERATE``. To add a | |
346 | new binfo, use ``BINFO_BASE_APPEND``. The vector of base binfos can | |
347 | be obtained with ``BINFO_BASE_BINFOS``, but normally you do not need | |
348 | to use that. The class type associated with a binfo is given by | |
349 | ``BINFO_TYPE``. It is not always the case that ``BINFO_TYPE | |
350 | (TYPE_BINFO (x))``, because of typedefs and qualified types. Neither is | |
351 | it the case that ``TYPE_BINFO (BINFO_TYPE (y))`` is the same binfo as | |
352 | ``y``. The reason is that if ``y`` is a binfo representing a | |
353 | base-class ``B`` of a derived class ``D``, then ``BINFO_TYPE | |
354 | (y)`` will be ``B``, and ``TYPE_BINFO (BINFO_TYPE (y))`` will be | |
355 | ``B`` as its own base-class, rather than as a base-class of ``D``. | |
356 | ||
357 | The access to a base type can be found with ``BINFO_BASE_ACCESS``. | |
358 | This will produce ``access_public_node``, ``access_private_node`` | |
359 | or ``access_protected_node``. If bases are always public, | |
360 | ``BINFO_BASE_ACCESSES`` may be ``NULL``. | |
361 | ||
362 | ``BINFO_VIRTUAL_P`` is used to specify whether the binfo is inherited | |
363 | virtually or not. The other flags, ``BINFO_FLAG_0`` to | |
364 | ``BINFO_FLAG_6``, can be used for language specific use. | |
365 | ||
366 | The following macros can be used on a tree node representing a class-type. | |
367 | ||
368 | .. envvar:: LOCAL_CLASS_P | |
369 | ||
370 | This predicate holds if the class is local class *i.e.* declared | |
371 | inside a function body. | |
372 | ||
373 | .. envvar:: TYPE_POLYMORPHIC_P | |
374 | ||
375 | This predicate holds if the class has at least one virtual function | |
376 | (declared or inherited). | |
377 | ||
378 | .. envvar:: TYPE_HAS_DEFAULT_CONSTRUCTOR | |
379 | ||
380 | This predicate holds whenever its argument represents a class-type with | |
381 | default constructor. | |
382 | ||
383 | .. envvar:: CLASSTYPE_HAS_MUTABLE | |
384 | ||
385 | These predicates hold for a class-type having a mutable data member. | |
386 | ||
387 | .. envvar:: CLASSTYPE_NON_POD_P | |
388 | ||
389 | This predicate holds only for class-types that are not PODs. | |
390 | ||
391 | .. envvar:: TYPE_HAS_NEW_OPERATOR | |
392 | ||
393 | This predicate holds for a class-type that defines | |
394 | ``operator new``. | |
395 | ||
396 | .. envvar:: TYPE_HAS_ARRAY_NEW_OPERATOR | |
397 | ||
398 | This predicate holds for a class-type for which | |
399 | ``operator new[]`` is defined. | |
400 | ||
401 | .. envvar:: TYPE_OVERLOADS_CALL_EXPR | |
402 | ||
403 | This predicate holds for class-type for which the function call | |
404 | ``operator()`` is overloaded. | |
405 | ||
406 | .. envvar:: TYPE_OVERLOADS_ARRAY_REF | |
407 | ||
408 | This predicate holds for a class-type that overloads | |
409 | ``operator[]`` | |
410 | ||
411 | .. envvar:: TYPE_OVERLOADS_ARROW | |
412 | ||
413 | This predicate holds for a class-type for which ``operator->`` is | |
414 | overloaded. | |
415 | ||
416 | .. index:: function | |
417 | ||
418 | .. _functions-for-c++: | |
419 | ||
420 | Functions for C++ | |
421 | ^^^^^^^^^^^^^^^^^ | |
422 | ||
423 | .. index:: FUNCTION_DECL, OVERLOAD, OVL_CURRENT, OVL_NEXT | |
424 | ||
425 | A function is represented by a ``FUNCTION_DECL`` node. A set of | |
426 | overloaded functions is sometimes represented by an ``OVERLOAD`` node. | |
427 | ||
428 | An ``OVERLOAD`` node is not a declaration, so none of the | |
429 | :samp:`DECL_` macros should be used on an ``OVERLOAD``. An | |
430 | ``OVERLOAD`` node is similar to a ``TREE_LIST``. Use | |
431 | ``OVL_CURRENT`` to get the function associated with an | |
432 | ``OVERLOAD`` node; use ``OVL_NEXT`` to get the next | |
433 | ``OVERLOAD`` node in the list of overloaded functions. The macros | |
434 | ``OVL_CURRENT`` and ``OVL_NEXT`` are actually polymorphic; you can | |
435 | use them to work with ``FUNCTION_DECL`` nodes as well as with | |
436 | overloads. In the case of a ``FUNCTION_DECL``, ``OVL_CURRENT`` | |
437 | will always return the function itself, and ``OVL_NEXT`` will always | |
438 | be ``NULL_TREE``. | |
439 | ||
440 | To determine the scope of a function, you can use the | |
441 | ``DECL_CONTEXT`` macro. This macro will return the class | |
442 | (either a ``RECORD_TYPE`` or a ``UNION_TYPE``) or namespace (a | |
443 | ``NAMESPACE_DECL``) of which the function is a member. For a virtual | |
444 | function, this macro returns the class in which the function was | |
445 | actually defined, not the base class in which the virtual declaration | |
446 | occurred. | |
447 | ||
448 | If a friend function is defined in a class scope, the | |
449 | ``DECL_FRIEND_CONTEXT`` macro can be used to determine the class in | |
450 | which it was defined. For example, in | |
451 | ||
452 | .. code-block:: c++ | |
453 | ||
454 | class C { friend void f() {} }; | |
455 | ||
456 | the ``DECL_CONTEXT`` for ``f`` will be the | |
457 | ``global_namespace``, but the ``DECL_FRIEND_CONTEXT`` will be the | |
458 | ``RECORD_TYPE`` for ``C``. | |
459 | ||
460 | The following macros and functions can be used on a ``FUNCTION_DECL`` : | |
461 | ||
462 | .. envvar:: DECL_MAIN_P | |
463 | ||
464 | This predicate holds for a function that is the program entry point | |
465 | ``::code``. | |
466 | ||
467 | .. envvar:: DECL_LOCAL_FUNCTION_P | |
468 | ||
469 | This predicate holds if the function was declared at block scope, even | |
470 | though it has a global scope. | |
471 | ||
472 | .. envvar:: DECL_ANTICIPATED | |
473 | ||
474 | This predicate holds if the function is a built-in function but its | |
475 | prototype is not yet explicitly declared. | |
476 | ||
477 | .. envvar:: DECL_EXTERN_C_FUNCTION_P | |
478 | ||
479 | This predicate holds if the function is declared as an | |
480 | ' ``extern "C"`` ' function. | |
481 | ||
482 | .. envvar:: DECL_LINKONCE_P | |
483 | ||
484 | This macro holds if multiple copies of this function may be emitted in | |
485 | various translation units. It is the responsibility of the linker to | |
486 | merge the various copies. Template instantiations are the most common | |
487 | example of functions for which ``DECL_LINKONCE_P`` holds; G++ | |
488 | instantiates needed templates in all translation units which require them, | |
489 | and then relies on the linker to remove duplicate instantiations. | |
490 | ||
491 | .. todo:: This macro is not yet implemented. | |
492 | ||
493 | .. envvar:: DECL_FUNCTION_MEMBER_P | |
494 | ||
495 | This macro holds if the function is a member of a class, rather than a | |
496 | member of a namespace. | |
497 | ||
498 | .. envvar:: DECL_STATIC_FUNCTION_P | |
499 | ||
500 | This predicate holds if the function a static member function. | |
501 | ||
502 | .. envvar:: DECL_NONSTATIC_MEMBER_FUNCTION_P | |
503 | ||
504 | This macro holds for a non-static member function. | |
505 | ||
506 | .. envvar:: DECL_CONST_MEMFUNC_P | |
507 | ||
508 | This predicate holds for a ``const`` -member function. | |
509 | ||
510 | .. envvar:: DECL_VOLATILE_MEMFUNC_P | |
511 | ||
512 | This predicate holds for a ``volatile`` -member function. | |
513 | ||
514 | .. envvar:: DECL_CONSTRUCTOR_P | |
515 | ||
516 | This macro holds if the function is a constructor. | |
517 | ||
518 | .. envvar:: DECL_NONCONVERTING_P | |
519 | ||
520 | This predicate holds if the constructor is a non-converting constructor. | |
521 | ||
522 | .. envvar:: DECL_COMPLETE_CONSTRUCTOR_P | |
523 | ||
524 | This predicate holds for a function which is a constructor for an object | |
525 | of a complete type. | |
526 | ||
527 | .. envvar:: DECL_BASE_CONSTRUCTOR_P | |
528 | ||
529 | This predicate holds for a function which is a constructor for a base | |
530 | class sub-object. | |
531 | ||
532 | .. envvar:: DECL_COPY_CONSTRUCTOR_P | |
533 | ||
534 | This predicate holds for a function which is a copy-constructor. | |
535 | ||
536 | .. envvar:: DECL_DESTRUCTOR_P | |
537 | ||
538 | This macro holds if the function is a destructor. | |
539 | ||
540 | .. envvar:: DECL_COMPLETE_DESTRUCTOR_P | |
541 | ||
542 | This predicate holds if the function is the destructor for an object a | |
543 | complete type. | |
544 | ||
545 | .. envvar:: DECL_OVERLOADED_OPERATOR_P | |
546 | ||
547 | This macro holds if the function is an overloaded operator. | |
548 | ||
549 | .. envvar:: DECL_CONV_FN_P | |
550 | ||
551 | This macro holds if the function is a type-conversion operator. | |
552 | ||
553 | .. envvar:: DECL_GLOBAL_CTOR_P | |
554 | ||
555 | This predicate holds if the function is a file-scope initialization | |
556 | function. | |
557 | ||
558 | .. envvar:: DECL_GLOBAL_DTOR_P | |
559 | ||
560 | This predicate holds if the function is a file-scope finalization | |
561 | function. | |
562 | ||
563 | .. envvar:: DECL_THUNK_P | |
564 | ||
565 | This predicate holds if the function is a thunk. | |
566 | ||
567 | These functions represent stub code that adjusts the ``this`` pointer | |
568 | and then jumps to another function. When the jumped-to function | |
569 | returns, control is transferred directly to the caller, without | |
570 | returning to the thunk. The first parameter to the thunk is always the | |
571 | ``this`` pointer; the thunk should add ``THUNK_DELTA`` to this | |
572 | value. (The ``THUNK_DELTA`` is an ``int``, not an | |
573 | ``INTEGER_CST``.) | |
574 | ||
575 | Then, if ``THUNK_VCALL_OFFSET`` (an ``INTEGER_CST``) is nonzero | |
576 | the adjusted ``this`` pointer must be adjusted again. The complete | |
577 | calculation is given by the following pseudo-code: | |
578 | ||
579 | .. code-block:: c++ | |
580 | ||
581 | this += THUNK_DELTA | |
582 | if (THUNK_VCALL_OFFSET) | |
583 | this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET] | |
584 | ||
585 | Finally, the thunk should jump to the location given | |
586 | by ``DECL_INITIAL`` ; this will always be an expression for the | |
587 | address of a function. | |
588 | ||
589 | .. envvar:: DECL_NON_THUNK_FUNCTION_P | |
590 | ||
591 | This predicate holds if the function is *not* a thunk function. | |
592 | ||
593 | .. envvar:: GLOBAL_INIT_PRIORITY | |
594 | ||
595 | If either ``DECL_GLOBAL_CTOR_P`` or ``DECL_GLOBAL_DTOR_P`` holds, | |
596 | then this gives the initialization priority for the function. The | |
597 | linker will arrange that all functions for which | |
598 | ``DECL_GLOBAL_CTOR_P`` holds are run in increasing order of priority | |
599 | before ``main`` is called. When the program exits, all functions for | |
600 | which ``DECL_GLOBAL_DTOR_P`` holds are run in the reverse order. | |
601 | ||
602 | .. envvar:: TYPE_RAISES_EXCEPTIONS | |
603 | ||
604 | This macro returns the list of exceptions that a (member-)function can | |
605 | raise. The returned list, if non ``NULL``, is comprised of nodes | |
606 | whose ``TREE_VALUE`` represents a type. | |
607 | ||
608 | .. envvar:: TYPE_NOTHROW_P | |
609 | ||
610 | This predicate holds when the exception-specification of its arguments | |
611 | is of the form ' ``()`` '. | |
612 | ||
613 | .. envvar:: DECL_ARRAY_DELETE_OPERATOR_P | |
614 | ||
615 | This predicate holds if the function an overloaded | |
616 | ``operator delete[]``. | |
617 | ||
618 | .. - | |
619 | Function Bodies | |
620 | - | |
621 | ||
622 | .. index:: statements | |
623 | ||
624 | .. _statements-for-c-and-c++: | |
625 | ||
626 | Statements for C and C++ | |
627 | ^^^^^^^^^^^^^^^^^^^^^^^^ | |
628 | ||
629 | .. index:: BREAK_STMT, CLEANUP_STMT, CLEANUP_DECL, CLEANUP_EXPR, CONTINUE_STMT, DECL_STMT, DECL_STMT_DECL, DO_STMT, DO_BODY, DO_COND, EMPTY_CLASS_EXPR, EXPR_STMT, EXPR_STMT_EXPR, FOR_STMT, FOR_INIT_STMT, FOR_COND, FOR_EXPR, FOR_BODY, HANDLER, IF_STMT, IF_COND, THEN_CLAUSE, ELSE_CLAUSE, RETURN_STMT, RETURN_EXPR, SUBOBJECT, SUBOBJECT_CLEANUP, SWITCH_STMT, SWITCH_COND, SWITCH_BODY, TRY_BLOCK, TRY_STMTS, TRY_HANDLERS, HANDLER_PARMS, HANDLER_BODY, USING_STMT, WHILE_STMT, WHILE_BODY, WHILE_COND | |
630 | ||
631 | A function that has a definition in the current translation unit has | |
632 | a non- ``NULL`` ``DECL_INITIAL``. However, back ends should not make | |
633 | use of the particular value given by ``DECL_INITIAL``. | |
634 | ||
635 | The ``DECL_SAVED_TREE`` gives the complete body of the | |
636 | function. | |
637 | ||
638 | There are tree nodes corresponding to all of the source-level | |
639 | statement constructs, used within the C and C++ frontends. These are | |
640 | enumerated here, together with a list of the various macros that can | |
641 | be used to obtain information about them. There are a few macros that | |
642 | can be used with all statements: | |
643 | ||
644 | .. envvar:: STMT_IS_FULL_EXPR_P | |
645 | ||
646 | In C++, statements normally constitute 'full expressions'; temporaries | |
647 | created during a statement are destroyed when the statement is complete. | |
648 | However, G++ sometimes represents expressions by statements; these | |
649 | statements will not have ``STMT_IS_FULL_EXPR_P`` set. Temporaries | |
650 | created during such statements should be destroyed when the innermost | |
651 | enclosing statement with ``STMT_IS_FULL_EXPR_P`` set is exited. | |
652 | ||
653 | Here is the list of the various statement nodes, and the macros used to | |
654 | access them. This documentation describes the use of these nodes in | |
655 | non-template functions (including instantiations of template functions). | |
656 | In template functions, the same nodes are used, but sometimes in | |
657 | slightly different ways. | |
658 | ||
659 | Many of the statements have substatements. For example, a ``while`` | |
660 | loop has a body, which is itself a statement. If the substatement | |
661 | is ``NULL_TREE``, it is considered equivalent to a statement | |
662 | consisting of a single ``;``, i.e., an expression statement in which | |
663 | the expression has been omitted. A substatement may in fact be a list | |
664 | of statements, connected via their ``TREE_CHAIN`` s. So, you should | |
665 | always process the statement tree by looping over substatements, like | |
666 | this: | |
667 | ||
668 | .. code-block:: c++ | |
669 | ||
670 | void process_stmt (stmt) | |
671 | tree stmt; | |
672 | { | |
673 | while (stmt) | |
674 | { | |
675 | switch (TREE_CODE (stmt)) | |
676 | { | |
677 | case IF_STMT: | |
678 | process_stmt (THEN_CLAUSE (stmt)); | |
679 | /* More processing here. */ | |
680 | break; | |
681 | ||
682 | ... | |
683 | } | |
684 | ||
685 | stmt = TREE_CHAIN (stmt); | |
686 | } | |
687 | } | |
688 | ||
689 | In other words, while the ``then`` clause of an ``if`` statement | |
690 | in C++ can be only one statement (although that one statement may be a | |
691 | compound statement), the intermediate representation sometimes uses | |
692 | several statements chained together. | |
693 | ||
694 | .. envvar:: BREAK_STMT | |
695 | ||
696 | Used to represent a ``break`` statement. There are no additional | |
697 | fields. | |
698 | ||
699 | .. envvar:: CLEANUP_STMT | |
700 | ||
701 | Used to represent an action that should take place upon exit from the | |
702 | enclosing scope. Typically, these actions are calls to destructors for | |
703 | local objects, but back ends cannot rely on this fact. If these nodes | |
704 | are in fact representing such destructors, ``CLEANUP_DECL`` will be | |
705 | the ``VAR_DECL`` destroyed. Otherwise, ``CLEANUP_DECL`` will be | |
706 | ``NULL_TREE``. In any case, the ``CLEANUP_EXPR`` is the | |
707 | expression to execute. The cleanups executed on exit from a scope | |
708 | should be run in the reverse order of the order in which the associated | |
709 | ``CLEANUP_STMT`` s were encountered. | |
710 | ||
711 | .. envvar:: CONTINUE_STMT | |
712 | ||
713 | Used to represent a ``continue`` statement. There are no additional | |
714 | fields. | |
715 | ||
716 | .. envvar:: CTOR_STMT | |
717 | ||
718 | Used to mark the beginning (if ``CTOR_BEGIN_P`` holds) or end (if | |
719 | ``CTOR_END_P`` holds of the main body of a constructor. See also | |
720 | ``SUBOBJECT`` for more information on how to use these nodes. | |
721 | ||
722 | .. envvar:: DO_STMT | |
723 | ||
724 | Used to represent a ``do`` loop. The body of the loop is given by | |
725 | ``DO_BODY`` while the termination condition for the loop is given by | |
726 | ``DO_COND``. The condition for a ``do`` -statement is always an | |
727 | expression. | |
728 | ||
729 | .. envvar:: EMPTY_CLASS_EXPR | |
730 | ||
731 | Used to represent a temporary object of a class with no data whose | |
732 | address is never taken. (All such objects are interchangeable.) The | |
733 | ``TREE_TYPE`` represents the type of the object. | |
734 | ||
735 | .. envvar:: EXPR_STMT | |
736 | ||
737 | Used to represent an expression statement. Use ``EXPR_STMT_EXPR`` to | |
738 | obtain the expression. | |
739 | ||
740 | .. envvar:: FOR_STMT | |
741 | ||
742 | Used to represent a ``for`` statement. The ``FOR_INIT_STMT`` is | |
743 | the initialization statement for the loop. The ``FOR_COND`` is the | |
744 | termination condition. The ``FOR_EXPR`` is the expression executed | |
745 | right before the ``FOR_COND`` on each loop iteration; often, this | |
746 | expression increments a counter. The body of the loop is given by | |
747 | ``FOR_BODY``. ``FOR_SCOPE`` holds the scope of the ``for`` | |
748 | statement (used in the C++ front end only). Note that | |
749 | ``FOR_INIT_STMT`` and ``FOR_BODY`` return statements, while | |
750 | ``FOR_COND`` and ``FOR_EXPR`` return expressions. | |
751 | ||
752 | .. envvar:: HANDLER | |
753 | ||
754 | Used to represent a C++ ``catch`` block. The ``HANDLER_TYPE`` | |
755 | is the type of exception that will be caught by this handler; it is | |
756 | equal (by pointer equality) to ``NULL`` if this handler is for all | |
757 | types. ``HANDLER_PARMS`` is the ``DECL_STMT`` for the catch | |
758 | parameter, and ``HANDLER_BODY`` is the code for the block itself. | |
759 | ||
760 | .. envvar:: IF_STMT | |
761 | ||
762 | Used to represent an ``if`` statement. The ``IF_COND`` is the | |
763 | expression. | |
764 | ||
765 | If the condition is a ``TREE_LIST``, then the ``TREE_PURPOSE`` is | |
766 | a statement (usually a ``DECL_STMT``). Each time the condition is | |
767 | evaluated, the statement should be executed. Then, the | |
768 | ``TREE_VALUE`` should be used as the conditional expression itself. | |
769 | This representation is used to handle C++ code like this: | |
770 | ||
771 | .. code-block:: c++ | |
772 | ||
773 | if (int i = 7) ... | |
774 | ||
775 | where there is a new local variable (or variables) declared within the | |
776 | condition. | |
777 | ||
778 | The ``THEN_CLAUSE`` represents the statement given by the ``then`` | |
779 | condition, while the ``ELSE_CLAUSE`` represents the statement given | |
780 | by the ``else`` condition. | |
781 | ||
782 | C++ distinguishes between this and ``COND_EXPR`` for handling templates. | |
783 | ||
784 | .. envvar:: SUBOBJECT | |
785 | ||
786 | In a constructor, these nodes are used to mark the point at which a | |
787 | subobject of ``this`` is fully constructed. If, after this point, an | |
788 | exception is thrown before a ``CTOR_STMT`` with ``CTOR_END_P`` set | |
789 | is encountered, the ``SUBOBJECT_CLEANUP`` must be executed. The | |
790 | cleanups must be executed in the reverse order in which they appear. | |
791 | ||
792 | .. envvar:: SWITCH_STMT | |
793 | ||
794 | Used to represent a ``switch`` statement. The ``SWITCH_STMT_COND`` | |
795 | is the expression on which the switch is occurring. See the documentation | |
796 | for an ``IF_STMT`` for more information on the representation used | |
797 | for the condition. The ``SWITCH_STMT_BODY`` is the body of the switch | |
798 | statement. The ``SWITCH_STMT_TYPE`` is the original type of switch | |
799 | expression as given in the source, before any compiler conversions. | |
800 | The ``SWITCH_STMT_SCOPE`` is the statement scope (used in the | |
801 | C++ front end only). | |
802 | ||
803 | There are also two boolean flags used with ``SWITCH_STMT``. | |
804 | ``SWITCH_STMT_ALL_CASES_P`` is true if the switch includes a default label | |
805 | or the case label ranges cover all possible values of the condition | |
806 | expression. ``SWITCH_STMT_NO_BREAK_P`` is true if there are no | |
807 | ``break`` statements in the switch. | |
808 | ||
809 | .. envvar:: TRY_BLOCK | |
810 | ||
811 | Used to represent a ``try`` block. The body of the try block is | |
812 | given by ``TRY_STMTS``. Each of the catch blocks is a ``HANDLER`` | |
813 | node. The first handler is given by ``TRY_HANDLERS``. Subsequent | |
814 | handlers are obtained by following the ``TREE_CHAIN`` link from one | |
815 | handler to the next. The body of the handler is given by | |
816 | ``HANDLER_BODY``. | |
817 | ||
818 | If ``CLEANUP_P`` holds of the ``TRY_BLOCK``, then the | |
819 | ``TRY_HANDLERS`` will not be a ``HANDLER`` node. Instead, it will | |
820 | be an expression that should be executed if an exception is thrown in | |
821 | the try block. It must rethrow the exception after executing that code. | |
822 | And, if an exception is thrown while the expression is executing, | |
823 | ``terminate`` must be called. | |
824 | ||
825 | .. envvar:: USING_STMT | |
826 | ||
827 | Used to represent a ``using`` directive. The namespace is given by | |
828 | ``USING_STMT_NAMESPACE``, which will be a NAMESPACE_DECL. This node | |
829 | is needed inside template functions, to implement using directives | |
830 | during instantiation. | |
831 | ||
832 | .. envvar:: WHILE_STMT | |
833 | ||
834 | Used to represent a ``while`` loop. The ``WHILE_COND`` is the | |
835 | termination condition for the loop. See the documentation for an | |
836 | ``IF_STMT`` for more information on the representation used for the | |
837 | condition. | |
838 | ||
839 | The ``WHILE_BODY`` is the body of the loop. | |
840 | ||
841 | .. _c++-expressions: | |
842 | ||
843 | C++ Expressions | |
844 | ^^^^^^^^^^^^^^^ | |
845 | ||
846 | This section describes expressions specific to the C and C++ front | |
847 | ends. | |
848 | ||
849 | .. envvar:: TYPEID_EXPR | |
850 | ||
851 | Used to represent a ``typeid`` expression. | |
852 | ||
853 | .. envvar:: NEW_EXPR | |
854 | ||
855 | Used to represent a call to ``new`` and ``new[]`` respectively. | |
856 | ||
857 | .. envvar:: DELETE_EXPR | |
858 | ||
859 | Used to represent a call to ``delete`` and ``delete[]`` respectively. | |
860 | ||
861 | .. envvar:: MEMBER_REF | |
862 | ||
863 | Represents a reference to a member of a class. | |
864 | ||
865 | .. envvar:: THROW_EXPR | |
866 | ||
867 | Represents an instance of ``throw`` in the program. Operand 0, | |
868 | which is the expression to throw, may be ``NULL_TREE``. | |
869 | ||
870 | .. envvar:: AGGR_INIT_EXPR | |
871 | ||
872 | An ``AGGR_INIT_EXPR`` represents the initialization as the return | |
873 | value of a function call, or as the result of a constructor. An | |
874 | ``AGGR_INIT_EXPR`` will only appear as a full-expression, or as the | |
875 | second operand of a ``TARGET_EXPR``. ``AGGR_INIT_EXPR`` s have | |
876 | a representation similar to that of ``CALL_EXPR`` s. You can use | |
877 | the ``AGGR_INIT_EXPR_FN`` and ``AGGR_INIT_EXPR_ARG`` macros to access | |
878 | the function to call and the arguments to pass. | |
879 | ||
880 | If ``AGGR_INIT_VIA_CTOR_P`` holds of the ``AGGR_INIT_EXPR``, then | |
881 | the initialization is via a constructor call. The address of the | |
882 | ``AGGR_INIT_EXPR_SLOT`` operand, which is always a ``VAR_DECL``, | |
883 | is taken, and this value replaces the first argument in the argument | |
884 | list. | |
885 | ||
3ed1b4ce | 886 | In either case, the expression is void. |