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 28295 invoked from network); 7 Jan 2021 20:03:06 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 7 Jan 2021 20:03:06 -0000
Received: (qmail 22411 invoked by uid 550); 7 Jan 2021 20:03:03 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 22392 invoked from network); 7 Jan 2021 20:03:02 -0000
Date: Thu, 7 Jan 2021 15:02:50 -0500
From: Rich Felker <dalias@libc.org>
To: Paul Zimmermann <Paul.Zimmermann@inria.fr>
Cc: musl@lists.openwall.com
Message-ID: <20210107200250.GG22981@brightrain.aerifal.cx>
References: <mwpn2hm1wy.fsf@tomate.loria.fr>
 <20210107194901.GF22981@brightrain.aerifal.cx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210107194901.GF22981@brightrain.aerifal.cx>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [musl] 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