Issues of providing both standard conforming and target optimized math runtimes for GCC were discussed.
Interested parties are various frontends (C++, Fortran, Ada) that are required to provide support similar to C99 from their runtime and like to be able to fall back to a standard conforming implementation provided by GCC. Especially on weird target architectures and OSs where the existing runtime is only partly working or cannot be relied upon. Other interest is from folks that require optimized versions of the math runtime, being it for different ABI, stripped versions useful for -ffast-math or -fno-math-errno. In addition to that, a place to add vectorized versions of the math routines, which are closely integrated to GCC is requested. Several points were be made about licensing, and people agreed that while it may be possible to use the LGPL, using GPL + exception will avoid user confusion and possible problems, especially if we are going to automatically link against this library. People had concerns about forking GNUs libm from glibc with respect to maintainance issues. The point was made that the standard conforming runtime GCC would provide was optional and not to be used if there is a conforming (and performant) runtime available from glibc or the target. Only the optimized routines would be used on such systems, which of course, if target dependent would have to be provided by the architecture maintainers if they want to enable extra optimizations for their platform. There were no doubts that we can get hands on properly licensed (GPL + exception compatible) standard conforming C routines that implement the C99 math runtime. Offerings were from AMD, and the original BSD-licensed routines from SUN were mentioned. Also it was suggested IBM could re-submit their math library for use in GCC with a GPL + exception license. -- In conclusion, having a C99 math runtime subject to GPL + exception inside GCC alongside with whatever optimized routines (being able to base on the C routines provided by the C99 routines) was generally accepted as worthwhile. Thanks, Richard. PS: please direct discussion to gcc@gcc.gnu.org only and avoid cross-posting followups.
