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