Re: [G95-develop] Should g77 accept file extensions .f90 and .f95 ?

[Zack Weinberg <zack at wolery dot cumb dot org>]

On Wed, Sep 06, 2000 at 12:28:25AM -0700, Andrew Vaught wrote:
> On Sat, 2 Sep 2000, Toon Moene wrote:
> 
> > 
> > So a couple of questions come up:
> > 
> > 1. *Should* g77 support compiling Fortran source code in files with
> >    the extensions .f90 and .f95 (in the end, Fortran 77 is a subset
> >    of Fortran 90/95, so it is not unreasonable to have code that's
> >    compileable by g77 in files that end in .f90 or .f95).
> > 
> > 2. If so, should this code be assumed to be free format (i.e. the
> >    compile time option -ffree-form be passed to the compiler by
> >    default) ?  I've checked that it is possible to override it by
> >    entering -fno-free-form.
> > 
> > 3. Or should g77 refrain from even purporting it has anything to do
> >    with Fortran 90/95 and simply refuse to recognise extensions
> >    .f90 and .f95 given that GNU Fortran 95 is well under way ?
> > 
> > Please share your thoughts on this matter.
> 
>   I think that (3) is the way to go.  Every now and then I hear someone
> talk about g95 "replacing" g77, but I think that g77 and g95 should
> complement one another.

Speaking only for myself: yes, the g95 *implementation* should
completely replace the g77 *implementation*.  Sure, people will want
to continue using Fortran 77, but I very much hope they can be served
by a backward-compatibility mode in g95.

I have three reasons for this.

1. The present g77 implementation is close to incomprehensible for
   anyone other than the original author, who has left the project.
   Fixing bugs - and there are plenty of bugs - is painful.  Look at
   how long some of the Fortran tests have been failing without anyone
   even looking at them...  You can forget about any improvements.
   For example, we'll never get functions-as-trees support in g77, or
   proper aliasing logic.

2. The g77 runtime - probably calling conventions, definitely the
   library - are unlikely to be compatible with whatever runtime g95
   eventually settles on.  It will be difficult or impossible to mix
   g77-compiled code with g95-compiled code in the same binary.  But
   people will definitely want to do just that (think about new code
   and old math libraries, for instance).  

3. Carrying around two completely different front ends for similar
   languages will be a maintenance headache.  We already have oodles
   of problems with divergence between C and C++ front ends.  (My
   integrated preprocessor patch, for instance, would be about 3x
   shorter if they shared more code.)  Imagine if you have a program
   which is correct Fortran 77 and also correct Fortran 90/95, but is
   miscompiled by one of the front ends.

Note that (3) is independent of (1).  Even if g77 were a pleasure to
maintain, you would still have to find and fix the same bug in both
front ends on a regular basis.

zw