From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8518 invoked by alias); 12 Apr 2011 20:40:51 -0000 Received: (qmail 8510 invoked by uid 22791); 12 Apr 2011 20:40:50 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,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 20:40:46 +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" MIME-Version: 1.0 Date: Tue, 12 Apr 2011 20:40: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/msg01280.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 --- Comment #2 from Zack Weinberg 2011-04-12 20:40:41 UTC --- (In reply to comment #1) > > Two signed integers given that they are known to be positive, anyway. > This may return unexpected results if either or both arguments are > negative or zero. ... > (If the function gets called with one constant operand, you can make it > inline and use __builtin_constant_p to replace a divide with a range check > on the other operand. That's only useful for some cases of overflow > checks, of course.) In the code that this is cut down from, both arguments are known to be strictly positive, but neither is constant. (They're only signed for historical reasons, I think, but it would be a huge amount of work to change that.) > I sort of think GCC should have built-in functions exposing C and C++ > interfaces for: each basic arithmetic operation, defined to wrap; each > basic arithmetic operation, defined to saturate; each basic arithmetic > operation, defined to have undefined overflow; each basic arithmetic > operation, with a separate overflow flag being set; each basic arithmetic > operation, defined to trap on overflow. All of these for both signed and > unsigned and for any desired number of bits (up to the maximum number > supported for arithmetic, so generally 1-64 bits on 32-bit configurations > and 1-128 bits on 64-bit configurations); except for the defined-to-trap > case, all would still have undefined behavior on division by 0. You could > then have optimizations mapping generic C idioms to such built-in > operations where the target supports efficient code for the operations. > But this rather relies on the no-undefined-overflow work being finished > first so that some of the required operations actually exist inside GCC, > before they can easily be exposed to the user. So you see this as more of a tree-level than an RTL-level missed optimization, then? Your plan sounds fine to me, although I might look for a less ambitious but more likely to get done soon approach, personally.