| _Note:_ This file is automatically generated from the files |
| `bugs0.texi' and `bugs.texi'. `BUGS' is _not_ a source file, although |
| it is normally included within source distributions. |
| |
| This file lists known bugs in the GCC-3.1 version of the GNU Fortran |
| compiler. Copyright (C) 1995,1996,1997,1998,1999,2000 Free Software |
| Foundation, Inc. You may copy, distribute, and modify it freely as |
| long as you preserve this copyright notice and permission notice. |
| |
| Known Bugs In GNU Fortran |
| ************************* |
| |
| This section identifies bugs that `g77' _users_ might run into in |
| the GCC-3.1 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 |
| `gcc/gcc/f/NEWS'. There, lists of bugs fixed in various versions of |
| `g77' can help determine what bugs existed in prior versions. |
| |
| _Warning:_ The information below is still under development, and |
| might not accurately reflect the `g77' code base of which it is a part. |
| Efforts are made to keep it somewhat up-to-date, but they are |
| particularly concentrated on any version of this information that is |
| distributed as part of a _released_ `g77'. |
| |
| In particular, while this information is intended to apply to the |
| GCC-3.1 version of `g77', only an official _release_ of that version is |
| expected to contain documentation that is most consistent with the |
| `g77' product in that version. |
| |
| An online, "live" version of this document (derived directly from |
| the mainline, development version of `g77' within `gcc') is available |
| via `http://www.gnu.org/software/gcc/onlinedocs/g77_bugs.html'. Follow |
| the "Known Bugs" link. |
| |
| For information on bugs that might afflict people who configure, |
| port, build, and install `g77', see "Problems Installing" in |
| `gcc/gcc/f/INSTALL'. |
| |
| The following information was last updated on 2000-11-05: |
| |
| * `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. 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. |
| |
| * Previous versions of `g77' didn't emit information on variable and |
| array members of common blocks and equivalences for use with a |
| debugger (the `-g' command-line option). As of the version of |
| `g77' shipped with version 3.0 of `GCC', this is corrected. |
| |
| 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. |
| |
| * 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. Version |
| 0.6 should solve most or all remaining problems (such as |
| cross-compiling involving 64-bit machines). |
| |
| * `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. |
| |