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.3 required=5.0 tests=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 5703 invoked from network); 26 Feb 2021 11:43:58 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 26 Feb 2021 11:43:58 -0000 Received: (qmail 1685 invoked by uid 550); 26 Feb 2021 11:43:54 -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 1651 invoked from network); 26 Feb 2021 11:43:54 -0000 Date: Fri, 26 Feb 2021 12:43:42 +0100 From: Szabolcs Nagy To: Alexander Richardson Cc: musl@lists.openwall.com Message-ID: <20210226114342.GE354034@port70.net> Mail-Followup-To: Alexander Richardson , musl@lists.openwall.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: [musl] Re: Potentially incorrect musl scalbn results on AArch64? * 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) > 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; > }