O3 flag affecting volatile ?

[onkarb]

Hi,

Do O1,2,3 optimizations affect the way volatile variables are handled in ifort 11.x ?

For me the output of the following code is different for different optimization levels. Here I am putting a skeleton version.

I am using volatile variables for controlling two threads (created using fortran-to-c interfaces) as follows :
================
common /counters/ i(2)
volatile i
i(2)=0
i(1)=0
....... create threads
do 55 while(i(2)==0) ! i(2) is set to 1 by other thread
55 continue
.......
some computation
================
I am using volatile variables because otherwise program may not evaluate (i2==0) every time in the loop. I don't want to use mutex and semaphores.

However gfortran produces the same output for every optimization level.

Any help would be highly appreciated !

[Steven_L_Intel1]

It shouldn't. Please provide an actual example. However, volatile doesn't protect you against issues such as "word tearing" and does not guarantee atomic operations.

[jimdempseyatthecove]

Steve,

In the little code snip provided, this would not be a case of word tearing.

It would be helpful if the user, with the symptomatic code, would run the debugger up to the problem loop and then open a Dissassembly window. Examining the code will clearly show if the while loopis

a)reading memory or
b)is re-reading a resister holding a prior read of the memory or
c) optimization sees variable not written within loop and omits test completely

With the volatile in the test, the code should be a)

If the code is reading memory, the user could have a programming error. e.g. the array used by one thread is not the same address of the array used by the other thread(s). Or the mailbox flag is taken by other thread.

Jim Dempsey

[jimdempseyatthecove]

What does the dissassembly code of the while loop show? (for each optimization level)
For diagnostic test add

common /foocounters/ ifoo1, ifoo2
volatile ifoo1, ifoo2
ifoo1 = 0
ifoo2 = 0
...
do 5555 while(ifoo1==0)
5555 continue

Check the dissassembly of the above (for each optimization level)

Is "volatile" seen in the compilation unit containing the while loop?

Jim Dempsey

[Steven_L_Intel1]

I constructed a test case and found that if the volatile variable was scalar, then it worked fine, but as an array element the optimizer removed the loop (at least in my example), which is clearly wrong. I escalated this as issue DPD200154515.

[jimdempseyatthecove]

As a work around, declare the common block the array exists in as volatile.

From IVF documentation:

"If a common block is declared VOLATILE, each variable in the common block becomes volatile."

Now as to if this exhibits the same bug as the array, you will have to run the experiment.

Jim Dempsey

[Steven_L_Intel1]

Nice idea, Jim but it doesn't help. I suspect that the optimizer is failing to honor the VOLATILE attribute on an array - at least in the test case I came up with.

[jimdempseyatthecove]

Then you may have two bugs

volatile array declaration
and
subscripted element ofarray within common not inheriting volatile attribute of common
where the array itself is not attributed with volatile.

This could be the same bug, but it may reside in two places in the code. (3 if module data has seperate instance of faulty code).

While they are in looking at this code, they should also check for volatile on user defined type with/without enclosed arrays (this may be a 4th place for the bug to be lurking).

And check permutations of volatile within volatile (i.e. make sure you are not adding 1 to a 1-bit field as opposed to oring 1 to the 1-bit field)

Jim Dempsey

[Steven_L_Intel1]

No, I don't think so. When the COMMON is marked VOLATILE, the compiler flags all the variables in that COMMON as VOLATILE. That part works. The optimizer seems to be ignoring this for array element references, however. When the optimizer people look at it and get back to me, I'll know more.

[Steven_L_Intel1]

This was a complicated bug to fix, and it has been fixed, but the fix will appear in a future version, not an update to 12.0.