Implications of converting fixed format FOR files into free format F90 files

[ferrad01]

We have a large engine made up of many fixed format .FOR files.

I am considering converting them all to free format .F90 files.

A number of our clients call our engine as a DLL from their own .FOR files.

Are there any compatibility implications I need to be aware of in moving our engines files to free format F90 to ensure our clients do not have any hiccoughs?

[Steven_L_Intel1]

If your clients are calling the DLL, and not INCLUDEing your source files, there is no issue. For any INCLUDE files, I recommend constructing them so that they are valid as both fixed and free-form source. Details on that are in the Intel Fortran Language Reference.

[mecej4]

If you compile your DLL with traceback, and your clients report any aborted runs with tracebacks back to you, the line numbers would be different.

Other than that, I would not count on poking into an OBJ file and being able to conclude whether it was compiled from a fixed or free format source file. I do not pretend to know the guts of the Intel compiler, but it would be reasonable to expect that once the parser pass is done there is no trace left of the source format.

In fact, apart from embedded source file names, compile date/time and check sums, two DLLs, one from fixed sources and the other from otherwise identical free format source, should match byte-for-byte.

[ferrad01]

Most clients call the DLL directly, however there is one client where the following happens:

They provide us with some LIBs and a whole bunch of CMN files which contain variable declarations and COMMON blocks. We include these CMN files in our source. We then build the whole lot into a DLL which they access from their EXE.

I translated our source to free format F90 and modified all their CMN files to be free format too. It all links fine, but I'm wondering whether there will be any problems with the shared common blocks (eg. alignment).

[jimdempseyatthecove]

Tim18 and Steve L. are more experienced at this, but from my experience in doing this is there are a two potential gotcha's

1) (nasty one first), if there fixed format file had an error where initialization data or variable name got truncated after column 72 and if there code outside your distributable relies on this error, then your changes may expose a latent bug. Hopefully this error will show up at compile time, but often it shows up in errors in output (which may be very hard to identify where the problem lies).

2) If there code has records where field packing is assumed to some default (packed or natural alignment)then you might insist on insertion of SEQUENCE or compiler options such that no ambiguity exists between the code you compile into your DLL and the code they use with your DLL. If the customer does not want to accept your recommendations (insistence) then have them sign off on an "as-is" copy that works now.

Jim Dempsey

[ferrad01]

>>For any INCLUDE files, I recommend constructing them so that they are valid as both fixed and free-form source.

All I have done is change C comments into !, and changed the format of the continuation lines. Is there anything more I need to do?

>> Details on that are in the Intel Fortran Language Reference.

Could you refer me the a link / page number?

Thanks

[Steven_L_Intel1]

Open the Intel Visual Fortran documentation. Look at Language Reference > Program Structure, Characters and Source Forms > Source Forms > Source Code Useable for All Source Forms Here's what it says:

To write source code that is useable for all source forms (free, fixed, or tab), follow these rules:

Blanks	Treat as significant (see Free Source Form).
Statement labels	Place in column positions 1 through 5 (or before the first tab character).
Statements	Start in column position 7 (or after the first tab character).
Comment indicator	Use only !. Place anywhere except in column position 6 (or immediately after the first tab character).
Continuation indicator	Use only &. Place in column position 73 of the initial line and each continuation line, and in column 6 of each continuation line (no tab character can precede the ampersand in column 6).

[bmchenry]

i'd suggest you also consider using a utility/tool like PlusFort by Polyhedron Software to convert your FOR files.
It allows restructuring and/or spagetti code elimination, etc.
i've used in on many projects bringing ANSI66 or so Fortran (FOR) up to f90, etc.
and NO, i am not associated with them in any way and i'd expect other tools exist that can automate your tasks.

brian

[TimP]

Sorry to nit-pick: this works for free-form and for f77 standard fixed form. For the longer fixed form extensions, continuations don't work compatibly with standard fixed form.

[Steven_L_Intel1]

The instructions I quoted tell you how to write code acceptable to both source forms. This means limiting the statement field to 72 columns. If you have longer fixed-form source lines, converting them into the "both" source form will be a bit of extra work. My usual advice is to not use non-standard long source lines.