Known Bugs - Using and Porting GNU Fortran (original) (raw)

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 (COMMONor EQUIVALENCE, or even a large enough array or CHARACTERvariable) that is large enough to increase g77's compile time by roughly a factor of 10.

This size currently is quite small, since g77currently has a known bug requiring too much memory and time to handle such cases. In gcc/gcc/f/data.c, the macroFFEDATA_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.

Debugging g77-compiled code using debuggers other thangdb 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 g77developers, seems like a much larger, unknown problem, and is a lower priority than making g77 and gdbwork 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.