Re: GCC and Floating-Point

[Scott Robert Ladd <scott dot ladd at coyotegulch dot com>]

Joseph S. Myers wrote:
> They didn't fail altogether; -ffast-math was split into multiple 
> options (-funsafe-math-optimizations -fno-trapping-math etc.) in 
> March 2001, following an analysis of everything that checked 
> flag_fast_math 
> <http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00690.html>.
> 
> Unfortunately this never got followed up properly by defining 
> separate preprocessor macros for each option, so if you use the 
> individual options then glibc headers checking __FAST_MATH__ may not 
> enable optimizations which would in fact be safe with the subset of 
> options specified.

Which implies, of course, that breaking -funsafe-math-optimizations into
components involves modifying glibc for corresponding __???_MATH__
definitions.

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.

GCC ships with an integral Standard C++ library; it seems to me that it
could also provide a Standard C90/99 library as well. But I suspect that
is a kettle of fish that should stay closed. ;)

> And as the current discussion illustrates, 
> -funsafe-math-optimizations itself has become a catch-all for many 
> different optimizations, such as -ffast-math was.

Breaking up -funsafe-math-optimizations would also require a policy for
how future optimizations should be organized, lest we end up right where
we started with one option that implies many things.

..Scott