weird optimization in sin+cos, x86 backend

[Joseph S. Myers]

On Fri, 10 Feb 2012, Geert Bosch wrote:

> On Feb 9, 2012, at 15:33, Joseph S. Myers wrote:
> > For a few, yes, inline support (such as already exists for some functions 
> > on some targets) makes sense.  But for some more complicated cases it 
> > seems plausible that LTO information in a library might be an appropriate 
> > way of inlining while allowing the functions to be written directly in C.  
> > (Or they could be inline in a header provided with GCC, but that would 
> > only help for use in C and C++ code.)
> But neither LTO nor header-based inlining would be compatible with LGPL, right?

Indeed.  Either the LGPL+exception used in soft-fp, or a generic 
permissive license, would be more appropriate there.  (GPL+exception as 
for most of libgcc should also work, though I don't think there's any of 
that in glibc at present.)

> > Indeed, if we can't then other sources would need using for the functions.  
> > But it seems worth explaining the issues to RMS - that is, that there is a 
> > need for permissively licensed versions of these functions in GNU, the 
> > question is just whether new ones are written or taken from elsewhere or 
> > whether glibc versions can be used for some functions.
> 
> I'm skeptical that talking to RMS will result in relicensing of these glibc
> functions. If we're writing new ones (or incorporate libraries such as fdlibm),
> we don't need permission.

Relicensing of soft-fp to LGPL+exception was approved by RMS.

There are certainly some justifications for a relicensing that might not 
be sufficient - that a change would cause some software to be more widely 
used, for example, may not be a justification by itself - but the 
justification here is more in terms of the GNU system working better 
together as a whole, that permissively licensed versions of many of the 
functions already exist, and especially if as you suggest you don't want 
to maintain a stable ABI to the functions called from GCC (so many would 
only be linked in statically) permissive licensing is needed to meet the 
expectations people have for use of code built with GCC.  You may of 
course get approval for specific concrete functions rather than more 
generally, if you identify particular functions where the glibc 
implementations are of interest - and there may be functions not owned by 
the FSF, or where the assignments to the FSF do not permit a more 
permissive relicensing.  There may also be functions assigned to the FSF 
by a few big contributors who could grant permissive licenses themselves 
if they wish (where there haven't been significant changes to those 
functions after the contribution).

-- 
Joseph S. Myers
joseph@codesourcery.com