On Feb 9, 2012, at 12:55, Joseph S. Myers wrote: > 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.)
I don't agree having such a libm is the ultimate goal. It could be a first step along the way, addressing correctness issues. This would be great progress, but does not remove the need for having at least versions of common elementary functions directly integrated with GCC. In particular, it would not address the issue of performance. For that we need at least a permissive license to allow full inlining, but it seems unlikely to me that we'd be able to get glibc code under those conditions any time soon. I'd rather start collecting suitable code in GCC now. If/when a libm project materializes, it can take our freely licensed code and integrate it. I don't see why we need to wait. Still, licensing is not the only issue for keeping this in GCC. From a technical point of view, I see many reasons to tightly couple implementations of elementary functions with the compiler like we do now for basic arithmetic in libgcc. On some targets we will want to directly implement elementary functions in the back end, such as we do for sqrt on ia64 today. In other cases we may want to do something similar in machine independent code. I think nowadays it makes as little sense to have sqrt, sin, cos, exp and ln and other common simple elementary functions in an external library, as it would be for multiplication and division to be there. Often we'll want to generate these functions inline taking advantage of all knowledge we have about arguments, context, rounding modes, required accuracy, etc. So we need both an accurate libm, and routines with a permissive license for integration with GCC. -Geert
