Errata.... I wrote:
In contrast, the FP control word is set to
_PC_64 + _RC_NEAR when Excel executes.

Well, we cannot distinguish between _PC_53 and _PC_64 in Excel.

Excel certainly behaves that way. I always assumed that was because Excel
stores each pairwise operation into 64-bit memory, in contrast to VBA which
does not.

But we cannot distinguish between that behavior and setting _PC_53.

(In contrast, we can distinguish among the various rounding modes. So we
know that Excel uses _RC_NEAR, either by default or by setting it.)

I thought I had remembered stumbling across a situation that demonstrates
that SUM() behaves as if _PC_64 is set. But I cannot remember the
situation. And now I realize I was thinking of a different anomaly of Excel
floating-point arithmetic.

Note that if we call a DLL function to alter the precision mode "directly"
from an Excel formula, apparently the call to DLL is occurring the VBA
thread. So it has no impact on the Excel thread.


I wrote:
3. Note the #pragma fenv_access (on) directive.
This is needed per VC++ documentation. Otherwise,
compile-time FP optimization (e.g. evaluation of constant FP
subexpressions) might not have the effect
intended by changing the FP control word at runtime

Although that might be relevant to someone who requires a particular effect,
it is probably not relevant to Lynn's situation for two reasons.

First, Lynn is not trying to have a "particular effect", but simply to
duplicate the behavior of DLL code in both VBA and exe environments.

Second, Lynn's particular example is not likely to benefit from any
compile-time evaluations.