950315

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, 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 before the main program unit is activated.

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 J,I"
   where J is INTEGER*2 and I is INTEGER*4 on machines like x86, because
   the back end insists that I 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.6.3).  The necessary patches
   should be folded in to the mainline gcc distribution.

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.

12. The -I and related -i command-line options do not affect INCLUDE
    statements.
