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 12292 invoked from network); 6 Feb 2021 06:45:46 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 6 Feb 2021 06:45:45 -0000
Received: (qmail 3337 invoked by uid 550); 6 Feb 2021 06:45:43 -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 3319 invoked from network); 6 Feb 2021 06:45:43 -0000
X-IronPort-AV: E=Sophos;i="5.81,157,1610406000"; 
   d="scan'208";a="372260028"
Date: Sat, 06 Feb 2021 07:45:31 +0100
Message-Id: <mw4kipvgms.fsf@tomate.loria.fr>
From: Paul Zimmermann <Paul.Zimmermann@inria.fr>
To: Rich Felker <dalias@libc.org>
Cc: musl@lists.openwall.com
In-Reply-To: <20210205164402.GB23432@brightrain.aerifal.cx> (message from Rich
	Felker on Fri, 5 Feb 2021 11:44:02 -0500)
References: <mwim77oudx.fsf@tomate.loria.fr> <20210205164402.GB23432@brightrain.aerifal.cx>
Subject: Re: [musl] issue with acoshf

       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