From owner-freebsd-standards@FreeBSD.ORG Mon Jan 19 11:03:35 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 BF9E616A4CE for ; Mon, 19 Jan 2004 11:03:35 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26C6C43D94 for ; Mon, 19 Jan 2004 11:01:34 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) i0JJ1YFR061939 for ; Mon, 19 Jan 2004 11:01:34 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i0JJ1X8g061933 for freebsd-standards@freebsd.org; Mon, 19 Jan 2004 11:01:33 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 19 Jan 2004 11:01:33 -0800 (PST) Message-Id: <200401191901.i0JJ1X8g061933@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Subject: Current problem reports assigned to you 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: Mon, 19 Jan 2004 19:03:35 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- s [2001/01/23] misc/24590 standards timezone function not compatible witn Sin o [2002/02/25] bin/35307 standards standard include files are not standard c o [2003/03/05] bin/48958 standards The type 'bool' has different sizes for C o [2003/04/21] standards/51209standards [PATCH] add a64l()/l64a/l64a_r functions p [2003/06/05] standards/52972standards /bin/sh arithmetic not POSIX compliant o [2003/06/20] standards/53554standards interval timers not cleared in fork() o [2003/07/12] standards/54410standards one-true-awk not POSIX compliant (no exte o [2003/09/15] standards/56906standards Several math(3) functions fail to set err o [2003/12/31] standards/60772standards _Bool and bool should be unsigned 9 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/01/16] bin/24390 standards Replacing old dir-symlinks when using /bi o [2001/11/20] standards/32126standards getopt(3) not Unix-98 conformant s [2002/03/18] standards/36076standards Implementation of POSIX fuser command o [2002/06/13] standards/39256standards [v]snprintf aren't POSIX-conformant for s o [2002/07/09] misc/40378 standards stdlib.h gives needless warnings with -an p [2002/08/12] standards/41576standards POSIX compliance of ln(1) o [2002/10/23] standards/44425standards getcwd() succeeds even if current dir has o [2002/12/09] standards/46119standards Priority problems for SCHED_OTHER using p o [2002/12/23] standards/46504standards Warnings in headers o [2003/04/22] standards/51292standards [PATCH] add ecvt()/fcvt()/gcvt() function o [2003/06/22] standards/53613standards FreeBSD doesn't define EPROTO o [2003/06/24] bin/53682 standards [PATCH] add fuser(1) utitity o [2003/07/24] standards/54809standards pcvt deficits o [2003/07/24] standards/54833standards more pcvt deficits o [2003/07/25] standards/54839standards pcvt deficits o [2003/07/31] standards/55112standards glob.h, glob_t's gl_pathc should be "size o [2003/09/04] standards/56476standards cd9660 unicode support simple hack o [2003/09/27] standards/57295standards [patch] make does not include cmd line va o [2003/10/12] standards/57911standards fnmatch ("[[:alpha:]]","x", FNM_PATHNAME) o [2003/10/29] standards/58676standards grantpt(3) alters storage used by ptsname o [2003/11/29] standards/59797standards Implement C99's round[f]() math fucntions p [2003/12/26] standards/60597standards FreeBSD's /usr/include lacks of cpio.h 22 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon Jan 19 11:04:21 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 0DFC416A4D0 for ; Mon, 19 Jan 2004 11:04:21 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B52CC43DA0 for ; Mon, 19 Jan 2004 11:04:06 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.10/8.12.10) with ESMTP id i0JJ3DFR063943 for ; Mon, 19 Jan 2004 11:03:13 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i0JJ3B5i063932 for standards@freebsd.org; Mon, 19 Jan 2004 11:03:11 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 19 Jan 2004 11:03:11 -0800 (PST) Message-Id: <200401191903.i0JJ3B5i063932@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: standards@FreeBSD.org Subject: Current problem reports assigned to you 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: Mon, 19 Jan 2004 19:04:21 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/08/18] kern/29844 standards [PATCH] setpgrp does not behave as manual 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/03/05] bin/25542 standards /bin/sh: null char in quoted string 1 problem total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [1995/01/11] i386/105 standards Distributed libm (msun) has non-standard o [2000/09/24] bin/21519 standards sys/dir.h should be deprecated some more o [2000/12/05] kern/23304 standards POSIX clock_gettime, clock_getres return s [2001/06/18] kern/28260 standards UIO_MAXIOV needs to be made public 4 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon Jan 19 13:32:16 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 2E13316A4CE for ; Mon, 19 Jan 2004 13:32:16 -0800 (PST) Received: from VARK.homeunix.com (adsl-68-122-6-70.dsl.pltn13.pacbell.net [68.122.6.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 650E743D3F for ; Mon, 19 Jan 2004 13:32:11 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.10/8.12.10) with ESMTP id i0JLVhKu073075; Mon, 19 Jan 2004 13:31:43 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.10/8.12.10/Submit) id i0JLVgID073074; Mon, 19 Jan 2004 13:31:42 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Mon, 19 Jan 2004 13:31:42 -0800 From: David Schultz To: Bruce Evans Message-ID: <20040119213142.GA72803@VARK.homeunix.com> Mail-Followup-To: Bruce Evans , Steve Kargl , freebsd-standards@FreeBSD.ORG References: <20031129000133.GA30662@troutmask.apl.washington.edu> <20031129080911.GA25448@VARK.homeunix.com> <20031129163105.GA32651@troutmask.apl.washington.edu> <20031130213951.GA37082@VARK.homeunix.com> <20031201182219.O4431@gamplex.bde.org> <20031201203512.GA95524@troutmask.apl.washington.edu> <20031202091936.I8778@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031202091936.I8778@gamplex.bde.org> 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: Mon, 19 Jan 2004 21:32:16 -0000 On Tue, Dec 02, 2003, Bruce Evans wrote: > On Mon, 1 Dec 2003, Steve Kargl wrote: > > > On Mon, Dec 01, 2003 at 07:05:18PM +1100, Bruce Evans wrote: > > > All the other corner cases need to be checked. It's possibly to check > > > all 2^32 cases for floats (once you know the correct results). > > > > Do you have code to do this check? > > > > > Other things to check: setting of exception flags. I'm not sure if the > > > settings by ceil() are the right ones and the only ones. > > I thought of a good way after righting the above: roundf() is supposed to > be equivalent to rintf() with certain rounding, so set the rounding mode > and call rintf() to determine the correct value. Unfortunately there > might not be a correct rounding mode (what does round to nearest do > for integers? I think it rounds to even, but roundf() requires rounding > up half-way cases). You're right on the money. The C99 standard says: The double version of round behaves as though implemented by #include #include #pragma STDC FENV_ACCESS ON double round(double x) { double result; fenv_t save_env; feholdexcept(&save_env); result = rint(x); if (fetestexcept(FE_INEXACT)) { fesetround(FE_TOWARDZERO); result = rint(copysign(0.5 + fabs(x), x)); } feupdateenv(&save_env); return result; } The round functions may, but are not required to, raise the inexact exception for noninteger numeric arguments, as this implementation does. This should be a faster implementation in that it only has one branch. The one with ceil() has a branch for the inf/NaN test, another that I added to avoid spurious inexact exceptions, and a third to test the sign of the input. However, I think we may be able to use floor() instead of fesetround()/rint()/feupdateenv() and do something similar without changing the rounding mode: double round(double x) { double result; fp_except_t fe; fe = fpresetsticky(0); result = rint(x); if (fpgetsticky() & FP_X_IMP) { result = copysign(floor(fabs(x) + 0.5), x); fe |= FP_X_IMP; } fpresetsticky(fe); return (result); } Does this seem reasonable? By the way, the man pages refer to fpresetsticky(3), but not fpsetsticky(3). The MI ieee.h header declares only fpsetsticky(), but some architectures override these with equivalent macros for both. If you have a good idea of how this is supposed to be, it would be great if you could fix it. Another option is to just implement the relevant parts of fenv.h. They are fairly straightforward, and there's no sense in hiding behind the brokenness of gcc's i386 backend forever. (By the way, if we did implement fenv.h, does anyone know if there are any legal issues or attribution requirements involved in using the exact round() code proposed by the C standard?) From owner-freebsd-standards@FreeBSD.ORG Mon Jan 19 14:13:19 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 96F8416A4CF for ; Mon, 19 Jan 2004 14:13:19 -0800 (PST) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D6B043D4C for ; Mon, 19 Jan 2004 14:13:15 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) i0JMDETA065925; Mon, 19 Jan 2004 14:13:14 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)i0JMDEEL065924; Mon, 19 Jan 2004 14:13:14 -0800 (PST) (envelope-from sgk) Date: Mon, 19 Jan 2004 14:13:14 -0800 From: Steve Kargl To: Bruce Evans , freebsd-standards@FreeBSD.ORG Message-ID: <20040119221314.GA65652@troutmask.apl.washington.edu> References: <20031129000133.GA30662@troutmask.apl.washington.edu> <20031129080911.GA25448@VARK.homeunix.com> <20031129163105.GA32651@troutmask.apl.washington.edu> <20031130213951.GA37082@VARK.homeunix.com> <20031201182219.O4431@gamplex.bde.org> <20031201203512.GA95524@troutmask.apl.washington.edu> <20031202091936.I8778@gamplex.bde.org> <20040119213142.GA72803@VARK.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040119213142.GA72803@VARK.homeunix.com> User-Agent: Mutt/1.4.1i 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: Mon, 19 Jan 2004 22:13:19 -0000 On Mon, Jan 19, 2004 at 01:31:42PM -0800, David Schultz wrote: > > double > round(double x) > { > double result; > fp_except_t fe; > > fe = fpresetsticky(0); > result = rint(x); > if (fpgetsticky() & FP_X_IMP) { > result = copysign(floor(fabs(x) + 0.5), x); > fe |= FP_X_IMP; > } > fpresetsticky(fe); > return (result); > } > > Does this seem reasonable? Don't you need rnd = fpsetround(FP_RN); /* Set to known rounding mode */ result = rint(x); fpsetround(rnd); /* Reset to whatever the user had */ to ensure that rint() rounds to an expected value. int main(void) { double u, v, x; x = 0.5; fpsetround(FP_RM); u = round(x); fpsetround(FP_RP); v = round(x); /* Does u equal v ? */ } BTW, thanks for working on this issue. -- Steve From owner-freebsd-standards@FreeBSD.ORG Mon Jan 19 20:34:13 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 C760116A4CE for ; Mon, 19 Jan 2004 20:34:13 -0800 (PST) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEE6243D2F for ; Mon, 19 Jan 2004 20:34:11 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i0K4YAtd001992; Tue, 20 Jan 2004 15:34:10 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i0K4Y8fe001733; Tue, 20 Jan 2004 15:34:09 +1100 Date: Tue, 20 Jan 2004 15:34:09 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Steve Kargl In-Reply-To: <20040119221314.GA65652@troutmask.apl.washington.edu> Message-ID: <20040120145749.I2417@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> <20040119221314.GA65652@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-standards@FreeBSD.ORG 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: Tue, 20 Jan 2004 04:34:13 -0000 On Mon, 19 Jan 2004, Steve Kargl wrote: > On Mon, Jan 19, 2004 at 01:31:42PM -0800, David Schultz wrote: > > > > double > > round(double x) > > { > > double result; > > fp_except_t fe; > > > > fe = fpresetsticky(0); > > result = rint(x); > > if (fpgetsticky() & FP_X_IMP) { > > result = copysign(floor(fabs(x) + 0.5), x); > > fe |= FP_X_IMP; > > } > > fpresetsticky(fe); > > return (result); > > } > > > > Does this seem reasonable? > > Don't you need > > rnd = fpsetround(FP_RN); /* Set to known rounding mode */ > result = rint(x); > fpsetround(rnd); /* Reset to whatever the user had */ > > to ensure that rint() rounds to an expected value. rint() may (and apparently does in at least our i386 implementation) raise the inexact exception when it does any rounding. So if rounding is needed then it is needed only in the inexact exception case, and David's point is to avoid it there. > int main(void) { > double u, v, x; > x = 0.5; > fpsetround(FP_RM); > u = round(x); > fpsetround(FP_RP); > v = round(x); > /* Does u equal v ? */ > } Testing on i386's shows that it does :-). Bruce From owner-freebsd-standards@FreeBSD.ORG Mon Jan 19 22:10:44 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 E813116A4CE; Mon, 19 Jan 2004 22:10:44 -0800 (PST) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2E5A43D2F; Mon, 19 Jan 2004 22:10:41 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i0K6Aeug001705; Tue, 20 Jan 2004 17:10:40 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i0K6Abp2005781; Tue, 20 Jan 2004 17:10:38 +1100 Date: Tue, 20 Jan 2004 17:10:38 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: David Schultz In-Reply-To: <20040119213142.GA72803@VARK.homeunix.com> Message-ID: <20040120154127.C2417@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> <20040119213142.GA72803@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: Tue, 20 Jan 2004 06:10:45 -0000 On Mon, 19 Jan 2004, David Schultz wrote: > On Tue, Dec 02, 2003, Bruce Evans wrote: > > I thought of a good way after righting the above: roundf() is supposed to > > be equivalent to rintf() with certain rounding, so set the rounding mode > > and call rintf() to determine the correct value. Unfortunately there > > might not be a correct rounding mode (what does round to nearest do > > for integers? I think it rounds to even, but roundf() requires rounding > > up half-way cases). > > You're right on the money. The C99 standard says: > > The double version of round behaves as though implemented by > > #include > #include > #pragma STDC FENV_ACCESS ON > double round(double x) > { > double result; > fenv_t save_env; > feholdexcept(&save_env); > result = rint(x); > if (fetestexcept(FE_INEXACT)) { > fesetround(FE_TOWARDZERO); > result = rint(copysign(0.5 + fabs(x), x)); > } > feupdateenv(&save_env); > return result; > } > > The round functions may, but are not required to, raise the > inexact exception for noninteger numeric arguments, as this > implementation does. I think getting FE_INEXACT from rint() is the usual case (if the implementation actually raises it), so we gain little or negative from sometimes avoiding the more complicated rint() call. Also, if we depend on the implemenation to set FE_INEXACT, then we may be able to depend on the implementation having FE_UPWARD and FE_DOWNWARD, which seems to permit a simple implementation that I had in mind. > This should be a faster implementation in that it only has one > branch. The one with ceil() has a branch for the inf/NaN test, > another that I added to avoid spurious inexact exceptions, and a > third to test the sign of the input. The fe access functions probably cost a lot more than branches. Certainly on i386's, especially with an implementation like the current one where all feset functions set the whole FP enviroment. The above wants to save and restore the whole FP enviorment anyway. > However, I think we may be able to use floor() instead of > fesetround()/rint()/feupdateenv() and do something similar without > changing the rounding mode: > > double > round(double x) > { > double result; > fp_except_t fe; > > fe = fpresetsticky(0); > result = rint(x); > if (fpgetsticky() & FP_X_IMP) { > result = copysign(floor(fabs(x) + 0.5), x); > fe |= FP_X_IMP; > } > fpresetsticky(fe); > return (result); > } > > Does this seem reasonable? rint() is mostly in hardware on i386's (frndint instruction), so it is faster than floor(), at least on i386's. But anything that avoids accessing the FP environment is good. > By the way, the man pages refer to fpresetsticky(3), but not > fpsetsticky(3). The MI ieee.h header declares only fpsetsticky(), > but some architectures override these with equivalent macros for > both. If you have a good idea of how this is supposed to be, it > would be great if you could fix it. I once thought that fpresetsticky() was standard and fpsetsticky() was intentionally undocumented because it is nonstandard, but this seems to be backwards -- it is fpresetsticky() that is the mistake. Look them up on the web. There are more hits for fpsetsticky, and google even suggests I wanted fpsetsticky when I seach for fpresetsticky. The C99 interfaces should make these moot. It has equivalents to both, and also feraiseexcept(). > Another option is to just implement the relevant parts of fenv.h. > They are fairly straightforward, and there's no sense in hiding > behind the brokenness of gcc's i386 backend forever. Is "hiding" not bothering to implement this because gcc's bugs make it moot? I think fenv.h can't be implemented until there is "#pragma STDC FENV_ACCESS ON" or some other mechanism to turn off both the bugs and (non-buggy) optimizations. BTW, I've been using "#define const volatile const" in lib/msun for 10 years to turn off some constant folding. I'm not sure exactly what C99 says about it, but I think most FP constant folding at compile time is a valid optimization unless FENV_ACCESS is ON. To avoid depending on implementation details that aren't even implemented, msun probably needs large changes to use FENV_ACCESS a lot, and/or to use feraisexcept() instead of things like: e_exp.c: if(x > o_threshold) return huge*huge; /* overflow */ [This needs to raise FE_OVERFLOW, and depends on huge*huge doing it, but huge is just "static const double huge 1.0e+300;" and gcc -O1 folds huge*huge to +Inf at compile time and doesn't raise FE_OVERFLOW. My volatile hack forces this to be done at runtime.] > (By the way, > if we did implement fenv.h, does anyone know if there are any > legal issues or attribution requirements involved in using the > exact round() code proposed by the C standard?) I don't know, but think that we would at last have to get permission, and it would be easier to reimplement it. Bryce From owner-freebsd-standards@FreeBSD.ORG Wed Jan 21 01:18:56 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 913F916A4CE for ; Wed, 21 Jan 2004 01:18:56 -0800 (PST) Received: from VARK.homeunix.com (adsl-69-104-247-110.dsl.pltn13.pacbell.net [69.104.247.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F23E43D39 for ; Wed, 21 Jan 2004 01:18:51 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.10/8.12.10) with ESMTP id i0L9IHKu099200; Wed, 21 Jan 2004 01:18:17 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.10/8.12.10/Submit) id i0L9IHaA099199; Wed, 21 Jan 2004 01:18:17 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Wed, 21 Jan 2004 01:18:17 -0800 From: David Schultz To: Bruce Evans Message-ID: <20040121091817.GA92143@VARK.homeunix.com> Mail-Followup-To: Bruce Evans , Steve Kargl , freebsd-standards@FreeBSD.ORG References: <20031129000133.GA30662@troutmask.apl.washington.edu> <20031129080911.GA25448@VARK.homeunix.com> <20031129163105.GA32651@troutmask.apl.washington.edu> <20031130213951.GA37082@VARK.homeunix.com> <20031201182219.O4431@gamplex.bde.org> <20031201203512.GA95524@troutmask.apl.washington.edu> <20031202091936.I8778@gamplex.bde.org> <20040119213142.GA72803@VARK.homeunix.com> <20040120154127.C2417@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040120154127.C2417@gamplex.bde.org> 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 09:18:56 -0000 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 > sometimes avoiding the more complicated rint() call. Also, if we > depend on the implemenation to set FE_INEXACT, then we may be able to > depend on the implementation having FE_UPWARD and FE_DOWNWARD, which > seems to permit a simple implementation that I had in mind. 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.) > > Another option is to just implement the relevant parts of fenv.h. > > They are fairly straightforward, and there's no sense in hiding > > behind the brokenness of gcc's i386 backend forever. > > Is "hiding" not bothering to implement this because gcc's bugs make > it moot? I think fenv.h can't be implemented until there is > "#pragma STDC FENV_ACCESS ON" or some other mechanism to turn off > both the bugs and (non-buggy) optimizations. > > BTW, I've been using "#define const volatile const" in lib/msun for > 10 years to turn off some constant folding. I'm not sure exactly what > C99 says about it, but I think most FP constant folding at compile > time is a valid optimization unless FENV_ACCESS is ON. To avoid > depending on implementation details that aren't even implemented, msun > probably needs large changes to use FENV_ACCESS a lot, and/or to use > feraisexcept() instead of things like: > > e_exp.c: if(x > o_threshold) return huge*huge; /* overflow */ > > [This needs to raise FE_OVERFLOW, and depends on huge*huge doing it, > but huge is just "static const double huge 1.0e+300;" and gcc -O1 > folds huge*huge to +Inf at compile time and doesn't raise FE_OVERFLOW. > My volatile hack forces this to be done at runtime.] 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) I know about the kludges in the math library to raise various exceptions, but they should be valid with a C99 compiler and the appropriate pragma. Ultimately, it wouldn't hurt to clean them up, though, and it would be nice to have fenv.h before doing that... 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. 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