Re: frexpl bugs remain on OS X 10.5 intel

[Gary V. Vaughan]

On 25 Jan 2008, at 07:12, Bruno Haible wrote:
> Hi Gary,

Hallo Bruno,

> Gary V. Vaughan wrote:
> > ... upgrade my gnulib checkout and rebuild m4 HEAD against it.
> > ... there are /\(still\|new\)/ frexpl bugs in gnulib on my intel  
> > MacBook:
> >
> > $ VERBOSE=1 make check TESTS='test-frexpl test-printf-frexpl'
> > [[...]]
> > make  check-TESTS
> > i:-16382 exp:-16384
> > .../../../tests/gnu/test-frexpl.c:136: assertion failed
> > FAIL: test-frexpl
>
> This ought to have been fixed by the patch presented in [1], last  
> week.
> (The MacOS X 10.5/i386 frexpl() function turned out to be buggy for
> denormalized numbers; the patch adds a configure time test for it.)

Not so far as I can tell... I'm running 10.5.1 if that makes a  
difference.

> Can you run the test program mentioned in [2]?

Sure:

$ gcc -o testfrexpl testfrexpl.c
$ ./testfrexpl
-16384 0.5

> And/or look at the configure messages relating to frexpl?

$ ../configure
## ------------------- ##
## Configuring m4 1.9a ##
## ------------------- ##

checking build system type... i386-apple-darwin9.1.0
checking host system type... i386-apple-darwin9.1.0
configure: autobuild project... GNU M4
configure: autobuild revision... 1.9a
configure: autobuild hostname... astaroth.local
configure: autobuild timestamp... 20080125-002240
[[...]]
checking whether frexp() can be used without linking with libm... yes
checking whether frexp works... yes
checking whether frexpl() can be used without linking with libm... yes
checking whether frexpl works... yes
checking whether frexpl is declared... yes
checking for fseeko... yes
checking for ftello... yes
checking for gettimeofday with POSIX signature... yes
checking whether gettimeofday clobbers localtime buffer... no
checking whether the compiler generally respects inline... yes
checking whether isnan(double) can be used without linking with  
libm... yes
checking whether isnan(float) can be used without linking with libm...  
yes
checking whether isnan(float) works... yes
checking whether isnan(long double) can be used without linking with  
libm... yes
checking whether isnanl works... no
checking where to find the exponent in a 'long double'... word 2 bit 0
[[...]]
checking whether frexp can be used without linking with libm...  
(cached) yes
checking whether frexp works... (cached) yes
checking whether ldexp can be used without linking with libm... yes
checking whether frexpl can be used without linking with libm...  
(cached) yes
checking whether frexpl works... (cached) yes
checking whether frexpl is declared... (cached) yes
checking whether ldexpl can be used without linking with libm... yes
checking whether ldexpl works... yes
checking whether ldexpl is declared... yes
[[...]
checking where to find the exponent in a 'double'... word 1 bit 20
checking where to find the exponent in a 'float'... word 0 bit 23
checking where to find the exponent in a 'long double'... (cached)  
word 2 bit 0

> Last not least, are you compiling in 32-bit mode (i686) or in 64-bit  
> mode
> (x86_64)? As we now know, the config.guess result does not contain  
> this
> information.

I'm not passing any special flags, so whatever is standard for the  
apple shipped
build of gcc on 10.5.1.  I believe that is 64 bit mode, unless I'm  
just falling
for the hype...

HTH,
        Gary
--
  ())_.              Email me: address@hidden
  ( '/           Read my blog: http://blog.azazil.net
  / )=         ...and my book: http://sources.redhat.com/autobook
`(_~)_

PGP.sig
Description: This is a digitally signed message part