|
Message-ID: <20210107200250.GG22981@brightrain.aerifal.cx> Date: Thu, 7 Jan 2021 15:02:50 -0500 From: Rich Felker <dalias@...c.org> To: Paul Zimmermann <Paul.Zimmermann@...ia.fr> Cc: musl@...ts.openwall.com Subject: Re: issue with exp10l 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.