Amber8 fails tests with ifort 9.1

[Katherine_H_]

I was helping a user recompile the Amber molecular-dynamics package (version 8) after we upgraded from the 8.1 to the 9.1 compiler. Amber includes a number of tests to determine whether the results are correct; it compares output with a standard. Results that differ in the last significant digit are acceptable and fairly common, but ifort 9.1 produced results that were grossly in error. This was with the fairly standard optimization flags used by Amber.

As it stands, this is probably not a very useful bug report, since Amber is a big package (and non-free). But might there be some known issue with floating-point operations?

[Steven_L_Intel1]

There is no "known issue with floating-point operations" as general as "grossly in error". If there were, the compiler would never have seen the light of day. I can imagine that for some specific program there might be a compiler error that causes wrong results, or the application may have a coding error that was masked with earlier compilers. The only way to tell for sure is to get a test case to Intel Premier Support.

If you want to try to nail it down yourself, you can look at the intermediate results compiled with each compiler and see what operation makes them differ. Then and only then can you start to figure out what is different.

Just for grins, try compiling with "-fp-model precise" and see what you get. It would also be interesting to see if -xW (or -xP or -xT depending on processor model) makes a difference.

[Katherine_H_]

I'll have the user try the -fp-model precise flag. I was casting around trying to determine whether any compiler flags might make a difference, so this could be helpful. We are going to be running it both on Opteron and on EMT (but both running in strictly 32-bit mode) but I can try one at a time to test the -x flag.

I am pretty certain it's an optimizer issue of some kind, because I can't imagine the compiler would have been released getting incorrect results, whereas optimization has traditionally been a rich source of "unusual" behavior for lots of compilers (both in the sense of revealing bugs in user code and in having its own bugs).

[Steven_L_Intel1]

Well, we do thoroughly test the optimizer too, and look for numerical differences in thousands of test programs. Optimizer bugs that cause wrong numeric results are actually rather rare, but they are not unknown. The vast majority of such cases that come to our attention are application issues - either outright coding errors, unstable algoithms or inappropriate expectations by the user given what the program does and what its inputs are.

This is why I asked for a test case.