From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25957 invoked by alias); 28 Jun 2005 17:35:39 -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 25945 invoked by uid 22791); 28 Jun 2005 17:35:37 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 28 Jun 2005 17:35:37 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j5SHZaGY024401; Tue, 28 Jun 2005 13:35:36 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j5SHZZu31704; Tue, 28 Jun 2005 13:35:35 -0400 Received: from topo.toronto.redhat.com (vpn50-6.rdu.redhat.com [172.16.50.6]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id j5SHZWjL032228; Tue, 28 Jun 2005 13:35:34 -0400 Received: from topo.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by topo.toronto.redhat.com (8.13.4/8.13.4) with ESMTP id j5SHI4U9030666; Tue, 28 Jun 2005 13:18:05 -0400 Received: (from dnovillo@localhost) by topo.toronto.redhat.com (8.13.4/8.13.4/Submit) id j5SHI4cW030665; Tue, 28 Jun 2005 13:18:04 -0400 Date: Tue, 28 Jun 2005 17:35:00 -0000 From: Diego Novillo To: Gabriel Dos Reis Cc: Joe Buck , Michael Veksler , gcc@gcc.gnu.org Subject: Re: signed is undefined and has been since 1992 (in GCC) Message-ID: <20050628171804.GA30458@topo.toronto.redhat.com> References: <3dbad9a6bd7eb1aea74ff2245eaa1b99@physics.uc.edu> <20050628163249.GB9524@synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-SW-Source: 2005-06/txt/msg01157.txt.bz2 On Tue, Jun 28, 2005 at 07:02:49PM +0200, Gabriel Dos Reis wrote: > 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? > I fixed this bug yesterday. Scalar evolutions was assuming it couldn't wrap around. Diego.