Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
44 Views

OMP: Error #133

Jump to solution

Hello everyone,my code written by Fortran95 with OpenMP,When compile with openmp,occured runtime error

OMP: Error #133: Inconsistent THREADPRIVATE common block declarations are non-conforming and are unsupported. Either all threadprivate common blocks must be declared identically, or the largest instance of each threadprivate common block must be referenced first during the run.

But in debug mode,it works well.How do I fix it?

thank you

0 Kudos

Accepted Solutions
Highlighted
44 Views

In your #8 post the same named block have different sizes. (I assume this named common block is also thread private).

Referring to:

OMP: Error #133: Inconsistent THREADPRIVATE common block declarations are non-conforming and are unsupported. Either all threadprivate common blocks must be declared identically, or the largest instance of each threadprivate common block must be referenced first during the run.

Specifically the ", or" clause, due to the sizes being different, this would require you to reference the larger of the two layouts first.

program YourProgramNameHere
real :: pv(100,2)
common/v14loc/ pv
!$omp threadprivate(/v14loc/)
!$omp parallel ! *** do not use PRIVATE(pv)
pv = 0.0 ! touch threadprivate copy
!$omp end parallel

Notes,

The first time you reference the threadprivate named common, you must do so using the largest declaration. Also note, you must do so in a manner whereby the compiler optimizations do not eliminate your code. I strongly caution that you place the first time use into a subroutine that is compiled in a separate source file, perhaps you can call it SUBROUTINE InitThreadPrivate(), then call that from your main PROGRAM.

It will be your responsibility to assure that each named block, as used for thread private, uses the largest of the named blocks in your application.

Note, if the compiler does not permit the ", or" clause, then you have to insert padd fields to your shorter same named thread privates.

Jim Dempsey

View solution in original post

0 Kudos
14 Replies
Highlighted
Beginner
44 Views

My system is Windows 10 64Bit,and Visual Studio 2015 with Intel Parallel Studio XE 2016 Update1

0 Kudos
Highlighted
44 Views

Place the thread private data into a module, then USE that module as opposed to having each routine (attempt to) specify the same COMMON. In this manner you always only have one declaration of the COMMON or module data.

Jim Dempsey

0 Kudos
Highlighted
Beginner
44 Views

jimdempseyatthecove wrote:

Place the thread private data into a module, then USE that module as opposed to having each routine (attempt to) specify the same COMMON. In this manner you always only have one declaration of the COMMON or module data.

Jim Dempsey

 

thank you.I will try to fix

0 Kudos
Highlighted
Beginner
44 Views

jimdempseyatthecove wrote:

Place the thread private data into a module, then USE that module as opposed to having each routine (attempt to) specify the same COMMON. In this manner you always only have one declaration of the COMMON or module data.

Jim Dempsey

Thank your reply.I try to use module,but my code is from 1990's with many of this usage,so I can't fix it.What does error occur?If it's a misuse,why not a compile error?In my project,not all of this usage can cause runtime error,and Debug Lib works well.

0 Kudos
Highlighted
44 Views

An alternate way is to place all of your threadprivate COMMON blocks into a single file, then use the Fortran INCLUDE in the appropriate places. The will require any code using threadprivate variables, see all threadprivate variables.

I've converted COMMON to module for code from the 1980's. Excepting when the named common blocks map the data differently, the conversion went quite easily.

Jim Dempsey

0 Kudos
Highlighted
Beginner
44 Views

jimdempseyatthecove wrote:

An alternate way is to place all of your threadprivate COMMON blocks into a single file, then use the Fortran INCLUDE in the appropriate places. The will require any code using threadprivate variables, see all threadprivate variables.

I've converted COMMON to module for code from the 1980's. Excepting when the named common blocks map the data differently, the conversion went quite easily.

Jim Dempsey

Thank you.I know how to fix.

     common/v14loc/ pv(100,2)

     common/v14loc/ pv(100),gv(100)

This two writing will bring about the runtime error.

0 Kudos
Highlighted
Beginner
44 Views

Sorry,

common/v14loc/ pv(100,2)

     common/v14loc/ pv(100)

This two writing will bring about the runtime error.It means var count not equal

0 Kudos
Highlighted
45 Views

