gcc/f/BUGS

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

   * `g77' sometimes crashes when compiling code containing the
     construct `CMPLX(0.)' or similar.  This is a `gcc' back-end bug.
     It can be worked around using `-fno-emulate-complex', though that
     might trigger other, older bugs.  Compiling without optimization
     is another work-around.

     Fixed in `egcs' 1.1.

   * Automatic arrays aren't working on HP-UX systems, at least in
     HP-UX version 10.20.  Writing into them apparently causes
     over-writing of statically declared data in the main program.
     This probably means the arrays themselves are being
     under-allocated, or pointers to them being improperly handled,
     e.g. not passed to other procedures as they should be.

   * Some Fortran code has been found to be miscompiled by `g77' built
     on `gcc' version 2.8.1 on m68k-next-nextstep3 configurations when
     using the `-O2' option.  Even a C function is known to miscompile
     on that configuration when using the `-O2 -funroll-loops' options.

     Fixed in `egcs'.

   * 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 mismanaged in cases
     where assigned `GOTO' and `ASSIGN' are involved.

     Fixed in `egcs' version 1.1.

   * A compiler crash, or apparently infinite run time, can result when
     compiling complicated expressions involving `COMPLEX' arithmetic
     (especially multiplication).

     Fixed in `egcs' version 1.1.

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

   * 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.  This bug is
     in the gcc back end, and it apparently occurs only when compiling
     sufficiently complicated functions *without* the `-O' option.

     Fixed in `egcs' version 1.1.

   * `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 x86 target's `-malign-double' option no longer reliably aligns
     double-precision variables and arrays when they are placed in the
     stack frame.

     This can significantly reduce the performance of some applications,
     even on a run-to-run basis (that is, performance measurements can
     vary fairly widely depending on whether frequently used variables
     are properly aligned, and that can change from one program run to
     the next, even from one procedure call to the next).

     Versions 0.5.22 and earlier of `g77' included a patch to `gcc'
     that enabled this, but that patch has been deemed an improper
     (probably buggy) one for version 2.8 of `gcc' and for `egcs'.

     Note that version 1.1 of `egcs' aligns double-precision variables
     and arrays when they are in static storage even if
     `-malign-double' is not specified.

     There is ongoing investigation into how to make `-malign-double'
     work properly, also into how to make it unnecessary to get all
     double-precision variables and arrays aligned when such alignment
     would not violate the relevant specifications for processor and
     inter-procedural interfaces.

     For a suite of programs to test double-precision alignment, see
     `ftp://alpha.gnu.org/gnu/g77/align/'.

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