This is g77.info, produced by makeinfo version 4.0 from g77.texi.

INFO-DIR-SECTION Programming
START-INFO-DIR-ENTRY
* g77: (g77).                  The GNU Fortran compiler.
END-INFO-DIR-ENTRY
   This file documents the use and the internals of the GNU Fortran
(`g77') compiler.  It corresponds to the GCC-3.0 version of `g77'.

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

   Copyright (C) 1995,1996,1997,1998,1999,2000,2001 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 James Craig Burley (<craig@jcb-sc.com>).  Inspired by
a first pass at translating `g77-0.5.16/f/DOC' that was contributed to
Craig by David Ronis (<ronis@onsager.chem.mcgill.ca>).


File: g77.info,  Node: Floating-point precision,  Next: Inconsistent Calling Sequences,  Prev: Large File Unit Numbers,  Up: Working Programs

Floating-point precision
------------------------

   If your program depends on exact IEEE 754 floating-point handling it
may help on some systems--specifically x86 or m68k hardware--to use the
`-ffloat-store' option or to reset the precision flag on the
floating-point unit.  *Note Optimize Options::.

   However, it might be better simply to put the FPU into double
precision mode and not take the performance hit of `-ffloat-store'.  On
x86 and m68k GNU systems you can do this with a technique similar to
that for turning on floating-point exceptions (*note Floating-point
Exception Handling::).  The control word could be set to double
precision by some code like this one:
     #include <fpu_control.h>
     {
       fpu_control_t cw = (_FPU_DEFAULT & ~_FPU_EXTENDED) | _FPU_DOUBLE;
       _FPU_SETCW(cw);
     }
   (It is not clear whether this has any effect on the operation of the
GNU maths library, but we have no evidence of it causing trouble.)

   Some targets (such as the Alpha) may need special options for full
IEEE conformance.  *Note Hardware Models and Configurations:
(gcc)Submodel Options.


File: g77.info,  Node: Inconsistent Calling Sequences,  Prev: Floating-point precision,  Up: Working Programs

Inconsistent Calling Sequences
------------------------------

   Code containing inconsistent calling sequences in the same file is
normally rejected--see *Note GLOBALS::.  (Use, say, `ftnchek' to ensure
consistency across source files.  *Note Generating Skeletons and
Prototypes with `f2c': f2c Skeletons and Prototypes.)

   Mysterious errors, which may appear to be code generation problems,
can appear specifically on the x86 architecture with some such
inconsistencies.  On x86 hardware, floating-point return values of
functions are placed on the floating-point unit's register stack, not
the normal stack.  Thus calling a `REAL' or `DOUBLE PRECISION'
`FUNCTION' as some other sort of procedure, or vice versa, scrambles
the floating-point stack.  This may break unrelated code executed
later.  Similarly if, say, external C routines are written incorrectly.


File: g77.info,  Node: Overly Convenient Options,  Next: Faster Programs,  Prev: Working Programs,  Up: Collected Fortran Wisdom

Overly Convenient Command-line Options
======================================

   These options should be used only as a quick-and-dirty way to
determine how well your program will run under different compilation
models without having to change the source.  Some are more problematic
than others, depending on how portable and maintainable you want the
program to be (and, of course, whether you are allowed to change it at
all is crucial).

   You should not continue to use these command-line options to compile
a given program, but rather should make changes to the source code:

`-finit-local-zero'
     (This option specifies that any uninitialized local variables and
     arrays have default initialization to binary zeros.)

     Many other compilers do this automatically, which means lots of
     Fortran code developed with those compilers depends on it.

     It is safer (and probably would produce a faster program) to find
     the variables and arrays that need such initialization and provide
     it explicitly via `DATA', so that `-finit-local-zero' is not
     needed.

     Consider using `-Wuninitialized' (which requires `-O') to find
     likely candidates, but do not specify `-finit-local-zero' or
     `-fno-automatic', or this technique won't work.

`-fno-automatic'
     (This option specifies that all local variables and arrays are to
     be treated as if they were named in `SAVE' statements.)

     Many other compilers do this automatically, which means lots of
     Fortran code developed with those compilers depends on it.

     The effect of this is that all non-automatic variables and arrays
     are made static, that is, not placed on the stack or in heap
     storage.  This might cause a buggy program to appear to work
     better.  If so, rather than relying on this command-line option
     (and hoping all compilers provide the equivalent one), add `SAVE'
     statements to some or all program unit sources, as appropriate.
     Consider using `-Wuninitialized' (which requires `-O') to find
     likely candidates, but do not specify `-finit-local-zero' or
     `-fno-automatic', or this technique won't work.

     The default is `-fautomatic', which tells `g77' to try and put
     variables and arrays on the stack (or in fast registers) where
     possible and reasonable.  This tends to make programs faster.

     _Note:_ Automatic variables and arrays are not affected by this
     option.  These are variables and arrays that are _necessarily_
     automatic, either due to explicit statements, or due to the way
     they are declared.  Examples include local variables and arrays
     not given the `SAVE' attribute in procedures declared `RECURSIVE',
     and local arrays declared with non-constant bounds (automatic
     arrays).  Currently, `g77' supports only automatic arrays, not
     `RECURSIVE' procedures or other means of explicitly specifying
     that variables or arrays are automatic.

