Initial revision

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@14772 138bc75d-0d04-0410-961f-82ee72b054a4

1 files changed, 198 insertions, 0 deletions

diff --git a/gcc/f/BUGS b/gcc/f/BUGS
new file mode 100644
index 00000000000..ebeaedb7b46
--- /dev/null
+++ b/gcc/f/BUGS
@@ -0,0 +1,198 @@
+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::.
+
+   * 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.
+