bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Test results for m4-1.4.9b


From: Bruno Haible
Subject: Re: Test results for m4-1.4.9b
Date: Sun, 17 Jun 2007 00:53:56 +0200
User-agent: KMail/1.5.4

Gary V. Vaughan wrote on 2007-06-05:
> (This is using test-frexpl.c from gnulib HEAD after your patch commit)
> 
>      1.01L = 0X2.051EB851EB851EB851EB851EB8P-1
>     0.505L = 0X2.051EB851EB851EB851EB851EB8P-2
> 
>   mantissa = 0X2.051EB851EB851EB851EB851EB8P-2
>          x = 0X2.051EB851EB851EB851EB851EB8P-1
>   mantissa == 0.505L? no
>   test-frexpl.c:171: assertion failed
>   FAIL: test-frexpl
> 
> Hrmm, the bit patterns look identical to me.  I'm lost!

Hmm, I tried looking at it from an even lower level. First, I isolated this
test case, which fails on MacOS X 10.4 but works on Linux/x86:

=======================================
#include <math.h>
long double x = 1.01L;
long double z = 0.505L;
int main ()
{
  int exp = -9999;
  long double y = frexpl (x, &exp);
  return y != z;
}
=======================================

I took a memory dump of y and z, in gdb using "print *(void*(*)[4])&z" etc.

The results are:
1.01L =  { 0x3ff028f5, 0xc28f5c29, 0xbc547ae1, 0x47ae1480 }
0.505L = { 0x3fe028f5, 0xc28f5c29, 0xbc547ae1, 0x47ae1480 }
y =      { 0x3fe028f5, 0xc28f5c28, 0x3c9eb851, 0xeb851eb8 }

What do these bit patterns mean? [1], [2], [3], [4] explain it.
    "The first double is equal to the long double value rounded to a
     double, while the second double is the difference between the
     first double and the true long double value."
[1] http://sxemacs.org/list-archives/html/sxemacs-devel/2006-11/msg00008.html
[2] http://www.linux-foundation.org/spec/ELF/ppc64/PPC-elf64abi-1.9.html
    section 3.1.5.
[3] gcc-4.2.0/gcc/config/rs6000/darwin-ldouble-format
[4] gcc-4.2.0/gcc/config/rs6000/darwin-ldouble.c

So the representation of 0.505L that gcc put into the object file is

   0.505L = 0x1.028f5c28f5c29 E-1 - 0x1.47ae147ae1480 E-58

(well,
   0.505L = 0x1.028f5c28f5c29 E-1 - 0x1.47ae147ae147a E-58
would be a little more precise, but that's irrelevant here).

Whereas the representation that the MacOS X frexpl function returns is

   y      = 0x1.028f5c28f5c28 E-1 + 0x1.eb851eb851eb8 E-54

Both have the same numeric value (which is also why you saw no difference
when using printf %A):

    0b1.0000001010001111010111000010100011110101110000101001
   -0b0.000000000000000000000000000000000000000000000000000000001010001111010...
   =
    0b1.0000001010001111010111000010100011110101110000101000
   +0b0.000000000000000000000000000000000000000000000000000011110101110000101...

But the y value is incorrectly normalized.


I'm applying this workaround.

2007-06-16  Bruno Haible  <address@hidden>

        * m4/frexpl.m4 (gl_FUNC_FREXPL_WORKS): Catch the MacOS X 10.4 bug.
        * doc/functions/frexpl.texi: Document the MacOS X 10.4 bug.
        Reported by Gary V. Vaughan <address@hidden>.

*** m4/frexpl.m4        2 Jun 2007 00:54:30 -0000       1.12
--- m4/frexpl.m4        16 Jun 2007 22:19:54 -0000
***************
*** 1,4 ****
! # frexpl.m4 serial 5
  dnl Copyright (C) 2007 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
--- 1,4 ----
! # frexpl.m4 serial 6
  dnl Copyright (C) 2007 Free Software Foundation, Inc.
  dnl This file is free software; the Free Software Foundation
  dnl gives unlimited permission to copy and/or distribute it,
***************
*** 95,103 ****
    fi
  ])
  
