Unary-and-Binary-Expressions.html 29 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624
  1. <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
  2. <html>
  3. <!-- Copyright (C) 1988-2017 Free Software Foundation, Inc.
  4. Permission is granted to copy, distribute and/or modify this document
  5. under the terms of the GNU Free Documentation License, Version 1.3 or
  6. any later version published by the Free Software Foundation; with the
  7. Invariant Sections being "Funding Free Software", the Front-Cover
  8. Texts being (a) (see below), and with the Back-Cover Texts being (b)
  9. (see below). A copy of the license is included in the section entitled
  10. "GNU Free Documentation License".
  11. (a) The FSF's Front-Cover Text is:
  12. A GNU Manual
  13. (b) The FSF's Back-Cover Text is:
  14. You have freedom to copy and modify this GNU Manual, like GNU
  15. software. Copies published by the Free Software Foundation raise
  16. funds for GNU development. -->
  17. <!-- Created by GNU Texinfo 5.2, http://www.gnu.org/software/texinfo/ -->
  18. <head>
  19. <title>GNU Compiler Collection (GCC) Internals: Unary and Binary Expressions</title>
  20. <meta name="description" content="GNU Compiler Collection (GCC) Internals: Unary and Binary Expressions">
  21. <meta name="keywords" content="GNU Compiler Collection (GCC) Internals: Unary and Binary Expressions">
  22. <meta name="resource-type" content="document">
  23. <meta name="distribution" content="global">
  24. <meta name="Generator" content="makeinfo">
  25. <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  26. <link href="index.html#Top" rel="start" title="Top">
  27. <link href="Option-Index.html#Option-Index" rel="index" title="Option Index">
  28. <link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
  29. <link href="Expression-trees.html#Expression-trees" rel="up" title="Expression trees">
  30. <link href="Vectors.html#Vectors" rel="next" title="Vectors">
  31. <link href="Storage-References.html#Storage-References" rel="prev" title="Storage References">
  32. <style type="text/css">
  33. <!--
  34. a.summary-letter {text-decoration: none}
  35. blockquote.smallquotation {font-size: smaller}
  36. div.display {margin-left: 3.2em}
  37. div.example {margin-left: 3.2em}
  38. div.indentedblock {margin-left: 3.2em}
  39. div.lisp {margin-left: 3.2em}
  40. div.smalldisplay {margin-left: 3.2em}
  41. div.smallexample {margin-left: 3.2em}
  42. div.smallindentedblock {margin-left: 3.2em; font-size: smaller}
  43. div.smalllisp {margin-left: 3.2em}
  44. kbd {font-style:oblique}
  45. pre.display {font-family: inherit}
  46. pre.format {font-family: inherit}
  47. pre.menu-comment {font-family: serif}
  48. pre.menu-preformatted {font-family: serif}
  49. pre.smalldisplay {font-family: inherit; font-size: smaller}
  50. pre.smallexample {font-size: smaller}
  51. pre.smallformat {font-family: inherit; font-size: smaller}
  52. pre.smalllisp {font-size: smaller}
  53. span.nocodebreak {white-space:nowrap}
  54. span.nolinebreak {white-space:nowrap}
  55. span.roman {font-family:serif; font-weight:normal}
  56. span.sansserif {font-family:sans-serif; font-weight:normal}
  57. ul.no-bullet {list-style: none}
  58. -->
  59. </style>
  60. </head>
  61. <body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
  62. <a name="Unary-and-Binary-Expressions"></a>
  63. <div class="header">
  64. <p>
  65. 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> &nbsp; [<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>
  66. </div>
  67. <hr>
  68. <a name="Unary-and-Binary-Expressions-1"></a>
  69. <h4 class="subsection">10.6.3 Unary and Binary Expressions</h4>
  70. <a name="index-NEGATE_005fEXPR"></a>
  71. <a name="index-ABS_005fEXPR"></a>
  72. <a name="index-BIT_005fNOT_005fEXPR"></a>
  73. <a name="index-TRUTH_005fNOT_005fEXPR"></a>
  74. <a name="index-PREDECREMENT_005fEXPR"></a>
  75. <a name="index-PREINCREMENT_005fEXPR"></a>
  76. <a name="index-POSTDECREMENT_005fEXPR"></a>
  77. <a name="index-POSTINCREMENT_005fEXPR"></a>
  78. <a name="index-FIX_005fTRUNC_005fEXPR"></a>
  79. <a name="index-FLOAT_005fEXPR"></a>
  80. <a name="index-COMPLEX_005fEXPR"></a>
  81. <a name="index-CONJ_005fEXPR"></a>
  82. <a name="index-REALPART_005fEXPR"></a>
  83. <a name="index-IMAGPART_005fEXPR"></a>
  84. <a name="index-NON_005fLVALUE_005fEXPR"></a>
  85. <a name="index-NOP_005fEXPR"></a>
  86. <a name="index-CONVERT_005fEXPR"></a>
  87. <a name="index-FIXED_005fCONVERT_005fEXPR"></a>
  88. <a name="index-THROW_005fEXPR"></a>
  89. <a name="index-LSHIFT_005fEXPR"></a>
  90. <a name="index-RSHIFT_005fEXPR"></a>
  91. <a name="index-BIT_005fIOR_005fEXPR"></a>
  92. <a name="index-BIT_005fXOR_005fEXPR"></a>
  93. <a name="index-BIT_005fAND_005fEXPR"></a>
  94. <a name="index-TRUTH_005fANDIF_005fEXPR"></a>
  95. <a name="index-TRUTH_005fORIF_005fEXPR"></a>
  96. <a name="index-TRUTH_005fAND_005fEXPR"></a>
  97. <a name="index-TRUTH_005fOR_005fEXPR"></a>
  98. <a name="index-TRUTH_005fXOR_005fEXPR"></a>
  99. <a name="index-POINTER_005fPLUS_005fEXPR"></a>
  100. <a name="index-PLUS_005fEXPR"></a>
  101. <a name="index-MINUS_005fEXPR"></a>
  102. <a name="index-MULT_005fEXPR"></a>
  103. <a name="index-MULT_005fHIGHPART_005fEXPR"></a>
  104. <a name="index-RDIV_005fEXPR"></a>
  105. <a name="index-TRUNC_005fDIV_005fEXPR"></a>
  106. <a name="index-FLOOR_005fDIV_005fEXPR"></a>
  107. <a name="index-CEIL_005fDIV_005fEXPR"></a>
  108. <a name="index-ROUND_005fDIV_005fEXPR"></a>
  109. <a name="index-TRUNC_005fMOD_005fEXPR"></a>
  110. <a name="index-FLOOR_005fMOD_005fEXPR"></a>
  111. <a name="index-CEIL_005fMOD_005fEXPR"></a>
  112. <a name="index-ROUND_005fMOD_005fEXPR"></a>
  113. <a name="index-EXACT_005fDIV_005fEXPR"></a>
  114. <a name="index-LT_005fEXPR"></a>
  115. <a name="index-LE_005fEXPR"></a>
  116. <a name="index-GT_005fEXPR"></a>
  117. <a name="index-GE_005fEXPR"></a>
  118. <a name="index-EQ_005fEXPR"></a>
  119. <a name="index-NE_005fEXPR"></a>
  120. <a name="index-ORDERED_005fEXPR"></a>
  121. <a name="index-UNORDERED_005fEXPR"></a>
  122. <a name="index-UNLT_005fEXPR"></a>
  123. <a name="index-UNLE_005fEXPR"></a>
  124. <a name="index-UNGT_005fEXPR"></a>
  125. <a name="index-UNGE_005fEXPR"></a>
  126. <a name="index-UNEQ_005fEXPR"></a>
  127. <a name="index-LTGT_005fEXPR"></a>
  128. <a name="index-MODIFY_005fEXPR"></a>
  129. <a name="index-INIT_005fEXPR"></a>
  130. <a name="index-COMPOUND_005fEXPR"></a>
  131. <a name="index-COND_005fEXPR"></a>
  132. <a name="index-CALL_005fEXPR"></a>
  133. <a name="index-STMT_005fEXPR"></a>
  134. <a name="index-BIND_005fEXPR"></a>
  135. <a name="index-LOOP_005fEXPR"></a>
  136. <a name="index-EXIT_005fEXPR"></a>
  137. <a name="index-CLEANUP_005fPOINT_005fEXPR"></a>
  138. <a name="index-CONSTRUCTOR"></a>
  139. <a name="index-COMPOUND_005fLITERAL_005fEXPR"></a>
  140. <a name="index-SAVE_005fEXPR"></a>
  141. <a name="index-TARGET_005fEXPR"></a>
  142. <a name="index-VA_005fARG_005fEXPR"></a>
  143. <a name="index-ANNOTATE_005fEXPR"></a>
  144. <dl compact="compact">
  145. <dt><code>NEGATE_EXPR</code></dt>
  146. <dd><p>These nodes represent unary negation of the single operand, for both
  147. integer and floating-point types. The type of negation can be
  148. determined by looking at the type of the expression.
  149. </p>
  150. <p>The behavior of this operation on signed arithmetic overflow is
  151. controlled by the <code>flag_wrapv</code> and <code>flag_trapv</code> variables.
  152. </p>
  153. </dd>
  154. <dt><code>ABS_EXPR</code></dt>
  155. <dd><p>These nodes represent the absolute value of the single operand, for
  156. both integer and floating-point types. This is typically used to
  157. implement the <code>abs</code>, <code>labs</code> and <code>llabs</code> builtins for
  158. integer types, and the <code>fabs</code>, <code>fabsf</code> and <code>fabsl</code>
  159. builtins for floating point types. The type of abs operation can
  160. be determined by looking at the type of the expression.
  161. </p>
  162. <p>This node is not used for complex types. To represent the modulus
  163. or complex abs of a complex value, use the <code>BUILT_IN_CABS</code>,
  164. <code>BUILT_IN_CABSF</code> or <code>BUILT_IN_CABSL</code> builtins, as used
  165. to implement the C99 <code>cabs</code>, <code>cabsf</code> and <code>cabsl</code>
  166. built-in functions.
  167. </p>
  168. </dd>
  169. <dt><code>BIT_NOT_EXPR</code></dt>
  170. <dd><p>These nodes represent bitwise complement, and will always have integral
  171. type. The only operand is the value to be complemented.
  172. </p>
  173. </dd>
  174. <dt><code>TRUTH_NOT_EXPR</code></dt>
  175. <dd><p>These nodes represent logical negation, and will always have integral
  176. (or boolean) type. The operand is the value being negated. The type
  177. of the operand and that of the result are always of <code>BOOLEAN_TYPE</code>
  178. or <code>INTEGER_TYPE</code>.
  179. </p>
  180. </dd>
  181. <dt><code>PREDECREMENT_EXPR</code></dt>
  182. <dt><code>PREINCREMENT_EXPR</code></dt>
  183. <dt><code>POSTDECREMENT_EXPR</code></dt>
  184. <dt><code>POSTINCREMENT_EXPR</code></dt>
  185. <dd><p>These nodes represent increment and decrement expressions. The value of
  186. the single operand is computed, and the operand incremented or
  187. decremented. In the case of <code>PREDECREMENT_EXPR</code> and
  188. <code>PREINCREMENT_EXPR</code>, the value of the expression is the value
  189. resulting after the increment or decrement; in the case of
  190. <code>POSTDECREMENT_EXPR</code> and <code>POSTINCREMENT_EXPR</code> is the value
  191. before the increment or decrement occurs. The type of the operand, like
  192. that of the result, will be either integral, boolean, or floating-point.
  193. </p>
  194. </dd>
  195. <dt><code>FIX_TRUNC_EXPR</code></dt>
  196. <dd><p>These nodes represent conversion of a floating-point value to an
  197. integer. The single operand will have a floating-point type, while
  198. the complete expression will have an integral (or boolean) type. The
  199. operand is rounded towards zero.
  200. </p>
  201. </dd>
  202. <dt><code>FLOAT_EXPR</code></dt>
  203. <dd><p>These nodes represent conversion of an integral (or boolean) value to a
  204. floating-point value. The single operand will have integral type, while
  205. the complete expression will have a floating-point type.
  206. </p>
  207. <p>FIXME: How is the operand supposed to be rounded? Is this dependent on
  208. <samp>-mieee</samp>?
  209. </p>
  210. </dd>
  211. <dt><code>COMPLEX_EXPR</code></dt>
  212. <dd><p>These nodes are used to represent complex numbers constructed from two
  213. expressions of the same (integer or real) type. The first operand is the
  214. real part and the second operand is the imaginary part.
  215. </p>
  216. </dd>
  217. <dt><code>CONJ_EXPR</code></dt>
  218. <dd><p>These nodes represent the conjugate of their operand.
  219. </p>
  220. </dd>
  221. <dt><code>REALPART_EXPR</code></dt>
  222. <dt><code>IMAGPART_EXPR</code></dt>
  223. <dd><p>These nodes represent respectively the real and the imaginary parts
  224. of complex numbers (their sole argument).
  225. </p>
  226. </dd>
  227. <dt><code>NON_LVALUE_EXPR</code></dt>
  228. <dd><p>These nodes indicate that their one and only operand is not an lvalue.
  229. A back end can treat these identically to the single operand.
  230. </p>
  231. </dd>
  232. <dt><code>NOP_EXPR</code></dt>
  233. <dd><p>These nodes are used to represent conversions that do not require any
  234. code-generation. For example, conversion of a <code>char*</code> to an
  235. <code>int*</code> does not require any code be generated; such a conversion is
  236. represented by a <code>NOP_EXPR</code>. The single operand is the expression
  237. to be converted. The conversion from a pointer to a reference is also
  238. represented with a <code>NOP_EXPR</code>.
  239. </p>
  240. </dd>
  241. <dt><code>CONVERT_EXPR</code></dt>
  242. <dd><p>These nodes are similar to <code>NOP_EXPR</code>s, but are used in those
  243. situations where code may need to be generated. For example, if an
  244. <code>int*</code> is converted to an <code>int</code> code may need to be generated
  245. on some platforms. These nodes are never used for C++-specific
  246. conversions, like conversions between pointers to different classes in
  247. an inheritance hierarchy. Any adjustments that need to be made in such
  248. cases are always indicated explicitly. Similarly, a user-defined
  249. conversion is never represented by a <code>CONVERT_EXPR</code>; instead, the
  250. function calls are made explicit.
  251. </p>
  252. </dd>
  253. <dt><code>FIXED_CONVERT_EXPR</code></dt>
  254. <dd><p>These nodes are used to represent conversions that involve fixed-point
  255. values. For example, from a fixed-point value to another fixed-point value,
  256. from an integer to a fixed-point value, from a fixed-point value to an
  257. integer, from a floating-point value to a fixed-point value, or from
  258. a fixed-point value to a floating-point value.
  259. </p>
  260. </dd>
  261. <dt><code>LSHIFT_EXPR</code></dt>
  262. <dt><code>RSHIFT_EXPR</code></dt>
  263. <dd><p>These nodes represent left and right shifts, respectively. The first
  264. operand is the value to shift; it will always be of integral type. The
  265. second operand is an expression for the number of bits by which to
  266. shift. Right shift should be treated as arithmetic, i.e., the
  267. high-order bits should be zero-filled when the expression has unsigned
  268. type and filled with the sign bit when the expression has signed type.
  269. Note that the result is undefined if the second operand is larger
  270. than or equal to the first operand&rsquo;s type size. Unlike most nodes, these
  271. can have a vector as first operand and a scalar as second operand.
  272. </p>
  273. </dd>
  274. <dt><code>BIT_IOR_EXPR</code></dt>
  275. <dt><code>BIT_XOR_EXPR</code></dt>
  276. <dt><code>BIT_AND_EXPR</code></dt>
  277. <dd><p>These nodes represent bitwise inclusive or, bitwise exclusive or, and
  278. bitwise and, respectively. Both operands will always have integral
  279. type.
  280. </p>
  281. </dd>
  282. <dt><code>TRUTH_ANDIF_EXPR</code></dt>
  283. <dt><code>TRUTH_ORIF_EXPR</code></dt>
  284. <dd><p>These nodes represent logical &ldquo;and&rdquo; and logical &ldquo;or&rdquo;, respectively.
  285. These operators are not strict; i.e., the second operand is evaluated
  286. only if the value of the expression is not determined by evaluation of
  287. the first operand. The type of the operands and that of the result are
  288. always of <code>BOOLEAN_TYPE</code> or <code>INTEGER_TYPE</code>.
  289. </p>
  290. </dd>
  291. <dt><code>TRUTH_AND_EXPR</code></dt>
  292. <dt><code>TRUTH_OR_EXPR</code></dt>
  293. <dt><code>TRUTH_XOR_EXPR</code></dt>
  294. <dd><p>These nodes represent logical and, logical or, and logical exclusive or.
  295. They are strict; both arguments are always evaluated. There are no
  296. corresponding operators in C or C++, but the front end will sometimes
  297. generate these expressions anyhow, if it can tell that strictness does
  298. not matter. The type of the operands and that of the result are
  299. always of <code>BOOLEAN_TYPE</code> or <code>INTEGER_TYPE</code>.
  300. </p>
  301. </dd>
  302. <dt><code>POINTER_PLUS_EXPR</code></dt>
  303. <dd><p>This node represents pointer arithmetic. The first operand is always
  304. a pointer/reference type. The second operand is always an unsigned
  305. integer type compatible with sizetype. This is the only binary
  306. arithmetic operand that can operate on pointer types.
  307. </p>
  308. </dd>
  309. <dt><code>PLUS_EXPR</code></dt>
  310. <dt><code>MINUS_EXPR</code></dt>
  311. <dt><code>MULT_EXPR</code></dt>
  312. <dd><p>These nodes represent various binary arithmetic operations.
  313. Respectively, these operations are addition, subtraction (of the second
  314. operand from the first) and multiplication. Their operands may have
  315. either integral or floating type, but there will never be case in which
  316. one operand is of floating type and the other is of integral type.
  317. </p>
  318. <p>The behavior of these operations on signed arithmetic overflow is
  319. controlled by the <code>flag_wrapv</code> and <code>flag_trapv</code> variables.
  320. </p>
  321. </dd>
  322. <dt><code>MULT_HIGHPART_EXPR</code></dt>
  323. <dd><p>This node represents the &ldquo;high-part&rdquo; of a widening multiplication.
  324. For an integral type with <var>b</var> bits of precision, the result is
  325. the most significant <var>b</var> bits of the full <em>2<var>b</var></em> product.
  326. </p>
  327. </dd>
  328. <dt><code>RDIV_EXPR</code></dt>
  329. <dd><p>This node represents a floating point division operation.
  330. </p>
  331. </dd>
  332. <dt><code>TRUNC_DIV_EXPR</code></dt>
  333. <dt><code>FLOOR_DIV_EXPR</code></dt>
  334. <dt><code>CEIL_DIV_EXPR</code></dt>
  335. <dt><code>ROUND_DIV_EXPR</code></dt>
  336. <dd><p>These nodes represent integer division operations that return an integer
  337. result. <code>TRUNC_DIV_EXPR</code> rounds towards zero, <code>FLOOR_DIV_EXPR</code>
  338. rounds towards negative infinity, <code>CEIL_DIV_EXPR</code> rounds towards
  339. positive infinity and <code>ROUND_DIV_EXPR</code> rounds to the closest integer.
  340. Integer division in C and C++ is truncating, i.e. <code>TRUNC_DIV_EXPR</code>.
  341. </p>
  342. <p>The behavior of these operations on signed arithmetic overflow, when
  343. dividing the minimum signed integer by minus one, is controlled by the
  344. <code>flag_wrapv</code> and <code>flag_trapv</code> variables.
  345. </p>
  346. </dd>
  347. <dt><code>TRUNC_MOD_EXPR</code></dt>
  348. <dt><code>FLOOR_MOD_EXPR</code></dt>
  349. <dt><code>CEIL_MOD_EXPR</code></dt>
  350. <dt><code>ROUND_MOD_EXPR</code></dt>
  351. <dd><p>These nodes represent the integer remainder or modulus operation.
  352. The integer modulus of two operands <code>a</code> and <code>b</code> is
  353. defined as <code>a - (a/b)*b</code> where the division calculated using
  354. the corresponding division operator. Hence for <code>TRUNC_MOD_EXPR</code>
  355. this definition assumes division using truncation towards zero, i.e.
  356. <code>TRUNC_DIV_EXPR</code>. Integer remainder in C and C++ uses truncating
  357. division, i.e. <code>TRUNC_MOD_EXPR</code>.
  358. </p>
  359. </dd>
  360. <dt><code>EXACT_DIV_EXPR</code></dt>
  361. <dd><p>The <code>EXACT_DIV_EXPR</code> code is used to represent integer divisions where
  362. the numerator is known to be an exact multiple of the denominator. This
  363. allows the backend to choose between the faster of <code>TRUNC_DIV_EXPR</code>,
  364. <code>CEIL_DIV_EXPR</code> and <code>FLOOR_DIV_EXPR</code> for the current target.
  365. </p>
  366. </dd>
  367. <dt><code>LT_EXPR</code></dt>
  368. <dt><code>LE_EXPR</code></dt>
  369. <dt><code>GT_EXPR</code></dt>
  370. <dt><code>GE_EXPR</code></dt>
  371. <dt><code>EQ_EXPR</code></dt>
  372. <dt><code>NE_EXPR</code></dt>
  373. <dd><p>These nodes represent the less than, less than or equal to, greater
  374. than, greater than or equal to, equal, and not equal comparison
  375. operators. The first and second operands will either be both of integral
  376. type, both of floating type or both of vector type. The result type of
  377. these expressions will always be of integral, boolean or signed integral
  378. vector type. These operations return the result type&rsquo;s zero value for
  379. false, the result type&rsquo;s one value for true, and a vector whose elements
  380. are zero (false) or minus one (true) for vectors.
  381. </p>
  382. <p>For floating point comparisons, if we honor IEEE NaNs and either operand
  383. is NaN, then <code>NE_EXPR</code> always returns true and the remaining operators
  384. always return false. On some targets, comparisons against an IEEE NaN,
  385. other than equality and inequality, may generate a floating point exception.
  386. </p>
  387. </dd>
  388. <dt><code>ORDERED_EXPR</code></dt>
  389. <dt><code>UNORDERED_EXPR</code></dt>
  390. <dd><p>These nodes represent non-trapping ordered and unordered comparison
  391. operators. These operations take two floating point operands and
  392. determine whether they are ordered or unordered relative to each other.
  393. If either operand is an IEEE NaN, their comparison is defined to be
  394. unordered, otherwise the comparison is defined to be ordered. The
  395. result type of these expressions will always be of integral or boolean
  396. type. These operations return the result type&rsquo;s zero value for false,
  397. and the result type&rsquo;s one value for true.
  398. </p>
  399. </dd>
  400. <dt><code>UNLT_EXPR</code></dt>
  401. <dt><code>UNLE_EXPR</code></dt>
  402. <dt><code>UNGT_EXPR</code></dt>
  403. <dt><code>UNGE_EXPR</code></dt>
  404. <dt><code>UNEQ_EXPR</code></dt>
  405. <dt><code>LTGT_EXPR</code></dt>
  406. <dd><p>These nodes represent the unordered comparison operators.
  407. These operations take two floating point operands and determine whether
  408. the operands are unordered or are less than, less than or equal to,
  409. greater than, greater than or equal to, or equal respectively. For
  410. example, <code>UNLT_EXPR</code> returns true if either operand is an IEEE
  411. NaN or the first operand is less than the second. With the possible
  412. exception of <code>LTGT_EXPR</code>, all of these operations are guaranteed
  413. not to generate a floating point exception. The result
  414. type of these expressions will always be of integral or boolean type.
  415. These operations return the result type&rsquo;s zero value for false,
  416. and the result type&rsquo;s one value for true.
  417. </p>
  418. </dd>
  419. <dt><code>MODIFY_EXPR</code></dt>
  420. <dd><p>These nodes represent assignment. The left-hand side is the first
  421. operand; the right-hand side is the second operand. The left-hand side
  422. will be a <code>VAR_DECL</code>, <code>INDIRECT_REF</code>, <code>COMPONENT_REF</code>, or
  423. other lvalue.
  424. </p>
  425. <p>These nodes are used to represent not only assignment with &lsquo;<samp>=</samp>&rsquo; but
  426. also compound assignments (like &lsquo;<samp>+=</samp>&rsquo;), by reduction to &lsquo;<samp>=</samp>&rsquo;
  427. assignment. In other words, the representation for &lsquo;<samp>i += 3</samp>&rsquo; looks
  428. just like that for &lsquo;<samp>i = i + 3</samp>&rsquo;.
  429. </p>
  430. </dd>
  431. <dt><code>INIT_EXPR</code></dt>
  432. <dd><p>These nodes are just like <code>MODIFY_EXPR</code>, but are used only when a
  433. variable is initialized, rather than assigned to subsequently. This
  434. means that we can assume that the target of the initialization is not
  435. used in computing its own value; any reference to the lhs in computing
  436. the rhs is undefined.
  437. </p>
  438. </dd>
  439. <dt><code>COMPOUND_EXPR</code></dt>
  440. <dd><p>These nodes represent comma-expressions. The first operand is an
  441. expression whose value is computed and thrown away prior to the
  442. evaluation of the second operand. The value of the entire expression is
  443. the value of the second operand.
  444. </p>
  445. </dd>
  446. <dt><code>COND_EXPR</code></dt>
  447. <dd><p>These nodes represent <code>?:</code> expressions. The first operand
  448. is of boolean or integral type. If it evaluates to a nonzero value,
  449. the second operand should be evaluated, and returned as the value of the
  450. expression. Otherwise, the third operand is evaluated, and returned as
  451. the value of the expression.
  452. </p>
  453. <p>The second operand must have the same type as the entire expression,
  454. unless it unconditionally throws an exception or calls a noreturn
  455. function, in which case it should have void type. The same constraints
  456. apply to the third operand. This allows array bounds checks to be
  457. represented conveniently as <code>(i &gt;= 0 &amp;&amp; i &lt; 10) ? i : abort()</code>.
  458. </p>
  459. <p>As a GNU extension, the C language front-ends allow the second
  460. operand of the <code>?:</code> operator may be omitted in the source.
  461. For example, <code>x ? : 3</code> is equivalent to <code>x ? x : 3</code>,
  462. assuming that <code>x</code> is an expression without side-effects.
  463. In the tree representation, however, the second operand is always
  464. present, possibly protected by <code>SAVE_EXPR</code> if the first
  465. argument does cause side-effects.
  466. </p>
  467. </dd>
  468. <dt><code>CALL_EXPR</code></dt>
  469. <dd><p>These nodes are used to represent calls to functions, including
  470. non-static member functions. <code>CALL_EXPR</code>s are implemented as
  471. expression nodes with a variable number of operands. Rather than using
  472. <code>TREE_OPERAND</code> to extract them, it is preferable to use the
  473. specialized accessor macros and functions that operate specifically on
  474. <code>CALL_EXPR</code> nodes.
  475. </p>
  476. <p><code>CALL_EXPR_FN</code> returns a pointer to the
  477. function to call; it is always an expression whose type is a
  478. <code>POINTER_TYPE</code>.
  479. </p>
  480. <p>The number of arguments to the call is returned by <code>call_expr_nargs</code>,
  481. while the arguments themselves can be accessed with the <code>CALL_EXPR_ARG</code>
  482. macro. The arguments are zero-indexed and numbered left-to-right.
  483. You can iterate over the arguments using <code>FOR_EACH_CALL_EXPR_ARG</code>, as in:
  484. </p>
  485. <div class="smallexample">
  486. <pre class="smallexample">tree call, arg;
  487. call_expr_arg_iterator iter;
  488. FOR_EACH_CALL_EXPR_ARG (arg, iter, call)
  489. /* arg is bound to successive arguments of call. */
  490. &hellip;;
  491. </pre></div>
  492. <p>For non-static
  493. member functions, there will be an operand corresponding to the
  494. <code>this</code> pointer. There will always be expressions corresponding to
  495. all of the arguments, even if the function is declared with default
  496. arguments and some arguments are not explicitly provided at the call
  497. sites.
  498. </p>
  499. <p><code>CALL_EXPR</code>s also have a <code>CALL_EXPR_STATIC_CHAIN</code> operand that
  500. is used to implement nested functions. This operand is otherwise null.
  501. </p>
  502. </dd>
  503. <dt><code>CLEANUP_POINT_EXPR</code></dt>
  504. <dd><p>These nodes represent full-expressions. The single operand is an
  505. expression to evaluate. Any destructor calls engendered by the creation
  506. of temporaries during the evaluation of that expression should be
  507. performed immediately after the expression is evaluated.
  508. </p>
  509. </dd>
  510. <dt><code>CONSTRUCTOR</code></dt>
  511. <dd><p>These nodes represent the brace-enclosed initializers for a structure or an
  512. array. They contain a sequence of component values made out of a vector of
  513. constructor_elt, which is a (<code>INDEX</code>, <code>VALUE</code>) pair.
  514. </p>
  515. <p>If the <code>TREE_TYPE</code> of the <code>CONSTRUCTOR</code> is a <code>RECORD_TYPE</code>,
  516. <code>UNION_TYPE</code> or <code>QUAL_UNION_TYPE</code> then the <code>INDEX</code> of each
  517. node in the sequence will be a <code>FIELD_DECL</code> and the <code>VALUE</code> will
  518. be the expression used to initialize that field.
  519. </p>
  520. <p>If the <code>TREE_TYPE</code> of the <code>CONSTRUCTOR</code> is an <code>ARRAY_TYPE</code>,
  521. then the <code>INDEX</code> of each node in the sequence will be an
  522. <code>INTEGER_CST</code> or a <code>RANGE_EXPR</code> of two <code>INTEGER_CST</code>s.
  523. A single <code>INTEGER_CST</code> indicates which element of the array is being
  524. assigned to. A <code>RANGE_EXPR</code> indicates an inclusive range of elements
  525. to initialize. In both cases the <code>VALUE</code> is the corresponding
  526. initializer. It is re-evaluated for each element of a
  527. <code>RANGE_EXPR</code>. If the <code>INDEX</code> is <code>NULL_TREE</code>, then
  528. the initializer is for the next available array element.
  529. </p>
  530. <p>In the front end, you should not depend on the fields appearing in any
  531. particular order. However, in the middle end, fields must appear in
  532. declaration order. You should not assume that all fields will be
  533. represented. Unrepresented fields will be cleared (zeroed), unless the
  534. CONSTRUCTOR_NO_CLEARING flag is set, in which case their value becomes
  535. undefined.
  536. </p>
  537. </dd>
  538. <dt><code>COMPOUND_LITERAL_EXPR</code></dt>
  539. <dd><a name="index-COMPOUND_005fLITERAL_005fEXPR_005fDECL_005fEXPR"></a>
  540. <a name="index-COMPOUND_005fLITERAL_005fEXPR_005fDECL"></a>
  541. <p>These nodes represent ISO C99 compound literals. The
  542. <code>COMPOUND_LITERAL_EXPR_DECL_EXPR</code> is a <code>DECL_EXPR</code>
  543. containing an anonymous <code>VAR_DECL</code> for
  544. the unnamed object represented by the compound literal; the
  545. <code>DECL_INITIAL</code> of that <code>VAR_DECL</code> is a <code>CONSTRUCTOR</code>
  546. representing the brace-enclosed list of initializers in the compound
  547. literal. That anonymous <code>VAR_DECL</code> can also be accessed directly
  548. by the <code>COMPOUND_LITERAL_EXPR_DECL</code> macro.
  549. </p>
  550. </dd>
  551. <dt><code>SAVE_EXPR</code></dt>
  552. <dd>
  553. <p>A <code>SAVE_EXPR</code> represents an expression (possibly involving
  554. side-effects) that is used more than once. The side-effects should
  555. occur only the first time the expression is evaluated. Subsequent uses
  556. should just reuse the computed value. The first operand to the
  557. <code>SAVE_EXPR</code> is the expression to evaluate. The side-effects should
  558. be executed where the <code>SAVE_EXPR</code> is first encountered in a
  559. depth-first preorder traversal of the expression tree.
  560. </p>
  561. </dd>
  562. <dt><code>TARGET_EXPR</code></dt>
  563. <dd><p>A <code>TARGET_EXPR</code> represents a temporary object. The first operand
  564. is a <code>VAR_DECL</code> for the temporary variable. The second operand is
  565. the initializer for the temporary. The initializer is evaluated and,
  566. if non-void, copied (bitwise) into the temporary. If the initializer
  567. is void, that means that it will perform the initialization itself.
  568. </p>
  569. <p>Often, a <code>TARGET_EXPR</code> occurs on the right-hand side of an
  570. assignment, or as the second operand to a comma-expression which is
  571. itself the right-hand side of an assignment, etc. In this case, we say
  572. that the <code>TARGET_EXPR</code> is &ldquo;normal&rdquo;; otherwise, we say it is
  573. &ldquo;orphaned&rdquo;. For a normal <code>TARGET_EXPR</code> the temporary variable
  574. should be treated as an alias for the left-hand side of the assignment,
  575. rather than as a new temporary variable.
  576. </p>
  577. <p>The third operand to the <code>TARGET_EXPR</code>, if present, is a
  578. cleanup-expression (i.e., destructor call) for the temporary. If this
  579. expression is orphaned, then this expression must be executed when the
  580. statement containing this expression is complete. These cleanups must
  581. always be executed in the order opposite to that in which they were
  582. encountered. Note that if a temporary is created on one branch of a
  583. conditional operator (i.e., in the second or third operand to a
  584. <code>COND_EXPR</code>), the cleanup must be run only if that branch is
  585. actually executed.
  586. </p>
  587. </dd>
  588. <dt><code>VA_ARG_EXPR</code></dt>
  589. <dd><p>This node is used to implement support for the C/C++ variable argument-list
  590. mechanism. It represents expressions like <code>va_arg (ap, type)</code>.
  591. Its <code>TREE_TYPE</code> yields the tree representation for <code>type</code> and
  592. its sole argument yields the representation for <code>ap</code>.
  593. </p>
  594. </dd>
  595. <dt><code>ANNOTATE_EXPR</code></dt>
  596. <dd><p>This node is used to attach markers to an expression. The first operand
  597. is the annotated expression, the second is an <code>INTEGER_CST</code> with
  598. a value from <code>enum annot_expr_kind</code>.
  599. </p></dd>
  600. </dl>
  601. <hr>
  602. <div class="header">
  603. <p>
  604. 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> &nbsp; [<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>
  605. </div>
  606. </body>
  607. </html>