This section identifies bugs that
might run into in the GCC-3.1 version
This includes bugs that are actually in the
back end (GBE) or in
libf2c, because those
sets of code are at least somewhat under the control
of (and necessarily intertwined with)
so it isn't worth separating them out.
For information on bugs in other versions of
see News About GNU Fortran.
There, lists of bugs fixed in various versions of
can help determine what bugs existed in prior versions.
An online, "live" version of this document
(derived directly from the mainline, development version
is available via
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
(although it does warn about this in a
g77's straightforward handling of
label references and definitions sometimes prevents the GBE
from unrolling loops.
Until this is solved, try inserting or removing
statements as the terminal statement, using the
form instead, and so on.
statements from within
g77 assumes that
INTEGER(KIND=1) constants range
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.
REAL A(1000000) followed by
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
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.)
g77 does display a warning message to
notify the user before the compiler appears to hang.
A warning message is issued when
g77 sees code that provides
initial values (e.g. via
DATA) to an aggregate area (
EQUIVALENCE, or even a large enough array or
that is large enough to increase
g77's compile time by roughly
a factor of 10.
This size currently is quite small, since
currently has a known bug requiring too much memory
and time to handle such cases.
gcc/gcc/f/data.c, the macro
FFEDATA_sizeTOO_BIG_INIT_ is defined
to the minimum size for the warning to appear.
The size is specified in storage units,
which can be bytes, words, or whatever, on a case-by-case basis.
After changing this macro definition, you must
(of course) rebuild and reinstall
the change to take effect.
Note that, as of version 0.5.18, improvements have
reduced the scope of the problem for sparse
initialization of large arrays, especially those
with large, contiguous uninitialized areas.
However, the warning is issued at a point prior to
g77 knows whether the initialization is sparse,
and delaying the warning could mean it is produced
too late to be helpful.
Therefore, the macro definition should not be adjusted to reflect sparse cases. Instead, adjust it to generate the warning when densely initialized arrays begin to cause responses noticeably slower than linear performance would suggest.
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.
g77-compiled code using debuggers other than
gdb is likely not to work.
gdb to work together is a known
g77 to work properly with other
debuggers, for which source code often is unavailable to
developers, seems like a much larger, unknown problem,
and is a lower priority than making
work together properly.
On the other hand, information about problems other debuggers
g77 output might make it easier to properly
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
INTEGER(KIND=1) on machines like x86,
because the back end insists that
be aligned to a 4-byte boundary,
but the processor has no such requirement
(though it is usually good for performance).
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.
libf2c routines that perform some run-time
were modified circa version 0.5.20 of
to work properly even in the presence of aliased operands.
netlib versions of
differ on how this is accomplished,
the main differences are that we believe
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.