From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95765 invoked by alias); 6 Jun 2019 16:43:28 -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 95757 invoked by uid 89); 6 Jun 2019 16:43:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=sk:SIGNIFI, H*i:sk:OfT3SrV, H*f:sk:ri61s0t, improvisation X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Jun 2019 16:43:27 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1hYvU1-0006A6-Ht from joseph_myers@mentor.com ; Thu, 06 Jun 2019 09:43:21 -0700 Received: from digraph.polyomino.org.uk (137.202.0.90) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 6 Jun 2019 17:43:18 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.90_1) (envelope-from ) id 1hYvTx-0004ZR-I4; Thu, 06 Jun 2019 16:43:17 +0000 Date: Thu, 06 Jun 2019 16:43:00 -0000 From: Joseph Myers To: Tejas Joshi CC: , Martin Jambor , Subject: Re: About GSOC. In-Reply-To: Message-ID: References: <20190530213839.GF31586@gate.crashing.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2019-06/txt/msg00046.txt.bz2 On Tue, 4 Jun 2019, Tejas Joshi wrote: > Hello. > > > NaN, and you should make sure it behaves accordingly. (If it should never > > be called for them, a gcc_assert would be appropriate.) > > I can't find any documentation about how and when to use gcc_assert. > But I used it looking at the comment at its definition and locations > it is used, is this appropriate? Or is it supposed to be used before > calling the function? : > > +bool > +is_even (REAL_VALUE_TYPE *r) > +{ > + /* The function is not supposed to use for Inf and NaN. */ > + gcc_assert (r->cl != rvc_inf); > + gcc_assert (r->cl != rvc_nan); I'd suggest making the comment above the function be clear about what classes of arguments are or are not valid, and then you don't need a comment on the assertions. Is REAL_EXP meaningful for rvc_zero? If not, you should check for rvc_zero and handle it appropriately before doing anything checking REAL_EXP. > > So n is the bit position, and w is the word position, of the bit with > > value 1; n-1 is the position of the bit with value 0.5. > > If n is a multiple of HOST_BITS_PER_LONG (that is, the bits with values > > 0.5 and 1 are in different words), this will incorrectly return false when > > the 0.5 bit is set. > > I did not understand this. What is the bit with value 1? I don't understand your question. The "sig" array contains SIGNIFICAND_BITS bits. The most significant one has value 2^(REAL_EXP-1) and thus the least significant one has value 2^(REAL_EXP-SIGNIFICAND_BITS). The ones we care about for the present purposes are the bit with value 1 (to tell whether an integer part is even or odd), the bit with value 0.5 and all the bits lower than that (to tell whether the fractional part is exactly 0.5 or not). > But when n is a multiple of HOST_BITS_PER_LONG, the function was > computing value of w wrong (e.g. for number 2^63 + 0.5). At such time, > would the following improvisation be acceptable in is_halfway_below? That still seems wrong. For testing for a halfway value you don't care about the bit with value 1. You do care about the bit with value 0.5, and you do care about the lower bits. So you should probably set n = SIGNIFICAND_BITS - REAL_EXP (r) - 1 (under a conditional with < not <=; if REAL_EXP (r) == SIGNIFICAND_BITS, the least significant bit has value 1 and the number must be an integer). That way, n is the bit position of the bit with value 0.5. Then you can compute w from n without special casing to get the word position of the bit with value 0.5. For the words below w you check they are entirely 0. For word w you need to check both that bit n is 1 and the lower bits are 0. -- Joseph S. Myers joseph@codesourcery.com