I'll give some data points from our OpenVMS Itanium (and Alpha)
platforms where we support multiple IEEE modes and dynamic rounding in
our C and Fortran compilers (we don't have actual FENV_ACCESS in our C
product but you can come close).
On the command line, you get to pick IEEE modes with:
/IEEE\_MODE=option /IEEE\_MODE=DENORM\_RESULTS \(D\) Selects the IEEE floating\-point mode to be used\. Options: FAST During program execution, only finite values \(no infinities, NaNs, or denorms\) are created\. Exceptional conditions, such as floating point overflow and divide by zero, are fatal\. UNDERFLOW\_TO\_ZERO Generate infinities and NaNs\. Flush denormalized results and underflow to zero without exceptions\. DENORM\_RESULTS Same as UNDERFLOW\_TO\_ZERO, except that denorms are generated\. This is the default for I64 systems\. INEXACT Same as DENORM\_RESULTS, except that inexact values are trapped\. This is the slowest mode\.
and rounding modes
/ROUNDING\_MODE=option /ROUNDING\_MODE=NEAREST \(D\) For /FLOAT=IEEE\_MODE, the /ROUNDING\_MODE qualifier lets you select one of the following IEEE rounding modes: o NEAREST \(default\) o DYNAMIC o MINUS\_INFINITY o CHOPPED
And "strict" modes
/ASSUME=\(option\[,\.\.\.\]\) Controls compiler assumptions\. You may select the following options: \[NO\]ACCURACY\_SENSITIVE Specifies whether certain code transformations that affect floating\-point operations are allowed\. These changes may or may not affect the accuracy of the program's results\. If you specify NOACCURACY\_SENSITIVE, the compiler is free to reorder floating\-point operations, based on algebraic identities \(inverses, associativity, and distribution\)\. This allows the compiler to move divide operations outside of loops, improving performance\. The default, ACCURACY\_SENSITIVE, directs the compiler to use only certain scalar rules for calculations\. This setting can prevent some optimization\.
if you pick DYNAMIC, you can then use a system call
(SYS$IEEE_SET_ROUNDING_MODE) to change the value. We warn in our
manuals that /ROUNDING=DYNAMIC may have a significant performance
impact. The idea is that you set the mode [the routine returns the
prior mode], do you work, put the old mode back. You would collect such
code into its own module and compile with with DYNAMIC but compile the
majority of your code with the defaults.
We've had our default be "strict" with /ASSUME=ACCURACY_SENSITIVE for
years and let people specify NOACCURACY if desired. We don't tie it to
any optimization level. It is a separate knob.