parallelization of obsolete fortran77 codes

[Michal_Kvasnicka]

Is there any tool or methodology how to routinely find potential sources of troubles during parallelization of the obsolete Fortran77 codes with COMMON blocks and SAVE constructs?

The "parallelization" is introduced by simple OpenMP parallel FOR cycle which is calling one special function for different input data. The problem is, that this special function communicate with rest of the code mostly via COMMON blocks and uses SAVE command.

I am looking for suitable tools and/or general methodology how to find data access conflicts and other potential problems in this case.

[TimP]

Most of the parallel programs I have dealt with use COMMON extensively. In simple cases you don't even need to study threadprivate. You'd have to explain what problem you face. Of course, it's important to follow the usual rules of nesting loops so that each thread works on its own local section of each COMMON.
If your function doesn't contain sufficiently large DO loops to be suitable for parallelization of a DO loop inside the function, its hard to imagine that an automatic tool would fix that.

[jimdempseyatthecove]

>>The problem is, that this special function communicate with rest of the code mostly via COMMON blocks and uses SAVE command

This will require you to examine the special function to check for conflicts when called from your parallel loop.

Typical problems are the function is an accumulator, e.g. calculating total force. For these types of functions consider using stack local temporaries in the external function loop (assuming function has a loop) then a reduction operator (or critical section or atomic) to form the global accumulation. When the function does not contain a loop and where the calling loop (the parallel loop) performs the accumulation, then use a private accumulation variable or reduction variable.

One potential problem area is local arrays in source files compiled without OpenMP (e.g. library) are subject to being SAVE. Therefore assure that these source files are compiled with the OpenMP option (even when they do not have !$OMP...). Alternately, add RECURSIVE attribute to the subroutine/function, or if you wish the non-portable AUTOMATIC attribute to your local array declarations.

Jim Dempsey

[Steven_L_Intel1]

Intel Inspector XE can find memory access problems. If you have one of the "Studio" suites that include both Fortran and Intel Inspector XE you can also use the Static Security Analysis feature which may detect such problems at build time.

[Michal_Kvasnicka]

Steve, yes I have the "Studio" suite ...

could you add a simple example of the command line witch proper switches and options?

Thanks ian advance ...

[Steven_L_Intel1]

I'm not sure how one does this on Linux. For Intel Inspector, look at the tutorials here. For Static Security Analysis, see the compiler documentation under Building Applications > Improving Application Security and Correctness.