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

[Toon Moene <toon at moene dot indiv dot nluug dot nl>]

Zack Weinberg wrote:

> On Wed, Sep 06, 2000 at 12:28:25AM -0700, Andrew Vaught wrote:

> > On Sat, 2 Sep 2000, Toon Moene wrote:

> > > 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.

So far, I agree - although for most of the language g77 compiles you
wouldn't need a backward-compatibility switch on g95 (ironically, g77
doesn't offer many extensions over Standard Fortran 77 - and is often
chastized for that - and most of the ones it *does* offer are in Fortran
95).

> 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...

I think you overlook some things here.  The C, C++ and Java crowd has
*paid* developers to chase bugs and improve frontends.  The one and only
reason I managed to fix fold-const.c's extract_muldiv problem was that I
did it during my *holidays* - normally I do not have several contiguous
hours to chase bugs in the GNU Compiler Collection.

O, and Andy is writing the Fortran 95 Frontend in his spare time too -
not to mention all the other volunteers sending patches and bug reports.

> 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).

Agreed, they'll have to recompile with g95 and it'd better work ...

> 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.)

Agreed.

> 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.

This is hard to imagine.  The frontends are completely different and
independently developed - it is next to impossible to believe they would
have similar bugs.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://g95.sourceforge.net/ (under construction)