From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20508 invoked by alias); 27 Feb 2009 12:07:54 -0000 Received: (qmail 20500 invoked by uid 22791); 27 Feb 2009 12:07:53 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from fg-out-1718.google.com (HELO fg-out-1718.google.com) (72.14.220.154) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 27 Feb 2009 12:07:46 +0000 Received: by fg-out-1718.google.com with SMTP id l27so604149fgb.28 for ; Fri, 27 Feb 2009 04:07:43 -0800 (PST) Received: by 10.86.53.11 with SMTP id b11mr3081197fga.76.1235736462988; Fri, 27 Feb 2009 04:07:42 -0800 (PST) Received: from ?82.6.108.62? (cpc2-cmbg8-0-0-cust61.cmbg.cable.ntl.com [82.6.108.62]) by mx.google.com with ESMTPS id f7sm1792338nfh.13.2009.02.27.04.07.41 (version=SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 04:07:42 -0800 (PST) Message-ID: <49A7D9B7.8050303@gmail.com> Date: Fri, 27 Feb 2009 12:07:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Richard Guenther CC: Zdenek Dvorak , gcc@gcc.gnu.org Subject: Re: New no-undefined-overflow branch References: <20090226230834.GA3470@kam.mff.cuni.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-02/txt/msg00449.txt.bz2 Richard Guenther wrote: > On Fri, 27 Feb 2009, Zdenek Dvorak wrote: >> introducing new codes seems like a bad idea to me. There are many >> places that do not care about the distinction between PLUS_EXPR and >> PLUSV_EXPR, and handling both cases will complicate the code (see eg. >> the problems caused by introducing POINTER_PLUS_EXPR vs PLUS_EXPR >> distinction). Why not just use a flag to mark the operation as >> non-overflowing? > > I obviously thought about this. The issue with using a flag is > that there is no convenient place to stick it and that it makes > the distinction between the two variants less visible. Consider > the folding routines that take split trees for a start. > > IMHO using new tree-codes is much less complicated than carrying > around flags. I did consider putting flags on the tree code > itself, but that isn't going to make the changes easier either. I think it's probably a far safer design too. If you suddenly introduce a new semantic for an existing code, suddenly every current check for that tree code becomes a potential bug site that has to be manually inspected to see if it's overflow-sensitive or not and therefore whether it needs to test the new flag or not; people who don't know about the new flag will carry on adding code that processes those tree codes without knowing to test the flag; and the bugs that do arise will be hard to find and result in silent bad codegen. If OTOH you add new tree codes, the meaning will be explicit, nobody using them can be under any misapprehension about the overflow semantics, nobody can forget to check the flag, and any places where they should be handled but aren't will very quickly draw themselves to our attention by ICEing, or if they don't will simply fall back to the safe option of not doing any processing on a tree code that they don't recognize; that might lead to pessimal code, but it shouldn't generate incorrect code. cheers, DaveK