`-fGROUP-intrinsics-hide'
     Change the source code to use `EXTERNAL' for any external procedure
     that might be the name of an intrinsic.  It is easy to find these
     using `-fGROUP-intrinsics-disable'.


File: g77.info,  Node: Faster Programs,  Prev: Overly Convenient Options,  Up: Collected Fortran Wisdom

Faster Programs
===============

   Aside from the usual `gcc' options, such as `-O', `-ffast-math', and
so on, consider trying some of the following approaches to speed up
your program (once you get it working).

* Menu:

* Aligned Data::
* Prefer Automatic Uninitialized Variables::
* Avoid f2c Compatibility::
* Use Submodel Options::


File: g77.info,  Node: Aligned Data,  Next: Prefer Automatic Uninitialized Variables,  Up: Faster Programs

Aligned Data
------------

   On some systems, such as those with Pentium Pro CPUs, programs that
make heavy use of `REAL(KIND=2)' (`DOUBLE PRECISION') might run much
slower than possible due to the compiler not aligning these 64-bit
values to 64-bit boundaries in memory.  (The effect also is present,
though to a lesser extent, on the 586 (Pentium) architecture.)

   The Intel x86 architecture generally ensures that these programs will
work on all its implementations, but particular implementations (such
as Pentium Pro) perform better with more strict alignment.  (Such
behavior isn't unique to the Intel x86 architecture.)  Other
architectures might _demand_ 64-bit alignment of 64-bit data.

   There are a variety of approaches to use to address this problem:

   * Order your `COMMON' and `EQUIVALENCE' areas such that the
     variables and arrays with the widest alignment guidelines come
     first.

     For example, on most systems, this would mean placing
     `COMPLEX(KIND=2)', `REAL(KIND=2)', and `INTEGER(KIND=2)' entities
     first, followed by `REAL(KIND=1)', `INTEGER(KIND=1)', and
     `LOGICAL(KIND=1)' entities, then `INTEGER(KIND=6)' entities, and
     finally `CHARACTER' and `INTEGER(KIND=3)' entities.

     The reason to use such placement is it makes it more likely that
     your data will be aligned properly, without requiring you to do
     detailed analysis of each aggregate (`COMMON' and `EQUIVALENCE')
     area.

     Specifically, on systems where the above guidelines are
     appropriate, placing `CHARACTER' entities before `REAL(KIND=2)'
     entities can work just as well, but only if the number of bytes
     occupied by the `CHARACTER' entities is divisible by the
     recommended alignment for `REAL(KIND=2)'.

     By ordering the placement of entities in aggregate areas according
     to the simple guidelines above, you avoid having to carefully
     count the number of bytes occupied by each entity to determine
     whether the actual alignment of each subsequent entity meets the
     alignment guidelines for the type of that entity.

     If you don't ensure correct alignment of `COMMON' elements, the
     compiler may be forced by some systems to violate the Fortran
     semantics by adding padding to get `DOUBLE PRECISION' data
     properly aligned.  If the unfortunate practice is employed of
     overlaying different types of data in the `COMMON' block, the
     different variants of this block may become misaligned with
     respect to each other.  Even if your platform doesn't require
     strict alignment, `COMMON' should be laid out as above for
     portability.  (Unfortunately the FORTRAN 77 standard didn't
     anticipate this possible requirement, which is
     compiler-independent on a given platform.)

   * Use the (x86-specific) `-malign-double' option when compiling
     programs for the Pentium and Pentium Pro architectures (called 586
     and 686 in the `gcc' configuration subsystem).  The warning about
     this in the `gcc' manual isn't generally relevant to Fortran, but
     using it will force `COMMON' to be padded if necessary to align
     `DOUBLE PRECISION' data.

     When `DOUBLE PRECISION' data is forcibly aligned in `COMMON' by
     `g77' due to specifying `-malign-double', `g77' issues a warning
     about the need to insert padding.

     In this case, each and every program unit that uses the same
     `COMMON' area must specify the same layout of variables and their
     types for that area and be compiled with `-malign-double' as well.
     `g77' will issue warnings in each case, but as long as every
     program unit using that area is compiled with the same warnings,
     the resulting object files should work when linked together unless
     the program makes additional assumptions about `COMMON' area
     layouts that are outside the scope of the FORTRAN 77 standard, or
     uses `EQUIVALENCE' or different layouts in ways that assume no
     padding is ever inserted by the compiler.

   * Ensure that `crt0.o' or `crt1.o' on your system guarantees a 64-bit
     aligned stack for `main()'.  The recent one from GNU (`glibc2')
     will do this on x86 systems, but we don't know of any other x86
     setups where it will be right.  Read your system's documentation
     to determine if it is appropriate to upgrade to a more recent
     version to obtain the optimal alignment.

   Progress is being made on making this work "out of the box" on
future versions of `g77', `gcc', and some of the relevant operating
systems (such as GNU/Linux).

   A package that tests the degree to which a Fortran compiler (such as
`g77') aligns 64-bit floating-point variables and arrays is available
at `ftp://alpha.gnu.org/gnu/g77/align/'.


File: g77.info,  Node: Prefer Automatic Uninitialized Variables,  Next: Avoid f2c Compatibility,  Prev: Aligned Data,  Up: Faster Programs

Prefer Automatic Uninitialized Variables
----------------------------------------

   If you're using `-fno-automatic' already, you probably should change
your code to allow compilation with `-fautomatic' (the default), to
allow the program to run faster.

   Similarly, you should be able to use `-fno-init-local-zero' (the
default) instead of `-finit-local-zero'.  This is because it is rare
that every variable affected by these options in a given program
actually needs to be so affected.

   For example, `-fno-automatic', which effectively `SAVE's every local
non-automatic variable and array, affects even things like `DO'
iteration variables, which rarely need to be `SAVE'd, and this often
reduces run-time performances.  Similarly, `-fno-init-local-zero'
forces such variables to be initialized to zero--when `SAVE'd (such as
when `-fno-automatic'), this by itself generally affects only startup
time for a program, but when not `SAVE'd, it can slow down the
procedure every time it is called.

   *Note Overly Convenient Command-Line Options: Overly Convenient
Options, for information on the `-fno-automatic' and
`-finit-local-zero' options and how to convert their use into selective
changes in your own code.


File: g77.info,  Node: Avoid f2c Compatibility,  Next: Use Submodel Options,  Prev: Prefer Automatic Uninitialized Variables,  Up: Faster Programs

Avoid f2c Compatibility
-----------------------

   If you aren't linking with any code compiled using `f2c', try using
the `-fno-f2c' option when compiling _all_ the code in your program.
(Note that `libf2c' is _not_ an example of code that is compiled using
`f2c'--it is compiled by a C compiler, typically `gcc'.)


File: g77.info,  Node: Use Submodel Options,  Prev: Avoid f2c Compatibility,  Up: Faster Programs

Use Submodel Options
--------------------

   Using an appropriate `-m' option to generate specific code for your
CPU may be worthwhile, though it may mean the executable won't run on
other versions of the CPU that don't support the same instruction set.
*Note Hardware Models and Configurations: (gcc)Submodel Options.  For
instance on an x86 system the compiler might have been built--as shown
by `g77 -v'--for the target `i386-pc-linux-gnu', i.e. an `i386' CPU.
In that case to generate code best optimized for a Pentium you could
use the option `-march=pentium'.

   For recent CPUs that don't have explicit support in the released
version of `gcc', it _might_ still be possible to get improvements with
certain `-m' options.

   `-fomit-frame-pointer' can help performance on x86 systems and
others.  It will, however, inhibit debugging on the systems on which it
is not turned on anyway by `-O'.


File: g77.info,  Node: Trouble,  Next: Open Questions,  Prev: Collected Fortran Wisdom,  Up: Top

Known Causes of Trouble with GNU Fortran
****************************************

   This section describes known problems that affect users of GNU
Fortran.  Most of these are not GNU Fortran bugs per se--if they were,
we would fix them.  But the result for a user might be like the result
of a bug.

   Some of these problems are due to bugs in other software, some are
missing features that are too much work to add, and some are places
where people's opinions differ as to what is best.

   To find out about major bugs discovered in the current release and
possible workarounds for them, see `ftp://alpha.gnu.org/g77.plan'.

   (Note that some of this portion of the manual is lifted directly
from the `gcc' manual, with minor modifications to tailor it to users
of `g77'.  Anytime a bug seems to have more to do with the `gcc'
portion of `g77', see *Note Known Causes of Trouble with GNU CC:
(gcc)Trouble.)

* Menu:

* But-bugs::         Bugs really in other programs or elsewhere.
* Known Bugs::       Bugs known to be in this version of `g77'.
* Missing Features:: Features we already know we want to add later.
* Disappointments::  Regrettable things we can't change.
* Non-bugs::         Things we think are right, but some others disagree.
* Warnings and Errors::  Which problems in your code get warnings,
                        and which get errors.


File: g77.info,  Node: But-bugs,  Next: Known Bugs,  Up: Trouble

Bugs Not In GNU Fortran
=======================

   These are bugs to which the maintainers often have to reply, "but
that isn't a bug in `g77'...".  Some of these already are fixed in new
versions of other software; some still need to be fixed; some are
problems with how `g77' is installed or is being used; some are the
result of bad hardware that causes software to misbehave in sometimes
bizarre ways; some just cannot be addressed at this time until more is
known about the problem.

   Please don't re-report these bugs to the `g77' maintainers--if you
must remind someone how important it is to you that the problem be
fixed, talk to the people responsible for the other products identified
below, but preferably only after you've tried the latest versions of
those products.  The `g77' maintainers have their hands full working on
just fixing and improving `g77', without serving as a clearinghouse for
all bugs that happen to affect `g77' users.

   *Note Collected Fortran Wisdom::, for information on behavior of
Fortran programs, and the programs that compile them, that might be
_thought_ to indicate bugs.

* Menu:

* Signal 11 and Friends::  Strange behavior by any software.
* Cannot Link Fortran Programs::  Unresolved references.
* Large Common Blocks::    Problems on older GNU/Linux systems.
* Debugger Problems::      When the debugger crashes.
* NeXTStep Problems::      Misbehaving executables.
* Stack Overflow::         More misbehaving executables.
* Nothing Happens::        Less behaving executables.
* Strange Behavior at Run Time::  Executables misbehaving due to
                            bugs in your program.
* Floating-point Errors::  The results look wrong, but....


File: g77.info,  Node: Signal 11 and Friends,  Next: Cannot Link Fortran Programs,  Up: But-bugs

Signal 11 and Friends
---------------------

   A whole variety of strange behaviors can occur when the software, or
the way you are using the software, stresses the hardware in a way that
triggers hardware bugs.  This might seem hard to believe, but it
happens frequently enough that there exist documents explaining in
detail what the various causes of the problems are, what typical
symptoms look like, and so on.

   Generally these problems are referred to in this document as "signal
11" crashes, because the Linux kernel, running on the most popular
hardware (the Intel x86 line), often stresses the hardware more than
other popular operating systems.  When hardware problems do occur under
GNU/Linux on x86 systems, these often manifest themselves as "signal 11"
problems, as illustrated by the following diagnostic:

     sh# g77 myprog.f
     gcc: Internal compiler error: program f771 got fatal signal 11
     sh#

   It is _very_ important to remember that the above message is _not_
the only one that indicates a hardware problem, nor does it always
indicate a hardware problem.

   In particular, on systems other than those running the Linux kernel,
the message might appear somewhat or very different, as it will if the
error manifests itself while running a program other than the `g77'
compiler.  For example, it will appear somewhat different when running
your program, when running Emacs, and so on.

   How to cope with such problems is well beyond the scope of this
manual.

   However, users of Linux-based systems (such as GNU/Linux) should
review `http://www.bitwizard.nl/sig11/', a source of detailed
information on diagnosing hardware problems, by recognizing their
common symptoms.

   Users of other operating systems and hardware might find this
reference useful as well.  If you know of similar material for another
hardware/software combination, please let us know so we can consider
including a reference to it in future versions of this manual.


File: g77.info,  Node: Cannot Link Fortran Programs,  Next: Large Common Blocks,  Prev: Signal 11 and Friends,  Up: But-bugs

Cannot Link Fortran Programs
----------------------------

   On some systems, perhaps just those with out-of-date (shared?)
libraries, unresolved-reference errors happen when linking
`g77'-compiled programs (which should be done using `g77').

   If this happens to you, try appending `-lc' to the command you use
to link the program, e.g. `g77 foo.f -lc'.  `g77' already specifies
`-lg2c -lm' when it calls the linker, but it cannot also specify `-lc'
because not all systems have a file named `libc.a'.

   It is unclear at this point whether there are legitimately installed
systems where `-lg2c -lm' is insufficient to resolve code produced by
`g77'.

   If your program doesn't link due to unresolved references to names
like `_main', make sure you're using the `g77' command to do the link,
since this command ensures that the necessary libraries are loaded by
specifying `-lg2c -lm' when it invokes the `gcc' command to do the
actual link.  (Use the `-v' option to discover more about what actually
happens when you use the `g77' and `gcc' commands.)

   Also, try specifying `-lc' as the last item on the `g77' command
line, in case that helps.


File: g77.info,  Node: Large Common Blocks,  Next: Debugger Problems,  Prev: Cannot Link Fortran Programs,  Up: But-bugs

Large Common Blocks
-------------------

   On some older GNU/Linux systems, programs with common blocks larger
than 16MB cannot be linked without some kind of error message being
produced.

   This is a bug in older versions of `ld', fixed in more recent
versions of `binutils', such as version 2.6.


File: g77.info,  Node: Debugger Problems,  Next: NeXTStep Problems,  Prev: Large Common Blocks,  Up: But-bugs

Debugger Problems
-----------------

   There are some known problems when using `gdb' on code compiled by
`g77'.  Inadequate investigation as of the release of 0.5.16 results in
not knowing which products are the culprit, but `gdb-4.14' definitely
crashes when, for example, an attempt is made to print the contents of
a `COMPLEX(KIND=2)' dummy array, on at least some GNU/Linux machines,
plus some others.  Attempts to access assumed-size arrays are also
known to crash recent versions of `gdb'.  (`gdb''s Fortran support was
done for a different compiler and isn't properly compatible with `g77'.)


File: g77.info,  Node: NeXTStep Problems,  Next: Stack Overflow,  Prev: Debugger Problems,  Up: But-bugs

NeXTStep Problems
-----------------

   Developers of Fortran code on NeXTStep (all architectures) have to
watch out for the following problem when writing programs with large,
statically allocated (i.e. non-stack based) data structures (common
blocks, saved arrays).

   Due to the way the native loader (`/bin/ld') lays out data
structures in virtual memory, it is very easy to create an executable
wherein the `__DATA' segment overlaps (has addresses in common) with
the `UNIX STACK' segment.

   This leads to all sorts of trouble, from the executable simply not
executing, to bus errors.  The NeXTStep command line tool `ebadexec'
points to the problem as follows:

     % /bin/ebadexec a.out
     /bin/ebadexec: __LINKEDIT segment (truncated address = 0x3de000
     rounded size = 0x2a000) of executable file: a.out overlaps with UNIX
     STACK segment (truncated address = 0x400000 rounded size =
     0x3c00000) of executable file: a.out

   (In the above case, it is the `__LINKEDIT' segment that overlaps the
stack segment.)

   This can be cured by assigning the `__DATA' segment (virtual)
addresses beyond the stack segment.  A conservative estimate for this
is from address 6000000 (hexadecimal) onwards--this has always worked
for me [Toon Moene]:

     % g77 -segaddr __DATA 6000000 test.f
     % ebadexec a.out
     ebadexec: file: a.out appears to be executable
     %

   Browsing through `gcc/gcc/f/Makefile.in', you will find that the
`f771' program itself also has to be linked with these flags--it has
large statically allocated data structures.  (Version 0.5.18 reduces
this somewhat, but probably not enough.)

   (The above item was contributed by Toon Moene
(<toon@moene.indiv.nluug.nl>).)


File: g77.info,  Node: Stack Overflow,  Next: Nothing Happens,  Prev: NeXTStep Problems,  Up: But-bugs

Stack Overflow
--------------

   `g77' code might fail at runtime (probably with a "segmentation
violation") due to overflowing the stack.  This happens most often on
systems with an environment that provides substantially more heap space
(for use when arbitrarily allocating and freeing memory) than stack
space.

   Often this can be cured by increasing or removing your shell's limit
on stack usage, typically using `limit stacksize' (in `csh' and
derivatives) or `ulimit -s' (in `sh' and derivatives).

   Increasing the allowed stack size might, however, require changing
some operating system or system configuration parameters.

   You might be able to work around the problem by compiling with the
`-fno-automatic' option to reduce stack usage, probably at the expense
of speed.

   `g77', on most machines, puts many variables and arrays on the stack
where possible, and can be configured (by changing
`FFECOM_sizeMAXSTACKITEM' in `gcc/gcc/f/com.c') to force smaller-sized
entities into static storage (saving on stack space) or permit
larger-sized entities to be put on the stack (which can improve
run-time performance, as it presents more opportunities for the GBE to
optimize the generated code).

   _Note:_ Putting more variables and arrays on the stack might cause
problems due to system-dependent limits on stack size.  Also, the value
of `FFECOM_sizeMAXSTACKITEM' has no effect on automatic variables and
arrays.  *Note But-bugs::, for more information.  _Note:_ While
`libg2c' places a limit on the range of Fortran file-unit numbers, the
underlying library and operating system might impose different kinds of
limits.  For example, some systems limit the number of files
simultaneously open by a running program.  Information on how to
increase these limits should be found in your system's documentation.

   However, if your program uses large automatic arrays (for example,
has declarations like `REAL A(N)' where `A' is a local array and `N' is
a dummy or `COMMON' variable that can have a large value), neither use
of `-fno-automatic', nor changing the cut-off point for `g77' for using
the stack, will solve the problem by changing the placement of these
large arrays, as they are _necessarily_ automatic.

   `g77' currently provides no means to specify that automatic arrays
are to be allocated on the heap instead of the stack.  So, other than
increasing the stack size, your best bet is to change your source code
to avoid large automatic arrays.  Methods for doing this currently are
outside the scope of this document.

   (_Note:_ If your system puts stack and heap space in the same memory
area, such that they are effectively combined, then a stack overflow
probably indicates a program that is either simply too large for the
system, or buggy.)


File: g77.info,  Node: Nothing Happens,  Next: Strange Behavior at Run Time,  Prev: Stack Overflow,  Up: But-bugs

Nothing Happens
---------------

   It is occasionally reported that a "simple" program, such as a
"Hello, World!" program, does nothing when it is run, even though the
compiler reported no errors, despite the program containing nothing
other than a simple `PRINT' statement.

   This most often happens because the program has been compiled and
linked on a UNIX system and named `test', though other names can lead
to similarly unexpected run-time behavior on various systems.

   Essentially this problem boils down to giving your program a name
that is already known to the shell you are using to identify some other
program, which the shell continues to execute instead of your program
when you invoke it via, for example:

     sh# test
     sh#

   Under UNIX and many other system, a simple command name invokes a
searching mechanism that might well not choose the program located in
the current working directory if there is another alternative (such as
the `test' command commonly installed on UNIX systems).

   The reliable way to invoke a program you just linked in the current
directory under UNIX is to specify it using an explicit pathname, as in:

     sh# ./test
      Hello, World!
     sh#

   Users who encounter this problem should take the time to read up on
how their shell searches for commands, how to set their search path,
and so on.  The relevant UNIX commands to learn about include `man',
`info' (on GNU systems), `setenv' (or `set' and `env'), `which', and
`find'.


File: g77.info,  Node: Strange Behavior at Run Time,  Next: Floating-point Errors,  Prev: Nothing Happens,  Up: But-bugs

Strange Behavior at Run Time
----------------------------

   `g77' code might fail at runtime with "segmentation violation", "bus
error", or even something as subtle as a procedure call overwriting a
variable or array element that it is not supposed to touch.

   These can be symptoms of a wide variety of actual bugs that occurred
earlier during the program's run, but manifested themselves as
_visible_ problems some time later.

   Overflowing the bounds of an array--usually by writing beyond the
end of it--is one of two kinds of bug that often occurs in Fortran code.
(Compile your code with the `-fbounds-check' option to catch many of
these kinds of errors at program run time.)

   The other kind of bug is a mismatch between the actual arguments
passed to a procedure and the dummy arguments as declared by that
procedure.

   Both of these kinds of bugs, and some others as well, can be
difficult to track down, because the bug can change its behavior, or
even appear to not occur, when using a debugger.

   That is, these bugs can be quite sensitive to data, including data
representing the placement of other data in memory (that is, pointers,
such as the placement of stack frames in memory).

   `g77' now offers the ability to catch and report some of these
problems at compile, link, or run time, such as by generating code to
detect references to beyond the bounds of most arrays (except
assumed-size arrays), and checking for agreement between calling and
called procedures.  Future improvements are likely to be made in the
procedure-mismatch area, at least.

   In the meantime, finding and fixing the programming bugs that lead
to these behaviors is, ultimately, the user's responsibility, as
difficult as that task can sometimes be.

   One runtime problem that has been observed might have a simple
solution.  If a formatted `WRITE' produces an endless stream of spaces,
check that your program is linked against the correct version of the C
library.  The configuration process takes care to account for your
system's normal `libc' not being ANSI-standard, which will otherwise
cause this behaviour.  If your system's default library is
ANSI-standard and you subsequently link against a non-ANSI one, there
might be problems such as this one.

   Specifically, on Solaris2 systems, avoid picking up the `BSD'
library from `/usr/ucblib'.


File: g77.info,  Node: Floating-point Errors,  Prev: Strange Behavior at Run Time,  Up: But-bugs

Floating-point Errors
---------------------

   Some programs appear to produce inconsistent floating-point results
compiled by `g77' versus by other compilers.

   Often the reason for this behavior is the fact that floating-point
values are represented on almost all Fortran systems by
_approximations_, and these approximations are inexact even for
apparently simple values like 0.1, 0.2, 0.3, 0.4, 0.6, 0.7, 0.8, 0.9,
1.1, and so on.  Most Fortran systems, including all current ports of
`g77', use binary arithmetic to represent these approximations.

   Therefore, the exact value of any floating-point approximation as
manipulated by `g77'-compiled code is representable by adding some
combination of the values 1.0, 0.5, 0.25, 0.125, and so on (just keep
dividing by two) through the precision of the fraction (typically
around 23 bits for `REAL(KIND=1)', 52 for `REAL(KIND=2)'), then
multiplying the sum by a integral power of two (in Fortran, by `2**N')
that typically is between -127 and +128 for `REAL(KIND=1)' and -1023
and +1024 for `REAL(KIND=2)', then multiplying by -1 if the number is
negative.

   So, a value like 0.2 is exactly represented in decimal--since it is
a fraction, `2/10', with a denominator that is compatible with the base
of the number system (base 10).  However, `2/10' cannot be represented
by any finite number of sums of any of 1.0, 0.5, 0.25, and so on, so
0.2 cannot be exactly represented in binary notation.

   (On the other hand, decimal notation can represent any binary number
in a finite number of digits.  Decimal notation cannot do so with
ternary, or base-3, notation, which would represent floating-point
numbers as sums of any of `1/1', `1/3', `1/9', and so on.  After all,
no finite number of decimal digits can exactly represent `1/3'.
Fortunately, few systems use ternary notation.)

   Moreover, differences in the way run-time I/O libraries convert
between these approximations and the decimal representation often used
by programmers and the programs they write can result in apparent
differences between results that do not actually exist, or exist to
such a small degree that they usually are not worth worrying about.

   For example, consider the following program:

     PRINT *, 0.2
     END

   When compiled by `g77', the above program might output `0.20000003',
while another compiler might produce a executable that outputs `0.2'.

   This particular difference is due to the fact that, currently,
conversion of floating-point values by the `libg2c' library, used by
`g77', handles only double-precision values.

   Since `0.2' in the program is a single-precision value, it is
converted to double precision (still in binary notation) before being
converted back to decimal.  The conversion to binary appends _binary_
zero digits to the original value--which, again, is an inexact
approximation of 0.2--resulting in an approximation that is much less
exact than is connoted by the use of double precision.

   (The appending of binary zero digits has essentially the same effect
as taking a particular decimal approximation of `1/3', such as
`0.3333333', and appending decimal zeros to it, producing
`0.33333330000000000'.  Treating the resulting decimal approximation as
if it really had 18 or so digits of valid precision would make it seem
a very poor approximation of `1/3'.)

   As a result of converting the single-precision approximation to
double precision by appending binary zeros, the conversion of the
resulting double-precision value to decimal produces what looks like an
incorrect result, when in fact the result is _inexact_, and is probably
no less inaccurate or imprecise an approximation of 0.2 than is
produced by other compilers that happen to output the converted value
as "exactly" `0.2'.  (Some compilers behave in a way that can make them
appear to retain more accuracy across a conversion of a single-precision
constant to double precision.  *Note Context-Sensitive Constants::, to
see why this practice is illusory and even dangerous.)

   Note that a more exact approximation of the constant is computed
when the program is changed to specify a double-precision constant:

     PRINT *, 0.2D0
     END

   Future versions of `g77' and/or `libg2c' might convert
single-precision values directly to decimal, instead of converting them
to double precision first.  This would tend to result in output that is
more consistent with that produced by some other Fortran
implementations.

   A useful source of information on floating-point computation is David
Goldberg, `What Every Computer Scientist Should Know About
Floating-Point Arithmetic', Computing Surveys, 23, March 1991, pp.
5-48.  An online version is available at `http://docs.sun.com/', and
there is a supplemented version, in PostScript form, at
`http://www.validgh.com/goldberg/paper.ps'.

   Information related to the IEEE 754 floating-point standard by a
leading light can be found at
`http://http.cs.berkeley.edu/%7Ewkahan/ieee754status/'; see also slides
from the short course referenced from
`http://http.cs.berkeley.edu/%7Efateman/'.
`http://www.linuxsupportline.com/%7Ebillm/' has a brief guide to IEEE
754, a somewhat x86-GNU/Linux-specific FAQ, and library code for
GNU/Linux x86 systems.

   The supplement to the PostScript-formatted Goldberg document,
referenced above, is available in HTML format.  See `Differences Among
IEEE 754 Implementations' by Doug Priest, available online at
`http://www.validgh.com/goldberg/addendum.html'.  This document
explores some of the issues surrounding computing of extended (80-bit)
results on processors such as the x86, especially when those results
are arbitrarily truncated to 32-bit or 64-bit values by the compiler as
"spills".

   (_Note:_ `g77' specifically, and `gcc' generally, does arbitrarily
truncate 80-bit results during spills as of this writing.  It is not
yet clear whether a future version of the GNU compiler suite will offer
80-bit spills as an option, or perhaps even as the default behavior.)

   The GNU C library provides routines for controlling the FPU, and
other documentation about this.

   *Note Floating-point precision::, regarding IEEE 754 conformance.


File: g77.info,  Node: Known Bugs,  Next: Missing Features,  Prev: But-bugs,  Up: Trouble

Known Bugs In GNU Fortran
=========================

   This section identifies bugs that `g77' _users_ might run into in
the GCC-3.0 version of `g77'.  This includes bugs that are actually in
the `gcc' back end (GBE) or in `libf2c', because those sets of code are
at least somewhat under the control of (and necessarily intertwined
with) `g77', so it isn't worth separating them out.

   For information on bugs in _other_ versions of `g77', see *Note News
About GNU Fortran: News.  There, lists of bugs fixed in various
versions of `g77' can help determine what bugs existed in prior
versions.

   An online, "live" version of this document (derived directly from
the mainline, development version of `g77' within `gcc') is available
via `http://www.gnu.org/software/gcc/onlinedocs/g77_bugs.html'.  Follow
the "Known Bugs" link.

   The following information was last updated on 2001-06-10:

   * `g77' fails to warn about use of a "live" iterative-DO variable as
     an implied-DO variable in a `WRITE' or `PRINT' statement (although
     it does warn about this in a `READ' statement).

   * Something about `g77''s straightforward handling of label
     references and definitions sometimes prevents the GBE from
     unrolling loops.  Until this is solved, try inserting or removing
     `CONTINUE' statements as the terminal statement, using the `END DO'
     form instead, and so on.

   * Some confusion in diagnostics concerning failing `INCLUDE'
     statements from within `INCLUDE''d or `#include''d files.

   * `g77' assumes that `INTEGER(KIND=1)' constants range from `-2**31'
     to `2**31-1' (the range for two's-complement 32-bit values),
     instead of determining their range from the actual range of the
     type for the configuration (and, someday, for the constant).

     Further, it generally doesn't implement the handling of constants
     very well in that it makes assumptions about the configuration
     that it no longer makes regarding variables (types).

     Included with this item is the fact that `g77' doesn't recognize
     that, on IEEE-754/854-compliant systems, `0./0.' should produce a
     NaN and no warning instead of the value `0.' and a warning.  This
     is to be fixed in version 0.6, when `g77' will use the `gcc' back
     end's constant-handling mechanisms to replace its own.

   * `g77' uses way too much memory and CPU time to process large
     aggregate areas having any initialized elements.

     For example, `REAL A(1000000)' followed by `DATA A(1)/1/' takes up
     way too much time and space, including the size of the generated
     assembler file.  This is to be mitigated somewhat in version 0.6.

     Version 0.5.18 improves cases like this--specifically, cases of
     _sparse_ initialization that leave large, contiguous areas
     uninitialized--significantly.  However, even with the
     improvements, these cases still require too much memory and CPU
     time.

     (Version 0.5.18 also improves cases where the initial values are
     zero to a much greater degree, so if the above example ends with
     `DATA A(1)/0/', the compile-time performance will be about as good
     as it will ever get, aside from unrelated improvements to the
     compiler.)

     Note that `g77' does display a warning message to notify the user
     before the compiler appears to hang.  A warning message is issued
     when `g77' sees code that provides initial values (e.g. via
     `DATA') to an aggregate area (`COMMON' or `EQUIVALENCE', or even a
     large enough array or `CHARACTER' variable) that is large enough
     to increase `g77''s compile time by roughly a factor of 10.

     This size currently is quite small, since `g77' currently has a
     known bug requiring too much memory and time to handle such cases.
     In `gcc/gcc/f/data.c', the macro `FFEDATA_sizeTOO_BIG_INIT_' is
     defined to the minimum size for the warning to appear.  The size
     is specified in storage units, which can be bytes, words, or
     whatever, on a case-by-case basis.

     After changing this macro definition, you must (of course) rebuild
     and reinstall `g77' for the change to take effect.

     Note that, as of version 0.5.18, improvements have reduced the
     scope of the problem for _sparse_ initialization of large arrays,
     especially those with large, contiguous uninitialized areas.
     However, the warning is issued at a point prior to when `g77'
     knows whether the initialization is sparse, and delaying the
     warning could mean it is produced too late to be helpful.

     Therefore, the macro definition should not be adjusted to reflect
     sparse cases.  Instead, adjust it to generate the warning when
     densely initialized arrays begin to cause responses noticeably
     slower than linear performance would suggest.

   * Previous versions of `g77' didn't emit information on variable and
     array members of common blocks and equivalences for use with a
     debugger (the `-g' command-line option).  As of the version of
     `g77' shipped with version 3.0 of `GCC', this is corrected.

     As of Version 0.5.19, a temporary kludge solution is provided
     whereby some rudimentary information on a member is written as a
     string that is the member's value as a character string.

     *Note Options for Code Generation Conventions: Code Gen Options,
     for information on the `-fdebug-kludge' option.

   * When debugging, after starting up the debugger but before being
     able to see the source code for the main program unit, the user
     must currently set a breakpoint at `MAIN__' (or `MAIN___' or
     `MAIN_' if `MAIN__' doesn't exist) and run the program until it
     hits the breakpoint.  At that point, the main program unit is
     activated and about to execute its first executable statement, but
     that's the state in which the debugger should start up, as is the
     case for languages like C.

   * Debugging `g77'-compiled code using debuggers other than `gdb' is
     likely not to work.

     Getting `g77' and `gdb' to work together is a known
     problem--getting `g77' to work properly with other debuggers, for
     which source code often is unavailable to `g77' developers, seems
     like a much larger, unknown problem, and is a lower priority than
     making `g77' and `gdb' work together properly.

     On the other hand, information about problems other debuggers have
     with `g77' output might make it easier to properly fix `g77', and
     perhaps even improve `gdb', so it is definitely welcome.  Such
     information might even lead to all relevant products working
     together properly sooner.

   * `g77' doesn't work perfectly on 64-bit configurations such as the
     Digital Semiconductor ("DEC") Alpha.

     This problem is largely resolved as of version 0.5.23.  Version
     0.6 should solve most or all remaining problems (such as
     cross-compiling involving 64-bit machines).

   * `g77' currently inserts needless padding for things like `COMMON
     A,IPAD' where `A' is `CHARACTER*1' and `IPAD' is `INTEGER(KIND=1)'
     on machines like x86, because the back end insists that `IPAD' be
     aligned to a 4-byte boundary, but the processor has no such
     requirement (though it is usually good for performance).

     The `gcc' back end needs to provide a wider array of
     specifications of alignment requirements and preferences for
     targets, and front ends like `g77' should take advantage of this
     when it becomes available.

   * The `libf2c' routines that perform some run-time arithmetic on
     `COMPLEX' operands were modified circa version 0.5.20 of `g77' to
     work properly even in the presence of aliased operands.

     While the `g77' and `netlib' versions of `libf2c' differ on how
     this is accomplished, the main differences are that we believe the
     `g77' version works properly even in the presence of _partially_
     aliased operands.

     However, these modifications have reduced performance on targets
     such as x86, due to the extra copies of operands involved.


File: g77.info,  Node: Missing Features,  Next: Disappointments,  Prev: Known Bugs,  Up: Trouble

Missing Features
================

   This section lists features we know are missing from `g77', and
which we want to add someday.  (There is no priority implied in the
ordering below.)

* Menu:

GNU Fortran language:
* Better Source Model::
* Fortran 90 Support::
* Intrinsics in PARAMETER Statements::
* Arbitrary Concatenation::
* SELECT CASE on CHARACTER Type::
* RECURSIVE Keyword::
* Popular Non-standard Types::
* Full Support for Compiler Types::
* Array Bounds Expressions::
* POINTER Statements::
* Sensible Non-standard Constructs::
* READONLY Keyword::
* FLUSH Statement::
* Expressions in FORMAT Statements::
* Explicit Assembler Code::
* Q Edit Descriptor::

GNU Fortran dialects:
* Old-style PARAMETER Statements::
* TYPE and ACCEPT I/O Statements::
* STRUCTURE UNION RECORD MAP::
* OPEN CLOSE and INQUIRE Keywords::
* ENCODE and DECODE::
* AUTOMATIC Statement::
* Suppressing Space Padding::
* Fortran Preprocessor::
* Bit Operations on Floating-point Data::
* Really Ugly Character Assignments::

New facilities:
* POSIX Standard::
* Floating-point Exception Handling::
* Nonportable Conversions::
* Large Automatic Arrays::
* Support for Threads::
* Increasing Precision/Range::
* Enabling Debug Lines::

Better diagnostics:
* Better Warnings::
* Gracefully Handle Sensible Bad Code::
* Non-standard Conversions::
* Non-standard Intrinsics::
* Modifying DO Variable::
* Better Pedantic Compilation::
* Warn About Implicit Conversions::
* Invalid Use of Hollerith Constant::
* Dummy Array Without Dimensioning Dummy::
* Invalid FORMAT Specifiers::
* Ambiguous Dialects::
* Unused Labels::
* Informational Messages::

Run-time facilities:
* Uninitialized Variables at Run Time::
* Portable Unformatted Files::
* Better List-directed I/O::
* Default to Console I/O::

Debugging:
* Labels Visible to Debugger::


File: g77.info,  Node: Better Source Model,  Next: Fortran 90 Support,  Up: Missing Features

Better Source Model
-------------------

   `g77' needs to provide, as the default source-line model, a "pure
visual" mode, where the interpretation of a source program in this mode
can be accurately determined by a user looking at a traditionally
displayed rendition of the program (assuming the user knows whether the
program is fixed or free form).

   The design should assume the user cannot tell tabs from spaces and
cannot see trailing spaces on lines, but has canonical tab stops and,
for fixed-form source, has the ability to always know exactly where
column 72 is (since the Fortran standard itself requires this for
fixed-form source).

   This would change the default treatment of fixed-form source to not
treat lines with tabs as if they were infinitely long--instead, they
would end at column 72 just as if the tabs were replaced by spaces in
the canonical way.

   As part of this, provide common alternate models (Digital, `f2c',
and so on) via command-line options.  This includes allowing
arbitrarily long lines for free-form source as well as fixed-form
source and providing various limits and diagnostics as appropriate.

   Also, `g77' should offer, perhaps even default to, warnings when
characters beyond the last valid column are anything other than spaces.
This would mean code with "sequence numbers" in columns 73 through 80
would be rejected, and there's a lot of that kind of code around, but
one of the most frequent bugs encountered by new users is accidentally
writing fixed-form source code into and beyond column 73.  So, maybe
the users of old code would be able to more easily handle having to
specify, say, a `-Wno-col73to80' option.


File: g77.info,  Node: Fortran 90 Support,  Next: Intrinsics in PARAMETER Statements,  Prev: Better Source Model,  Up: Missing Features

Fortran 90 Support
------------------

   `g77' does not support many of the features that distinguish Fortran
90 (and, now, Fortran 95) from ANSI FORTRAN 77.

   Some Fortran 90 features are supported, because they make sense to
offer even to die-hard users of F77.  For example, many of them codify
various ways F77 has been extended to meet users' needs during its
tenure, so `g77' might as well offer them as the primary way to meet
those same needs, even if it offers compatibility with one or more of
the ways those needs were met by other F77 compilers in the industry.

   Still, many important F90 features are not supported, because no
attempt has been made to research each and every feature and assess its
viability in `g77'.  In the meantime, users who need those features must
use Fortran 90 compilers anyway, and the best approach to adding some
F90 features to GNU Fortran might well be to fund a comprehensive
project to create GNU Fortran 95.

