|
[Sponsors] |
November 16, 2004, 13:46 |
F77 Compile.
|
#1 |
Guest
Posts: n/a
|
Hello,
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. |
|
November 16, 2004, 22:01 |
Re: F77 Compile.
|
#2 |
Guest
Posts: n/a
|
(1) try to debug by using gdb etc. (2) change a fortran compiler, maybe you can get more useful information.
|
|
November 17, 2004, 10:27 |
Re: F77 Compile.
|
#3 |
Guest
Posts: n/a
|
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. |
|
November 17, 2004, 11:33 |
Re: F77 Compile.
|
#4 |
Guest
Posts: n/a
|
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.
|
|
November 17, 2004, 13:45 |
Re: F77 Compile.
|
#5 |
Guest
Posts: n/a
|
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. |
|
November 17, 2004, 22:12 |
Re: F77 Compile.
|
#6 |
Guest
Posts: n/a
|
Based on your information, maybe, you have used a undefined (or without intialization) variable.
Sincerely, Zeng |
|
November 18, 2004, 07:51 |
Re: F77 Compile.
|
#7 |
Guest
Posts: n/a
|
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. |
|
November 18, 2004, 09:29 |
Re: F77 Compile.
|
#8 |
Guest
Posts: n/a
|
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.
|
|
November 18, 2004, 09:55 |
Re: F77 Compile.
|
#9 |
Guest
Posts: n/a
|
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.
|
|
November 19, 2004, 15:58 |
Re: F77 Compile.
|
#10 |
Guest
Posts: n/a
|
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.
|
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
ATTN ALL: SOLUTON TO UDF COMPILE PROBLEM | Rizwan | Fluent UDF and Scheme Programming | 40 | March 18, 2018 07:05 |
How to compile OpenFOAM-1.7.x on CrunchBang linux 10 | gwierink | OpenFOAM Installation | 0 | April 5, 2011 05:38 |
PV3FoamReader compile error.... | PEM_GUY | OpenFOAM Installation | 6 | April 5, 2010 18:22 |
Can someone PLEASE document the development version installation | bernd | OpenFOAM Installation | 76 | November 14, 2008 22:51 |
I can't compile UDS by Absoft Fortran 7.5 | Thitikorn | FLUENT | 2 | July 27, 2002 08:00 |