This file lists known bugs in the GNU Fortran compiler.  Copyright (C)
1995, 1996 Free Software Foundation, Inc.  You may copy, distribute,
and modify it freely as long as you preserve this copyright notice and
permission notice.

Bugs in GNU Fortran
*******************

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

   * When using `-fugly', `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.

   * Although `g77' generally supports `SELECT CASE', it doesn't do so
     for `CHARACTER' types.  Worse, it just crashes with a barely
     servicable diagnostic.  If the time can't be taken soon to finish
     implementing this feature, at least a better way of diagnosing the
     problem should be provided.

   * To accept a lot of fine code, `g77' needs to accept `FORMAT' and
     `ENTRY' before an `IMPLICIT NONE'.

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

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

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

   * `g77' could use a `--help' option of some sort.

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

   * Some problems on RS/6000 regarding statement functions and/or
     `COMPLEX' arithmetic?

   * `g77' assumes that `INTEGER' 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 `INTEGER'
     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.

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

   * `g77' currently inserts needless padding for things like `COMMON
     A,IPAD' where `A' is `CHARACTER*1' and `IPAD' is `INTEGER*4' 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.

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

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

   * `g77' doesn't work on 64-bit configurations such as the Alpha.
     The problem is not yet adequately investigated, and some Alpha
     users are having quite a bit of success, so perhaps it depends on
     the OS and configuration of `gcc' they are using.

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

     But there might well be some problems with the portions of
     `__complex__' support in the back end that `g77' uses to implement
     `COMPLEX' and `DOUBLE COMPLEX'.  More investigation is needed, but
     bug reports are definitely welcome, since that can help speed
     investigation of problem areas.

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

     This might be fixed in version 2.7.2 of `gcc'.

