From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 9A79E3830EA4 for ; Thu, 17 Nov 2022 16:41:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9A79E3830EA4 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668703274; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=77QEcgDb7wAkuJs7hHYCHCM+8VC5sBANq1DEayY66VU=; b=THycVzlnzh9li9Qi5gBthz4DlWyXRTrNxxAH7BCmtmUiCjv/JKCkin6eu4HG73Sh82vLY5 h4Nrn+m9pTjaUYn4DNjoMdUXGVc0/RiTPp7tE64eRoj5R3S72d1Apzn9mOX9HhMMnN2ZHQ KMhKTqR7Sx9c2m4cRCaD5Yg7siuARxc= Received: from mail-yb1-f198.google.com (mail-yb1-f198.google.com [209.85.219.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-376-AvYFjinOOUy09rAyQKVvcg-1; Thu, 17 Nov 2022 11:41:12 -0500 X-MC-Unique: AvYFjinOOUy09rAyQKVvcg-1 Received: by mail-yb1-f198.google.com with SMTP id e189-20020a25e7c6000000b006e37f21e689so2018078ybh.10 for ; Thu, 17 Nov 2022 08:41:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=77QEcgDb7wAkuJs7hHYCHCM+8VC5sBANq1DEayY66VU=; b=kBiaRYlww4FG03mSybnaySZSXcy6t/VRXKUPI4+IlO6icOq1FalceSfcZWpg9XxwhG hVJAmAWGvQzoQqPLuhMHNMBHp1hABomSIpcSJ9ukZwMs4Dj5eV4k98n2wf1CO/uXNVF5 LOopjzpadvu9GE48UeHi3R15VrXW7z1PWiOmxr7ReOYFqZrsFjY3jxsMFe1/DaUU8WMz Q5X8lGPs1fpS8Sig5DHy2jK4Bki3ys4/qdP0uYl+9OLqyiY5uSa+9C8T/FlNJIipWorI prmhRIN4cfsOQmcjtar2p3WrvZKL3e3twO9tD4RfQdVhqmu2GM3P7f/pdEtSiMm9CToR NMdQ== X-Gm-Message-State: ANoB5pnmnGefLL/dc9CtJlaIvCNcOZg9y86ZOdmctH3Yah4+TzfZKbPI R8sFuBVB4GT8a1PJSLMu4F4gX37difB3Ef+l1DJZ7rW+6yUlgpeoShpCp/e5ODD+pXZqRDNs0Co MDSjRdW7yKkPpR4ExFUKWxn7tGnszqnzXjg== X-Received: by 2002:a5b:984:0:b0:6cf:b8f4:2fe2 with SMTP id c4-20020a5b0984000000b006cfb8f42fe2mr2913686ybq.80.1668703271596; Thu, 17 Nov 2022 08:41:11 -0800 (PST) X-Google-Smtp-Source: AA0mqf7+E+kFtP6FE+GmvXICONcJDhHqxlmzCLEmqliIKppaSU1NTXn+J6SygjK9qVOE3LedJuXVk0Wbjakgu+59c78= X-Received: by 2002:a5b:984:0:b0:6cf:b8f4:2fe2 with SMTP id c4-20020a5b0984000000b006cfb8f42fe2mr2913666ybq.80.1668703271248; Thu, 17 Nov 2022 08:41:11 -0800 (PST) MIME-Version: 1.0 References: <20221113200553.440728-1-aldyh@redhat.com> <6150f7fd-5a57-c138-f65e-8dc3bf13d11a@codesourcery.com> In-Reply-To: From: Aldy Hernandez Date: Thu, 17 Nov 2022 17:40:59 +0100 Message-ID: Subject: Re: [PATCH] [range-ops] Implement sqrt. To: Jakub Jelinek Cc: Joseph Myers , GCC patches , Andrew MacLeod X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="000000000000b8168005edad411b" X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000b8168005edad411b Content-Type: text/plain; charset="UTF-8" To go along with whatever magic we're gonna tack along to the range-ops sqrt implementation, here is another revision addressing the VARYING issue you pointed out. A few things... Instead of going through trees, I decided to call do_mpfr_arg1 directly. Let's not go the wide int <-> tree rat hole in this one. The function do_mpfr_arg1 bails on +INF, so I had to handle it manually. There's a regression in gfortran.dg/ieee/ieee_6.f90, which I'm not sure how to handle. We are failing because we are calculating sqrt(-1) and expecting certain IEEE flags set. These flags aren't set, presumably because we folded sqrt(-1) into a NAN directly: // All negatives. if (real_compare (LT_EXPR, &lh_ub, &dconst0)) { real_nan (&lb, "", 0, TYPE_MODE (type)); ub = lb; maybe_nan = true; return; } The failing part of the test is: if (.not. (all(flags .eqv. [.false.,.false.,.true.,.true.,.false.]) & .or. all(flags .eqv. [.false.,.false.,.true.,.true.,.true.]) & .or. all(flags .eqv. [.false.,.false.,.true.,.false.,.false.]) & .or. all(flags .eqv. [.false.,.false.,.true.,.false.,.true.]))) STOP 5 But we are generating F F F F F. Google has informed me that that 3rd flag is IEEE_INVALID. So... is the optimization wrong? Are we not allowed to substitute that NAN if we know it's gonna happen? Should we also allow F F F F F in the test? Or something else? Thanks. Aldy On Wed, Nov 16, 2022 at 9:33 PM Jakub Jelinek wrote: > > On Mon, Nov 14, 2022 at 09:55:29PM +0000, Joseph Myers wrote: > > On Sun, 13 Nov 2022, Jakub Jelinek via Gcc-patches wrote: > > > > > So, I wonder if we don't need to add a target hook where targets will be > > > able to provide upper bound on error for floating point functions for > > > different floating point modes and some way to signal unknown accuracy/can't > > > be trusted, in which case we would give up or return just the range for > > > VARYING. > > > > Note that the figures given in the glibc manual are purely empirical > > (largest errors observed for inputs in the glibc testsuite on a system > > that was then used to update the libm-test-ulps files); they don't > > constitute any kind of guarantee about either the current implementation > > or the API, nor are they formally verified, nor do they come from > > exhaustive testing (though worst cases from exhaustive testing for float > > may have been added to the glibc testsuite in some cases). (I think the > > only functions known to give huge errors for some inputs, outside of any > > IBM long double issues, are the Bessel functions and cpow functions. But > > even if other functions don't have huge errors, and some > > architecture-specific implementations might have issues, there are > > certainly some cases where errors can exceed the 9ulp threshold on what > > the libm tests will accept in libm-test-ulps files, which are thus > > considered glibc bugs. (That's 9ulp from the correctly rounded value, > > computed in ulp of that value. For IBM long double it's 16ulp instead, > > treating the format as having a fixed 106 bits of precision. Both figures > > are empirical ones chosen based on what bounds sufficed for most libm > > functions some years ago; ideally, with better implementations of some > > functions we could probably bring those numbers down.)) > > I know I can't get guarantees without formal proofs and even ulps from > reported errors are better than randomized testing. > But I think at least for non-glibc we want to be able to get a rough idea > of the usual error range in ulps. > > This is what I came up with so far (link with > gcc -o ulp-tester{,.c} -O2 -lmpfr -lm > ), it still doesn't verify that functions are always within the mathematical > range of results ([-0.0, Inf] for sqrt, [-1.0, 1.0] for sin/cos etc.), guess > that would be useful and verify the program actually does what is intended. > One can supply just one argument (number of tests, first 46 aren't really > random) or two, in the latter case the second should be upward, downward or > towardzero to use non-default rounding mode. > The idea is that we'd collect ballpark estimates for roundtonearest and > then estimates for the other 3 rounding modes, the former would be used > without -frounding-math, max over all 4 rounding modes for -frounding-math > as gcc will compute using mpfr always in round to nearest. > > Jakub --000000000000b8168005edad411b Content-Type: text/x-patch; charset="US-ASCII"; name="0001-range-ops-Implement-sqrt.patch" Content-Disposition: attachment; filename="0001-range-ops-Implement-sqrt.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lalahavo0 RnJvbSA3NTliY2Q0YjRiNmY3MGZjZWMwNDViMjRmYjY4NzRhYWNhOTg5NTQ5IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBbGR5IEhlcm5hbmRleiA8YWxkeWhAcmVkaGF0LmNvbT4KRGF0 ZTogU3VuLCAxMyBOb3YgMjAyMiAxODozOTo1OSArMDEwMApTdWJqZWN0OiBbUEFUQ0hdIFtyYW5n ZS1vcHNdIEltcGxlbWVudCBzcXJ0LgoKZ2NjL0NoYW5nZUxvZzoKCgkqIGZvbGQtY29uc3QtY2Fs bC5jYyAoZG9fbXBmcl9hcmcxKTogUmVtb3ZlIHN0YXRpYy4KCSogZ2ltcGxlLXJhbmdlLW9wLmNj IChjbGFzcyBjZm5fc3FydCk6IE5ldy4KCShnaW1wbGVfcmFuZ2Vfb3BfaGFuZGxlcjo6bWF5YmVf YnVpbHRpbl9jYWxsKTogQWRkIHNxcnQgY2FzZS4KCSogcmVhbG1wZnIuaCAoZG9fbXBmcl9hcmcx KTogQWRkIGV4dGVybi4KCmdjYy90ZXN0c3VpdGUvQ2hhbmdlTG9nOgoKCSogZ2NjLmRnL3RyZWUt c3NhL3ZycDEyNC5jOiBOZXcgdGVzdC4KLS0tCiBnY2MvZm9sZC1jb25zdC1jYWxsLmNjICAgICAg ICAgICAgICAgICB8ICAyICstCiBnY2MvZ2ltcGxlLXJhbmdlLW9wLmNjICAgICAgICAgICAgICAg ICB8IDU2ICsrKysrKysrKysrKysrKysrKysrKysrKysrCiBnY2MvcmVhbG1wZnIuaCAgICAgICAg ICAgICAgICAgICAgICAgICB8ICA0ICsrCiBnY2MvdGVzdHN1aXRlL2djYy5kZy90cmVlLXNzYS92 cnAxMjQuYyB8IDE2ICsrKysrKysrCiA0IGZpbGVzIGNoYW5nZWQsIDc3IGluc2VydGlvbnMoKyks IDEgZGVsZXRpb24oLSkKIGNyZWF0ZSBtb2RlIDEwMDY0NCBnY2MvdGVzdHN1aXRlL2djYy5kZy90 cmVlLXNzYS92cnAxMjQuYwoKZGlmZiAtLWdpdCBhL2djYy9mb2xkLWNvbnN0LWNhbGwuY2MgYi9n Y2MvZm9sZC1jb25zdC1jYWxsLmNjCmluZGV4IDhjZWVkOGYwMmY5Li41YzZiODUyYWNkYyAxMDA2 NDQKLS0tIGEvZ2NjL2ZvbGQtY29uc3QtY2FsbC5jYworKysgYi9nY2MvZm9sZC1jb25zdC1jYWxs LmNjCkBAIC0xMTgsNyArMTE4LDcgQEAgZG9fbXBmcl9ja2NvbnYgKHJlYWxfdmFsdWUgKnJlc3Vs dCwgbXBmcl9zcmNwdHIgbSwgYm9vbCBpbmV4YWN0LAogICAgaW4gZm9ybWF0IEZPUk1BVCwgZ2l2 ZW4gdGhhdCBGVU5DIGlzIHRoZSBNUEZSIGltcGxlbWVudGF0aW9uIG9mIGYuCiAgICBSZXR1cm4g dHJ1ZSBvbiBzdWNjZXNzLiAgKi8KIAotc3RhdGljIGJvb2wKK2Jvb2wKIGRvX21wZnJfYXJnMSAo cmVhbF92YWx1ZSAqcmVzdWx0LAogCSAgICAgIGludCAoKmZ1bmMpIChtcGZyX3B0ciwgbXBmcl9z cmNwdHIsIG1wZnJfcm5kX3QpLAogCSAgICAgIGNvbnN0IHJlYWxfdmFsdWUgKmFyZywgY29uc3Qg cmVhbF9mb3JtYXQgKmZvcm1hdCkKZGlmZiAtLWdpdCBhL2djYy9naW1wbGUtcmFuZ2Utb3AuY2Mg Yi9nY2MvZ2ltcGxlLXJhbmdlLW9wLmNjCmluZGV4IDc3NjQxNjZkNWZiLi5mMWYyZjA5ODMwNSAx MDA2NDQKLS0tIGEvZ2NjL2dpbXBsZS1yYW5nZS1vcC5jYworKysgYi9nY2MvZ2ltcGxlLXJhbmdl LW9wLmNjCkBAIC00Myw2ICs0Myw4IEBAIGFsb25nIHdpdGggR0NDOyBzZWUgdGhlIGZpbGUgQ09Q WUlORzMuICBJZiBub3Qgc2VlCiAjaW5jbHVkZSAicmFuZ2UuaCIKICNpbmNsdWRlICJ2YWx1ZS1x dWVyeS5oIgogI2luY2x1ZGUgImdpbXBsZS1yYW5nZS5oIgorI2luY2x1ZGUgImZvbGQtY29uc3Qt Y2FsbC5oIgorI2luY2x1ZGUgInJlYWxtcGZyLmgiCiAKIC8vIEdpdmVuIHN0bXQgUywgZmlsbCBW RUMsIHVwIHRvIFZFQ19TSVpFIGVsZW1lbnRzLCB3aXRoIHJlbGV2YW50IHNzYS1uYW1lcwogLy8g b24gdGhlIHN0YXRlbWVudC4gIEZvciBlZmZpY2llbmN5LCBpdCBpcyBhbiBlcnJvciB0byBub3Qg cGFzcyBpbiBlbm91Z2gKQEAgLTMwMSw2ICszMDMsNTQgQEAgcHVibGljOgogICB9CiB9IG9wX2Nm bl9jb25zdGFudF9wOwogCisvLyBJbXBsZW1lbnQgcmFuZ2Ugb3BlcmF0b3IgZm9yIFNRUlQuCitj bGFzcyBjZm5fc3FydCA6IHB1YmxpYyByYW5nZV9vcGVyYXRvcl9mbG9hdAoreworICB1c2luZyBy YW5nZV9vcGVyYXRvcl9mbG9hdDo6Zm9sZF9yYW5nZTsKK3ByaXZhdGU6CisgIHZvaWQgcnZfZm9s ZCAoUkVBTF9WQUxVRV9UWVBFICZsYiwgUkVBTF9WQUxVRV9UWVBFICZ1YiwgYm9vbCAmbWF5YmVf bmFuLAorCQl0cmVlIHR5cGUsCisJCWNvbnN0IFJFQUxfVkFMVUVfVFlQRSAmbGhfbGIsCisJCWNv bnN0IFJFQUxfVkFMVUVfVFlQRSAmbGhfdWIsCisJCWNvbnN0IFJFQUxfVkFMVUVfVFlQRSAmLAor CQljb25zdCBSRUFMX1ZBTFVFX1RZUEUgJiwKKwkJcmVsYXRpb25fa2luZCkgY29uc3QgZmluYWwg b3ZlcnJpZGUKKyAgeworICAgIC8vIEFsbCBuZWdhdGl2ZXMuCisgICAgaWYgKHJlYWxfY29tcGFy ZSAoTFRfRVhQUiwgJmxoX3ViLCAmZGNvbnN0MCkpCisgICAgICB7CisJcmVhbF9uYW4gKCZsYiwg IiIsIDAsIFRZUEVfTU9ERSAodHlwZSkpOworCXViID0gbGI7CisJbWF5YmVfbmFuID0gdHJ1ZTsK KwlyZXR1cm47CisgICAgICB9CisgICAgY29uc3QgcmVhbF9mb3JtYXQgKmZvcm1hdCA9IFJFQUxf TU9ERV9GT1JNQVQgKFRZUEVfTU9ERSAodHlwZSkpOworICAgIC8vIEFsbCBwb3NpdGl2ZXMuCisg ICAgaWYgKHJlYWxfY29tcGFyZSAoR0VfRVhQUiwgJmxoX2xiLCAmZGNvbnN0MCkpCisgICAgICB7 CisJLy8gPz8gSGFuZGxlICtJTkYgbWFudWFsbHkgc2luY2UgZG9fbXBmcl9hcmcxIGRvZXMgbm90 LgorCWlmIChyZWFsX2lzaW5mICgmbGhfbGIsIDApKQorCSAgbGIgPSBsaF9sYjsKKwllbHNlIGlm ICghZG9fbXBmcl9hcmcxICgmbGIsIG1wZnJfc3FydCwgJmxoX2xiLCBmb3JtYXQpKQorCSAgewor CSAgICBsYiA9IGRjb25zdDA7CisJICAgIGxiLnNpZ24gPSAxOworCSAgfQorCW1heWJlX25hbiA9 IGZhbHNlOworICAgICAgfQorICAgIC8vIEJvdGggcG9zaXRpdmVzIGFuZCBuZWdhdGl2ZXMuCisg ICAgZWxzZQorICAgICAgeworCS8vIFJhbmdlIGlzIFstMC4wLCBzcXJ0KGxoX3ViKV0gKy1OQU4u CisJbGIgPSBkY29uc3QwOworCWxiLnNpZ24gPSAxOworCW1heWJlX25hbiA9IHRydWU7CisgICAg ICB9CisgICAgaWYgKCFkb19tcGZyX2FyZzEgKCZ1YiwgbXBmcl9zcXJ0LCAmbGhfdWIsIGZvcm1h dCkpCisgICAgICB1YiA9IGRjb25zdGluZjsKKyAgfQorfSBmb3BfY2ZuX3NxcnQ7CisKIC8vIElt cGxlbWVudCByYW5nZSBvcGVyYXRvciBmb3IgQ0ZOX0JVSUxUX0lOX1NJR05CSVQuCiBjbGFzcyBj Zm5fc2lnbmJpdCA6IHB1YmxpYyByYW5nZV9vcGVyYXRvcl9mbG9hdAogewpAQCAtOTA3LDYgKzk1 NywxMiBAQCBnaW1wbGVfcmFuZ2Vfb3BfaGFuZGxlcjo6bWF5YmVfYnVpbHRpbl9jYWxsICgpCiAg ICAgICBtX2ludCA9ICZvcF9jZm5fcGFyaXR5OwogICAgICAgYnJlYWs7CiAKKyAgICBDQVNFX0NG Tl9TUVJUX0FMTDoKKyAgICAgIG1fdmFsaWQgPSB0cnVlOworICAgICAgbV9vcDEgPSBnaW1wbGVf Y2FsbF9hcmcgKGNhbGwsIDApOworICAgICAgbV9mbG9hdCA9ICZmb3BfY2ZuX3NxcnQ7CisgICAg ICBicmVhazsKKwogICAgIGRlZmF1bHQ6CiAgICAgICBicmVhazsKICAgICB9CmRpZmYgLS1naXQg YS9nY2MvcmVhbG1wZnIuaCBiL2djYy9yZWFsbXBmci5oCmluZGV4IGVkYzA4Mzg1ZmU4Li44MDdk ZDIzMDhkMiAxMDA2NDQKLS0tIGEvZ2NjL3JlYWxtcGZyLmgKKysrIGIvZ2NjL3JlYWxtcGZyLmgK QEAgLTMyLDQgKzMyLDggQEAgZXh0ZXJuIHZvaWQgcmVhbF9mcm9tX21wZnIgKFJFQUxfVkFMVUVf VFlQRSAqLCBtcGZyX3NyY3B0ciwKIAkJCSAgICBjb25zdCByZWFsX2Zvcm1hdCAqLCBtcGZyX3Ju ZF90KTsKIGV4dGVybiB2b2lkIG1wZnJfZnJvbV9yZWFsIChtcGZyX3B0ciwgY29uc3QgUkVBTF9W QUxVRV9UWVBFICosIG1wZnJfcm5kX3QpOwogCitleHRlcm4gYm9vbCBkb19tcGZyX2FyZzEgKHJl YWxfdmFsdWUgKnJlc3VsdCwKKwkJCSAgaW50ICgqZnVuYykgKG1wZnJfcHRyLCBtcGZyX3NyY3B0 ciwgbXBmcl9ybmRfdCksCisJCQkgIGNvbnN0IHJlYWxfdmFsdWUgKmFyZywgY29uc3QgcmVhbF9m b3JtYXQgKmZvcm1hdCk7CisKICNlbmRpZiAvKiAhIEdDQ19SRUFMR01QX0ggKi8KZGlmZiAtLWdp dCBhL2djYy90ZXN0c3VpdGUvZ2NjLmRnL3RyZWUtc3NhL3ZycDEyNC5jIGIvZ2NjL3Rlc3RzdWl0 ZS9nY2MuZGcvdHJlZS1zc2EvdnJwMTI0LmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAw MDAwMDAwMDAuLmVmNzJkNjYwMTUzCi0tLSAvZGV2L251bGwKKysrIGIvZ2NjL3Rlc3RzdWl0ZS9n Y2MuZGcvdHJlZS1zc2EvdnJwMTI0LmMKQEAgLTAsMCArMSwxNiBAQAorLy8geyBkZy1kbyBjb21w aWxlIH0KKy8vIHsgZGctb3B0aW9ucyAiLU8yIC1mZHVtcC10cmVlLWV2cnAgLWZkaXNhYmxlLXRy ZWUtZXRocmVhZCIgfQorCit2b2lkIGxpbmtfZXJyb3IgKCk7CisKK3ZvaWQgZm9vIChmbG9hdCBm KQoreworICBmbG9hdCB6ID0gX19idWlsdGluX3NxcnQgKGYpOworICBpZiAoIV9fYnVpbHRpbl9p c25hbiAoeikpCisgICAgeworICAgICAgaWYgKHogPCAwLjApCisJbGlua19lcnJvciAoKTsKKyAg ICB9Cit9CisKKy8vIHsgZGctZmluYWwgeyBzY2FuLXRyZWUtZHVtcC1ub3QgImxpbmtfZXJyb3Ii ICJldnJwIiB9IH0KLS0gCjIuMzguMQoK --000000000000b8168005edad411b--