|Fortran 2008 features||Absoft||Cray||g95||GNU||HP||IBM||Intel||NAG||Oracle||PathScale||PGI|
|Compiler Version Number||14||8.1.1||4.7/4.8||14.1||14||5.3.1||4||14.1|
|Simply contiguous arrays||N||Y||?||Y||N||Y||Y||N||N||N||N|
|Long integers||Y (100)||Y||?||Y||N||Y||Y (100)||Y||Y||Y||Y|
|Allocatable components of recursive type||N||Y||?||N||N||N||P||N||N||N||N|
|Data statement restrictions lifted||?||Y||?||?||?||N||N||N||?||N||N|
|Kind of a forall index||N||Y||?||N||N||N||Y||N||N||N||N|
|Type statement for intrinsic types||?||Y||?||Y||?||Y||N||N||?||N||Y|
|Declaring type-bound procedures||?||Y||?||Y||?||Y||Y||Y||?||N||N|
|Accessing data objects||Absoft||Cray||g95||GNU||HP||IBM||Intel||NAG||Oracle||PathScale||PGI|
|Omitting an allocatable component in a structure component||?||Y||?||N||?||N||Y||Y||?||N||?|
|Copying bounds of source array in allocate||?||?||?||N||?||Y||Y||N||?||N||?|
|Allocating a polymorphic variable||N||Y||?||P (210)||N||P (213)||Y||Y||N||N||?|
|Accessing real and imaginary parts||N||Y||?||N||N||Y||N||N||N||N||Y|
|Elemental dummy argument restrictions lifted||?||Y||?||Y||?||N||N||N||?||?||Y|
|Finding a unit when opening a file||N||Y||?||Y||N||Y||Y||Y||N||N||Y|
|g0 edit descriptor||N||Y||?||Y||N||N||Y||N||N||N||N|
|Unlimited format item||N||Y||?||Y||N||N||Y||N||N||N||N|
|The block construct||N||Y||?||Y||N||Y||N||Y||N||N||N|
|Intrinsic procedures for bit processsing||Absoft||Cray||g95||GNU||HP||IBM||Intel||NAG||Oracle||PathScale||PGI|
|Bit sequence comparison||N||Y||?||Y||N||N||Y||Y||N||N||N|
|Counting bits||Y||Y||?||Y||N||Y||Y||Y||N||P (212)||P (214)|
|Bit transformational functions||N||Y||?||Y||N||N||Y||Y||N||N||N|
|Intrinsic procedures and modules||Absoft||Cray||g95||GNU||HP||IBM||Intel||NAG||Oracle||PathScale||PGI|
|Taking radix into account when selecting a real kind||N||Y||?||Y||N||Y||Y||Y||N||N||N|
|Extensions to trigonometric hyperbolic intrinsics||Y||Y||?||Y||N||Y||Y||Y||N||N||Y|
|Error and gamma functions||P||Y||?||Y||N||Y||Y||N||N||P||N|
|Euclidean vector norms||N||Y||?||Y||N||N||Y||Y||N||N||N|
|Execute command line||N||Y||?||Y||N||Y||N||Y||N||N||N|
|Location of max. or min. value in an array||N||Y||?||N||N||N||N||N||N||N||N|
|Find location in an array||?||Y||?||N||N||N||N||N||N||N||N|
|Programs and procedures||Absoft||Cray||g95||GNU||HP||IBM||Intel||NAG||Oracle||PathScale||PGI|
|Save attribute for module and submodule data||?||Y||?||Y||?||Y||Y||Y||?||N||N|
|Empty contains section||Y||Y||?||Y||N||Y||Y||Y||N||N||N|
|Form of end statement for internal and module procedures||?||Y||?||Y||?||Y||N||Y||?||N||Y|
|Internal procedure as an actual argument||N||Y||?||Y||N||Y||Y||N||N||N||N|
|Null pointer or unallocated allocatable as absent dummy arg.||N||Y||?||Y||N||Y||Y||N||N||N||N|
|Generic resolution by pointer or alloc. attr. - procedure||N||Y||?||N||N||N||N||Y||N||N||N|
|Generic resolution by pointer or alloc. attr. - data obj.||N||Y||?||N||N||N||N||Y||N||N||N|
|Elemental procedures that are not pure||N||Y||?||Y||N||N||N||Y||N||N||Y|
|Entry statement becomes obsolescent||N||Y||?||Y||N||Y||Y||Y||N||N||N|
|Semicolon at line start||Y||Y||?||Y||?||Y||N||Y||?||Y||Y|
Legend: Y = Yes, N = No, P = Partial, U = Unconfirmed
integer(kind=8); (200) Only for a single image; (202) Only MOLD=; (203) int and real, and coarray. (210) gfortran via allocate but not via intrinsic assignment (211) NAG has ALLOCATE(MOLD=), but not polymorphic assignment (212) Pathscale, counting bits, not trailz (213) Waiting for update from IBM (214) leads, popent, and poppar supproted. No trailz.
Changes January 2013:
Changes between December 2010 and April 2011:
Extended list of Fortran 2008 features.
Absoft: first issue with available data.
Partial support: Allocatable components of recursive type.
Full support: Coarrays, DO CONCURRENT, CONTIGUOUS attribute, Simply contiguous arrays, Maximum rank, Implied-shape array, Pointer initialization, Kind of a forall index, Allocating a polymorphic variable, MOLD= in ALLOCATE, NEWUNIT= in OPEN, G0 and G0.d edit descriptor, Unlimited format item, CONTAINS may be empty, Additional intrinsic procedures, Additional items in ISO_FORTRAN_ENV.
PGI: first issue with available data.
Changes between August 2010 and December 2010:
Partial support: pointer initialization.
Full support: CONTIGUOUS attribute, simply CONTIGUOUS arrays, implied-shape arrays, EXIT statement, bit sequence comparison, combined shifting, counting bits, masking bits, shifting bits, Bessel functions Euclidean vector norms, parity, execute command line, NULL pointer as a missing dummy argument, ELEMENTAL procedures that are not PURE, ENTRY statement becomes obsolescent.
Changes between April 2010 and August 2010:
Partial support: error and gamma functions.
Full support: coarrays, CONTIGUOUS attribute, simply contiguous arrays, allocating a polymorphic variable,
g0 edit descriptor, unlimited format item, BLOCK construct, stop code, bit sequence comparison, masking bits, selecting a real kind, arc tangent function, location of max or min value in an array, find location in an array, constants, and entry statement becomes obsolescent.
Errata: “null pointer as a missing dummy argument” changed from Y to N.
Partial support: coarrays, allocating polymorphic variables, and constants.
Full support: BLOCK construct, stop code, hyperbolic intrinsic functions, and arc tangent function.
HP: first issue with available data.
IBM: first issue with available data on Fortran 2008 features.
Changes between August 2009 and April 2010:
GFortran added full support for unlimited format items and the error and gamma functions and partial support for the block construct.
Sun added full support for parity.
The information in the above table is from “Compiler Support for the Fortran 2003 and 2008 Standards,” a recurring article in the Fortran Forum by Ian D. Chivers and Jane Sleightholme.
Fortran has a long history. Many other programming languages have come and gone over the life of Fortran. Part of this success is that Fortran has avoided the temptation of implementing new programming concepts. Unfortunately, the resistance to change has also been responsible for Fortran’s diminishing user base over the last 20 years. Fortran 2003 and 2008 fix the most glaring deficiencies, such as standardized C interoperability and better string support. But is it too late to prevent Fortran’s demise?
For this to work, you need the current version of the LLVM, the matching version of Dragonegg, which you will compile to create a library eg dragonegg.so, which is then called from gfortran/gcc using
This page is for linking to available Fortran libraries and source code repositories. See Software repositories for collections of libraries and see Library distribution for methods for packaging and distributing Fortran libraries.
Libraries linked here are classified as follows:
When available, the above tags should link to the license page for a particular library, or to the text of the license itself.
Chin, L. S., D. J. Worth and C. Greenough (2006). Thoughts on using the Features of Fortran 95. Software Engineering Group Notes no. SEG-N-003.
Gray, M. G. and R. M. Roberts (1997). Object-based programming in Fortran 90. Computers in Physics 11, 355–361.
Reid, J. (2003). The future of Fortran. Computing in Science & Engineering 5, 59–67.
Worth, D. J. (2008). State of the art in object oriented programming with fortran. Technical Report RAL-TR-2008-002.
Fortran Standards development has a history of controversy, and new standards often seem to have “half baked” implementations. Unfortunately, the committee-driven standards development often does a poor job of meeting the interests of the user community. If we can develop proposals for new language features and illustrate a common interest, there is a reasonable chance of incorporating them into the next Fortran standards revision.
Most Proposals have a separate page. Add your comments there
Other proposals without a separate page
A separate set of proposals
These are extensions already implemented by some compilers, but have negative consequences that make them undesirable features.
Merging undelimited string literals (as in C). This just allows errors from a missing comma to go unnoticed, and is totally unnecessary because Fortran already supports breaking long strings across multiple lines.
Silently casting between logical and integer types. Again, the potential for missed errors outweigh the benefits of allowing sloppy coding.
Overloading logical operators as bitwise operators. Some compilers support this and the previous extension, leading to many opportunities for ambiguity.
Using period as an alias for the percent character in selecting derived-type members. The period produces a cleaner code appearance, but can also result in ambiguities.
Support for C-style backslash escape sequences. This can be useful, but is not compatible with standard Fortran. Instead, this should be supported via an intrinsic string function. For example:
Submodules are a feature of Fortran 2008 which allow a module procedure to have its interface defined in a module while having the body of the procedure defined in a separate unit, a submodule.
Submodules were originally introduced as an extension to Fortran 2003 and were later adopted as part of the Fortran 2008 standard. For further details, see the following technical report: ISO/IEC TR 19767:2005 Fortran - Enhanced Module Facilities.
The module-submodule structure is hierarchical - in that a submodule can itself be further extended by other “descendant” submodules.
Splitting a module into submodules may allow a programmer to reduce the source code size of the module proper.
Before submodules, this could only be done by moving code into other modules or into external procedures.
However, this moving of code was not always possible given the way the public/private attributes in Fortran work. Other modules and external procedure cannot access the private entities and components of a module - if the code to be moved accessed such an entity or component, then either the move was not possible or the private attribute needed to be removed, contrary to the original “information hiding” design of the program.
Entities in a submodule have access to the all entities and components of their ancestor module and any ancestor submodules by host association, just as if they were physically present inside the source code of their ancestors.
Depending on the Fortran processor in use, splitting a module into submodules may also reduce the time it takes to compile the entire program, by avoiding so called compilation cascades.
Ordinarily, changes to source code in the body of a module procedure require recompilation of the module hosting the procedure. For most build systems recompilation of a module then triggers recompilation of all program units that use that module, even if there has been no change in the things that the module “provides” to the program units that use it. When the recompiled program units are themselves modules, a cascade results.
If the body of the procedure is moved into a submodule, then any subsequent changes to the body will typically only require recompilation of the submodule and its descendants. The information in the source code of a submodule is typically not used to compile its ancestors or any program units that may use its ancestor module.
Use of submodules also allows information hiding within the scope of a module. Sibling submodules of a module cannot access the entities defined local to each other.
Consider the following example (from ISO/IEC TR 19767):
module points type :: point real :: x, y end type point interface module function point_dist(a, b) result(distance) type(point), intent(in) :: a, b real :: distance end function point_dist end interface end module points submodule (points) points_a contains module function point_dist(a, b) result(distance) type(point), intent(in) :: a, b real :: distance distance = sqrt((a%x - b%x)**2 + (a%y - b%y)**2) end function point_dist end submodule points_a
The repetition in the above example can be avoided by using an alternative declaration. The following example shows that it is not necessary to restate the properties of the
submodule (points) points_a contains module procedure point_dist distance = sqrt((a%x - b%x)**2 + (a%y - b%y)**2) end procedure point_dist end submodule points_a
When contributing code, please specify a license so that others know the extent to which they may use and modify your code. All code on the Fortran Wiki shall be in the public domain unless otherwise noted. Other common licenses are the BSD, MIT, and GPL licenses.
To contribute Fortran source code, add a link here to the filename, program, or module name, and create the new page by pasting the code, wrapping it in a fenced code block with a language keyword. See the HowTo and existing pages such as hello for examples.
This section lists individual modules, programs, and procedures, typically single files or perhaps zip files. See the Libraries page for more comprehensive collections of routines.
roman_numerals.f90 - a Roman numerals module.
Fortran with Excel -A gfortran example to call fortran from excel
How to Create Fortran DLL in Visual studio - A google powerpoint presentation on how to create a fortran DLL with Intel Compiler in Visual Studio 2005/2008
Binary STL file reader in fortran Binary STL file reader in fortran
Quine in fortran 90 While Fortran has been thought to develop scientific applications, it can also be used for programmer amusement, here is a nice quine written in Fortran. A quine is a computer program which takes no input and produces a copy of its own source code as its only output.
Let It Snow in Fortran Inspired by google’s let it snow, this is let it snow animation in fortran using pgplot graphics library.
Value of PI by Monte Carlo Method Fortran code to determine the value of PI using Monte Carlo Method.
Fireworks animation in Fortran Fireworks animation using Fortran PGPLOT libraries.
Heart in Fortran Generating Heart with Fortran code using pgplot.
ogpf An object-based Fortran 2003 / 2008 interface to gnuplot.
Hermite Polynomial Fortran module to generate hermite polynomials
Random number generator codes in fortran for probability distribution Fortran module to generate non-uniform random numbers
A Beginners Guide to Integrate java and Fortran in windows Simple tutorial on mixing JAVA and Fortran
Metcalf, M., J. Reid, and M. Cohen (2011). Modern Fortran Explained. Oxford University Press
Adams, J. C., W. S. Brainerd, R. A. Hendrickson, R. E. Maine, J. T. Martin, and B. T. Smith (2008). Fortran 2003 Handbook. Springer.
Brainerd, Walter S. (2009) Guide to Fortran 2003 Programming. Springer.
Metcalf, M., J. Reid, and M. Cohen (2004). Fortran 95/2003 Explained. Oxford University Press.
Adams, Brainerd, Martin, Smith and Wagener (1997). Fortran 95 Handbook. MIT.
Lemmon, D. R. and J. L. Schafer. (2005). Developing Statistical Software in Fortran 95. Springer.
McCormack, D. (2009). Scientific Software Development with Fortran. Lulu.
Clerman, Norman S. and Spector, Walter (2012). Modern Fortran: Style and Usage. Cambridge University Press.
Markus, Arjen (2012). Modern Fortran in Practice. Cambridge University Press.
Press, Teukolsky, Vetterling and Flannery (1996). Numerical Recipes in Fortran 90: The Art of Parallel Scientific Computing. Volume 2 of Numerical Recipes in Fortran. Cambridge University Press.
Kernighan, Brian W. and Pike, Rob (1999). The Practice of Programming. Addison-Wesley.
Oliveira, Suely and Stewart, David (2006). Writing Scientific Software: A Guide to Good Style. Cambridge University Press.
Chapman, Barbara et al. (2007). Using OpenMP: Portable Shared Memory Parallel Programming. The MIT Press.
Gropp W., Lusk, E. and Skjellum, A. (1999). Using MPI - 2nd Edition: Portable Parallel Programming with the Message Passing Interface. The MIT Press.
Rouson, D., J. Xia, and X. Xu (2011), Scientific Software Design: The Object-Oriented Way. Cambridge University Press.
Snir, Marc and Gropp, William (1998) MPI: The Complete Reference (2-volume set). The MIT Press.
The comp.lang.fortran newsgroup is very active and can be accessed from your favorite news reader via a usenet server provided by your internet service provider or university, if available, or via Google Groups.
Google Groups: http://groups.google.com/group/comp.lang.fortran
If your ISP or University doesn’t provide a Usenet server, a very good free service is provided by dotsrc.org (formerly SunSITE.dk). Information about registering can be found at http://dotsrc.org/usenet/. It carries all open-source related groups, which includes
comp.*, and thus
Links to selected comp.lang.fortran threads, sorted by date:
Fortran Myths & Disinformation Wanted (4 Feb 1999)
Recasting Fortran pointers (14 Nov 2001)
Object Oriented Optimization (27 Nov 2007)
Fortran templates (15 Apr 2008)
how to declare doubles in f95 (28 Jan 2009)
64-bit KISS RNGs (28 Feb 2009)
EOF idiom? (24 Apr 2009)
Get Key Function? (1 May 2009)
example of KIND to replace DOUBLE PRECISION (8 May 2009)
Stream I/O questions (26 Jun 2009)
There are many possible programming conventions. Example here should not be considered the correct answer.
In languages where procedure and/or variable names have global scope, it is useful to define a common prefix to avoid namespace collisions. Modern languages provide namespace hierarchies that preclude the need for an explicit prefix on every entity.
Fortran Modules are global scope. Module names for a given code project should include a common prefix. For example, a module named ‘constants’ is likely to cause problems.
Entities within a module do not need a namespace prefix. Doing so just makes the code more verbose.
If you want to USE a module without explicit ONLY statements, and still avoid the potential namepsace collisions, one method is to use a namespace-prefix wrapper module. For example:
module zzz_module_prefixed use zzz_module, only: & zzz_sub1 => sub1, & zzz_sub2 => sub2 end module zzz_module_prefixed
Now, “use zzz_module_prefixed” imports the entire module, but with namespace prefixes on all entities.
Fortran entities all share a common namespace. You cannot have a procedure and a type with the same name. Therefore, type suffixes are useful. The Fortran convention is to prefer full words, so it seems reasonable to use full words whenever it would not become too verbose. I use the following:
* The subroutine and function suffixes are obviously too verbose. These are only used when there is a reason to have subroutine and function versions of the same routine. I typically add a suffix only for the less-used variant. This could be avoided if Fortran allowed specific procedures to share the same generic name.
I do not use a suffix for allocatables because they behave more like normal variables. Pointers need more care, because they can leak memory.
(Joe Krahn) Logical Units should never be defined by a literal integer, including standard I/O units 5 and 6. Traditionally, this required user-defined procedures to allocate a free UNIT, and parameters to define standard I/O units. F2003 defines the units in ISO_FORTRAN_ENV, and F2008 include the OPEN NEWUNIT specifier to automatically allocate a free unit.
UNIT=* to read or write to standard I/O.
Use the values from ISO_FORTRAN_ENV for standard I/O units when necessary.
Always allocate units using F2008 NEWUNIT=, when it is available. Until then, use a function to locate an available unit number.
IMPLICIT NONE has been strongly encouraged for some time. Joe Krahn instead always uses compiler options that disable the default implicit-none. Maybe the next Fortran standard will define IMPLICIT-NONE as the default? Meanwhile, it is just another line of extra verbosity.
Use ‘.f’ for all Fortran source formats. Traditionally, Fortran source always had the ‘.f’ suffix. With Fortran90, ‘.f90’ became the convention, Fortran95 still used ‘.f90’. The ‘.f90’ is really more to indicate free-format source rather than the appropriate language version. Fixed-format should no longer be used for new code. Rather than complicate the suffix issue further by including ‘.f03’ and ‘.f08’, Fortran should revert to the single common suffix, as is the convention in most languages. For example, C99 code still uses the ‘.c’ suffix.
On the other hand, compilers use the suffix to detect whether the source is fixed-form or free-form. If you are using only free-form source, then the above convention is appropriate, and a compiler option must be used to tell the compiler to interpret all files as free-form. If you are mixing fixed and free source, then the most practical solution, until compilers can detect it automatically, is to use ‘.f’ for all fixed-form source and ‘.f90’ for all free-form, regardless of which language specification is being used, thus avoiding the proliferation of version-specific suffixes.
For code intended to be portable, it is useful to compile code under multiple compilers. It is also useful to build both debug and optimized versions. Rather than copying or symlinking source files to multiple build locations, all builds can be done in the same location using subdirectories for intermediate and output files.
This is an example Makefile fragment. It is trimmed down from the actual Makefile to reduce verbosity. It defines $(OUTDIR) to be a subdirectory specific to a given compiler and build option, where all object amd .mod files are written. You can make a small change, then re-build any of the build forms without cleaning and starting from scratch each time.
#BUILD options: openmp, release, profile, debug #FC options: ifort, gfortran ifeq ($(BUILD),) BUILD=release endif ifeq ($(FC),) FC=gfortran endif OUTDIR = $(FC).$(BUILD) #=================================================================== ifeq ($(FC),ifort) CC = icc FFLAGS = -implicitnone -free -module $(OUTDIR) -sox FPPFLAGS = -cpp -I $(OUTDIR) ifeq ($(BUILD),debug) FFLAGS += -g -mp -traceback -debug extended else ifeq ($(BUILD),profile) FFLAGS += -O2 -p -prof-genx else # release or openmp FFLAGS += -O3 -IPF-fp-relaxed ifeq ($(BUILD),openmp) FFLAGS += -openmp LDFLAGS += -openmp endif endif endif ifneq ($(BUILD),openmp) FFLAGS += -stand f03 endif endif #ifort #=================================================================== ifeq ($(FC),gfortran) CC = gcc FFLAGS = -fimplicit-none -ffree-form -J$(OUTDIR) FPPFLAGS = -xf77-cpp-input -I $(OUTDIR) ifeq ($(BUILD),debug) FFLAGS += -g -fbounds-check FFLAGS += -Wunused-parameter -Wunused-variable -Wuninitialized else FFLAGS += -O2 endif endif #gfortran #=================================================================== ifeq ($(FFLAGS),) $(error unknown compiler) endif
Good C programming generally includes status return values for all functions that can produce an error, and proper code should check the error status from every call. Checking and passing back status codes in a call hierarchy can add overhead.
C++ removes the overhead by error handler support that can catch all errors in a hierarchy in one place. Unfortunately, making the errors recoverable also adds overhead, and the throw/catch mechanism can become quite complex for the compiler to handle,
In procedural code, the end result is normally aborted program execution, so all of the error-handling hierarchy is an unnecessary hassle. In this case, the most efficient error-handling system is to simply stop at the point of the error, possibly calling a routine to print information about the error context.
One approach is to make status return codes an optional argument. If the status return is present, the caller can decide how to handle the error. If it is absent, abort with an error message. This is how many Fortran intrinsics work, and it is an effective design that lets the caller choose either a simple procedural method, or a some form of error handling.