[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210205164402.GB23432@brightrain.aerifal.cx>
Date: Fri, 5 Feb 2021 11:44:02 -0500
From: Rich Felker <dalias@...c.org>
To: Paul Zimmermann <Paul.Zimmermann@...ia.fr>
Cc: musl@...ts.openwall.com
Subject: Re: issue with acoshf
On Fri, Feb 05, 2021 at 08:18:02AM +0100, Paul Zimmermann wrote:
> Hi,
>
> while updating to my comparison of the accuracy of mathematical functions [1],
> I have noticed an issue with acoshf in musl-1.2.2:
>
> $ cat test_acosh_musl.c
> #include <stdio.h>
> #include <stdlib.h>
> #include <math.h>
>
> int
> main (int argc, char *argv[])
> {
> float x = -0x1.1e6ae8p+5;
> float y;
> y = acoshf (x);
> printf ("x=%a y=%a\n", x, y);
> }
>
> With gcc I get NaN as expected:
>
> $ gcc -fno-builtin test_acosh_musl.c -lm
> $ ./a.out
> x=-0x1.1e6ae8p+5 y=-nan
>
> With musl-1.2.2 I get -0x1.2f63acp+3:
>
> $ gcc -fno-builtin test_acosh_musl.c $FILES
> $ ./a.out
> x=-0x1.1e6ae8p+5 y=-0x1.2f63acp+3
>
> Please can someone confirm?
I can't reproduce it on i386 but can on sh w/softfloat. I'm guessing
you're using an arch without its own special definition of sqrtf or
logf, so it looks like it would have to be a bug in the
non-arch-specific version of one of those, but I haven't been able to
reproduce it in isolation just passing the values passed to them
(-0x1.c9b6fcp-7 to logf or 0x1.40330cp+10 to sqrtf) manually building
the generic C versions.
Thanks for the report. I'll keep looking.
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.
