Re: weird optimization in sin+cos, x86 backend

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

On Tue, 14 Feb 2012, Christoph Lauter wrote:

> As a matter of course, we'd be more than happy to get your input (and even
> guidance w.r.t. copyright management and coding conventions) on and during
> that project.

* GNU projects do not automatically need copyright assignments to the FSF 
(some do, some don't), but GCC and glibc are among the projects that do 
require assignments and I've never heard of an assigning project changing 
to non-assigning.  So assigning the work to the FSF is certainly the safe 
option for inclusion in GCC and glibc, although it may not be required.  
(GCC does not necessarily require assignments for new runtime libraries; 
see the Mission Statement.  glibc has lots of existing non-assigned code 
in libm, though new non-assigned code would need FSF approval.)

* The soft-fp license - LGPL+exception - is the safe option for licensing 
code built for the target - code going in libm itself - although other 
permissive licenses approved by the FSF would also be fine.

* Host-side code - generators - need to be free software; the GNU 
convention would be GPLv3+ although other free software licenses should 
also work (subject to FSF approval if this is a GNU project).

* The generators (for code in libm, test cases, etc.) must be fully usable 
using only free software.  For example, generators using Maple or 
Mathematica would not be OK for a GNU libm project.  The exact free 
software licenses for languages and libraries used in the generators are 
not so significant - as long as the licenses are suitably compatible for 
whatever combinations are formed.  I don't know what tools will be most 
appropriate here (though it seems likely GNU MP and GNU MPFR would end up 
involved somewhere even if code is not written directly in C using those C 
libraries directly).

* Follow the GNU Coding Standards for both the generated code, and for 
generators if those are written in C or C++ rather than some higher level 
language.  If using some higher level language, still follow the GNU 
Coding Standards as far as they make sense (not for details of source code 
formatting, but for such things as making programs support --help and 
--version, for example).

> If (parts of) GNU or gcc could officially endorse it, we'd even be happier.
> This might also help to get the financing.

I suspect endorsement may be tricky in that normally a new GNU project 
would I think be designated as such at a point where working code already 
exists.  But personally I think it's a very good idea to learn from what 
was done with crlibm and more recent research and use that to produce 
automatically generated versions of C99 libm functions suitable for use in 
both GCC and glibc (fully namespace-clean, avoiding global state, 
configurable as regards error handling, etc.), suitable for meeting a 
range of speed and accuracy requirements, able to handle variations among 
hardware architectures (for example, including variants of float and 
double functions that work correctly with x87 in 64-bit precision mode 
when the only type with real hardware operations is long double).  And 
certainly people can talk to RMS about the directions we'd like to follow 
for libm development, where this involves such things as choice of 
licensing and starting new GNU projects.

-- 
Joseph S. Myers
joseph@codesourcery.com