Tracking down optimization problems

[Deleted_U_Intel]

Does anyone have a checklist of the various kinds of code statements that could lead to problems when using higher levels of optimization?

I have some old code that runs fine under debug or local optimization, but fails or gives incorrect answers at higher optimizations for release. If I had an idea of what to scrutinize, I could try cleaning up that code. Or some idea of how to zero in on the offending statements.

Thanks.

[Steven_L_Intel1]

The first thing I do in such cases is do a "binary search" on the source files to find the one (hopefully) file which, when compiled without optimization, makes the problem go away. That's a start.

Usually, such problems are caused by coding errors such as out-of-bounds array references, argument mismatches or dummy argument aliasing.

Steve

[Intel_C_Intel]

If this is old code, the first thing you should check for are variables that are not initialized before they are used on the RHS of an assignment statement. The fact that there is no option to zero out variables that are not explicitly initialized has caused me more headaches than I could ever imagine on a code that previously ran fine on DEC 10, VAX, Silicon Graphics, HP, DEC Alpha, Cray YMP, and Cray C90 systems, and on PC's using the WATCOM, NDP, SVS, Layer, and Salford compilers. Anyone with legacy code that took advantage of the abiity to zero out all reals and integers will have to resort to print statements in the code in order to debug the code. Unfortunately, there is no way to ensure that problems in the optimized version are mirrored in the debug version for variables that have not been explicitly initialized. Sigh.............

Tom