1 - Start the debugger, gdb executable_name, type run and wait to see where it is crashing.. You should see the routine name..From there is up to you..

2 - Compile with -g, repeat as above, and if it fails you now know the line of the routine where is failing.. If it does not fail as above, there might be an uninitialized variable in the routine in (1), or an optimization bug.

It is a very good idea to compile using bounds checking.. It will run slower, but safe until you remove all the wrinkles. Remove for production code.

There are no references because FORTRAN requires no changes for 32, 48, 64, 128 or whatever bit system. The size of all types is fully defined by the FORTRAN specification. (Of course, this is not the case for C/C++ but this is more of a systems language than a programming language)

Given the above I am curious about what your clue maybe. Some serious numerical code does try to pin down the floating point behaviour around the limits but getting this wrong is almost certainly not going to cause a crash just less than optimal performance.

Given that you have come from Windows there is a fair chance you have got some non-standard FORTRAN that is causing problems?

The easiest way to find the problem area is to compile with -g and run under the visual debugger ddd which will enable you to debug interactively.

Another method is to turn on the strict FORTRAN 77 if this is viable. It is not for most codes because of the limit on the length of variable names and the lack of "end do".

It would be helpful to see any message that you might get before the program stalls.

To confirm the previous post: Your code should still work even if your compiler does not have the option of 64 bit.

I am using Linux on AMD opterons in 64 bit mode as well, although with a different compiler, but that shouldn't be the problem. However, to make sure that your system is working properly, try a different Fortran77 code and see if that one works.

How about memory requirements? Could it be that your new machine simply does not have enough RAM to run your code? Could your RAM be faulty (do other codes run well?)

Debug your code, as suggested in previous messages.Chances are that your portability problems will reveal a glitch in your code which remained hidden in XP.