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-08-30

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).  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.  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 such a system.

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 productds 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. g77 sometimes gives the wrong info for messages like "In file
    included from...:".  In fact, so does gcc, though due to linguistic
    differences, the problem is more likely to show up when using g77.

    This is a bug in the gcc back end, actually.  The patch to fix this
    follows (apply via "patch -p1 -d gcc-2.7.0 -V t < gcc/f/BUGS", for
    example):

Tue Aug 22 10:08:08 1995  Craig Burley  (burley@gnu.ai.mit.edu)

	* toplev.c (report_error_function): Don't attempt to use input
	file stack to identify nesting of #include's if the file
	name (pointer) of the location being diagnosed is not the
	same as input_filename, since in that case the contents
	of the file stack are irrelevant -- they apply to only the
	current file.

*** gcc-2.7.0/toplev.c	Thu Jun 15 08:09:51 1995
--- g77-new/toplev.c	Tue Aug 22 09:56:54 1995
*************** report_error_function (file)
*** 1049,1053 ****
  
    if (input_file_stack && input_file_stack->next != 0
!       && input_file_stack_tick != last_error_tick)
      {
        fprintf (stderr, "In file included");
--- 1049,1054 ----
  
    if (input_file_stack && input_file_stack->next != 0
!       && input_file_stack_tick != last_error_tick
!       && file == input_filename)
      {
        fprintf (stderr, "In file included");
