From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21551 invoked by alias); 1 Mar 2008 12:31:14 -0000 Received: (qmail 21398 invoked by uid 22791); 1 Mar 2008 12:31:11 -0000 X-Spam-Check-By: sourceware.org Received: from mail.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 01 Mar 2008 12:30:51 +0000 Received: from Relay2.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 67B8E32810; Sat, 1 Mar 2008 13:30:49 +0100 (CET) Date: Sat, 01 Mar 2008 12:31:00 -0000 From: Richard Guenther To: Mark Mitchell Cc: gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: [PATCH][4.3] Deprecate -ftrapv In-Reply-To: <47C8AB88.10503@codesourcery.com> Message-ID: References: <47C89DB1.6030200@codesourcery.com> <47C8AB88.10503@codesourcery.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-03/txt/msg00030.txt.bz2 On Fri, 29 Feb 2008, Mark Mitchell wrote: > Richard Guenther wrote: > > > The tree optimizers do not recognize +-* of singed integers as > > possibly trapping which causes functions to become const/pure that > > should not and causes 'dead' code to be removed that should not. > > Thanks for the explanations. It seems like tree-ssa should in theory make it > easier to implement this; for example, at the point of gimplification one > could insert checks, and then just let everything else do its thing. I don't > see how libcalls and such would matter in that scheme. I'm not denying that > this is a project, though. I missed once point noticed by Joseph also, that the libgcc implementation uses signed types in the implementation of the trapping arithmetics. Where we of course optimize away the overflow check, so the libgcc routines will never trap. (if it does work in some cases then this would be a missed optimization, so sooner or later it is going to break more) I agree that all the problems can be fixed, but it's been several years that they didn't get fixed and we still advertise that feature as working. > I fully agree that claiming things work when they don't is bad -- we don't > want to lie to the users! But, is the failure mode that we issue run-time > errors when we shouldn't, or that we don't issue run-time errors when we > should? The latter is much less severe than the former. I believe it's both, as some optimizations still can introduce signed overflow, especially in the view of our interesting middle-end sizetype semantics. > I guess you've withdrawn the deprecation request, so maybe this is something > of a moot point now? I certainly agree that we shouldn't let a non-working > feature stand in the way of improvements in 4.4. Yes, removing the libcall notes around these calls will actually improve "workiness" of -ftrapv, so removing libcall notes will not make the situation worse here. Richard.