Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.

Debug and Release question

dondilworth
New Contributor II
433 Views
I have a large mixed-language program that works in both debug and release modes. The problem is that the release mode is not as fast as it was in CVF. Here are the command lines:

Fortran:
/nologo /debug:full /I"Release/" /reentrancy:none /extend_source:132 /Qauto /align:rec4byte /align:commons /assume:byterecl /Qzero /fpconstant /iface:cvf /module:"Release/" /object:"Release/" /Fd"Release\\vc100.pdb" /check:none /libs:dll /threads /winapp /c

C++:
/Zi /nologo /W2 /WX- /O2 /Ob1 /Ot /Oy- /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_VC80_UPGRADE=0x0600" /GF /Gm- /EHsc /MT /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /GR /Fp".\\Release\\SYNOPSYS200.pch" /Fa".\\Release\\" /Fo".\\Release\\" /Fd".\\Release\\" /FR".\\Release\\" /Gd /analyze- /errorReport:queue

Linker:
/OUT:".\\Release\\SYNOPSYS200v14.exe" /VERSION:"14.0" /INCREMENTAL /NOLOGO /LIBPATH:"C:\\Program Files (x86)\\Intel\\Composer XE 2011 SP1\\\\compiler\\lib\\ia32" /LIBPATH:"C:\\SYNOPSYSV14\\OpenGL\\freeglut 2.4.0 (compiled)" /LIBPATH:"C:\\SYNOPSYSV14\\Libraries(x64)\\Static\\MT" "ODBC32.LIB" "ODBCCP32.LIB" "mpr.lib" "SentinelKeys.lib" "wsock32.lib" "freeglut.lib" "Release\\SYNOPSYS200_lib_.lib" /NODEFAULTLIB:"LIBCMTd.lib" /NODEFAULTLIB:"msvcrtd.lib" /NODEFAULTLIB:"msvcrt.lib" /MANIFEST /ManifestFile:".\\Release\\SYNOPSYS200v14.exe.intermediate.manifest" /ALLOWISOLATION /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /PDB:"C:\\SYNOPSYSV14\\Release\\SYNOPSYS200v14.pdb" /SUBSYSTEM:WINDOWS /STACK:"3000000" /PGD:"C:\\SYNOPSYSV14\\Release\\SYNOPSYS200v14.pgd" /TLBID:1 /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:QUEUE

Notice the "/debug:full" directive in the Fortran command line. This seems out of place in a release-mode compile, and may be what is slowing things down. But if I take it out, the program crashes immediately after starting.

It starts with a C++ routine that calls some Fortran subroutines and then goes to my override of the run() loop. I cannot diagnose things with no debug information -- but it does not crash if the info is there.

Any idea what is going on?
0 Kudos
1 Solution
jimdempseyatthecove
Honored Contributor III
433 Views
>> So I put a SAVE in all of the routines that were crashing, and now they don't

*** CAUTION ***

You may have been crashing due to the variables NOT being initialized (static/SAVE variables can be initialized (explicitly or implicitly with compiler/linker switch)).

*** Your app is multi-threaded....
*** Therefore, IF your now SAVEd variables are required to be thread private (e.g. temp array), then you have a problem awaiting for a sequence of events to happen. IOW the program may work some of the time or most of the time or you never see the problem.

In a multi-threaded program be very careful of what is SAVEd (implicit or explicit) and what is on the stack (omission of SAVE does not place local arrays on stack unless RECURSIVE in effect). Do NOT rely on getting good results (once) as an indication that your program is correct (with respect to SAVE or stack'ed variables/arrays).

Jim Dempsey

View solution in original post

0 Kudos
2 Replies
dondilworth
New Contributor II
433 Views
I can answer my own question! The program was migrated from CVF, which does an implied SAVE everywhere. I had to change that option in order to implement a multi-threaded version, since local variables are different all the time. That caused the crashing. So I put a SAVE in all of the routines that were crashing, and now they don't.

Then I removed the debug request from the release version and -- viola -- fast code.

I do not understand why not saving a local variable would cause a crash, but it's a moot point. I'm up and running.
0 Kudos
jimdempseyatthecove
Honored Contributor III
434 Views
>> So I put a SAVE in all of the routines that were crashing, and now they don't

*** CAUTION ***

You may have been crashing due to the variables NOT being initialized (static/SAVE variables can be initialized (explicitly or implicitly with compiler/linker switch)).

*** Your app is multi-threaded....
*** Therefore, IF your now SAVEd variables are required to be thread private (e.g. temp array), then you have a problem awaiting for a sequence of events to happen. IOW the program may work some of the time or most of the time or you never see the problem.

In a multi-threaded program be very careful of what is SAVEd (implicit or explicit) and what is on the stack (omission of SAVE does not place local arrays on stack unless RECURSIVE in effect). Do NOT rely on getting good results (once) as an indication that your program is correct (with respect to SAVE or stack'ed variables/arrays).

Jim Dempsey
0 Kudos
Reply