| 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. |
| |