| *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 EGCS-1.2 version of the GNU |
| Fortran compiler. Copyright (C) 1995-1999 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 EGCS-1.2 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 |
| `egcs/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 |
| EGCS-1.2 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 `egcs') is available |
| via `http://egcs.cygnus.com/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 |
| `egcs/gcc/f/INSTALL'. |
| |
| The following information was last updated on 1999-04-03: |
| |
| * Automatic arrays possibly aren't working on HP-UX systems, at |
| least in HP-UX version 10.20. Writing into them apparently causes |
| over-writing of statically declared data in the main program. |
| This probably means the arrays themselves are being |
| under-allocated, or pointers to them being improperly handled, |
| e.g. not passed to other procedures as they should be. |
| |
| * `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. |
| |
| * `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. |
| |
| * 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 x86 target's `-malign-double' option no longer reliably aligns |
| double-precision variables and arrays when they are placed in the |
| stack frame. |
| |
| This can significantly reduce the performance of some applications, |
| even on a run-to-run basis (that is, performance measurements can |
| vary fairly widely depending on whether frequently used variables |
| are properly aligned, and that can change from one program run to |
| the next, even from one procedure call to the next). |
| |
| Versions 0.5.22 and earlier of `g77' included a patch to `gcc' |
| that enabled this, but that patch has been deemed an improper |
| (probably buggy) one for version 2.8 of `gcc' and for `egcs'. |
| |
| Note that version 1.1 of `egcs' aligns double-precision variables |
| and arrays when they are in static storage even if |
| `-malign-double' is not specified. |
| |
| There is ongoing investigation into how to make `-malign-double' |
| work properly, also into how to make it unnecessary to get all |
| double-precision variables and arrays aligned when such alignment |
| would not violate the relevant specifications for processor and |
| inter-procedural interfaces. |
| |
| For a suite of programs to test double-precision alignment, see |
| `ftp://alpha.gnu.org/gnu/g77/align/'. |
| |
| * 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. |
| |