Date: Fri, 25 Oct 2002 19:01:12 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Loren James Rittle <rittle@latour.rsch.comm.mot.com> Cc: current@freebsd.org Subject: Re: Lack of real long double support (was Re: libstdc++ does not contain fabsl symbol) Message-ID: <20021025182223.D3076-100000@gamplex.bde.org> In-Reply-To: <200210242347.g9ONlJqk036023@latour.rsch.comm.mot.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 24 Oct 2002, Loren James Rittle wrote:
> >> ... Anyways, that work exposed some issues.
> ...
> It is easy to generate, with arithmetic, a long double value outside
> the *exponent* range above no matter how the precision is set; it is
> not truncated to Inf until it is actually cast to a double (as is
> currently done just before a long double is printed with stdio). See
> below for a program that demonstrates this behavior.
>
> >> Yet, the FP hardware is actually configured by default to provide
> >> `long double' as:
>
> >> #define LDBL_MANT_DIG 53
>
> > I think you mean 64 (the hardware default).
>
> No sir, I did mean as configured in the system startup code, it is
> forced to 53-bits (that choice affects long double as well as double).
> But there are no IEEE control bits to limit the size of the exponent
> field, are there? Thus, the following describes the exact size of the
> HW's exponent field of a long double as configured by default:
>
> >> #define LDBL_MIN_EXP (-16381)
> >> #define LDBL_MAX_EXP 16384
>
> > gcc can't actually support the full range, since it doesn't control
> > the runtime environement (it could issue a fninit before main() to
> > change the default, but it shouldn't and doesn't). The exponent
> > range is lost long before printf() is reached. E.g.,
>
> > long double x= DBL_MAX;
> > long double y = 2 * x;
>
> > gives +Inf for y since the result is doesn't fit in 53-bit precision.
>
> As you know, the selection of maximum precision is orthogonal to the
> number of bits used for the exponent.
>
> I do wish you were correct. Have you looked at the raw memory of y?
> It is *not* the bit pattern for +Inf. If y were +Inf, then based on
> the properties of IEEE math, the following would report Inf not
> DBL_MAX/2:
Oops. I did look at the bits, but I looked more closely at gdb's display
of the value which is broken (it says +inf). Apparently gdb uses the
host's FP too much.
> #include <float.h>
> int main (void)
> {
> long double x= LDBL_MAX; // Same as DBL_MAX in current float.h
> long double y = 2e100 * x; // If LDBL_MAX was correct, we should latch Inf.
> long double z = y / 4e100;
> printf ("%Lg\n", z);
> }
>
> It does, in fact, report DBL_MAX/2 with the system compiler on FreeBSD
> 4. FYI, I reviewed the generated code to ensure it was using run-time
> calculations not compile-time calculations. I'd call that a rather
> easy time getting a normalized long double much larger than
> LDBL_MAX/DBL_MAX. This test alone proves in my mind that the
> <float.h> system header for i386 is itself wrong.
Yes, this example is as convincing as examining the (right :) bits.
> > The system header correctly reports this default precision. Any header
> > genrated by the gcc build should be no different, since the build should
> > run in the target environment.
>
> I agree that the precision setting in the system header is fine. The
> size of the exponent field is buggy. I held the opinion you have but
> while trying to convince RTH (the guy that rewrote gcc FP support), I
> did enough research that also leads me to think that it is the header
> itself which is buggy.
>
> 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. 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).
> > It should use whatever is the default format for the host environment,
> > It still has enquire.c for doing this automatically. [...]
>
> I fear I didn't explain clearly enough. enquire.c is completely
> *gone* in gcc 3.3. This is why gcc needs to fully understand the
> exact FP default configuration. As you noted, enquire.c was buggy.
Ah. I was a little surprised to find it still in 3.2. It is not so
much buggy as dysfunctional in a cross compiler. It has to run on the
target somehow to work.
Bruce
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?20021025182223.D3076-100000>