Re: Test results for m4-1.4.9b

[Bruno Haible]

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