From owner-freebsd-standards@FreeBSD.ORG Mon Dec 3 08:06:09 2007 Return-Path: Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B513316A41B for ; Mon, 3 Dec 2007 08:06:09 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.freebsd.org (Postfix) with ESMTP id 7727C13C4D5 for ; Mon, 3 Dec 2007 08:06:09 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.14.2/8.14.1) with ESMTP id lB37i82X011212; Mon, 3 Dec 2007 02:44:08 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.14.2/8.14.1/Submit) id lB37i8Hk011211; Mon, 3 Dec 2007 02:44:08 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Mon, 3 Dec 2007 02:44:08 -0500 From: David Schultz To: Steve Kargl Message-ID: <20071203074407.GA10989@VARK.MIT.EDU> Mail-Followup-To: Steve Kargl , Bruce Evans , freebsd-standards@FreeBSD.ORG References: <20070928152227.GA39233@troutmask.apl.washington.edu> <20071001173736.U1985@besplex.bde.org> <20071002001154.GA3782@troutmask.apl.washington.edu> <20071002172317.GA95181@VARK.MIT.EDU> <20071002173237.GA12586@troutmask.apl.washington.edu> <20071003103519.X14175@delplex.bde.org> <20071010204249.GA7446@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071010204249.GA7446@troutmask.apl.washington.edu> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: long double broken on i386? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2007 08:06:09 -0000 Is the latest version of the patch the one you sent to the list? If cosl and friends produce accurate answers within a reasonable domain, it's worth committing; the whole business about how accurate cosl(1000000000) is can be dealt with later. From owner-freebsd-standards@FreeBSD.ORG Mon Dec 3 11:07:10 2007 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 351AA16A49E for ; Mon, 3 Dec 2007 11:07:10 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2467913C43E for ; Mon, 3 Dec 2007 11:07:10 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lB3B7AJ9005735 for ; Mon, 3 Dec 2007 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id lB3B79hm005731 for freebsd-standards@FreeBSD.org; Mon, 3 Dec 2007 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Dec 2007 11:07:09 GMT Message-Id: <200712031107.lB3B79hm005731@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2007 11:07:10 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/25542 standards /bin/sh: null char in quoted string o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/82654 standards C99 long double math functions are missing o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY 4 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/21519 standards sys/dir.h should be deprecated some more o bin/24390 standards Replacing old dir-symlinks when using /bin/ln s stand/24590 standards timezone function not compatible witn Single Unix Spec s stand/36076 standards Implementation of POSIX fuser command o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings p stand/41576 standards POSIX compliance of ln(1) o stand/44425 standards getcwd() succeeds even if current dir has perm 000. o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/54833 standards [pcvt] more pcvt deficits o stand/54839 standards [pcvt] pcvt deficits p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/56476 standards cd9660 unicode support simple hack o stand/58676 standards grantpt(3) alters storage used by ptsname(3) s stand/62858 standards malloc(0) not C99 compliant s kern/64875 standards [libc] [patch] [feature request] add a system call: fd o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- o stand/66531 standards _gettemp uses a far smaller set of filenames than docu o stand/70813 standards [PATCH] ls(1) not Posix compliant o stand/72006 standards floating point formating in non-C locales o stand/79056 standards regex(3) regression tests a stand/80293 standards sysconf() does not support well-defined unistd values o stand/81287 standards [PATCH]: fingerd(8) might send a line not ending in CR o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/85080 standards output of long double subnormals (with printf) is wron o stand/92360 standards [headers] [patch] Missing TAB3 in kernel headers o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/96016 standards [headers] clock_getres et al should be in o stand/96236 standards [PATCH] [POSIX] sed.1 incorrectly describes a function p stand/99517 standards Missing SIGRTMIN and SIGRTMAX signals o stand/99960 standards [Patch] make(1): Add -p flag o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/104841 standards [libm] [patch] C99 long double square root. o stand/107561 standards [patch] Missing SUS function tcgetsid() o kern/114578 standards [libc] wide character printing using swprintf(dst, n, o stand/114633 standards /etc/rc.subr: line 511: omits a quotation mark: "force o stand/116081 standards make does not work with the directive sinclude o stand/116221 standards SUS issue -- FreeBSD has not flag WNOWAIT for wait*() o stand/116826 standards [PATCH] sh support for POSIX character classes o stand/118047 standards SUGGESTION: /etc/printcap vs mergemaster 41 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon Dec 3 11:22:45 2007 Return-Path: Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA78816A469; Mon, 3 Dec 2007 11:22:45 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id 5ACEE13C442; Mon, 3 Dec 2007 11:22:45 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lB3BMepI020253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2007 22:22:42 +1100 Date: Mon, 3 Dec 2007 22:22:40 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David Schultz In-Reply-To: <20071203074407.GA10989@VARK.MIT.EDU> Message-ID: <20071203214940.A1141@delplex.bde.org> References: <20070928152227.GA39233@troutmask.apl.washington.edu> <20071001173736.U1985@besplex.bde.org> <20071002001154.GA3782@troutmask.apl.washington.edu> <20071002172317.GA95181@VARK.MIT.EDU> <20071002173237.GA12586@troutmask.apl.washington.edu> <20071003103519.X14175@delplex.bde.org> <20071010204249.GA7446@troutmask.apl.washington.edu> <20071203074407.GA10989@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-standards@FreeBSD.ORG, Steve Kargl Subject: Re: long double broken on i386? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2007 11:22:45 -0000 On Mon, 3 Dec 2007, David Schultz wrote: > Is the latest version of the patch the one you sent to the list? > If cosl and friends produce accurate answers within a reasonable > domain, it's worth committing; the whole business about how > accurate cosl(1000000000) is can be dealt with later. Well, it doesn't work for: i386 (long double is broken in general) pc98 (like i386) sparc64 (long double is longer) sun4v (like sparc64), and is irrelevant for: alpha (long double = double, and alpha = unsupported) arm (long double = double) amd64 (should use trivial assembler code until plain cos and friends on i386 are more accurate than the hardware) i386 (like amd64, except not using the hardware would be sillier) pc98 (like i386) powerpc (long double = double) so its relevance is limited to: ia64 (long doubles have same precision as on i386, but cos and friends are not in hardware so trivial assembler code cannot be used). Bruce From owner-freebsd-standards@FreeBSD.ORG Mon Dec 3 14:54:35 2007 Return-Path: Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8CD716A511 for ; Mon, 3 Dec 2007 14:54:35 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 88B0413C46E for ; Mon, 3 Dec 2007 14:54:35 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.14.1) with ESMTP id lB3Ep5TG016347; Mon, 3 Dec 2007 06:51:05 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.14.1/Submit) id lB3Ep583016346; Mon, 3 Dec 2007 06:51:05 -0800 (PST) (envelope-from sgk) Date: Mon, 3 Dec 2007 06:51:05 -0800 From: Steve Kargl To: Bruce Evans , freebsd-standards@FreeBSD.ORG Message-ID: <20071203145105.GA16203@troutmask.apl.washington.edu> References: <20070928152227.GA39233@troutmask.apl.washington.edu> <20071001173736.U1985@besplex.bde.org> <20071002001154.GA3782@troutmask.apl.washington.edu> <20071002172317.GA95181@VARK.MIT.EDU> <20071002173237.GA12586@troutmask.apl.washington.edu> <20071003103519.X14175@delplex.bde.org> <20071010204249.GA7446@troutmask.apl.washington.edu> <20071203074407.GA10989@VARK.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071203074407.GA10989@VARK.MIT.EDU> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: long double broken on i386? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2007 14:54:35 -0000 On Mon, Dec 03, 2007 at 02:44:08AM -0500, David Schultz wrote: > Is the latest version of the patch the one you sent to the list? > If cosl and friends produce accurate answers within a reasonable > domain, it's worth committing; the whole business about how > accurate cosl(1000000000) is can be dealt with later. No, I've rewritten most of the code (numerous times in fact :-). First, I followed Bruce's recommendation to compute the ULP in the higher precision available in GMP/MPFR instead of the long double type. The old method appears to have been using a chop rounding because I would get only 0.5, 1.0, 1.5, ... ULPs (ie, I never saw anything like 0.6312 ULP). With the new method, I see ULPs in the 0.6 to 0.75 range. I haven't had time to implement a full blown Remes algorithm to see if I can reduce the ULP. Second, I've implemented the algorithms found in s_cos.c, s_sin.c, and s_tan.c that use the extra precision from the argument reduction. If I use these algorithms, then the ULPs go up! For example, the ULP for sinl() goes up to about 1.5. Bruce had suggested that the 396 hex digits in the table for 2/pi may need to be checked. I found a paper by K.C. Ng at David Hough's website that (if I read it correctly) suggests that we need a much larger table. So, I need to check how well argument reduction is working. -- Steve From owner-freebsd-standards@FreeBSD.ORG Mon Dec 3 17:11:48 2007 Return-Path: Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4570816A419 for ; Mon, 3 Dec 2007 17:11:48 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.freebsd.org (Postfix) with ESMTP id 0C59913C46B for ; Mon, 3 Dec 2007 17:11:47 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.14.2/8.14.1) with ESMTP id lB3HBfgu013426; Mon, 3 Dec 2007 12:11:41 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.14.2/8.14.1/Submit) id lB3HBe1e013425; Mon, 3 Dec 2007 12:11:40 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Mon, 3 Dec 2007 12:11:40 -0500 From: David Schultz To: Bruce Evans Message-ID: <20071203171140.GA13355@VARK.MIT.EDU> Mail-Followup-To: Bruce Evans , Steve Kargl , freebsd-standards@FreeBSD.ORG References: <20070928152227.GA39233@troutmask.apl.washington.edu> <20071001173736.U1985@besplex.bde.org> <20071002001154.GA3782@troutmask.apl.washington.edu> <20071002172317.GA95181@VARK.MIT.EDU> <20071002173237.GA12586@troutmask.apl.washington.edu> <20071003103519.X14175@delplex.bde.org> <20071010204249.GA7446@troutmask.apl.washington.edu> <20071203074407.GA10989@VARK.MIT.EDU> <20071203214940.A1141@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071203214940.A1141@delplex.bde.org> Cc: freebsd-standards@FreeBSD.ORG, Steve Kargl Subject: Re: long double broken on i386? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2007 17:11:48 -0000 On Mon, Dec 03, 2007, Bruce Evans wrote: > On Mon, 3 Dec 2007, David Schultz wrote: > > >Is the latest version of the patch the one you sent to the list? > >If cosl and friends produce accurate answers within a reasonable > >domain, it's worth committing; the whole business about how > >accurate cosl(1000000000) is can be dealt with later. > > Well, it doesn't work for: > i386 (long double is broken in general) > pc98 (like i386) > sparc64 (long double is longer) > sun4v (like sparc64), > and is irrelevant for: > alpha (long double = double, and alpha = unsupported) > arm (long double = double) > amd64 (should use trivial assembler code until plain cos and friends > on i386 are more accurate than the hardware) > i386 (like amd64, except not using the hardware would be sillier) > pc98 (like i386) > powerpc (long double = double) > so its relevance is limited to: > ia64 (long doubles have same precision as on i386, but cos and friends > are not in hardware so trivial assembler code cannot be used). Okay, but realistically, the only one of these complaints that's an impediment to committing the code is the lack of 128-bit long double support for sparc64. From owner-freebsd-standards@FreeBSD.ORG Tue Dec 4 19:02:22 2007 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E11AB16A418 for ; Tue, 4 Dec 2007 19:02:22 +0000 (UTC) (envelope-from matthieu@nxdomain.fr) Received: from homer.epita.info (alice.nxdomain.fr [213.251.160.11]) by mx1.freebsd.org (Postfix) with ESMTP id AD7B013C447 for ; Tue, 4 Dec 2007 19:02:22 +0000 (UTC) (envelope-from matthieu@nxdomain.fr) Received: from [172.16.31.6] (unknown [172.16.31.6]) by homer.epita.info (Postfix) with ESMTP id C60CA78C3C for ; Tue, 4 Dec 2007 19:44:08 +0100 (CET) Message-ID: <47559FF0.5090008@nxdomain.fr> Date: Tue, 04 Dec 2007 19:44:00 +0100 From: Matthieu Michaud User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: standards@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: make struct timeval posix compliant ? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2007 19:02:23 -0000 Hi, Few months ago I sent a mail to stable@freebsd.org in the hope to discuss struct timeval posix conformance in RELENG_6. http://docs.freebsd.org/cgi/mid.cgi?1397BA88-CC55-4585-86CB-3BD08FBABEF5 Given the few answers, I may have targetted the wrong mailing list or this change has no interest. So, here are the questions again : - Do you want FreeBSD 6 to conform posix specs for struct timeval ? (it's not always a right thing to do to strictly conform standards) - Is it ok to do it ? (if i'm correct there is a minor abi change and this could be a strong reason to stay as is) Best regards. -- Matthieu Michaud From owner-freebsd-standards@FreeBSD.ORG Tue Dec 4 20:10:56 2007 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9777A16A41A for ; Tue, 4 Dec 2007 20:10:56 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 19C9B13C43E for ; Tue, 4 Dec 2007 20:10:55 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.1/8.13.8) with ESMTP id lB4KAs38043174; Tue, 4 Dec 2007 14:10:54 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.1/8.13.8/Submit) id lB4KArD5043173; Tue, 4 Dec 2007 14:10:53 -0600 (CST) (envelope-from brooks) Date: Tue, 4 Dec 2007 14:10:53 -0600 From: Brooks Davis To: Matthieu Michaud Message-ID: <20071204201053.GA41843@lor.one-eyed-alien.net> References: <47559FF0.5090008@nxdomain.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline In-Reply-To: <47559FF0.5090008@nxdomain.fr> User-Agent: Mutt/1.5.16 (2007-06-09) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 04 Dec 2007 14:10:55 -0600 (CST) Cc: standards@freebsd.org Subject: Re: make struct timeval posix compliant ? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2007 20:10:56 -0000 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 04, 2007 at 07:44:00PM +0100, Matthieu Michaud wrote: > Hi, >=20 > Few months ago I sent a mail to stable@freebsd.org in the hope to discuss= =20 > struct timeval posix conformance in RELENG_6. >=20 > http://docs.freebsd.org/cgi/mid.cgi?1397BA88-CC55-4585-86CB-3BD08FBABEF5 >=20 > Given the few answers, I may have targetted the wrong mailing list or thi= s=20 > change has no interest. So, here are the questions again : >=20 > - Do you want FreeBSD 6 to conform posix specs for struct timeval ? (it's= =20 > not always a right thing to do to strictly conform standards) >=20 > - Is it ok to do it ? (if i'm correct there is a minor abi change and thi= s=20 > could be a strong reason to stay as is) With 7.0 about to be released and is fixed, I can't say I see much value compared to the potential disruption in the 6.x series (the fact that the patch corrects some printf statements demonstrates that there will be disruption). Is there something we'd get other than conformance? -- Brooks --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHVbRMXY6L6fI4GtQRAjEVAKCLAm8WE9Rh9V2dfyBk9CjFaPQLuQCfXZqv z/MsFyfN9T506SB+FusxiKk= =MmE6 -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From owner-freebsd-standards@FreeBSD.ORG Wed Dec 5 02:34:25 2007 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0EC116A417 for ; Wed, 5 Dec 2007 02:34:25 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 4604013C43E for ; Wed, 5 Dec 2007 02:34:24 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lB52YKLR009550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 13:34:22 +1100 Date: Wed, 5 Dec 2007 13:34:20 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Matthieu Michaud In-Reply-To: <47559FF0.5090008@nxdomain.fr> Message-ID: <20071205132138.J6892@delplex.bde.org> References: <47559FF0.5090008@nxdomain.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: standards@freebsd.org Subject: Re: make struct timeval posix compliant ? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2007 02:34:25 -0000 On Tue, 4 Dec 2007, Matthieu Michaud wrote: > Few months ago I sent a mail to stable@freebsd.org in the hope to discuss > struct timeval posix conformance in RELENG_6. > > http://docs.freebsd.org/cgi/mid.cgi?1397BA88-CC55-4585-86CB-3BD08FBABEF5 > > Given the few answers, I may have targetted the wrong mailing list or this > change has no interest. So, here are the questions again : > > - Do you want FreeBSD 6 to conform posix specs for struct timeval ? (it's not > always a right thing to do to strictly conform standards) No, but I don't use FreeBSD-6. > - Is it ok to do it ? (if i'm correct there is a minor abi change and this > could be a strong reason to stay as is) It is a huge ABI breakage for arches with 64-bit longs and 32-bit time_t's (these seem to be only alpha, and i386 and powerpc with the not-really-supported correctly-sized longs). These could be ifdefed like arm already is (ugh). It is a minor API breakage/fix. Bruce From owner-freebsd-standards@FreeBSD.ORG Wed Dec 5 18:51:46 2007 Return-Path: Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28C0516A418 for ; Wed, 5 Dec 2007 18:51:46 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.freebsd.org (Postfix) with ESMTP id DC6BB13C4FF for ; Wed, 5 Dec 2007 18:51:45 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.14.2/8.14.1) with ESMTP id lB5IpWxl091788; Wed, 5 Dec 2007 13:51:32 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.14.2/8.14.1/Submit) id lB5IpWaq091787; Wed, 5 Dec 2007 13:51:32 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Wed, 5 Dec 2007 13:51:32 -0500 From: David Schultz To: Steve Kargl Message-ID: <20071205185132.GA91591@VARK.MIT.EDU> Mail-Followup-To: Steve Kargl , Bruce Evans , freebsd-standards@FreeBSD.ORG References: <20070928152227.GA39233@troutmask.apl.washington.edu> <20071001173736.U1985@besplex.bde.org> <20071002001154.GA3782@troutmask.apl.washington.edu> <20071002172317.GA95181@VARK.MIT.EDU> <20071002173237.GA12586@troutmask.apl.washington.edu> <20071003103519.X14175@delplex.bde.org> <20071010204249.GA7446@troutmask.apl.washington.edu> <20071203074407.GA10989@VARK.MIT.EDU> <20071203145105.GA16203@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071203145105.GA16203@troutmask.apl.washington.edu> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: long double broken on i386? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2007 18:51:46 -0000 On Mon, Dec 03, 2007, Steve Kargl wrote: > On Mon, Dec 03, 2007 at 02:44:08AM -0500, David Schultz wrote: > > Is the latest version of the patch the one you sent to the list? > > If cosl and friends produce accurate answers within a reasonable > > domain, it's worth committing; the whole business about how > > accurate cosl(1000000000) is can be dealt with later. > > No, I've rewritten most of the code (numerous times in fact :-). > > First, I followed Bruce's recommendation to compute the > ULP in the higher precision available in GMP/MPFR instead > of the long double type. The old method appears to > have been using a chop rounding because I would get > only 0.5, 1.0, 1.5, ... ULPs (ie, I never saw anything like > 0.6312 ULP). With the new method, I see ULPs in the 0.6 > to 0.75 range. I haven't had time to implement a full > blown Remes algorithm to see if I can reduce the ULP. > > Second, I've implemented the algorithms found in > s_cos.c, s_sin.c, and s_tan.c that use the extra > precision from the argument reduction. If I use > these algorithms, then the ULPs go up! For example, > the ULP for sinl() goes up to about 1.5. Bruce > had suggested that the 396 hex digits in the table > for 2/pi may need to be checked. I found a paper > by K.C. Ng at David Hough's website that (if I read it > correctly) suggests that we need a much larger > table. So, I need to check how well argument reduction > is working. Having a version that works for machines with the 128-bit floating point format is pretty important. (These would probably be two separate files; I've been thinking we should add a msun/ieee96 directory and a msun/ieee128 directory or something.) But honestly, I've tried to wrestle with the argument reduction stuff before, and my advice is to not kill yourself over it. You need tons of extra precision and an entirely different computation for huge numbers, and there are other things you could spend your time on that would have a bigger impact. If someone tries to compute cosl(10^20 * pi/3) using libm, for example, they're going to get the wrong answer anyway. When 10^20 * pi/3 is expressed in extended precision, the rounding error is more than pi, so it doesn't matter how accurately you compute the cosine because the input is totally out of phase. While it might be nice to say that we have accurate argument reduction and blah blah blah, but it's of little practical value. That's not to say that we need no argument reduction at all. For instance, cosl(5*pi/3) should still give an accurate answer. But when the input is so huge that the exponent is bigger than the number of significant bits in the mantissa, you lose so much precision in the input that it's not as important anymore. That's probably why Intel decided to make its trig instructions only work up to 2^63 before requiring explicit argument reduction. From owner-freebsd-standards@FreeBSD.ORG Wed Dec 5 20:36:26 2007 Return-Path: Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4444916A419 for ; Wed, 5 Dec 2007 20:36:26 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 1B76713C465 for ; Wed, 5 Dec 2007 20:36:26 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.14.1) with ESMTP id lB5KWZRK044448; Wed, 5 Dec 2007 12:32:35 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.14.1/Submit) id lB5KWZ08044447; Wed, 5 Dec 2007 12:32:35 -0800 (PST) (envelope-from sgk) Date: Wed, 5 Dec 2007 12:32:35 -0800 From: Steve Kargl To: Bruce Evans , freebsd-standards@FreeBSD.ORG Message-ID: <20071205203235.GA40539@troutmask.apl.washington.edu> References: <20070928152227.GA39233@troutmask.apl.washington.edu> <20071001173736.U1985@besplex.bde.org> <20071002001154.GA3782@troutmask.apl.washington.edu> <20071002172317.GA95181@VARK.MIT.EDU> <20071002173237.GA12586@troutmask.apl.washington.edu> <20071003103519.X14175@delplex.bde.org> <20071010204249.GA7446@troutmask.apl.washington.edu> <20071203074407.GA10989@VARK.MIT.EDU> <20071203145105.GA16203@troutmask.apl.washington.edu> <20071205185132.GA91591@VARK.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071205185132.GA91591@VARK.MIT.EDU> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: long double broken on i386? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2007 20:36:26 -0000 On Wed, Dec 05, 2007 at 01:51:32PM -0500, David Schultz wrote: > On Mon, Dec 03, 2007, Steve Kargl wrote: > > On Mon, Dec 03, 2007 at 02:44:08AM -0500, David Schultz wrote: > > > Is the latest version of the patch the one you sent to the list? > > > If cosl and friends produce accurate answers within a reasonable > > > domain, it's worth committing; the whole business about how > > > accurate cosl(1000000000) is can be dealt with later. > > > > No, I've rewritten most of the code (numerous times in fact :-). > > > > First, I followed Bruce's recommendation to compute the > > ULP in the higher precision available in GMP/MPFR instead > > of the long double type. The old method appears to > > have been using a chop rounding because I would get > > only 0.5, 1.0, 1.5, ... ULPs (ie, I never saw anything like > > 0.6312 ULP). With the new method, I see ULPs in the 0.6 > > to 0.75 range. I haven't had time to implement a full > > blown Remes algorithm to see if I can reduce the ULP. > > > > Second, I've implemented the algorithms found in > > s_cos.c, s_sin.c, and s_tan.c that use the extra > > precision from the argument reduction. If I use > > these algorithms, then the ULPs go up! For example, > > the ULP for sinl() goes up to about 1.5. Bruce > > had suggested that the 396 hex digits in the table > > for 2/pi may need to be checked. I found a paper > > by K.C. Ng at David Hough's website that (if I read it > > correctly) suggests that we need a much larger > > table. So, I need to check how well argument reduction > > is working. > > Having a version that works for machines with the 128-bit floating > point format is pretty important. (These would probably be two > separate files; I've been thinking we should add a msun/ieee96 > directory and a msun/ieee128 directory or something.) This is probably a good idea if freebsd wants to maintain the same algorithm across, say, sinf, sin, and sinl. I can produce code for the ieee128 case, but I have no way to test it. An alternative may be to use table-driven implementations where the intervals are defined by exactly representable values in ieee96 (i.e., 64-bit significand), which are then also exactly representable in ieee128. I haven't investigated how many intervals one would need nor the best interpolation scheme. > But honestly, I've tried to wrestle with the argument reduction > stuff before, and my advice is to not kill yourself over it. (large arg discussion elided) > That's not to say that we need no argument reduction at all. For > instance, cosl(5*pi/3) should still give an accurate answer. But > when the input is so huge that the exponent is bigger than the > number of significant bits in the mantissa, you lose so much > precision in the input that it's not as important anymore. That's > probably why Intel decided to make its trig instructions only work > up to 2^63 before requiring explicit argument reduction. This is what I need to check. For reasonable args, does the arg reduction provide extra precision and is it useful? It seems that you may have already checked this. I hope to revisit some of this on Saturday. -- Steve From owner-freebsd-standards@FreeBSD.ORG Thu Dec 6 00:12:04 2007 Return-Path: Delivered-To: standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44EA316A419 for ; Thu, 6 Dec 2007 00:12:04 +0000 (UTC) (envelope-from matthieu@nxdomain.fr) Received: from homer.epita.info (alice.nxdomain.fr [213.251.160.11]) by mx1.freebsd.org (Postfix) with ESMTP id 112DE13C455 for ; Thu, 6 Dec 2007 00:12:03 +0000 (UTC) (envelope-from matthieu@nxdomain.fr) Received: from [172.16.31.6] (unknown [172.16.31.6]) by homer.epita.info (Postfix) with ESMTP id 3006578D04; Thu, 6 Dec 2007 01:12:02 +0100 (CET) Message-ID: <47573E4F.9070403@nxdomain.fr> Date: Thu, 06 Dec 2007 01:11:59 +0100 From: Matthieu Michaud User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Bruce Evans References: <47559FF0.5090008@nxdomain.fr> <20071205132138.J6892@delplex.bde.org> In-Reply-To: <20071205132138.J6892@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: standards@freebsd.org Subject: Re: make struct timeval posix compliant ? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2007 00:12:04 -0000 Bruce Evans wrote: > On Tue, 4 Dec 2007, Matthieu Michaud wrote: > >> Few months ago I sent a mail to stable@freebsd.org in the hope to >> discuss struct timeval posix conformance in RELENG_6. >> >> http://docs.freebsd.org/cgi/mid.cgi?1397BA88-CC55-4585-86CB-3BD08FBABEF5 >> >> Given the few answers, I may have targetted the wrong mailing list or >> this change has no interest. So, here are the questions again : >> >> - Do you want FreeBSD 6 to conform posix specs for struct timeval ? >> (it's not always a right thing to do to strictly conform standards) > > No, but I don't use FreeBSD-6. > >> - Is it ok to do it ? (if i'm correct there is a minor abi change and >> this could be a strong reason to stay as is) > > It is a huge ABI breakage for arches with 64-bit longs and 32-bit > time_t's (these seem to be only alpha, and i386 and powerpc with the > not-really-supported correctly-sized longs). These could be ifdefed > like arm already is (ugh). > > It is a minor API breakage/fix. > > Bruce This is a little portability issue. I noticed it while working on an app targetting both 6 and 7. I wasn't 100% sure of the consequences. I now am and you're right : this is a minor API fix and a big API break. This is no game to play and I'll live with it. Thanks for your answer. From owner-freebsd-standards@FreeBSD.ORG Thu Dec 6 03:35:40 2007 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85B1416A418; Thu, 6 Dec 2007 03:35:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 1D7D613C457; Thu, 6 Dec 2007 03:35:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lB63ZZvc021773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2007 14:35:37 +1100 Date: Thu, 6 Dec 2007 14:35:35 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David Schultz In-Reply-To: <20071205185132.GA91591@VARK.MIT.EDU> Message-ID: <20071206141035.V10327@delplex.bde.org> References: <20070928152227.GA39233@troutmask.apl.washington.edu> <20071001173736.U1985@besplex.bde.org> <20071002001154.GA3782@troutmask.apl.washington.edu> <20071002172317.GA95181@VARK.MIT.EDU> <20071002173237.GA12586@troutmask.apl.washington.edu> <20071003103519.X14175@delplex.bde.org> <20071010204249.GA7446@troutmask.apl.washington.edu> <20071203074407.GA10989@VARK.MIT.EDU> <20071203145105.GA16203@troutmask.apl.washington.edu> <20071205185132.GA91591@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-standards@freebsd.org, Steve Kargl Subject: Re: long double broken on i386? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2007 03:35:40 -0000 On Wed, 5 Dec 2007, David Schultz wrote: > But honestly, I've tried to wrestle with the argument reduction > stuff before, and my advice is to not kill yourself over it. You > need tons of extra precision and an entirely different computation > for huge numbers, and there are other things you could spend your > time on that would have a bigger impact. The work for this is mostly already done. The new work is just to ensure correctness of data fed into and read out of a hopefully debugged algorithm. That must be done anyway. > If someone tries to > compute cosl(10^20 * pi/3) using libm, for example, they're going > to get the wrong answer anyway. When 10^20 * pi/3 is expressed in Why would anyone do that? :-) > extended precision, the rounding error is more than pi, so it > doesn't matter how accurately you compute the cosine because the > input is totally out of phase. While it might be nice to say that > we have accurate argument reduction and blah blah blah, but it's > of little practical value. The Intel ia64 library and IIRC, LIA, has functions which take an arg in degrees (cosd(), etc?) so that arg reduction is simpler and even huge integer args (in degrees) can be handled perfectly. It's strange that degrees can work better than radians. With only functions that take args in radians, the loss of precison goes the other way, with naive user code doing cosd(x) := cos(x * pi / 180) and losing a lot of accuracy even for x = 360. > That's not to say that we need no argument reduction at all. For > instance, cosl(5*pi/3) should still give an accurate answer. But > when the input is so huge that the exponent is bigger than the > number of significant bits in the mantissa, you lose so much > precision in the input that it's not as important anymore. That's > probably why Intel decided to make its trig instructions only work > up to 2^63 before requiring explicit argument reduction. They don't actually work up to 2^63. They work up to about 2^2 or 2^4 for extended precision and up to about 2^13 or 2^15 for double precision, since their internal approximation to pi only has 66 or 68 bits (ucbtest says 66(->68) bits; fdlibm has 3168 bits). When Intel decided this for i87's, they only had a budget of 25000 (?) gates and a few hundred million dollars (?). Their budget is larger now :-), but for ia64 they do it all in software (like fdlibm does I think, but much more MD and optimized, especially for arg reduction). Thus the old bugs of a bad internal approximation for pi and a broken indicator for when better arg reduction is needed are fixed on ia64. Bruce From owner-freebsd-standards@FreeBSD.ORG Thu Dec 6 05:15:53 2007 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62C5A16A420 for ; Thu, 6 Dec 2007 05:15:53 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 338F113C46E for ; Thu, 6 Dec 2007 05:15:50 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lB65FZWE024277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2007 16:15:42 +1100 Date: Thu, 6 Dec 2007 16:15:35 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Steve Kargl In-Reply-To: <20071205203235.GA40539@troutmask.apl.washington.edu> Message-ID: <20071206151017.U10456@delplex.bde.org> References: <20070928152227.GA39233@troutmask.apl.washington.edu> <20071001173736.U1985@besplex.bde.org> <20071002001154.GA3782@troutmask.apl.washington.edu> <20071002172317.GA95181@VARK.MIT.EDU> <20071002173237.GA12586@troutmask.apl.washington.edu> <20071003103519.X14175@delplex.bde.org> <20071010204249.GA7446@troutmask.apl.washington.edu> <20071203074407.GA10989@VARK.MIT.EDU> <20071203145105.GA16203@troutmask.apl.washington.edu> <20071205185132.GA91591@VARK.MIT.EDU> <20071205203235.GA40539@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-standards@freebsd.org Subject: Re: long double broken on i386? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2007 05:15:53 -0000 On Wed, 5 Dec 2007, Steve Kargl wrote: > On Wed, Dec 05, 2007 at 01:51:32PM -0500, David Schultz wrote: >> Having a version that works for machines with the 128-bit floating >> point format is pretty important. (These would probably be two >> separate files; I've been thinking we should add a msun/ieee96 >> directory and a msun/ieee128 directory or something.) > > This is probably a good idea if freebsd wants to maintain the > same algorithm across, say, sinf, sin, and sinl. I can produce > code for the ieee128 case, but I have no way to test it. I guarantee that it will have bugs if it is not tested :-). > An alternative may be to use table-driven implementations where > the intervals are defined by exactly representable values in ieee96 > (i.e., 64-bit significand), which are then also exactly representable > in ieee128. I haven't investigated how many intervals one would > need nor the best interpolation scheme. My best implementation of logl does this to a large extent (see your mailbox). It uses an variable interval length of ~1/128 and rounds the endpoints to float precision (endpoints are round(1 + i/128)). Full precision is still needed for the values at the endpoints, but the full-precision values are represented as sums of lower-precision values to optimize for amd64 and i386. This won't work so well for sparc64. The interval length of 1/128 gives a rounding error for the polynomial of about (1/128)^2 53-bit ULPs = 2^-14 53-bit ULPs = 2^-3 64-bit ULPs, (due to the coeff of the x^2 term possibly having a 1 53-bit ULP rounding error), and the Remez approximation method reduces this to about 2^-11 64-bit ULPs, with 113-bit precision and 53-bit coeffs the interval length needs to be more like sqrt(2^(53-113)) = 2^-30 which is too small to implement. Hopefully Remez helps even more here. The trig family (especially cos) doesn't need such a small interval as log(), since its power series converge faster and have every second term 0 and thus exactly representable. You don't want to do this initially for the trig family since it adds complexity. The Intel ia64 library uses intervals for almost everything, including the trig family. Splicing at the endpoints and relating the endpoints to multiples of pi/2 makes it more complicated for the trig family than for the (real) log family. Bruce From owner-freebsd-standards@FreeBSD.ORG Thu Dec 6 09:08:49 2007 Return-Path: Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C21B16A417 for ; Thu, 6 Dec 2007 09:08:49 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.freebsd.org (Postfix) with ESMTP id 1F5C413C45B for ; Thu, 6 Dec 2007 09:08:48 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.14.2/8.14.1) with ESMTP id lB698YuB095678; Thu, 6 Dec 2007 04:08:34 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.14.2/8.14.1/Submit) id lB698XrJ095677; Thu, 6 Dec 2007 04:08:34 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 6 Dec 2007 04:08:33 -0500 From: David Schultz To: Steve Kargl Message-ID: <20071206090833.GA95428@VARK.MIT.EDU> Mail-Followup-To: Steve Kargl , freebsd-standards@FreeBSD.ORG References: <20071012180959.GA36345@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071012180959.GA36345@troutmask.apl.washington.edu> Cc: freebsd-standards@FreeBSD.ORG Subject: Re: [PATCH] hypotl, cabsl, and code removal in cabs X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2007 09:08:49 -0000 I like the approach. One concern, though, is that IEEE 754 requires sqrt to always be correctly rounded, and one might reasonably expect the same from hypot. If we believe that, then the intermediate quantity a*a + b*b needs to be computed exactly; if it is rounded before we take the square root, the double rounding may cause us to round the wrong way. This basically requires computing things with twice as many bits of precision. Arguably, though, your code is correct in the most important ways (avoiding underflow/overflow). Also, umm, I've been busy and unable to pay attention for a while, so forgive me if I'm missing something, but isn't it the case that we don't have a sqrtl(), except for the gcc builtin on some architectures? From owner-freebsd-standards@FreeBSD.ORG Thu Dec 6 21:08:13 2007 Return-Path: Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D15B16A417 for ; Thu, 6 Dec 2007 21:08:13 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.freebsd.org (Postfix) with ESMTP id AC7D913C455 for ; Thu, 6 Dec 2007 21:08:12 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.14.2/8.14.1) with ESMTP id lB6L7twF098239; Thu, 6 Dec 2007 16:07:55 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.14.2/8.14.1/Submit) id lB6L7tZw098238; Thu, 6 Dec 2007 16:07:55 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 6 Dec 2007 16:07:55 -0500 From: David Schultz To: Bruce Evans Message-ID: <20071206210755.GA98191@VARK.MIT.EDU> Mail-Followup-To: Bruce Evans , Steve Kargl , freebsd-standards@FreeBSD.ORG References: <20071002001154.GA3782@troutmask.apl.washington.edu> <20071002172317.GA95181@VARK.MIT.EDU> <20071002173237.GA12586@troutmask.apl.washington.edu> <20071003103519.X14175@delplex.bde.org> <20071010204249.GA7446@troutmask.apl.washington.edu> <20071203074407.GA10989@VARK.MIT.EDU> <20071203145105.GA16203@troutmask.apl.washington.edu> <20071205185132.GA91591@VARK.MIT.EDU> <20071205203235.GA40539@troutmask.apl.washington.edu> <20071206151017.U10456@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071206151017.U10456@delplex.bde.org> Cc: freebsd-standards@FreeBSD.ORG, Steve Kargl Subject: Re: long double broken on i386? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2007 21:08:13 -0000 On Thu, Dec 06, 2007, Bruce Evans wrote: > On Wed, 5 Dec 2007, Steve Kargl wrote: > > >On Wed, Dec 05, 2007 at 01:51:32PM -0500, David Schultz wrote: > > >>Having a version that works for machines with the 128-bit floating > >>point format is pretty important. (These would probably be two > >>separate files; I've been thinking we should add a msun/ieee96 > >>directory and a msun/ieee128 directory or something.) > > > >This is probably a good idea if freebsd wants to maintain the > >same algorithm across, say, sinf, sin, and sinl. I can produce > >code for the ieee128 case, but I have no way to test it. > > I guarantee that it will have bugs if it is not tested :-). Panther is down, so neither do I unless there's another sparc64 machine in the cluster. I will ask about getting Steve access if that seems helpful. > >An alternative may be to use table-driven implementations where > >the intervals are defined by exactly representable values in ieee96 > >(i.e., 64-bit significand), which are then also exactly representable > >in ieee128. I haven't investigated how many intervals one would > >need nor the best interpolation scheme. > > My best implementation of logl does this to a large extent (see your > mailbox). It uses an variable interval length of ~1/128 and rounds the > endpoints to float precision (endpoints are round(1 + i/128)). Full > precision is still needed for the values at the endpoints, but the > full-precision values are represented as sums of lower-precision > values to optimize for amd64 and i386. Yeah, I need to page all of that material back into my brain at some point. The trouble is I have a gazillion emails, but I don't have a gazillion minutes of time with which to think about them and do something about all of them right now. From owner-freebsd-standards@FreeBSD.ORG Thu Dec 6 23:15:44 2007 Return-Path: Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AE6E16A419 for ; Thu, 6 Dec 2007 23:15:44 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 07E8313C442 for ; Thu, 6 Dec 2007 23:15:44 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.1/8.14.1) with ESMTP id lB6NBhpP064497 for ; Thu, 6 Dec 2007 15:11:43 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.1/8.14.1/Submit) id lB6NBh9I064496 for freebsd-standards@FreeBSD.ORG; Thu, 6 Dec 2007 15:11:43 -0800 (PST) (envelope-from sgk) Date: Thu, 6 Dec 2007 15:11:43 -0800 From: Steve Kargl To: freebsd-standards@FreeBSD.ORG Message-ID: <20071206231143.GA63969@troutmask.apl.washington.edu> References: <20071012180959.GA36345@troutmask.apl.washington.edu> <20071206090833.GA95428@VARK.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071206090833.GA95428@VARK.MIT.EDU> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: [PATCH] hypotl, cabsl, and code removal in cabs X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2007 23:15:44 -0000 On Thu, Dec 06, 2007 at 04:08:33AM -0500, David Schultz wrote: > I like the approach. One concern, though, is that IEEE 754 > requires sqrt to always be correctly rounded, and one might > reasonably expect the same from hypot. If we believe that, then > the intermediate quantity a*a + b*b needs to be computed exactly; > if it is rounded before we take the square root, the double > rounding may cause us to round the wrong way. This basically > requires computing things with twice as many bits of precision. > Arguably, though, your code is correct in the most important > ways (avoiding underflow/overflow). > > Also, umm, I've been busy and unable to pay attention for a while, > so forgive me if I'm missing something, but isn't it the case that > we don't have a sqrtl(), except for the gcc builtin on some > architectures? David, bde pointed me to the right file in src/libm/ieee that explains the rounding issues with hypotl. I haven't had a chance to update my implementation to use extra care in the evaluation of a*a+b*b. As to the sqrtl question, I have an implementation that supposely does correct rounding in all rounding modes. It is restricted to 64-bit significand long doubles. The code does not use bit twiddle; instead, it uses fenv. -- Steve From owner-freebsd-standards@FreeBSD.ORG Fri Dec 7 06:58:46 2007 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69A7216A420 for ; Fri, 7 Dec 2007 06:58:46 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id 0A1DD13C442 for ; Fri, 7 Dec 2007 06:58:45 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lB76wdAQ031723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Dec 2007 17:58:44 +1100 Date: Fri, 7 Dec 2007 17:58:39 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Steve Kargl In-Reply-To: <20071206231143.GA63969@troutmask.apl.washington.edu> Message-ID: <20071207173222.D702@delplex.bde.org> References: <20071012180959.GA36345@troutmask.apl.washington.edu> <20071206090833.GA95428@VARK.MIT.EDU> <20071206231143.GA63969@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-standards@freebsd.org Subject: Re: [PATCH] hypotl, cabsl, and code removal in cabs X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2007 06:58:46 -0000 On Thu, 6 Dec 2007, Steve Kargl wrote: > On Thu, Dec 06, 2007 at 04:08:33AM -0500, David Schultz wrote: >> Also, umm, I've been busy and unable to pay attention for a while, >> so forgive me if I'm missing something, but isn't it the case that >> we don't have a sqrtl(), except for the gcc builtin on some >> architectures? > > bde pointed me to the right file in src/libm/ieee that explains > the rounding issues with hypotl. I haven't had a chance to > update my implementation to use extra care in the evaluation of > a*a+b*b. I fixed it in your mailbox for the float precision case. (It is useful to test algorithms for the float precision case, since only that case can be tested resonably exhaustively (not actually exhaustively for 2-arg functions like hypotf()). But after a lot of work, the debugged version reduces to almost the fdlibm version except for different style bugs.) > As to the sqrtl question, I have an implementation that supposely > does correct rounding in all rounding modes. It is restricted to > 64-bit significand long doubles. The code does not use bit twiddle; > instead, it uses fenv. This I haven't looked at closely. I fear extreme slowness. On athlon-xp, fenv accesses take a about 100 cycles each (129 for fldenv and 89 for fstenv; thus > 200 for fldenv+fstenv in a C-level fenv access), while bit twiddling instructions can be executed at up to 3 per cycle. mxcsr accesses are much faster, but mxcsr gives just more environment to handle for general C-level access functions, since the i387 and the SSE environments must be maintained in parallel, even on amd64 in case someone actually uses long doubles (SSE would suffice without long doubles). Anyway, the software version of sqrtl is irrelevant on athlon-xp, since athlon-xp has sqrtl in hardware (takes 35 cycles). Similarly for amd64, ia64 and possibly sparc64 (sparc64 has sqrt in hardware so it hopefully has sqrtl in hardware). arm and powerpc apparently have long double == double, so the software version of sqrtl is apparently only needed on ia64. When gcc and gcc actually support C99+IEC-mumble floating point, rounding and setting exception flags will have to continue to be handled using bit fiddling integer instructions or ordinary FP instructions, possibly moved to the C fenv access functions, since i387 fenv accesses are too slow to use for anything except initialization. Bruce From owner-freebsd-standards@FreeBSD.ORG Fri Dec 7 07:12:52 2007 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2384D16A419; Fri, 7 Dec 2007 07:12:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id 99B7113C459; Fri, 7 Dec 2007 07:12:51 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lB77CMKp003044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Dec 2007 18:12:39 +1100 Date: Fri, 7 Dec 2007 18:12:22 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: David Schultz In-Reply-To: <20071206210755.GA98191@VARK.MIT.EDU> Message-ID: <20071207180901.G853@delplex.bde.org> References: <20071002001154.GA3782@troutmask.apl.washington.edu> <20071002172317.GA95181@VARK.MIT.EDU> <20071002173237.GA12586@troutmask.apl.washington.edu> <20071003103519.X14175@delplex.bde.org> <20071010204249.GA7446@troutmask.apl.washington.edu> <20071203074407.GA10989@VARK.MIT.EDU> <20071203145105.GA16203@troutmask.apl.washington.edu> <20071205185132.GA91591@VARK.MIT.EDU> <20071205203235.GA40539@troutmask.apl.washington.edu> <20071206151017.U10456@delplex.bde.org> <20071206210755.GA98191@VARK.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-standards@freebsd.org, Steve Kargl Subject: Re: long double broken on i386? X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2007 07:12:52 -0000 On Thu, 6 Dec 2007, David Schultz wrote: > On Thu, Dec 06, 2007, Bruce Evans wrote: >>> On Wed, Dec 05, 2007 at 01:51:32PM -0500, David Schultz wrote: >>> This is probably a good idea if freebsd wants to maintain the >>> same algorithm across, say, sinf, sin, and sinl. I can produce >>> code for the ieee128 case, but I have no way to test it. >> >> I guarantee that it will have bugs if it is not tested :-). > > Panther is down, so neither do I unless there's another sparc64 > machine in the cluster. I will ask about getting Steve access if > that seems helpful. It's been down for a year or two. This has given me an excuse to not work on long doubles. I don't have any use for sparcs but think they set a high standard for floating point, at least with Sun compilers and libraries. Bruce