Migrating a CVF DLL to IVF

[robert_henry]

I'm evaluating Intel Visual Fortran evaluation version 10.1to write DLLs against a third-party Fortran-based application. The vendor has provided sample DLL source code, recommending Compaq Visual Fortran to compile it, andCVF produces a DLL that works as expected. When I compile the code with IVF (after converting) it produces a DLL that throws an Access Violation Exception when called by the application.

I'm assuming that the problem is in the calling conventions. I'm compiling IVF using /iface:cvf, as the converter set it, though I've tried other settings. Dumpbin shows that /iface:cvf produces a DLL that looks like the CVF version. I've read "Porting Applications From Compaq Visual Fortran to Intel Visual Fortran" and tried to apply its recommendations, but so far no luck. I've tried to debug the DLL so I can observe what's happening, invoking the calling application in the debug command line, but the debugger stops immediately with a message that "*.exe is not an EXE", although the application is most assuredly an EXE. I'm not sure why that happens, but it is inconvenient.

For now we can use CVF to compile DLLs for this application. However, since CVF is no longer supported I'm assuming that in the long term that IVF would be the better choice, assuming it will do the job. Is what I'm trying to do with IVF possible? What other things can I try?

RKH

[Steven_L_Intel1]

It should work by compiling with /iface:cvf. The only thing that comes to mind is if the application makes some CVF-specific assumptions, such as the format of an array descriptor (important only if your DLL routines have arguments that are assumed-shape arrays with (:) bounds.) I can think of some other things but they are far-fetched for an application like this.

You ought to be able to debug by setting the "command line" Debug property in your DLL project to be the full path to the executable. It would be interesting to know where in your DLL the access violation occurs - is it at the point of entry or somewhere inside the routine.

What's the routine specification (declarations, including declarations of arguments) for one of the routines that fails?

[robert_henry]

I've considered the possibility of an array problem. This application does use multidimensional arrays, including complex data types.

I tried setting the "command line" property, but the debugger says that the executable isn't of "EXE" type. Surprising sinceI can type the name of the EXE file in a Windows Command window and it will run.

I can't tell what part is not executing. The application simply reports that an error has occurred, without telling much else.A Windows message box pops up with buttons to report the issue to Microsoft or not. And there's a Debug button. Clicking that and selecting the VS JIT debugger,a message box pops up reporting that there was an Access Violation reading some address, my only indication of what the problem might be. VS opens a disassembly of the code, pointing to the opcode that caused the violation.

mov ecx,dword ptr [eax+edx*4]

I can't really tell if the fault is in theinitial call to the initialization subroutine or if it's elsewhere. A debugger might help if I can figure out how to get it to cooperate.

[Steven_L_Intel1]

Do any of the arguments to your routine have (:) array bounds? (Or (:.:.:), etc.) Is this application and your DLL code something you can send to Intel Premier Support so that we can help you with it? (If you do, please ask that it be assigned to me.)

[robert_henry]

I don't see any (:) in the subroutine interface blocks, though I do see several in other parts of the code. I'm not sure yet how they're related. I'm still studying this code, hampered somewhat by the fact that my last experience with Fortran was F77. I hope the code won't need a major rework to get it to work with IVF.

Since this is commercial 3rd party software, I don't know that I'm at liberty to share much. Maybe I'll have to ask the vendor for help. Since they recommend CVF, I'm not sure how responsive they might be to getting it to work with IVF, though I suspect that destiny may eventually require it. They say it should work with any Fortran compiler, but they guarantee only CVF.

Now the compiler has developed another quirk: When I tried to recompile with a debug configuration, it fails with a link error. "fatal error LNK1101: incorrect MSPDB80.DLL version; recheck installation of this product". Curiously, this is the only project that behaves that way. The sampleproject "DynamicLoad" compiles and runs just fine.

[Steven_L_Intel1]

The MSPDB80.DLL error should go away if you install VS2005 SP1. I can't explain why it happens for some projects and not others.

If they say it should work with any Fortran compiler, then it is not likely to be an array descriptor issue.

The code should not need revising. Please contact the vendor and ask if we can be allowed access to the application to help you with this.

[robert_henry]

VS2005 SP1 was already installed. I discovered the problem with MSPDB80.DLL was my own fault. I'd tried to force DUMPBIN to work when it couldn't find MSPDB80.DLL by copying the dll to its folder. That made DUMPBIN work but introduced this other problem. Solved by removing that copy of MSPDB80 and checking what has happened to my environment path variable.

I've received a response from the vendor. They say that they'll be moving to the Intel compiler but right now they're having trouble with the way it handles arrays in a DLL. They say they've been in contact with Intel and no fix is currently available. So I guess that's it--for now.

Thank you for your help

[Steven_L_Intel1]

Who is the vendor? I'm unaware of any issues relating to "arrays in a DLL". I'd like to look in our database to see if I can find it.

[robert_henry]

EMTP-RV. http://www.emtp.com/

[Steven_L_Intel1]

I can't find any registrations under that name. Might you get the company to part with the Intel case number?