more debug / nodebug issues

[ferrad]

Back to my debug / nodebug issue with my Fortran engine. I am getting really confused with whats happening here. Heres the background:

We have different results being generated by debug and nodebug engines, written in Fortran, compiled under Intel v9. Not being able run both through the debugger, I insert write statements in the code to monitor the values of certain variables. I have to start with the output and move backwards. Eventually I track it down (or so I think) to some single precision variables being set up in a subroutine. After the call to this subroutine, the last significant digit of the variables are different. (These then get converted into double precision, and these differences then amplify, causing the later differences).

So I think Ive got it, but now I scatter some write statements in this subroutine, and the differences disappear! What's going on?

The only difference between debug and nodebug are:

Linker: debug version has

/incremental:yes /DEBUG /DEBUGTYPE:CV /PDB:%PWD%ds_place2pplacec.pdb

My compilation command line is:

fort /nologo /c /iface:cvf /Tfsub_schedule.for /define:INTEL9 /Qsave /Fosub_schedule.obj /include:D:sfpintelbugs_nd /fpconstant /real_size:64

Are there any compiler options I can specify to avoid these problems?

Adrian

[Lorri_M_Intel]

I don't actually know what you mean by a "debug engine", but let me make a couple of observations.

When you specify /debug (or /Zi) the optimization level is set to "no optimize". You could try specifying /debug as well as

/optimize:2 ( or /O2 ) and see if you can reproduce the differences.

The optimization level absolutely can affect the order of expression evaluation, etc, which can change the floating point numbers.

- Lorri

[jim_dempsey]

Debug configuration typicaly initializes uninitialized variables to 0 the Release configuration typicaly does not. Also Optimizations are typicaly off so computation order can be different. There are two suggestions I can make:

1) Use the debugger runtime option to break on reference of uninitialized variable (to track down a bug in your code)

2) To compile the debug session with the same optimization options as the Release version. It is hard to debug this code but you can place breakpoints on statements that call out (calls or writes). Viewing variables can be problematic in this configuration. But the point is to identify the problem and not in particular to run with full debugging.

Jim Dempsey

[Steven_L_Intel1]

"Debug configuration typicaly initializes uninitialized variables to 0"

Not deliberately. If you get that value, it's a coincidence.