Hello,
On Thu, 27 Apr 2023, Jakub Jelinek wrote:
> The first really large error I see is for sinl with
> x/2gx &val
> 0x748160ed90d9425b0xefd8b811d6293294
> i.e.
> 1.5926552660973502228303666578452949e+253
> with most significant double being
> 1.5926552660973502e+253
> and low double
> -5.99
On Thu, Apr 27, 2023 at 10:59:47AM +0200, Jakub Jelinek via Gcc-patches wrote:
> I guess I'll need to look at the IBM double double sinl/cosl results,
> either it is some bug in my tester or the libm functions are useless.
> But appart from the MODE_COMPOSITE_P cases, I think all the numbers are
>
On Thu, 27 Apr 2023, Jakub Jelinek wrote:
> On Thu, Apr 27, 2023 at 07:18:52AM +, Richard Biener wrote:
> > Humm. Is it worth the trouble? I think if we make use of this it needs
>
> I think so. Without that, frange is half blind, using at least most common
> libm functions in floating poi
On Thu, Apr 27, 2023 at 07:18:52AM +, Richard Biener wrote:
> Humm. Is it worth the trouble? I think if we make use of this it needs
I think so. Without that, frange is half blind, using at least most common
libm functions in floating point code is extremely common and without
knowing anyth
On Wed, Apr 26, 2023 at 04:10:32PM +, Michael Matz wrote:
> On Wed, 26 Apr 2023, Jakub Jelinek via Gcc-patches wrote:
>
> > For glibc I've gathered data from:
> > 4) using attached ulp-tester.c (how to invoke in file comment; tested
> >both x86_64, ppc64, ppc64le 50M pseudo-random values i
On Wed, 26 Apr 2023, Jakub Jelinek wrote:
> Hi!
>
> As has been discussed before, the following patch adds target hook
> for math library function maximum errors measured in ulps.
> The default is to return ~0U which is a magic maximum value which means
> nothing is known about precision of the m
Hello,
On Wed, 26 Apr 2023, Jakub Jelinek via Gcc-patches wrote:
> For glibc I've gathered data from:
> 4) using attached ulp-tester.c (how to invoke in file comment; tested
>both x86_64, ppc64, ppc64le 50M pseudo-random values in all 4 rounding
>modes, plus on x86_64 float/double sin/cos
Hi!
As has been discussed before, the following patch adds target hook
for math library function maximum errors measured in ulps.
The default is to return ~0U which is a magic maximum value which means
nothing is known about precision of the match function.
The first argument is unsigned int beca
