[Top][All Lists]
[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.
- Test results for m4-1.4.9b, Gary V. Vaughan, 2007/06/01
- Re: Test results for m4-1.4.9b, Bruno Haible, 2007/06/02
- Re: Test results for m4-1.4.9b, Gary V. Vaughan, 2007/06/03
- Test results for m4-1.4.9b, Bruno Haible, 2007/06/04
- Re: Test results for m4-1.4.9b, Gary V. Vaughan, 2007/06/04
- Re: Test results for m4-1.4.9b, Bruno Haible, 2007/06/04
- Re: Test results for m4-1.4.9b, Gary V. Vaughan, 2007/06/05
- Re: Test results for m4-1.4.9b, Bruno Haible, 2007/06/05
- Re: Test results for m4-1.4.9b,
Bruno Haible <=
- Re: Test results for m4-1.4.9b, Gary V. Vaughan, 2007/06/17