porting from CVF

Hi, we would like to convert our application written with CVF 6.6 to use FTN95 and .NET. Have you same hints or suggestions? Is there a 'tool' to migrate the project from CVF to FTN95?

thanks vspinelli

No. There is no conversion tool. If the code conforms to the Fortran 95 standard then it should compile and run without change.

I converted couple very large codes working before under 5-7 other Fortran compilers and the only suggestions would be

• to take care of often used with other compilers and specifically in older codes console WRITE(0,) by changing it to screen WRITE(6,).

• do not use WRITE(N,*) where N is ⇐ 6, changing N to something larger, say N>10 or even >100.

Conversion goes usually with no problems. If you will get some hiccups be happy: it's 99.9999% your code problems which other compilers just have missed. Compiler developers will most probably not tell that in this forum, but i see no problem for myself if i say that: this specific compiler as no other one is known for its excellent bug killing.

One per million lines by my stats will be the problem of this compiler which may not have some very old DEC routine like DECODE or may have unknown problem with one parallel algebra library which does not compile. Both problems are fixable though.

More, i will bet you will get at least 100 your code warnings/problems per 10K source text lines 5-10% of which could be serious ones (not initialized or not zeroised something, or comparing for equality floating point numbers) and will find good old hidden bugs which may be bothered you from day one (use /full_debug and the King-of-All-Hidden-Logical-Bugs-Kills /undef for that). As a result of all this here is one funny suggestion

• be polite with the author of the code if it is not yours. I broke relationships with one of developers after sending to him huge file with 10000 FTN95 compiler warnings and errors.

I'd also suggest two main areas of change to adopt:

1. Modify all file I/O to use Fortran 95 standard syntax wherever practical and include the use of IOSTAT=, especially for OPEN and READ. WRITE (, and READ (, are the cleanest way for addressing the console.
2. Search for all compiler provided functions and use the generic names wherever possible. They supply the appropriate KIND result, based on the argument precision. eg use ABS rather than IABS or DABS. I find /IMPLICIT_NONE to be a very useful coding practice, although many disagree. The most common subscript error when addressing an array is the case when the subscript = 0, typically for a null case when the value is not required. As Dan says, FTN95 is a bug killer and don't be surprised if you find a few that have been lirking around for years.

John

Thanks for suggestions, my 'fear' come from settings of the compiler and linker options and the needed 'adjustments' for interop with the system and not for the standard of the language. In the past i upgrade from f77 in UNIX version of LIANT fortran to CVF 6.6 and 90% of the work and problem was to 'tuning' compiler to meet my conventions. Like I2 as default for integer, R4 for real, passing the length of string arguments after other, etc etc. It was wonderful if there was an ' interpreter' for .dsw, .opt, .dsp files of CVF projects and workspaces.

If your sources are Fortran standard conforming then moving from CVF will be specifically painless. CVF inherited DEC Fortran which was sort of an unwritten standard and every other compiler mostly implemented its extensions and default settings. You don't need anything else if you want to keep your project as portable, future proof and headache-free as possible (but seems all we tend to move into exactly opposite direction :lol: )