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

DLL vs EXE quandary

Brian_Murphy
New Contributor II
790 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
Honored Contributor III
790 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
Brian_Murphy
New Contributor II
790 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
Steve_Lionel
Honored Contributor III
790 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
jimdempseyatthecove
Honored Contributor III
790 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
andrew_4619
Honored Contributor II
790 Views

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

0 Kudos
Brian_Murphy
New Contributor II
790 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
jimdempseyatthecove
Honored Contributor III
790 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
andrew_4619
Honored Contributor II
790 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
Brian_Murphy
New Contributor II
790 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
Reply