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
/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
/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
/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.