[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

["joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678

--- Comment #22 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Mon, 11 Nov 2013, nmm1 at cam dot ac.uk wrote:

> There are also very strong grounds for not wanting IEEE 754 support by
> default, anyway, because of the performance impact and because a lot of
> programs won't reset the state before calling external functions (and
> hence may well give wrong answers).  That is especially true if the code
> is used within a C++ program or uses GPUs or some SIMD units - let alone
> OpenMP :-(

Note also that the documented default is -ftrapping-math 
-fno-rounding-math.  I suspect that if -ftrapping-math actually 
implemented everything required for the floating-point exceptions aspects 
of FENV_ACCESS, it would be just as bad for optimization as 
-frounding-math - it would disallow constant-folding inexact 
floating-point expressions because that would eliminate the side effect of 
raising the "inexact" exception, for example (just as -frounding-math does 
disable such constant folding, although not in all cases it should, 
because the result depends on the rounding mode), and would mean a value 
computed before a function call can't be reused for the same computation 
after that call because the computation might raise exceptions that the 
function call could have cleared (just as -frounding-math should prevent 
such reuse because the call might change the rounding mode).

So a key part of actually making rounding modes and exceptions work 
reliably would be working out a definition of GCC's default mode that 
allows more or less the same optimizations as at present, while allowing 
users wanting the full support (and consequent optimization cost) to 
specify the appropriate command-line options or FENV_ACCESS pragma to 
enable it.