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