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 13:40:40 -0700
From: enh <>
Cc: Paul Zimmermann <>
Subject: Re: Re: integration of CORE-MATH routines into Musl?

(having now had time to skim the whole paper, i see you are already
comparing against llvm-libc [if not actually talking to them], and that you
have done some binary64 work [but no binary128 yet]. if you are trying to
find someone to talk to about llvm-libc and struggling with that, let me
know and i can try to find someone...)

On Fri, Sep 2, 2022 at 12:28 PM enh <> wrote:

> 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.