Date: Wed, 30 Oct 2002 23:09:38 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "M. Warner Losh" <imp@bsdimp.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: <3DC0D732.C29B956C@mindspring.com> References: <20021030215500.E5692-100000@gamplex.bde.org> <20021030.162239.52163953.imp@bsdimp.com> <3DC06CE4.57CF2F96@mindspring.com> <20021030.170154.35505346.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"M. Warner Losh" wrote:
> : The compiler must emit instructions to truncate and set flags, as
> : well as generating pseudo-exceptions (should they be called for)
> : in the case that the storage is in registers bigger than the memory
> : backing them. IT doesn't do this.
>
> I think I don't understand what you are saying at all. It doesn't
> seem top jive with the rest of the messages in this thread.
I mean that if there is a difference between doing the math in
registers vs. doing it in memory (or storing it in memory and
pulling it back in the registers, then you have two options:
1) Don't late-bind the FPU registers in the kernel, and take
a huge performance hit
2) Have the compiler generate code that will give the same
results as if the store and load had taken place
The gcc people argue that it's the kernel's job (do #1, not #2),
and the kernel argues that it's the compilers job (do #2, not #1).
> Except that's wrong, and further messages in the thread showed.
I didn't see a printf involved; Bruce was talking, as far as I
could tell, about a direct compare, with no printf() involved.
Are you maybe mixing this up with the "paranoia" tests?
The problem is that the double didn't give +Inf, like it should
have, because the rvalue was incorrectly promoted to long
double, instead of staying double, and overflowing (Bruce?
Correct this if it's wrong, please).
> 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.
> 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.
> 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.
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.
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).
-- Terry
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?3DC0D732.C29B956C>