- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
! foo.f90 module foo ... integer, volatile :: count end module foo ... ! fee.f90 subroutine fee use foo ... !$OMP ATOMIC count = count + 1 ... end subroutine fee ! fido.f90 subroutine fido use foo ... !$OMP ATOMIC count = count - 1 ... end subroutine fido
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Generally, I find the people on the other side of the world conscientious, maybe even quicker to respond. It should help to title your issue as explicitly as possible, like "OpenMP ATOMIC problem." In a case like this, you certainly need to get it assigned to someone who knows the right people on the Fortran and OpenMP teams.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks tim18,
The issue on the Premier Site was titled "OpenMP ATOMIC".
The title on this forum reflects my query as to outsourcing.
There is nothing wrong with outsourcing as long as it achieves the desired results. The CSR that took this incident is certainly trying hard enough and is quite polite. The corispondence though leads me to believe he is knowledgeble yet has an incomplete knowledge of what a volatile variable is, the reasons why it is volatile, and the interrelationship between volatile and atomic. Also, it appears he is reluctant to seek an athority on the subject (for the lack of "OK, I learned something new").
The incident was submitted including sample code that illustrated the problem.
W_FC_C_9.1.025 supposedly corrected similarly reported problems. In examining the dissassembly window it appears to have not. The generated code has changed but it appears incorrect.
Code:
>> Code from main W_FC_C_9.1.025 00401056 E8 BD 01 00 00 call INCSHARED (401218h) !$OMP ATOMIC 0040105B 83 C4 F4 add esp,0FFFFFFF4h 0040105E C7 04 24 C0 30 49 00 mov dword ptr [esp],offset ___xt_z+8Ch (4930C0h) 00401065 8B 45 E8 mov eax,dword ptr [ebp-18h] 00401068 89 44 24 04 mov dword ptr [esp+4],eax 0040106C C7 44 24 08 60 2E 4A 00 mov dword ptr [esp+8],offset _kmpc_atomic_lock (4A2E60h) 00401074 E8 4F B0 03 00 call ___kmpc_critical (43C0C8h) 00401079 83 C4 0C add esp,0Ch 0040107C A1 00 76 49 00 mov eax,dword ptr [_MOD_ATOMIC_mp_NUMBEROFWAITINGTHREADS (497600h)] NumberOfWaitingThreads = NumberOfWaitingThreads + 1 00401081 FF 05 00 76 49 00 inc dword ptr [_MOD_ATOMIC_mp_NUMBEROFWAITINGTHREADS (497600h)] 00401087 83 C4 F4 add esp,0FFFFFFF4h 0040108A C7 04 24 C0 30 49 00 mov dword ptr [esp],offset ___xt_z+8Ch (4930C0h) 00401091 8B 45 E8 mov eax,dword ptr [ebp-18h] 00401094 89 44 24 04 mov dword ptr [esp+4],eax 00401098 C7 44 24 08 60 2E 4A 00 mov dword ptr [esp+8],offset _kmpc_atomic_lock (4A2E60h) 004010A0 E8 4B B0 03 00 call ___kmpc_end_critical (43C0F0h) 004010A5 83 C4 0C add esp,0Ch Note, Semaphore is at offset ___xt_z+8Ch (4930C0h) Whereas subroutine INCSHARED is as follows: >> Code from seperate project (Static Library LibAtomicCode, source IncShared.f90, subroutine ncShared) !$OMP ATOMIC 00401235 83 C4 F4 add esp,0FFFFFFF4h 00401238 C7 04 24 4C 32 49 00 mov dword ptr [esp],offset ___xt_z+218h (49324Ch) 0040123F 8B 45 F0 mov eax,dword ptr [ebp-10h] 00401242 89 44 24 04 mov dword ptr [esp+4],eax 00401246 C7 44 24 08 60 2E 4A 00 mov dword ptr [esp+8],offset _kmpc_atomic_lock (4A2E60h) 0040124E E8 75 AE 03 00 call ___kmpc_critical (43C0C8h) 00401253 83 C4 0C add esp,0Ch 00401256 A1 00 76 49 00 mov eax,dword ptr [_MOD_ATOMIC_mp_NUMBEROFWAITINGTHREADS (497600h)] NumberOfWaitingThreads = NumberOfWaitingThreads + 1 0040125B FF 05 00 76 49 00 inc dword ptr [_MOD_ATOMIC_mp_NUMBEROFWAITINGTHREADS (497600h)] 00401261 83 C4 F4 add esp,0FFFFFFF4h 00401264 C7 04 24 4C 32 49 00 mov dword ptr [esp],offset ___xt_z+218h (49324Ch) 0040126B 8B 45 F0 mov eax,dword ptr [ebp-10h] 0040126E 89 44 24 04 mov dword ptr [esp+4],eax 00401272 C7 44 24 08 60 2E 4A 00 mov dword ptr [esp+8],offset _kmpc_atomic_lock (4A2E60h) 0040127A E8 71 AE 03 00 call ___kmpc_end_critical (43C0F0h) 0040127F 83 C4 0C add esp,0Ch Note, Semaphore is at offset ___xt_z+218h (49324Ch) main Semaphore is at offset ___xt_z+8Ch (4930C0h)
<
/span>
When volatile is off the variable declaration the code generated omits the critical section and calls "___kmpc_atomic_fixed4_add" instead.
Regardless of if the variable is "integer" or "integer, volatile" both should have called "___kmpc_atomic_fixed4_add".
Note, as a seperate issue the "___kmpc_atomic_fixed4_add" call can be replaced with a
LOCK
ADD dword ptr..., 1
Or lock,inc
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Intel Premier Support is NOT "outsourced" in any way. The majority of the compiler support engineers who respond to issues through Premier Support are Intel employees. We do supplement our staff with some contractors, but they work under the direction of Intel. In particular, the support engineer Jim corresponded with is an Intel employee who, as far as I can tell, gave correct advice, and he did indeed seek the advice of experts.

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