From owner-freebsd-current Wed Oct 30 23:11:30 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8953A37B401 for ; Wed, 30 Oct 2002 23:11:28 -0800 (PST) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16BE643E42 for ; Wed, 30 Oct 2002 23:11:28 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0172.cvx21-bradley.dialup.earthlink.net ([209.179.192.172] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1879Tn-00029y-00; Wed, 30 Oct 2002 23:10:59 -0800 Message-ID: <3DC0D732.C29B956C@mindspring.com> Date: Wed, 30 Oct 2002 23:09:38 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" 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 References: <20021030215500.E5692-100000@gamplex.bde.org> <20021030.162239.52163953.imp@bsdimp.com> <3DC06CE4.57CF2F96@mindspring.com> <20021030.170154.35505346.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "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