Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Sep 2022 12:28:33 -0700
From: enh <>
Cc: Paul Zimmermann <>
Subject: Re: Re: integration of CORE-MATH routines into Musl?

On Fri, Sep 2, 2022 at 5:18 AM Rich Felker <> wrote:

> On Fri, Sep 02, 2022 at 12:10:18PM +0200, Paul Zimmermann wrote:
> >        Dear Rich,
> >
> > we now distribute the CORE-MATH routines under the MIT license,
> > to ease integration into Musl (among other libraries).
> >
> > Please can you point out to a Musl developer who might be
> > interested to integrate some CORE-MATH routines?
> >
> > We will try to answer potential issues that might arise
> > during this integration.
> >
> > Best regards,
> > Paul
> >
> > PS: see for more details about
> > the CORE-MATH project.
> Could you summaraize briefly what you have in mind, and what tradeoffs
> might be? Are these intended to be drop-in replacements for the
> existing standard functions, or implementations for the "cr" versions
> thereof? I have not followed closely the "mandatory requirement of
> correct rounding for mathematical functions in the next revision of
> the IEEE-754 standard" topic and how it relates to the future of C,
> but my vague recollection was that the direction folks were leaning
> was towards a separate set of cr*() functions or something. But if
> it's possible to do correct rounding in a way that's all-wins
> (performance, size, quality of results) or nearly all wins (maybe
> slightly larger?), at least for select functions, that seems very
> interesting.

"what he said" (including the "i haven't been following the details").

assuming you have good answers to those questions then -- if you haven't
already done so -- you should probably also bring this up with
freebsd-numerics ( and the mailing list
mentioned on that page). that's the source of the vast majority of the libm
code used by Android/iOS/macOS. (the exceptions for Android are mostly
binary128 stuff from netbsd and arm32/arm64 optimized code from

on the opposite end of the spectrum, llvm-libc isn't widely used at all,
but that work is at such an early stage (although it seems like they have
had a heavy libm focus) that they probably don't have existing
implementations for a lot of stuff.

it seems -- having admittedly not read past the abstract of the paper that
you linked to -- that you're only addressing binary32 so far? not even
binary64? (i'm used to binary128 not getting much love!)

(oh, and thanks for picking a license that makes it much more likely that
all the libcs can use your work!)

> Rich

Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.