Go to the first, previous, next, last section, table of contents. ---------------------------------------------------------------------------- Known Causes of Trouble with GNU Fortran This section describes known problems that affect users of GNU Fortran. Most of these are not GNU Fortran bugs per se--if they were, we would fix them. But the result for a user might be like the result of a bug. Some of these problems are due to bugs in other software, some are missing features that are too much work to add, and some are places where people's opinions differ as to what is best. Information on bugs that show up when configuring, porting, building, or installing g77 is not provided here. See section Problems Installing. (Note that some of this portion of the manual is lifted directly from the gcc manual, with minor modifications to tailor it to users of g77. Anytime a bug seems to have more to do with the gcc portion of g77, See section `Known Causes of Trouble with GNU CC' in Using and Porting GNU CC.) Bugs Not In GNU Fortran These are bugs to which the maintainers often have to reply, "but that isn't a bug in g77...". Some of these already are fixed in new versions of other software; some still need to be fixed; some are problems with how g77 is installed or is being used; some just cannot be addressed at this time until more is known about the problem. Please don't re-report these bugs to the g77 maintainers--if you must remind someone how important it is to you that the problem be fixed, talk to the people responsible for the other products identified below, but preferably only after you've tried the latest versions of those products. The g77 maintainers have their hands full working on just fixing and improving g77, without serving as a clearinghouse for all bugs that happen to affect g77 users. See section Collected Fortran Wisdom, for information on behavior of Fortran programs, and the programs that compile them, that might be thought to indicate bugs. Cannot Link Fortran Programs On some systems, perhaps just those with out-of-date (shared?) libraries, unresolved-reference errors happen when linking g77-compiled programs (which should be done using g77). If this happens to you, try appending `-lc' to the command you use to link the program, e.g. `g77 foo.f -lc'. g77 already specifies `-lf2c -lm' when it calls the linker, but it cannot also specify `-lc' because not all systems have a file named `libc.a'. It is unclear at this point whether there are legitimately installed systems where `-lf2c -lm' is insufficient to resolve code produced by g77. If your program doesn't link due to unresolved references to names like `_main', make sure you're using the g77 command to do the link, since this command ensures that the necessary libraries are loaded by specifying `-lf2c -lm' when it invokes the gcc command to do the actual link. (Use the `-v' option to discover more about what actually happens when you use the g77 and gcc commands.) Also, try specifying `-lc' as the last item on the g77 command line, in case that helps. Large Common Blocks On some older GNU/Linux systems, programs with common blocks larger than 16MB cannot be linked without some kind of error message being produced. This is a bug in older versions of ld, fixed in more recent versions of binutils, such as version 2.6. Debugger Problems 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 products are the culprit, but `gdb-4.14' definitely crashes when, for example, an attempt is made to print the contents of a COMPLEX(KIND=2) dummy array, on at least some GNU/Linux machines, plus some others. NeXTStep Problems Developers of Fortran code on NeXTStep (all architectures) have to watch out for the following problem when writing programs with large, statically allocated (i.e. non-stack based) data structures (common blocks, saved arrays). Due to the way the native loader (`/bin/ld') lays out data structures in virtual memory, it is very easy to create an executable wherein the `__DATA' segment overlaps (has addresses in common) with the `UNIX STACK' segment. This leads to all sorts of trouble, from the executable simply not executing, to bus errors. The NeXTStep command line tool ebadexec points to the problem as follows: % /bin/ebadexec a.out /bin/ebadexec: __LINKEDIT segment (truncated address = 0x3de000 rounded size = 0x2a000) of executable file: a.out overlaps with UNIX STACK segment (truncated address = 0x400000 rounded size = 0x3c00000) of executable file: a.out (In the above case, it is the `__LINKEDIT' segment that overlaps the stack segment.) This can be cured by assigning the `__DATA' segment (virtual) addresses beyond the stack segment. A conservative estimate for this is from address 6000000 (hexadecimal) onwards--this has always worked for me [Toon Moene]: % g77 -segaddr __DATA 6000000 test.f % ebadexec a.out ebadexec: file: a.out appears to be executable % Browsing through `gcc/f/Makefile.in', you will find that the f771 program itself also has to be linked with these flags--it has large statically allocated data structures. (Version 0.5.18 reduces this somewhat, but probably not enough.) (The above item was contributed by Toon Moene (@email{toon@moene.indiv.nluug.nl}).) Stack Overflow g77 code might fail at runtime (probably with a "segmentation violation") due to overflowing the stack. This happens most often on systems with an environment that provides substantially more heap space (for use when arbitrarily allocating and freeing memory) than stack space. Often this can be cured by increasing or removing your shell's limit on stack usage, typically using limit stacksize (in csh and derivatives) or ulimit -s (in sh and derivatives). Increasing the allowed stack size might, however, require changing some operating system or system configuration parameters. You might be able to work around the problem by compiling with the `-fno-automatic' option to reduce stack usage, probably at the expense of speed. See section Maximum Stackable Size, for information on patching g77 to use different criteria for placing local non-automatic variables and arrays on the stack. However, if your program uses large automatic arrays (for example, has declarations like `REAL A(N)' where `A' is a local array and `N' is a dummy or COMMON variable that can have a large value), neither use of `-fno-automatic', nor changing the cut-off point for g77 for using the stack, will solve the problem by changing the placement of these large arrays, as they are necessarily automatic. g77 currently provides no means to specify that automatic arrays are to be allocated on the heap instead of the stack. So, other than increasing the stack size, your best bet is to change your source code to avoid large automatic arrays. Methods for doing this currently are outside the scope of this document. (Note: If your system puts stack and heap space in the same memory area, such that they are effectively combined, then a stack overflow probably indicates a program that is either simply too large for the system, or buggy.) Strange Behavior at Run Time g77 code might fail at runtime with "segmentation violation", "bus error", or even something as subtle as a procedure call overwriting a variable or array element that it is not supposed to touch. These can be symptoms of a wide variety of actual bugs that occurred earlier during the program's run, but manifested themselves as visible problems some time later. Overflowing the bounds of an array--usually by writing beyond the end of it--is one of two kinds of bug that often occurs in Fortran code. The other kind of bug is a mismatch between the actual arguments passed to a procedure and the dummy arguments as declared by that procedure. Both of these kinds of bugs, and some others as well, can be difficult to track down, because the bug can change its behavior, or even appear to not occur, when using a debugger. That is, these bugs can be quite sensitive to data, including data representing the placement of other data in memory (that is, pointers, such as the placement of stack frames in memory). Plans call for improving g77 so that it can offer the ability to catch and report some of these problems at compile, link, or run time, such as by generating code to detect references to beyond the bounds of an array, or checking for agreement between calling and called procedures. In the meantime, finding and fixing the programming bugs that lead to these behaviors is, ultimately, the user's responsibility, as difficult as that task can sometimes be. Floating-point Errors Some programs appear to produce inconsistent floating-point results compiled by g77 versus by other compilers. Often the reason for this behavior is the fact that floating-point values are represented on almost all Fortran systems by approximations, and these approximations are inexact even for apparently simple values like 0.1, 0.2, 0.3, 0.4, 0.6, 0.7, 0.8, 0.9, 1.1, and so on. Most Fortran systems, including all current ports of g77, use binary arithmetic to represent these approximations. Therefore, the exact value of any floating-point approximation as manipulated by g77-compiled code is representable by adding some combination of the values 1.0, 0.5, 0.25, 0.125, and so on (just keep dividing by two) through the precision of the fraction (typically around 23 bits for REAL(KIND=1), 52 for REAL(KIND=2)), then multiplying the sum by a integral power of two (in Fortra...
alvin888