GCC and Floating-Point

[Joseph S. Myers]

On Sat, 28 May 2005, Scott Robert Ladd wrote:

> The separation of glibc and GCC leads to many problems not faced by
> commercial compilers; not only can a commercial compiler focus on a
> single platform, it also ships a C library as an integral part of the
> compiler package. Thus a commercial compiler, with a narrow focus, can
> ensure that the C library tracks changes in the compiler, while such is
> not the case with GCC.

People who care about glibc in this regard make the necessary changes.  
People not concerned with it do not need to do so; they just change the 
compiler and leave the glibc changes for others.  In practice glibc gets 
updated fine for changes in the compiler, e.g.:

2004-05-27  Jakub Jelinek  <jakub@redhat.com>

        * sysdeps/i386/fpu/bits/mathinline.h (__expm1_code): Define using
        __builtin_expm1l for GCC 3.5+.
        (__expl): Define using __builtin_expl for GCC 3.4+.
        (exp, expf, expl): Don't define for GCC 3.4+.
        (tan, tanf, tanl): Don't define for GCC 3.5+.
        (__atan2l): Define using __builtin_atan2l for GCC 3.4+.
        (atan2, atan2f, atan2l): Don't define for GCC 3.4+ or !__FAST_MATH__.
        (fmod, fmodf, fmodl): Don't define for GCC 3.5+ or !__FAST_MATH__.
        (fabsf, fabsl): Only provide if __USE_MISC or __USE_ISOC99.
        (sin, sinf, sinl, cos, cosf, cosl, log, logf, logl): Don't define
        for GCC 3.4+.
        (log10, log10f, log10l, asin, asinf, asinl, acos, acosf, acosl):
        Don't define for GCC 3.5+.
        (atan, atanf, atanl): Don't define for GCC 3.4+ or !__FAST_MATH__.
        (log1p, log1pf, log1pl, logb, logbf, logbl, log2, log2f, log2l): Don't
        define for GCC 3.5+.
        (drem, dremf, dreml): Don't define for GCC 3.5+ or !__FAST_MATH__.
        * sysdeps/sparc/fpu/bits/mathinline.h (sqrt, sqrtf, sqrtl): Don't
        define for GCC 3.2+.

It is not hard to get this sort of clean patch accepted for glibc.  If 
more precise macros were added to GCC to define what optimizations are OK 
it should be easy to get a patch to use them into glibc, probably 
including the 2.3 stable branch.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)