From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28573 invoked by alias); 28 Jun 2005 16:32:59 -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 28537 invoked by uid 22791); 28 Jun 2005 16:32:51 -0000 Received: from us01smtp2.synopsys.com (HELO kiruna.synopsys.com) (198.182.44.80) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 28 Jun 2005 16:32:51 +0000 Received: from mother.synopsys.com (mother.synopsys.com [146.225.100.171]) by kiruna.synopsys.com (Postfix) with ESMTP id DF25CF4D6; Tue, 28 Jun 2005 09:33:45 -0700 (PDT) Received: from piper.synopsys.com (localhost [127.0.0.1]) by mother.synopsys.com (8.9.1/8.9.1) with ESMTP id JAA23753; Tue, 28 Jun 2005 09:32:49 -0700 (PDT) Received: from piper.synopsys.com (localhost [127.0.0.1]) by piper.synopsys.com (8.12.10/8.12.3) with ESMTP id j5SGWnOe009573; Tue, 28 Jun 2005 09:32:49 -0700 Received: (from jbuck@localhost) by piper.synopsys.com (8.12.10/8.12.10/Submit) id j5SGWn0c009571; Tue, 28 Jun 2005 09:32:49 -0700 Date: Tue, 28 Jun 2005 16:32:00 -0000 From: Joe Buck To: Michael Veksler Cc: gcc@gcc.gnu.org Subject: Re: signed is undefined and has been since 1992 (in GCC) Message-ID: <20050628163249.GB9524@synopsys.com> References: <3dbad9a6bd7eb1aea74ff2245eaa1b99@physics.uc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-SW-Source: 2005-06/txt/msg01137.txt.bz2 On Tue, Jun 28, 2005 at 10:23:51AM +0300, Michael Veksler wrote: On Jun 28, 2005, at 1:12 AM, Gabriel Dos Reis wrote: > > > So, > > > please, do refrain from reasoning like "since we did X for Y and Y was > > > undefined behaviour, we should do the same for Z." "Undefined > > > behaviour" isn't a 0 or 1 thingy, even though it is about computers. > > > You need to evaluate them on case-by-case basis. Andrew Pinski wrote on 28/06/2005 08:34:25: > Gaby, I am not sure you can do that in a reliable way. You may end up > with different behavior of overflow in the following two cases: > 1. for (int i = x ; i <= y ; ++i) > { > // this loop can be eliminated - overflow case (y == MAX_INT) > // is undefined. > q= s + 5; // moved outside the loop. > } > 2. a = b + c; // modulo > > If you treat overflow in case 1 differently than in case 2 then > you get into many inconsistencies and corner cases. In digital logic optimization we speak of "don't cares". This means that we have certain input combinations that we don't care about, but we must produce correct logic for all the cases that we do care about. It's really just the same for producing a compiler that matches a spec: We want to produce the cheapest possible circuit/program, by taking maximal advantage of the degrees of freedom provided by the don't-cares. Andrew, you're exactly right that we can't define the behavior in a reliable way, and THAT IS EXACTLY THE POINT. We want to produce the most efficient possible implementation for the cases that *are* defined, and the behavior for the undefined cases naturally falls out of that. You've actually given us an excellent example above. Consider a processor whose integer addition instruction wraps. Then the cheapest implementation for examples 1 and 2 above that cover the defined cases is to eliminate the loop in case 1, and produce a modulo result in case 2. You worried about interaction between the two constructs. Consider /* int a, b, c; */ if (b > 0) { a = b + c; int count; for (int i = c; i <= a; i++) count++; some_func(count); } Since behavior on integer overflow is undefined, we can optimize assuming that overflow has not occurred. Then a > c, so the for loop always executes b+1 times, and we end up with if (b > 0) some_func(b+1); Any attempt to assign meaning to integer overflow would prevent this optimization.