http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #36 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-12-03 14:54:40 UTC --- > Kind of, though, -ffast-math by itself already is on the verge of violating > the > standard. I disagree with this statement at least for codes that does not use IEEE intrinsic modules (not yet implemented in gfortran). Indeed the interaction between -ffast-math and IEEE intrinsic modules will have to be discussed and documented when these modules will be implemented (see pr50724 for the kind of problems). > I think -fno-protect-parens could be enabled by -ffast-math as that > means that one does not really care about the exact value. PLEEEASE DON'T. The situation is bad enough with -Ofast to not make it worse: with -fno-protect-parens gfortran no longer complies with the Fortran standard (7.1.5.2.4 quoted in comment #23) and IMO SHOULD NOT be part of any compound option. Note that if I am using -ffast-math, it is not because I do "not really care about the exact value". It is mostly because I KNOW that exceptions will be the signature of either a bug in my code and/or a bad choice of the parameters leading to numerical instabilities. In top of that, I think that the concept of "exact value" for floating-point numbers is ill-posed and as a consequence I do accept that the least significant digits may depend on the way I write the code or it is optimized (small fluctuations for well-posed methods, large ones otherwise). > If we want to add add extra protection for > tem = x + 2.d0**52 > x = tem - 2.d0**52 > we probably need to add yet another flag as there are surely users, which want > to have protected parentheses but allow for optimizations in the 'tmp' case. If I need an extra protection, I'll put parentheses and I don't need yet another flag. However, since the logic of the optimization is surprising the first time you hit it, it could (should) be documented.
