CVF to Intel Visual Fortran porting document

CVF to Intel Visual Fortran porting document

Attached is the current draft of a document to help with porting applications from Compaq Visual Fortran to Intel Visual Fortran. Your comments would be appreciated.

Message Edited by sblionel on 03-17-2004 02:04 PM

Steve - Intel Developer Support
26 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I read the document and think it's pretty good. I have the following suggestions.

1. You might want to put some kind of version or date reference near the title. If someone ever revises the document there will be a way to easily tell people which version of it you're referring to.

2. You've got a typo on the fifth page above the screen shot. It looks like "is shows here" should be "is shown here."

3. In the section discussing how the default calling conventions have changed it might be appropriate to mention that the Fortran convention of calling by reference and the position of the hidden length argument for strings hasn't changed. I'm not sure this is valuable.

4. In the section discussing the new ifort compile command I see no mention of whether IVF will accept CVF'sdf command. If it does, then what happens if you have both CVF and IVF installed on the same computer? Which compiler will respond to the df command?

5. In the section on getting help you might consider a reference for help with using VS.NET. There are a zillion books and Microsoft Web pages available, but perhaps you can come up with a pointer or two to give the new user (of which I am one) a nudge in the right direction. This isn't really Intel's responsibility, but the IDE and the compiler are closely intertwined, and most people won't be able to make good use of the compiler unless they become competent with the IDE.

Hope that helps.

Mike D.

Mike,

Thanks for the great comments.

The position of the string length argument HAS changed. The default is "after all arguments", whereas CVF put the length immediately after the address.

The DF command is accepted by Intel Visual Fortran. If you have both installed, you get whichever one is first in your PATH. If you start your command prompt session with the appropriate "shortcut" in the program group, you'll get the right one automatically.

I have CVF, IF7 and IF8 all installed on my system, and they don't interfere with each other. (Well, installing IF7 screws up the CVF directories list in Developer Studio, but that's an easy one-time fix.)

Steve - Intel Developer Support

Hi Steve,

I have found your 'porting hints' usefull.

However, I don't understand how to use the 'custum build step' to manage to build a mixed fortran-C static library as you mention on page five (page numbers could be useful).

Can you point me to some sample?

regs/Bjrn

Well, isn't this interesting? Turns out you don't need a custom build step at all! The correct thing happens automatically. I am astonished, pleasantly so. Time to update the document...

Steve - Intel Developer Support

Here's a revised version of the document. Apparently I can't replace the one in the base topic.

On the issue of the old CVF command names, it turns out that the paragraph in the first draft was intended for a separate document about porting from Intel Fortran 7, and not this one. I've updated it. Thanks for your comments so far.

Steve - Intel Developer Support

It might be time to include two related issues that are not covered in the current document (nor are they covered in the IMSL and MKL documentations), viz:

1. Migration of CVF linked to IMSL 4.1 static libs with particular attention to calling convention changes and the IVF preferred linkage to IMSL 5 DLL's.

2. The coupling between IMSL 5 and MKL for SMP and IMSL 5's use of MKL BLAS. Note that MKL gives one freedom ro use whatever calling convention one cares to use whereas IMSL appears to eliminate ones choice.

HTH,
Gerry T.

Steve,

I would also like to see included in your document something about linking intel fortran code with IMSL.
The only information is provided by IMSL who give comand-line instructions for compiling.

There is nothing on how to compile and linking within the visual studio environment.

In addition, I have found that there are some problems with some of the options that the convertion utility generates when convertyingcvf projects that utilize IMSL routines to intel-visual studio projects. In particular the compiler option /iface:cvf that the conversion utility sets is incompatible with IMSL version 5.

David Halpern

I agree with the need for documentation on using IMSL. I find very little so far. The Intel Visual Fortran Compiler User's Guide, Volume I gives a little and mentions "Using the IMSL Libraries from Intel Visual Fortran" that I can not find. You would expect a link to it within the help file.

I have not been able to compile an old DLL project as yet. The compiler can not find numerical_libraries.

Thanks,

Lee

How to reconcile this inconsistency within one project: linking to IMSL 5.0 DLLs requires /iface:default convention, whereas a previous CVF project linked to other DLLs requires /iface:cvf convention?

One way to resolve this is to add the appropriate ATTRIBUTES keywords to your interfaces for the non-IMSL routines and compile without /iface:cvf.

The interfaces for the IMSL routines ought to have ATTRIBUTES DEFAULT. I will send VNI a request that they do so.

Steve - Intel Developer Support

