gfortran.texi

gcc-fortran,linux使用fortran的编译软件。很好用的。

@node Hollerith constants support
@section Hollerith constants support
@cindex Hollerith constants

A Hollerith constant is a string of characters preceded by the letter @samp{H}
or @samp{h}, and there must be an literal, unsigned, nonzero default integer
constant indicating the number of characters in the string. Hollerith constants
are stored as byte strings, one character per byte.

@command{gfortran} supports Hollerith constants. They can be used as the right
hands in the @code{DATA} statement and @code{ASSIGN} statement, also as the
arguments. The left hands can be of Integer, Real, Complex and Logical type.
The constant will be padded or truncated to fit the size of left hand.

Valid Hollerith constants examples:
@smallexample
complex*16 x(2)
data x /16Habcdefghijklmnop, 16Hqrstuvwxyz012345/
call foo (4H abc)
x(1) = 16Habcdefghijklmnop
@end smallexample

Invalid Hollerith constants examples:
@smallexample
integer*4 a
a = 8H12345678 ! The Hollerith constant is too long. It will be truncated.
a = 0H         ! At least one character needed.
@end smallexample

@node Cray pointers
@section Cray pointers
@cindex Cray pointers

Cray pointers are part of a non-standard extension that provides a
C-like pointer in Fortran.  This is accomplished through a pair of
variables: an integer "pointer" that holds a memory address, and a
"pointee" that is used to dereference the pointer.

Pointer/pointee pairs are declared in statements of the form:
@smallexample
        pointer ( <pointer> , <pointee> )
@end smallexample
or,
@smallexample
        pointer ( <pointer1> , <pointee1> ), ( <pointer2> , <pointee2> ), ...
@end smallexample
The pointer is an integer that is intended to hold a memory address.
The pointee may be an array or scalar.  A pointee can be an assumed
size array -- that is, the last dimension may be left unspecified by
using a '*' in place of a value -- but a pointee cannot be an assumed
shape array.  No space is allocated for the pointee.

The pointee may have its type declared before or after the pointer
statement, and its array specification (if any) may be declared
before, during, or after the pointer statement.  The pointer may be
declared as an integer prior to the pointer statement.  However, some
machines have default integer sizes that are different than the size
of a pointer, and so the following code is not portable:
@smallexample
        integer ipt
        pointer (ipt, iarr)
@end smallexample
If a pointer is declared with a kind that is too small, the compiler
will issue a warning; the resulting binary will probably not work
correctly, because the memory addresses stored in the pointers may be
truncated.  It is safer to omit the first line of the above example;
if explicit declaration of ipt's type is omitted, then the compiler
will ensure that ipt is an integer variable large enough to hold a
pointer.

Pointer arithmetic is valid with Cray pointers, but it is not the same
as C pointer arithmetic.  Cray pointers are just ordinary integers, so
the user is responsible for determining how many bytes to add to a
pointer in order to increment it.  Consider the following example:
@smallexample
        real target(10)
        real pointee(10)
        pointer (ipt, pointee)
        ipt = loc (target)
        ipt = ipt + 1       
@end smallexample
The last statement does not set ipt to the address of
@code{target(1)}, as one familiar with C pointer arithmetic might
expect.  Adding 1 to ipt just adds one byte to the address stored in
ipt.

Any expression involving the pointee will be translated to use the
value stored in the pointer as the base address.

To get the address of elements, this extension provides an intrinsic
function loc(), loc() is essentially the C '&' operator, except the
address is cast to an integer type:
@smallexample
        real ar(10)
        pointer(ipt, arpte(10))
        real arpte
        ipt = loc(ar)  ! Makes arpte is an alias for ar
        arpte(1) = 1.0 ! Sets ar(1) to 1.0
