(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
-
-@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.
-
-@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
-
-@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.
-
-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.)
+@node Compiler and Library Status
+@section Compiler and Library Status
+
+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.
+
+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}.
+
+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.
+
+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.
-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
@subsection Compiler extensions:
@itemize @bullet
@item
-Flag for defining the kind number for default logicals.
-
-@item
User-specified alignment rules for structures.
+
@item
Flag to generate @code{Makefile} info.
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
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
@end itemize
+
+@c ---------------------------------------------------------------------
+@c Runtime
+@c ---------------------------------------------------------------------
+
@node Runtime
@chapter Runtime: Influencing runtime behavior with environment variables
@cindex Runtime
OSDN Git Service
