From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13507 invoked from network); 26 Feb 2021 12:49:37 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 26 Feb 2021 12:49:37 -0000 Received: (qmail 22045 invoked by uid 550); 26 Feb 2021 12:49:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 18058 invoked from network); 26 Feb 2021 12:45:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cam.ac.uk; s=20180806.ppsw; h=Sender:Content-Type:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=dtqr9v9JUE0kGwXnW7aQCD8HObZayvk/WRI+ytLdcoE=; b=VcGutKsD4z5tzKQkdttD8vfP0M r7rIYH9GFARMOTPKPiMF1McLDSSwZ0j6ZoXSYgfCEbZJJ/qLtdWVAE2tVdx7tydQNaswRS2qckZTS BNBd17r08aeOrE0WzRGC4Nv9Lc9SH2GX70etxGVIU8T5SWH8WEdU4NbCLa3SSe1e8YFM=; X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus X-Gm-Message-State: AOAM533eur9Zve/GxD01gJRv9JBAdmL1YO4x6Kzj4qEQubwzknl6QO1/ XxSd5cke5p6+5s9FdDJy+dps+C9Un9c3JCjE1LM= X-Google-Smtp-Source: ABdhPJyUtS3ZejyDXkcTG6wxviBVB724x4ua84q2SpKeQEClGfcK1TIOsLg/JWrd0wwVU8bqcTAJTtXS/d8BNSze+/o= X-Received: by 2002:aa7:c997:: with SMTP id c23mr3119902edt.93.1614343522169; Fri, 26 Feb 2021 04:45:22 -0800 (PST) MIME-Version: 1.0 References: <20210226114342.GE354034@port70.net> In-Reply-To: <20210226114342.GE354034@port70.net> From: Alexander Richardson Date: Fri, 26 Feb 2021 12:45:06 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Szabolcs Nagy Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Sender: "A.L. Richardson" Subject: [musl] Re: Potentially incorrect musl scalbn results on AArch64? On Fri, 26 Feb 2021 at 11:43, Szabolcs Nagy wrote: > > * Alexander Richardson [2021-02-25 10:27:11 +0000]: > > Hello, > > > > I've recently been tracking down testsuite failures on FreeBSD aarch64 > > and as part of this updated the FreeBSD scalbn* implementations to use > > the musl versions. However, two of the scalbn tests are failing on > > non-x86 architectures (https://godbolt.org/z/rax7f6) > > For example, scalbn(1, -1023) returns > > "1.1125369292536006915451e-308"/0x0.8p-1022 on x86, but if I run the > > tests on aarch64 I get 0 instead. > > i added musl list on cc > > i cannot reproduce your issue (i.e. the c code works for me on > all targets as is) > > one issue can be that if freebsd incorrectly sets the fpu on > aarch64 into flush-subnormals-to-zero mode. > > or a clang compiler bug (which we have seen before wrt floating > point optimizations, although not wrong results, only wrong fenv) > Thanks very much for that suggestion! Turns out that as of https://cgit.freebsd.org/src/commit/?id=65618fdda0f272a823e6701966421bdca0efa301 FreeBSD sets the flush-subnormals-to-zero flag on startup so this is a FreeBSD issue and I can confirm that the code works as expected when I clear the flag. I've submitted a possible fix to FreeBSD in https://reviews.freebsd.org/D28938. Alex > > I'm not particularly familiar with floating-point calculations, but it > > appears to me that this could be caused by x86's extended precision > > during calculations? > > If I cast the result to (long double) on aarch64 prior to the > > multiplication, I get the expected result on AArch64 (but that's > > obviously slow and won't work on architectures where long double == > > double). > > I've attached the current workaround, but I'm sure there is a better > > solution to this. Or possibly the test is incorrect and 0 is a > > perfectly valid result? > > > > Kind regards, > > Alex > > > > > > diff --git a/lib/msun/src/s_scalbn.c b/lib/msun/src/s_scalbn.c > > index 219cd8f0c989..0d344840862f 100644 > > --- a/lib/msun/src/s_scalbn.c > > +++ b/lib/msun/src/s_scalbn.c > > @@ -29,6 +29,19 @@ double scalbn(double x, int n) > > } > > u.i = (uint64_t)(0x3ff+n)<<52; > > x = y * u.f; > > +#if !defined(__amd64__) && !defined(__i386__) > > + /* > > + * x86 performs the multiplication with higher precision, but on > > + * non-x86 architectures we might get 0 instead of a tiny value. To work > > + * around this problem perform the multiplication with float128 (slow). > > + * TODO: This doesn't work on e.g. MIPS where long double == double. > > + */ > > + if (x == 0.) { > > + x = (long double)y * u.f; > > + /* fprintf(stderr, "\ttrying again: %a/%a\n", x, > > (double)((long double)y * u.f)); */ > > + return x; > > + } > > +#endif > > return x; > > }