Re: weird optimization in sin+cos, x86 backend

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Thu, 9 Feb 2012, Geert Bosch wrote:

> While I think it would be great if there were a suitable
> GNU libm project that we could directly use, this seems to only
> make sense if this could be based on the current glibc math
> library. As far as I understand, it is unlikely that we

No, that's not the case.  Rather, the point would be that both GCC's 
library and glibc's end up being based on the new GNU project (which might 
take some code from glibc and some from elsewhere - and quite possibly 
write some from scratch, taking care to ensure new code is properly 
commented and all constants are properly explained with free software code 
available to calculate all the precomputed tables).  (Is 
sysdeps/ieee754/dbl-64/uatan.tbl in glibc - a half-megabyte file of 
precomputed numbers - *really* free software?  No doubt it wouldn't be 
hard to work out what the numbers are from the comment "x0,cij for 
(1/16,1)" and write a program using MPFR to compute them - but you 
shouldn't need such an exercise to figure it out, such generated tables 
should come with free software to generate them since the table itself 
certainly isn't the preferred form for modification.)

There are permissively licensed GNU projects, such as ncurses.  You just 
need to make the case properly for the choice of project structure and 
licensing being the right thing for the GNU project (in this case, it 
makes sense to have one master place maintaining libm code for use in all 
projects needing it).  And, where existing LGPL code in glibc is not 
assigned to the FSF or is assigned with assignment terms preventing 
permissive licensing, indeed it won't be possible to use that code in a 
permissively licensed project.  But there's probably plenty that can be 
reused and cleaned up from various places, taking e.g. all the various 
bugfixes and enhancements in different forks of Sun fdlibm.

-- 
Joseph S. Myers
joseph@codesourcery.com