Have You Found a Bug?

If you are not sure whether you have found a bug, here are some guidelines:

If the compiler gets a fatal signal, for any input whatever, that is a
compiler bug.
Reliable compilers never crash--they just remain obsolete.

If the compiler produces invalid assembly code, for any input whatever,
that is a compiler bug, unless the
compiler reports errors (not just warnings) which would ordinarily
prevent the assembler from being run.

If the compiler produces valid assembly code that does not correctly
execute the input source code, that is a compiler bug.

However, you must double-check to make sure, because you might have run
into an incompatibility between GNU Fortran and traditional Fortran.
These incompatibilities might be considered
bugs, but they are inescapable consequences of valuable features.

Or you might have a program whose behavior is undefined, which happened
by chance to give the desired results with another Fortran compiler.
It is best to check the relevant Fortran standard thoroughly if
it is possible that the program indeed does something undefined.

After you have localized the error to a single source line, it should
be easy to check for these things.
If your program is correct and well defined, you have found
a compiler bug.

It might help if, in your submission, you identified the specific
language in the relevant Fortran standard that specifies the
desired behavior, if it isn't likely to be obvious and agreed-upon
by all Fortran users.

If the compiler produces an error message for valid input, that is a
compiler bug.

If the compiler does not produce an error message for invalid input,
that is a compiler bug.
However, you should note that your idea of
"invalid input" might be someone else's idea
of "an extension" or "support for traditional practice".

If you are an experienced user of Fortran compilers, your suggestions
for improvement of GNU Fortran are welcome in any case.

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:

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 unwarranted assumptions
about the Fortran dialect and/or underlying machine it is
being compiled and run on.

Here are some sample Makefile rules using ftnchek
"project" files to do cross-file checking and sfmakedepend
(from ftp://ahab.rutgers.edu/pub/perl/sfmakedepend)
to maintain dependencies automatically.
These assume the use of GNU make.

Try your code out using other Fortran compilers, such as 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 exceptg77, 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.