From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26567 invoked by alias); 13 Feb 2003 18:33:27 -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 26545 invoked from network); 13 Feb 2003 18:33:26 -0000 Received: from unknown (HELO executor.cambridge.redhat.com) (213.86.99.237) by 172.16.49.205 with SMTP; 13 Feb 2003 18:33:26 -0000 Received: from cuddles.cambridge.redhat.com (vpn50-1.rdu.redhat.com [172.16.50.1]) by executor.cambridge.redhat.com (Postfix) with ESMTP id 115C6ABB08; Thu, 13 Feb 2003 18:33:23 +0000 (GMT) Received: (from aph@localhost) by cuddles.cambridge.redhat.com (8.11.6/8.11.0) id h1DIXFH03680; Thu, 13 Feb 2003 18:33:15 GMT From: Andrew Haley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15947.58603.472058.802006@cuddles.cambridge.redhat.com> Date: Thu, 13 Feb 2003 18:44:00 -0000 To: Roger Sayle Cc: Richard Henderson , gcc-patches@gcc.gnu.org, Subject: Re: [PATCH] Document arithmetic overflow semantics In-Reply-To: References: <20030213175851.GC12198@redhat.com> X-SW-Source: 2003-02/txt/msg00961.txt.bz2 Roger Sayle writes: > > > Do you believe the Java front-end is currently incorrect to use > PLUS_EXPR to represent signed addition? It probably is. Java requires strict 32-bit two's complement arithmetic for its ints, and PLUS_EXPR isn't guaranteed to do that. We could, of course, generate something like uint((ulong)a + (ulong)b) which would be well defined. Andrew.