mailing list of musl libc
 help / color / mirror / Atom feed
* [musl] issue with acoshf
@ 2021-02-05  7:18 Paul Zimmermann
  2021-02-05 16:44 ` Rich Felker
  0 siblings, 1 reply; 3+ messages in thread
From: Paul Zimmermann @ 2021-02-05  7:18 UTC (permalink / raw)
  To: musl

       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?

Best regards,
Paul

[1] https://members.loria.fr/PZimmermann/papers/accuracy.pdf

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

* Re: [musl] issue with acoshf
  2021-02-05  7:18 [musl] issue with acoshf Paul Zimmermann
@ 2021-02-05 16:44 ` Rich Felker
  2021-02-06  6:45   ` Paul Zimmermann
  0 siblings, 1 reply; 3+ messages in thread
From: Rich Felker @ 2021-02-05 16:44 UTC (permalink / raw)
  To: Paul Zimmermann; +Cc: musl

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

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

* Re: [musl] issue with acoshf
  2021-02-05 16:44 ` Rich Felker
@ 2021-02-06  6:45   ` Paul Zimmermann
  0 siblings, 0 replies; 3+ messages in thread
From: Paul Zimmermann @ 2021-02-06  6:45 UTC (permalink / raw)
  To: Rich Felker; +Cc: musl

       Dear Rich,

> Date: Fri, 5 Feb 2021 11:44:02 -0500
> From: Rich Felker <dalias@libc.org>
> Cc: musl@lists.openwall.com
> User-Agent: Mutt/1.5.21 (2010-09-15)
> 
> 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

my machine is an Intel(R) Core(TM) i5-4590, and I use gcc version 10.2.1,
under Debian bullseye/sid. Szabolcs sent a patch, and I confirmed it solves
the issue. I'm now testing again acosh and sinh for the whole binary32 domain,
and will report here my findings.

Paul

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

end of thread, other threads:[~2021-02-06  6:45 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-05  7:18 [musl] issue with acoshf Paul Zimmermann
2021-02-05 16:44 ` Rich Felker
2021-02-06  6:45   ` 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