Initial PATCH for *-*-freebsd* under new <limits>

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

18_support/numeric_limits.cc has been failing on
i386-unknown-freebsd4.3 since we changed how <limits> is created.

I have attempted to make a patch to address the problem but I have hit
a minor snag.  I think my configuration patch is basically correct
(although there may be a better way than patching
config/cpu/i386/bits/limits.h which involves touching configure.in - I
will take advise on how you, Gaby, want it done for my final
submission of the patch), but the test still fails.  Here is the patch
I am using at the moment:

Index: libstdc++-v3/config/cpu/i386/bits/limits.h
===================================================================
RCS file: /cvs/gcc/egcs/libstdc++-v3/config/cpu/i386/bits/limits.h,v
retrieving revision 1.2
diff -c -r1.2 limits.h
*** limits.h	2001/08/13 22:26:07	1.2
--- limits.h	2001/08/22 04:55:54
***************
*** 28,33 ****
--- 28,36 ----
  #ifndef _GLIBCPP_CPU_LIMITS
  #define _GLIBCPP_CPU_LIMITS 1
  
+ // Some operating systems set this
+ #ifndef __glibcpp_long_double_bits
  #define __glibcpp_long_double_bits 80
+ #endif
  
  #endif
Index: libstdc++-v3/config/os/bsd/freebsd/bits/os_defines.h
===================================================================
RCS file: /cvs/gcc/egcs/libstdc++-v3/config/os/bsd/freebsd/bits/os_defines.h,v
retrieving revision 1.2
diff -c -r1.2 os_defines.h
*** os_defines.h	2001/06/12 23:09:05	1.2
--- os_defines.h	2001/08/22 04:55:54
***************
*** 35,40 ****
--- 35,42 ----
  /* System-specific #define, typedefs, corrections, etc, go here.  This
     file will come before all others. */
  
+ #define __glibcpp_long_double_bits __glibcpp_double_bits
+ 
  #define _GLIBCPP_AVOID_FSEEK 1
  
  #endif

The reason I define __glibcpp_long_double_bits to
__glibcpp_double_bits is that in <float.h> on all freebsd platforms,
we find:  #define LDBL_MANT_DIG   DBL_MANT_DIG, etc.

When I run this non-portable C program (but useful since it prints the
raw bits out like gdb does on this platform):

#include <stdio.h>
#include <float.h>

void foo (long double a)
{
  unsigned char* x = (unsigned char*)&a;
  for (int i = sizeof (a); i; --i) printf ("%02x", x[i-1]);
  printf (" %Le %d\n", a, sizeof(a));
}

main()
{
  foo (LDBL_MAX);
  foo (LDBL_MIN);
}

I see:

000043fefffffffffffff800 1.797693e+308 12
00003c018000000000000000 2.225074e-308 12

Note that 96 bits are used for storage in memory but the maximum
exponent doesn't match what __glibcpp_[...] macros would want to do
with that.  When I look at the return value of
std::numeric_limits<T>::min() and std::numeric_limits<T>::max() under
gdb, perhaps by luck, it matches the above bit patterns perfectly.

However, I see:

(gdb) print/x 'extrema<long double>::min'
$3 = 0x00003c018000000000000046
(gdb) print/x 'extrema<long double>::max'
$4 = 0x000043fefffffffffffff7ac

Of course the test fails because bits down in the noise don't match.

So, is the test subtly wrong (at least for hosts that retain extra
bits)?  Or, is there some additional configuration I should/must do to
make this correct?

Regards,
Loren