15.2 Known Bugs In GNU Fortran

This section identifies bugs that g77 users might run into in the GCC-3.4.4 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 News About GNU Fortran. There, lists of bugs fixed in various versions of g77 can help determine what bugs existed in prior versions.

The following information was last updated on 2004-05-18:

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

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

  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. A warning message is issued when g77 sees code that provides initial values (e.g. via DATA) to an aggregate area (COMMON or EQUIVALENCE, or even a large enough array or CHARACTER variable) that is large enough to increase g77's compile time by roughly a factor of 10.

  This size currently is quite small, since g77 currently has a known bug requiring too much memory and time to handle such cases. In gcc/gcc/f/data.c, the macro FFEDATA_sizeTOO_BIG_INIT_ is defined to the minimum size for the warning to appear. The size is specified in storage units, which can be bytes, words, or whatever, on a case-by-case basis.

  After changing this macro definition, you must (of course) rebuild and reinstall g77 for the change to take effect.

  Note that, as of version 0.5.18, improvements have reduced the scope of the problem for sparse initialization of large arrays, especially those with large, contiguous uninitialized areas. However, the warning is issued at a point prior to when g77 knows whether the initialization is sparse, and delaying the warning could mean it is produced too late to be helpful.

  Therefore, the macro definition should not be adjusted to reflect sparse cases. Instead, adjust it to generate the warning when densely initialized arrays begin to cause responses noticeably slower than linear performance would suggest.

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

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