PGI User Forum

[dcwarren]

Hello,

In my last thread (here), I mentioned a problem I was seeing with common blocks in the OpenMP paradigm. After some testing, I'm out of ideas, so I'd appreciate some advice.

The code I'm using makes use of common blocks. What I think is happening is that when subroutines inside the parallel region use these common blocks, they refer back to the global values -- even if the individual variables have been declared as "private". If, on the other hand, I make the common blocks "threadprivate", the code outside of the parallel region cannot use those variables to initialize them; subroutines (outside the parallel region) that should be seeing values for those variables are getting 0's instead.

Is there a way in OpenMP to (1) get the compiler to create local copies of common blocks for use in a parallel region, (2) initialize those variables according to any pre-existing values in the global common blocks, and (3) distinguish based on location which version of the common block to be using?

[mkcolg]

Hi dcwarren,

[dcwarren]

I ended up writing this issue off to bad memory management by the person who wrote the code. The common blocks were added any time they were needed with whatever variables were needed at the time, so there was a hideous mix of variables that needed to be private/shared/constant scattered through all of the common blocks.


I spent the weekend rewriting the code to restore some sanity to the way this code manages its variables, and now I have a bizarre new problem. The code now loses the value of arguments to one of its subroutines. Here's how the code looks (ignoring lots of structure around these lines, such as declarations, etc.):

[mkcolg]

[dcwarren]

I am using the debugger, but I've turned off optimization. One of the greybeards in my department suggested it might be an array overstepping its bounds somehow, so I'll try that and print/flush statements to figure it out. Thanks for the speedy response.