| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> |
| <html> |
| <!-- Copyright (C) 1988-2015 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.2, 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="prev" 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="prev">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">10.6.3 Unary and Binary Expressions</h4> |
| <a name="index-NEGATE_005fEXPR"></a> |
| <a name="index-ABS_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-PLUS_005fEXPR"></a> |
| <a name="index-MINUS_005fEXPR"></a> |
| <a name="index-MULT_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>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 is the only binary |
| arithmetic operand that can operate on pointer types. |
| </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>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. |
| </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>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, 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. 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> |
| <dt><code>LTGT_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. With the possible |
| exception of <code>LTGT_EXPR</code>, 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. |
| </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> |
| </dd> |
| <dt><code>COMPOUND_LITERAL_EXPR</code></dt> |
| <dd><a name="index-COMPOUND_005fLITERAL_005fEXPR_005fDECL_005fEXPR"></a> |
| <a name="index-COMPOUND_005fLITERAL_005fEXPR_005fDECL"></a> |
| <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>. |
| </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="prev">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> |