Date: Thu, 31 Oct 2002 00:15:32 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: tlambert2@mindspring.com Cc: bde@zeta.org.au, rittle@labs.mot.com, rittle@latour.rsch.comm.mot.com, current@FreeBSD.ORG, dschultz@uclink.Berkeley.EDU Subject: Re: Lack of real long double support Message-ID: <20021031.001532.99559440.imp@bsdimp.com> In-Reply-To: <3DC0D732.C29B956C@mindspring.com> References: <3DC06CE4.57CF2F96@mindspring.com> <20021030.170154.35505346.imp@bsdimp.com> <3DC0D732.C29B956C@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <3DC0D732.C29B956C@mindspring.com>
Terry Lambert <tlambert2@mindspring.com> writes:
: > This
: > example shows that we don't support it in printf, since the above
: > example does ***NOT*** give +Inf, but rather whatever 2*DBL_MAX is.
:
: That would be +Inf for double values... a 53 bit +Inf. But
: since it's being improperly treated as a 64 bit value, you don't
: get +Inf when you *should*. I think this case is about *not*
: getting an error you should get.
Terry you are wrong. This has to do with the RANGE not the PRECISION
of the floating point number. It is ***NOT*** +Inf.
: > The exponent range is ***NOT*** lost until printf truncates it, as my
: > test programs showed.
:
: Exactly! And it *should* be, because a double *is not* the same
: precision as a *long double*. A validation suite that tested edge
: conditions to ensure that there was a precision failure where there
: was supposed to be, and didn't get an expected failure, would mean
: it's broken.
You are wrong. You are confusing the precision of the mantissa with
the range of the exponent.
Printf should *NOT* truncate to double before converting to print.
That's a bug too.
: > The one issue that I've seen is
: >
: > long double a = 1.0L;
: > long double b = 1.0L + LDBL_EPSION
: > if (a == b) abort();
: >
: > which is what I'm trying to fix. (note, "1.0L" must be spelled
: > "oneld()" and long double oneld() { return (1.0L);}) to avoid the
: > optimizer getting it right.
:
: Heh. I saw that discussion; I think that's seperate.
Yes.
: The main issue that I think is outstanding is that you can't get
: both exception behaviour and non-exception behaviour, and it is
: going to have to be the compiler's job to force the issue, because
: it can't dictate implementaiton to the host OS.
I don't follow.
: One problem is the initialization of the hardware (there was already
: a flags change for an initialization difference from what the compiler
: expects suggested in this thread -- to my mind, it's a workaround for
: the gcc generating header files, instead of taking the system's word
: for it).
I don't follow.
Warner
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?20021031.001532.99559440.imp>