Re: weird optimization in sin+cos, x86 backend

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

On Thu, 9 Feb 2012, Andrew Haley wrote:

> On 02/09/2012 04:53 PM, Joseph S. Myers wrote:
> > 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).
> 
> But why, exactly?  Simply because we could never get an improved
> libm into glibc with Ulrich Drepper and Richard Stallman as
> gatekeepers?

The community of active glibc developers is moving glibc to cooperative, 
civil, community development - just look at patches being discussed and 
developed on the libc-alpha list.  Individual developers are not now 
gatekeepers; we discuss patches in public and if one person objects that 
doesn't mean a patch doesn't go in, if the overall conclusion from 
discussion is that the patch makes sense; you can see plenty of cases of 
patches going in based on reasoned discussion even where there were 
previous concerns.  Please do not avoid contributing to glibc on the basis 
of past problems.

Richard Stallman is not involved in the day-to-day development of glibc 
and is not a gatekeeper either except for overall FSF policy matters.

We welcome additional contributions, including contributions to libm - 
people interested are invited to help improve libm.  There are plenty of 
open bugs in the "math" component to address, and it's likely fixes to the 
existing functions will be of use for quite some time to come even if 
eventually some implementations are replaced.

So you can certainly get in fixes to individual functions - people helping 
with patch review are welcome as well - and you can replace function 
implementations where you have appropriate evidence for the new 
implementation generally improving things (which probably means 
information about accuracy, code size, average-case performance and 
worst-case performance; benchmarks are relevant to glibc changes just as 
they are relevant to GCC changes).

Help with patch review, bug fixing and triage and other improvements are 
of course very welcome in areas other than libm as well.

-- 
Joseph S. Myers
joseph@codesourcery.com