Initial integration of G77.

Please do a make cleandir before rebuilding gcc!

1 files changed, 161 insertions, 0 deletions

diff --git a/gnu/usr.bin/gcc/f/BUGS b/gnu/usr.bin/gcc/f/BUGS
new file mode 100644
index 00000000000..7faed1860bc
--- /dev/null
+++ b/gnu/usr.bin/gcc/f/BUGS
@@ -0,0 +1,161 @@
+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::.
+
+   * When using `-fugly', `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.
+
+   * Although `g77' generally supports `SELECT CASE', it doesn't do so
+     for `CHARACTER' types.  Worse, it just crashes with a barely
+     servicable diagnostic.  If the time can't be taken soon to finish
+     implementing this feature, at least a better way of diagnosing the
+     problem should be provided.
+
+   * To accept a lot of fine code, `g77' needs to accept `FORMAT' and
+     `ENTRY' before an `IMPLICIT NONE'.
+
+   * Some crashes occur when compiling under Solaris on x86 machines.
+
+   * 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.
+
+   * 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.
+
+   * `g77' could use a `--help' option of some sort.
+
+   * Some confusion in diagnostics concerning failing `INCLUDE'
+     statements from within `INCLUDE''d or `#include''d files.
+
+   * Some problems on RS/6000 regarding statement functions and/or
+     `COMPLEX' arithmetic?
+
+   * `g77' assumes that `INTEGER' 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 `INTEGER'
+     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.
+
+   * 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.
+
+   * `g77' currently inserts needless padding for things like `COMMON
+     A,IPAD' where `A' is `CHARACTER*1' and `IPAD' is `INTEGER*4' 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.
+
+   * 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'.
+
+   * SGI support is known to be a bit buggy.  The known problem shows
+     up only when compiling the Fortran program with `-O'.
+
+   * `g77' doesn't work on 64-bit configurations such as the Alpha.
+     The problem is not yet adequately investigated, and some Alpha
+     users are having quite a bit of success, so perhaps it depends on
+     the OS and configuration of `gcc' they are using.
+
+   * 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.
+
+     But there might well be some problems with the portions of
+     `__complex__' support in the back end that `g77' uses to implement
+     `COMPLEX' and `DOUBLE COMPLEX'.  More investigation is needed, but
+     bug reports are definitely welcome, since that can help speed
+     investigation of problem areas.
+
+   * 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.
+
+     This might be fixed in version 2.7.2 of `gcc'.
+