Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

DLL vs EXE quandary

Brian_Murphy
New Contributor II
142 Views

This is a puzzler.

I have a rather old code that gets all of its input from reading an input file and writes all output to a file.
I have compiled the code as a console program (i.e. EXE), and as a subroutine in a DLL.  The only change to the fortran source is changing PROGRAM to SUBROUTINE.  Visual Studio 2010 forces me to use a different project for each since it can't seem to build both an EXE and a DLL from the same project.

Upon execution, the two builds produce very different results from the same input file.  Does anyone have any suggestions on what could cause that.  The two Intel Fortran projects in Visual Studio were created entirely with default settings.  The DLL seems to run correctly, but not the EXE.  I tried the EXE from both Release and Debug builds, but got the same thing from each.

0 Kudos
9 Replies
jimdempseyatthecove
Black Belt
142 Views

>>Visual Studio 2010 forces me to use a different project for each since it can't seem to build both an EXE and a DLL from the same project.

True, but both can be in the same Solution.

>>Upon execution, the two builds produce very different results from the same input file.
>>The DLL seems to run correctly, but not the EXE. 

Apparently your start point of writing the PROGRAM has errors.

This may be a case of uninitialized variable usage. Have you enabled the runtime checks for uninitialized variables?

Jim Dempsey

Brian_Murphy
New Contributor II
142 Views

Thanks for the reply, Jim.

I set r/t error checking to ALL, and the EXE code built and ran with no change in output.

It turns out I may have been too quick in saying the DLL and EXE produce different output, because this morning I'm getting the same output!  I need to redo it carefully.  If they end up matching, then what I've got is a case of Intel Fortran giving different results than Compaq Fortran.  The project was not "imported" into IVF, I made the projects from scratch.

Steve_Lionel
Black Belt Retired Employee
142 Views

Different results from different compilers is not at all unusual. Even changing versions of the same compiler can change results due to different instruction sequences. CVF didn't use SSE instructions for floating point where CVF did not, and this will definitely create small differences in floating point operations.

jimdempseyatthecove
Black Belt
142 Views

>> this will definitely create small differences in floating point operations

and additionally, for poorly written convergence code, can result in either non-convergence or large divergence.

Jim Dempsey

andrew_4619
Honored Contributor I
142 Views

Quantify "produce different output", are we talking small differences in real values or chalk instead of cheese?

Brian_Murphy
New Contributor II
142 Views

The difference is one code says the answer is 8, and the other says 5.  It'll be a week or so until I can spend any more time on it.  I need to start over and make absolutely sure the difference is not from a screw up on my part.

jimdempseyatthecove
Black Belt
142 Views

Brian,

It may be beneficial to run two instances of Visual Studio debugger. One debugging the PROGRAM, and the other debugging the Test Program + DLL SUBROUTINE. You should be able to walk each versions with break points on same statements and then examine the input variables as used by computational sections.

If the iteration counts are too large to have this technique be effective, then insert diagnostic trace PRINT statements (same places same values). With appropriately constructed trace statements (file, line number, DO loop index, intermediary values, other...) you can capture the trace outputs into files, then run WinDiff or other difference program to locate the point where the programs diverge. Then you can re-run the debug sessions on both versions, with break points installed (break on iteration prior to divergence).

Jim Dempsey

andrew_4619
Honored Contributor I
142 Views

Brian Murphy wrote:

The difference is one code says the answer is 8, and the other says 5.  It'll be a week or so until I can spend any more time on it.  I need to start over and make absolutely sure the difference is not from a screw up on my part.

Sound like a coding error then. A Jim says normal debugging methods should get to the bottom of it.

Brian_Murphy
New Contributor II
142 Views

As it turns out, my problem was my own doing.  When testing the DLL, I was switching between multiple versions.  And the one I thought I was running was not the one loaded in memory, even though I thought it was.  So in the end, the DLL and EXE made from the same code did in fact produce the same results.

Sorry for the false alarm.

 

Reply