diff options
Diffstat (limited to 'contrib/gcc/f/BUGS')
| -rw-r--r-- | contrib/gcc/f/BUGS | 130 |
1 files changed, 0 insertions, 130 deletions
diff --git a/contrib/gcc/f/BUGS b/contrib/gcc/f/BUGS deleted file mode 100644 index acfe4ab..0000000 --- a/contrib/gcc/f/BUGS +++ /dev/null @@ -1,130 +0,0 @@ -_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.2 version of the GNU Fortran -compiler. Copyright (C) 1995,1996,1997,1998,1999,2000,2001,2002 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.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 -`gcc/gcc/f/NEWS'. There, lists of bugs fixed in various versions of -`g77' can help determine what bugs existed in prior versions. - - 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/Trouble.html'. -Follow the "Known Bugs" link. - - The following information was last updated on 2002-02-01: - - * `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. - - * `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. - - 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. - - * 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. - - * `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. - |
