Date: Thu, 31 Oct 2002 01:33:38 -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.013338.106483974.imp@bsdimp.com> In-Reply-To: <3DC0E0A7.290A57CA@mindspring.com> References: <3DC0D732.C29B956C@mindspring.com> <20021031.001532.99559440.imp@bsdimp.com> <3DC0E0A7.290A57CA@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <3DC0E0A7.290A57CA@mindspring.com>
Terry Lambert <tlambert2@mindspring.com> writes:
: "M. Warner Losh" wrote:
: > : > 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.
:
: [ ... ]
:
: > Terry you are wrong. This has to do with the RANGE not the PRECISION
: > of the floating point number. It is ***NOT*** +Inf.
:
: I await an explanation of how you can fit 2*DBL_MAX into a double,
: which has a range of DBL_MIN..DBL_MAX.
Look at the code.
long double a = DBL_MAX;
long double b = DBL_MAX * 2;
The original posting said that b would be +Inf at this point, which is
not correct. I think that Bruce was confused there. The more correct
example to look at was the one that rittle@ posted which was 1 +
LDBL_EPSILON.
: > : 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.
:
: I think that a number that's a 64 bit mantissa reaised to an exponent
: N takes a larger N if you have only 53 bits of mantissa, if you want
: to represent the same value.
Nope. The only difference between 53 bits and 64 bits of precision is
just that: precision. The number of bits for expoentent is
independent of this.
: The obvious example in the FreeBSD case is the default value of the
: expression (fpgetprec() == FP_PE). The compiler is not permitted to
: assume, one way or the other; it has to do runtime testing, at the
: time you compile the compiler, to comply with a completely strict
: interpretation of C99 (IMO).
This is true. Granting, for the moment, that fpgetprec() == FP_PE
isn't a standards conforming expression.
But I think that the rest of this is going off into the weeds. I'm
just trying to get things working in a sane way for long doubles. It
looks like gcc 3.2 really wants the fpu to start off in FP_PE.
Before I go forward on this further, I've got a lot of testing to do
with kernels and such to find out what really works and what does (and
doesn't) break paranoia.c.
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.013338.106483974.imp>