Intel® Fortran Compiler 16.0 User and Reference Guide
Enables improved floating-point consistency.
Not available on Intel® 64 architecture targeting the Intel® Xeon Phi™ coprocessor x100 product family (formerly code name Knights Corner)
Linux and OS X: | -fltconsistency -nofltconsistency |
Windows: | /fltconsistency /nofltconsistency |
None
nofltconsistency |
Improved floating-point consistency is not enabled. This setting provides better accuracy and run-time performance at the expense of less consistent floating-point results. |
This option enables improved floating-point consistency and may slightly reduce execution speed. It limits floating-point optimizations and maintains declared precision. It also disables inlining of math library functions.
Floating-point operations are not reordered and the result of each floating-point operation is stored in the target variable rather than being kept in the floating-point processor for use in a subsequent calculation.
For example, the compiler can change floating-point division computations into multiplication by the reciprocal of the denominator. This change can alter the results of floating-point division computations slightly.
Floating-point intermediate results are kept in full 80 bits internal precision. Additionally, all spills/reloads of the X87 floating point registers are done using the internal formats; this prevents accidental loss of precision due to spill/reload behavior over which you have no control.
Specifying this option has the following effects on program compilation:
Floating-point user variables are not assigned to registers.
Floating-point arithmetic comparisons conform to IEEE 754.
The exact operations specified in the code are performed. For example, division is never changed to multiplication by the reciprocal.
The compiler performs floating-point operations in the order specified without reassociation.
The compiler does not perform constant folding on floating-point values. Constant folding also eliminates any multiplication by 1, division by 1, and addition or subtraction of 0. For example, code that adds 0.0 to a number is executed exactly as written. Compile-time floating-point arithmetic is not performed to ensure that floating-point exceptions are also maintained.
Whenever an expression is spilled, it is spilled as 80 bits (extended precision), not 64 bits (DOUBLE PRECISION). When assignments to type REAL and DOUBLE PRECISION are made, the precision is rounded from 80 bits down to 32 bits (REAL) or 64 bits (DOUBLE PRECISION). When you do not specify /fltconsistency, the extra bits of precision are not always rounded away before the variable is reused.
Even if vectorization is enabled by the [Q]x option, the compiler does not vectorize reduction loops (loops computing the dot product) and loops with mixed precision types. Similarly, the compiler does not enable certain loop transformations. For example, the compiler does not transform reduction loops to perform partial summation or loop interchange.
This option causes performance degradation relative to using default floating-point optimization flags.
On Windows systems, an alternative is to use the /Qprec option, which should provide better than default floating-point precision while still delivering good floating-point performance.
The recommended method to control the semantics of floating-point calculations is to use option -fp-model (Linux* and OS X*) or /fp (Windows*).
Visual Studio: None
Eclipse: None
Xcode: Floating Point > Improve Floating-Point Consistency
fltconsistency |
Linux and OS X: -mieee-fp Windows: None |
nofltconsistency |
Linux and OS X: -mno-ieee-fp Windows: None |