Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Another "debug" vs. "release"

lklawrie1
Beginner
803 Views
The two configurations seem to differ. The release is flat out crashing. The debug runs. Making it very hard to track down if it's a real error or not.
CVF works fine. (At least in debug mode, I suppose I can try the release mode there too).
If I can't resolve this soon, I will have to switch compilers to ???
0 Kudos
6 Replies
Steven_L_Intel1
Employee
803 Views
What I usually do in these cases is, in the debug configuration, change the optimization level and see if the problem returns. I then selectively lower optimization on source files until I find one that makes a difference. Sometimes you can lower the level partially (to 2 or 1) and still see the error, yet still have good debug information.
0 Kudos
lklawrie1
Beginner
803 Views
Yes, that will work if it's truly a problem in the code. But if it's the compiler configuration? Ref: earlier support issue. Is anyone working on that other than you?
Linda
0 Kudos
lklawrie1
Beginner
803 Views
Ok, you're off the hook this time -- currently works iff there is a SAVE on a var in the calling routine -- now I have to figure if that is accurate.
And, it won't compile right now in Lahey anyway. (Which will have to change when I do the Linux port).
Linda
0 Kudos
Steven_L_Intel1
Employee
803 Views
That can be a sign of an uninitialized variable.
0 Kudos
lklawrie1
Beginner
803 Views
Might be uninitialized.
I'm still getting the NANs (which was the next reason this one died since I had commented out that code for trying the Lahey compiler). Any idea if they're related to the optimization level?
Linda
0 Kudos
Steven_L_Intel1
Employee
803 Views
Impossible to say. Usually, problems that show up with optimization are due to incorrect assumptions made by the source code. Optimized code is less forgiving of coding errors. But there could also be a compiler bug.
0 Kudos
Reply