The status of the GNU Fortran project
Today, Fortran is primarily used by scientists and engineers. There is a wide variety of free and non-free scientific software written in Fortran. A lot of the free Fortran software comes from University professors. Just as important, a number of small software companies develop and sell software for limited or specialized market segments. Examples of such software is the quantum chemistry package Gaussian 03 and Adina, the Finite Element System for Structures, Heat Transfer, and CFD.
In the UNIXes of the 1980s, the most common variant of Fortran was Fortran-77. At AT&T Bell Laboratories the free translator f2c was developed. Translation from Fortran-77 to ISO C required a large runtime library in order to compile the resulting C code. Later, a front-end for GCC, the GNU C compiler (now GNU Compiler Collection) was developed using the same runtime library. The GNU Fortran 77 (g77) team, lead by James Craig Burley, stopped development after it was determined that g77 was sufficient to meet the requirements of its users. The front-end is still included in the GNU Compiler Collection prior to version 4. It is available at the g77 Legacy Site.
In year 2000, a new Fortran project entered the GNU scene - GNU Fortran 95 (G95). The goal of the G95 project is to implement the Fortran variant or standard from 1995 (ISO/IEC 1539:1997). Currently, no bugs are known!
With the release of version 4 of GCC in April, 2005, Fortran 95 was included as one of the new languages. In GCC 4, the Fortran 95 language is fully implemented. A valid Fortran 95 program should compile, while an invalid Fortran 95 will be rejected. GFortran uses the Tree-SSA middle of GCC, and therefore the same back-end (or code generators) and by that, GFortran is supported on a large number of architectures. But there exists a number of issues with the front-end including a need for better error messages.
Fortran has a large number of intrinsic functions. These functions are defined in the specification of the language, they are not implemented as a library subroutine as you might see in languages like C and C++. Examples of Intrinsic functions include the performing of averages of elements in an array and calculating dot products between two vectors/arrays. The set of I/O intrinsic functions is still limited. Most programs do not use the advanced I/O intrinsics, and these programs will work perfectly. Software that uses advanced I/O intrinsics might prove to be challenging to implement.
As of this writing, a large number of free software packages can be compiled using GFortran. Of course, most of the available packages are related to the scientific and engineering fields.
One of the nice things about GFortran programs is that you can suspend them during runtime. When the program receives a QUIT signal, a core dump will be generated. Later, you can restart the program from this core dump. This is a useful feature when your software reaches the CPU limit, this tends to be something that is tightly enforced in supercomputing centers around the world.
Even though the
documentation is extensive, it might not be up to date
with the latest releases of GFortran.
Most of the development in the GFortran project is focused on
implementing new intrinsics and optimizing the implementation of the
existing intrinsics.
The web pages related to GFortran are not well maintained.
If you're looking for a non-technical role in a free software
project, here's your chance to make a contribution.
| Index entries for this article | |
|---|---|
| GuestArticles | Geisshirt, Kenneth |
Posted Dec 1, 2005 11:43 UTC (Thu)
by xyz (subscriber, #504)
[Link] (1 responses)
Posted Dec 1, 2005 15:06 UTC (Thu)
by gurgel (guest, #6248)
[Link]
Posted Dec 1, 2005 16:33 UTC (Thu)
by hughmerz (guest, #34252)
[Link] (1 responses)
Posted Dec 8, 2005 16:43 UTC (Thu)
by steven97 (guest, #2702)
[Link]
The article is just wrong in some places, there are many known GFortran bugs. The author of G95 claimed "zero bugs" in G95 on his blog, but that probably was more intended as a joke than a serious statement about the quality of the software.
The editors of this LWN page should perhaps be more careful what they allow to be published here, even though I understand that this G95-vs-Gfortran mess is confusing.
Posted Dec 1, 2005 17:20 UTC (Thu)
by vblum (guest, #1151)
[Link] (3 responses)
I second a statement of a previous poster. The article fails to address that g95 and gfortran are different projects now, and what is said for one does not hold for the other. E.g., g95 is bug-free (as far as known) - gfortran is not (as far as known). gfortran is official gcc - g95 is not.
I am aware of the deep-rooted split between some of the developers and the reasons, and really appreciate that this unnecessary episode of free software history is not detailed here; however, the fact that there are two products does deserve an explicit mention.
PS: g95 "just works" for me. Lacking a full gcc 4 installation, I have not yet tried successfully to even get gfortran to run, but it appears to have a number of leftover bugs, just from reading the mailing lists. Any experiences with gfortran vs g95, anyone?
Posted Dec 5, 2005 23:10 UTC (Mon)
by kneth (subscriber, #5341)
[Link]
Posted Dec 6, 2005 3:56 UTC (Tue)
by bamrung (guest, #19446)
[Link]
Posted Dec 8, 2005 16:53 UTC (Thu)
by steven97 (guest, #2702)
[Link]
G95 is more careful about being standard conforming, but GFortran produces far better code for e.g. the Polyhedron benchmarks and SPECCPU. For me, G95 still doesn't build my codes while GFortran does. For others it may be the other way around.
The nice thing about g95 is that its release process is more dynamic than gfortran's. A new G95 binary is uploaded almost daily, while a gfortran binary is a bit harder to find (they do exist, see http://gcc.gnu.org/wiki/GFortranBinaries).
Although the article does not mention it G95 and gfortran are not the The status of the GNU Fortran project
same project. IIRC gfortran is a fork of the former.
The reasons why this happened are not clear and it is difficult to find
a place explaining this. :-)
What is the present relation between both projects?
A short explanation is found at The status of the GNU Fortran project
http://gcc.gnu.org/wiki/TheOtherGCCBasedFortranCompiler
From what I understand gfortran does not include the ability to resume from a core dump, rather this is a feature of G95.The status of the GNU Fortran project
The entire article is full of claims that apply to G95 but not to GFortran, and the other way around.The status of the GNU Fortran project
Thanks for the update - I'm sure a lot of readers here are interested / following the development.The status of the GNU Fortran project
I'm sorry not for being absolutely clear between G95 and gfortran. I would also like to have addressed the GOMP project a bit further.The status of the GNU Fortran project
Yes! g95 "just work" for me too. I migrated from Portland's Fortran 90 when I got my first Athlon 64 for my scientific research project. I found that g95 is more serious about the standard of Fortran than the Portland's. My code is not running on gfortran yet, the code compiled but the file I/O part just not work as expected yet.The status of the GNU Fortran project
The gfortran released with GCC 4.0.0 is not nearly as good as some recent G95 snapshots. Later GCC 4.0.x releases have a better gfortran. I think the gfortran in GCC 4.1 will be the first real test to see how well it works for everyone.The status of the GNU Fortran project