This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Update sparc ULPs.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]