path: root/gcc/f/g77.info-16

This is Info file g77.info, produced by Makeinfo version 1.68 from the
input file g77.texi.

   This file explains how to use the GNU Fortran system.

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

   Copyright (C) 1995-1997 Free Software Foundation, Inc.

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License," "Funding for
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License," "Funding for Free Software," and "Protect Your Freedom--Fight
`Look And Feel'", and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.

   Contributed by James Craig Burley (<burley@gnu.ai.mit.edu>).
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>).

INFO-DIR-SECTION Fortran Programming
START-INFO-DIR-ENTRY
* g77: (g77).               The GNU Fortran compilation system.
END-INFO-DIR-ENTRY


File: g77.info,  Node: But-bugs,  Next: Actual 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
`-lf2c -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 `-lf2c -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 `-lf2c -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.


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

   *Note Maximum Stackable Size::, for information on patching `g77' to
use different criteria for placing local non-automatic variables and
arrays on the stack.

   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.

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

   Plans call for improving `g77' so that it can offer 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
an array, or checking for agreement between calling and called
procedures.

   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 denomenator 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 `libf2c' 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 `libf2c' 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.


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

Actual Bugs We Haven't Fixed Yet
================================

   This section identifies bugs that `g77' *users* might run into.
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 that might afflict people who configure,
port, build, and install `g77', *Note Problems Installing::.

   * `g77''s version of `gcc', and probably `g77' itself, cannot be
     reliably used with the `-O2' option (or higher) on Digital
     Semiconductor Alpha AXP machines.  The problem is most immediately
     noticed in differences discovered by `make compare' following a
     bootstrap build using `-O2'.  It also manifests itself as a
     failure to compile `DATA' statements such as `DATA R/7./'
     correctly; in this case, `R' might be initialized to `4.0'.

     Until this bug is fixed, use only `-O1' or no optimization.

   * A code-generation bug afflicts Intel x86 targets when `-O2' is
     specified compiling, for example, an old version of the `DNRM2'
     routine.  The x87 coprocessor stack is being somewhat mismanaged
     in cases where assigned `GOTO' and `ASSIGN' are involved.

     Version 0.5.21 of `g77' contains an initial effort to fix the
     problem, but this effort is incomplete, and a more complete fix is
     planned for the next release.

   * Work is needed on the `SIGNAL()' intrinsic to ensure that pointers
     and integers are properly handled on all targets, including 64-bit
     machines.

   * When using `-fugly-comma', `g77' assumes an extra `%VAL(0)'
     argument is to be passed to intrinsics taking no arguments, such
     as `IARGC()', which in turn reject such a call.  Although this has
     been worked around for 0.5.18 due to changes in the handling of
     intrinsics, `g77' needs to do the ugly-argument-appending trick
     only for external-function invocation, as this would probably be
     more consistent with compilers that default to using that trick.

   * 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.  (Probably improved, but not wholly
     fixed, in 0.5.21.)

   * The `g77' command itself should more faithfully process options
     the way the `gcc' command does.  For example, `gcc' accepts
     abbreviated forms of long options, `g77' generally doesn't.

   * 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.  *Note Initialization of
     Large Aggregate Areas: Large Initialization, for information on
     how to change the point at which `g77' decides to issue this
     warning.

   * `g77' doesn't emit variable and array members of common blocks for
     use with a debugger (the `-g' command-line option).  The code is
     present to do this, but doesn't work with at least one debug
     format--perhaps it works with others.  And it turns out there's a
     similar bug for local equivalence areas, so that has been disabled
     as well.

     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' 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's good for performance).

     It is possible that this is not a real bug, and could be considered
     a performance feature, but it might be important to provide the
     ability to Fortran code to specify minimum padding for aggregate
     areas such as common blocks--and, certainly, there is the
     potential, with the current setup, for interface differences in
     the way such areas are laid out between `g77' and other compilers.

   * Some crashes occur when compiling under Solaris on x86 machines.

     Nothing has been heard about any such problems for some time, so
     this is considering a closed item as of 0.5.20.  Please submit any
     bug reports pertinent to `g77''s support for Solaris/x86 systems.

   * RS/6000 support is not complete as of the gcc 2.6.3 back end.  The
     2.7.0 back end appears to fix this problem, or at least mitigate
     it significantly, but there is at least one known problem that is
     likely to be a code-generation bug in `gcc-2.7.0' plus
     `g77-0.5.16'.  This problem shows up only when compiling the
     Fortran program with `-O'.

     Nothing has been heard about any RS/6000 problems for some time,
     so this is considering a closed item as of 0.5.20.  Please submit
     any bug reports pertinent to `g77''s support for RS/6000 systems.

   * SGI support is known to be a bit buggy.  The known problem shows
     up only when compiling the Fortran program with `-O'.

     It is possible these problems have all been fixed in 0.5.20 by
     emulating complex arithmetic in the front end.  Please submit any
     bug reports pertinent to `g77''s support for SGI systems.

   * `g77' doesn't work perfectly on 64-bit configurations such as the
     Alpha.  This problem is expected to be largely resolved as of
     version 0.5.20, and further addressed by 0.5.21.  Version 0.6
     should solve most or all related problems (such as 64-bit machines
     other than Digital Semiconductor ("DEC") Alphas).

     One known bug that causes a compile-time crash occurs when
     compiling code such as the following with optimization:

          SUBROUTINE CRASH (TEMP)
          INTEGER*2 HALF(2)
          REAL TEMP
          HALF(1) = NINT (TEMP)
          END

     It is expected that a future version of `g77' will have a fix for
     this problem, almost certainly by the time `g77' supports the
     forthcoming version 2.8.0 of `gcc'.

   * Maintainers of gcc report that the back end definitely has "broken"
     support for `COMPLEX' types.  Based on their input, it seems many
     of the problems affect only the more-general facilities for gcc's
     `__complex__' type, such as `__complex__ int' (where the real and
     imaginary parts are integers) that GNU Fortran does not use.

     Version 0.5.20 of `g77' works around this problem by not using the
     back end's support for `COMPLEX'.  The new option
     `-fno-emulate-complex' avoids the work-around, reverting to using
     the same "broken" mechanism as that used by versions of `g77'
     prior to 0.5.20.

   * There seem to be some problems with passing constants, and perhaps
     general expressions (other than simple variables/arrays), to
     procedures when compiling on some systems (such as i386) with
     `-fPIC', as in when compiling for ELF targets.  The symptom is
     that the assembler complains about invalid opcodes.  More
     investigation is needed, but the problem is almost certainly in
     the gcc back end, and it apparently occurs only when compiling
     sufficiently complicated functions *without* the `-O' option.


