Re: [PATCH 2/3] libm: Remove __ieee754_gamma_r variants

Keith Packard via Newlib <[email protected]> Tue, 01 Sep 2020 10:23:03 -0700

Newsgroups	gmane.comp.lib.newlib
Message-ID	<[email protected]>

Fabian Schriever <[email protected]> writes:

> Hi Keith,
>
> We welcome your efforts to clean up - and correct the error return 
> values of - the gamma/lgamma/tgamma families.

Thanks! I'm doing continuous integration testing as a part of embedded
toolchain support for RISC-V as part of my SiFive dayjob; fixing bugs
like this is part of that process.

> We would favor the removal of all non C/POSIX(+XSI)-standard functions 
> from the interface.

Oh, that's probably the best idea of all. Applications should not be
using 'gamma' at all given the different definitions over time and
space.

Any thoughts about the newlib __ieee754 interfaces? Those are
essentially the same as the C/POSIX interfaces but do not use errno or
other global variables, reporting exceptions only through the fenv API.

> If something was changed in 2002, that is working incorrectly and no one 
> found out until now, that is also not part of any standard, it suggests 
> that no one is actually using it and should be able to be safely 
> removed. Does Newlib have a policy to remove elements?

I don't think it's 'newlib' which would need any policy; newlib is used
downstream in a wide variety of projects, including cygwin and picolibc,
which may have separate policies. Cygwin has binary interface
definitions, changing those could affect applications there.

I'm using newlib as part of picolibc which is used for embedded
toolchains where removing things from the ABI to fix bugs would be just
fine.

> An interesting discussion about the standard lgamma/tgamma functions 
> would be to discuss accuracy improvements in line with the glibc 
> improvements from Joseph Myers (see 
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=050f29c18873ec05ba04a4034bed8cb3f6ae4463).

I read through that patch and agree that it would be nice to incorporate
something similar. We need to be cautious as code cannot be directly
brought in from glibc due to licensing differences.

-- 
-keith

signature.asc (application/pgp-signature, 832 B)