fp-port switch

[chris3]

I was bitten by the different default values of -fp-port /Qfp-port switches on linux and windows, and was getting different results on x86 running those OS' s because of it.

In the docs, it says that the option is available for EM64T on linux, but not on windows.

First, my understanding is that on EM64T, this issue should not apply (because in 64 bit mode, floating point ops are done in 32/64 bit regs, not the 80 bit x86/x87 fp regs).

Second, if I am incorrect above, what does this switch do on EM64T/linux?

Finally, if it is useful on linux, why isn't it available on windows?

Thanks,
Chris

[TimP]

I'll take a stab at this one, since it has been flagged as unanswered for so long, even though I don't have an authoritative source. The EM64T compiler for linux uses x87 code to implement the -mp option, which is deprecated now that the -fp-model switches have become available. Thus, you could run into situations where -fp-port would be needed to force round-off to float precision when -mp is set. However, -fp-port is supposed to be set by default by -mp, so the usage which could actually make a difference would be -mp -fp-port-, to get the extra precision evaluation of expressions, and avoid the extra performance cost of -fp-port.
I suppose it's possible that expressions with mixed long double and double or float would need -fp-port to force roundoff to expected precision. As you point out, the Windows EM64T compiler never uses x87 code, so -Qfp-port- would not make a difference.
I understand the 10.0 compiler should make more of an effort to avoid the situations seen up to now, where certain options would produce x87 code for short loops and cleanup loops where vectorized code is done with SSE/SSE2. Particularly when -fp-port is not set, this switching between x87 and SSE code would make results inconsistent. Now we will have better options to avoid these inconsistencies.