From owner-freebsd-standards@FreeBSD.ORG Mon Jun 7 01:28:23 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 D146016A4D8; Mon, 7 Jun 2004 01:28:23 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB8A143D1F; Sun, 6 Jun 2004 18:28:23 -0700 (PDT) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) i571SNeG068543; Sun, 6 Jun 2004 18:28:23 -0700 (PDT) (envelope-from kargl@troutmask.apl.washington.edu) Received: (from kargl@localhost)i571SNuN068542; Sun, 6 Jun 2004 18:28:23 -0700 (PDT) (envelope-from kargl) From: "Steven G. Kargl" Message-Id: <200406070128.i571SNuN068542@troutmask.apl.washington.edu> In-Reply-To: <20040605224915.GA3306@VARK.homeunix.com> To: David Schultz Date: Sun, 6 Jun 2004 18:28:23 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL99f (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: FreeBSD-gnats-submit@FreeBSD.ORG cc: freebsd-standards@FreeBSD.ORG Subject: Re: standards/59797: Implement C99's round[f]() math fucntions 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, 07 Jun 2004 01:28:24 -0000 David Schultz wrote: > On Fri, Jun 04, 2004, David Schultz wrote: > > Sorry, I've put this off way too long. The good news is that I'm > > now going to do something about it. The bad news is that I found > > a significant bug in the proposed implementation. Namely, round() > > and roundf() often get the wrong answer for halfway cases. In > > IEEE-754 round-to-nearest mode, numbers that are halfway between > > two representable numbers are supposed to be rounded to even. > > It seems I've paged out more material from my brain than I thought > since I last looked at this. POSIX defines round() to > specifically *not* use the IEEE-754 round-to-nearest behavior. > Your implementation is absolutely correct, Steve, and it even gets > the exception flags right. (I tested all positive inputs to > roundf(), probed inputs to round() uniformly at random for a few > minutes, and checked important special cases.) I'll go ahead and > commit it with minor style and doc fixes. > I would have to go back and review the PR for all the discussion, but I thought bde had proposed using rint(3) with an appropriate rounding mode. Anyway, whatever you decide to do is fine with me. BTW, thanks for the work on fenv. Sorry, I couldn't provide a review. I did look at your patch, but it was way over my head. -- Steve http://troutmask.apl.washington.edu/~kargl/ From owner-freebsd-standards@FreeBSD.ORG Mon Jun 7 01:30:29 2004 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3182116A4CE for ; Mon, 7 Jun 2004 01:30:29 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2ADCC43D1D for ; Sun, 6 Jun 2004 18:30:29 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i571UTA4006071 for ; Mon, 7 Jun 2004 01:30:29 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i571USSY006070; Mon, 7 Jun 2004 01:30:28 GMT (envelope-from gnats) Date: Mon, 7 Jun 2004 01:30:28 GMT Message-Id: <200406070130.i571USSY006070@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: "Steven G. Kargl" Subject: Re: standards/59797: Implement C99's round[f]() math fucntions X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Steven G. Kargl" List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 01:30:29 -0000 The following reply was made to PR standards/59797; it has been noted by GNATS. From: "Steven G. Kargl" To: David Schultz Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: standards/59797: Implement C99's round[f]() math fucntions Date: Sun, 6 Jun 2004 18:28:23 -0700 (PDT) David Schultz wrote: > On Fri, Jun 04, 2004, David Schultz wrote: > > Sorry, I've put this off way too long. The good news is that I'm > > now going to do something about it. The bad news is that I found > > a significant bug in the proposed implementation. Namely, round() > > and roundf() often get the wrong answer for halfway cases. In > > IEEE-754 round-to-nearest mode, numbers that are halfway between > > two representable numbers are supposed to be rounded to even. > > It seems I've paged out more material from my brain than I thought > since I last looked at this. POSIX defines round() to > specifically *not* use the IEEE-754 round-to-nearest behavior. > Your implementation is absolutely correct, Steve, and it even gets > the exception flags right. (I tested all positive inputs to > roundf(), probed inputs to round() uniformly at random for a few > minutes, and checked important special cases.) I'll go ahead and > commit it with minor style and doc fixes. > I would have to go back and review the PR for all the discussion, but I thought bde had proposed using rint(3) with an appropriate rounding mode. Anyway, whatever you decide to do is fine with me. BTW, thanks for the work on fenv. Sorry, I couldn't provide a review. I did look at your patch, but it was way over my head. -- Steve http://troutmask.apl.washington.edu/~kargl/ From owner-freebsd-standards@FreeBSD.ORG Mon Jun 7 01:33:54 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 2D1F616A4CE; Mon, 7 Jun 2004 01:33:54 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id D523E43D31; Sun, 6 Jun 2004 18:33:53 -0700 (PDT) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) i571XrHl068577; Sun, 6 Jun 2004 18:33:53 -0700 (PDT) (envelope-from kargl@troutmask.apl.washington.edu) Received: (from kargl@localhost)i571Xrxu068576; Sun, 6 Jun 2004 18:33:53 -0700 (PDT) (envelope-from kargl) From: "Steven G. Kargl" Message-Id: <200406070133.i571Xrxu068576@troutmask.apl.washington.edu> In-Reply-To: <20040605025359.GA3084@VARK.homeunix.com> To: David Schultz Date: Sun, 6 Jun 2004 18:33:53 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL99f (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: FreeBSD-gnats-submit@FreeBSD.ORG cc: freebsd-standards@FreeBSD.ORG Subject: Re: standards/59797: Implement C99's round[f]() math fucntions 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, 07 Jun 2004 01:33:54 -0000 David Schultz wrote: > > BTW, benchmarking shows that using the sample implementation that > appears in the C99 standard results in a slowdown of two orders of > magnitude over your round() implementation and four orders of > magnitude over the x87 frndint instruction. Just setting the > rounding mode and calling rint() also results in a significant > slowdown. Thus, we definitely want something that's in the spirit > of what you wrote, but perhaps one that operates on the bits directly. > I looked at the glibc implementation of round(). It does bit twiddling, but I would definitely recommend not using the glibc version because of licensing and possible copyright infringement concerns [hiint compare glibc's round() with fdlibm's ceil()]. -- Steve http://troutmask.apl.washington.edu/~kargl/ From owner-freebsd-standards@FreeBSD.ORG Mon Jun 7 01:40:12 2004 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F94116A4CE for ; Mon, 7 Jun 2004 01:40:12 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 589BE43D31 for ; Sun, 6 Jun 2004 18:40:12 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i571eCUr006307 for ; Mon, 7 Jun 2004 01:40:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i571eC4P006306; Mon, 7 Jun 2004 01:40:12 GMT (envelope-from gnats) Date: Mon, 7 Jun 2004 01:40:12 GMT Message-Id: <200406070140.i571eC4P006306@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: "Steven G. Kargl" Subject: Re: standards/59797: Implement C99's round[f]() math fucntions X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Steven G. Kargl" List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 01:40:12 -0000 The following reply was made to PR standards/59797; it has been noted by GNATS. From: "Steven G. Kargl" To: David Schultz Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: standards/59797: Implement C99's round[f]() math fucntions Date: Sun, 6 Jun 2004 18:33:53 -0700 (PDT) David Schultz wrote: > > BTW, benchmarking shows that using the sample implementation that > appears in the C99 standard results in a slowdown of two orders of > magnitude over your round() implementation and four orders of > magnitude over the x87 frndint instruction. Just setting the > rounding mode and calling rint() also results in a significant > slowdown. Thus, we definitely want something that's in the spirit > of what you wrote, but perhaps one that operates on the bits directly. > I looked at the glibc implementation of round(). It does bit twiddling, but I would definitely recommend not using the glibc version because of licensing and possible copyright infringement concerns [hiint compare glibc's round() with fdlibm's ceil()]. -- Steve http://troutmask.apl.washington.edu/~kargl/ From owner-freebsd-standards@FreeBSD.ORG Mon Jun 7 08:12:14 2004 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12EA016A4CE; Mon, 7 Jun 2004 08:12:14 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9F8543D1F; Mon, 7 Jun 2004 08:12:13 +0000 (GMT) (envelope-from das@FreeBSD.org) Received: from freefall.freebsd.org (das@localhost [127.0.0.1]) i578CBEP019191; Mon, 7 Jun 2004 08:12:11 GMT (envelope-from das@freefall.freebsd.org) Received: (from das@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i578CBMp019187; Mon, 7 Jun 2004 08:12:11 GMT (envelope-from das) Date: Mon, 7 Jun 2004 08:12:11 GMT From: David Schultz Message-Id: <200406070812.i578CBMp019187@freefall.freebsd.org> To: kargl@troutmask.apl.washington.edu, das@FreeBSD.org, freebsd-standards@FreeBSD.org Subject: Re: standards/59797: Implement C99's round[f]() math fucntions 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, 07 Jun 2004 08:12:14 -0000 Synopsis: Implement C99's round[f]() math fucntions State-Changed-From-To: open->closed State-Changed-By: das State-Changed-When: Mon Jun 7 08:11:51 GMT 2004 State-Changed-Why: Committed at long last! http://www.freebsd.org/cgi/query-pr.cgi?pr=59797 From owner-freebsd-standards@FreeBSD.ORG Mon Jun 7 11:02:08 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 DDD2216A4F3 for ; Mon, 7 Jun 2004 11:02:07 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4B8B43D31 for ; Mon, 7 Jun 2004 11:02:07 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i57B26dR043541 for ; Mon, 7 Jun 2004 11:02:06 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i57B25BJ043535 for freebsd-standards@freebsd.org; Mon, 7 Jun 2004 11:02:05 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 7 Jun 2004 11:02:05 GMT Message-Id: <200406071102.i57B25BJ043535@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, 07 Jun 2004 11:02:08 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- s [2001/01/24] misc/24590 standards timezone function not compatible witn Sin o [2001/03/05] bin/25542 standards /bin/sh: null char in quoted string 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/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 [2004/01/01] standards/60772standards _Bool and bool should be unsigned o [2004/02/05] standards/62388standards sys/resource.h does not pull in dependenc o [2004/05/13] standards/66608standards sigprocmask() does not work with pthread 11 problems 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 o [2001/01/16] bin/24390 standards Replacing old dir-symlinks when using /bi s [2001/06/18] kern/28260 standards UIO_MAXIOV needs to be made public o [2001/11/20] standards/32126standards getopt(3) not Unix-98 conformant s [2002/03/19] standards/36076standards Implementation of POSIX fuser command o [2002/06/14] 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/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/25] 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/05] standards/56476standards cd9660 unicode support simple hack o [2003/10/12] standards/57911standards fnmatch ("[[:alpha:]]","x", FNM_PATHNAME) o [2003/10/29] standards/58676standards grantpt(3) alters storage used by ptsname p [2003/12/26] standards/60597standards FreeBSD's /usr/include lacks of cpio.h s [2004/02/14] standards/62858standards malloc(0) not C99 compliant p [2004/02/21] standards/63173standards Patch to add getopt_long_only(3) to libc o [2004/05/07] standards/66357standards make POSIX conformance problem ('sh -e' & o [2004/05/11] standards/66531standards _gettemp uses a far smaller set of filena 27 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon Jun 7 22:10:34 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 79BF916A4CE; Mon, 7 Jun 2004 22:10:34 +0000 (GMT) Received: from VARK.homeunix.com (ar59.lsanca2-4.27.98.47.lsanca2.dsl-verizon.net [4.27.98.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2514C43D5C; Mon, 7 Jun 2004 22:10:34 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.11/8.12.10) with ESMTP id i576chbJ013362; Sun, 6 Jun 2004 23:38:43 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i576ch2H013361; Sun, 6 Jun 2004 23:38:43 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Sun, 6 Jun 2004 23:38:43 -0700 From: David Schultz To: "Steven G. Kargl" Message-ID: <20040607063843.GB13248@VARK.homeunix.com> Mail-Followup-To: "Steven G. Kargl" , FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG References: <20040605224915.GA3306@VARK.homeunix.com> <200406070128.i571SNuN068542@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406070128.i571SNuN068542@troutmask.apl.washington.edu> cc: FreeBSD-gnats-submit@FreeBSD.ORG cc: freebsd-standards@FreeBSD.ORG Subject: Re: standards/59797: Implement C99's round[f]() math fucntions 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, 07 Jun 2004 22:10:34 -0000 On Sun, Jun 06, 2004, Steven G. Kargl wrote: > I would have to go back and review the PR for all the discussion, > but I thought bde had proposed using rint(3) with an appropriate > rounding mode. Anyway, whatever you decide to do is fine with > me. I found that setting the rounding mode and calling rint(3) is significantly slower on x87, and that's not counting the special handling for the halfway cases. The bit-fiddling approach is a little bit faster than yours (I compared against ceil()), but it's much harder to maintain. Consider that rintf() still has bugs, and it has been around for over a decade! > I looked at the glibc implementation of round(). It does > bit twiddling, but I would definitely recommend not using > the glibc version because of licensing and possible copyright > infringement concerns [hiint compare glibc's round() with > fdlibm's ceil()]. Hmmm...the glibc implementation does indeed appear to be plagiarized. Perhaps someone should let the glibc folks know. From owner-freebsd-standards@FreeBSD.ORG Mon Jun 7 22:20:21 2004 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20E5E16A4D0 for ; Mon, 7 Jun 2004 22:20:21 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1888543D31 for ; Mon, 7 Jun 2004 22:20:21 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i57MKKxC016115 for ; Mon, 7 Jun 2004 22:20:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i57MKKex016114; Mon, 7 Jun 2004 22:20:20 GMT (envelope-from gnats) Date: Mon, 7 Jun 2004 22:20:20 GMT Message-Id: <200406072220.i57MKKex016114@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: David Schultz Subject: Re: standards/59797: Implement C99's round[f]() math fucntions X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Schultz List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 22:20:21 -0000 The following reply was made to PR standards/59797; it has been noted by GNATS. From: David Schultz To: "Steven G. Kargl" Cc: FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: standards/59797: Implement C99's round[f]() math fucntions Date: Sun, 6 Jun 2004 23:38:43 -0700 On Sun, Jun 06, 2004, Steven G. Kargl wrote: > I would have to go back and review the PR for all the discussion, > but I thought bde had proposed using rint(3) with an appropriate > rounding mode. Anyway, whatever you decide to do is fine with > me. I found that setting the rounding mode and calling rint(3) is significantly slower on x87, and that's not counting the special handling for the halfway cases. The bit-fiddling approach is a little bit faster than yours (I compared against ceil()), but it's much harder to maintain. Consider that rintf() still has bugs, and it has been around for over a decade! > I looked at the glibc implementation of round(). It does > bit twiddling, but I would definitely recommend not using > the glibc version because of licensing and possible copyright > infringement concerns [hiint compare glibc's round() with > fdlibm's ceil()]. Hmmm...the glibc implementation does indeed appear to be plagiarized. Perhaps someone should let the glibc folks know. From owner-freebsd-standards@FreeBSD.ORG Tue Jun 8 03:16:18 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 ECE5816A4CE; Tue, 8 Jun 2004 03:16:18 +0000 (GMT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 955FA43D46; Tue, 8 Jun 2004 03:16:18 +0000 (GMT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id i583GEkP038134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Mon, 7 Jun 2004 23:16:15 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.9/8.12.9/Submit) id i583GECP038131; Mon, 7 Jun 2004 23:16:14 -0400 (EDT) (envelope-from wollman) Date: Mon, 7 Jun 2004 23:16:14 -0400 (EDT) From: Garrett Wollman Message-Id: <200406080316.i583GECP038131@khavrinen.lcs.mit.edu> To: Ken Smith In-Reply-To: <20040608024746.GB25445@electra.cse.Buffalo.EDU> References: <20040607.082534.17038697.imp@bsdimp.com> <200406071712.i57HC805042166@grimreaper.grondar.org> <20040608024746.GB25445@electra.cse.Buffalo.EDU> X-Spam-Score: -19.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES X-Scanned-By: MIMEDefang 2.37 cc: standards@FreeBSD.ORG cc: des@FreeBSD.ORG Subject: Re: cvs commit: CVSROOT cfg_local.pm 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, 08 Jun 2004 03:16:19 -0000 [Moving this discussion to -standards.] < said: > It sounds like it would be better for the system to say "UTC" instead > of "GMT" in the absence of /etc/localtime. Does anyone disagree? I don't think POSIX reaches this question. It says that there shall be a default timezone used when the TZ variable is not set, but doesn't say how this is established or what it should be, so I'm fine with that. (But it will be a challenge to find the right bits in localtime.c to frob in order to make it happen, as I just found when I looked.) -GAWollman From owner-freebsd-standards@FreeBSD.ORG Tue Jun 8 03:26: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 6F8A516A4CE; Tue, 8 Jun 2004 03:26:35 +0000 (GMT) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E15D43D41; Tue, 8 Jun 2004 03:26:35 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (kensmith@localhost [127.0.0.1]) i583QXAx026949; Mon, 7 Jun 2004 23:26:33 -0400 (EDT) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.10/8.12.9/Submit) id i583QXu6026948; Mon, 7 Jun 2004 23:26:33 -0400 (EDT) Date: Mon, 7 Jun 2004 23:26:33 -0400 From: Ken Smith To: Garrett Wollman Message-ID: <20040608032633.GF25445@electra.cse.Buffalo.EDU> References: <20040607.082534.17038697.imp@bsdimp.com> <200406071712.i57HC805042166@grimreaper.grondar.org> <20040608024746.GB25445@electra.cse.Buffalo.EDU> <200406080316.i583GECP038131@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406080316.i583GECP038131@khavrinen.lcs.mit.edu> User-Agent: Mutt/1.4.1i cc: standards@FreeBSD.ORG cc: Ken Smith cc: des@FreeBSD.ORG Subject: Re: cvs commit: CVSROOT cfg_local.pm 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, 08 Jun 2004 03:26:35 -0000 On Mon, Jun 07, 2004 at 11:16:14PM -0400, Garrett Wollman wrote: > [Moving this discussion to -standards.] > > < said: > > > It sounds like it would be better for the system to say "UTC" instead > > of "GMT" in the absence of /etc/localtime. Does anyone disagree? > > I don't think POSIX reaches this question. It says that there shall > be a default timezone used when the TZ variable is not set, but > doesn't say how this is established or what it should be, so I'm fine > with that. (But it will be a challenge to find the right bits in > localtime.c to frob in order to make it happen, as I just found when I > looked.) Thanks - I should have realized this was where to ask. :-( Since I brought it up I'm willing to try and find what needs to be changed unless someone else feels a burning need to do it themselves, I don't want to step on toes. If it's me I would be assuming this is something that would need to happen before -current becomes -stable and that it would not be retro-fitted to 4.X since it has the potential for breakage. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | From owner-freebsd-standards@FreeBSD.ORG Tue Jun 8 15:14:36 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 A2C1F16A4CE; Tue, 8 Jun 2004 15:14:36 +0000 (GMT) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 510AD43D45; Tue, 8 Jun 2004 15:14:36 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (kensmith@localhost [127.0.0.1]) i58FEMAx014813; Tue, 8 Jun 2004 11:14:22 -0400 (EDT) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.10/8.12.9/Submit) id i58FELn6014812; Tue, 8 Jun 2004 11:14:21 -0400 (EDT) Date: Tue, 8 Jun 2004 11:14:21 -0400 From: Ken Smith To: standards@freebsd.org Message-ID: <20040608151421.GA14487@electra.cse.Buffalo.EDU> References: <20040607.082534.17038697.imp@bsdimp.com> <200406071712.i57HC805042166@grimreaper.grondar.org> <20040608024746.GB25445@electra.cse.Buffalo.EDU> <200406080316.i583GECP038131@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406080316.i583GECP038131@khavrinen.lcs.mit.edu> User-Agent: Mutt/1.4.1i cc: wollman@freebsd.org cc: des@freebsd.org Subject: Re: cvs commit: CVSROOT cfg_local.pm 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, 08 Jun 2004 15:14:36 -0000 On Mon, Jun 07, 2004 at 11:16:14PM -0400, Garrett Wollman wrote: > [Moving this discussion to -standards.] > > < said: > > > It sounds like it would be better for the system to say "UTC" instead > > of "GMT" in the absence of /etc/localtime. Does anyone disagree? > > I don't think POSIX reaches this question. It says that there shall > be a default timezone used when the TZ variable is not set, but > doesn't say how this is established or what it should be, so I'm fine > with that. (But it will be a challenge to find the right bits in > localtime.c to frob in order to make it happen, as I just found when I > looked.) > Believe it or not, if we don't mind all the mention of GMT in the file and all the functions/variables being named "gmt" then I think this is all that's needed: Index: localtime.c =================================================================== RCS file: /home/ncvs/src/lib/libc/stdtime/localtime.c,v retrieving revision 1.36 diff -u -r1.36 localtime.c --- localtime.c 16 Feb 2003 17:29:11 -0000 1.36 +++ localtime.c 8 Jun 2004 04:49:30 -0000 @@ -70,7 +70,7 @@ static char wildabbr[] = "WILDABBR"; -static const char gmt[] = "GMT"; +static const char gmt[] = "UTC"; struct ttinfo { /* time type information */ long tt_gmtoff; /* GMT offset in seconds */ -------------------------- It seems to be working: breathed 25 % uname -a FreeBSD breathed.cse.buffalo.edu 5.2-CURRENT FreeBSD 5.2-CURRENT #2: Tue Jun 8 06:59:48 EDT 2004 root@breathed.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC sparc64 breathed 26 % date Tue Jun 8 15:04:49 UTC 2004 breathed 27 % setenv TZ GMT breathed 28 % date Tue Jun 8 15:04:55 GMT 2004 breathed 29 % setenv TZ EST5EDT breathed 30 % date Tue Jun 8 11:05:08 EDT 2004 breathed 31 % unsetenv TZ breathed 32 % date Tue Jun 8 15:05:13 UTC 2004 breathed 33 % -------------------------- I'm new to changes like this... Has this been brought up in enough places to proceed in a few days (give people a bit more time to decide to complain)? -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | From owner-freebsd-standards@FreeBSD.ORG Wed Jun 9 12:16:11 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 1193716A4CE for ; Wed, 9 Jun 2004 12:16:11 +0000 (GMT) Received: from bgezal.rise.tuwien.ac.at (bgezal.rise.tuwien.ac.at [128.130.59.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F93C43D66 for ; Wed, 9 Jun 2004 12:16:10 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from fafoe.narf.at (unknown [212.186.3.235]) by bgezal.rise.tuwien.ac.at (Postfix) with ESMTP id CDB3B20B0 for ; Wed, 9 Jun 2004 14:16:05 +0200 (CEST) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.1.42]) by fafoe.narf.at (Postfix) with ESMTP id 8337640B6 for ; Wed, 9 Jun 2004 14:15:55 +0200 (CEST) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id 5CC8F38C; Wed, 9 Jun 2004 14:15:51 +0200 (CEST) Date: Wed, 9 Jun 2004 14:15:50 +0200 From: Stefan Farfeleder To: standards@FreeBSD.ORG Message-ID: <20040609121547.GG715@wombat.fafoe.narf.at> Mail-Followup-To: standards@FreeBSD.ORG References: <20040602073235.GA6457@VARK.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040602073235.GA6457@VARK.homeunix.com> User-Agent: Mutt/1.5.6i Subject: Re: RFC: fenv.h 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, 09 Jun 2004 12:16:11 -0000 On Wed, Jun 02, 2004 at 12:32:35AM -0700, David Schultz wrote: > The following patch adds the fenv.h header to FreeBSD. I would > appreciate any reviews of these changes. Descriptions of the various > functions are included in the patch in the form of some manpages. Thanks for committing this! Just a small nit: Using inline functions with internal linkage to implement standard library functions isn't 100% conforming. 7.1.2#6: Any declaration of a library function shall have external linkage. 7.1.4#2: Provided that a library function can be declared without reference to any type defined in a header, it is also permissible to declare the function and use it without including its associated header. Stefan From owner-freebsd-standards@FreeBSD.ORG Wed Jun 9 22:32:31 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 293E916A4CE; Wed, 9 Jun 2004 22:32:31 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74A1643D53; Wed, 9 Jun 2004 22:32:30 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i59MWP5v008500; Thu, 10 Jun 2004 08:32:25 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i59MWMLS015251; Thu, 10 Jun 2004 08:32:23 +1000 Date: Thu, 10 Jun 2004 08:32:22 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Stefan Farfeleder In-Reply-To: <20040510153731.GP29712@wombat.fafoe.narf.at> Message-ID: <20040610074734.L6340@gamplex.bde.org> References: <20040508194748.GN29712@wombat.fafoe.narf.at> <20040509201148.P8241@gamplex.bde.org> <20040510153731.GP29712@wombat.fafoe.narf.at> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-standards@freebsd.org Subject: Re: Fixing ilogb() 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, 09 Jun 2004 22:32:31 -0000 Long ago, On Mon, 10 May 2004, Stefan Farfeleder wrote: > On Sun, May 09, 2004 at 09:44:03PM +1000, Bruce Evans wrote: > [about delayed detection of exceptional cases] > > Thanks for your comments, Bruce. A revised patch is attached, it only adds two > instructions in the common case. > > > > > % + movl $0x7fffffff,%eax /* FP_ILOGBNAN, INT_MAX */ > > > > Style bugs: some comments could be improved, but won't be needed when > > is used. > > Unfortunately cannot be included for FP_ILOGB{0,NAN}, so I've > duplicated those #defines for now. Any suggestions? Move them to another/new > header instead? I'm happy with this version, but I tried using ilogb() to implement fls() and while micro-optimizing things it became clear that the MI C version of ilogb() is good enough. The difference is only a few cycles. On an old Celeron, the MI C version can be tweaked to save a few instructions and then it is actually faster than the MD version except probably for denormal inputs. On an Athlon XP, the FPU is relatively faster than integer instructions, so it is hard to beat in C, but it can be beaten for non-denormal inputs by using the same integer algorithm as the C version. The integer algorithm is especially efficent on i386's because the parameter is passed on the stack so no conversions are required. On an Athlon64, the parameter has to be moved from %xmm0 for both the integer version and for fxtract, so the integer algorithm should lose nothing. Tweaked versions: These use correct algorithms but may have some details wrong. The patch for s_ilogb.S includes all your changes: %%% Index: s_ilogb.S =================================================================== RCS file: /home/ncvs/src/lib/msun/i387/s_ilogb.S,v retrieving revision 1.8 diff -u -2 -r1.8 s_ilogb.S --- s_ilogb.S 6 Jun 2000 12:12:36 -0000 1.8 +++ s_ilogb.S 9 Jun 2004 20:47:56 -0000 @@ -34,9 +34,34 @@ */ +#include #include RCSID("$FreeBSD: src/lib/msun/i387/s_ilogb.S,v 1.8 2000/06/06 12:12:36 bde Exp $") +#define FP_ILOGB0 (-__INT_MAX) +#define FP_ILOGBNAN __INT_MAX +#define FP_ILOGBINF __INT_MAX + ENTRY(ilogb) + movl 8(%esp),%eax + andl $0x7FF00000,%eax +#if 0 + je 1f # zero or denormal + cmpl $0x7FF00000,%eax + je 1f # Inf or NaN +#else + decl %eax + cmpl $0x7FEFFFFF,%eax + jae 1f +#endif + shrl $20,%eax + subl $1022,%eax + ret + +1: + /* + * Lots of dead code left by above -- should jump further (but + * fxtract is probably still the best way to handle denormals). + */ pushl %ebp movl %esp,%ebp @@ -45,9 +70,34 @@ fldl 8(%ebp) fxtract - fstp %st + fstp %st(0) fistpl -4(%ebp) movl -4(%ebp),%eax + /* fistpl yields __INT_MIN for NaN, Inf and 0. */ + cmpl $__INT_MIN,%eax + je .L2 + +.L1: leave ret + +.L2: + fldl 8(%ebp) + fldz + fucompp + fnstsw %ax + sahf + jp .L3 + jz .L4 + + movl $FP_ILOGBINF,%eax + jmp .L1 + +.L3: + movl $FP_ILOGBNAN,%eax + jmp .L1 + +.L4: + movl $FP_ILOGB0,%eax + jmp .L1 %%% The "if 0" clause gives better classification (it has rotted - the it needs an adjustment of 1023 instead of 1022). The else clase is micro-optimized to avoid a branch. Tweaked ilogb() (same branch avoidance): %%% int xilogb(double x) { int32_t hx,lx,ix,xx; EXTRACT_WORDS(hx,lx,x); xx = hx & 0x7ff00000; if ((uint32_t)(xx-1)<0x7fefffff) return (xx>>20)-1022; if(xx==0) { hx &= 0x7fffffff; if((hx|lx)==0) return 0x80000001; /* ilogb(0) = 0x80000001 */ else /* subnormal x */ if(hx==0) { for (ix = -1043; lx>0; lx<<=1) ix -=1; } else { for (ix = -1022,hx<<=11; hx>0; hx<<=1) ix -=1; } return ix; } else return 0x7fffffff; } %%% Bruce From owner-freebsd-standards@FreeBSD.ORG Wed Jun 9 23:04:15 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 8DE1D16A4E4 for ; Wed, 9 Jun 2004 23:04:15 +0000 (GMT) Received: from VARK.homeunix.com (ar59.lsanca2-4.27.98.47.lsanca2.dsl-verizon.net [4.27.98.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CCC943D1F for ; Wed, 9 Jun 2004 23:04:15 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.11/8.12.10) with ESMTP id i59N4DQi005274 for ; Wed, 9 Jun 2004 16:04:13 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i59N4D7x005273 for standards@FreeBSD.ORG; Wed, 9 Jun 2004 16:04:13 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 9 Jun 2004 16:04:13 -0700 From: David Schultz To: standards@FreeBSD.ORG Message-ID: <20040609230413.GA5164@VARK.homeunix.com> Mail-Followup-To: standards@FreeBSD.ORG References: <20040602073235.GA6457@VARK.homeunix.com> <20040609121547.GG715@wombat.fafoe.narf.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040609121547.GG715@wombat.fafoe.narf.at> Subject: Re: RFC: fenv.h 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, 09 Jun 2004 23:04:15 -0000 On Wed, Jun 09, 2004, Stefan Farfeleder wrote: > On Wed, Jun 02, 2004 at 12:32:35AM -0700, David Schultz wrote: > > The following patch adds the fenv.h header to FreeBSD. I would > > appreciate any reviews of these changes. Descriptions of the various > > functions are included in the patch in the form of some manpages. > > Thanks for committing this! > > Just a small nit: Using inline functions with internal linkage to > implement standard library functions isn't 100% conforming. > > 7.1.2#6: > Any declaration of a library function shall have external linkage. > > 7.1.4#2: > Provided that a library function can be declared without reference to > any type defined in a header, it is also permissible to declare the > function and use it without including its associated header. Yeah, I know, but gcc makes the implementation of this detail very ugly! There are three kinds of inline functions: 'static inline', 'extern inline', and just plain 'inline'. If we had a C99-conformant compiler, we could just say this: fenv.h: inline int fefoo(int x) { ... } fenv.c: extern inline int fefoo(int x); This would automatically generate a symbol fefoo() in libm, and it would tell the compiler to either inline calls to fefoo(), *or* generate an external reference to the version in the library. However, gcc disagrees with the C99 standard on the meaning of 'inline' and 'extern inline'. The only case in which gcc and the standard agree is 'static inline'. As you pointed out, this results in not-quite-standard definitions. It also wastes a little bit of space. The rationale for doing things this way is that the gcc developers are planning on implementing C99-style inlines. At this point, we don't know what the appropriate compile-time test will be to determine whether we have the old gcc or the new gcc, because the new gcc doesn't exist yet. Therefore, any solution of the form `#if __GNUC__ >= ...' is going to break some day. I'm hoping that with the way I did it, it will be easy to fix ``the right way'' when gcc's inline misfeature is gone. BTW, our has a nasty but simple kludge to work around the problem. If you can't wait for the gcc developers, you're welcome to port that solution.