If you are not sure whether you have found a bug, here are some guidelines:
Many, perhaps most, bug reports against g77
turn out to
be bugs in the user's code.
While we find such bug reports educational, they sometimes take
a considerable amount of time to track down or at least respond
to--time we could be spending making g77
, not some user's
code, better.
Some steps you can take to verify that the bug is not certainly
in the code you're compiling with g77
:
g77
options `-W -Wall -O'.
These options enable many useful warning; the `-O' option
enables flow analysis that enables the uninitialized-variable
warning.
If you investigate the warnings and find evidence of possible bugs
in your code, fix them first and retry g77
.
g77
options `-finit-local-zero',
`-fno-automatic', `-ffloat-store', and various
combinations thereof.
If your code works with any of these combinations, that is not
proof that the bug isn't in g77
---a g77
bug exposed
by your code might simply be avoided, or have a different, more subtle
effect, when different options are used--but it can be a
strong indicator that your code is making unawarranted assumptions
about the Fortran dialect and/or underlying machine it is
being compiled and run on.
See section Overly Convenient Command-line Options,
for information on the `-fno-automatic' and
`-finit-local-zero' options and how to convert
their use into selective changes in your own code.
ftnchek
or a similar code-checking
tool.
ftncheck
can be found at @uref{ftp://ftp.netlib.org/fortran}
or @uref{ftp://ftp.dsm.fordham.edu}.
f2c
.
If it does not work on at least one other compiler (assuming the
compiler supports the features the code needs), that is a strong
indicator of a bug in the code.
However, even if your code works on many compilers except
g77
, that does not mean the bug is in g77
.
It might mean the bug is in your code, and that g77
simply
exposes it more readily than other compilers.
Go to the first, previous, next, last section, table of contents.