From owner-freebsd-standards@FreeBSD.ORG Wed Jan 21 02:01:50 2004 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0A0016A4CE; Wed, 21 Jan 2004 02:01:50 -0800 (PST) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC41743D3F; Wed, 21 Jan 2004 02:01:48 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i0LA1lug017127; Wed, 21 Jan 2004 21:01:47 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i0LA1jp2029348; Wed, 21 Jan 2004 21:01:46 +1100 Date: Wed, 21 Jan 2004 21:01:46 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: David Schultz In-Reply-To: <20040121091817.GA92143@VARK.homeunix.com> Message-ID: <20040121205312.E8174@gamplex.bde.org> References: <20031129000133.GA30662@troutmask.apl.washington.edu> <20031129163105.GA32651@troutmask.apl.washington.edu> <20031201182219.O4431@gamplex.bde.org> <20031202091936.I8778@gamplex.bde.org> <20040120154127.C2417@gamplex.bde.org> <20040121091817.GA92143@VARK.homeunix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-standards@FreeBSD.ORG cc: Steve Kargl Subject: Re: Implementing C99's roundf(), round(), and roundl() X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2004 10:01:51 -0000 On Wed, 21 Jan 2004, David Schultz wrote: > On Tue, Jan 20, 2004, Bruce Evans wrote: > > I think getting FE_INEXACT from rint() is the usual case (if the > > implementation actually raises it), so we gain little or negative from > ... > If you have something in mind that will work, and you have the > time to code it up, then by all means present or commit it. You > probably have a better idea than I do about the best way to deal > with the exceptions and whatnot. (Thanks again for taking the > time to look at all of this, by the way.) I probably won't get to this soon (enough). I should give priority to other things. > When FENV_ACCESS is on, C99 requires compiler-optimized code to be > affected by any operative modes in effect at runtime and set any > exception flags at runtime as if no optimizations had been > performed. gcc is flat out broken in this regard, as I think > you've pointed out in the past. Even with FENV_ACCESS on (though > likely ignored entirely), the code generated for 'd = 0.0 / 0.0' is: > > movl $0, %eax > movl $2146959360, %edx > movl %eax, -8(%ebp) > movl %edx, -4(%ebp) Unless you have a special version of gcc, it is just ignored: $ cat z.c #pragma FENV_ACCESS ON #pragma FENV_ACCESS is broken $ cc -c z.c $ cc -c -Wall z.c z.c:1: warning: ignoring #pragma FENV_ACCESS ON z.c:2: warning: ignoring #pragma FENV_ACCESS is > Given that gcc is so broken with respect to exceptions, the fact > that the math libraries don't raise the appropriate exceptions is > not a big concern given that basic arithmetic operations often > don't raise exceptions either. When gcc is fixed, both of these > problems will go away simultaneously. Nevertheless, if we > implement fenv.h now, we (a) are able to clean up libm sooner and > (b) are a step ahead when gcc supports exceptions better. It > doesn't seem like we have much to lose by going ahead and > implementing fenv.h, so at the very least we can use it in our own > libraries. I agree. Bruce