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