File: g77.info,  Node: Missing Features,  Next: Disappointments,  Prev: Actual 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::
* 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::
* 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::
* Suppressing Space Padding::
* Fortran Preprocessor::
* Bit Operations on Floating-point Data::

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

Better diagnostics:
* 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::
* Bounds Checking at Run Time::

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.


File: g77.info,  Node: Intrinsics in PARAMETER Statements,  Next: SELECT CASE on CHARACTER Type,  Prev: Fortran 90 Support,  Up: Missing Features

Intrinsics in `PARAMETER' Statements
------------------------------------

   `g77' doesn't allow intrinsics in `PARAMETER' statements.  This
feature is considered to be absolutely vital, even though it is not
standard-conforming, and is scheduled for version 0.6.

   Related to this, `g77' doesn't allow non-integral exponentiation in
`PARAMETER' statements, such as `PARAMETER (R=2**.25)'.  It is unlikely
`g77' will ever support this feature, as doing it properly requires
complete emulation of a target computer's floating-point facilities when
building `g77' as a cross-compiler.  But, if the `gcc' back end is
enhanced to provide such a facility, `g77' will likely use that facility
in implementing this feature soon afterwards.


File: g77.info,  Node: SELECT CASE on CHARACTER Type,  Next: RECURSIVE Keyword,  Prev: Intrinsics in PARAMETER Statements,  Up: Missing Features

`SELECT CASE' on `CHARACTER' Type
---------------------------------

   Character-type selector/cases for `SELECT CASE' currently are not
supported.


File: g77.info,  Node: RECURSIVE Keyword,  Next: Popular Non-standard Types,  Prev: SELECT CASE on CHARACTER Type,  Up: Missing Features

`RECURSIVE' Keyword
-------------------

   `g77' doesn't support the `RECURSIVE' keyword that F90 compilers do.
Nor does it provide any means for compiling procedures designed to do
recursion.

   All recursive code can be rewritten to not use recursion, but the
result is not pretty.


File: g77.info,  Node: Increasing Precision/Range,  Next: Gracefully Handle Sensible Bad Code,  Prev: Support for Threads,  Up: Missing Features

Increasing Precision/Range
--------------------------

   Some compilers, such as `f2c', have an option (`-r8' or similar)