! dnl Test whether frexpl() works on finite numbers (this fails on AIX 5.1 and
! dnl on BeOS) and also on infinite numbers (this fails e.g. on IRIX 6.5 and
! dnl mingw).
  AC_DEFUN([gl_FUNC_FREXPL_WORKS],
  [
    AC_REQUIRE([AC_PROG_CC])
--- 95,103 ----
    fi
  ])
  
! dnl Test whether frexpl() works on finite numbers (this fails on
! dnl MacOS X 10.4/PowerPC, on AIX 5.1, and on BeOS) and also on infinite 
numbers
! dnl (this fails e.g. on IRIX 6.5 and mingw).
  AC_DEFUN([gl_FUNC_FREXPL_WORKS],
  [
    AC_REQUIRE([AC_PROG_CC])
***************
*** 110,116 ****
  int main()
  {
    volatile long double x;
!   /* Test on finite numbers.  */
    x = 16.0L;
    {
      int exp = -9999;
--- 110,116 ----
  int main()
  {
    volatile long double x;
!   /* Test on finite numbers that fails on AIX 5.1.  */
    x = 16.0L;
    {
      int exp = -9999;
***************
*** 118,123 ****
--- 118,135 ----
      if (exp != 5)
        return 1;
    }
+   /* Test on finite numbers that fails on MacOS X 10.4, because its frexpl
+      function returns an invalid (incorrectly normalized) value: it returns
+                y = { 0x3fe028f5, 0xc28f5c28, 0x3c9eb851, 0xeb851eb8 }
+      but the correct result is
+           0.505L = { 0x3fe028f5, 0xc28f5c29, 0xbc547ae1, 0x47ae1480 }  */
+   x = 1.01L;
+   {
+     int exp = -9999;
+     long double y = frexpl (x, &exp);
+     if (!(exp == 1 && y == 0.505L))
+       return 1;
+   }
    /* Test on large finite numbers.  This fails on BeOS at i = 16322, while
       LDBL_MAX_EXP = 16384.
       In the loop end test, we test x against Infinity, rather than comparing
***************
*** 143,149 ****
    return 0;
  }], [gl_cv_func_frexpl_works=yes], [gl_cv_func_frexpl_works=no],
        [case "$host_os" in
!          aix* | beos* | irix* | mingw* | pw*)
              gl_cv_func_frexpl_works="guessing no";;
           *) gl_cv_func_frexpl_works="guessing yes";;
         esac
--- 155,161 ----
    return 0;
  }], [gl_cv_func_frexpl_works=yes], [gl_cv_func_frexpl_works=no],
        [case "$host_os" in
!          aix* | beos* | darwin* | irix* | mingw* | pw*)
              gl_cv_func_frexpl_works="guessing no";;
           *) gl_cv_func_frexpl_works="guessing yes";;
         esac
*** doc/functions/frexpl.texi   2 Jun 2007 00:54:30 -0000       1.4
--- doc/functions/frexpl.texi   16 Jun 2007 22:19:54 -0000
***************
*** 13,19 ****
  FreeBSD 5.2.1, NetBSD 3.0, OpenBSD 3.8, HP-UX 11, IRIX 6.5, Solaris 9, 
Cygwin, Interix 3.5.
  @item
  This function does not work on finite numbers on some platforms:
! AIX 5.1, BeOS.
  @item
  This function does not work on infinite numbers on some platforms:
  IRIX 6.5, mingw.
--- 13,19 ----
  FreeBSD 5.2.1, NetBSD 3.0, OpenBSD 3.8, HP-UX 11, IRIX 6.5, Solaris 9, 
Cygwin, Interix 3.5.
  @item
  This function does not work on finite numbers on some platforms:
! MacOS X 10.4/PowerPC, AIX 5.1, BeOS.
  @item
  This function does not work on infinite numbers on some platforms:
  IRIX 6.5, mingw.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]