From owner-freebsd-numerics@FreeBSD.ORG Thu Oct 31 21:20:05 2013 Return-Path: Delivered-To: freebsd-numerics@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 072A246F; Thu, 31 Oct 2013 21:20:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 8BB4C241C; Thu, 31 Oct 2013 21:20:04 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 713B6D6236E; Fri, 1 Nov 2013 07:52:28 +1100 (EST) Date: Fri, 1 Nov 2013 07:52:27 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl Subject: Re: MUSL math functions In-Reply-To: <20131031133352.GA59918@troutmask.apl.washington.edu> Message-ID: <20131101072032.P1002@besplex.bde.org> References: <20131031133352.GA59918@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=bpB1Wiqi c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=1RzFHNT0_LQA:10 a=vRDF3k4bEgO3gBk9w0sA:9 a=CjuIK1q_8ugA:10 Cc: "freebsd-numerics@FreeBSD.org" , David Chisnall X-BeenThere: freebsd-numerics@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of high quality implementation of libm functions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 21:20:05 -0000 On Thu, 31 Oct 2013, Steve Kargl wrote: > On Thu, Oct 31, 2013 at 10:46:15AM +0000, David Chisnall wrote: >> Hi all, >> >> MUSL (permissively licensed libc for embedded Linux) appears to include implementations of all of the functions that we're currently missing for C99 compliance. According to the wiki, we are currently missing: >> >> clogf, clog, clogl Done with the complex inverse hyperbolic functions last year, but not committed. >> coshl, sinhl, tanhl > > I have code for coshl, sinhl, and tanhl. > >> cexpl >> sincosf, sincos, sincosl > > I have code for sincosf, sincos, and sincosl. > >> ccosl, ccoshl, csinl, csinhl, ctanl, ctanhl >> cacosl, cacoshl, casinl, casinhl, catanl, catanhl Last line done last year but not committed. Was depending on logl. logl has been committed. Now depending on an active committer. >> erfcl, erfl > > I have code for erfcl and erfl. cerfl (not in C99) is apparently amazingly complicated. There is a whole library libcerf for it on the net. erf support is very patchy in calculators. See the list in the NIST web pages that update Abramowicz and Stegun. I find it hard to test since it is not in pari. >> powl Not quite as far off as cpowl. >> lgammal, tgammal Far off. >> cpowf, cpow, cpowl Far off. >> >> The following are marked as either in-progress or patches available: >> >> clogf, clog, clogl (bde) >> sincosf, sincos, sincosl (kargl) >> cacosl, cacoshl, casinl, casinhl, catanl, catanhl (stephen) >> >> Are these ready to commit? > > coshl, sinhl, tanhl are almost ready. This requires splitting a > computational kernel out of expl. sincosf, sincos, and sincosl > need to be retested and reviewed again. erfcl and erfl need to > be resubmitted for additional review. > >> What are the current blockers for getting them in? > > 1) Code freeze for FreeBSD-10 came at the wrong time. > 2) Got sidetracked on fixing a bug in roundl. > 3) Can't update my development systems to FreeBSD-11 (where new > code should appear) because news/pan does not compile with > clang++ because clang++ appears to have problems compiling > headers associated with libc++. > 4) ENOTIME. das AWOL :-). I don't commit. Others not very active. >> >> These are present in the MUSL tree. >> > > Have you looked at the code? Hint, I have. Here's ccoshl(). > > #include "libm.h" > > //FIXME > long double complex ccoshl(long double complex z) > { > return ccosh(z); > } Ick. >> Many are from OpenBSD, some are home-grown: musl developers know about FreeBSD libm and I think they sometimes get better bits from it. >> >> coshl, sinhl, tanhl >> ccosl, ccoshl, csinl, csinhl, ctanl, ctanhl >> erfcl, erfl >> powl >> lgammal, tgammal >> cpowf, cpow, cpowl >> >> cexpl is missing >> >> Would anyone like to object to importing the ones that are implemented? > > Yes. I object to importing anything from MUSL or OpenBSD or NetBSD > without review or testing. It also appears that these functions are > only available for ld80 archs. FreeBSD has both ld80 and ld128. Supporting ld128 can be a blocker. Apart from increasing the amount of code needed, the extra precision sometimes expands the technical complications a lot. It's a larger joke to use code like the above ccoshl() for ld128 where it loses 64 bits of extra precison instead of only 16. Using ld128 long doubles on sparc64 costs a factor for several hundred in performance (versus using doubles), so if they are used then they should work. Bruce