freebsd-dev/contrib/gcc/f/BUGS

_Note:_ This file is automatically generated from the files
`bugs0.texi' and `bugs.texi'.  `BUGS' is _not_ a source file, although
it is normally included within source distributions.

   This file lists known bugs in the GCC-3.2 version of the GNU Fortran
compiler.  Copyright (C) 1995,1996,1997,1998,1999,2000,2001,2002 Free
Software Foundation, Inc.  You may copy, distribute, and modify it
freely as long as you preserve this copyright notice and permission
notice.

Known Bugs In GNU Fortran
*************************

   This section identifies bugs that `g77' _users_ might run into in
the GCC-3.2 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
`gcc/gcc/f/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/Trouble.html'.
Follow the "Known Bugs" link.

   The following information was last updated on 2002-02-01:

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

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

     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.

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

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