From owner-freebsd-current Wed Oct 30 16: 2:56 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 A971737B407 for ; Wed, 30 Oct 2002 16:02:51 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFF2B43E97 for ; Wed, 30 Oct 2002 16:02:49 -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 g9V02hpk049332; Wed, 30 Oct 2002 17:02:43 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 30 Oct 2002 17:01:54 -0700 (MST) Message-Id: <20021030.170154.35505346.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: <3DC06CE4.57CF2F96@mindspring.com> References: <20021030215500.E5692-100000@gamplex.bde.org> <20021030.162239.52163953.imp@bsdimp.com> <3DC06CE4.57CF2F96@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: <3DC06CE4.57CF2F96@mindspring.com> Terry Lambert writes: : "M. Warner Losh" wrote: : > And there's a comment: : > * 64-bit precision often gives bad results with high level languages : > * because it makes the results of calculations depend on whether : > * intermediate values are stored in memory or in FPU registers. : > which seems like a compiler issue, not an OS issue to me. : : 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. : This is the basis of Bruce's complaint: : : http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1099099+0+archive/2002/freebsd-current/20021027.freebsd-current : : | gcc can't actually support the full range, since it doesn't control : | the runtime environement (it could issue a fninit before main() to : | change the default, but it shouldn't and doesn't). The exponent : | range is lost long before printf() is reached. E.g., : | : | long double x= DBL_MAX; : | long double y = 2 * x; : | : | gives +Inf for y since the result is doesn't fit in 53-bit precision. : | The system header correctly reports this default precision. Any header : | genrated by the gcc build should be no different, since the build should : | run in the target environment. Except that's wrong, and further messages in the thread showed. 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. The exponent range is ***NOT*** lost until printf truncates it, as my test programs showed. 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. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message