From owner-freebsd-current Wed Oct 30 23:16:32 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 23AC637B401 for ; Wed, 30 Oct 2002 23:16:30 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A7A443E7B for ; Wed, 30 Oct 2002 23:16:29 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g9V7GSpk051010; Thu, 31 Oct 2002 00:16:28 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 31 Oct 2002 00:15:32 -0700 (MST) Message-Id: <20021031.001532.99559440.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 From: "M. Warner Losh" In-Reply-To: <3DC0D732.C29B956C@mindspring.com> References: <3DC06CE4.57CF2F96@mindspring.com> <20021030.170154.35505346.imp@bsdimp.com> <3DC0D732.C29B956C@mindspring.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 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 In message: <3DC0D732.C29B956C@mindspring.com> Terry Lambert 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