I have a CVF DLL that is called by a VB AXDLL and conversely so they both use the same /Gz calling convention as required by VB. The CVF links (statically) to IMSL 4.1. Also the CVF DLL is a mix of VC++ and Fortran. And all if this on a solo IA32 processor under W2K latest SP.

I'm trying to port the CVF DLL to IVF 8 Pro (latest build). The solution now consists of a VC++ DLL that is supposed to statically link to an IVF static library project. The latter links to IMSL 5 via the statement

include 'link_f90_static.h'

(which yanks in imsl, imslblas, imslscaler, and imsls_err .libs) and appears to built successfully, albeit with a bunch of LNK4006's and a couple of attendant LNK4221's), and warnings about the unused and variables not having an explicit type (use of implicit).

Alas, the build of the VC++ DLL fails.

I've attached both buildlogs in the hopes that someone can point out the error(s) of my ways.

Your help will be greately appreciated,
Gerry T.

PS
In the foregoing solution, how can I interchange projects, ie, have Fortran as the DLL and VC++ as the static library? The reason I ask is that I'd like to link to the IMSL DLL as recommended by VNI.

PPS
The VNI release/useage notes allude to the two modules numerical_libraries.f90 and numerical_libraries_f90.f90. The former compiled module is in include but the latter appears to be gibberish and isn't compiled. What gives?

PPPS
I happened on this:

http://softwareforums.intel.com/ids/board/message?board.id=16&message.id...

which may be of relevance to the PRJ link error encountered on the final build of my IVF-to be DLL.

By going with the IVF default of creating a Fortran DLL linked to a static C++ lib, everything built fine. The only changes required to the original CVF code were a few IMSL renames and CVF's IOSDEF.FOR is FOR_IOSDEF.FOR in IVF. Also, the IVF DLL builds successfully with either the static or DLL versions of IMSL. IMSL has to have /fpe:3 (no floating point error handling, just NaN's, Inf's, and denormals.)

HTH,
Gerry T.

Message Edited by g.f.thomas on 06-12-2004 11:21 AM

Good doc Steve - I use some of the old !DEC attributes, such as !DEC$ ATTRIBUTES NO_ARG_CHECK; will this cause any problems with the new IVF?

Thanks.

Jon Lea

That attribute is supported. I think the only one not supported is the ARRAY_VISUALIZER attribute - for now.

Steve - Intel Developer Support

Steve,
I ran afoul of something you might want to comment on in more detail, for us idiots. Following your Document I converted a CVF worskpace file to the MS IDE. I did the Fortran conversion as specified. The program build went fine in the debug configuration. When I changed to the release configuration, the build aborted with the message "Internal Complier error (Code 3) ..Please Report". The fix I got from Premier Support was the change the Project>Properties>Fortran>External Procedures calling convention from "CVF" to "default". I'm sure that thiswould screw someone else up, but it resolves an otherwise very unhelpful error msg, which gives no hint whatever of where to start looking for the problem. (The program did build from the command line whichI presume uses the Intel linker, while the MS IDE uses an MS linker)
Keith

Keith,

There were some bugs in earlier versions of the compiler that changing the convention was a workaround. Please make sure you are using the most recent version, which is 8.0.053.

Steve - Intel Developer Support

Really? Is the most recent version 8.0.053? But my version is W_FC_PC_8.0.050_PE053.1.exe? Are they the same version?

Thanks,
Zhanghong Tang

Yes, that's the current version. The installer file has the additional numbers to indicate that it revises 8.0.050 or newer to 8.0.053.

Steve,
I was using (I thought at least) .053. I apologize for being verbose. Perhaps just a comment to the effect that if one gets "Internal Compiler Error...", try this... Not everyone keeps their compiler truly up to date. I can send you the same zipped file that I sent Intel Premier Support, if you are curious.
Regards,
Keith

I don't think mention of this particular feature as related to compiler errors is appropriate for this document.

If you submitted a case to support, thanks.

Steve - Intel Developer Support

Hi Steve,

I think that what you are discussing here may provide a solution to my problem. I am unfamiliar with using compiler directives but think that I need to tell set iface to cvf and then tell the routines that call the mkl routines to use a different calling convention (or vice versa?). Would you mind giving me a few hints here it would be greatly appreceated.

Thanks,

ACAR.

One way to resolve this is to add the appropriate ATTRIBUTES keywords to your interfaces for the non-IMSL routines and compile without /iface:cvf.

The interfaces for the IMSL routines ought to have ATTRIBUTES DEFAULT. I will send VNI a request that they do so.

ATTRIBUTES DEFAULT needs to be added in the source that declares the interface. IMSL did add this, but MKL does not seem to have. I will suggest it to them.

