From: Szabolcs Nagy <nsz@port70.net>
To: Alexander Richardson <Alexander.Richardson@cl.cam.ac.uk>
Cc: musl@lists.openwall.com
Subject: [musl] Re: Potentially incorrect musl scalbn results on AArch64?
Date: Fri, 26 Feb 2021 12:43:42 +0100 [thread overview]
Message-ID: <20210226114342.GE354034@port70.net> (raw)
In-Reply-To: <CAEeofcgZbgsP6D-idQXFv6qqQw-d0kVeBHiCi2xqEeSoD-JcZw@mail.gmail.com>
* Alexander Richardson <Alexander.Richardson@cl.cam.ac.uk> [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;
> }
next parent reply other threads:[~2021-02-26 11:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAEeofcgZbgsP6D-idQXFv6qqQw-d0kVeBHiCi2xqEeSoD-JcZw@mail.gmail.com>
2021-02-26 11:43 ` Szabolcs Nagy [this message]
2021-02-26 12:45 ` Alexander Richardson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210226114342.GE354034@port70.net \
--to=nsz@port70.net \
--cc=Alexander.Richardson@cl.cam.ac.uk \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).