bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [2/2] new module 'isinf', FreeBSD/x86 'long double'


From: Bruno Haible
Subject: Re: [2/2] new module 'isinf', FreeBSD/x86 'long double'
Date: Tue, 15 Jul 2008 13:40:06 +0200
User-agent: KMail/1.5.4

Ben Pfaff wrote:
> This second patch is the body of the module.

It looks all right. Well done!

> It fails on FreeBSD 6.2 on i386 (td152.testdrive.hp.com) with an
> assertion failure on "ASSERT (!isinf (LDBL_MAX));", because that
> system thinks that LDBL_MAX is infinite:
> 
>     $ cat > test.c
>     #include <float.h>
>     #include <stdio.h>
> 
>     int
>     main(void)  
>     {
>       printf ("%Lf\n", LDBL_MAX);
>       return 0;
>     }
>     $ gcc test.c
>     $ ./a.out
>     inf
>     $ gcc -v
>     Using built-in specs.
>     Configured with: FreeBSD/i386 system compiler
>     Thread model: posix
>     gcc version 3.4.6 [FreeBSD] 20060305
> 
> The existing float module doesn't help, because the definition
> that it provides for LDBL_MAX is identical to the definition
> provided by the system.
> 
> I don't know what to do about that problem.

This slightly extended test program
============================================================================
#include <float.h>
#include <stdio.h>
long double value0 = 1.0L / 0.0L;
long double value1 = LDBL_MAX;
long double value2 = __LDBL_MAX__;
long double value3 = 1.1897e+4932L;
long double value4 = 1.189e+4932L;
int
main(void)
{
  printf ("%Lg\n%Lg\n%Lg\n%Lg\n%Lg\n", value0, value1, value2, value3, value4);
  return 0;
}
===========================================================================
prints on Linux/x86:

inf
1.18973e+4932
1.18973e+4932
1.1897e+4932
1.189e+4932

and on FreeBSD/x86:

inf
inf
1.18973e+4932
1.1897e+4932
1.189e+4932

Also when I look at the .s file, I see that on FreeBSD/x86
  1) value0 and value1 have the same representation, i.e. LDBL_MAX was
     transformed into inf by the compiler,
  2) value2 is (in hex) 7FFEFFFFFFFFFFFFF800 but on Linux/x86 it is
     7FFEFFFFFFFFFFFFFFFF.
So, both LDBL_MAX is wrong on FreeBSD/x86, and __LDBL_MAX__ is at least
fishy.

Another test program:

========================================================================
#include <float.h>
#include <stdio.h>
long double value = __LDBL_MAX__;
void foo (int n)
{
  long double x = value + (value / (long double) (1ULL << n));

  printf ("%d %Lg %d %d\n", n, x, x > value, x + x == x);
}
int main ()
{
  int n;
  for (n = 0; n < 64; n++)
    foo (n);
  return 0;
}
========================================================================

Output on Linux/x86:

0 inf 1 1
1 inf 1 1
2 inf 1 1
3 inf 1 1
4 inf 1 1
5 inf 1 1
6 inf 1 1
7 inf 1 1
8 inf 1 1
9 inf 1 1
10 inf 1 1
11 inf 1 1
12 inf 1 1
13 inf 1 1
14 inf 1 1
15 inf 1 1
16 inf 1 1
17 inf 1 1
18 inf 1 1
19 inf 1 1
20 inf 1 1
21 inf 1 1
22 inf 1 1
23 inf 1 1
24 inf 1 1
25 inf 1 1
26 inf 1 1
27 inf 1 1
28 inf 1 1
29 inf 1 1
30 inf 1 1
31 inf 1 1
32 inf 1 1
33 inf 1 1
34 inf 1 1
35 inf 1 1
36 inf 1 1
37 inf 1 1
38 inf 1 1
39 inf 1 1
40 inf 1 1
41 inf 1 1
42 inf 1 1
43 inf 1 1
44 inf 1 1
45 inf 1 1
46 inf 1 1
47 inf 1 1
48 inf 1 1
49 inf 1 1
50 inf 1 1
51 inf 1 1
52 inf 1 1
53 inf 1 1
54 inf 1 1
55 inf 1 1
56 inf 1 1
57 inf 1 1
58 inf 1 1
59 inf 1 1
60 inf 1 1
61 inf 1 1
62 inf 1 1
63 inf 1 1

Output on FreeBSD/x86:

0 inf 1 1
1 inf 1 1
2 inf 1 1
3 inf 1 1
4 inf 1 1
5 inf 1 1
6 inf 1 1
7 inf 1 1
8 inf 1 1
9 inf 1 1
10 inf 1 1
11 inf 1 1
12 inf 1 1
13 inf 1 1
14 inf 1 1
15 inf 1 1
16 inf 1 1
17 inf 1 1
18 inf 1 1
19 inf 1 1
20 inf 1 1
21 inf 1 1
22 inf 1 1
23 inf 1 1
24 inf 1 1
25 inf 1 1
26 inf 1 1
27 inf 1 1
28 inf 1 1
29 inf 1 1
30 inf 1 1
31 inf 1 1
32 inf 1 1
33 inf 1 1
34 inf 1 1
35 inf 1 1
36 inf 1 1
37 inf 1 1
38 inf 1 1
39 inf 1 1
40 inf 1 1
41 inf 1 1
42 inf 1 1
43 inf 1 1
44 inf 1 1
45 inf 1 1
46 inf 1 1
47 inf 1 1
48 inf 1 1
49 inf 1 1
50 inf 1 1
51 inf 1 1
52 inf 1 1
53 inf 1 1
54 1.18973e+4932 0 0
55 1.18973e+4932 0 0
56 1.18973e+4932 0 0
57 1.18973e+4932 0 0
58 1.18973e+4932 0 0
59 1.18973e+4932 0 0
60 1.18973e+4932 0 0
61 1.18973e+4932 0 0
62 1.18973e+4932 0 0
63 1.18973e+4932 0 0

What conclusion do you draw from this output?

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]