Do you really need /iface:cvf? You can usually do without it by with a bit of work. Why are you using it?

Steve - Intel Developer Support

Hi Steve,

I'm responding to your response added yesterday - unfortunately I can't seem to do this in the correct place as when I more to the second or third page of the thread the reply button seems to disappear! Your response was (and thank you for it):

ATTRIBUTES DEFAULT needs to be added in the source that declares the interface. IMSL did add this, but MKL does not seem to have. I will suggest it to them.

Do you really need /iface:cvf? You can usually do without it by with a bit of work. Why are you using it?

My response is as follows:

I have recently upgraded a largeprojectfrom cvf to the lastest ivf compiler. I did this through the automatic conversion in the IDE and following a little bit of work to change obsolete routines etc my project was up and running almost (numerically correct but issues with the gui hanging) as it had been before. The current problem came to light when I realised that I wanted to eliminate the IMSL libraries from my project and replace the linear algebra routines with equivalent ones from mkl. I had previously replaced the large sparse linear solver from IMSL with PARDISO with no effort whatsoever - it just worked first time without any of the effort or issues I am seeminglyfacing now. I was unaware of an iface option until this issue but find that the conversion process has automatically changed it for me.

If I change iface from cvf then my project fails with errors on calls to routines where I am passing assumed length character strings - I've used this programming model quite extensively in my project.It might be that cvf was letting me get away with a non-standardprogramming model but it worked fine. So although I could do the work to modify all the routines to include the string length explicitly in thepass-parameters, I would prefer to leave well alone if possible. Hence my search forunderstanding of the problemfor findinga solution and my response to your thread.

Soif I don't wish to make the changes to my project whatis/are the solution(s)? It seems that the simplest solution (least effort) would be to leave iface set to cvf for my projectand change to default the calling convention for the routines that call the mkl routines. I have shyed away from gettinginvolved with modifying compiler attributes in the past and would like to seek advice on how this might be donefor my project. If I understand your response correctly then this simply means the inclusion of the appropriate compiler directive in the mkl interfaces. Is this something that I can add myself or do I need the Intel people to do it for me? Could I add the appropriate directive in the routines that call the mkl interface? If so how do I switch it back to cvf at the end of the routine? Probably, in the longer term, with the aim of having a st'standard' applicationI need to change my routines to reflect the default calling convention but at the moment, with the aim of returning to productive development,I would prefernot to do.

Many thanks in anticipation of your help.

ACAR

Actually, I think all you need to do here is to link to the _s suffix MKL routines. These are STDCALL and should work with /iface:cvf.

If you are calling C routines passing strings, the default convention is that the lengths are implicitly passed at the end of the argument list, where CVF put them right after the string address. You can't use ATTRIBUTES DEFAULT as a mode switcher - it is something used in the interface body for an individual routine. You could, I suppose, copy the MKL module source into your project and add ATTRIBUTES DEFAULT for all the routines, but that seems like a lot of work.

Steve - Intel Developer Support

Steve,

Responding to your following response (again in the wrong place as there is no reply button):

Actually, I think all you need to do here is to link to the _s suffix MKL routines. These are STDCALL and should work with /iface:cvf.

If you are calling C routines passing strings, the default convention is that the lengths are implicitly passed at the end of the argument list, where CVF put them right after the string address. You can't use ATTRIBUTES DEFAULT as a mode switcher - it is something used in the interface body for an individual routine. You could, I suppose, copy the MKL module source into your project and add ATTRIBUTES DEFAULT for all the routines, but that seems like a lot of work.

Response:

I have managed to get the project to compile and link with the calling conventions set to default. Not sure what actually did the trick but I have removed the kernal32.lib from the list of libraries. My link line is now as follows:

/OUT:"Debug/EFESYS.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\Program Files\Intel\Compiler\11.1\051\mkl\ia32\lib" /NODEFAULTLIB:"dfconsol.lib" /MANIFEST /MANIFESTFILE:"C:\RMA\Programs\EFE_V1.1\EFE\Debug\EFESYS.exe.intermediate.manifest" /DEBUG /PDB:"Debug/EFESYS.pdb" /SUBSYSTEM:WINDOWS /ENTRY:"WinMainCRTStartup" mkl_lapack95.lib mkl_intel_c.lib mkl_intel_thread.lib mkl_core.lib libiomp5md.lib

So thanks again for your help.

ACAR.

PS I will attempt to terminate the thread I started earlier on this subject.

Leave a Comment

Please sign in to add a comment. Not a member? Join today