"Lynn McGuire" wrote:
Bummer, neither of
_control87( _PC_64+_RC_NEAR, _MCW_PC+_MCW_RC);
_control87 (_PC_64, _MCW_PC);
did not help. Something is really weird here.

The only "really weird" thing here is that apparently you are not
comprehending my explanations. My bad: TMI!

The outcome with _control87 should come as no surprise because I already
demonstrated that no change in the rouned 64-bit value would result in
exactly zero.

I concluded, therefore, that it is the extended 80-bit precision that, by
coincidence, causes that particular example to become zero.

I say "by coincidence" because the 80-bit precision will not always cause
expressions of the form (x/y)*y-x to be zero, for integer x and y, just as
there are integer x and y where that expression is not zero using 64-bit
precision.

I never fully explained my reference to "80-bit precision". Perhaps you are
unaware....

Although type Double is represented in memory by 64-bit floating-point,
Intel CPUs use 80-bit floating-point registers to perform arithmetic.

Since the 80-bit FP registers are accessible to the CPU, compilers can take
advantage of them to store pairwise intermediate results.

For example, the compiler might put x into FP1 and y into FP2, compute
FP1/FP2 in FP3 (x/y), then compute FP3*FP2 ((x/y)*y) in FP3, and finally
compute FP3-FP1 in FP3 ((x/y)*y-x). Finally, FP3 would be rounded to 64-bit
and stored into a variable, chptst in your case.

That is what is happening in my VBA example procedure called testit2().

-----

As for why the C++ compiler might optimize the DLL when linked to a C++
application, but not when linked to an Excel/VBA application, both Martin
and I conjectured that that is simply how things work.

Perhaps someone who understands Microsoft C++ and DLLs better can offer a
more detailed factual explanation. I don't think we need any more wild
speculation ;-).