Bugs in GNU Fortran

This section identifies bugs that g77 users might run into. 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 that might afflict people who configure, port, build, and install g77, Problems Installing.

• g77's version of gcc, and probably g77 itself, cannot be reliably used with the -O2 option (or higher) on Digital Semiconductor Alpha AXP machines. The problem is most immediately noticed in differences discovered by make compare following a bootstrap build using -O2. It also manifests itself as a failure to compile DATA statements such as DATA R/7./ correctly; in this case, R might be initialized to 4.0.

  Until this bug is fixed, use only -O1 or no optimization.

• 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. (Probably improved, but not wholly fixed, in 0.5.21.)
• The g77 command itself should more faithfully process options the way the gcc command does. For example, gcc accepts abbreviated forms of long options, g77 generally doesn't.
• 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. This is to be fixed in version 0.6, when g77 will use the gcc back end's constant-handling mechanisms to replace its own.

• 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. This is to be mitigated somewhat in version 0.6.

  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. See Initialization of Large Aggregate Areas, for information on how to change the point at which g77 decides to issue this warning.

• g77 doesn't emit variable and array members of common blocks 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.

  As of Version 0.5.19, a temporary kludge solution is provided whereby some rudimentary information on a member is written as a string that is the member's value as a character string.

  See Options for Code Generation Conventions, for information on the -fdebug-kludge option.

• 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 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's good for performance).

  It is possible that this is not a real bug, and could be considered a performance feature, but it might be important to provide the ability to Fortran code to specify minimum padding for aggregate areas such as common blocks---and, certainly, there is the potential, with the current setup, for interface differences in the way such areas are laid out between g77 and other compilers.

• g77 doesn't work perfectly on 64-bit configurations such as the Alpha. This problem is expected to be largely resolved as of version 0.5.20, and further addressed by 0.5.21. Version 0.6 should solve most or all related problems (such as 64-bit machines other than Digital Semiconductor (``DEC'') Alphas).

  One known bug that causes a compile-time crash occurs when compiling code such as the following with optimization:

  SUBROUTINE CRASH (TEMP)
  INTEGER*2 HALF(2)
  REAL TEMP
  HALF(1) = NINT (TEMP)
  END
  

  It is expected that a future version of g77 will have a fix for this problem, almost certainly by the time g77 supports the forthcoming version 2.8.0 of gcc.

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

  Version 0.5.20 of g77 works around this problem by not using the back end's support for COMPLEX. The new option -fno-emulate-complex avoids the work-around, reverting to using the same ``broken'' mechanism as that used by versions of g77 prior to 0.5.20.

• 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. This bug is in the gcc back end, and it apparently occurs only when compiling sufficiently complicated functions without the -O option.