From owner-freebsd-standards@FreeBSD.ORG Mon May 31 11:02: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 62BDE16A4CE for ; Mon, 31 May 2004 11:02:16 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49C2B43D2F for ; Mon, 31 May 2004 11:02:16 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) i4VI1ouR022773 for ; Mon, 31 May 2004 11:01:50 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i4VI1nQO022767 for freebsd-standards@freebsd.org; Mon, 31 May 2004 11:01:49 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 31 May 2004 11:01:49 -0700 (PDT) Message-Id: <200405311801.i4VI1nQO022767@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, 31 May 2004 18:02:16 -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 [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 [2003/12/31] 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/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/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/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 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 28 problems total. From owner-freebsd-standards@FreeBSD.ORG Wed Jun 2 00:33: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 0F48816A4CE for ; Wed, 2 Jun 2004 00:33:08 -0700 (PDT) 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 9C8C943D31 for ; Wed, 2 Jun 2004 00:33:07 -0700 (PDT) (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 i527WZkj006473 for ; Wed, 2 Jun 2004 00:32:35 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i527WZMg006472 for standards@FreeBSD.ORG; Wed, 2 Jun 2004 00:32:35 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 2 Jun 2004 00:32:35 -0700 From: David Schultz To: standards@FreeBSD.ORG Message-ID: <20040602073235.GA6457@VARK.homeunix.com> Mail-Followup-To: standards@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: 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, 02 Jun 2004 07:33:08 -0000 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. Barring any problems that arise, I would like to commit this over the weekend. http://www.freebsd.org/~das/patches/fenv.diff Implementations are provided for all supported architectures, with caveats noted below. Perhaps the biggest caveat is that the programmer cannot count on the contents of the floating-point environment without compiler support, which gcc currently lacks. However, program behavior is reasonable with `gcc -O0', and often even with `gcc -O1'. At least we'll be ready when gcc evolves. The only other significant problem is that unmasked exceptions (which aren't standard anyway) are handled inconsistently among architectures. alpha: - All the standard features (i.e. not unmasked exceptions) appear to work. - Much of the floating-point support on the Alpha platform is emulated by the kernel. I found and fixed some kernel bugs during development, but the kernel still doesn't deliver SIGFPEs for unmasked exceptions generated by SUI-format instructions. The lack of response from alpha@ was disappointing, but I'd like to thank marcel@ for testing some changes on his hardware. amd64: - Everything appears to work, except as noted. - The kernel does not set the default FP environment appropriately for new processes. Proposed solution to amd64@. - When a signal handler is invoked for an SSE trap (but not an x87 trap ???), it is not possible to safely return from the handler. (Strictly speaking this is allowed in POSIX, but it makes it impossible to write a portable and useful SIGFPE handler.) arm: - I made an effort to get this right. However, there will certainly be bugs. I have poor documentation and no access to ARM hardware, and I couldn't even get a cross-toolchain to build. ia64: - Everything appears to work. - The same caveat about signal handlers for amd64 applies for all FP traps on ia64. i386: - Everything appears to work. powerpc: - All the standard features appear to work. - There is no powerpc machine in the main FreeBSD cluster available for testing. I did the best I could on a machine running Darwin sparc64: - Everything appears to work. From owner-freebsd-standards@FreeBSD.ORG Fri Jun 4 19:54:12 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 9073816A4CE; Fri, 4 Jun 2004 19:54:12 -0700 (PDT) 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 3C07843D31; Fri, 4 Jun 2004 19:54:12 -0700 (PDT) (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 i552rx92004039; Fri, 4 Jun 2004 19:53:59 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i552rx2x004038; Fri, 4 Jun 2004 19:53:59 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 4 Jun 2004 19:53:59 -0700 From: David Schultz To: "Steven G. Kargl" Message-ID: <20040605025359.GA3084@VARK.homeunix.com> Mail-Followup-To: "Steven G. Kargl" , FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG References: <200311291810.hATIAIWu084953@freefall.freebsd.org> <200312101711.hBAHBoEL007529@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312101711.hBAHBoEL007529@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: Sat, 05 Jun 2004 02:54:12 -0000 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. For instance, 0.5 becomes 0, and 1.5 becomes 2. I don't see an easy way to make this work in the present implementation without fiddling with the underlying bits. Perhaps we need to implement it more similarly to fdlibm's rint(). 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. From owner-freebsd-standards@FreeBSD.ORG Fri Jun 4 20:01:11 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 6C5CD16A4CE for ; Fri, 4 Jun 2004 20:01:11 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6641543D2F for ; Fri, 4 Jun 2004 20:01:11 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i5530lfi044236 for ; Fri, 4 Jun 2004 20:00:47 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i5530loM044235; Fri, 4 Jun 2004 20:00:47 -0700 (PDT) (envelope-from gnats) Date: Fri, 4 Jun 2004 20:00:47 -0700 (PDT) Message-Id: <200406050300.i5530loM044235@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: Sat, 05 Jun 2004 03:01:11 -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: Fri, 4 Jun 2004 19:53:59 -0700 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. For instance, 0.5 becomes 0, and 1.5 becomes 2. I don't see an easy way to make this work in the present implementation without fiddling with the underlying bits. Perhaps we need to implement it more similarly to fdlibm's rint(). 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. From owner-freebsd-standards@FreeBSD.ORG Sat Jun 5 15:49:52 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 C3B2F16A4CE; Sat, 5 Jun 2004 15:49:52 -0700 (PDT) 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 82F7F43D2F; Sat, 5 Jun 2004 15:49:52 -0700 (PDT) (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 i55MnGsK003352; Sat, 5 Jun 2004 15:49:16 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.11/8.12.10/Submit) id i55MnGNl003351; Sat, 5 Jun 2004 15:49:16 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Sat, 5 Jun 2004 15:49:16 -0700 From: David Schultz To: "Steven G. Kargl" , FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Message-ID: <20040605224915.GA3306@VARK.homeunix.com> Mail-Followup-To: "Steven G. Kargl" , FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG References: <200311291810.hATIAIWu084953@freefall.freebsd.org> <200312101711.hBAHBoEL007529@troutmask.apl.washington.edu> <20040605025359.GA3084@VARK.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040605025359.GA3084@VARK.homeunix.com> 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: Sat, 05 Jun 2004 22:49:52 -0000 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. From owner-freebsd-standards@FreeBSD.ORG Sat Jun 5 15:50:45 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 5CBD516A4E2 for ; Sat, 5 Jun 2004 15:50:45 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55CEB43D45 for ; Sat, 5 Jun 2004 15:50:45 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i55MoUKq087072 for ; Sat, 5 Jun 2004 15:50:30 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i55MoU9e087071; Sat, 5 Jun 2004 15:50:30 -0700 (PDT) (envelope-from gnats) Date: Sat, 5 Jun 2004 15:50:30 -0700 (PDT) Message-Id: <200406052250.i55MoU9e087071@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: Sat, 05 Jun 2004 22:50:45 -0000 The following reply was made to PR standards/59797; it has been noted by GNATS. From: David Schultz To: "Steven G. Kargl" , FreeBSD-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Cc: Subject: Re: standards/59797: Implement C99's round[f]() math fucntions Date: Sat, 5 Jun 2004 15:49:16 -0700 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.