Updates to gfortran.texi "Project Status" section?

[Brooks Moses <bmoses at stanford dot edu>]

The "Project Status" section of the manual seems to be painfully out of 
date, compared to my impression of the current status.  I'd like to 
offer an update for it, but I'd like to get some consensus on what the 
current status actually _is_ before doing so.  What follows are my 
comments and suggestions, interspersed with quotations of the existing 
text.  I'd appreciate opinions and discussion.

Also, are there meta-bugs (other than the #19292 "g77 features not yet 
implemented" one) or such that I should look at for data for this?  I 
presume that the "status" pages off http://gcc.gnu.org/fortran/ are 
considerably more out-of-date than the 2006/06/21 "last updated" note 
would indicate, since one of them says "we hope to include a beta 
version in GCC 4.0"....

> @c ---------------------------------------------------------------------
> @c Project Status
> @c ---------------------------------------------------------------------
>
> @node Project Status
> @chapter Project Status
[...]
> The start of the GNU Fortran 95 project was announced on
> the GCC homepage in March 18, 2000
> (even though Andy had already been working on it for a while,
> of course).
>
> Gfortran is currently reaching the stage where is is able to compile real
> world programs.  However it is still under development and has many rough
> edges.

At this point, I'd say, "Gfortran is currently able to compile 
real-world programs.  However, it is still under development and has a 
few rough edges."

It may be useful to expand some of that into explicit mention of "nearly 
all standard-compliant Fortran 95 programs and many legacy Fortran 
programs, including a number of non-standard extensions."  I might also 
include some examples of known large codes that compile with Gfortran.

For that matter, http://gcc.gnu.org/wiki/GFortranResults lists the NIST 
F77 testsuite and the LAPACK testsuite, both of which seem worth 
mentioning (though do we have a more current result for LAPACK?).  Are 
there other significant ones?  Should I list successful execution of the 
Polyhedron benchmarks, and mention "respectable performance" on them?

My understanding is that Gfortran currently implements the entirety of 
the Fortran 95 language (but not including TRs), which means that it 
will compile nearly all standard Fortran 77 programs as well.  In 
addition, it supports the majority of g77 functionality at this point. 
Yes/no/opinions?

What about large common extensions?  I would think that the Cray 
pointers deserve a mention here.  Anything else?  Stream I/O from F2003?

> @menu
> * Compiler Status::
> * Library Status::
> * Proposed Extensions::
> @end menu
>
> @node Compiler Status
> @section Compiler Status
>
> @table @emph
> @item Front end
> This is the part of gfortran which parses a source file, verifies that it
> is valid Fortran 95, performs compile time replacement of constants
> (PARAMETER variables) and reads and generate module files. This is
> almost complete. Every Fortran 95 source should be accepted, and most
> none-Fortran 95 source should be rejected. If you find a source file where
> this is not true, please tell us. You can use the -fsyntax-only switch to
> make gfortran quit after running the front end, effectively reducing it to
> a syntax checker.

This is still true, I believe.  Though I think that the "most 
non-Fortran-95 source should be rejected" really should be restricted to 
_diagnosably_ non-standard code; there are plenty of ways to write 
illegal code that no compiler will catch.

> @item Middle end interface
> These are the parts of gfortran that take the parse tree generated by the
> front end and translate it to the GENERIC form required by the GCC back
> end. Work is ongoing in these parts of gfortran, but a large part has
> already been completed.
> @end table

As I understand it, this work is effectively complete, and there is 
nothing that the front end will parse that can't be delivered to the 
middle end, yes?

Given this, I'm of the opinion that the distinction between the 
front-end and middle-end-interface status here is obsolete, and the 
above two sections should be collapsed into "Compiler Status" or 
something like that.

> @node Library Status
> @section Library Status
>
> Some intrinsic functions map directly to library functions, and in most
> cases the name of the library function used depends on the type of the
> arguments.  For some intrinsics we generate inline code, and for others,
> such as sin, cos and sqrt, we rely on the backend to use special
> instructions in the floating point unit of the CPU if available, or to
> fall back to a call to libm if these are not available.

Still true?  Though this is more "design" than "status" information.

> Implementation of some non-elemental intrinsic functions (eg. DOT_PRODUCT,
> AVERAGE) is not yet optimal. This is hard because we have to make decisions
> whether to use inline code (good for small arrays as no function call
> overhead occurs) or generate function calls (good for large arrays as it
> allows use of hand-optimized assembly routines, SIMD instructions, etc.)

This seems true but nearly tautological.  Are we still in a _notably_ 
non-optimal state with regards to these intrinsics?  If so, are there 
particular ones that should be noted here?

> The IO library is in a mostly usable state.  Unformatted I/O for
> @code{REAL(KIND=10)} variables is currently not recommended.

Still true?  (And that caveat ought include REAL=16 variables too, 
right?)  Can I say something stronger than "mostly usable" here?  (In 
particular, is it effectively complete except for the large reals?)

> Array intrinsics mostly work.

Is this still a "mostly", or is this down in the realm of minor bugs?

> @node Proposed Extensions
> @section Proposed Extensions
[...]
> @item
> Flag to cause the compiler to distinguish between upper and lower case
> names.  The Fortran 95 standard does not distinguish them.

Does anyone actually think this is a good idea?

> @item
> Flag to compile lines beginning with ``D''.
>
> @item
> Flag to ignore lines beginning with ``D''.

We have this implemented, right?

I'm not going to quote all the rest, but could someone a little more 
knowledgable than me take a look through and see what other things are 
now valid?

> @item
> Support for Fortran 200x. This includes several new features including
> floating point exceptions, extended use of allocatable arrays, C
> interoperability, Parameterizer data types and function pointers.
> @end itemize

This should probably be up in the "Status" section or somewhere, rather 
than in with the rest of the proposed extensions, I'd think.

In addition, the TR15581 allocatable-components-and-such support should 
be explicitly mentioned -- is it reasonable to say that this is in 
progress and an implementation will be available soon?  (In particular, 
what's the projected status of this for the 4.2.0 release?)

Going at this from the other direction, are there additions to this 
section that ought to be made?

- Brooks