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':
* Compile your code using the `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'.
* Compile your code using the `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 unwarranted assumptions about
the Fortran dialect and/or underlying machine it is being compiled
and run on.
Note: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.
* Validate your code with `ftnchek' or a similar code-checking tool.
`ftnchek' can be found at `ftp://ftp.netlib.org/fortran' or
`ftp://ftp.dsm.fordham.edu'.
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'.
# Dummy suffix for ftnchek targets:
.SUFFIXES: .chek
.PHONY: chekall
# How to compile .f files (for implicit rule):
FC = g77
# Assume `include' directory:
FFLAGS = -Iinclude -g -O -Wall
# Flags for ftnchek:
CHEK1 = -array=0 -include=includes -noarray
CHEK2 = -nonovice -usage=1 -notruncation
CHEKFLAGS = $(CHEK1) $(CHEK2)
# Run ftnchek with all the .prj files except the one corresponding
# to the target's root:
%.chek : %.f ; \
ftnchek $(filter-out $*.prj,$(PRJS)) $(CHEKFLAGS) \
-noextern -library $<
# Derive a project file from a source file:
%.prj : %.f ; \
ftnchek $(CHEKFLAGS) -noextern -project -library $<
# The list of objects is assumed to be in variable OBJS.
# Sources corresponding to the objects:
SRCS = $(OBJS:%.o=%.f)
# ftnchek project files:
PRJS = $(OBJS:%.o=%.prj)
# Build the program
prog: $(OBJS) ; \
$(FC) -o $ $(OBJS)
chekall: $(PRJS) ; \
ftnchek $(CHEKFLAGS) $(PRJS)
prjs: $(PRJS)
# For Emacs M-x find-tag:
TAGS: $(SRCS) ; \
etags $(SRCS)
# Rebuild dependencies:
depend: ; \
sfmakedepend -I $(PLTLIBDIR) -I includes -a prj $(SRCS1)
* 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 *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.