This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Update sparc ULPs.
- From: David Miller <davem at davemloft dot net>
- To: joseph at codesourcery dot com
- Cc: libc-alpha at sourceware dot org
- Date: Sun, 23 Sep 2012 21:02:06 -0400 (EDT)
- Subject: Re: [PATCH] Update sparc ULPs.
- References: <Pine.LNX.4.64.1208081955410.31240@digraph.polyomino.org.uk><20120808.145640.1140383087882421124.davem@davemloft.net><Pine.LNX.4.64.1208082319540.31240@digraph.polyomino.org.uk>
From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Wed, 8 Aug 2012 23:21:26 +0000
> On Wed, 8 Aug 2012, David Miller wrote:
>
>> From: "Joseph S. Myers" <joseph@codesourcery.com>
>> Date: Wed, 8 Aug 2012 20:00:10 +0000
>>
>> > Does log1pl (0x1p-16378L) (with of course -fno-builtin or use of
>> > volatile variables to prevent compile-time computation) generate a
>> > spurious underflow exception?
>>
>> Yes, this generates both an underflow and an inexact exception.
>
> OK, so that's where to look for fixing this
It turns out that the very first operation on xm1 in the ldbl-128
implementation of log1pl triggers the underflow/inexact exception.
x = xm1 + 1.0L;
This unprotected expression exists in the ldbl-128ibm version of
log1pl as well, so I'm surprised powerpc doesn't see this too.
The expression "0x1p-16378L + 1.0L" should underflow, right?
Anyways, I notice that dbl-64's log1p() is careful to avoid this
"xm1 + 1.0" computation when it might underflow.
Just for fun I changed the above to:
if ((hx & 0x7fffffff) >= 0x7ffeffff)
x = xm1 + 1.0L;
else
x = xm1;
which eliminates the underflow/inexact in this one specific case
but of course generates inaccurate results since we really need
to adjust the rest of the code to accomodate this adjustment.