From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23732 invoked by alias); 28 Jun 2005 17:03:36 -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 23670 invoked by uid 22791); 28 Jun 2005 17:03:30 -0000 Received: from smtp-102-tuesday.noc.nerim.net (HELO mallaury.noc.nerim.net) (62.4.17.102) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 28 Jun 2005 17:03:30 +0000 Received: from uniton.integrable-solutions.net (gdr.net1.nerim.net [62.212.99.186]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 8CD1862D14; Tue, 28 Jun 2005 19:03:26 +0200 (CEST) Received: from uniton.integrable-solutions.net (localhost [127.0.0.1]) by uniton.integrable-solutions.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5SH2nKY004503; Tue, 28 Jun 2005 19:02:50 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.10/8.12.10/Submit) id j5SH2n3V004502; Tue, 28 Jun 2005 19:02:49 +0200 To: Joe Buck Cc: Michael Veksler , gcc@gcc.gnu.org Subject: Re: signed is undefined and has been since 1992 (in GCC) References: <3dbad9a6bd7eb1aea74ff2245eaa1b99@physics.uc.edu> <20050628163249.GB9524@synopsys.com> From: Gabriel Dos Reis In-Reply-To: <20050628163249.GB9524@synopsys.com> Date: Tue, 28 Jun 2005 17:03:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-06/txt/msg01148.txt.bz2 Joe Buck writes: | 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: I think there is a slight misattribution in your message. The example was given my Michael. [...] | 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. We document that a = (int) ((unsigned) b + c) is well-defined and given by the wrapping semantics. Does the current optimizer takes that into account or will it assume b+1 execution times? If the optimizer takes that into account, then the question becomes when do we consider breaking the ABI to switch numeric_limits::is_modulo back to old behaviour. -- Gaby