migrating code from f77 to f90

[Bud Davis]

i think this brings up an important issue of which the
answer is not clear.

say i have a million line g77 program that uses
'non-standards compliant' constructs.  i wish to move
to gfortran eventually for supportability, and wish to
re-write portions of the code and new functionality
using f95 features... but first i need the whole mess
to be compilable by gfortran.

truth of the matter is that g77 speaks 'street
fortran'.  almost any variant of F77 that existed
works with g77...irregardless of standards compliance.
 it is not trivial to 'clean up' a large program !!

ideally, i could 'clean up' my non-compliant f77 code
a couple of modules at a time, compile them with
gfortran, then mix them with the f77 compiled source
to make a single executable. 


this would make a nice, slow, step-wise migration
path.

can we do this between g77 and gfortran now ?


--bud

--- Brooks Moses <bmoses@stanford.edu> wrote:

> Jack Howarth wrote:
> > Tobi,
> >    Specifically, at...
> > 
> >
>
http://www.absoft.com/Products/Compilers/Fortran/Linux/XLF/xlf.html
> > 
> > The XL Fortran Advanced Edition compiler helps you
> port or migrate source
> > code among Fortran compilers by providing full
> Fortran 90 and Fortran 95
> > language support. Selected language extensions
> (intrinsic functions, data
> > types, and so on) from many different compiler
> vendors are also provided.
> > To protect your investments in FORTRAN 77 object
> code, you can link Fortran
> > 90 and Fortran 95 programs with existing FORTRAN
> 77 object modules and
> > libraries. To make programming and porting easier,
> XL Fortran Advanced
> > Edition Version 9.1 provides common industry
> extensions not found in
> > Fortran 95.
> 
> I presume that that's referring to linking Fortran
> 90 and Fortran 95 
> programs with existing _pre-compiled_ Fortran 77
> modules etc.  Either 
> that, or it's essentially meaningless marketing
> fluff (except insofar as 
> it implies that their extensions are compatible.)
> 
> Fortran 95 is, with very few exceptions, a superset
> of Fortran 77.  The 
> exceptions are as follows:
> 
> * The following things have been deleted:
> real/double loop variables, 
> branching to an END IF statement from outside its
> block, the PAUSE 
> statement, ASSIGN and assigned GOTO and assigned
> format specifiers, and 
> the H edit descriptor.
> 
> * There are more intrinsics; this may cause
> conflicts.
> 
> The following things that had been left
> processor-dependent are now 
> specified:
> 
> * The SIGN function may now handle negative real
> zero differently on 
> processors that support it.
> 
> * When a real constant is used in a DATA statement
> to initialize a 
> double-precision variable, Fortran 77 allowed the
> processor to parse the 
> literal with more precision than a real constant
> allows.  Fortran 95 
> doesn't.
> 
> * named non-common variables initialized in a DATA
> statement are now SAVEd.
> 
> * Input records can now be treated as padded with
> blanks if too short.
> 
> * A value of 0 may be formatted differently by a G
> descriptor.
> 
> That, according to the Fortran 95 standard, is the
> complete list -- 
> barring, of course, compiler-dependent extensions
> that your code may 
> use; when this topic comes up on comp.lang.fortran,
> it seems that the 
> code always has some of those!
> 
> What Mike Metcalf's convert.f90 program does is
> _not_ convert from 
> Fortran 77 to Fortran 90/95.  This is a common
> misconception.  What it 
> does is convert from fixed-form source to equivalent
> free-form source. 
> However, except in INCLUDE statements, the compiler
> has no problems 
> linking code in the two forms.
> 
> - Brooks
> 
>