Re: "seq .1 .1" would mistakenly generate no output on FreeBSD 6.1

[Bruno Haible]

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