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,
section Problems Installing.
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.
Whether these problems exist on other configurations
is not yet known.
Similarly, when these problems will be fixed is
not yet known.
We believe they do not occur in egcs
version 1.0.3.
GOTO
and ASSIGN are involved.
Version 0.5.22 of g77 fixed this problem
by patching the version of gcc on which it
is based.
Version 1.1 of egcs will fix
this problem as well.
It is not known when a version of gcc
that fixes this problem will be made available.
COMPLEX arithmetic
(especially multiplication).
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.)
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.
See section Initialization of Large Aggregate Areas,
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.
See section Options for Code Generation Conventions,
for information on the `-fdebug-kludge' option.
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.
g77 doesn't work perfectly on 64-bit configurations
such as the Digital Semiconductor ("DEC") Alpha.
This problem is expected to be 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).
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.
Go to the first, previous, next, last section, table of contents.