me: > > problem with a small test program on FreeBSD/x86 6.1: Oops, that should read: FreeBSD/x86 6.2
Jim, > The value for .8 that produces is not the same as the one > that provokes failure in seq. > > In the above: > (gdb) p x > $1 = 0.80000000000000004440892098500626162 > > in seq.c: > #3 0x0804d8f1 in decode_long_double > (x=0.80000000000000000001084202172485504, I don't trust gdb's display routines here. To show a 'long double', please show it in hexadecimal. > > Value of LDBL_MANT_BIT? > > freebsd6$ echo LDBL_MANT_BIT|gcc -include ../lib/float+.h -E -|tail -1 > 53 That's the problem. <float.h> is pretending that 'long double' is as wide as 'double' ... > 0x0804d683 <decode_long_double+195>: fstpt 0xffffffd8(%ebp) > 0x0804d686 <decode_long_double+198>: fldt 0xffffffd8(%ebp) > (gdb) p sizeof (long double) > $2 = 12 ... whereas gcc emits instructions for 'long double'. On FreeBSD/x86 6.2 I get: $ echo LDBL_MANT_BIT|gcc -include float+.h -E -|tail -1 64 > (gdb) info registers Oops, it doesn't show the FPU control word (cw). Anyway, the diagnosis is clear: Bug in <float.h>. Same as on BeOS. We have a workaround in the 'float' module. Probably we need to add FreeBSD 6.1 here... Bruno
