diff options
Diffstat (limited to 'share/doc/gccint/Unary-and-Binary-Expressions.html')
| -rw-r--r-- | share/doc/gccint/Unary-and-Binary-Expressions.html | 651 |
1 files changed, 651 insertions, 0 deletions
diff --git a/share/doc/gccint/Unary-and-Binary-Expressions.html b/share/doc/gccint/Unary-and-Binary-Expressions.html new file mode 100644 index 0000000..f7b5eb8 --- /dev/null +++ b/share/doc/gccint/Unary-and-Binary-Expressions.html @@ -0,0 +1,651 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> +<html> +<!-- Copyright (C) 1988-2023 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.3 or +any later version published by the Free Software Foundation; with the +Invariant Sections being "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. --> +<!-- Created by GNU Texinfo 5.1, http://www.gnu.org/software/texinfo/ --> +<head> +<title>GNU Compiler Collection (GCC) Internals: Unary and Binary Expressions</title> + +<meta name="description" content="GNU Compiler Collection (GCC) Internals: Unary and Binary Expressions"> +<meta name="keywords" content="GNU Compiler Collection (GCC) Internals: Unary and Binary Expressions"> +<meta name="resource-type" content="document"> +<meta name="distribution" content="global"> +<meta name="Generator" content="makeinfo"> +<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> +<link href="index.html#Top" rel="start" title="Top"> +<link href="Option-Index.html#Option-Index" rel="index" title="Option Index"> +<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents"> +<link href="Expression-trees.html#Expression-trees" rel="up" title="Expression trees"> +<link href="Vectors.html#Vectors" rel="next" title="Vectors"> +<link href="Storage-References.html#Storage-References" rel="previous" title="Storage References"> +<style type="text/css"> +<!-- +a.summary-letter {text-decoration: none} +blockquote.smallquotation {font-size: smaller} +div.display {margin-left: 3.2em} +div.example {margin-left: 3.2em} +div.indentedblock {margin-left: 3.2em} +div.lisp {margin-left: 3.2em} +div.smalldisplay {margin-left: 3.2em} +div.smallexample {margin-left: 3.2em} +div.smallindentedblock {margin-left: 3.2em; font-size: smaller} +div.smalllisp {margin-left: 3.2em} +kbd {font-style:oblique} +pre.display {font-family: inherit} +pre.format {font-family: inherit} +pre.menu-comment {font-family: serif} +pre.menu-preformatted {font-family: serif} +pre.smalldisplay {font-family: inherit; font-size: smaller} +pre.smallexample {font-size: smaller} +pre.smallformat {font-family: inherit; font-size: smaller} +pre.smalllisp {font-size: smaller} +span.nocodebreak {white-space:nowrap} +span.nolinebreak {white-space:nowrap} +span.roman {font-family:serif; font-weight:normal} +span.sansserif {font-family:sans-serif; font-weight:normal} +ul.no-bullet {list-style: none} +--> +</style> + + +</head> + +<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000"> +<a name="Unary-and-Binary-Expressions"></a> +<div class="header"> +<p> +Next: <a href="Vectors.html#Vectors" accesskey="n" rel="next">Vectors</a>, Previous: <a href="Storage-References.html#Storage-References" accesskey="p" rel="previous">Storage References</a>, Up: <a href="Expression-trees.html#Expression-trees" accesskey="u" rel="up">Expression trees</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p> +</div> +<hr> +<a name="Unary-and-Binary-Expressions-1"></a> +<h4 class="subsection">11.6.3 Unary and Binary Expressions</h4> +<a name="index-NEGATE_005fEXPR"></a> +<a name="index-ABS_005fEXPR"></a> +<a name="index-ABSU_005fEXPR"></a> +<a name="index-BIT_005fNOT_005fEXPR"></a> +<a name="index-TRUTH_005fNOT_005fEXPR"></a> +<a name="index-PREDECREMENT_005fEXPR"></a> +<a name="index-PREINCREMENT_005fEXPR"></a> +<a name="index-POSTDECREMENT_005fEXPR"></a> +<a name="index-POSTINCREMENT_005fEXPR"></a> +<a name="index-FIX_005fTRUNC_005fEXPR"></a> +<a name="index-FLOAT_005fEXPR"></a> +<a name="index-COMPLEX_005fEXPR"></a> +<a name="index-CONJ_005fEXPR"></a> +<a name="index-REALPART_005fEXPR"></a> +<a name="index-IMAGPART_005fEXPR"></a> +<a name="index-NON_005fLVALUE_005fEXPR"></a> +<a name="index-NOP_005fEXPR"></a> +<a name="index-CONVERT_005fEXPR"></a> +<a name="index-FIXED_005fCONVERT_005fEXPR"></a> +<a name="index-THROW_005fEXPR"></a> +<a name="index-LSHIFT_005fEXPR"></a> +<a name="index-RSHIFT_005fEXPR"></a> +<a name="index-BIT_005fIOR_005fEXPR"></a> +<a name="index-BIT_005fXOR_005fEXPR"></a> +<a name="index-BIT_005fAND_005fEXPR"></a> +<a name="index-TRUTH_005fANDIF_005fEXPR"></a> +<a name="index-TRUTH_005fORIF_005fEXPR"></a> +<a name="index-TRUTH_005fAND_005fEXPR"></a> +<a name="index-TRUTH_005fOR_005fEXPR"></a> +<a name="index-TRUTH_005fXOR_005fEXPR"></a> +<a name="index-POINTER_005fPLUS_005fEXPR"></a> +<a name="index-POINTER_005fDIFF_005fEXPR"></a> +<a name="index-PLUS_005fEXPR"></a> +<a name="index-MINUS_005fEXPR"></a> +<a name="index-MULT_005fEXPR"></a> +<a name="index-WIDEN_005fMULT_005fEXPR"></a> +<a name="index-MULT_005fHIGHPART_005fEXPR"></a> +<a name="index-RDIV_005fEXPR"></a> +<a name="index-TRUNC_005fDIV_005fEXPR"></a> +<a name="index-FLOOR_005fDIV_005fEXPR"></a> +<a name="index-CEIL_005fDIV_005fEXPR"></a> +<a name="index-ROUND_005fDIV_005fEXPR"></a> +<a name="index-TRUNC_005fMOD_005fEXPR"></a> +<a name="index-FLOOR_005fMOD_005fEXPR"></a> +<a name="index-CEIL_005fMOD_005fEXPR"></a> +<a name="index-ROUND_005fMOD_005fEXPR"></a> +<a name="index-EXACT_005fDIV_005fEXPR"></a> +<a name="index-LT_005fEXPR"></a> +<a name="index-LE_005fEXPR"></a> +<a name="index-GT_005fEXPR"></a> +<a name="index-GE_005fEXPR"></a> +<a name="index-EQ_005fEXPR"></a> +<a name="index-NE_005fEXPR"></a> +<a name="index-ORDERED_005fEXPR"></a> +<a name="index-UNORDERED_005fEXPR"></a> +<a name="index-UNLT_005fEXPR"></a> +<a name="index-UNLE_005fEXPR"></a> +<a name="index-UNGT_005fEXPR"></a> +<a name="index-UNGE_005fEXPR"></a> +<a name="index-UNEQ_005fEXPR"></a> +<a name="index-LTGT_005fEXPR"></a> +<a name="index-MODIFY_005fEXPR"></a> +<a name="index-INIT_005fEXPR"></a> +<a name="index-COMPOUND_005fEXPR"></a> +<a name="index-COND_005fEXPR"></a> +<a name="index-CALL_005fEXPR"></a> +<a name="index-STMT_005fEXPR"></a> +<a name="index-BIND_005fEXPR"></a> +<a name="index-LOOP_005fEXPR"></a> +<a name="index-EXIT_005fEXPR"></a> +<a name="index-CLEANUP_005fPOINT_005fEXPR"></a> +<a name="index-CONSTRUCTOR"></a> +<a name="index-COMPOUND_005fLITERAL_005fEXPR"></a> +<a name="index-SAVE_005fEXPR"></a> +<a name="index-TARGET_005fEXPR"></a> +<a name="index-VA_005fARG_005fEXPR"></a> +<a name="index-ANNOTATE_005fEXPR"></a> + +<dl compact="compact"> +<dt><code>NEGATE_EXPR</code></dt> +<dd><p>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. +</p> +<p>The behavior of this operation on signed arithmetic overflow is +controlled by the <code>flag_wrapv</code> and <code>flag_trapv</code> variables. +</p> +</dd> +<dt><code>ABS_EXPR</code></dt> +<dd><p>These nodes represent the absolute value of the single operand, for +both integer and floating-point types. This is typically used to +implement the <code>abs</code>, <code>labs</code> and <code>llabs</code> builtins for +integer types, and the <code>fabs</code>, <code>fabsf</code> and <code>fabsl</code> +builtins for floating point types. The type of abs operation can +be determined by looking at the type of the expression. +</p> +<p>This node is not used for complex types. To represent the modulus +or complex abs of a complex value, use the <code>BUILT_IN_CABS</code>, +<code>BUILT_IN_CABSF</code> or <code>BUILT_IN_CABSL</code> builtins, as used +to implement the C99 <code>cabs</code>, <code>cabsf</code> and <code>cabsl</code> +built-in functions. +</p> +</dd> +<dt><code>ABSU_EXPR</code></dt> +<dd><p>These nodes represent the absolute value of the single operand in +equivalent unsigned type such that <code>ABSU_EXPR</code> of <code>TYPE_MIN</code> +is well defined. +</p> +</dd> +<dt><code>BIT_NOT_EXPR</code></dt> +<dd><p>These nodes represent bitwise complement, and will always have integral +type. The only operand is the value to be complemented. +</p> +</dd> +<dt><code>TRUTH_NOT_EXPR</code></dt> +<dd><p>These nodes represent logical negation, and will always have integral +(or boolean) type. The operand is the value being negated. The type +of the operand and that of the result are always of <code>BOOLEAN_TYPE</code> +or <code>INTEGER_TYPE</code>. +</p> +</dd> +<dt><code>PREDECREMENT_EXPR</code></dt> +<dt><code>PREINCREMENT_EXPR</code></dt> +<dt><code>POSTDECREMENT_EXPR</code></dt> +<dt><code>POSTINCREMENT_EXPR</code></dt> +<dd><p>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 <code>PREDECREMENT_EXPR</code> and +<code>PREINCREMENT_EXPR</code>, the value of the expression is the value +resulting after the increment or decrement; in the case of +<code>POSTDECREMENT_EXPR</code> and <code>POSTINCREMENT_EXPR</code> 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. +</p> +</dd> +<dt><code>FIX_TRUNC_EXPR</code></dt> +<dd><p>These nodes represent conversion of a floating-point value to an +integer. The single operand will have a floating-point type, while +the complete expression will have an integral (or boolean) type. The +operand is rounded towards zero. +</p> +</dd> +<dt><code>FLOAT_EXPR</code></dt> +<dd><p>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. +</p> +<p>FIXME: How is the operand supposed to be rounded? Is this dependent on +<samp>-mieee</samp>? +</p> +</dd> +<dt><code>COMPLEX_EXPR</code></dt> +<dd><p>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. +</p> +</dd> +<dt><code>CONJ_EXPR</code></dt> +<dd><p>These nodes represent the conjugate of their operand. +</p> +</dd> +<dt><code>REALPART_EXPR</code></dt> +<dt><code>IMAGPART_EXPR</code></dt> +<dd><p>These nodes represent respectively the real and the imaginary parts +of complex numbers (their sole argument). +</p> +</dd> +<dt><code>NON_LVALUE_EXPR</code></dt> +<dd><p>These nodes indicate that their one and only operand is not an lvalue. +A back end can treat these identically to the single operand. +</p> +</dd> +<dt><code>NOP_EXPR</code></dt> +<dd><p>These nodes are used to represent conversions that do not require any +code-generation. For example, conversion of a <code>char*</code> to an +<code>int*</code> does not require any code be generated; such a conversion is +represented by a <code>NOP_EXPR</code>. The single operand is the expression +to be converted. The conversion from a pointer to a reference is also +represented with a <code>NOP_EXPR</code>. +</p> +</dd> +<dt><code>CONVERT_EXPR</code></dt> +<dd><p>These nodes are similar to <code>NOP_EXPR</code>s, but are used in those +situations where code may need to be generated. For example, if an +<code>int*</code> is converted to an <code>int</code> 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 <code>CONVERT_EXPR</code>; instead, the +function calls are made explicit. +</p> +</dd> +<dt><code>FIXED_CONVERT_EXPR</code></dt> +<dd><p>These nodes are used to represent conversions that involve fixed-point +values. For example, from a fixed-point value to another fixed-point value, +from an integer to a fixed-point value, from a fixed-point value to an +integer, from a floating-point value to a fixed-point value, or from +a fixed-point value to a floating-point value. +</p> +</dd> +<dt><code>LSHIFT_EXPR</code></dt> +<dt><code>RSHIFT_EXPR</code></dt> +<dd><p>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 or equal to the first operand’s type size. Unlike most nodes, these +can have a vector as first operand and a scalar as second operand. +</p> + +</dd> +<dt><code>BIT_IOR_EXPR</code></dt> +<dt><code>BIT_XOR_EXPR</code></dt> +<dt><code>BIT_AND_EXPR</code></dt> +<dd><p>These nodes represent bitwise inclusive or, bitwise exclusive or, and +bitwise and, respectively. Both operands will always have integral +type. +</p> +</dd> +<dt><code>TRUTH_ANDIF_EXPR</code></dt> +<dt><code>TRUTH_ORIF_EXPR</code></dt> +<dd><p>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 that of the result are +always of <code>BOOLEAN_TYPE</code> or <code>INTEGER_TYPE</code>. +</p> +</dd> +<dt><code>TRUTH_AND_EXPR</code></dt> +<dt><code>TRUTH_OR_EXPR</code></dt> +<dt><code>TRUTH_XOR_EXPR</code></dt> +<dd><p>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. The type of the operands and that of the result are +always of <code>BOOLEAN_TYPE</code> or <code>INTEGER_TYPE</code>. +</p> +</dd> +<dt><code>POINTER_PLUS_EXPR</code></dt> +<dd><p>This node represents pointer arithmetic. The first operand is always +a pointer/reference type. The second operand is always an unsigned +integer type compatible with sizetype. This and POINTER_DIFF_EXPR are +the only binary arithmetic operators that can operate on pointer types. +</p> +</dd> +<dt><code>POINTER_DIFF_EXPR</code></dt> +<dd><p>This node represents pointer subtraction. The two operands always +have pointer/reference type. It returns a signed integer of the same +precision as the pointers. The behavior is undefined if the difference +of the two pointers, seen as infinite precision non-negative integers, +does not fit in the result type. The result does not depend on the +pointer type, it is not divided by the size of the pointed-to type. +</p> +</dd> +<dt><code>PLUS_EXPR</code></dt> +<dt><code>MINUS_EXPR</code></dt> +<dt><code>MULT_EXPR</code></dt> +<dd><p>These nodes represent various binary arithmetic operations. +Respectively, these operations are addition, subtraction (of the second +operand from the first) and multiplication. Their operands 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. +</p> +<p>The behavior of these operations on signed arithmetic overflow is +controlled by the <code>flag_wrapv</code> and <code>flag_trapv</code> variables. +</p> +</dd> +<dt><code>WIDEN_MULT_EXPR</code></dt> +<dd><p>This node represents a widening multiplication. The operands have +integral types with same <var>b</var> bits of precision, producing an +integral type result with at least <em>2<var>b</var></em> bits of precision. +The behaviour is equivalent to extending both operands, possibly of +different signedness, to the result type, then multiplying them. +</p> +</dd> +<dt><code>MULT_HIGHPART_EXPR</code></dt> +<dd><p>This node represents the “high-part” of a widening multiplication. +For an integral type with <var>b</var> bits of precision, the result is +the most significant <var>b</var> bits of the full <em>2<var>b</var></em> product. +Both operands must have the same precision and same signedness. +</p> +</dd> +<dt><code>RDIV_EXPR</code></dt> +<dd><p>This node represents a floating point division operation. +</p> +</dd> +<dt><code>TRUNC_DIV_EXPR</code></dt> +<dt><code>FLOOR_DIV_EXPR</code></dt> +<dt><code>CEIL_DIV_EXPR</code></dt> +<dt><code>ROUND_DIV_EXPR</code></dt> +<dd><p>These nodes represent integer division operations that return an integer +result. <code>TRUNC_DIV_EXPR</code> rounds towards zero, <code>FLOOR_DIV_EXPR</code> +rounds towards negative infinity, <code>CEIL_DIV_EXPR</code> rounds towards +positive infinity and <code>ROUND_DIV_EXPR</code> rounds to the closest integer. +Integer division in C and C++ is truncating, i.e. <code>TRUNC_DIV_EXPR</code>. +</p> +<p>The behavior of these operations on signed arithmetic overflow, when +dividing the minimum signed integer by minus one, is controlled by the +<code>flag_wrapv</code> and <code>flag_trapv</code> variables. +</p> +</dd> +<dt><code>TRUNC_MOD_EXPR</code></dt> +<dt><code>FLOOR_MOD_EXPR</code></dt> +<dt><code>CEIL_MOD_EXPR</code></dt> +<dt><code>ROUND_MOD_EXPR</code></dt> +<dd><p>These nodes represent the integer remainder or modulus operation. +The integer modulus of two operands <code>a</code> and <code>b</code> is +defined as <code>a - (a/b)*b</code> where the division calculated using +the corresponding division operator. Hence for <code>TRUNC_MOD_EXPR</code> +this definition assumes division using truncation towards zero, i.e. +<code>TRUNC_DIV_EXPR</code>. Integer remainder in C and C++ uses truncating +division, i.e. <code>TRUNC_MOD_EXPR</code>. +</p> +</dd> +<dt><code>EXACT_DIV_EXPR</code></dt> +<dd><p>The <code>EXACT_DIV_EXPR</code> code 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 <code>TRUNC_DIV_EXPR</code>, +<code>CEIL_DIV_EXPR</code> and <code>FLOOR_DIV_EXPR</code> for the current target. +</p> +</dd> +<dt><code>LT_EXPR</code></dt> +<dt><code>LE_EXPR</code></dt> +<dt><code>GT_EXPR</code></dt> +<dt><code>GE_EXPR</code></dt> +<dt><code>LTGT_EXPR</code></dt> +<dt><code>EQ_EXPR</code></dt> +<dt><code>NE_EXPR</code></dt> +<dd><p>These nodes represent the less than, less than or equal to, greater than, +greater than or equal to, less or greater than, equal, and not equal +comparison operators. The first and second operands will either be both +of integral type, both of floating type or both of vector type, except for +LTGT_EXPR where they will only be both of floating type. The result type +of these expressions will always be of integral, boolean or signed integral +vector type. These operations return the result type’s zero value for false, +the result type’s one value for true, and a vector whose elements are zero +(false) or minus one (true) for vectors. +</p> +<p>For floating point comparisons, if we honor IEEE NaNs and either operand +is NaN, then <code>NE_EXPR</code> 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. +</p> +</dd> +<dt><code>ORDERED_EXPR</code></dt> +<dt><code>UNORDERED_EXPR</code></dt> +<dd><p>These nodes represent non-trapping ordered and unordered comparison +operators. These operations take two floating point operands and +determine whether they are ordered or unordered relative to each other. +If either operand is an IEEE NaN, their comparison is defined to be +unordered, otherwise the comparison is defined to be ordered. 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. +</p> +</dd> +<dt><code>UNLT_EXPR</code></dt> +<dt><code>UNLE_EXPR</code></dt> +<dt><code>UNGT_EXPR</code></dt> +<dt><code>UNGE_EXPR</code></dt> +<dt><code>UNEQ_EXPR</code></dt> +<dd><p>These nodes represent the unordered comparison operators. +These operations take two floating point operands and determine whether +the operands are unordered or are less than, less than or equal to, +greater than, greater than or equal to, or equal respectively. For +example, <code>UNLT_EXPR</code> returns true if either operand is an IEEE +NaN or the first operand is less than the second. All 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. +</p> +</dd> +<dt><code>MODIFY_EXPR</code></dt> +<dd><p>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 <code>VAR_DECL</code>, <code>INDIRECT_REF</code>, <code>COMPONENT_REF</code>, or +other lvalue. +</p> +<p>These nodes are used to represent not only assignment with ‘<samp>=</samp>’ but +also compound assignments (like ‘<samp>+=</samp>’), by reduction to ‘<samp>=</samp>’ +assignment. In other words, the representation for ‘<samp>i += 3</samp>’ looks +just like that for ‘<samp>i = i + 3</samp>’. +</p> +</dd> +<dt><code>INIT_EXPR</code></dt> +<dd><p>These nodes are just like <code>MODIFY_EXPR</code>, 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. +</p> +</dd> +<dt><code>COMPOUND_EXPR</code></dt> +<dd><p>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. +</p> +</dd> +<dt><code>COND_EXPR</code></dt> +<dd><p>These nodes represent <code>?:</code> 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. +</p> +<p>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 <code>(i >= 0 && i < 10) ? i : abort()</code>. +</p> +<p>As a GNU extension, the C language front-ends allow the second +operand of the <code>?:</code> operator may be omitted in the source. +For example, <code>x ? : 3</code> is equivalent to <code>x ? x : 3</code>, +assuming that <code>x</code> is an expression without side effects. +In the tree representation, however, the second operand is always +present, possibly protected by <code>SAVE_EXPR</code> if the first +argument does cause side effects. +</p> +</dd> +<dt><code>CALL_EXPR</code></dt> +<dd><p>These nodes are used to represent calls to functions, including +non-static member functions. <code>CALL_EXPR</code>s are implemented as +expression nodes with a variable number of operands. Rather than using +<code>TREE_OPERAND</code> to extract them, it is preferable to use the +specialized accessor macros and functions that operate specifically on +<code>CALL_EXPR</code> nodes. +</p> +<p><code>CALL_EXPR_FN</code> returns a pointer to the +function to call; it is always an expression whose type is a +<code>POINTER_TYPE</code>. +</p> +<p>The number of arguments to the call is returned by <code>call_expr_nargs</code>, +while the arguments themselves can be accessed with the <code>CALL_EXPR_ARG</code> +macro. The arguments are zero-indexed and numbered left-to-right. +You can iterate over the arguments using <code>FOR_EACH_CALL_EXPR_ARG</code>, as in: +</p> +<div class="smallexample"> +<pre class="smallexample">tree call, arg; +call_expr_arg_iterator iter; +FOR_EACH_CALL_EXPR_ARG (arg, iter, call) + /* arg is bound to successive arguments of call. */ + …; +</pre></div> + +<p>For non-static +member functions, there will be an operand corresponding to the +<code>this</code> 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. +</p> +<p><code>CALL_EXPR</code>s also have a <code>CALL_EXPR_STATIC_CHAIN</code> operand that +is used to implement nested functions. This operand is otherwise null. +</p> +</dd> +<dt><code>CLEANUP_POINT_EXPR</code></dt> +<dd><p>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. +</p> +</dd> +<dt><code>CONSTRUCTOR</code></dt> +<dd><p>These nodes represent the brace-enclosed initializers for a structure or an +array. They contain a sequence of component values made out of a vector of +constructor_elt, which is a (<code>INDEX</code>, <code>VALUE</code>) pair. +</p> +<p>If the <code>TREE_TYPE</code> of the <code>CONSTRUCTOR</code> is a <code>RECORD_TYPE</code>, +<code>UNION_TYPE</code> or <code>QUAL_UNION_TYPE</code> then the <code>INDEX</code> of each +node in the sequence will be a <code>FIELD_DECL</code> and the <code>VALUE</code> will +be the expression used to initialize that field. +</p> +<p>If the <code>TREE_TYPE</code> of the <code>CONSTRUCTOR</code> is an <code>ARRAY_TYPE</code>, +then the <code>INDEX</code> of each node in the sequence will be an +<code>INTEGER_CST</code> or a <code>RANGE_EXPR</code> of two <code>INTEGER_CST</code>s. +A single <code>INTEGER_CST</code> indicates which element of the array is being +assigned to. A <code>RANGE_EXPR</code> indicates an inclusive range of elements +to initialize. In both cases the <code>VALUE</code> is the corresponding +initializer. It is re-evaluated for each element of a +<code>RANGE_EXPR</code>. If the <code>INDEX</code> is <code>NULL_TREE</code>, then +the initializer is for the next available array element. +</p> +<p>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 +undefined. +</p> +<a name="index-COMPOUND_005fLITERAL_005fEXPR_005fDECL_005fEXPR"></a> +<a name="index-COMPOUND_005fLITERAL_005fEXPR_005fDECL"></a> +</dd> +<dt><code>COMPOUND_LITERAL_EXPR</code></dt> +<dd><p>These nodes represent ISO C99 compound literals. The +<code>COMPOUND_LITERAL_EXPR_DECL_EXPR</code> is a <code>DECL_EXPR</code> +containing an anonymous <code>VAR_DECL</code> for +the unnamed object represented by the compound literal; the +<code>DECL_INITIAL</code> of that <code>VAR_DECL</code> is a <code>CONSTRUCTOR</code> +representing the brace-enclosed list of initializers in the compound +literal. That anonymous <code>VAR_DECL</code> can also be accessed directly +by the <code>COMPOUND_LITERAL_EXPR_DECL</code> macro. +</p> +</dd> +<dt><code>SAVE_EXPR</code></dt> +<dd> +<p>A <code>SAVE_EXPR</code> 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 +<code>SAVE_EXPR</code> is the expression to evaluate. The side effects should +be executed where the <code>SAVE_EXPR</code> is first encountered in a +depth-first preorder traversal of the expression tree. +</p> +</dd> +<dt><code>TARGET_EXPR</code></dt> +<dd><p>A <code>TARGET_EXPR</code> represents a temporary object. The first operand +is a <code>VAR_DECL</code> for 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. +</p> +<p>Often, a <code>TARGET_EXPR</code> 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 <code>TARGET_EXPR</code> is “normal”; otherwise, we say it is +“orphaned”. For a normal <code>TARGET_EXPR</code> the temporary variable +should be treated as an alias for the left-hand side of the assignment, +rather than as a new temporary variable. +</p> +<p>The third operand to the <code>TARGET_EXPR</code>, 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 +<code>COND_EXPR</code>), the cleanup must be run only if that branch is +actually executed. +</p> +</dd> +<dt><code>VA_ARG_EXPR</code></dt> +<dd><p>This node is used to implement support for the C/C++ variable argument-list +mechanism. It represents expressions like <code>va_arg (ap, type)</code>. +Its <code>TREE_TYPE</code> yields the tree representation for <code>type</code> and +its sole argument yields the representation for <code>ap</code>. +</p> +</dd> +<dt><code>ANNOTATE_EXPR</code></dt> +<dd><p>This node is used to attach markers to an expression. The first operand +is the annotated expression, the second is an <code>INTEGER_CST</code> with +a value from <code>enum annot_expr_kind</code>, the third is an <code>INTEGER_CST</code>. +</p></dd> +</dl> + + +<hr> +<div class="header"> +<p> +Next: <a href="Vectors.html#Vectors" accesskey="n" rel="next">Vectors</a>, Previous: <a href="Storage-References.html#Storage-References" accesskey="p" rel="previous">Storage References</a>, Up: <a href="Expression-trees.html#Expression-trees" accesskey="u" rel="up">Expression trees</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p> +</div> + + + +</body> +</html> |