From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106907 invoked by alias); 8 May 2019 03:27:12 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 106896 invoked by uid 89); 8 May 2019 03:27:11 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=H*c:alternative X-HELO: mail-ed1-f46.google.com Received: from mail-ed1-f46.google.com (HELO mail-ed1-f46.google.com) (209.85.208.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 May 2019 03:27:09 +0000 Received: by mail-ed1-f46.google.com with SMTP id m4so20656416edd.8 for ; Tue, 07 May 2019 20:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=LM3x4LUs698mTp7+CDvRqtoSFFb5joVIRJTkEwU37ts=; b=eC3pXwB2OwREcb6KU4Scn6GnozswfDLglhPN0taAFF7vE36SnAEr5gsKyxDGyvlFYy Cczk2Lk92cz31NZLTX1xtAyLVOcdauz+nfYvt+UHTNJ4ZVopULMqRfcDMHRikwa1CCvy gKNcWKgO1IMCv1FLS2+BcdzU/WXoJseVFYu+mDNwzSkC9SvBs0hrYAfPW3nNh8xOZVIY Vvz/pCIocN9PqQzBQA+1ku/Ib1J33k7KVwty2ohx5wfLTe107zgrrb0/NXdZcZQZ/SrF von203+SR/B8Ov55NNTHbd9mPPi4vnpzWlW/JYqJgaR50dkDfaBtkPO89g2jkxVEQoQj kEUQ== MIME-Version: 1.0 References: In-Reply-To: From: Tejas Joshi Date: Wed, 08 May 2019 03:27:00 -0000 Message-ID: Subject: Re: About GSOC. To: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00064.txt.bz2 I should have taken all the test cases into consideration. Fool of me. I will try to make changes taking all the test cases into consideration along with the testsuite. Thanks. On Wed, 8 May 2019 at 02:31, Joseph Myers wrote: > On Wed, 8 May 2019, Tejas Joshi wrote: > > > Hello. > > As per my understanding, 3.5 would be represented in GCC as follows : > > r->uexp = 2 > > and > > r->sig[2] = 1110000....00 in binary 64 bit. (first 2 bits being 3 and > > following 1000....0 being 0.5, which later only happens for halfway > cases) > > So, if we clear out the significand part and the immediate bit to the > right > > which represent 0.5, the entire significand would become 0 due to > bit-wise > > ANDing. > > > > > + tempsig[w] &= (((unsigned long)1 << ((n % HOST_BITS_PER_LONG) - 1)) > - > > > 1); > > > > > > > That is what the following line intend to do. The clearing part would > > change the significand, that's why significand was copied to a temporary > > That much is fine. My issues are two other things: > > * The function would wrongly return true for 3, not just for 3.5, because > it never checks the bit representing 0.5. (If you don't care what it > returns for 3, see my previous point about every function needing a > comment defining its semantics. Without such a comment, I have to guess, > and my guess here is that the function should return true for 3.5 but > false for 3 and for 3.5000...0001.) > > * The function would wrongly return true for 3.5000...0001, if there are > enough 0s that all those low bits in sig[2] are 0, but some low bits in > sig[1] or sig[0] are not 0. > > And also: > > * You should never need to modify parts of (a copy of) the significand in > place. Compare low parts of the significand (masked as needed) with 0. > If not 0, just return false. Likewise for comparing the 0.5 bit with 1. > It's not that copying and modifying in place results in incorrect logic, > it's simply excessively convoluted compared to things like: > > if ((something & mask) != 0) > return false > > (the function is probably twice as long as necessary because of that > copying). > > > array for checking. This logic is inspired by the clear_significand_below > > function. Or isn't this the way it was meant to be implemented? Also, why > > unsigned long sig[SIGSZ] has to be an array? > > What would it be other than an array? It can't be a single scalar because > floating-point significands may be longer than any supported integer type > on the host (remember the IEEE binary128 case). And if you made it a > sequence of individually named fields, a load of loops would need to be > manually unrolled, which would be much more error prone and hard to read. > > -- > Joseph S. Myers > joseph@codesourcery.com >