From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2197 invoked by alias); 14 Jul 2005 19:09:43 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 2172 invoked by uid 22791); 14 Jul 2005 19:09:38 -0000 Received: from sccrmhc14.comcast.net (HELO sccrmhc14.comcast.net) (204.127.202.59) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 14 Jul 2005 19:09:38 +0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (sccrmhc14) with SMTP id <2005071419093501400pq9qce>; Thu, 14 Jul 2005 19:09:36 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 14 Jul 2005 19:09:00 -0000 Subject: Re: Where does the C standard describe overflow of signed integers? From: Paul Schlie To: Matthew Woodcraft CC: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-07/txt/msg00608.txt.bz2 > Matthew Woodcraft writes: >> Paul Schlie wrote: >>As optimization seems to be a non-argument, as by analogy all >>optimizations which are available for unsigned arithmetic are >>correspondingly available for signed integer operations; as any signed >>value may then be thought of as being unsigned for the purposes of >>computation and/or comparison. > > What about optimising x*2/2 to x? Given that "C" requires the above be evaluated as (x*2)/2, as the language specifies that the syntax defines the precedence of the operations, and that no optimization should alter the behavior as specified by the program; I'd say that unless it was known that the value range of x was between 0 and INT_MAX, the optimization is simply invalid. As programmers should know and often rely on the finite range of integers to intentionally specify algebraically inconsistent transforms; which is why various precision integers, and in the infinite precision libraries are available for use when such overflow ambiguities are not acceptable or desired; the complier should simply do what is asked, not pretend it knows better, because it doesn't. However it seems quite reasonable and desirable for the compiler to provide feedback to the programmer, indicating that the expression specified may be portably algebraically simplified to "x", if the negative value overflow behavior was not intentionally desired; thereby enabling the programmer to improve both the portability and performance of their specified program, rather than assuming that a value altering optimization is desirable (which in general it never is, and typically only leads to difficult to diagnose problems, as the program isn't actually doing an equivalent of what was specified).