X-Git-Url: https://oss.titaniummirror.com/gitweb/?a=blobdiff_plain;f=gcc%2Fdoc%2Fgccint.info-4;fp=gcc%2Fdoc%2Fgccint.info-4;h=0000000000000000000000000000000000000000;hb=6fed43773c9b0ce596dca5686f37ac3fc0fa11c0;hp=764893fcdf5717e19ba72a4943d03c75f04fb320;hpb=27b11d56b743098deb193d510b337ba22dc52e5c;p=msp430-gcc.git diff --git a/gcc/doc/gccint.info-4 b/gcc/doc/gccint.info-4 deleted file mode 100644 index 764893fc..00000000 --- a/gcc/doc/gccint.info-4 +++ /dev/null @@ -1,1014 +0,0 @@ -This is doc/gccint.info, produced by makeinfo version 4.5 from -doc/gccint.texi. - -INFO-DIR-SECTION Programming -START-INFO-DIR-ENTRY -* gccint: (gccint). Internals of the GNU Compiler Collection. -END-INFO-DIR-ENTRY - This file documents the internals of the GNU compilers. - - Published by the Free Software Foundation -59 Temple Place - Suite 330 -Boston, MA 02111-1307 USA - - Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, -1999, 2000, 2001, 2002 Free Software Foundation, Inc. - - Permission is granted to copy, distribute and/or modify this document -under the terms of the GNU Free Documentation License, Version 1.1 or -any later version published by the Free Software Foundation; with the -Invariant Sections being "GNU General Public License" and "Funding Free -Software", the Front-Cover texts being (a) (see below), and with the -Back-Cover Texts being (b) (see below). A copy of the license is -included in the section entitled "GNU Free Documentation License". - - (a) The FSF's Front-Cover Text is: - - A GNU Manual - - (b) The FSF's Back-Cover Text is: - - You have freedom to copy and modify this GNU Manual, like GNU -software. Copies published by the Free Software Foundation raise -funds for GNU development. - - -File: gccint.info, Node: Function Bodies, Prev: Function Basics, Up: Functions - -Function Bodies ---------------- - - A function that has a definition in the current translation unit will -have a non-`NULL' `DECL_INITIAL'. However, back ends should not make -use of the particular value given by `DECL_INITIAL'. - - The `DECL_SAVED_TREE' macro will give the complete body of the -function. This node will usually be a `COMPOUND_STMT' representing the -outermost block of the function, but it may also be a `TRY_BLOCK', a -`RETURN_INIT', or any other valid statement. - -Statements -.......... - - There are tree nodes corresponding to all of the source-level -statement constructs. These are enumerated here, together with a list -of the various macros that can be used to obtain information about -them. There are a few macros that can be used with all statements: - -`STMT_LINENO' - This macro returns the line number for the statement. If the - statement spans multiple lines, this value will be the number of - the first line on which the statement occurs. Although we mention - `CASE_LABEL' below as if it were a statement, they do not allow - the use of `STMT_LINENO'. There is no way to obtain the line - number for a `CASE_LABEL'. - - Statements do not contain information about the file from which - they came; that information is implicit in the `FUNCTION_DECL' - from which the statements originate. - -`STMT_IS_FULL_EXPR_P' - In C++, statements normally constitute "full expressions"; - temporaries created during a statement are destroyed when the - statement is complete. However, G++ sometimes represents - expressions by statements; these statements will not have - `STMT_IS_FULL_EXPR_P' set. Temporaries created during such - statements should be destroyed when the innermost enclosing - statement with `STMT_IS_FULL_EXPR_P' set is exited. - - - Here is the list of the various statement nodes, and the macros used -to access them. This documentation describes the use of these nodes in -non-template functions (including instantiations of template functions). -In template functions, the same nodes are used, but sometimes in -slightly different ways. - - Many of the statements have substatements. For example, a `while' -loop will have a body, which is itself a statement. If the substatement -is `NULL_TREE', it is considered equivalent to a statement consisting -of a single `;', i.e., an expression statement in which the expression -has been omitted. A substatement may in fact be a list of statements, -connected via their `TREE_CHAIN's. So, you should always process the -statement tree by looping over substatements, like this: - void process_stmt (stmt) - tree stmt; - { - while (stmt) - { - switch (TREE_CODE (stmt)) - { - case IF_STMT: - process_stmt (THEN_CLAUSE (stmt)); - /* More processing here. */ - break; - - ... - } - - stmt = TREE_CHAIN (stmt); - } - } - In other words, while the `then' clause of an `if' statement in C++ -can be only one statement (although that one statement may be a -compound statement), the intermediate representation will sometimes use -several statements chained together. - -`ASM_STMT' - Used to represent an inline assembly statement. For an inline - assembly statement like: - asm ("mov x, y"); - The `ASM_STRING' macro will return a `STRING_CST' node for `"mov - x, y"'. If the original statement made use of the - extended-assembly syntax, then `ASM_OUTPUTS', `ASM_INPUTS', and - `ASM_CLOBBERS' will be the outputs, inputs, and clobbers for the - statement, represented as `STRING_CST' nodes. The - extended-assembly syntax looks like: - asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); - The first string is the `ASM_STRING', containing the instruction - template. The next two strings are the output and inputs, - respectively; this statement has no clobbers. As this example - indicates, "plain" assembly statements are merely a special case - of extended assembly statements; they have no cv-qualifiers, - outputs, inputs, or clobbers. All of the strings will be - `NUL'-terminated, and will contain no embedded `NUL'-characters. - - If the assembly statement is declared `volatile', or if the - statement was not an extended assembly statement, and is therefore - implicitly volatile, then the predicate `ASM_VOLATILE_P' will hold - of the `ASM_STMT'. - -`BREAK_STMT' - Used to represent a `break' statement. There are no additional - fields. - -`CASE_LABEL' - Use to represent a `case' label, range of `case' labels, or a - `default' label. If `CASE_LOW' is `NULL_TREE', then this is a - `default' label. Otherwise, if `CASE_HIGH' is `NULL_TREE', then - this is an ordinary `case' label. In this case, `CASE_LOW' is an - expression giving the value of the label. Both `CASE_LOW' and - `CASE_HIGH' are `INTEGER_CST' nodes. These values will have the - same type as the condition expression in the switch statement. - - Otherwise, if both `CASE_LOW' and `CASE_HIGH' are defined, the - statement is a range of case labels. Such statements originate - with the extension that allows users to write things of the form: - case 2 ... 5: - The first value will be `CASE_LOW', while the second will be - `CASE_HIGH'. - -`CLEANUP_STMT' - Used to represent an action that should take place upon exit from - the enclosing scope. Typically, these actions are calls to - destructors for local objects, but back ends cannot rely on this - fact. If these nodes are in fact representing such destructors, - `CLEANUP_DECL' will be the `VAR_DECL' destroyed. Otherwise, - `CLEANUP_DECL' will be `NULL_TREE'. In any case, the - `CLEANUP_EXPR' is the expression to execute. The cleanups - executed on exit from a scope should be run in the reverse order - of the order in which the associated `CLEANUP_STMT's were - encountered. - -`COMPOUND_STMT' - Used to represent a brace-enclosed block. The first substatement - is given by `COMPOUND_BODY'. Subsequent substatements are found by - following the `TREE_CHAIN' link from one substatement to the next. - The `COMPOUND_BODY' will be `NULL_TREE' if there are no - substatements. - -`CONTINUE_STMT' - Used to represent a `continue' statement. There are no additional - fields. - -`CTOR_STMT' - Used to mark the beginning (if `CTOR_BEGIN_P' holds) or end (if - `CTOR_END_P' holds of the main body of a constructor. See also - `SUBOBJECT' for more information on how to use these nodes. - -`DECL_STMT' - Used to represent a local declaration. The `DECL_STMT_DECL' macro - can be used to obtain the entity declared. This declaration may - be a `LABEL_DECL', indicating that the label declared is a local - label. (As an extension, GCC allows the declaration of labels - with scope.) In C, this declaration may be a `FUNCTION_DECL', - indicating the use of the GCC nested function extension. For more - information, *note Functions::. - -`DO_STMT' - Used to represent a `do' loop. The body of the loop is given by - `DO_BODY' while the termination condition for the loop is given by - `DO_COND'. The condition for a `do'-statement is always an - expression. - -`EMPTY_CLASS_EXPR' - Used to represent a temporary object of a class with no data whose - address is never taken. (All such objects are interchangeable.) - The `TREE_TYPE' represents the type of the object. - -`EXPR_STMT' - Used to represent an expression statement. Use `EXPR_STMT_EXPR' to - obtain the expression. - -`FILE_STMT' - Used to record a change in filename within the body of a function. - Use `FILE_STMT_FILENAME' to obtain the new filename. - -`FOR_STMT' - Used to represent a `for' statement. The `FOR_INIT_STMT' is the - initialization statement for the loop. The `FOR_COND' is the - termination condition. The `FOR_EXPR' is the expression executed - right before the `FOR_COND' on each loop iteration; often, this - expression increments a counter. The body of the loop is given by - `FOR_BODY'. Note that `FOR_INIT_STMT' and `FOR_BODY' return - statements, while `FOR_COND' and `FOR_EXPR' return expressions. - -`GOTO_STMT' - Used to represent a `goto' statement. The `GOTO_DESTINATION' will - usually be a `LABEL_DECL'. However, if the "computed goto" - extension has been used, the `GOTO_DESTINATION' will be an - arbitrary expression indicating the destination. This expression - will always have pointer type. Additionally the `GOTO_FAKE_P' - flag is set whenever the goto statement does not come from source - code, but it is generated implicitly by the compiler. This is - used for branch prediction. - -`HANDLER' - Used to represent a C++ `catch' block. The `HANDLER_TYPE' is the - type of exception that will be caught by this handler; it is equal - (by pointer equality) to `CATCH_ALL_TYPE' if this handler is for - all types. `HANDLER_PARMS' is the `DECL_STMT' for the catch - parameter, and `HANDLER_BODY' is the `COMPOUND_STMT' for the block - itself. - -`IF_STMT' - Used to represent an `if' statement. The `IF_COND' is the - expression. - - If the condition is a `TREE_LIST', then the `TREE_PURPOSE' is a - statement (usually a `DECL_STMT'). Each time the condition is - evaluated, the statement should be executed. Then, the - `TREE_VALUE' should be used as the conditional expression itself. - This representation is used to handle C++ code like this: - - if (int i = 7) ... - - where there is a new local variable (or variables) declared within - the condition. - - The `THEN_CLAUSE' represents the statement given by the `then' - condition, while the `ELSE_CLAUSE' represents the statement given - by the `else' condition. - -`LABEL_STMT' - Used to represent a label. The `LABEL_DECL' declared by this - statement can be obtained with the `LABEL_STMT_LABEL' macro. The - `IDENTIFIER_NODE' giving the name of the label can be obtained from - the `LABEL_DECL' with `DECL_NAME'. - -`RETURN_INIT' - If the function uses the G++ "named return value" extension, - meaning that the function has been defined like: - S f(int) return s {...} - then there will be a `RETURN_INIT'. There is never a named - returned value for a constructor. The first argument to the - `RETURN_INIT' is the name of the object returned; the second - argument is the initializer for the object. The object is - initialized when the `RETURN_INIT' is encountered. The object - referred to is the actual object returned; this extension is a - manual way of doing the "return-value optimization." Therefore, - the object must actually be constructed in the place where the - object will be returned. - -`RETURN_STMT' - Used to represent a `return' statement. The `RETURN_EXPR' is the - expression returned; it will be `NULL_TREE' if the statement was - just - return; - -`SCOPE_STMT' - A scope-statement represents the beginning or end of a scope. If - `SCOPE_BEGIN_P' holds, this statement represents the beginning of a - scope; if `SCOPE_END_P' holds this statement represents the end of - a scope. On exit from a scope, all cleanups from `CLEANUP_STMT's - occurring in the scope must be run, in reverse order to the order - in which they were encountered. If `SCOPE_NULLIFIED_P' or - `SCOPE_NO_CLEANUPS_P' holds of the scope, back ends should behave - as if the `SCOPE_STMT' were not present at all. - -`SUBOBJECT' - In a constructor, these nodes are used to mark the point at which a - subobject of `this' is fully constructed. If, after this point, an - exception is thrown before a `CTOR_STMT' with `CTOR_END_P' set is - encountered, the `SUBOBJECT_CLEANUP' must be executed. The - cleanups must be executed in the reverse order in which they - appear. - -`SWITCH_STMT' - Used to represent a `switch' statement. The `SWITCH_COND' is the - expression on which the switch is occurring. See the documentation - for an `IF_STMT' for more information on the representation used - for the condition. The `SWITCH_BODY' is the body of the switch - statement. The `SWITCH_TYPE' is the original type of switch - expression as given in the source, before any compiler conversions. - -`TRY_BLOCK' - Used to represent a `try' block. The body of the try block is - given by `TRY_STMTS'. Each of the catch blocks is a `HANDLER' - node. The first handler is given by `TRY_HANDLERS'. Subsequent - handlers are obtained by following the `TREE_CHAIN' link from one - handler to the next. The body of the handler is given by - `HANDLER_BODY'. - - If `CLEANUP_P' holds of the `TRY_BLOCK', then the `TRY_HANDLERS' - will not be a `HANDLER' node. Instead, it will be an expression - that should be executed if an exception is thrown in the try - block. It must rethrow the exception after executing that code. - And, if an exception is thrown while the expression is executing, - `terminate' must be called. - -`USING_STMT' - Used to represent a `using' directive. The namespace is given by - `USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL. This node - is needed inside template functions, to implement using directives - during instantiation. - -`WHILE_STMT' - Used to represent a `while' loop. The `WHILE_COND' is the - termination condition for the loop. See the documentation for an - `IF_STMT' for more information on the representation used for the - condition. - - The `WHILE_BODY' is the body of the loop. - - - -File: gccint.info, Node: Attributes, Next: Expression trees, Prev: Declarations, Up: Trees - -Attributes in trees -=================== - - Attributes, as specified using the `__attribute__' keyword, are -represented internally as a `TREE_LIST'. The `TREE_PURPOSE' is the -name of the attribute, as an `IDENTIFIER_NODE'. The `TREE_VALUE' is a -`TREE_LIST' of the arguments of the attribute, if any, or `NULL_TREE' -if there are no arguments; the arguments are stored as the `TREE_VALUE' -of successive entries in the list, and may be identifiers or -expressions. The `TREE_CHAIN' of the attribute is the next attribute -in a list of attributes applying to the same declaration or type, or -`NULL_TREE' if there are no further attributes in the list. - - Attributes may be attached to declarations and to types; these -attributes may be accessed with the following macros. All attributes -are stored in this way, and many also cause other changes to the -declaration or type or to other internal compiler data structures. - - - Tree Macro: tree DECL_ATTRIBUTES (tree DECL) - This macro returns the attributes on the declaration DECL. - - - Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE) - This macro returns the attributes on the type TYPE. - - -File: gccint.info, Node: Expression trees, Prev: Attributes, Up: Trees - -Expressions -=========== - - The internal representation for expressions is for the most part -quite straightforward. However, there are a few facts that one must -bear in mind. In particular, the expression "tree" is actually a -directed acyclic graph. (For example there may be many references to -the integer constant zero throughout the source program; many of these -will be represented by the same expression node.) You should not rely -on certain kinds of node being shared, nor should rely on certain kinds -of nodes being unshared. - - The following macros can be used with all expression nodes: - -`TREE_TYPE' - Returns the type of the expression. This value may not be - precisely the same type that would be given the expression in the - original program. - - In what follows, some nodes that one might expect to always have type -`bool' are documented to have either integral or boolean type. At some -point in the future, the C front end may also make use of this same -intermediate representation, and at this point these nodes will -certainly have integral type. The previous sentence is not meant to -imply that the C++ front end does not or will not give these nodes -integral type. - - Below, we list the various kinds of expression nodes. Except where -noted otherwise, the operands to an expression are accessed using the -`TREE_OPERAND' macro. For example, to access the first operand to a -binary plus expression `expr', use: - - TREE_OPERAND (expr, 0) - -As this example indicates, the operands are zero-indexed. - - The table below begins with constants, moves on to unary expressions, -then proceeds to binary expressions, and concludes with various other -kinds of expressions: - -`INTEGER_CST' - These nodes represent integer constants. Note that the type of - these constants is obtained with `TREE_TYPE'; they are not always - of type `int'. In particular, `char' constants are represented - with `INTEGER_CST' nodes. The value of the integer constant `e' is - given by - ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT) - + TREE_INST_CST_LOW (e)) - - HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms. - Both `TREE_INT_CST_HIGH' and `TREE_INT_CST_LOW' return a - `HOST_WIDE_INT'. The value of an `INTEGER_CST' is interpreted as - a signed or unsigned quantity depending on the type of the - constant. In general, the expression given above will overflow, - so it should not be used to calculate the value of the constant. - - The variable `integer_zero_node' is an integer constant with value - zero. Similarly, `integer_one_node' is an integer constant with - value one. The `size_zero_node' and `size_one_node' variables are - analogous, but have type `size_t' rather than `int'. - - The function `tree_int_cst_lt' is a predicate which holds if its - first argument is less than its second. Both constants are - assumed to have the same signedness (i.e., either both should be - signed or both should be unsigned.) The full width of the - constant is used when doing the comparison; the usual rules about - promotions and conversions are ignored. Similarly, - `tree_int_cst_equal' holds if the two constants are equal. The - `tree_int_cst_sgn' function returns the sign of a constant. The - value is `1', `0', or `-1' according on whether the constant is - greater than, equal to, or less than zero. Again, the signedness - of the constant's type is taken into account; an unsigned constant - is never less than zero, no matter what its bit-pattern. - -`REAL_CST' - FIXME: Talk about how to obtain representations of this constant, - do comparisons, and so forth. - -`COMPLEX_CST' - These nodes are used to represent complex number constants, that - is a `__complex__' whose parts are constant nodes. The - `TREE_REALPART' and `TREE_IMAGPART' return the real and the - imaginary parts respectively. - -`VECTOR_CST' - These nodes are used to represent vector constants, whose parts are - constant nodes. Each individual constant node is either an - integer or a double constant node. The first operand is a - `TREE_LIST' of the constant nodes and is accessed through - `TREE_VECTOR_CST_ELTS'. - -`STRING_CST' - These nodes represent string-constants. The `TREE_STRING_LENGTH' - returns the length of the string, as an `int'. The - `TREE_STRING_POINTER' is a `char*' containing the string itself. - The string may not be `NUL'-terminated, and it may contain - embedded `NUL' characters. Therefore, the `TREE_STRING_LENGTH' - includes the trailing `NUL' if it is present. - - For wide string constants, the `TREE_STRING_LENGTH' is the number - of bytes in the string, and the `TREE_STRING_POINTER' points to an - array of the bytes of the string, as represented on the target - system (that is, as integers in the target endianness). Wide and - non-wide string constants are distinguished only by the `TREE_TYPE' - of the `STRING_CST'. - - FIXME: The formats of string constants are not well-defined when - the target system bytes are not the same width as host system - bytes. - -`PTRMEM_CST' - These nodes are used to represent pointer-to-member constants. The - `PTRMEM_CST_CLASS' is the class type (either a `RECORD_TYPE' or - `UNION_TYPE' within which the pointer points), and the - `PTRMEM_CST_MEMBER' is the declaration for the pointed to object. - Note that the `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is in - general different from the `PTRMEM_CST_CLASS'. For example, given: - struct B { int i; }; - struct D : public B {}; - int D::*dp = &D::i; - - The `PTRMEM_CST_CLASS' for `&D::i' is `D', even though the - `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is `B', since `B::i' is - a member of `B', not `D'. - -`VAR_DECL' - These nodes represent variables, including static data members. - For more information, *note Declarations::. - -`NEGATE_EXPR' - These nodes represent unary negation of the single operand, for - both integer and floating-point types. The type of negation can be - determined by looking at the type of the expression. - -`BIT_NOT_EXPR' - These nodes represent bitwise complement, and will always have - integral type. The only operand is the value to be complemented. - -`TRUTH_NOT_EXPR' - These nodes represent logical negation, and will always have - integral (or boolean) type. The operand is the value being - negated. - -`PREDECREMENT_EXPR' -`PREINCREMENT_EXPR' -`POSTDECREMENT_EXPR' -`POSTINCREMENT_EXPR' - These nodes represent increment and decrement expressions. The - value of the single operand is computed, and the operand - incremented or decremented. In the case of `PREDECREMENT_EXPR' and - `PREINCREMENT_EXPR', the value of the expression is the value - resulting after the increment or decrement; in the case of - `POSTDECREMENT_EXPR' and `POSTINCREMENT_EXPR' is the value before - the increment or decrement occurs. The type of the operand, like - that of the result, will be either integral, boolean, or - floating-point. - -`ADDR_EXPR' - These nodes are used to represent the address of an object. (These - expressions will always have pointer or reference type.) The - operand may be another expression, or it may be a declaration. - - As an extension, GCC allows users to take the address of a label. - In this case, the operand of the `ADDR_EXPR' will be a - `LABEL_DECL'. The type of such an expression is `void*'. - - If the object addressed is not an lvalue, a temporary is created, - and the address of the temporary is used. - -`INDIRECT_REF' - These nodes are used to represent the object pointed to by a - pointer. The operand is the pointer being dereferenced; it will - always have pointer or reference type. - -`FIX_TRUNC_EXPR' - These nodes represent conversion of a floating-point value to an - integer. The single operand will have a floating-point type, - while the the complete expression will have an integral (or - boolean) type. The operand is rounded towards zero. - -`FLOAT_EXPR' - These nodes represent conversion of an integral (or boolean) value - to a floating-point value. The single operand will have integral - type, while the complete expression will have a floating-point - type. - - FIXME: How is the operand supposed to be rounded? Is this - dependent on `-mieee'? - -`COMPLEX_EXPR' - These nodes are used to represent complex numbers constructed from - two expressions of the same (integer or real) type. The first - operand is the real part and the second operand is the imaginary - part. - -`CONJ_EXPR' - These nodes represent the conjugate of their operand. - -`REALPART_EXPR' - -`IMAGPART_EXPR' - These nodes represent respectively the real and the imaginary parts - of complex numbers (their sole argument). - -`NON_LVALUE_EXPR' - These nodes indicate that their one and only operand is not an - lvalue. A back end can treat these identically to the single - operand. - -`NOP_EXPR' - These nodes are used to represent conversions that do not require - any code-generation. For example, conversion of a `char*' to an - `int*' does not require any code be generated; such a conversion is - represented by a `NOP_EXPR'. The single operand is the expression - to be converted. The conversion from a pointer to a reference is - also represented with a `NOP_EXPR'. - -`CONVERT_EXPR' - These nodes are similar to `NOP_EXPR's, but are used in those - situations where code may need to be generated. For example, if an - `int*' is converted to an `int' code may need to be generated on - some platforms. These nodes are never used for C++-specific - conversions, like conversions between pointers to different - classes in an inheritance hierarchy. Any adjustments that need to - be made in such cases are always indicated explicitly. Similarly, - a user-defined conversion is never represented by a - `CONVERT_EXPR'; instead, the function calls are made explicit. - -`THROW_EXPR' - These nodes represent `throw' expressions. The single operand is - an expression for the code that should be executed to throw the - exception. However, there is one implicit action not represented - in that expression; namely the call to `__throw'. This function - takes no arguments. If `setjmp'/`longjmp' exceptions are used, the - function `__sjthrow' is called instead. The normal GCC back end - uses the function `emit_throw' to generate this code; you can - examine this function to see what needs to be done. - -`LSHIFT_EXPR' -`RSHIFT_EXPR' - These nodes represent left and right shifts, respectively. The - first operand is the value to shift; it will always be of integral - type. The second operand is an expression for the number of bits - by which to shift. Right shift should be treated as arithmetic, - i.e., the high-order bits should be zero-filled when the - expression has unsigned type and filled with the sign bit when the - expression has signed type. Note that the result is undefined if - the second operand is larger than the first operand's type size. - -`BIT_IOR_EXPR' -`BIT_XOR_EXPR' -`BIT_AND_EXPR' - These nodes represent bitwise inclusive or, bitwise exclusive or, - and bitwise and, respectively. Both operands will always have - integral type. - -`TRUTH_ANDIF_EXPR' -`TRUTH_ORIF_EXPR' - These nodes represent logical and and logical or, respectively. - These operators are not strict; i.e., the second operand is - evaluated only if the value of the expression is not determined by - evaluation of the first operand. The type of the operands, and - the result type, is always of boolean or integral type. - -`TRUTH_AND_EXPR' -`TRUTH_OR_EXPR' -`TRUTH_XOR_EXPR' - These nodes represent logical and, logical or, and logical - exclusive or. They are strict; both arguments are always - evaluated. There are no corresponding operators in C or C++, but - the front end will sometimes generate these expressions anyhow, if - it can tell that strictness does not matter. - -`PLUS_EXPR' -`MINUS_EXPR' -`MULT_EXPR' -`TRUNC_DIV_EXPR' -`TRUNC_MOD_EXPR' -`RDIV_EXPR' - These nodes represent various binary arithmetic operations. - Respectively, these operations are addition, subtraction (of the - second operand from the first), multiplication, integer division, - integer remainder, and floating-point division. The operands to - the first three of these may have either integral or floating - type, but there will never be case in which one operand is of - floating type and the other is of integral type. - - The result of a `TRUNC_DIV_EXPR' is always rounded towards zero. - The `TRUNC_MOD_EXPR' of two operands `a' and `b' is always `a - - a/b' where the division is as if computed by a `TRUNC_DIV_EXPR'. - -`ARRAY_REF' - These nodes represent array accesses. The first operand is the - array; the second is the index. To calculate the address of the - memory accessed, you must scale the index by the size of the type - of the array elements. The type of these expressions must be the - type of a component of the array. - -`ARRAY_RANGE_REF' - These nodes represent access to a range (or "slice") of an array. - The operands are the same as that for `ARRAY_REF' and have the same - meanings. The type of these expressions must be an array whose - component type is the same as that of the first operand. The - range of that array type determines the amount of data these - expressions access. - -`EXACT_DIV_EXPR' - Document. - -`LT_EXPR' -`LE_EXPR' -`GT_EXPR' -`GE_EXPR' -`EQ_EXPR' -`NE_EXPR' - These nodes represent the less than, less than or equal to, greater - than, greater than or equal to, equal, and not equal comparison - operators. The first and second operand with either be both of - integral type or both of floating type. The result type of these - expressions will always be of integral or boolean type. - -`MODIFY_EXPR' - These nodes represent assignment. The left-hand side is the first - operand; the right-hand side is the second operand. The left-hand - side will be a `VAR_DECL', `INDIRECT_REF', `COMPONENT_REF', or - other lvalue. - - These nodes are used to represent not only assignment with `=' but - also compound assignments (like `+='), by reduction to `=' - assignment. In other words, the representation for `i += 3' looks - just like that for `i = i + 3'. - -`INIT_EXPR' - These nodes are just like `MODIFY_EXPR', but are used only when a - variable is initialized, rather than assigned to subsequently. - -`COMPONENT_REF' - These nodes represent non-static data member accesses. The first - operand is the object (rather than a pointer to it); the second - operand is the `FIELD_DECL' for the data member. - -`COMPOUND_EXPR' - These nodes represent comma-expressions. The first operand is an - expression whose value is computed and thrown away prior to the - evaluation of the second operand. The value of the entire - expression is the value of the second operand. - -`COND_EXPR' - These nodes represent `?:' expressions. The first operand is of - boolean or integral type. If it evaluates to a nonzero value, the - second operand should be evaluated, and returned as the value of - the expression. Otherwise, the third operand is evaluated, and - returned as the value of the expression. As a GNU extension, the - middle operand of the `?:' operator may be omitted in the source, - like this: - - x ? : 3 - - which is equivalent to - - x ? x : 3 - - assuming that `x' is an expression without side-effects. However, - in the case that the first operation causes side effects, the - side-effects occur only once. Consumers of the internal - representation do not need to worry about this oddity; the second - operand will be always be present in the internal representation. - -`CALL_EXPR' - These nodes are used to represent calls to functions, including - non-static member functions. The first operand is a pointer to the - function to call; it is always an expression whose type is a - `POINTER_TYPE'. The second argument is a `TREE_LIST'. The - arguments to the call appear left-to-right in the list. The - `TREE_VALUE' of each list node contains the expression - corresponding to that argument. (The value of `TREE_PURPOSE' for - these nodes is unspecified, and should be ignored.) For non-static - member functions, there will be an operand corresponding to the - `this' pointer. There will always be expressions corresponding to - all of the arguments, even if the function is declared with default - arguments and some arguments are not explicitly provided at the - call sites. - -`STMT_EXPR' - These nodes are used to represent GCC's statement-expression - extension. The statement-expression extension allows code like - this: - int f() { return ({ int j; j = 3; j + 7; }); } - In other words, an sequence of statements may occur where a single - expression would normally appear. The `STMT_EXPR' node represents - such an expression. The `STMT_EXPR_STMT' gives the statement - contained in the expression; this is always a `COMPOUND_STMT'. The - value of the expression is the value of the last sub-statement in - the `COMPOUND_STMT'. More precisely, the value is the value - computed by the last `EXPR_STMT' in the outermost scope of the - `COMPOUND_STMT'. For example, in: - ({ 3; }) - the value is `3' while in: - ({ if (x) { 3; } }) - (represented by a nested `COMPOUND_STMT'), there is no value. If - the `STMT_EXPR' does not yield a value, it's type will be `void'. - -`BIND_EXPR' - These nodes represent local blocks. The first operand is a list of - temporary variables, connected via their `TREE_CHAIN' field. These - will never require cleanups. The scope of these variables is just - the body of the `BIND_EXPR'. The body of the `BIND_EXPR' is the - second operand. - -`LOOP_EXPR' - These nodes represent "infinite" loops. The `LOOP_EXPR_BODY' - represents the body of the loop. It should be executed forever, - unless an `EXIT_EXPR' is encountered. - -`EXIT_EXPR' - These nodes represent conditional exits from the nearest enclosing - `LOOP_EXPR'. The single operand is the condition; if it is - nonzero, then the loop should be exited. An `EXIT_EXPR' will only - appear within a `LOOP_EXPR'. - -`CLEANUP_POINT_EXPR' - These nodes represent full-expressions. The single operand is an - expression to evaluate. Any destructor calls engendered by the - creation of temporaries during the evaluation of that expression - should be performed immediately after the expression is evaluated. - -`CONSTRUCTOR' - These nodes represent the brace-enclosed initializers for a - structure or array. The first operand is reserved for use by the - back end. The second operand is a `TREE_LIST'. If the - `TREE_TYPE' of the `CONSTRUCTOR' is a `RECORD_TYPE' or - `UNION_TYPE', then the `TREE_PURPOSE' of each node in the - `TREE_LIST' will be a `FIELD_DECL' and the `TREE_VALUE' of each - node will be the expression used to initialize that field. You - should not depend on the fields appearing in any particular order, - nor should you assume that all fields will be represented. - Unrepresented fields may be assigned any value. - - If the `TREE_TYPE' of the `CONSTRUCTOR' is an `ARRAY_TYPE', then - the `TREE_PURPOSE' of each element in the `TREE_LIST' will be an - `INTEGER_CST'. This constant indicates which element of the array - (indexed from zero) is being assigned to; again, the `TREE_VALUE' - is the corresponding initializer. If the `TREE_PURPOSE' is - `NULL_TREE', then the initializer is for the next available array - element. - - Conceptually, before any initialization is done, the entire area of - storage is initialized to zero. - -`COMPOUND_LITERAL_EXPR' - These nodes represent ISO C99 compound literals. The - `COMPOUND_LITERAL_EXPR_DECL_STMT' is a `DECL_STMT' containing an - anonymous `VAR_DECL' for the unnamed object represented by the - compound literal; the `DECL_INITIAL' of that `VAR_DECL' is a - `CONSTRUCTOR' representing the brace-enclosed list of initializers - in the compound literal. That anonymous `VAR_DECL' can also be - accessed directly by the `COMPOUND_LITERAL_EXPR_DECL' macro. - -`SAVE_EXPR' - A `SAVE_EXPR' represents an expression (possibly involving - side-effects) that is used more than once. The side-effects should - occur only the first time the expression is evaluated. Subsequent - uses should just reuse the computed value. The first operand to - the `SAVE_EXPR' is the expression to evaluate. The side-effects - should be executed where the `SAVE_EXPR' is first encountered in a - depth-first preorder traversal of the expression tree. - -`TARGET_EXPR' - A `TARGET_EXPR' represents a temporary object. The first operand - is a `VAR_DECL' for the temporary variable. The second operand is - the initializer for the temporary. The initializer is evaluated, - and copied (bitwise) into the temporary. - - Often, a `TARGET_EXPR' occurs on the right-hand side of an - assignment, or as the second operand to a comma-expression which is - itself the right-hand side of an assignment, etc. In this case, - we say that the `TARGET_EXPR' is "normal"; otherwise, we say it is - "orphaned". For a normal `TARGET_EXPR' the temporary variable - should be treated as an alias for the left-hand side of the - assignment, rather than as a new temporary variable. - - The third operand to the `TARGET_EXPR', if present, is a - cleanup-expression (i.e., destructor call) for the temporary. If - this expression is orphaned, then this expression must be executed - when the statement containing this expression is complete. These - cleanups must always be executed in the order opposite to that in - which they were encountered. Note that if a temporary is created - on one branch of a conditional operator (i.e., in the second or - third operand to a `COND_EXPR'), the cleanup must be run only if - that branch is actually executed. - - See `STMT_IS_FULL_EXPR_P' for more information about running these - cleanups. - -`AGGR_INIT_EXPR' - An `AGGR_INIT_EXPR' represents the initialization as the return - value of a function call, or as the result of a constructor. An - `AGGR_INIT_EXPR' will only appear as the second operand of a - `TARGET_EXPR'. The first operand to the `AGGR_INIT_EXPR' is the - address of a function to call, just as in a `CALL_EXPR'. The - second operand are the arguments to pass that function, as a - `TREE_LIST', again in a manner similar to that of a `CALL_EXPR'. - The value of the expression is that returned by the function. - - If `AGGR_INIT_VIA_CTOR_P' holds of the `AGGR_INIT_EXPR', then the - initialization is via a constructor call. The address of the third - operand of the `AGGR_INIT_EXPR', which is always a `VAR_DECL', is - taken, and this value replaces the first argument in the argument - list. In this case, the value of the expression is the `VAR_DECL' - given by the third operand to the `AGGR_INIT_EXPR'; constructors do - not return a value. - -`VTABLE_REF' - A `VTABLE_REF' indicates that the interior expression computes a - value that is a vtable entry. It is used with `-fvtable-gc' to - track the reference through to front end to the middle end, at - which point we transform this to a `REG_VTABLE_REF' note, which - survives the balance of code generation. - - The first operand is the expression that computes the vtable - reference. The second operand is the `VAR_DECL' of the vtable. - The third operand is an `INTEGER_CST' of the byte offset into the - vtable. - - - -File: gccint.info, Node: RTL, Next: Machine Desc, Prev: Trees, Up: Top - -RTL Representation -****************** - - Most of the work of the compiler is done on an intermediate -representation called register transfer language. In this language, -the instructions to be output are described, pretty much one by one, in -an algebraic form that describes what the instruction does. - - RTL is inspired by Lisp lists. It has both an internal form, made -up of structures that point at other structures, and a textual form -that is used in the machine description and in printed debugging dumps. -The textual form uses nested parentheses to indicate the pointers in -the internal form. - -* Menu: - -* RTL Objects:: Expressions vs vectors vs strings vs integers. -* RTL Classes:: Categories of RTL expression objects, and their structure. -* Accessors:: Macros to access expression operands or vector elts. -* Flags:: Other flags in an RTL expression. -* Machine Modes:: Describing the size and format of a datum. -* Constants:: Expressions with constant values. -* Regs and Memory:: Expressions representing register contents or memory. -* Arithmetic:: Expressions representing arithmetic on other expressions. -* Comparisons:: Expressions representing comparison of expressions. -* Bit-Fields:: Expressions representing bit-fields in memory or reg. -* Vector Operations:: Expressions involving vector datatypes. -* Conversions:: Extending, truncating, floating or fixing. -* RTL Declarations:: Declaring volatility, constancy, etc. -* Side Effects:: Expressions for storing in registers, etc. -* Incdec:: Embedded side-effects for autoincrement addressing. -* Assembler:: Representing `asm' with operands. -* Insns:: Expression types for entire insns. -* Calls:: RTL representation of function call insns. -* Sharing:: Some expressions are unique; others *must* be copied. -* Reading RTL:: Reading textual RTL from a file. - - -File: gccint.info, Node: RTL Objects, Next: RTL Classes, Up: RTL - -RTL Object Types -================ - - RTL uses five kinds of objects: expressions, integers, wide integers, -strings and vectors. Expressions are the most important ones. An RTL -expression ("RTX", for short) is a C structure, but it is usually -referred to with a pointer; a type that is given the typedef name `rtx'. - - An integer is simply an `int'; their written form uses decimal -digits. A wide integer is an integral object whose type is -`HOST_WIDE_INT'; their written form uses decimal digits. - - A string is a sequence of characters. In core it is represented as a -`char *' in usual C fashion, and it is written in C syntax as well. -However, strings in RTL may never be null. If you write an empty -string in a machine description, it is represented in core as a null -pointer rather than as a pointer to a null character. In certain -contexts, these null pointers instead of strings are valid. Within RTL -code, strings are most commonly found inside `symbol_ref' expressions, -but they appear in other contexts in the RTL expressions that make up -machine descriptions. - - In a machine description, strings are normally written with double -quotes, as you would in C. However, strings in machine descriptions may -extend over many lines, which is invalid C, and adjacent string -constants are not concatenated as they are in C. Any string constant -may be surrounded with a single set of parentheses. Sometimes this -makes the machine description easier to read. - - There is also a special syntax for strings, which can be useful when -C code is embedded in a machine description. Wherever a string can -appear, it is also valid to write a C-style brace block. The entire -brace block, including the outermost pair of braces, is considered to be -the string constant. Double quote characters inside the braces are not -special. Therefore, if you write string constants in the C code, you -need not escape each quote character with a backslash. - - A vector contains an arbitrary number of pointers to expressions. -The number of elements in the vector is explicitly present in the -vector. The written form of a vector consists of square brackets -(`[...]') surrounding the elements, in sequence and with whitespace -separating them. Vectors of length zero are not created; null pointers -are used instead. - - Expressions are classified by "expression codes" (also called RTX -codes). The expression code is a name defined in `rtl.def', which is -also (in upper case) a C enumeration constant. The possible expression -codes and their meanings are machine-independent. The code of an RTX -can be extracted with the macro `GET_CODE (X)' and altered with -`PUT_CODE (X, NEWCODE)'. - - The expression code determines how many operands the expression -contains, and what kinds of objects they are. In RTL, unlike Lisp, you -cannot tell by looking at an operand what kind of object it is. -Instead, you must know from its context--from the expression code of -the containing expression. For example, in an expression of code -`subreg', the first operand is to be regarded as an expression and the -second operand as an integer. In an expression of code `plus', there -are two operands, both of which are to be regarded as expressions. In -a `symbol_ref' expression, there is one operand, which is to be -regarded as a string. - - Expressions are written as parentheses containing the name of the -expression type, its flags and machine mode if any, and then the -operands of the expression (separated by spaces). - - Expression code names in the `md' file are written in lower case, -but when they appear in C code they are written in upper case. In this -manual, they are shown as follows: `const_int'. - - In a few contexts a null pointer is valid where an expression is -normally wanted. The written form of this is `(nil)'. -