that provides automatic treatment of `REAL' entities such that they
have twice the storage size, and a corresponding increase in the range
and precision, of what would normally be the `REAL(KIND=1)' (default
`REAL') type.  (This affects `COMPLEX' the same way.)

   They also typically offer another option (`-i8') to increase
`INTEGER' entities so they are twice as large (with roughly twice as
much range).

   (There are potential pitfalls in using these options.)

   `g77' does not yet offer any option that performs these kinds of
transformations.  Part of the problem is the lack of detailed
specifications regarding exactly how these options affect the
interpretation of constants, intrinsics, and so on.

   Until `g77' addresses this need, programmers could improve the
portability of their code by modifying it to not require compile-time
options to produce correct results.  Some free tools are available
which may help, specifically in Toolpack (which one would expect to be
sound) and the `fortran' section of the Netlib repository.

   Use of preprocessors can provide a fairly portable means to work
around the lack of widely portable methods in the Fortran language
itself (though increasing acceptance of Fortran 90 would alleviate this
problem).


File: g77.info,  Node: Popular Non-standard Types,  Next: Full Support for Compiler Types,  Prev: RECURSIVE Keyword,  Up: Missing Features

Popular Non-standard Types
--------------------------

   `g77' doesn't fully support `INTEGER*2', `LOGICAL*1', and similar.
Version 0.6 will provide full support for this very popular set of
features.  In the meantime, version 0.5.18 provides rudimentary support
for them.


File: g77.info,  Node: Full Support for Compiler Types,  Next: Array Bounds Expressions,  Prev: Popular Non-standard Types,  Up: Missing Features

Full Support for Compiler Types
-------------------------------

   `g77' doesn't support `INTEGER', `REAL', and `COMPLEX' equivalents
for *all* applicable back-end-supported types (`char', `short int',
`int', `long int', `long long int', and `long double').  This means
providing intrinsic support, and maybe constant support (using F90
syntax) as well, and, for most machines will result in automatic
support of `INTEGER*1', `INTEGER*2', `INTEGER*8', maybe even `REAL*16',
and so on.  This is scheduled for version 0.6.


File: g77.info,  Node: Array Bounds Expressions,  Next: POINTER Statements,  Prev: Full Support for Compiler Types,  Up: Missing Features

Array Bounds Expressions
------------------------

   `g77' doesn't support more general expressions to dimension arrays,
such as array element references, function references, etc.

   For example, `g77' currently does not accept the following:

     SUBROUTINE X(M, N)
     INTEGER N(10), M(N(2), N(1))


File: g77.info,  Node: POINTER Statements,  Next: Sensible Non-standard Constructs,  Prev: Array Bounds Expressions,  Up: Missing Features

POINTER Statements
------------------

   `g77' doesn't support pointers or allocatable objects (other than
automatic arrays).  This set of features is probably considered just
behind intrinsics in `PARAMETER' statements on the list of large,
important things to add to `g77'.

   In the meantime, consider using the `INTEGER(KIND=7)' declaration to
specify that a variable must be able to hold a pointer.  This construct
is not portable to other non-GNU compilers, but it is portable to all
machines GNU Fortran supports when `g77' is used.

   *Note Functions and Subroutines::, for information on `%VAL()',
`%REF()', and `%DESCR()' constructs, which are useful for passing
pointers to procedures written in languages other than Fortran.


File: g77.info,  Node: Sensible Non-standard Constructs,  Next: FLUSH Statement,  Prev: POINTER Statements,  Up: Missing Features

Sensible Non-standard Constructs
--------------------------------

   `g77' rejects things other compilers accept, like `INTRINSIC
SQRT,SQRT'.  As time permits in the future, some of these things that
are easy for humans to read and write and unlikely to be intended to
mean something else will be accepted by `g77' (though `-fpedantic'
should trigger warnings about such non-standard constructs).

   Until `g77' no longer gratuitously rejects sensible code, you might
as well fix your code to be more standard-conforming and portable.

   The kind of case that is important to except from the recommendation
to change your code is one where following good coding rules would
force you to write non-standard code that nevertheless has a clear
meaning.

   For example, when writing an `INCLUDE' file that defines a common
block, it might be appropriate to include a `SAVE' statement for the
common block (such as `SAVE /CBLOCK/'), so that variables defined in
the common block retain their values even when all procedures declaring
the common block become inactive (return to their callers).

   However, putting `SAVE' statements in an `INCLUDE' file would
