Fortran Composer v12.0: THREADPRIVATE directive must not be an element of a common block or be declared in an equivalence statement

Fortran Composer v12.0: THREADPRIVATE directive must not be an element of a common block or be declared in an equivalence statement

Hi,

I'm not sure if this question belongs in this forum or the Fortran Compiler forum. If I'm in the wrong place please let me know.

I am trying to compile software with ifort v12.0 with OMP. I know this software will comile using ifort v10.0 using OMP. I can compile it using ifort v12.0 without OMP. When I try to compile it with ifort v12.0 with OMP get the following error:

A variable in a THREADPRIVATE directive must not be an element of a common block or be declared in an equivalence statement

I have a vague idea what this means, but not an exact one. I am wondering why this occurs with ifort v12.0 and not previous versions. Is there stricter enforcement of an OpenMP standard or did the standard change between ifort releases?

Most importantly, is there a simple way to correct this? For example, could I compile with a flag that would ignore errors like this?

(My appologies if similar questions have been addressed previously. I searched the forum and did not find my issue anywhere so I started a new thread.)

Thank you,
N

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

OK, I'm trying to recover my Fortran chops after a long period of abstinence, but I'm blithe enough to blunder in over my depth to take a stab at this.

First, I could migrate this thread to one of the Fortran forums, but they seem to be classed by OS and you don't provide any distinquishing marks in your statement to clue me in on which way to pass it. So I'll leave it here for now.

Now, regarding THREADPRIVATE, my reading of the documentation suggest that for Fortran, THREADPRIVATE is a directive for declaring common blocks, i.e., named common blocks, and each thread will get their own private copy of the common, which is then available globally throughout the thread. The error message you quote seems to suggest that your code has a variable declaration in the THREADPRIVATE directive. According to the documentation, that's a no-no. The elements of a common need to stay ordered and typed, and pulling out individual variables may be the issue here. Hopefully you're not using EQUIVALENCE to bind private copies of variables together.

Finally, the question of V12 vs V10. A Fortran novice myself, I don't have the history to be able to answer this question directly. It may not be related at all to your question, but I did discover that there are old (legacy) and new behaviors for the threadprivate directive, controlled by the runtime switch -openmp-threadprivate (or /Qopenmp-threadprivate for the Windows users) that select between "legacy" and "compat" behaviors for the implementation of threadprivate. The documentation is rather vague on the actual difference between those behaviors, so I can't tell whether the issue is related to the observations you reported.

Anyway, that's my stab at the problem. You or someone else with more experience can shoot me down, but this is what I came across when looking into the problem you reported. Hopefully it's relevant.

Thanks for the help. I'm compiling on a linux cluster. I've tried the -openmp-threadprivate switch and I think it may have worked, but I'm getting other errors now. I have to try to track them down before I can comment on them inteligently. But in any case, thanks for your help. When I get the whole thing up and running, I'll comment back here with my fixes.

N

This is how I use it

type    TypeThreadContext
  SEQUENCE
  type(TypeObject), pointer :: pObject
  type(TypeTether), pointer :: pTether
  type(TypeFSInput), pointer :: pFSInput
  integer :: LastObjectLoaded
end type TypeThreadContext

type(TypeThreadContext) :: ThreadContext
COMMON /CONTEXT/ ThreadContext
!$OMP THREADPRIVATE(/CONTEXT/)

Jim Dempsey

www.quickthreadprogramming.com

Leave a Comment

Please sign in to add a comment. Not a member? Join today