In your #8 post the same named block have different sizes. (I assume this named common block is also thread private).

Referring to:

OMP: Error #133: Inconsistent THREADPRIVATE common block declarations are non-conforming and are unsupported. Either all threadprivate common blocks must be declared identically, or the largest instance of each threadprivate common block must be referenced first during the run.

Specifically the ", or" clause, due to the sizes being different, this would require you to reference the larger of the two layouts first.

program YourProgramNameHere
real :: pv(100,2)
common/v14loc/ pv
!$omp threadprivate(/v14loc/)
!$omp parallel ! *** do not use PRIVATE(pv)
pv = 0.0 ! touch threadprivate copy
!$omp end parallel

Notes,

The first time you reference the threadprivate named common, you must do so using the largest declaration. Also note, you must do so in a manner whereby the compiler optimizations do not eliminate your code. I strongly caution that you place the first time use into a subroutine that is compiled in a separate source file, perhaps you can call it SUBROUTINE InitThreadPrivate(), then call that from your main PROGRAM.

It will be your responsibility to assure that each named block, as used for thread private, uses the largest of the named blocks in your application.

Note, if the compiler does not permit the ", or" clause, then you have to insert padd fields to your shorter same named thread privates.

Jim Dempsey

View solution in original post

0 Kudos
Highlighted
Beginner
44 Views

jimdempseyatthecove wrote:

In your #8 post the same named block have different sizes. (I assume this named common block is also thread private).

Referring to:

OMP: Error #133: Inconsistent THREADPRIVATE common block declarations are non-conforming and are unsupported. Either all threadprivate common blocks must be declared identically, or the largest instance of each threadprivate common block must be referenced first during the run.

Specifically the ", or" clause, due to the sizes being different, this would require you to reference the larger of the two layouts first.

program YourProgramNameHere
real :: pv(100,2)
common/v14loc/ pv
!$omp threadprivate(/v14loc/)
!$omp parallel ! *** do not use PRIVATE(pv)
pv = 0.0 ! touch threadprivate copy
!$omp end parallel

Notes,

The first time you reference the threadprivate named common, you must do so using the largest declaration. Also note, you must do so in a manner whereby the compiler optimizations do not eliminate your code. I strongly caution that you place the first time use into a subroutine that is compiled in a separate source file, perhaps you can call it SUBROUTINE InitThreadPrivate(), then call that from your main PROGRAM.

It will be your responsibility to assure that each named block, as used for thread private, uses the largest of the named blocks in your application.

Note, if the compiler does not permit the ", or" clause, then you have to insert padd fields to your shorter same named thread privates.

Jim Dempsey

It means that my threadprivate code has not been initialized firstly?

0 Kudos
Highlighted
Beginner
44 Views

I know the reason.All common data declaration size is equal,or the largest common data should been called firstly.

0 Kudos
Highlighted
Beginner
44 Views

Two functions declare the same common,if the first function common block is lager but called later then the second function,Can also avoid the above mistakes.

0 Kudos
Highlighted
44 Views

 IMHO this is an implementation issue. The Linker should have been able to determine the largest size of each named threadprivate common and thus determine the sum of all the named threadprivate commons and thusly be able to determine the total size and relative offsets. This said, there can be mitigating circumstances the may make this difficult. In a DLL that is loaded programmically and which uses shared threadprivate in the API into the DLL (linker never sees its export library).

It is advisable to insert !DIR$-ective conditional compilation assert runtime checks into your development code to assure that it is operating as expected. These you enable during development, and disable for production code.

Jim Dempsey

0 Kudos
Highlighted
44 Views

It is a programming error. All named COMMON blocks must be the same size, per the standard. Only unnamed COMMON may have different sizes across program units. Yes, on some platforms the first contribution linked in sets the size, and on others the maximum size is taken, but the Fortran standard is clear that the behavior is unspecified when the same named COMMON has different sizes in different program units.

Retired 12/31/2016
0 Kudos
Highlighted
Beginner
44 Views

Thanks to Jim Dempsey and Steve.I am a C/C++ Developer,not familiar with the Fortran and my English is poor, my fortran Code is 1990's writing.When I met the above error,I search Intel Fortran Document and via google to search Internet,there is no solution.In this forum to get the perfect solution.Thank you very much.

0 Kudos