This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.Wonderful!
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"....
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?
type :: mytype real :: a integer :: b end type type (mytype), target :: c(10) integer, pointer :: d(:) c%b = 42 d => c%b print *, d end
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?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |