Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
10 Views

DLL vs EXE quandary

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
Highlighted
10 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

0 Kudos
Highlighted
New Contributor I
10 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.

0 Kudos
Highlighted
Black Belt Retired Employee
10 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.

0 Kudos
Highlighted
10 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

0 Kudos
Highlighted
Valued Contributor III
10 Views

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

0 Kudos
Highlighted
New Contributor I
10 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.

0 Kudos
Highlighted
10 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

0 Kudos
Highlighted
Valued Contributor III
10 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.

0 Kudos
Highlighted
New Contributor I
10 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.

 

0 Kudos