Date: Fri, 1 Nov 2013 07:52:27 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: "freebsd-numerics@FreeBSD.org" <freebsd-numerics@FreeBSD.org>, David Chisnall <theraven@FreeBSD.org> Subject: Re: MUSL math functions Message-ID: <20131101072032.P1002@besplex.bde.org> In-Reply-To: <20131031133352.GA59918@troutmask.apl.washington.edu> References: <DFD5EA35-ABDA-4A09-BFC7-9452D650C7FE@FreeBSD.org> <20131031133352.GA59918@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131101072032.P1002>