From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1130 invoked by alias); 3 Sep 2011 20:37:57 -0000 Received: (qmail 1122 invoked by uid 22791); 3 Sep 2011 20:37:56 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-yx0-f175.google.com (HELO mail-yx0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 03 Sep 2011 20:37:40 +0000 Received: by yxl11 with SMTP id 11so1766617yxl.20 for ; Sat, 03 Sep 2011 13:37:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.103.11 with SMTP id a11mr2071378ybc.76.1315082259948; Sat, 03 Sep 2011 13:37:39 -0700 (PDT) Received: by 10.151.84.14 with HTTP; Sat, 3 Sep 2011 13:37:39 -0700 (PDT) In-Reply-To: <11109031947.AA28670@vlsi1.ultra.nyu.edu> References: <201109031124.37807.ebotcazou@adacore.com> <201109031708.52403.ebotcazou@adacore.com> <11109031947.AA28670@vlsi1.ultra.nyu.edu> Date: Sat, 03 Sep 2011 20:37:00 -0000 Message-ID: Subject: Re: [PATCH] Remove bogus TYPE_IS_SIZETYPE special-casing in extract_muldiv_1 From: Richard Guenther To: Richard Kenner Cc: ebotcazou@adacore.com, gcc-patches@gcc.gnu.org, rguenther@suse.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: 2011-09/txt/msg00229.txt.bz2 On Sat, Sep 3, 2011 at 9:47 PM, Richard Kenner wrote: > Let me jump in on this a little bit, since much of the code in this area > was originally written by me. > >> Are all sizetype (sub-)expressions always of value in that range? >> What do we do about the fact that sizetype is unsigned, so -x always >> overflows for x !=3D 0? =A0Thus, do we need to disable all a - b -> a + >> -b kind of foldings for sizetypes? (we don't) > > The basic idea is that an overflow of sizetype is either: > > (1) Detected at a higher level (e.g., testing for maximum sizes of object= s) or; > (2) Is an undetected error and hence the result of such overflow is undef= ined. > > What this means from a practical point of view (but indeed a bit hard > to define from a formal point of view) is that the normal addition and > subtraction operations (on a 2's complement machines, which all are > now) will "do the right thing" in all cases so we can perform all > those sorts of folding operations. So what's your opinion on the "bug" that triggered the patch in question?\ Namely extract_muldiv_1 folding (((10240 - (sizetype) first) + 1) * 8) /[cl] 8 to ((sizetype) first * 0x0fffffffffffffff8 + 81928) /[cl] 8 to ((sizetype) first * 2305843009213693951 + 10241) thus, folding A - B to -B + A, which is valid for unsigned types only if overflow wraps. But the 2nd folding is only valid if overflow is undefi= ned. Both foldings happen in extract_muldiv_1, the latter is especially enabled for TYPE_IS_SIZETYPE. The reasoning why both transforms are valid is bogus IMHO. Can you give a formal definition of sizetype behavior that can be used to prove that both transforms are valid? Richard.