222 lines
10 KiB
Plaintext
222 lines
10 KiB
Plaintext
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.
|
|
|