CVF to Intel Visual Fortran porting document

[Steven_L_Intel1]

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

[durisinm]

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.

[Steven_L_Intel1]

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.)

[Intel_C_Intel]

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

[Steven_L_Intel1]

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...

[Steven_L_Intel1]

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.

[g_f_thomas]

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.

[dhalpern]

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

[lpartin1]

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

[Rolf_A_]

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?

[Steven_L_Intel1]

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.

[g_f_thomas]

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=153

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

[g_f_thomas]

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

[jlea]

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

[Steven_L_Intel1]

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

[keefer]

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

[Steven_L_Intel1]

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.

[Zhanghong_T_]

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

[TimP]

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.

[keefer]

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

[Steven_L_Intel1]

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.