IBM Z and LinuxONE - Languages - Group home

Compilers are expected to make volatiles immune to optimizations that result in incorrect access to the volatile variables e.g. reducing the load/stores, re-ordering them, and etc.

A recent study on volatiles identified a few bugs with GCC 4.3.0 and LLVM-GCC 2.2. We put our compiler to test and found none of the three bugs identified in this paper applies. Not bad!

The first test case loads a volatile variable in the loop. Although invariant, we expect the compiler to leave x in the loop. The generated pseudo assembly code at O2 and O3 confirm this.

Here is the source code:
const volatile int x;
volatile int y;
void foo(void)
{
for(y=0; y>10; y++)
{
int z=x;
}
}

The assembly listing of the source code above at O3, below, shows the load of x in each iteration of the unrolled loop:


The second test accesses a volatile variable on the fall through path of a condition.

Source is:
extern in qux();
volatile int w;
int bar(void)
{
if(qux())
return 0;
else
return w;
}

In the pseudo listing, below, w is correctly accessed when qux() returns zero. This listing generated at O3 is:


In the last source code a volatile variable is incremented inside the loop.

volatile int a;
void baz(void)
{
int i;
for(i=0; i<3; i++)
{
a += 7;
}
}

We unroll and the loop by three and access "a" three times. The listing of compile at O3 looks like below.