[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: |
Wed, 6 Jun 2007 00:16:46 +0200 |
User-agent: |
KMail/1.5.4 |
Hello Gary,
> >> That fixes test-frexpl.c on my ppc machine.
> >
> > OK, I've committed the fix.
>
> My bad, I meant test-printf-frexpl is fixed by the patch.
Sure, I understood that, from the context.
> (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!
>
> $ ls -l lib/fre*
> 4 -rw-r--r-- 1 gary gary 1744 May 30 02:37 lib/freading.c
> 4 -rw-r--r-- 1 gary gary 1869 May 30 02:37 lib/freading.h
> 12 -rw-r--r-- 1 gary gary 12184 Jun 4 16:05 lib/freading.o
> 4 -rw-r--r-- 1 gary gary 973 Mar 23 12:50 lib/free.c
> 4 -rw-r--r-- 1 gary gary 3920 May 30 02:37 lib/frexp.c
> 4 -rw-r--r-- 1 gary gary 854 May 30 02:37 lib/frexpl.c
>
> Gnulib's frexp* have not been compiled, so it seems that autoconf has
> decided
> that the MacOS ppc implementation is good enough... for completeness'
> sake:
>
> $ ./configure --enable-changeword gl_cv_func_frexpl_works=no
> ...
> checking whether frexpl() can be used without linking with libm... yes
> checking whether frexpl works... (cached) no
> ...
> $ ls -l lib/fre*
> 4 -rw-r--r-- 1 gary gary 1744 May 30 02:37 lib/freading.c
> 4 -rw-r--r-- 1 gary gary 1869 May 30 02:37 lib/freading.h
> 4 -rw-r--r-- 1 gary gary 2044 Jun 5 11:40 lib/freading.o
> 4 -rw-r--r-- 1 gary gary 973 Mar 23 12:50 lib/free.c
> 4 -rw-r--r-- 1 gary gary 3920 May 30 02:37 lib/frexp.c
> 4 -rw-r--r-- 1 gary gary 854 May 30 02:37 lib/frexpl.c
> 8 -rw-r--r-- 1 gary gary 4668 Jun 5 11:40 lib/frexpl.o
> $ make all check
> ...
> 1.01L = 0X2.051EB851EB851EB851EB851EB8P-1
> 0.505L = 0X2.051EB851EB851EB851EB851EB8P-2
>
> mantissa = 0X2.051EB851EB851EB851EB851EB8P-2
> x = 0X2.051EB851EB851EB851EB851EB8P-1
> mantissa == 0.505L? yes
> ...
> mantissa = 0X2.051EB851EB851EB851EB851EB8P-2
> x = 0X2.051EB851EB851EB851EB851EB8P+1021
> mantissa == 0.505L? yes
>
> mantissa = 0X2.051EB851EB851EB851EB851EB8P-2
> x = 0X2.051EB851EB851EB851EB851EB8P+1022
> mantissa == 0.505L? yes
> PASS: test-frexpl
> ...
> All checks successful
There's something we still don't understand. It is, of course, relieving
that the gnulib replacement works. But it would still be interesting to
know why the MacOS X frexpl() function causes the test to fail. Without
this knowledge, we don't know how to write the autoconf test.
Maybe the comparison of the numbers compares also some irrelevant hidden
bits in the registers? Does it help to write 'volatile long double'
instead of 'long double' in test-frexpl.c? Does the result depend on the
gcc optimization flags? Does a memory dump of the numbers reveal more than
the printf %A output?
Bruno
- 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 <=
- Re: Test results for m4-1.4.9b, Bruno Haible, 2007/06/16
- Re: Test results for m4-1.4.9b, Gary V. Vaughan, 2007/06/17