Is premier support outsourced?

[jimdempseyatthecove]

I would like to post this question here instead of on the Premere support site.

My question is:

Is premier support outsourced?

In particular outsourced to what I would call junior programmers, who may speak English well but do not have a full command of technical usage of the language.

In particular, when they see "Examples are..." followed by a list of examples, their interpretation is that the listed examples exclusivelythe only examples. (instead of representative examples).

The reason I ask is, I am currently in a dialog with (unnamed) on the premier support site regarding a problem the use of $ATOMIC on an "integer , volatile" variable.

I posted a bug report regarding this on the premier site. The following outlines the problem:

Code:

! 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

For the code generated pre-W_FC_C_9.1.025

When count is volatile, the code generated would use different named semephors and a non-LOCK incriment or decriment. This resulted in broken code. (deadlock due to count getting hosed).

If the variable (count) is defined without "volatile" a call to a locked integer add subroutine is called. Acceptible, but not as optimal as using theLOCK prefex with the add instruction.

In my applicaton, when I examine the variable count I want to be assured that it is coming from memory and not from a stale copy in a register. If I want to use a copy that is (may be) register-ized then I will explicitly copy the variable and then use the copy.

(By the way, replacing the $ATOMIC with a named $CRITICAL fixed the code)

The support person is of the position that "volitile" refers onlyto variables subject to change by way of the Operating System (I would venture to guess that those were the only examples in the "Examples are...").

My reply was something along the line of what the documentation reads:

"VOLATILE Specifies that the value of an object is entirely unpredictable, based on information local to the current program unit. "

In the case of the sample code above, and in a multi-threaded program, subroutines fee and fido could be running at the same time. Thus the application itself causes the unpredictability,

It is the programmers preference (based on design requirements) if volatile should be used on the target of an $ATOMIC operation.

Jim Dempsey

[TimP]

The site itself is outsourced. The people who respond to issues are located at various sites around the world. The reason given is this is the way to assure initial response within the time guidelines, regardless of the time of day you submit. As a consequence, you can increase the probability of the issue being picked up in North America by submitting issues when it is morning in North America.
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.

[jimdempseyatthecove]

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

[Steven_L_Intel1]

Sorry to bring an old topic back to life, but I want to correct a major misconception.

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.