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
