linux-mips
[Top] [All Lists]

Re: ieee754[sd]p_neg workaround

To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Subject: Re: ieee754[sd]p_neg workaround
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Wed, 20 Apr 2005 13:23:11 +0100 (BST)
Cc: linux-mips@linux-mips.org, ralf@linux-mips.org
In-reply-to: <20050420.174023.113589096.nemoto@toshiba-tops.co.jp>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20050420.174023.113589096.nemoto@toshiba-tops.co.jp>
Sender: linux-mips-bounce@linux-mips.org
On Wed, 20 Apr 2005, Atsushi Nemoto wrote:

> I have a long standing patch for FPU emulator to fix a segmentation
> fault in pow() library function.
> 
> Here is a test program to reproduce it.
> 
> main()
> {
>       union {
>               double d;
>               struct {
> #ifdef __MIPSEB
>                       unsigned int high, low;
> #else
>                       unsigned int low, high;
> #endif
>               } i;
>       } x, y, z;
>         x.i.low = 0x00000000;
>         x.i.high = 0xfff00001;
>         y.i.low = 0x80000000;
>         y.i.high = 0xcff00000;
>         z.d = pow(x.d, y.d);
>         printf("%x %x\n", z.i.high, z.i.low);
>         return 0;
> }
> 
> 
> If you run this program, you will get segmentation fault (unless your
> FPU does not raise Unimplemented exception for NaN operands).  The
> segmentation fault is caused by endless recursion in __ieee754_pow().
> 
> It looks glibc's pow() assume unary '-' operation for any number
> (including NaN) always invert its sign bit.

 AFAICS, the IEEE 754 standard explicitly leaves interpretation of the 
sign bit for NaNs as unspecified.  Therefore our implementation is correct 
and its glibc that should be fixed instead.  Please file a bug report 
against glibc.

  Maciej

<Prev in Thread] Current Thread [Next in Thread>