------- Comment #5 from joseph at codesourcery dot com 2008-10-16 16:31 ------- Subject: Re: gcc ignores FP_CONTRACT pragma set to OFF
On Thu, 16 Oct 2008, rguenth at gcc dot gnu dot org wrote: > Confirmed. The FP_CONTRACT macro is not implemented, but the default behavior > of GCC is to behave like it was set to OFF. No, the default is to behave like it is ON, on targets with fused operations, with target-specific options to turn it off. A default of ON is fine according to C99. It so happens that GCC's version of "ON" is buggy, in that it contracts even outside the bounds of source language expressions - those boundaries are lost at gimplification, long before the insn patterns are applied. Fixing this would probably require fused operations to be identified in the front end in conforming mode, and the only insn patterns in conforming mode for the fused instructions to have RTL describing them precisely as fused operations so non-fused ones don't get combined. This situation is much like the other floating-point pragmas: * GCC doesn't support any of the pragmas, and doesn't claim to support those parts of C99; the features can only be enabled or disabled for a whole translation unit on the command line. * The features for a whole translation unit are in practice rather buggy and incomplete. -fno-cx-limited-range (on by default) doesn't work for constant arithmetic (bug 30789). -ftrapping-math (on by default) doesn't cause all required exceptions to be generated, and spurious exceptions are generated in some cases; no real effort has been made to get it to work properly in all cases. -frounding-math (off by default) comes with a specific warning in the manual that it's experimental and incomplete, which is quite correct. Yes, there should be a target-independent option to disable contracting rather than needing separate options for each target, and in conformance mode (flag_iso) contracting, if enabled, should be restricted to source language expressions. I'm not aware of anyone working on this, or on the other issues with the options approximating to the standard pragmas, or on the pragmas themselves. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37845