1 files changed, 130 insertions, 0 deletions
diff --git a/contrib/gcc/f/BUGS b/contrib/gcc/f/BUGS
new file mode 100644
index 0000000..acfe4ab
--- /dev/null
+++ b/contrib/gcc/f/BUGS
@@ -0,0 +1,130 @@
+_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.
+