CFD Online Discussion Forums

CFD Online Discussion Forums (
-   Main CFD Forum (
-   -   F77 Compile. (

CFD User. November 16, 2004 13:46

F77 Compile.

I am having trouble using a fortran f77 compiler to compile my code. If I include a statement that writes (for example) 'hello' to screen, the code fails (i.e, something strange occurs to other variables in this routine). If I don't write this line, everything is fine. If I write this line elsewhere everything is fine. I use f77 -g -check_bounds and I am not told anything aobut overflows etc that may be causing this bizarre problem. Does anyone have any ideas? I hope I have asked in the right place.

Zeng November 16, 2004 22:01

Re: F77 Compile.
(1) try to debug by using gdb etc. (2) change a fortran compiler, maybe you can get more useful information.

CFD User. November 17, 2004 10:27

Re: F77 Compile.
Thank you. I have done both. Changing compiler gets rid of the problem (at least it seems to), but it still doesn't explain why I was having problems with the other one.

Thanks for your comments.

Tom November 17, 2004 11:33

Re: F77 Compile.
I've had similar problems (usually in reverse - the code crashes so I insert a write statement and it then miraculously works). The cause of the problem is usually a memory/alignment fault. A common cause is that, for example, you have a subroutine that takes 3 arguments but is called with only 2 - another possibility is that an array passed to the subroutine is smaller than it is declared within the subprogram.

Ananda Himansu November 17, 2004 13:45

Re: F77 Compile.
if the problem disappeared under a different compiler, it is possibly due to a compiler bug, though this possibility is much unlikelier than the probability of a bug in CFD User's own program.

Another possibility in addition to those Tom mentioned, is that writing to the screen at that juncture might interfere with an already open logical unit 5 which has been previously associated with an input file. I had this happen to a colleague just last week. Under the old compiler, put a write statement in exactly the same place that causes the problem, but write to a different unit number, say 44, instead of to the screen (unit 6 or *). If the program does not then misbehave, look for whether a disk file that has previously been opened for reading as logical unit 5 is later read from for input. The symptom would be that your previous error message would refer to an end-of-file condition on an attempted read (because the write statement effectively truncates the input file at the file pointer position after write).

CFD User, you do mention that placing a write statement elsewhere in the program does not produce the bug symptoms. You do not mention whether the location that does result in bug symptoms is in within a DO loop or an IF block?

If you find the cause of the bug, please let us know the cause. Subtle bugs like this are interesting to many programmers.

Zeng November 17, 2004 22:12

Re: F77 Compile.
Based on your information, maybe, you have used a undefined (or without intialization) variable.

Sincerely, Zeng

CFD User. November 18, 2004 07:51

Re: F77 Compile.
Hi, Thank you all for you comments.

That is interesting Zeng. I discovered a variable being used in another routine which was used before it had been defined or initialised. I didn't think this was thec asue, but fixing this problem (which occurs in 5 or 6 places in the routine!) seems to fix the crazy problem! How would sometihing being undefined in one subroutine interfer with values apparently unrelated values in another...and then, only when I use write(*,*) statements or write(23,*) (write to file) statements at particular locations! Its all a bit odd.

Steve November 18, 2004 09:29

Re: F77 Compile.
Odd behaviour that you can't quite understand and that goes away if you switch compiler is nearly always related to memory trampling or uninitialised variables. It really pays to compile on many different platforms. It's often the case that a non-fatal (but annoying) error on one platform may show up as a fatal (and therefore debuggable) error elsewhere.

ag November 18, 2004 09:55

Re: F77 Compile.
The variable will have some value when it gets used the first time - just not the value you intend it to have. Without initialization it will have some value that comes from the element of memory it gets assigned during compilation, and when you put a write statement in, that assignment will shift so that the non-initialized value will change just enough to allow the code to work.

Zeng November 19, 2004 15:58

Re: F77 Compile.
Glad to know you have fixed your problem. The assigned value without initialization depends on your compiler and working enviroment, and it therfore looks very strange. You are luck, becuase you have found error. It is also possible that the program could work without any error message, but the result is a non-physical solution, and it is very diffcult to fix the error caused by uninitialized varables.

All times are GMT -4. The time now is 19:15.