     [file gcc-common.texi not included]

This file documents the use and the internals of the GNU Fortran 95 compiler, (gfortran).

Published by the Free Software Foundation 59 Temple Place - Suite 330 Boston, MA 02111-1307 USA

Copyright © 1999-2004 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being ``GNU General Public License'' and ``Funding Free Software'', the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below).  A copy of the license is included in the section entitled ``GNU Free Documentation License''.

(a) The FSF's Front-Cover Text is:

A GNU Manual

(b) The FSF's Back-Cover Text is:

You have freedom to copy and modify this GNU Manual, like GNU software.  Copies published by the Free Software Foundation raise funds for GNU development.

Contributed by Steven Bosscher (s.bosscher@gcc.gnu.org).

Introduction
************

This manual documents the use of gfortran, the GNU Fortran 95 compiler. You can find in this manual how to invoke gfortran, as well as its features and incompatibilities.

     [file gpl.texi not included]

     [file fdl.texi not included]

     [file funding.texi not included]

Getting Started
***************

Gfortran is the GNU Fortran 95 compiler front end, designed initially as a free replacement for, or alternative to, the unix f95 command; gfortran is command you'll use to invoke the compiler.

Gfortran is still in an early state of development. gfortran can generate code for most constructs and expressions, but much work remains to be done.

When gfortran is finished, it will do everything you expect from any decent compiler:

  * Read a user's program, stored in a file and containing instructions written in Fortran 77, Fortran 90 or Fortran 95. This file contains source code.

  * Translate the user's program into instructions a computer can carry out more quickly than it takes to translate the instructions in the first place.  The result after compilation of a program is machine code, code designed to be efficiently translated and processed by a machine such as your computer. Humans usually aren't as good writing machine code as they are at writing Fortran (or C++, Ada, or Java), because is easy to make tiny mistakes writing machine code.

  * Provide the user with information about the reasons why the compiler is unable to create a binary from the source code. Usually this will be the case if the source code is flawed. When writing Fortran, it is easy to make big mistakes. The Fortran 90 requires that the compiler can point out mistakes to the user. An incorrect usage of the language causes an error message.

     The compiler will also attempt to diagnose cases where the user's program contains a correct usage of the language, but instructs the computer to do something questionable. This kind of diagnostics message is called a warning message.

  * Provide optional information about the translation passes from the source code to machine code. This can help a user of the compiler to find the cause of certain bugs which may not be obvious in the source code, but may be more easily found at a lower level compiler output. It also helps developers to find bugs in the compiler itself.

  * Provide information in the generated machine code that can make it easier to find bugs in the program (using a debugging tool, called a debugger, such as the GNU Debugger gdb).

  * Locate and gather machine code already generated to perform actions requested by statements in the user's program. This machine code is organized into modules and is located and linked to the user program.

