- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I have an old Fortran program which uses common data blocks, and I need to use it with my new code. My new code uses OpenMP, and because of a compiler bug in array pointers which are threadprivate (see this thread) I use the '-openmp-threadprivate compat' flag. The problem is this flag causes a bug with threadprivate common data blocks. Consider the following test program, which is made of three files. First is 'iblock.com':
Can anyone help?
I have an old Fortran program which uses common data blocks, and I need to use it with my new code. My new code uses OpenMP, and because of a compiler bug in array pointers which are threadprivate (see this thread) I use the '-openmp-threadprivate compat' flag. The problem is this flag causes a bug with threadprivate common data blocks. Consider the following test program, which is made of three files. First is 'iblock.com':
[plain]integer :: inumNow 'bdata.f90':
save/iblock/
common/iblock/inum
!$omp threadprivate(/iblock/)[/plain]
[plain]black data bdataLastly 'test.f90':
include 'iblock.com'
data inum/7/
end[/plain]
[plain]program testI have compiled this test program with the Intel Fortran compiler (version 11), with the '-openmp-threadprivate compat' flag (and the '-openmp' flag of course), and it printed 0 (instead of 7). When the threadprivate directive is removed, it works correctly (prints 7). Without the '-openmp-threadprivate compat' flag, it works correctly anyway, even with the threadprivate directive present.
include 'iblock.com'
write(*,*) inum
end program test[/plain]
Can anyone help?
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Put your block-data object file first in the link line.
As a totally simplistic explanation:
It seems thatthread-local-storage variables (the implementation behind the openmp_threadprivate=compat switch) work on a first-found basis.
openmp_threadprivate=legacy put the variables into "normal" Fortran COMMON storage, which merges all the declarations.
- Lorri
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry for the delayed reply. I will inquire with the developers who suggested the earlier work around and update the thread when I know more.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
This looks like a bug. However, there are some limitations to the gcc-compatible implementation of threadprivate, that's why the default remains "legacy", though I don't think they should play a role here. This has been escalated to the compiler developers, we'll let you know what they conclude.
Martyn
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Put your block-data object file first in the link line.
As a totally simplistic explanation:
It seems thatthread-local-storage variables (the implementation behind the openmp_threadprivate=compat switch) work on a first-found basis.
openmp_threadprivate=legacy put the variables into "normal" Fortran COMMON storage, which merges all the declarations.
- Lorri
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Lorri Menard (Intel)
Put your block-data object file first in the link line.
As a totally simplistic explanation:
It seems thatthread-local-storage variables (the implementation behind the openmp_threadprivate=compat switch) work on a first-found basis.
openmp_threadprivate=legacy put the variables into "normal" Fortran COMMON storage, which merges all the declarations.
- Lorri
Whew! That seems like a land mine.
The IVF documentation needs highlight this in the section relating to thread private data (not elsewhere such as an old FAQ).
From my understanding of the IVF documentation, when a new thread is created, thread private data from the master thread is copied into the thread private data of the new thread. Apparently this is not so.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yeah, one of the things that we're discovering is how different threadprivate: compat and threadprivate:legacy are, and yes, we hope to improve the documentation, and possibly do some KB articles on this.
Really, we don't like landmines either :-)
- Lorri

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page