On Thu, 9 Feb 2012, Richard Guenther wrote:
> > Given the fact that GCC already needs to know pretty much everything
> > about these functions for optimizations and constant folding, and is
> > in the best situation to choose specific implementations (-ffast-math
> > or not, -frounding-math or not, -ftrapping-math or not, etc), specific
> > optimizations (latency/throughput/vector optimized) and perform
> > (partial) inlining, shouldn't we have a math library directly within GCC?
>
> Yes, definitely! OTOH last time I added the toplevel libgcc-math directory
> and populated it with sources from glibc RMS objected violently and I had
> to remove it again. So we at least need to find a different source of
> math routines to start with (with proper licensing terms).
My view is that we should have a "GNU libm" project whose purpose is not
to install a library directly but to provide functions for use in other
projects (much like gnulib, but the functions could presume that they were
being built with recent GCC). In essence, there would be a range of
implementations parametrized by both properties of the system ("implement
this function for binary32, given binary64 as an underlying floating-point
type with efficient hardware operations and efficient 64-bit integer
operations") and requirements (on error handling, accuracy, speed) and
libraries using GNU libm would pick the implementations they want and give
them the exported names they want. (It's expected that future ISO C
bindings to IEEE 754-2008 will define specific type and function names for
types such as binary32 - so a function might be exported from libm with
both "sinf" and "sinf32" names - and also "crsin" and "crsinf32" if
correctly rounded.)
See further what I said at
<http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00517.html> on this.
A new GNU project is different from copying files from one to another and
modifying the copies (there seems to be more difficulty with that than
with using a well-defined external project in another project). We did
get approval for libquadmath doing such copying, however. (With GNU libm
it would be cleaner - functions written in terms of a generic binary128
type that could be either __float128 or long double, not needing changes
to use in two different places.)
Although ideally for convenient redistribution of binaries linked with the
library with GCC there would be permissive licensing, I'm not sure we
should necessarily rule out an LGPL library which would generally be
dynamically linked into binaries.
> So - do you have an idea what routines we can start off with to get
> a full C99 set of routines for float, double and long double? The last
> time I was exploring the idea again I was looking at the BSD libm.
crlibm would seem a good starting point for some functions (note that it's
possible to balance speed and size - build larger tables for faster
functions). The authors seemed possibly amenable to permissive licensing.
New GNU projects do not necessarily need copyright assignments to the FSF
and my inclination would be to make this a non-assigning project, that
could use BSD code if it seems appropriate. But I'd think of such a
project in any case as a large, long-term project needing an appropriate
investment of effort, that probably wouldn't start with a full set of
routines - it would start with a few functions, for a few types, and grow
gradually while carefully tracking the properties of each implementation.
Testcases from existing implementations could be used under a range of
licenses.
--
Joseph S. Myers
jos...@codesourcery.com
