From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98813 invoked by alias); 8 May 2019 07:30:25 -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 98799 invoked by uid 89); 8 May 2019 07:30:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-22.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-ed1-f66.google.com Received: from mail-ed1-f66.google.com (HELO mail-ed1-f66.google.com) (209.85.208.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 May 2019 07:30:22 +0000 Received: by mail-ed1-f66.google.com with SMTP id a8so21123025edx.3 for ; Wed, 08 May 2019 00:30:22 -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=KrovsyhlykrPJpjTMgjJIBb/Ad2UuPPIIOObmBsxAgk=; b=e8SGaqvfvsEcmfKEXQIV6J02P+N+BKM75u3jKbcgo1WZa0/hhv9bZaDB26KOzBBS5l 4dUKbaOJV0K31+Bh5qkNmIG88LQD+6BShj1D+HeGtHsPVGXgwoJAo42lOVa8KX2BT2xI gV4C26UKVXDxumCI1xpAw0sjDFPi6sSbGtFXSld7kTeJrmG6gEySn1K/rQpE8IsUQgtH nfZCzmqHMyRFVP0wzyeak3l2utNHjbUdXydplXZnlLI5oZekwfH+b6xCEd5vcMYuQ9JR kYwq1bUpbT3NIerCaGhugsEhmRyhk1+uA3IsKi8ruCL4QALsJTrjKkoXldETXFTe8/7y WmQg== MIME-Version: 1.0 References: In-Reply-To: From: Tejas Joshi Date: Wed, 08 May 2019 07:30:00 -0000 Message-ID: Subject: Re: About GSOC. To: gcc@gcc.gnu.org Content-Type: multipart/mixed; boundary="00000000000041fea705885b4e03" X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00065.txt.bz2 --00000000000041fea705885b4e03 Content-Type: text/plain; charset="UTF-8" Content-length: 3175 Hello. I can't figure out from the documentation how to add test cases in the testsuite and inspect the results. How can I do that? Although, Taking the mentioned conditions under consideration, I have made another patch, attached. Thanks, -Tejas On Wed, 8 May 2019 at 09:01, Tejas Joshi wrote: > > 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 --00000000000041fea705885b4e03 Content-Type: text/x-patch; charset="US-ASCII"; name="roundeven.patch" Content-Disposition: attachment; filename="roundeven.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jvewqhg90 Content-length: 6942 ZGlmZiAtLWdpdCBhL2djYy9idWlsdGlucy5jIGIvZ2NjL2J1aWx0aW5zLmMK aW5kZXggMjVlMDFlNDA5MmIuLjBiMmQ2YmY4MmY5IDEwMDY0NAotLS0gYS9n Y2MvYnVpbHRpbnMuYworKysgYi9nY2MvYnVpbHRpbnMuYwpAQCAtMjA2Nyw2 ICsyMDY3LDcgQEAgbWF0aGZuX2J1aWx0X2luXzIgKHRyZWUgdHlwZSwgY29t YmluZWRfZm4gZm4pCiAgICAgQ0FTRV9NQVRIRk4gKFJFTVFVTykKICAgICBD QVNFX01BVEhGTl9GTE9BVE4gKFJJTlQpCiAgICAgQ0FTRV9NQVRIRk5fRkxP QVROIChST1VORCkKKyAgICBDQVNFX01BVEhGTiAoUk9VTkRFVkVOKQogICAg IENBU0VfTUFUSEZOIChTQ0FMQikKICAgICBDQVNFX01BVEhGTiAoU0NBTEJM TikKICAgICBDQVNFX01BVEhGTiAoU0NBTEJOKQpkaWZmIC0tZ2l0IGEvZ2Nj L2J1aWx0aW5zLmRlZiBiL2djYy9idWlsdGlucy5kZWYKaW5kZXggZWY4OTcy OWZkMGMuLmUxZDU5M2E4NzY1IDEwMDY0NAotLS0gYS9nY2MvYnVpbHRpbnMu ZGVmCisrKyBiL2djYy9idWlsdGlucy5kZWYKQEAgLTU0Miw2ICs1NDIsOSBA QCBERUZfQzk5X0JVSUxUSU4gICAgICAgIChCVUlMVF9JTl9SSU5UTCwgInJp bnRsIiwgQlRfRk5fTE9OR0RPVUJMRV9MT05HRE9VQkxFLCBBVAogI2RlZmlu ZSBSSU5UX1RZUEUoRikgQlRfRk5fIyNGIyNfIyNGCiBERUZfRVhUX0xJQl9G TE9BVE5fTlhfQlVJTFRJTlMgKEJVSUxUX0lOX1JJTlQsICJyaW50IiwgUklO VF9UWVBFLCBBVFRSX0NPTlNUX05PVEhST1dfTEVBRl9MSVNUKQogI3VuZGVm IFJJTlRfVFlQRQorREVGX0VYVF9MSUJfQlVJTFRJTiAgICAoQlVJTFRfSU5f Uk9VTkRFVkVOLCAicm91bmRldmVuIiwgQlRfRk5fRE9VQkxFX0RPVUJMRSwg QVRUUl9DT05TVF9OT1RIUk9XX0xFQUZfTElTVCkKK0RFRl9FWFRfTElCX0JV SUxUSU4gICAgKEJVSUxUX0lOX1JPVU5ERVZFTkYsICJyb3VuZGV2ZW5mIiwg QlRfRk5fRkxPQVRfRkxPQVQsIEFUVFJfQ09OU1RfTk9USFJPV19MRUFGX0xJ U1QpCitERUZfRVhUX0xJQl9CVUlMVElOICAgIChCVUlMVF9JTl9ST1VOREVW RU5MLCAicm91bmRldmVubCIsIEJUX0ZOX0xPTkdET1VCTEVfTE9OR0RPVUJM RSwgQVRUUl9DT05TVF9OT1RIUk9XX0xFQUZfTElTVCkKIERFRl9DOTlfQlVJ TFRJTiAgICAgICAgKEJVSUxUX0lOX1JPVU5ELCAicm91bmQiLCBCVF9GTl9E T1VCTEVfRE9VQkxFLCBBVFRSX0NPTlNUX05PVEhST1dfTEVBRl9MSVNUKQog REVGX0M5OV9CVUlMVElOICAgICAgICAoQlVJTFRfSU5fUk9VTkRGLCAicm91 bmRmIiwgQlRfRk5fRkxPQVRfRkxPQVQsIEFUVFJfQ09OU1RfTk9USFJPV19M RUFGX0xJU1QpCiBERUZfQzk5X0JVSUxUSU4gICAgICAgIChCVUlMVF9JTl9S T1VOREwsICJyb3VuZGwiLCBCVF9GTl9MT05HRE9VQkxFX0xPTkdET1VCTEUs IEFUVFJfQ09OU1RfTk9USFJPV19MRUFGX0xJU1QpCmRpZmYgLS1naXQgYS9n Y2MvZm9sZC1jb25zdC1jYWxsLmMgYi9nY2MvZm9sZC1jb25zdC1jYWxsLmMK aW5kZXggMDZhNDIwNjAxYzAuLjdlYWZkOTFlOWEyIDEwMDY0NAotLS0gYS9n Y2MvZm9sZC1jb25zdC1jYWxsLmMKKysrIGIvZ2NjL2ZvbGQtY29uc3QtY2Fs bC5jCkBAIC03OTIsNiArNzkyLDE0IEBAIGZvbGRfY29uc3RfY2FsbF9zcyAo cmVhbF92YWx1ZSAqcmVzdWx0LCBjb21iaW5lZF9mbiBmbiwKIAl9CiAgICAg ICByZXR1cm4gZmFsc2U7CiAKKyAgICBjYXNlIENGTl9CVUlMVF9JTl9ST1VO REVWRU46CisgICAgICBpZiAoIVJFQUxfVkFMVUVfSVNOQU4gKCphcmcpIHx8 ICFmbGFnX2Vycm5vX21hdGgpCisgIHsKKyAgICByZWFsX3JvdW5kZXZlbiAo cmVzdWx0LCBmb3JtYXQsIGFyZyk7CisgICAgcmV0dXJuIHRydWU7CisgIH0K KyAgICAgIHJldHVybiBmYWxzZTsKKwogICAgIENBU0VfQ0ZOX0xPR0I6CiAg ICAgICByZXR1cm4gZm9sZF9jb25zdF9sb2diIChyZXN1bHQsIGFyZywgZm9y bWF0KTsKIApAQCAtODU0LDYgKzg2Miw5IEBAIGZvbGRfY29uc3RfY2FsbF9z cyAod2lkZV9pbnQgKnJlc3VsdCwgY29tYmluZWRfZm4gZm4sCiAgICAgICBy ZXR1cm4gZm9sZF9jb25zdF9jb252ZXJzaW9uIChyZXN1bHQsIHJlYWxfcm91 bmQsIGFyZywKIAkJCQkgICAgcHJlY2lzaW9uLCBmb3JtYXQpOwogCisgICAg Y2FzZSBDRk5fQlVJTFRfSU5fUk9VTkRFVkVOOgorICAgICAgcmV0dXJuIGZv bGRfY29uc3RfY29udmVyc2lvbiAocmVzdWx0LCByZWFsX3JvdW5kZXZlbiwg YXJnLCBwcmVjaXNpb24sIGZvcm1hdCk7CisKICAgICBDQVNFX0NGTl9JUklO VDoKICAgICBDQVNFX0NGTl9MUklOVDoKICAgICBDQVNFX0NGTl9MTFJJTlQ6 CmRpZmYgLS1naXQgYS9nY2MvZm9sZC1jb25zdC5jIGIvZ2NjL2ZvbGQtY29u c3QuYwppbmRleCA1OWNlZGVhZmQ3MS4uMzBjNDA5ZTk1YmYgMTAwNjQ0Ci0t LSBhL2djYy9mb2xkLWNvbnN0LmMKKysrIGIvZ2NjL2ZvbGQtY29uc3QuYwpA QCAtMzI5LDYgKzMyOSw3IEBAIG5lZ2F0ZV9tYXRoZm5fcCAoY29tYmluZWRf Zm4gZm4pCiAgICAgQ0FTRV9DRk5fTExST1VORDoKICAgICBDQVNFX0NGTl9M Uk9VTkQ6CiAgICAgQ0FTRV9DRk5fUk9VTkQ6CisgICAgQ0FTRV9DRk5fUk9V TkRFVkVOOgogICAgIENBU0VfQ0ZOX1NJTjoKICAgICBDQVNFX0NGTl9TSU5I OgogICAgIENBU0VfQ0ZOX1RBTjoKQEAgLTEzMDYwLDYgKzEzMDYxLDggQEAg dHJlZV9jYWxsX25vbm5lZ2F0aXZlX3dhcm52X3AgKHRyZWUgdHlwZSwgY29t YmluZWRfZm4gZm4sIHRyZWUgYXJnMCwgdHJlZSBhcmcxLAogICAgIENBU0Vf Q0ZOX1JJTlRfRk46CiAgICAgQ0FTRV9DRk5fUk9VTkQ6CiAgICAgQ0FTRV9D Rk5fUk9VTkRfRk46CisgICAgQ0FTRV9DRk5fUk9VTkRFVkVOOgorICAgIENB U0VfQ0ZOX1JPVU5ERVZFTl9GTjoKICAgICBDQVNFX0NGTl9TQ0FMQjoKICAg ICBDQVNFX0NGTl9TQ0FMQkxOOgogICAgIENBU0VfQ0ZOX1NDQUxCTjoKQEAg LTEzNTgzLDYgKzEzNTg2LDggQEAgaW50ZWdlcl92YWx1ZWRfcmVhbF9jYWxs X3AgKGNvbWJpbmVkX2ZuIGZuLCB0cmVlIGFyZzAsIHRyZWUgYXJnMSwgaW50 IGRlcHRoKQogICAgIENBU0VfQ0ZOX1JJTlRfRk46CiAgICAgQ0FTRV9DRk5f Uk9VTkQ6CiAgICAgQ0FTRV9DRk5fUk9VTkRfRk46CisgICAgQ0FTRV9DRk5f Uk9VTkRFVkVOOgorICAgIENBU0VfQ0ZOX1JPVU5ERVZFTl9GTjoKICAgICBD QVNFX0NGTl9UUlVOQzoKICAgICBDQVNFX0NGTl9UUlVOQ19GTjoKICAgICAg IHJldHVybiB0cnVlOwpkaWZmIC0tZ2l0IGEvZ2NjL3JlYWwuYyBiL2djYy9y ZWFsLmMKaW5kZXggZjgyMmFlODJkNjEuLjA0NWRjNzU4MDQ4IDEwMDY0NAot LS0gYS9nY2MvcmVhbC5jCisrKyBiL2djYy9yZWFsLmMKQEAgLTUwMTAsNiAr NTAxMCw1MyBAQCByZWFsX3JvdW5kIChSRUFMX1ZBTFVFX1RZUEUgKnIsIGZv cm1hdF9oZWxwZXIgZm10LAogICAgIHJlYWxfY29udmVydCAociwgZm10LCBy KTsKIH0KIAorLyogUmV0dXJuIHRydWUgaWYgaW50ZWdlciBwYXJ0IG9mIFIg aXMgZXZlbiwgZWxzZSByZXR1cm4gZmFsc2UuICovCisKK2Jvb2wKK2lzX2V2 ZW4gKFJFQUxfVkFMVUVfVFlQRSAqcikKK3sKKyAgdW5zaWduZWQgaW50IG4g PSBTSUdOSUZJQ0FORF9CSVRTIC0gUkVBTF9FWFAgKHIpOworCisgIHVuc2ln bmVkIGxvbmcgbnVtID0gKCh1bnNpZ25lZCBsb25nKTEgPDwgKG4gJSBIT1NU X0JJVFNfUEVSX0xPTkcpKTsKKworICBpZiAoKHItPnNpZ1tTSUdTWi0xXSAm IG51bSkgPT0gMCkKKyAgICByZXR1cm4gdHJ1ZTsKKyAgcmV0dXJuIGZhbHNl OworfQorCisvKiBSZXR1cm4gdHJ1ZSBpZiBSIGlzIGhhbGZ3YXkgYmV0d2Vl biB0d28gaW50ZWdlcnMsIGVsc2UgcmV0dXJuIGZhbHNlLiAqLworCitib29s Citpc19oYWxmd2F5X2JlbG93IChjb25zdCBSRUFMX1ZBTFVFX1RZUEUgKnIp Cit7CisgIGlmIChyLT5zaWdbMF0gIT0gMCAmJiByLT5zaWdbMV0gIT0gMCkK KyAgICByZXR1cm4gZmFsc2U7CisKKyAgdW5zaWduZWQgaW50IG4gPSBTSUdO SUZJQ0FORF9CSVRTIC0gUkVBTF9FWFAgKHIpOworCisgIHVuc2lnbmVkIGxv bmcgbnVtID0gKCh1bnNpZ25lZCBsb25nKTEgPDwgKChuIC0gMSkgJSBIT1NU X0JJVFNfUEVSX0xPTkcpKTsKKworICBpZiAoKChyLT5zaWdbU0lHU1otMV0g JiBudW0pICE9IDApICYmICgoci0+c2lnW1NJR1NaLTFdICYgKG51bS0xKSkg PT0gMCkpCisgICAgcmV0dXJuIHRydWU7CisgIHJldHVybiBmYWxzZTsKK30K KworLyogUm91bmQgWCB0byBuZWFyZXN0IGludGVnZXIsIHJvdW5kaW5nIGhh bGZ3YXkgY2FzZXMgdG93YXJkcyBldmVuLiAqLworCit2b2lkCityZWFsX3Jv dW5kZXZlbiAoUkVBTF9WQUxVRV9UWVBFICpyLCBmb3JtYXRfaGVscGVyIGZt dCwKKwkJY29uc3QgUkVBTF9WQUxVRV9UWVBFICp4KQoreworICBpZiAoaXNf aGFsZndheV9iZWxvdyAoeCkpCisgIHsKKyAgICBkb19hZGQgKHIsIHgsICZk Y29uc3RoYWxmLCB4LT5zaWduKTsKKyAgICBpZiAoIWlzX2V2ZW4gKHIpKQor ICAgICAgZG9fYWRkIChyLCByLCAmZGNvbnN0bTEsIHgtPnNpZ24pOworICB9 CisgIGVsc2UKKyAgICByZWFsX3JvdW5kIChyLCBmbXQsIHgpOworfQorCiAv KiBTZXQgdGhlIHNpZ24gb2YgUiB0byB0aGUgc2lnbiBvZiBYLiAgKi8KIAog dm9pZApkaWZmIC0tZ2l0IGEvZ2NjL3JlYWwuaCBiL2djYy9yZWFsLmgKaW5k ZXggMGNlNDI1NjU3MDguLjEwODk4ZWFlNzllIDEwMDY0NAotLS0gYS9nY2Mv cmVhbC5oCisrKyBiL2djYy9yZWFsLmgKQEAgLTQ5OSw2ICs0OTksOCBAQCBl eHRlcm4gdm9pZCByZWFsX2NlaWwgKFJFQUxfVkFMVUVfVFlQRSAqLCBmb3Jt YXRfaGVscGVyLAogCQkgICAgICAgY29uc3QgUkVBTF9WQUxVRV9UWVBFICop OwogZXh0ZXJuIHZvaWQgcmVhbF9yb3VuZCAoUkVBTF9WQUxVRV9UWVBFICos IGZvcm1hdF9oZWxwZXIsCiAJCQljb25zdCBSRUFMX1ZBTFVFX1RZUEUgKik7 CitleHRlcm4gdm9pZCByZWFsX3JvdW5kZXZlbiAoUkVBTF9WQUxVRV9UWVBF ICosIGZvcm1hdF9oZWxwZXIsCisgICAgICBjb25zdCBSRUFMX1ZBTFVFX1RZ UEUgKik7CiAKIC8qIFNldCB0aGUgc2lnbiBvZiBSIHRvIHRoZSBzaWduIG9m IFguICAqLwogZXh0ZXJuIHZvaWQgcmVhbF9jb3B5c2lnbiAoUkVBTF9WQUxV RV9UWVBFICosIGNvbnN0IFJFQUxfVkFMVUVfVFlQRSAqKTsK --00000000000041fea705885b4e03--