Re: correctly rounded mathematical functions

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

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.

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.

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

-- 
Joseph S. Myers
joseph@codesourcery.com