diff options
Diffstat (limited to 'contrib/gcc/f/BUGS')
| -rw-r--r-- | contrib/gcc/f/BUGS | 211 |
1 files changed, 211 insertions, 0 deletions
diff --git a/contrib/gcc/f/BUGS b/contrib/gcc/f/BUGS new file mode 100644 index 0000000..ae6efd9 --- /dev/null +++ b/contrib/gcc/f/BUGS @@ -0,0 +1,211 @@ +This file lists known bugs in the GNU Fortran compiler. Copyright (C) +1995, 1996 Free Software Foundation, Inc. You may copy, distribute, +and modify it freely as long as you preserve this copyright notice and +permission notice. + +Bugs in GNU Fortran +******************* + + This section identifies bugs that `g77' *users* might run into in +the `egcs'-1.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'. + + An online, "live" version of this document (derived directly from +the up-to-date mainline version of `g77' within `egcs') is available at +`http://egcs.cygnus.com/onlinedocs/g77_bugs.html'. + + For information on bugs that might afflict people who configure, +port, build, and install `g77', see "Problems Installing" in +`egcs/gcc/f/INSTALL'. + + * `g77' generates bad code for assignments, or other conversions, of + `REAL' or `COMPLEX' constant expressions to type `INTEGER(KIND=2)' + (often referred to as `INTEGER*8'). + + For example, `INTEGER*8 J; J = 4E10' is miscompiled on some + systems--the wrong value is stored in J. + + * The `IDate' Intrinsic (VXT) fails to return the year in the + documented, non-Y2K-compliant range of 0-99, instead returning 100 + for the year 2000. + + * Year 2000 (Y2K) compliance information is missing from the + documentation. + + * `g77' crashes when compiling I/O statements using keywords that + define `INTEGER' values, such as `IOSTAT=J', where J is other than + default `INTEGER' (such as `INTEGER*2'). + + * The `-ax' option is not obeyed when compiling Fortran programs. + (It is not passed to the `f771' driver.) + + * `g77' fails to warn about a reference to a function when the + corresponding *subsequent* function program unit disagrees with + the reference concerning the type of the function. + + * 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). + + * 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. + + * `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. + |
