Re: correctly rounded mathematical functions

[Paul Zimmermann <Paul.Zimmermann@inria.fr>]

       Dear Joseph,

> Date: Wed, 5 Jan 2022 18:44:46 +0000
> From: Joseph Myers <joseph@codesourcery.com>
> 
> On Wed, 5 Jan 2022, Paul Zimmermann wrote:
> 
> > I see one solution: declare cr_xxx as an alias for xxx for all functions,
> > and create corresponding bugzilla issues for those which are not (yet) CR.
> 
> That is contrary to recent practice for e.g. new Linux kernel syscalls, 
> where we no longer tend to add emulations if they have problems such as 
> race conditions meaning they are not a good emulation of the semantics of 
> the syscall.  Presumably if someone uses cr_* it's because they need 
> correct rounding, just as if they use pselect it's because they need to 
> avoid a race (cf. bug 9813 criticising the emulation added before we 
> tended to avoid such emulations).

this was just one proposal, feel free to propose a better one!

> Now, in the syscall case, the functions produce an ENOSYS error when the 
> syscall is unavailable.  But that's not such a good idea for libm 
> functions, given that users don't expect such functions to fail (other 
> than domain/range/pole errors) and so won't check for such an error - and 
> even if you use the stubs mechanism, that only produces a link-time 
> warning, and while autoconf knows about not detecting as a available a 
> function glibc defines only as a stub, other configuration systems might 
> not.  So I think for these functions, not defining or declaring them at 
> all when we don't have an implementation with the right semantics is the 
> better approach - but it also introduces complexity in the installed 
> headers.
> 
> 
> One more consideration to mention: the cr_* names reserved in draft C23 
> include some for functions that are new in C23 (from TS 18661-4) and not 
> currently (except for the exp10 functions) supported by glibc.  It would 
> be reasonable to say that we don't add cr_<func> before we have the 
> underlying, not-correctly-rounded, function <func> (for all floating-point 
> types and formats for all architectures) - so no cr_exp2m1 before we have 
> exp2m1, for example.

yes that make sense.

> I don't expect that to be a major issue, given that (a) most of those new 
> functions can be implemented reasonably, if not as fast or precise as 
> ideal, with fairly straightforward generic implementations in terms of 
> other functions, (b) I expect the C99 functions are a priority for your 
> correctly-rounded functions work over the newer ones and (c) when I get 
> time I hope to implement those new functions for glibc if no-one else has 
> done them by then, just as with other new C23 features.

yes our priority will be the C99 functions.

> Those new functions do have a soft dependency on MPFR support in order to 
> generate expected test results (it's not impossible to add them without 
> the MPFR support, but it means adding a local emulation in 
> gen-auto-libm-tests), but most of that MPFR support is in current git MPFR 
> (to be 4.2) - the main exception being that rootn with negative integer 
> argument has no corresponding MPFR function.  (If gen-auto-libm-tests is 
> to be usable on 32-bit hosts, which probably isn't that important, there 
> would also be the issue that the MPFR functions for rootn and compoundn 
> use unsigned long / long as their integer arguments but the C23 functions 
> can have any integer argument in the range of signed long long int.)

mpfr_rootn_si should not be difficult to add. I'll see with the MPFR
developers :-)

Best regards,
Paul