From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24003 invoked by alias); 28 Jun 2005 18:09:22 -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 23932 invoked by uid 22791); 28 Jun 2005 18:09:10 -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 18:09:10 +0000 Received: from uniton.integrable-solutions.net (gdr.net1.nerim.net [62.212.99.186]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 3BB9862D02; Tue, 28 Jun 2005 20:09:06 +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 j5SI8TKY004811; Tue, 28 Jun 2005 20:08:30 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.10/8.12.10/Submit) id j5SI8TdW004810; Tue, 28 Jun 2005 20:08:29 +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> <20050628173432.GA9783@synopsys.com> From: Gabriel Dos Reis In-Reply-To: <20050628173432.GA9783@synopsys.com> Date: Tue, 28 Jun 2005 18:09:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-06/txt/msg01164.txt.bz2 Joe Buck writes: | On Tue, Jun 28, 2005 at 07:02:49PM +0200, Gabriel Dos Reis wrote: | > | 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? | | C/C++ require unsigned to be modulo, and I think it is perfectly | appropriate to define the cast from unsigned to int to assume two's | complement behavior. But if unsigned variables are involved, in my | example the compiler is forced to produce worse code (it must cover | the case of wraparound). >From Diego's mail, I understand that the loop optimizer was way too aggressive in its assumptions and it is fixed now. So, the next logical step would be to have the semantics well-documented. | > If the optimizer takes that into account, then the question becomes | > when do we consider breaking the ABI to switch numeric_limits type>::is_modulo back to old behaviour. | | I think that defining signed types as is_modulo is broken, but I'm not | sure what consequences follow from this problem (e.g. what kind of user | code is using this feature, and for what). numeric_limits::is_modulo is part of the core C++ language (not just the library) and any change to that value implies an ABI change, in the sense any use of numeric_limits::is_modulo in template declarations (e.g. SFINAE hackery) gets mangled the same but instantiate to a different function. I would expect such hackery to be localized, but it is an ABI change and we must know that (whatever is decided after). -- Gaby