From: Rich Felker <dalias@libc.org>
To: Paul Zimmermann <Paul.Zimmermann@inria.fr>
Cc: musl@lists.openwall.com
Subject: Re: [musl] issue with exp10l
Date: Thu, 7 Jan 2021 15:02:50 -0500 [thread overview]
Message-ID: <20210107200250.GG22981@brightrain.aerifal.cx> (raw)
In-Reply-To: <20210107194901.GF22981@brightrain.aerifal.cx>
On Thu, Jan 07, 2021 at 02:49:03PM -0500, Rich Felker wrote:
> On Thu, Jan 07, 2021 at 12:17:33PM +0100, Paul Zimmermann wrote:
> > Hi,
> >
> > I am extending my comparison of the accuracy of several mathematical libraries
> > to the "double extended precision" (long double on x86_64).
> >
> > First I notice that Musl does not provide j0, j1, y0, and y1 for the long
> > double format. Do you confirm?
>
> I believe that's correct; they're not part of the standard and don't
> seem to be an extension we implement at this time.
>
> > Then I got a segmentation fault using exp10l with NaN input with a non-zero
> > payload.
> >
> > $ cat test_exp10.c
> > #define _GNU_SOURCE
> >
> > typedef union { __uint128_t n; long double x; } union_t;
> >
> > #include <stdio.h>
> > #include <math.h>
> > int main()
> > {
> > union_t u;
> > u.n = 16383UL;
> > u.n = u.n << 64;
> > u.n = u.n | 629329181547216221UL;
> > /* u.n = 302213637488765131341149 */
> > long double x = u.x;
> > printf ("x=%La\n", x);
> > fflush (stdout);
> > long double y;
> > y = exp10l (x);
> > printf ("y=%La\n", y);
> > fflush (stdout);
> > return 0;
> > }
> >
> > With glibc this works fine:
> >
> > $ gcc -fno-builtin test_exp10.c -lm
> > $ ./a.out
> > x=nan
> > y=-nan
> >
> > With Musl 1.2.1 I get:
> >
> > $ ./a.out
> > x=nan
> > Segmentation fault
> >
> > According to gdb, the issue is in pow10l:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x000055555555d10e in pow10l ()
> > (gdb) where
> > #0 0x000055555555d10e in pow10l ()
> > #1 0x0000000080000000 in ?? ()
> > #2 0x0000000000003fff in ?? ()
> > #3 0x0000000000000000 in ?? ()
>
> I can't reproduce this; I get x=nan y=nan. Can you provide a
> disassembly and register dump of the point of crash? Did you do
> anything weird building musl, or are you using a stock build from a
> distro or musl-cross-make?
OK, on further investigation it looks like your problem is that you're
not passing a NAN but a trap representation. The representation is
only a nan if the exponent value is 0x7fff. For exponent not 0x7fff or
0, the high bit of the significand must be set; otherwise it's a trap
representation.
Rich
next prev parent reply other threads:[~2021-01-07 20:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-07 11:17 Paul Zimmermann
2021-01-07 19:49 ` Rich Felker
2021-01-07 20:02 ` Rich Felker [this message]
2021-01-08 9:06 ` Paul Zimmermann
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=20210107200250.GG22981@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=Paul.Zimmermann@inria.fr \
--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).