Compiler Purchase Evaluation

[mattintelnetfort]

I am trying to determine if the Intel Fortran compiler is the right product for our needs; I'm looking for some technical assistance and experience sharing. We have a windows desktop application that has components written in C++ and Fortran. The Fortran components as expected are our computational, high performance, components. We're moving to the .NET environment (Studio 2005) though I believe unmanaged C++ to start, and have to move from Compaq Visual Fortran to a current Fortran compiler. I'm aware that Intel has absorbed Compaq Visual Fortran, but am looking for a read on how seamless the migration was to the Intel compiler. Also, I see the Lahey compiler (I believe a competitor product)touts the ability to compile to the .NET Common Language Runtime while Intel appears to not support this (I assume for performance reasons). As a newbie to .NET, I don't know what this means or how much significance it should have on our Fortran compiler selection decision. Can anyone share their thoughts on this or compiler evaluation experiences with me? Is 'managed fortran' useful? How easy is the migration from CVF to IVF?

[Les_Neilson]

Late last year I undertook, for our company, the upgrade from CVF and Visual Studio 6 toIVF 9 and .net2003 We have not looked at .net2005 yet.Some 15000+ files of Fortran and C/C++, with several hundred projects / solutions (many of them mixed language). I kept notes of the changes I had to make as a report for my manager. The following is a summary of the findings.

The installation of both was straightforward - noinstallation problems. The code changes to the Fortran code were minor. The C++ changes were more significant because the VC7 compiler adheres to the standard more strictly.

Fortran specific comments :

(a) All files with
implicit none
include flib.fd
include flib.fi

will need the order to be changed to
include flib.fd
include flib.fi
implicit none

because the new include files have a USE present which must comebefore implicit none.

(b)Continuation lines that do NOT begin with a comma will need an "&" at the start

(c)All routines that call SEED, RANDOM, GETDAT, GETTIM, and/or QQ(eg MAKEDIRQQ)

will need the following line added : USE IFPORT
and remove the declaration (if there) eg INTEGER*4 MAKEDIRQQ

(d)INQUIRE has changed depending on whether against a file or a directory.

(e) IVF 9 does not like arrays dimensioned(1) (We had one routine where this occurred)

(f) GETCWD is a function not a subroutine. (We had one routine which "called" GETCWD)

(g) I changed <> to /= (not equal) in one routine.

(h) OPEN statement with SHARED= change to SHARE=

C/C++ comments This was more problematical.

The main problems I had were due to the new V7 C/C++ compiler in .NET 2003 and the changes to the iostream implementation.

From the MSDN / C++ documentation :
"The old iostream library was removed beginning in Visual C++ .NET 2003.
The main difference between the Standard C++ Library and previous run-timelibraries is in the iostream library. Details of the iostream implementation havechanged, and it may be necessary to rewrite parts of your code that use
iostream if you want to link with the Standard C++ Library. "

Some "cast"changes :HFILE to HANDLE; HTASK to DWORD
Change type for ON_COMMAND_RANGE (has signature void (UINT) )

One final comment. I found that with mixed language solutions, I made the C/C++ project the main one and the Fortran project the subsidiary one. I think it was to do with creating the seperate debug files and combining them for the solution,I think I remember some warnings of missing pdb file for the C/C++ code if I got the projects the other way round.

Hope this helps

Les

[Steven_L_Intel1]

(b) Continuation lines that do NOT begin with a comma will need an "&" at the start

Intel Fortran does not have such a requirement (it would be a bug if it did.)

(c) All routines that call SEED, RANDOM, GETDAT, GETTIM, and/or QQ (eg MAKEDIRQQ)

will need the following line added : USE IFPORT
and remove the declaration (if there) eg INTEGER*4 MAKEDIRQQ

This is needed only if you keep the /iface:cvf option added by the project converter and didn't have USE DFLIB or USE DFPORT under CVF.

(e) IVF 9 does not like arrays dimensioned(1) (We had one routine where this occurred)

Intel Fortran support arrays dimensioned (1) just the way CVF did.

[Les_Neilson]

Hi Steve,

"(e) IVF 9 does not like arrays dimensioned(1) (We had one routine where this occurred)

Intel Fortran support arrays dimensioned (1) just the way CVF did."

I submitted an example to premier support (Issue no. 336887) where I had a problem with this. It is under investigation.

You are right of courseabout (b) the continuation lines. I've just run a compile checking it.I'm not sure now what the original error was caused by. There must have been one as I made a note in my work diary and subsequent memo to manager, from which I cut and pasted the reply above.

Sorry for the misinformation.

Les

[Steven_L_Intel1]

Ah, that's a different problem - relating to the uninitialized variable checking. It works in 9.0.030, where we made a number of fixes to that feature.

[Les_Neilson]

Ah, thanks for that.I've just run my test program and you are right build 30 has fixed it.

Les