This file documents known bugs in the GNU Fortran system.
Copyright (C) 1995 Free Software Foundation, Inc.  You may copy,
distribute, and modify it freely as long as you preserve this copyright
notice and permission notice.  Contributed by James Craig Burley
(burley@gnu.ai.mit.edu).

1995-11-16

1. g77 statically assumes INTEGER constants range from -2**31 to 2**31-1,
   instead of determining their range from the actual range of the INTEGER
   type.  And, 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 0.6, when g77 will use the gcc back end's constant-handling
   mechanisms instead of its own.

2. g77 uses way too much memory and CPU time to process large aggregate
   areas having any initialized elements.  E.g. REAL A(1000000) followed
   by DATA A(1)/1/ will take up way too much time and space, including
   the size of the generated assembler file.  This is to be mitigated
   somewhat in 0.6.  (NOTE: 0.5.5 adds a warning message to at least
   notify the user before the compiler appears to hang.  See f/data.c,
   macro FFEDATA_sizeTOO_BIG_INIT_, for the minimum # of storage units
   that trigger the diagnostic.  Adjust as desired.  If 0, no diagnostic
   gets produced.)

3. g77 doesn't emit variable and array members of COMMON areas 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.

4. 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.

5. The current external-interface design, which includes naming of
   external procedures, COMMON blocks, and the library interface,
   has various usability problems, including things like adding
   underscores where not really necessary (and preventing easier
   inter-language operability) and yet not providing complete
   namespace freedom for user C code linked with Fortran apps (due
   to the naming of functions in the library, among other things).
   The GNU project should at least get all this "right" for systems
   it fully controls, such as the Hurd, and provide defaults and
   options for compatibility with existing systems and interoperability
   with popular existing compilers.

6. 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).

7. g77 currently requires application of a patch file to the gcc compiler
   tree (at least up through gcc version 2.7.0).  The necessary patches
   should be folded in to the mainline gcc distribution.  (Some combinations
   of versions of g77 and gcc might actually _require_ no patches, but the
   patch files will be provided anyway as long as there are more changes
   expected in subsequent releases, and these patch files might contain
   unnecessary, but possibly helpful, patches.)

8. Need option to suppress information messages (notes) in bad.c.  -w does
   this but also suppresses warnings.  The default should be to suppress
   info messages.

9. It should be possible to build the runtime without building cc1 etc.

10. g77 requires GNU C, not just ANSI C, to compile it.  Fixing this wouldn't
    be very hard (just tedious), but the code using GNU-C extensions is
    expected to be rewritten for 0.6, so there are no plans for an
    interim fix.

11. 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+g77-0.5.16.  This
    problem shows up only when compiling the Fortran program with -O.

12. There's a problem similar to the one mentioned in #11 above that
    shows up on SGI machines.  This problem shows up only when
    compiling the Fortran program with -O.

13. g77 doesn't work on 64-bit configurations such as the Alpha.  The
    problem is not yet adequately investigated.  As of 0.5.16, g77 issues
    a warning diagnostic whenever it is run after being built to
    generate code for a system with canonical types not 32 bits wide.

14. There are some known problems when using gdb on code compiled by g77.
    Inadequate investigation as of the release of 0.5.16 results in not
    knowing which products are the culprit, but gdb-4.14 definitely
    crashes when, for example, an attempt is made to print the contents
    of a COMPLEX*16 dummy array, on at least some Linux machines, plus
    some others.

15. 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.

16. 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.
