Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29277 Discussions

Threadprivate common data doesn't work with '-openmp-threadprivate compat' flag

ymost
New Contributor I
804 Views
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':
[plain]integer :: inum
save/iblock/
common/iblock/inum
!$omp threadprivate(/iblock/)[/plain]
Now 'bdata.f90':
[plain]black data bdata
include 'iblock.com'
data inum/7/
end[/plain]
Lastly 'test.f90':
[plain]program test
include 'iblock.com'
write(*,*) inum
end program test[/plain]
I 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.
Can anyone help?
0 Kudos
1 Solution
Lorri_M_Intel
Employee
804 Views

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



View solution in original post

0 Kudos
5 Replies
Kevin_D_Intel
Employee
804 Views

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.
0 Kudos
Martyn_C_Intel
Employee
804 Views

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
0 Kudos
Lorri_M_Intel
Employee
805 Views

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



0 Kudos
jimdempseyatthecove
Honored Contributor III
804 Views

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
0 Kudos
Lorri_M_Intel
Employee
804 Views

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
0 Kudos
Reply