diff options
Diffstat (limited to 'gcc/f/BUGS')
| -rwxr-xr-x | gcc/f/BUGS | 221 |
1 files changed, 0 insertions, 221 deletions
diff --git a/gcc/f/BUGS b/gcc/f/BUGS deleted file mode 100755 index 703393f..0000000 --- a/gcc/f/BUGS +++ /dev/null @@ -1,221 +0,0 @@ -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. -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 that might afflict people who configure, -port, build, and install `g77', *Note Problems Installing::. - - * `g77' sometimes crashes when compiling code containing the - construct `CMPLX(0.)' or similar. This is a `gcc' back-end bug. - It can be worked around using `-fno-emulate-complex', though that - might trigger other, older bugs. Compiling without optimization - is another work-around. - - Fixed in `egcs' 1.1. - - * Automatic arrays 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. - - * Some Fortran code has been found to be miscompiled by `g77' built - on `gcc' version 2.8.1 on m68k-next-nextstep3 configurations when - using the `-O2' option. Even a C function is known to miscompile - on that configuration when using the `-O2 -funroll-loops' options. - - Fixed in `egcs'. - - * A code-generation bug afflicts Intel x86 targets when `-O2' is - specified compiling, for example, an old version of the `DNRM2' - routine. The x87 coprocessor stack is being mismanaged in cases - where assigned `GOTO' and `ASSIGN' are involved. - - Fixed in `egcs' version 1.1. - - * `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). - - * A compiler crash, or apparently infinite run time, can result when - compiling complicated expressions involving `COMPLEX' arithmetic - (especially multiplication). - - Fixed in `egcs' version 1.1. - - * 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. *Note Initialization of - Large Aggregate Areas: Large Initialization, for information on - how to change the point at which `g77' decides to issue this - warning. - - * `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. - - *Note Options for Code Generation Conventions: Code Gen Options, - for information on the `-fdebug-kludge' option. - - * 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' sometimes produces invalid assembler code when using the - `-fPIC' option (such as compiling for ELF targets) on the Intel - x86 architecture target. The symptom is that the assembler - complains about invalid opcodes. This bug is in the `gcc' back - end. - - Fixed in `egcs' version 1.0.2. - - * `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. - |