1 files changed, 221 insertions, 0 deletions
diff --git a/gcc/f/BUGS b/gcc/f/BUGS
new file mode 100755
index 0000000..703393f
--- /dev/null
+++ b/gcc/f/BUGS
@@ -0,0 +1,221 @@
+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.
+
+   * `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).
+
+   * 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.
+
+   * `g77' sometimes produces invalid assembler code when using the
+     `-fPIC' option (such as compiling for ELF targets) on the Intel
+     x86 architecture target.  The symptom is that the assembler
+     complains about invalid opcodes.  This bug is in the `gcc' back
+     end.
+
+     Fixed in `egcs' version 1.0.2.
+
+   * `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.
+