- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
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?
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>> 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
*** 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
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>> 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
*** 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

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page