Lowest Common Denominator Compiler Options - Compiler version 10.1

[Leigh_Wardle]

Hi everyone,

I have been using Intel Fortran Compiler version 10.1 for the production versions of my code since February 2009.
I estimate maybe 50 customers are currently using those versions.
I have not changed any compiler options from the defaults provided by the Visual IDE.

I have now got to the stage where a few customers have got issues with execution of the code.
At first I thought it may have been a problem with some AMD CPUs, but the code certainly runs on at least one AMD CPU.
I now have a problem executing on a recent Intel CPU. What is weird about this one is that seems to skip part of the computation, but finishes gracefully.

Is there a set of what I would call "Lowest Common Denominator" Compiler Options that at a minimum will ensure the same execution outcome on all Intel targets (and preferably) all AMD targets? I am happy to forgo all optimizations.
I only want to distribute one .exe file at any one time.

Thanks,

Regards,
Leigh

[Steven_L_Intel1]

Unless you use the /Qax option, the compiler generates code that executes identically on all processors, in that it does not change code paths. However, the math library, in particular, does do processor-type dispatching internally and this has been known to cause slight differences across different processor types (even for Intel processors) as different instructions are used. There is no way to disable this.

If your application is sensitive to small differences in computations, this might explain the change in behavior, but the only advice I can offer you is to try to figure out where in the application the differences appear and where they come from. Logging intermediate results (for floating point values, I find that writing the values in hexadecimal format is best) will allow you to compare differences.

Is this problem readily reproducible?

[TimP]

We found one case (numerically incorrect on Intel "Northwood" CPU, using ifort 9.1 and 10.1 32-bit, but correct on AMD Opteron) was solved by use of /QxW option. This option has become the default since ifort 11.0, and is intended for all Intel CPUs beginning with P4, and all AMD CPUs beginning with Opteron and Turion X2.
We are still looking for a solution to some other cases with the 64-bit ifort.

[Leigh_Wardle]

Quoting - Steve Lionel (Intel)

Unless you use the /Qax option, the compiler generates code that executes identically on all processors, in that it does not change code paths. However, the math library, in particular, does do processor-type dispatching internally and this has been known to cause slight differences across different processor types (even for Intel processors) as different instructions are used. There is no way to disable this.

If your application is sensitive to small differences in computations, this might explain the change in behavior, but the only advice I can offer you is to try to figure out where in the application the differences appear and where they come from. Logging intermediate results (for floating point values, I find that writing the values in hexadecimal format is best) will allow you to compare differences.

Is this problem readily reproducible?

Thanks, Steve, for the advice.

Is this problem readily reproducible?
Yes, I think so, based on some output files I have. So I will try logging intermediate results.

My other worry is that maybe there are one or more undefined variables that may change the flow of the program.
From my recent development experience with debugging in the IDE it looks as though undefined variables are automatically assigned unusually large values.
Is assignment of undefined variables something that can vary with target CPU?

Thanks,

Regards,
Leigh

[TimP]

Uninitialized variables will take on whatever bit patterns happen to be left behind in memory. For integers, as you said, this is likely to produce large values, which will change whenever anything changes in your build, possibly even from one run to the next. It would be good to try the '-diag-enable sv' for static checking and then the -check or thread checker options for run-time checking.