prevent otherwise standard-conforming code from also specifying the
`SAVE' statement, by itself, to indicate that all local variables and
arrays are to have the `SAVE' attribute.

   For this reason, `g77' already has been changed to allow this
combination, because although the general problem of gratuitously
rejecting unambiguous and "safe" constructs still exists in `g77', this
particular construct was deemed useful enough that it was worth fixing
`g77' for just this case.

   So, while there is no need to change your code to avoid using this
particular construct, there might be other, equally appropriate but
non-standard constructs, that you shouldn't have to stop using just
because `g77' (or any other compiler) gratuitously rejects it.

   Until the general problem is solved, if you have any such construct
you believe is worthwhile using (e.g. not just an arbitrary, redundant
specification of an attribute), please submit a bug report with an
explanation, so we can consider fixing `g77' just for cases like yours.


File: g77.info,  Node: FLUSH Statement,  Next: Expressions in FORMAT Statements,  Prev: Sensible Non-standard Constructs,  Up: Missing Features

`FLUSH' Statement
-----------------

   `g77' could perhaps use a `FLUSH' statement that does what `CALL
FLUSH' does, but that supports `*' as the unit designator (same unit as
for `PRINT') and accepts `ERR=' and/or `IOSTAT=' specifiers.


File: g77.info,  Node: Expressions in FORMAT Statements,  Next: Explicit Assembler Code,  Prev: FLUSH Statement,  Up: Missing Features

Expressions in `FORMAT' Statements
----------------------------------

   `g77' doesn't support `FORMAT(I<J>)' and the like.  Supporting this
requires a significant redesign or replacement of `libf2c'.

   However, a future version of `g77' might support this construct when
the expression is constant.  For example:

           PARAMETER (IWIDTH = 12)
     10    FORMAT (I<IWIDTH>)

   In the meantime, at least for output (`PRINT' and `WRITE'), Fortran
code making use of this feature can be rewritten to avoid it by
constructing the `FORMAT' string in a `CHARACTER' variable or array,
then using that variable or array in place of the `FORMAT' statement
label to do the original `PRINT' or `WRITE'.

   Many uses of this feature on input can be rewritten this way as
well, but not all can.  For example, this can be rewritten:

           READ 20, I
     20    FORMAT (I<J>)

   However, this cannot, in general, be rewritten, especially when
`ERR=' and `END=' constructs are employed:

           READ 30, J, I
     30    FORMAT (I<J>)


File: g77.info,  Node: Explicit Assembler Code,  Next: Q Edit Descriptor,  Prev: Expressions in FORMAT Statements,  Up: Missing Features

Explicit Assembler Code
-----------------------

   `g77' needs to provide some way, a la `gcc', for `g77' code to
specify explicit assembler code.


File: g77.info,  Node: Q Edit Descriptor,  Next: Old-style PARAMETER Statements,  Prev: Explicit Assembler Code,  Up: Missing Features

Q Edit Descriptor
-----------------

   The `Q' edit descriptor in `FORMAT's isn't supported.  (This is
meant to get the number of characters remaining in an input record.)
Supporting this requires a significant redesign or replacement of
`libf2c'.

   A workaround might be using internal I/O or the stream-based
intrinsics.  *Note FGetC Intrinsic (subroutine)::.


File: g77.info,  Node: Old-style PARAMETER Statements,  Next: TYPE and ACCEPT I/O Statements,  Prev: Q Edit Descriptor,  Up: Missing Features

Old-style PARAMETER Statements
------------------------------

   `g77' doesn't accept `PARAMETER I=1'.  Supporting this obsolete form
of the `PARAMETER' statement would not be particularly hard, as most of
the parsing code is already in place and working.

   Until time/money is spent implementing it, you might as well fix
your code to use the standard form, `PARAMETER (I=1)' (possibly needing
`INTEGER I' preceding the `PARAMETER' statement as well, otherwise, in
the obsolete form of `PARAMETER', the type of the variable is set from
the type of the constant being assigned to it).


File: g77.info,  Node: TYPE and ACCEPT I/O Statements,  Next: STRUCTURE UNION RECORD MAP,  Prev: Old-style PARAMETER Statements,  Up: Missing Features

`TYPE' and `ACCEPT' I/O Statements
----------------------------------

   `g77' doesn't support the I/O statements `TYPE' and `ACCEPT'.  These
are common extensions that should be easy to support, but also are
fairly easy to work around in user code.

   Generally, any `TYPE fmt,list' I/O statement can be replaced by
`PRINT fmt,list'.  And, any `ACCEPT fmt,list' statement can be replaced
by `READ fmt,list'.


File: g77.info,  Node: STRUCTURE UNION RECORD MAP,  Next: OPEN CLOSE and INQUIRE Keywords,  Prev: TYPE and ACCEPT I/O Statements,  Up: Missing Features

`STRUCTURE', `UNION', `RECORD', `MAP'
-------------------------------------

   `g77' doesn't support `STRUCTURE', `UNION', `RECORD', `MAP'.  This
