From owner-freebsd-current Mon Oct 28 22:42:58 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 3412637B401 for ; Mon, 28 Oct 2002 22:42:57 -0800 (PST) Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBA2843E42 for ; Mon, 28 Oct 2002 22:42:56 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0225.cvx40-bradley.dialup.earthlink.net ([216.244.42.225] helo=mindspring.com) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 186Q5W-0002ns-00; Mon, 28 Oct 2002 22:42:55 -0800 Message-ID: <3DBE2DA1.62B2563B@mindspring.com> Date: Mon, 28 Oct 2002 22:41:37 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rittle@labs.mot.com Cc: current@freebsd.org, bde@zeta.org.au, imp@bsdimp.com, dschultz@uclink.Berkeley.EDU Subject: Re: Lack of real long double support (was Re: libstdc++ does notcontain fabsl symbol) References: <20021025182223.D3076-100000@gamplex.bde.org> <200210290211.g9T2BBcP010112@latour.rsch.comm.mot.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 Loren James Rittle wrote: > I will advise RTH about that type of issue. Fortunately, in this > case, I think advertising 53-bit precision but really using 64-bit > precision (i.e. application code overrode system default) doesn't > invalidate the advertised epsilon, in terms of how it is used by the > application. > > More generally, I will ask if gcc can support these details as gained > from the run-time environment instead of hard-coded defaults. This > would be useful for all free OSes not just FreeBSD running on hardware > with such "flexible" FP hardware. > > Any more comments, before I start work on the gcc mainline side of > things? Claiming 53 bits but supporting 64, and then not raising an exception and/or giving a "NaN" or "INF" result on overflow to the 54th bit is broken. If you do this, you will fail runtime validation suites. The C99 standard intentionall gets its information from float.h ... rather than it's float.h from the information, as you are doing ... because this is a combination host OS *and* compiler issue. I don't think that any amount of hand-waving will turn it into a compiler-only issue. I'd like to see Bruce's issues with the 64 bit support taken care of with long double (and the implicit cast that occurs in the one case that Bruce complained about in his email, where there is *too much* precision on the rvalue, which is a computation of dobule operands done in long double form, with a double result). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message