Optimization

[sfcaustx]

I have problem with Optimization. I set optimization to "Disable" for debug build and to "Max. Speed" for release build. Some data file run fine in debug mode but failed in release mode. I do not know how the same program could run in debug mode and not run in release mode. If there is problem, why program runs fine in debug mode? The release executable should not be much different from the debug executable other than the speed or size for optimization. Can I just disable optimization in release build for production? Do you see any potential problems and how to solve them? Thanks.

[sfcaustx]

I set the optimization to "Max. Speed". To find theproblem in release build, I tracked down the code and added one WRITE statement (write blank to screen) within the possible troubled part. Amazingly, once the WRITE statement is added, the problem is suddenly solved. I could not explain why the program will get into a loop if there is no WRITE statement. Thanks.

[Steven_L_Intel1]

Optimization makes a lot of assumptions about the correctness of the code. If you have uninitialized variables, mismatched argument types or other errors optimization can bring out wrong results. Adding WRITE statements changes memory allocation for local variables and changes the instruction stream.

I suggest first turning on both array bounds checking and uninitialized variable checking in the release build to see if it shows anything. You can also try gradually increasing the optimization level in a Debug build and see where the change occurs. You can do some debuggiing even with some levels of optimization.

[sfcaustx]

Thanks for your suggestion. I did turn onarray bound checking and the uninitialized variables checking. This is a legacy program and many code lines were using FORTRAN66 and modifications were made through the years. I found some variables declared as REAL*8 for double precision and others are not declared, which is implicit as REAL*4. Will the conversionbetween them cause trouble? I did find some parts of code having mixedREAL*8 and REAL*4 expression and assigned to a REAL*4.I do not how optimization will deal with this situation. If this is a problem, how I should handle it?

[Steven_L_Intel1]

It depends on what you mean by "trouble". You may lose precision with such conversions, but otherwise it should not cause problems. You would have trouble if you passed a REAL*8 to a routine which expected the argument as a REAL*4.

[sfcaustx]

Is the assignment of REAL*8 variable to REAL*4 variablewrong and yield incorrect results? I found several places in the code have this kind assignment. I think this is also probably the cause of problem in the release build when optimization is enabled.

Will itset both "Default Real KIND" and "Default Double Precision KIND" to 8 a possible way to go and solve the problem? Or you can offer other suggestions?

[Steven_L_Intel1]

It is not "wrong". You will lose the extra precision of REAL*8 and get the closest REAL*4 value to what the REAL*8 had. This wouldn't change with optimization.

I do not recommend using the option to set the default real kind to 8, though it is certainly worth trying to see if the "problem" goes away. If it does, either you have a coding error somewhere in argument passing (not assignment) or your program is sensitive to small floating point differences.

[sfcaustx]

The problem went away after I set REAL kind to 8 and set the common element alignment to 8.There are minor precision loss comparing the output from release build with the output from debug build.The output from release build contains maximum speed optimizationand the output from debug build that contains no optimization. Both have same double precision settings.

I appreciate your help in getting the problem solved. Reading all the posts, I feel your contributionsare so important for the FORTRAN community. Thanks again.