set of extensions is quite a bit lower on the list of large, important
things to add to `g77', partly because it requires a great deal of work
either upgrading or replacing `libf2c'.


File: g77.info,  Node: OPEN CLOSE and INQUIRE Keywords,  Next: ENCODE and DECODE,  Prev: STRUCTURE UNION RECORD MAP,  Up: Missing Features

`OPEN', `CLOSE', and `INQUIRE' Keywords
---------------------------------------

   `g77' doesn't have support for keywords such as `DISP='DELETE'' in
the `OPEN', `CLOSE', and `INQUIRE' statements.  These extensions are
easy to add to `g77' itself, but require much more work on `libf2c'.


File: g77.info,  Node: ENCODE and DECODE,  Next: Suppressing Space Padding,  Prev: OPEN CLOSE and INQUIRE Keywords,  Up: Missing Features

`ENCODE' and `DECODE'
---------------------

   `g77' doesn't support `ENCODE' or `DECODE'.

   These statements are best replaced by READ and WRITE statements
involving internal files (CHARACTER variables and arrays).

   For example, replace a code fragment like

           INTEGER*1 LINE(80)
     ...
           DECODE (80, 9000, LINE) A, B, C
     ...
     9000  FORMAT (1X, 3(F10.5))

with:

           CHARACTER*80 LINE
     ...
           READ (UNIT=LINE, FMT=9000) A, B, C
     ...
     9000  FORMAT (1X, 3(F10.5))

   Similarly, replace a code fragment like

           INTEGER*1 LINE(80)
     ...
           ENCODE (80, 9000, LINE) A, B, C
     ...
     9000  FORMAT (1X, 'OUTPUT IS ', 3(F10.5))

with:

           CHARACTER*80 LINE
     ...
           WRITE (UNIT=LINE, FMT=9000) A, B, C
     ...
     9000  FORMAT (1X, 'OUTPUT IS ', 3(F10.5))

   It is entirely possible that `ENCODE' and `DECODE' will be supported
by a future version of `g77'.


File: g77.info,  Node: Suppressing Space Padding,  Next: Fortran Preprocessor,  Prev: ENCODE and DECODE,  Up: Missing Features

Suppressing Space Padding of Source Lines
-----------------------------------------

   `g77' should offer VXT-Fortran-style suppression of virtual spaces
at the end of a source line if an appropriate command-line option is
specified.

   This affects cases where a character constant is continued onto the
next line in a fixed-form source file, as in the following example:

     10    PRINT *,'HOW MANY
          1 SPACES?'

`g77', and many other compilers, virtually extend the continued line
through column 72 with spaces that become part of the character
constant, but Digital Fortran normally didn't, leaving only one space
between `MANY' and `SPACES?'  in the output of the above statement.

   Fairly recently, at least one version of Digital Fortran was
enhanced to provide the other behavior when a command-line option is
specified, apparently due to demand from readers of the USENET group
`comp.lang.fortran' to offer conformance to this widespread practice in
the industry.  `g77' should return the favor by offering conformance to
Digital's approach to handling the above example.


File: g77.info,  Node: Fortran Preprocessor,  Next: Bit Operations on Floating-point Data,  Prev: Suppressing Space Padding,  Up: Missing Features

Fortran Preprocessor
--------------------

   `g77' should offer a preprocessor designed specifically for Fortran
to replace `cpp -traditional'.  There are several out there worth
evaluating, at least.

   Such a preprocessor would recognize Hollerith constants, properly
parse comments and character constants, and so on.  It might also
recognize, process, and thus preprocess files included via the
`INCLUDE' directive.


File: g77.info,  Node: Bit Operations on Floating-point Data,  Next: POSIX Standard,  Prev: Fortran Preprocessor,  Up: Missing Features

Bit Operations on Floating-point Data
-------------------------------------

   `g77' does not allow `REAL' and other non-integral types for
arguments to intrinsics like `AND', `OR', and `SHIFT'.

   For example, this program is rejected by `g77', because the
intrinsic `IAND' does not accept `REAL' arguments:

     DATA A/7.54/, B/9.112/
     PRINT *, IAND(A, B)
     END


File: g77.info,  Node: POSIX Standard,  Next: Floating-point Exception Handling,  Prev: Bit Operations on Floating-point Data,  Up: Missing Features

`POSIX' Standard
----------------

   `g77' should support the POSIX standard for Fortran.