Date: Mon, 28 Oct 2002 20:11:11 -0600 (CST) From: Loren James Rittle <rittle@latour.rsch.comm.mot.com> To: current@freebsd.org Cc: bde@zeta.org.au, imp@bsdimp.com, dschultz@uclink.Berkeley.EDU Subject: Re: Lack of real long double support (was Re: libstdc++ does not contain fabsl symbol) Message-ID: <200210290211.g9T2BBcP010112@latour.rsch.comm.mot.com> In-Reply-To: <20021025182223.D3076-100000@gamplex.bde.org> (message from Bruce Evans on Fri, 25 Oct 2002 19:01:12 %2B1000 (EST)) References: <20021025182223.D3076-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <20021025182223.D3076-100000@gamplex.bde.org>,
Bruce Evans<bde@zeta.org.au> writes:
>> If you really want, I can tell RTH that FreeBSD/i386 absolutely wants
>> `long double' to be:
>> 53 mantissa bits
>> 1024 max exponent
> No need. I prefer to keep the 53-bit precision for now, but fix the
> exponents.
OK. This was the resolution that made sense to us on the gcc side
(RTH, quickly; myself, some time to get up to speed). FYI, the system
header patch that was actually checked in claims 64-bit precision. Oh
well, at least the exponents are now correct. ;-) FYI, here is the
exact test case which shows the new value for LDBL_EPSILON (derived
directly from LDBL_MANT_DIG) is wrong verses the hardware default:
#include <float.h>
// Force run-time computation of math (beware, inlining oneld will defeat this).
long double oneld() { return 1.0L; }
main ()
{
long double a = oneld();
long double b = oneld() + LDBL_EPSILON;
if (a == b) abort ();
}
On ref5 against gcc 3.2.X (as installed as system compiler), with the
latest <float.h>, it crashes. By specification, this is one FP test
involving exact equality that is guaranteed to work (and report false,
in this case).
> Hopefully the precision won't be hard-coded into gcc in such
> a way as to completely break changing the precision at runtime. I think
> it should affect (only) constant folding. The issues are very similar
> to the ones with changing the rounding mode at runtime (C99 compilers
> shouldn't do constant folding in "#pragma STDC FENV_ACCESS ON" sections
> if the correct result might depend on the FP environment).
This exchange has been quite useful. I see that issue.
Unfortunately, changing precision of the FP hardware would seem to
change the value of epsilon that is exported, both in classic C
headers and C++ <limits> (the latter being how I originally took any
interest in this matter since a C++ test case started failing after
the new real.c code was installed).
gcc 3.3 will support a framework in which such changes would be easy
to convey at compile-time but, to my knowledge, there is no support
yet to obtain e.g. the precision setting at run-time. I.e. <float.h>
is now completely dynamically created at compile-time based on the
exact knowledge within gcc of the FP hardware; but it is static
w.r.t. eventual run-time. It does not know how to effectively export
a function ala FreeBSD/alpha's <float.h>:
#define FLT_ROUNDS __flt_rounds()
One issue, the standard says that various macros related to float
limits are constant expressions (as may be used to influence the
preprocessor?). The above construct doesn't conform but I understand
the intent.
I will advise RTH about that type of issue. Fortunately, in this
case, I think advertising 53-bit precision but really using 64-bit
precision (i.e. application code overrode system default) doesn't
invalidate the advertised epsilon, in terms of how it is used by the
application.
More generally, I will ask if gcc can support these details as gained
from the run-time environment instead of hard-coded defaults. This
would be useful for all free OSes not just FreeBSD running on hardware
with such "flexible" FP hardware.
Any more comments, before I start work on the gcc mainline side of
things?
Thanks,
Loren
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210290211.g9T2BBcP010112>