From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17001 invoked by alias); 8 Apr 2008 20:12:38 -0000 Received: (qmail 16989 invoked by uid 22791); 8 Apr 2008 20:12:37 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 08 Apr 2008 20:12:10 +0000 Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id m38KBptZ004369; Tue, 8 Apr 2008 21:11:51 +0100 Received: from localhost.localdomain.google.com (dhcp-172-18-118-233.corp.google.com [172.18.118.233]) (authenticated bits=0) by zps38.corp.google.com with ESMTP id m38KBoYn003364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Apr 2008 13:11:50 -0700 To: Mark Mitchell Cc: gcc-patches@gcc.gnu.org Subject: Re: PATCH RFC: Warn about pointer wraparound with -Wstrict-overflow References: <47FBBD7E.2040607@codesourcery.com> <47FBBFFB.7020104@codesourcery.com> From: Ian Lance Taylor Date: Tue, 08 Apr 2008 21:00:00 -0000 In-Reply-To: <47FBBFFB.7020104@codesourcery.com> (Mark Mitchell's message of "Tue\, 08 Apr 2008 11\:56\:59 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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-04/txt/msg00710.txt.bz2 Mark Mitchell writes: > Ian Lance Taylor wrote: >> Mark Mitchell writes: >> >>> * I think Richard's right that this is a new feature for 4.2, which >>> means we would have to bend the rules to put it in. But, the patch >>> seems very safe by its construction, since flag_strict_overflow is >>> usually false. So, I think it should be in 4.2. Jakub, Joseph, what >>> say you? >> >> Note that flag_strict_overflow defaults to true when using -O2. > > Excellent point. > > That does up the risk a bit, since it means we are more likely to take > the new code paths. You're making optimization more aggressive, if I > understand correctly, in that we'll now optimize based on pointers not > overflowing. I agree with Richard that in this case we should avoid > this for 4.2; it seems like we might break existing programs in the > field and it would be better to do that in 4.3.1, than on the 4.2 > branch. No, I am making the optimization less aggressive. In gcc 4.2, the optimization currently fires if -fno-wrapv and -fno-trapv. When I backport my patch to gcc 4.2, the optimization will additionally require -fstrict-overflow. That is, in current gcc 4.2, the optimization fires even at -O0 (in general--of course the folder is called more often when optimizing). When my patch is backported, it will only fire when -fstrict-overflow is used, which means in typical cases it will only fire at -O2. In gcc 4.3 and 4.4, the optimization currently fires unconditionally. With my current patch, it only fires if -fno-wrapv, and -fno-trapv, and -fstrict-overflow. I believe my patch is quite safe in the sense that it will optimize less often. However, it will cause more warnings when using -Wstrict-overflow=3 or higher (not the default), and of course some people might see the lack of optimization at -O1 as a regression. Ian