egcs projects compiler system

Exact copy of the snapshot, except for the removal of
	texinfo/
	gcc/ch/
	libchill/

1 files changed, 159 insertions, 0 deletions

diff --git a/gnu/egcs/gcc/f/BUGS b/gnu/egcs/gcc/f/BUGS
new file mode 100644
index 00000000000..f97b75e3949
--- /dev/null
+++ b/gnu/egcs/gcc/f/BUGS
@@ -0,0 +1,159 @@
+*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 EGCS-1.2 version of the GNU
+Fortran compiler.  Copyright (C) 1995-1999 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 EGCS-1.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
+`egcs/gcc/f/NEWS'.  There, lists of bugs fixed in various versions of
+`g77' can help determine what bugs existed in prior versions.
+
+   *Warning:* The information below is still under development, and
+might not accurately reflect the `g77' code base of which it is a part.
+Efforts are made to keep it somewhat up-to-date, but they are
+particularly concentrated on any version of this information that is
+distributed as part of a *released* `g77'.
+
+   In particular, while this information is intended to apply to the
+EGCS-1.2 version of `g77', only an official *release* of that version
+is expected to contain documentation that is most consistent with the
+`g77' product in that version.
+
+   An online, "live" version of this document (derived directly from
+the mainline, development version of `g77' within `egcs') is available
+via `http://egcs.cygnus.com/onlinedocs/g77_bugs.html'.  Follow the
+"Known Bugs" link.
+
+   For information on bugs that might afflict people who configure,
+port, build, and install `g77', see "Problems Installing" in
+`egcs/gcc/f/INSTALL'.
+
+   The following information was last updated on 1999-05-06:
+
+   * `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.  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.
+
+   * `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.
+
+   * 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).
+
+   * `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.
+