Fortran script only runs when print statement added

2
votes

I am running an atmospheric model, and need to compile an executable to convert some files. If I compile the code as supplied, it runs but it gets stuck and doesn't ever complete. It doesn't give an error or anything like that.

After doing some testing by adding print statements to see where it was getting stuck, I've found that the executable only runs if I compile the code with a print statement in one of the subroutines.

The piece of code in question is the one here. Specifically, the code fails to run unless I put a print statement somewhere in the get_bottom_top_dim subroutine.

Does anyone know why this might be? It doesn't matter what the print statement is (currently I'm using print*, '!'). but as soon as I remove it or comment it out, the code no longer works.

I'm assuming it must have something to do with my machine or compiler (ifort 12.1.0), but I'm stumped as to what the problem is!

2
fortran
Please consider this as a comment. Have you tried to debug using a fortran debugger (on your machine) to identify where the program fails without the print statement and why it continues execution when you put the print statement? – Konstantinos Chertouras
This is a very large code and the main program is missing. Compile it with -check -warn -g -traceback and try to run it again. – Vladimir F

2 Answers

3
votes

This is an extended comment rather than an answer:

The situation you describe, inserting a print statement which apparently fixes a program, often arises when the underlying problem is due to either

a) an attempt to access an element outside the declared bounds of an array; or

b) a mismatch between dummy and actual arguments to some procedure.

Recompile your program with the compiler options to check interfaces at compile-time and to check array bounds at run-time.

0
votes

Fortran has evolved a LOT since I last used it but here's how to go about solving your problem.

  • Think of some hypotheses that could explain the symptoms, e.g. the compiler is optimizing the subroutine down to a no-op when it has no print side effect. Or a compiler bug is translating this code into something empty or an infinite loop or crashing code. (What exactly do you mean by "fails to run"?) Or the Linker is failing to link in some needed code unless the subroutine explicitly calls print. Or there's a bug in this subroutine and the print statement alters its symptoms e.g. by changing which data gets overwritten by an index-out-of-bounds bug.
  • Think of ways to test these hypotheses. You might already have observations adequate to rule out of some of them. You could decompile the object code to see if this subroutine is empty. Or step through it in a debugger. Or replace the print statement with a different side effect like logging to a file or to an in-memory text buffer. Or turn on all optional runtime memory checks and compile time warnings. Or simplify the code until the problem goes away, then binary search on bringing back code until the problem recurs.
  • Do the most likely or easiest tests first. Rule out some hypotheses, and iterate.