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

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

[ This will be my last contribution to this thread :-)  Honest ]

Zack Weinberg wrote:

> On Wed, Sep 06, 2000 at 11:20:18PM +0200, Toon Moene wrote:

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

From the Fortran 95 Standard, Paragraph 1.5.1 Fortran 90 compatibility:

The following features present in Fortran 90 are not present in this
standard:

1. Real and double precision DO variables.
2. Branching to an ENDIF statement from outside its IF construct.
3. PAUSE statement.
4. ASSIGN and assigned GOTO statements and assigned format specifiers.
5. H edit descriptor.

Although I won't lose sleep over these featurs not being present in my
compiler of choice, it's not rocket science to add 'm to g95.

> > > 1. The present g77 implementation is close to incomprehensible for
> > >    anyone other than the original author, who has left the project.

My reply, somewhat at cross-purposes:

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

And you did - see below; sorry if I sounded ungrateful.

[ Two frontends harder to maintain than one ]

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

...

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

Yep, and I looked into your change to see if I could switch the Fortran
Frontend from using bit sizes to byte sizes (it's a regular complaint
that on a 1 Gb RAM Pentium XXX you can't have an array of more than
65000000 (*) double precision variables).  However, I never figured it
out.

So it *is* hard and we *should* aim for g95 to replace g77 in the (long)
run - I agree with you on that one.

(*) 2**32 bits .EQ. 2**29 bytes .EQ. 2**26 double precision variables.
    Fills only half of your expensive RAM - bummer.

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