From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15289 invoked by alias); 12 Apr 2011 21:03:10 -0000 Received: (qmail 15275 invoked by uid 22791); 12 Apr 2011 21:03:09 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Apr 2011 21:03:03 +0000 From: "zackw at panix dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/48580] missed optimization: integer overflow checks X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: zackw at panix dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Tue, 12 Apr 2011 21:03:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg01282.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D48580 --- Comment #4 from Zack Weinberg 2011-04-12 21:03= :01 UTC --- On Tue, Apr 12, 2011 at 1:52 PM, joseph at codesourcery dot com wrote: >> In the code that this is cut down from, both arguments are known to be s= trictly >> positive, but neither is constant. =C2=A0(They're only signed for histor= ical >> reasons, I think, but it would be a huge amount of work to change that.) > > My point in noting the need for the integers to be positive was really > that unless the compiler knows they are positive, the transformation > you're asking for appears to be incorrect - the semantics of your function > are that a product with either term 0 counts as overflowing, but using a > processor overflow flag would report it as not overflowing. Well, if the compiler didn't know that, it could still use the overflow flag plus an extra test for either input operand being zero, couldn't it? The C idiom has to test for a zero result, because e.g. 0x4000_0000U * 16 wraps to zero. (The original code does in fact check for x or y <=3D 0 in a place where VRP would notice; I should have said that instead of "known to be strictly positive", sorry for any confusion.)