This is the mail archive of the
`gcc-patches@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Roger Sayle <roger at www dot eyesopen dot com>*To*: gcc-patches at gcc dot gnu dot org*Date*: Wed, 12 Feb 2003 21:31:51 -0700 (MST)*Subject*: [PATCH] Document arithmetic overflow semantics

Not being afraid of a potentially controversial topic, I thought I'd take the opportunity to document the overflow semantics of GCC's internal tree representation of arithmetic operations. The behaviour below is that required by the Java front-end, and currently guaranteed by all GCC backends. Formally documenting this contract avoid confusion and misunderstanding, and prevents bugs from creeping into the compiler. It even allows GCC's optimizers to uniformly take advantage of these previously "unwritten" rules. Failures to adhere to these guidelines should be reported to GNATS in the usual manner :> I'll do my best to fix them. Ok for mainline? 2003-02-12 Roger Sayle <roger@eyesopen.com> * doc/c-tree.texi: Clarify the semantics of GCC's arithmetic tree nodes. Index: c-tree.texi =================================================================== RCS file: /cvs/gcc/gcc/gcc/doc/c-tree.texi,v retrieving revision 1.40 diff -c -3 -p -r1.40 c-tree.texi *** c-tree.texi 7 Feb 2003 14:44:19 -0000 1.40 --- c-tree.texi 13 Feb 2003 04:49:07 -0000 *************** These nodes represent unary negation of *** 1913,1918 **** --- 1913,1924 ---- integer and floating-point types. The type of negation can be determined by looking at the type of the expression. + For integral types, negation is the same as subtraction from zero. + Because the range of two's-complement values in not symmetric, the + negation of the maximum negative integer results in the same maximum + negative number. For all integer values @code{x}, @code{-x} equals + @code{(~x)+1}, where the addition is computed by a @code{PLUS_EXPR}. + @item BIT_NOT_EXPR These nodes represent bitwise complement, and will always have integral type. The only operand is the value to be complemented. *************** The result of a @code{TRUNC_DIV_EXPR} is *** 2065,2070 **** --- 2071,2082 ---- The @code{TRUNC_MOD_EXPR} of two operands @code{a} and @code{b} is always @code{a - (a/b)*b} where the division is as if computed by a @code{TRUNC_DIV_EXPR}. + + If the result of an integral arithmetic operation overflows, then the + result is the low order bits of that mathematical operation as represented + in some sufficiently large two's-complement format. If overflow occurs + of a signed integral type, then the sign of the result may not be the + same as the mathematical operation on the two operand values. @item ARRAY_REF These nodes represent array accesses. The first operand is the array; Roger -- Roger Sayle, E-mail: roger@eyesopen.com OpenEye Scientific Software, WWW: http://www.eyesopen.com/ Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385 Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833

**Follow-Ups**:**Re: [PATCH] Document arithmetic overflow semantics***From:*Joseph S. Myers

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |