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 11:20:18PM +0200, Toon Moene wrote:
> Zack Weinberg wrote:
> > On Wed, Sep 06, 2000 at 12:28:25AM -0700, Andrew Vaught wrote:
> > >   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).

I thought I saw a list of features removed between F77 and F9[05] go
by.  Obscure features, perhaps, but this _is_ Fortran... :)

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

Well, yes, but I think some of those paid developers, and some of the
random-bug-fix volunteers, would be willing to look at Fortran bugs if
the front end were comprehensible; particularly bugs that are
front/back end interaction problems.  I know I would.

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

I'm thinking specifically of bugs due to changes in the backend
interface.  For instance:

2000-05-06  Zack Weinberg  <zack@wolery.cumb.org>

        * com.c (ffecom_overlap_): Set source_offset to
        bitsize_zero_node.
        (ffecom_tree_canonize_ptr_): Use size_binop.  Convert to
        bitsizetype before multiplying by TYPE_SIZE.
        (ffecom_tree_canonize_ref_) [case ARRAY_REF]: Break up offset
        calculation.  Convert to bitsizetype before multiplying by
        TYPE_SIZE.

This was fallout from all the sizetype/bitsizetype changes Richard
Kenner made back in April.  Changes like that require updating every
front end.  The more there are, the more work that is.

zw