Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 05 Sep 2022 11:09:04 +0200
From: Paul Zimmermann <>
To: Rich Felker <>
Subject: Re: integration of CORE-MATH routines into Musl?

       Dear Rich,

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

the current situation is:

- IEEE 754 does not require correct rounding for mathematical functions

- indeed, the C2X standard will reserve cr_xxx names for correctly rounded

- thus mathematical libraries will have essentially 3 choices:

0) either provide incorrectly rounded functions as (say) exp.
   This is the current situation.

1) provide incorrectly rounded functions as exp, and correctly rounded
   functions as cr_exp.

2) or provide only exp, with correct rounding (then cr_exp could be an alias
   for exp)

It seems that LLVM-libc will go for 2), I have no news from other libraries.

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

If you look at Table II from, you see that
for *single* precision functions (binary32), indeed that's all-wins.

Best regards,

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.