The behavior of this operation on signed arithmetic overflow is
controlled by the
llabsbuiltins for integer types, and the
fabslbuiltins for floating point types. The type of abs operation can be determined by looking at the type of the expression.
This node is not used for complex types. To represent the modulus
or complex abs of a complex value, use the
BUILT_IN_CABSL builtins, as used
to implement the C99
PREINCREMENT_EXPR, the value of the expression is the value resulting after the increment or decrement; in the case of
POSTINCREMENT_EXPRis 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.
FIXME: How is the operand supposed to be rounded? Is this dependent on
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_EXPRs, but are used in those situations where code may need to be generated. For example, if an
int*is converted to an
intcode 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.
The behavior of these operations on signed arithmetic overflow is
controlled by the
TRUNC_DIV_EXPRrounds towards zero,
FLOOR_DIV_EXPRrounds towards negative infinity,
CEIL_DIV_EXPRrounds towards positive infinity and
ROUND_DIV_EXPRrounds to the closest integer. Integer division in C and C++ is truncating, i.e.
The behavior of these operations on signed arithmetic overflow, when
dividing the minimum signed integer by minus one, is controlled by the
bis defined as
a - (a/b)*bwhere the division calculated using the corresponding division operator. Hence for
TRUNC_MOD_EXPRthis definition assumes division using truncation towards zero, i.e.
TRUNC_DIV_EXPR. Integer remainder in C and C++ uses truncating division, i.e.
EXACT_DIV_EXPRcode is used to represent integer divisions where the numerator is known to be an exact multiple of the denominator. This allows the backend to choose between the faster of
FLOOR_DIV_EXPRfor the current target.
For floating point comparisons, if we honor IEEE NaNs and either operand
is NaN, then
NE_EXPR always returns true and the remaining operators
always return false. On some targets, comparisons against an IEEE NaN,
other than equality and inequality, may generate a floating point exception.
UNLT_EXPRreturns true if either operand is an IEEE NaN or the first operand is less than the second. With the possible exception of
LTGT_EXPR, all of these operations are guaranteed not to generate a floating point exception. The result type of these expressions will always be of integral or boolean type. These operations return the result type's zero value for false, and the result type's one value for true.
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’.
MODIFY_EXPR, but are used only when a variable is initialized, rather than assigned to subsequently. This means that we can assume that the target of the initialization is not used in computing its own value; any reference to the lhs in computing the rhs is undefined.
?: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.
The second operand must have the same type as the entire expression,
unless it unconditionally throws an exception or calls a noreturn
function, in which case it should have void type. The same constraints
apply to the third operand. This allows array bounds checks to be
represented conveniently as
(i >= 0 && i < 10) ? i : abort().
As a GNU extension, the C language front-ends allow the second
operand of the
?: operator may be omitted in the source.
x ? : 3 is equivalent to
x ? x : 3,
x is an expression without side-effects.
In the tree representation, however, the second operand is always
present, possibly protected by
SAVE_EXPR if the first
argument does cause side-effects.
CALL_EXPRs are implemented as expression nodes with a variable number of operands. Rather than using
TREE_OPERANDto extract them, it is preferable to use the specialized accessor macros and functions that operate specifically on
CALL_EXPR_FN returns a pointer to the
function to call; it is always an expression whose type is a
The number of arguments to the call is returned by
while the arguments themselves can be accessed with the
macro. The arguments are zero-indexed and numbered left-to-right.
You can iterate over the arguments using
FOR_EACH_CALL_EXPR_ARG, as in:
tree call, arg; call_expr_arg_iterator iter; FOR_EACH_CALL_EXPR_ARG (arg, iter, call) /* arg is bound to successive arguments of call. */ ...;
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
CALL_EXPRs also have a
CALL_EXPR_STATIC_CHAIN operand that
is used to implement nested functions. This operand is otherwise null.
TREE_TYPE of the
CONSTRUCTOR is a
QUAL_UNION_TYPE then the
INDEX of each
node in the sequence will be a
FIELD_DECL and the
be the expression used to initialize that field.
TREE_TYPE of the
CONSTRUCTOR is an
INDEX of each node in the sequence will be an
INTEGER_CST or a
RANGE_EXPR of two
INTEGER_CST indicates which element of the array is being
assigned to. A
RANGE_EXPR indicates an inclusive range of elements
to initialize. In both cases the
VALUE is the corresponding
initializer. It is re-evaluated for each element of a
RANGE_EXPR. If the
the initializer is for the next available array element.
In the front end, you should not depend on the fields appearing in any
particular order. However, in the middle end, fields must appear in
declaration order. You should not assume that all fields will be
represented. Unrepresented fields will be cleared (zeroed), unless the
CONSTRUCTOR_NO_CLEARING flag is set, in which case their value becomes
DECL_EXPRcontaining an anonymous
VAR_DECLfor the unnamed object represented by the compound literal; the
CONSTRUCTORrepresenting the brace-enclosed list of initializers in the compound literal. That anonymous
VAR_DECLcan also be accessed directly by the
SAVE_EXPRrepresents 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_EXPRis the expression to evaluate. The side-effects should be executed where the
SAVE_EXPRis first encountered in a depth-first preorder traversal of the expression tree.
TARGET_EXPRrepresents a temporary object. The first operand is a
VAR_DECLfor the temporary variable. The second operand is the initializer for the temporary. The initializer is evaluated and, if non-void, copied (bitwise) into the temporary. If the initializer is void, that means that it will perform the initialization itself.
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
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
va_arg (ap, type). Its
TREE_TYPEyields the tree representation for
typeand its sole argument yields the representation for
INTEGER_CSTwith a value from