If you are not sure whether you have found a bug, here are some guidelines:
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.
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
Some steps you can take to verify that the bug is not certainly
in the code you're compiling with
-W -Wall -O. These options enable many useful warning; the
-Ooption 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
-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 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.
See Overly Convenient Command-Line Options,
for information on the
-finit-local-zero options and how to convert
their use into selective changes in your own code.
ftnchekor a similar code-checking tool.
ftnchekcan be found at ftp://ftp.netlib.org/fortran or ftp://ftp.dsm.fordham.edu.
Here are some sample
Makefile rules using
"project" files to do cross-file checking and
to maintain dependencies automatically.
These assume the use of GNU
# 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)
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
It might mean the bug is in your code, and that
exposes it more readily than other compilers.