[PATCH, Fortran] gfortran.texi: Update "Project Status" section.

[Jerry DeLisle]

Brooks Moses wrote:
> This is the same text that I posted in a "draft" version last week, 
> taking into account Jerry's comments with regards to the LAPACK 
> testsuite -- it now says "produces acceptable results on the LAPACK Test 
> Suite".  (I think it would be useful to explain this a bit more on the 
> Wiki page about the results, and in particular explain why it is that 
> the results report "1 failure" and it's still "acceptable".  I don't 
> understand the details well enough to write that, though.)
> 
> In any case, this is that revised text, plus thinning out the "Proposed 
> Extensions" section.  Oh, and a missing comment to mark the "Results" 
> section header.
> 
> Ok for trunk?
> 
> --------------------------------------------------
> 2006-10-04  Brooks Moses  <bmoses@stanford.edu>
> 
>     * gfortran.texi (Current Status): update and rewrite to
>     reflect actual status more accurately.
> --------------------------------------------------
> 
> - Brooks
> 
> 
> ------------------------------------------------------------------------
> 
> Index: gfortran.texi
> ===================================================================
> --- gfortran.texi	(revision 117442)
> +++ gfortran.texi	(working copy)
> @@ -374,59 +374,50 @@
>  (even though Andy had already been working on it for a while,
>  of course).
>  
> -The GNU Fortran compiler 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.
> -
>  @menu
> -* Compiler Status::
> -* Library Status::
> +* Compiler and Library Status::
>  * Proposed Extensions::
>  @end menu
>  
> -@node Compiler Status
> -@section Compiler Status
> +@node Compiler and Library Status
> +@section Compiler and Library Status
>  
> -@table @emph
> -@item Front end
> -This is the part of the GNU Fortran compiler which parses a source file, verifies that it
> -is valid Fortran, 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 @command{gfortran} quit after running the front end, effectively reducing it to
> -a syntax checker.
> +The GNU Fortran compiler is able to compile nearly all
> +standard-compliant Fortran 95, Fortran 90, and Fortran 77 programs,
> +including a number of standard and non-standard extensions, and can be
> +used on real-world programs.  In particular, the supported extensions
> +include OpenMP, Cray-style pointers, and several Fortran 2003 features
> +such as enumeration, stream I/O, and some of the enhancements to
> +allocatable array support from TR 15581.  However, it is still under
> +development and has a few remaining rough edges.
>  
> -@item Middle end interface
> -These are the parts of GNU Fortran 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 GNU Fortran, but a large part has
> -already been completed.
> -@end table
> +At present, the GNU Fortran compiler passes the
> +@uref{http://www.fortran-2000.com/ArnaudRecipes/fcvs21_f95.html, 
> +NIST Fortran 77 Test Suite}, and produces acceptable results on the
> +@uref{http://www.netlib.org/lapack/faq.html#1.21, LAPACK Test Suite}.
> +It also provides respectable performance on 
> +the @uref{http://www.polyhedron.com/pb05.html, Polyhedron Fortran
> +compiler benchmarks} and the
> +@uref{http://www.llnl.gov/asci_benchmarks/asci/limited/lfk/README.html,
> +Livermore Fortran Kernels test}.  It has been used to compile a number of
> +large real-world programs, including
> +@uref{http://mysite.verizon.net/serveall/moene.pdf, the HIRLAM
> +weather-forecasting code} and
> +@uref{http://www.theochem.uwa.edu.au/tonto/, the Tonto quantum 
> +chemistry package}.
>  
> -@node Library Status
> -@section Library Status
> +Among other things, the GNU Fortran compiler is intended as a replacement
> +for G77.  At this point, nearly all programs that could be compiled with
> +G77 can be compiled with GNU Fortran, although there are a few minor known
> +regressions.
>  
> -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.
> +The primary work remaining to be done on GNU Fortran falls into three
> +categories: bug fixing (primarily regarding the treatment of invalid code
> +and providing useful error messages), improving the compiler optimizations
> +and the performance of compiled code, and extending the compiler to support
> +future standards -- in particular, Fortran 2003.
>  
> -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.)
>  
> -The IO library is in a mostly usable state.  Unformatted I/O for
> -@code{REAL(KIND=10)} variables is currently not recommended.
> -
> -Array intrinsics mostly work.
> -
>  @node Proposed Extensions
>  @section Proposed Extensions
>  
> @@ -438,11 +429,9 @@
>  @subsection Compiler extensions: 
>  @itemize @bullet
>  @item
> -Flag for defining the kind number for default logicals.
> +User-specified alignment rules for structures.
>  
>  @item
> -User-specified alignment rules for structures.
> -@item
>  Flag to generate @code{Makefile} info.
>  
>  @item
> @@ -453,10 +442,6 @@
>  module storage either on stack or heap.
>  
>  @item
> -Flag to cause the compiler to distinguish between upper and lower case
> -names.  The Fortran 95 standard does not distinguish them.
> -
> -@item
>  Compile flag to generate code for array conformance checking (suggest -CC).
>  
>  @item
> @@ -473,30 +458,11 @@
>  Flag to force local variables onto stack.
>  
>  @item
> -Flag to compile lines beginning with ``D''.
> -
> -@item
> -Flag to ignore lines beginning with ``D''.
> -
> -@item
>  Flag for maximum errors before ending compile.
>  
>  @item
> -Generate code to check for null pointer dereferences -- prints locus of
> -dereference instead of segfaulting.  There was some discussion about this
> -option in the g95 development mailing list.
> -
> -@item
> -Allow setting the default unit number.
> -
> -@item
>  Option to initialize otherwise uninitialized integer and floating
>  point variables.
> -
> -@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
>  
>  
> @@ -545,6 +511,11 @@
>  
>  @end itemize
>  
> +
> +@c ---------------------------------------------------------------------
> +@c Runtime
> +@c ---------------------------------------------------------------------
> +
>  @node Runtime
>  @chapter Runtime:  Influencing runtime behavior with environment variables
>  @cindex Runtime
This is OK.