Gfortran consists of several components:

  * A version of the gcc command (which also might be installed as the system's cc command) that also understands and accepts Fortran source code. The gcc command is the driver program for all the languages in the GNU Compiler Collection (GCC); With gcc, you can compiler the source code of any language for which a front end is available in GCC.

  * The gfortran command itself, which also might be installed as the system's f95 command. gfortran is just another driver program, but specifically for the Fortran 95 compiler only. The difference with gcc is that gfortran will automatically link the correct libraries to your program.

  * A collection of run-time libraries. These libraries contains the machine code needed to support capabilities of the Fortran language that are not directly provided by the machine code generated by the gfortran compilation phase, such as intrinsic functions and subroutines, and routines for interaction with files and the operating system.

  * The Fortran compiler itself, (f951). This is the gfortran parser and code generator, linked to and interfaced with the GCC backend library. f951 ``translates'' the source code to assembler code.  You would typically not use this program directly; instead, the gcc or gfortran driver programs will call it for you.

GFORTRAN and GCC
****************

GCC used to be the GNU ``C'' Compiler, but is now known as the GNU Compiler Collection. GCC provides the GNU system with a very versatile compiler middle end (shared optimization passes), and with back ends (code generators) for many different computer architectures and operating systems. The code of the middle end and back end are shared by all compiler front ends that are in the GNU Compiler Collection.

A GCC front end is essentially a source code parser and a pass to generate a representation of the semantics of the program in the source code in the GCC language independent intermediate language, called GENERIC.

The parser takes a source file written in a particular computer language, reads and parses it, and tries to make sure that the source code conforms to the language rules. Once the correctness of a program has been established, the compiler will build a data structure known as the Abstract Syntax tree, or just AST or ``tree'' for short. This data structure represents the whole program or a subroutine or a function. The ``tree'' is passed to the GCC middle end, which will perform optimization passes on it, pass the optimized AST and generate assembly for the program unit.

Different phases in this translation process can be, and in fact are merged in many compiler front ends. GNU Fortran 95 has a strict separation between the parser and code generator.

The goal of the gfortran project is to build a new front end for GCC: A Fortran 95 front end. In a non-gfortran installation, gcc will not be able to compile Fortran 95 source code (only the ``C'' front end has to be compiled if you want to build GCC, all other languages are optional). If you build GCC with gfortran, gcc will recognize .f/.f90/.f95 source files and accepts Fortran 95 specific command line options.

GFORTRAN and G77
****************

Why do we write a compiler front end from scratch? There's a fine Fortran 77 compiler in the GNU Compiler Collection that accepts some features of the Fortran 90 standard as extensions. Why not start from there and revamp it?

One of the reasons is that Craig Burley, the author of G77, has decided to stop working on the G77 front end. On Craig explains the reasons for his decision to stop working on G77 (http://world.std.com/~burley/g77-why.html) in one of the pages in his homepage. Among the reasons is a lack of interest in improvements to g77. Users appear to be quite satisfied with g77 as it is. While g77 is still being maintained (by Toon Moene), it is unlikely that sufficient people will be willing to completely rewrite the existing code.

But there are other reasons to start from scratch. Many people, including Craig Burley, no longer agreed with certain design decisions in the G77 front end. Also, the interface of g77 to the back end is written in a style which is confusing and not up to date on recommended practice. In fact, a full rewrite had already been planned for GCC 3.0.

When Craig decided to stop, it just seemed to be a better idea to start a new project from scratch, because it was expected to be easier to maintain code we develop ourselves than to do a major overhaul of g77 first, and then build a Fortran 95 compiler out of it.

     [file invoke.texi not included]

Project Status
**************

     As soon as gfortran can parse all of the statements correctly, it will be in the ``larva'' state. When we generate code, the ``puppa'' state. When gfortran is done, we'll see if it will be a beautiful butterfly, or just a big bug....

     --Andy Vaught, April 2000

The start of the GNU Fortran 95 project was announced on the GCC homepage in March 18, 2000 (even though Andy had already been working on it for a while, or course).

Gfortran 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.

Compiler Status
===============

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.

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.

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.)

The IO library is still under development.  The following features should be usable for real programs:

  - List directed

  - Unformatted sequential

Usable with bugs:

  - Formatted sequential ('T' edit descriptor, and others)

  - Namelist (can read a namelist that it writes, but not free-form)

Not recommended:

  - Unformatted direct access

  - Formatted direct access

Many Fortran programs only use a small subset of the available IO capabilities, so your mileage may vary.

Proposed Extensions
===================

Here's a list of proposed extensions for gfortran, in no particular order.  Most of these are necessary to be fully compatible with existing Fortran compilers, but they are not part of the official J3 Fortran 95 standard.

Compiler extensions:
--------------------

  * Flag for defining the kind number for default logicals.

  * User-specified alignment rules for structures.

  * Flag to generate a Makefile info.

  * Automatically extend single precision constants to double.

  * Cray pointers (this was high on the g77 wishlist).

  * Compile code that conserves memory by dynamically allocating common and module storage either on stack or heap.

  * Flag to cause the compiler to distinguish between upper and lower case names.  The Fortran 95 standard does not distinguish them.

  * Compile switch for changing the interpretation of a backslash from a character to ``C''-style escape characters.

  * Compile flag to generate code for array conformance checking (suggest -CC).

  * User control of symbol names (underscores, etc).

  * Compile setting for maximum size of stack frame size before spilling parts to static or heap.

  * Flag to force local variables into static space.

  * Flag to force local variables onto stack.

  * Flag to compile lines beginning with ``D''.

  * Flag to ignore lines beginning with ``D''.

  * Flag for maximum errors before ending compile.

  * 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.

  * Allow setting default unit number.

  * Option to initialize of otherwise uninitialized integer and floating point variables.

  * Support for OpenMP directives.  This also requires support from the runtime library and the rest of the compiler.

  * 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.

Environment Options
-------------------

  * Pluggable library modules for random numbers, linear algebra. LA should use BLAS calling conventions.

  * Environment variables controlling actions on arithmetic exceptions like overflow, underflow, precision loss -- Generate NaN, abort, default. action.

  * Set precision for fp units that support it (i387).

  * Variables for setting fp rounding mode.

  * Support old style namelists ending in $end or &end.

  * Variable to fill uninitialized variables with a user-defined bit pattern.

  * Environment variable controlling filename that is opened for that unit number.

  * Environment variable to clear/trash memory being freed.

  * Environment variable to control tracing of allocations and frees.

  * Environment variable to display allocated memory at normal program end.

  * Environment variable for filename for * IO-unit.

  * Environment variable for temporary file directory.

  * Environment variable forcing standard output to be line buffered (unix).

  * Variable for swapping endianness during unformatted read.

  * Variable for swapping Endianness during unformatted write.

Extensions
**********

gfortran implements a number of extensions over standard Fortran. This chapter contains information on their syntax and meaning.

Old-style kind specifications
=============================

gfortran allows old-style kind specifications in declarations. These look like:

           TYPESPEC*k x,y,z

where TYPESPEC is a basic type, and where k is a valid kind number for that type. The statement then declares x, y and z to be of type TYPESPEC with kind k. In other words, it is equivalent to the standard conforming declaration

           TYPESPEC(k) x,y,z

Old-style variable initialization
=================================

gfortran allows old-style initialization of variables of the form:

           INTEGER*4 i/1/,j/2/
           REAL*8 x(2,2) /3*0.,1./

These are only allowed in declarations without double colons (::), as these were introduced in Fortran 90 which also introduced a new syntax for variable initializations. The syntax for the individual initializers is as for the DATA statement, but unlike in a DATA statement, an initializer only applies to the variable immediately preceding. In other words, something like INTEGER I,J/2,3/ is not valid.

Examples of standard conforming code equivalent to the above example, are:

     ! Fortran 90
           INTEGER(4) :: i = 1, j = 2
           REAL(8) :: x(2,2) = RESHAPE((/0.,0.,0.,1./),SHAPE(x))
     ! Fortran 77
           INTEGER  i, j
           DOUBLE PRECISION x(2,2)
           DATA i,j,x /1,2,3*0.,1./

Contributing
************

Free software is only possible if people contribute to efforts to create it. We're always in need of more people helping out with ideas and comments, writing documentation and contributing code.

If you want to contribute to GNU Fortran 95, have a look at the long lists of projects you can take on. Some of these projects are small, some of them are large; some are completely orthogonal to the rest of what is happening on gfortran, but others are ``mainstream'' projects in need of enthusiastic hackers. All of these projects are important! We'll eventually get around to the things here, but they are also things doable by someone who is willing and able.

Contributors to GNU Fortran 95
==============================

Most of the parser was hand-crafted by Andy Vaught, who is also the initiator of the whole project.  Thanks Andy! Most of the interface with GCC was written by Paul Brook.

The following individuals have contributed code and/or ideas and significant help to the gfortran project (in no particular order):

  - Andy Vaught

  - Katherine Holcomb

  - Tobias Schlüter

  - Steven Bosscher

  - Toon Moene

  - Tim Prince

  - Niels Kristian Bech Jensen

  - Steven Johnson

  - Paul Brook

  - Feng Wang

  - Bud Davis

The following people have contributed bug reports, smaller or larger patches, and much needed feedback and encouragement for the gfortran project:

  - Erik Schnetter

  - Bill Clodius

  - Kate Hedstrom

Many other individuals have helped debug, test and improve gfortran over the past two years, and we welcome you to do the same! If you already have done so, and you would like to see your name listed in the list above, please contact us.

Projects
========

Help build the test suite
     Solicit more code for donation to the test suite. We can keep code private on request.

Bug hunting/squishing
     Find bugs and write more test cases! Test cases are especially very welcome, because it allows us to concentrate on fixing bugs instead of isolating them.

Smaller projects (``bug'' fixes):

       - Allow init exprs to be numbers raised to integer powers.

       - Implement correct rounding.

       - Implement F restrictions on Fortran 95 syntax.

       - See about making Emacs-parsable error messages.

If you wish to work on the runtime libraries, please contact a project maintainer.

Standards
*********

The GNU Fortran 95 Compiler aims to be a conforming implementation of ISO/IEC 1539:1997 (Fortran 95).

In the future it may also support other variants and extensions to the Fortran language.  This includes ANSI Fortran 77, Fortran 90, Fortran 2000 (not yet finalized), and OpenMP.