Date: Fri, 8 Nov 2013 00:50:39 -0800 From: David Schultz <das@FreeBSD.ORG> To: Bruce Evans <brde@optusnet.com.au> Cc: "freebsd-numerics@FreeBSD.org" <freebsd-numerics@FreeBSD.org>, David Chisnall <theraven@FreeBSD.org>, Steve Kargl <sgk@troutmask.apl.washington.edu> Subject: Re: MUSL math functions Message-ID: <20131108085039.GA1821@zim.MIT.EDU> In-Reply-To: <20131101072032.P1002@besplex.bde.org> References: <DFD5EA35-ABDA-4A09-BFC7-9452D650C7FE@FreeBSD.org> <20131031133352.GA59918@troutmask.apl.washington.edu> <20131101072032.P1002@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 01, 2013, Bruce Evans wrote:
> >> 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.
Not entirely, but sign me up for the ENOTIME excuse.
> > 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);
> > }
Is there anything usable in there? Thanks for the pointer in any case!
> > 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.
I think I was the one who proposed several years ago that we
should develop the ld80 and ld128 versions at the same time
because (a) it's more efficient to do both while you have the
algorithm in your head and (b) the ld128 versions probably would
never happen otherwise.
However, several things have happened since then. For one, years
have passed and there's still quite a bit of work to do. For two,
the only ld128 platform, sparc64, doesn't look as important as it
used to be. For a long time, we had trouble even finding a viable
test machine. Therefore, I think any incremental improvement would
be welcome -- even if it means doing ld80 only.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131108085039.GA1821>