This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: PATCH: Relax one test in 18_support/numeric_limits.cc for FreeBSD only
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- To: libstdc++ at gcc dot gnu dot org
- Cc: pcarlini at unitus dot it
- Date: Thu, 17 Jan 2002 04:50:23 -0600 (CST)
- Subject: Re: PATCH: Relax one test in 18_support/numeric_limits.cc for FreeBSD only
- Organization: Networks and Infrastructure Lab (IL02/2240), Motorola Labs
- References: <200201170812.g0H8CXO74961@latour.rsch.comm.mot.com>
In article <3C468D9C.2040408@unitus.it> you write:
> Loren James Rittle wrote:
>>+ // they were wrong verses the actual FP hardware.
> Versus?
The limits as expressed in /usr/include/float.h on FreeBSD for long
double are exactly as those expressed for double. Double uses a/the
standard 8-byte IEEE FP format (I don't know the full official name).
In fact, here is the excerpt from that system header:
#define LDBL_MANT_DIG DBL_MANT_DIG
#define LDBL_EPSILON DBL_EPSILON
#define LDBL_DIG DBL_DIG
#define LDBL_MIN_EXP DBL_MIN_EXP
#define LDBL_MIN DBL_MIN
#define LDBL_MIN_10_EXP DBL_MIN_10_EXP
#define LDBL_MAX_EXP DBL_MAX_EXP
#define LDBL_MAX DBL_MAX
#define LDBL_MAX_10_EXP DBL_MAX_10_EXP
Yet the precision seen on i386 hardware with gcc on this OS for long
double is greater than allowed by the 8-byte format without extending
the range at all (since this is done in a generic OS header, the same
mapping is done on FreeBSD/alpha and all other CPUs supported by
FreeBSD). Perhaps due to a long-ago mistake or "feature", the ABI for
a long double is 12 bytes.
This program:
main() {printf ("%d\n", sizeof (long double));}
as compiled with the system compiler (also gcc but not 3.0 with
libstdc++-v3):
$ a.out
12
as compiled with gcc 3.1 (prerelease) from FSF sources:
$ a.out
12
So it is "system header declaration of limits for long double" verses
"startup code for port on CPU and implied actual precision limits for
long double". The bug, if anywhere, is in an operating system
header's expression since the ABI clearly allocates 12 bytes and they
are productively used (not really supported very well by the library
implementation according to man pages) beyond the 8-byte format. But
it is not the type of bug that may be simply fixed with a fixinclude
rule or by making the C++ limits != C limits. Users of the operating
system header, employing the standard idioms of FP use will not even
notice the mismatch.
Regards,
Loren