@end smallexample
The pointer can also be set by a call to a malloc-type
function.  There is no malloc intrinsic implemented as part of the
Cray pointer extension, but it might be a useful future addition to
@command{gfortran}.  Even without an intrinsic malloc function,
dynamic memory allocation can be combined with Cray pointers by
calling a short C function:
@smallexample
mymalloc.c:

        void mymalloc_(void **ptr, int *nbytes)
        @{
            *ptr = malloc(*nbytes);
            return;
        @}

caller.f:

        program caller
        integer ipinfo;
        real*4 data
        pointer (ipdata, data(1024))
        call mymalloc(ipdata,4*1024)
        end
@end smallexample
Cray pointees often are used to alias an existing variable.  For
example:
@smallexample
        integer target(10)
        integer iarr(10)
        pointer (ipt, iarr)
        ipt = loc(target)
@end smallexample
As long as ipt remains unchanged, iarr is now an alias for target.
The optimizer, however, will not detect this aliasing, so it is unsafe
to use iarr and target simultaneously.  Using a pointee in any way
that violates the Fortran aliasing rules or assumptions is illegal.
It is the user's responsibility to avoid doing this; the compiler
works under the assumption that no such aliasing occurs.

Cray pointers will work correctly when there is no aliasing (i.e.,
when they're used to access a dynamically allocated block of memory),
and also in any routine where a pointee is used, but any variable with
which it shares storage is not used.  Code that violates these rules
may not run as the user intends.  This is not a bug in the optimizer;
any code that violates the aliasing rules is illegal.  (Note that this
is not unique to gfortran; any Fortran compiler that supports Cray
pointers will ``incorrectly'' optimize code with illegal aliasing.)

There are a number of restrictions on the attributes that can be
applied to Cray pointers and pointees.  Pointees may not have the
attributes ALLOCATABLE, INTENT, OPTIONAL, DUMMY, TARGET, EXTERNAL,
INTRINSIC, or POINTER.  Pointers may not have the attributes
DIMENSION, POINTER, TARGET, ALLOCATABLE, EXTERNAL, or INTRINSIC.
Pointees may not occur in more than one pointer statement.  A pointee
cannot be a pointer.  Pointees cannot occur in equivalence, common, or
data statements.

A pointer may be modified during the course of a program, and this
will change the location to which the pointee refers.  However, when
pointees are passed as arguments, they are treated as ordinary
variables in the invoked function.  Subsequent changes to the pointer
will not change the base address of the array that was passed.

@node CONVERT specifier
@section CONVERT specifier
@cindex CONVERT specifier

gfortran allows the conversion of unformatted data between little-
and big-endian representation to facilitate moving of data
between different systems.  The conversion can be indicated with
the @code{CONVERT} specifier on the @code{OPEN} statement.
@xref{GFORTRAN_CONVERT_UNIT}, for an alternative way of specifying
the data format via an environment variable.

Valid values for @code{CONVERT} are:
@itemize @w{}
@item @code{CONVERT='NATIVE'} Use the native format.  This is the default.
@item @code{CONVERT='SWAP'} Swap between little- and big-endian.
@item @code{CONVERT='LITTLE_ENDIAN'} Use the little-endian representation
        for unformatted files.
@item @code{CONVERT='BIG_ENDIAN'} Use the big-endian representation for
        unformatted files.
@end itemize

Using the option could look like this:
@smallexample
  open(file='big.dat',form='unformatted',access='sequential', &
       convert='big_endian')
@end smallexample

The value of the conversion can be queried by using
@code{INQUIRE(CONVERT=ch)}.  The values returned are
@code{'BIG_ENDIAN'} and @code{'LITTLE_ENDIAN'}.

@code{CONVERT} works between big- and little-endian for
@code{INTEGER} values of all supported kinds and for @code{REAL}
on IEEE sytems of kinds 4 and 8.  Conversion between different
``extended double'' types on different architectures such as
m68k and x86_64, which gfortran
supports as @code{REAL(KIND=10)} will probably not work.

@emph{Note that the values specified via the GFORTRAN_CONVERT_UNIT
environment variable will override the CONVERT specifier in the
open statement}.  This is to give control over data formats to
a user who does not have the source code of his program available.

Using anything but the native representation for unformatted data
carries a significant speed overhead.  If speed in this area matters
to you, it is best if you use this only for data that needs to be
portable.

@c ---------------------------------------------------------------------
@include intrinsic.texi
@c ---------------------------------------------------------------------

@c ---------------------------------------------------------------------
@c Contributing
@c ---------------------------------------------------------------------

@node Contributing
@chapter Contributing
@cindex 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 @command{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.

@menu
* Contributors::
* Projects::
@end menu


@node Contributors
@section Contributors to GNU Fortran 95
@cindex Contributors
@cindex Credits
@cindex Authors

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

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

@itemize @minus
@item Andy Vaught
@item Katherine Holcomb
@item Tobias Schl黷er
@item Steven Bosscher
@item Toon Moene
@item Tim Prince
@item Niels Kristian Bech Jensen
@item Steven Johnson
@item Paul Brook
@item Feng Wang
@item Bud Davis
@item Paul Thomas
@item Fran鏾is-Xavier Coudert
@item Steve Kargl
@item Jerry Delisle
@item Janne Blomqvist
@item Erik Edelmann
@item Thomas Koenig
@item Asher Langton
@end itemize

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

@itemize @minus
@item Erik Schnetter
@item Bill Clodius
@item Kate Hedstrom
@end itemize

Many other individuals have helped debug,
test and improve @command{gfortran} over the past few 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.


@node Projects
@section Projects

@table @emph

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

@item 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.

@item Smaller projects (``bug'' fixes):
  @itemize @minus
  @item Allow init exprs to be numbers raised to integer powers.
  @item Implement correct rounding.
  @item Implement F restrictions on Fortran 95 syntax.
  @item See about making Emacs-parsable error messages.
  @end itemize
@end table

If you wish to work on the runtime libraries,
please contact a project maintainer.
@c TODO: email!


@c ---------------------------------------------------------------------
@c Standards
@c ---------------------------------------------------------------------

@node Standards
@chapter Standards
@cindex 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 of and extensions to
the Fortran language.  These include ANSI Fortran 77, ISO Fortran 90,
ISO Fortran 2003 and OpenMP.

@menu
* Fortran 2003 status::
@end menu

@node Fortran 2003 status
@section Fortran 2003 status

Although @command{gfortran} focuses on implementing the Fortran 95
standard for the time being, a few Fortran 2003 features are currently
available.

@itemize
@item 
Intrinsics @code{command_argument_count}, @code{get_command},
@code{get_command_argument}, and @code{get_environment_variable}.

@item 
@cindex Array constructors
@cindex @code{[...]}
Array constructors using square brackets. That is, @code{[...]} rather
than @code{(/.../)}.

@item
@cindex @code{FLUSH} statement
@code{FLUSH} statement.

@item
@cindex @code{IOMSG=} specifier
@code{IOMSG=} specifier for I/O statements.

@item
@cindex @code{ENUM} statement
@cindex @code{ENUMERATOR} statement
@cindex @command{-fshort-enums}
Support for the declaration of enumeration constants via the
@code{ENUM} and @code{ENUMERATOR} statements.  Interoperability with
@command{gcc} is guaranteed also for the case where the
@command{-fshort-enums} command line option is given.

@end itemize


@c ---------------------------------------------------------------------
@c GNU General Public License
@c ---------------------------------------------------------------------

@include gpl.texi



@c ---------------------------------------------------------------------
@c GNU Free Documentation License
@c ---------------------------------------------------------------------

@include fdl.texi



@c ---------------------------------------------------------------------
@c Funding Free Software
@c ---------------------------------------------------------------------

@include funding.texi

@c ---------------------------------------------------------------------
@c Index
@c ---------------------------------------------------------------------

@node Index
@unnumbered Index

@printindex cp

@bye