jmleonar@crdec-vax2.arpa (jle) (03/06/88)
Folks, for those who answered my recent post regarding linking C
and F77 routines, thanks, it let me finish the job fast. Now, there
seems to be a small problem with the -O switch of the F77 compiler,
namely the code bombs horribly when it's used.
To be explicit, the code compiles without the -O flag, and the resulting
program runs correctly (i.e. the results match those obtained on another
OS/machine), but it runs slowly. Benchmarks indicate that the code,
running on a 785 "appears" to be the same speed as a 730 or 750 (?!).
The man entry for F77 indicated that the compiler was experimental, and
that the optimizer was known to produce errors. What I'm interested in
knowing is (1) Is the effect of the optimizer worth the effort needed to
figure what routines bomb? (2) Is this a common event - or am I subject
to a special case? (3) Is there a better F77 than the portable one
(there has to be...), and does it/do they run under BSD?
I'd appreciate learning of/from those who have used BSD/F77 to develop
numerically intensive codes (mine is a computational chemistry application).
Thanks in advance,
Joe Leonard
<jmleonar@crdec.arpa>ags@s.cc.purdue.edu (Dave Seaman) (03/06/88)
In article <12147@brl-adm.ARPA> jmleonar@crdec-vax2.arpa (jle) writes: >Folks, for those who answered my recent post regarding linking C >and F77 routines, thanks, it let me finish the job fast. Now, there >seems to be a small problem with the -O switch of the F77 compiler, >namely the code bombs horribly when it's used. > >To be explicit, the code compiles without the -O flag, and the resulting >program runs correctly ... It may very well be that your problem is faulty optimization, but that is not the only possible explanation. The fact that the program apparently "runs correctly" without optimization does not prove that the program is correct. I constantly encounter faulty programs that appear to "run correctly" in one environment (optimization level, compiler, machine) and fail in a different environment. It is tempting to assume that the processor is at fault, but that is frequently not the case. If it were my program, I would want to find out what is wrong before trusting ANY answers that it computes. -- Dave Seaman ags@j.cc.purdue.edu