mailing list of musl libc
 help / color / mirror / Atom feed
* [musl] issue with exp10l
@ 2021-01-07 11:17 Paul Zimmermann
  2021-01-07 19:49 ` Rich Felker
  0 siblings, 1 reply; 4+ messages in thread
From: Paul Zimmermann @ 2021-01-07 11:17 UTC (permalink / raw)
  To: musl

       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?

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 ?? ()

Best regards,
Paul


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] issue with exp10l
  2021-01-07 11:17 [musl] issue with exp10l Paul Zimmermann
@ 2021-01-07 19:49 ` Rich Felker
  2021-01-07 20:02   ` Rich Felker
  0 siblings, 1 reply; 4+ messages in thread
From: Rich Felker @ 2021-01-07 19:49 UTC (permalink / raw)
  To: Paul Zimmermann; +Cc: musl

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?

Rich

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] issue with exp10l
  2021-01-07 19:49 ` Rich Felker
@ 2021-01-07 20:02   ` Rich Felker
  2021-01-08  9:06     ` Paul Zimmermann
  0 siblings, 1 reply; 4+ messages in thread
From: Rich Felker @ 2021-01-07 20:02 UTC (permalink / raw)
  To: Paul Zimmermann; +Cc: musl

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] issue with exp10l
  2021-01-07 20:02   ` Rich Felker
@ 2021-01-08  9:06     ` Paul Zimmermann
  0 siblings, 0 replies; 4+ messages in thread
From: Paul Zimmermann @ 2021-01-08  9:06 UTC (permalink / raw)
  To: Rich Felker; +Cc: musl

       Dear Rich,

> 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.

thank you. I have now forced the high bit of the significand to be set,
and it works better indeed. I have found errors up to 40 ulps for exp10l:

exp10l 0xd.41cfe8659e3d7eep+8l 40.1

Best regards,
Paul

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-01-08  9:07 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-07 11:17 [musl] issue with exp10l Paul Zimmermann
2021-01-07 19:49 ` Rich Felker
2021-01-07 20:02   ` Rich Felker
2021-01-08  9:06     ` Paul Zimmermann

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ http://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git