diff options
Diffstat (limited to 'gcc/f/BUGS')
| -rw-r--r-- | gcc/f/BUGS | 198 |
1 files changed, 198 insertions, 0 deletions
diff --git a/gcc/f/BUGS b/gcc/f/BUGS new file mode 100644 index 00000000000..ebeaedb7b46 --- /dev/null +++ b/gcc/f/BUGS @@ -0,0 +1,198 @@ +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::. + + * Work is needed on the `SIGNAL()' intrinsic to ensure that pointers + and integers are properly handled on all targets, including 64-bit + machines. + + * When using `-fugly-comma', `g77' assumes an extra `%VAL(0)' + argument is to be passed to intrinsics taking no arguments, such + as `IARGC()', which in turn reject such a call. Although this has + been worked around for 0.5.18 due to changes in the handling of + intrinsics, `g77' needs to do the ugly-argument-appending trick + only for external-function invocation, as this would probably be + more consistent with compilers that default to using that trick. + + * 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. (Probably improved, but not wholly + fixed, in 0.5.21.) + + * The `g77' command itself should more faithfully process options + the way the `gcc' command does. For example, `gcc' accepts + abbreviated forms of long options, `g77' generally doesn't. + + * 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' 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's good for performance). + + It is possible that this is not a real bug, and could be considered + a performance feature, but it might be important to provide the + ability to Fortran code to specify minimum padding for aggregate + areas such as common blocks--and, certainly, there is the + potential, with the current setup, for interface differences in + the way such areas are laid out between `g77' and other compilers. + + * Some crashes occur when compiling under Solaris on x86 machines. + + Nothing has been heard about any such problems for some time, so + this is considering a closed item as of 0.5.20. Please submit any + bug reports pertinent to `g77''s support for Solaris/x86 systems. + + * RS/6000 support is not complete as of the gcc 2.6.3 back end. The + 2.7.0 back end appears to fix this problem, or at least mitigate + it significantly, but there is at least one known problem that is + likely to be a code-generation bug in `gcc-2.7.0' plus + `g77-0.5.16'. This problem shows up only when compiling the + Fortran program with `-O'. + + Nothing has been heard about any RS/6000 problems for some time, + so this is considering a closed item as of 0.5.20. Please submit + any bug reports pertinent to `g77''s support for RS/6000 systems. + + * SGI support is known to be a bit buggy. The known problem shows + up only when compiling the Fortran program with `-O'. + + It is possible these problems have all been fixed in 0.5.20 by + emulating complex arithmetic in the front end. Please submit any + bug reports pertinent to `g77''s support for SGI systems. + + * `g77' doesn't work perfectly on 64-bit configurations such as the + Alpha. This problem is expected to be largely resolved as of + version 0.5.20, and further addressed by 0.5.21. Version 0.6 + should solve most or all related problems (such as 64-bit machines + other than Digital Semiconductor ("DEC") Alphas). + + One known bug that causes a compile-time crash occurs when + compiling code such as the following with optimization: + + SUBROUTINE CRASH (TEMP) + INTEGER*2 HALF(2) + REAL TEMP + HALF(1) = NINT (TEMP) + END + + It is expected that a future version of `g77' will have a fix for + this problem, almost certainly by the time `g77' supports the + forthcoming version 2.8.0 of `gcc'. + + * 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. + + * There seem to be some problems with passing constants, and perhaps + general expressions (other than simple variables/arrays), to + procedures when compiling on some systems (such as i386) with + `-fPIC', as in when compiling for ELF targets. The symptom is + that the assembler complains about invalid opcodes. More + investigation is needed, but the problem is almost certainly in + the gcc back end, and it apparently occurs only when compiling + sufficiently complicated functions *without* the `-O' option. + |