+++ /dev/null
-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.
-
-\1f
-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.
-
-
-\1f
-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.
-
-\1f
-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.
-
-
-\1f
-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.
-
-\1f
-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)'.
-
projects / msp430-gcc.git / blobdiff