After much pondering and talking with both you and Torvald, it has been
determined that the test at hand is technically allowed to hoist the
value of x/y because the standard guarantees that the code below is data
race free:
if (__atomic_load_n (&flag1, __ATOMIC_ACQUIRE))
On 03/23/2012 10:39 AM, Aldy Hernandez wrote:
On 03/21/12 12:54, Andrew MacLeod wrote:
On 03/21/2012 01:35 PM, Aldy Hernandez wrote:
In the test below, we cannot cache either [x] or [y] neither before
the load of flag1 nor the load of flag2. This is because the
corresponding store/release can f
On 03/21/12 12:54, Andrew MacLeod wrote:
On 03/21/2012 01:35 PM, Aldy Hernandez wrote:
In the test below, we cannot cache either [x] or [y] neither before
the load of flag1 nor the load of flag2. This is because the
corresponding store/release can flush a different value of x or y:
+ if (__atom
On 03/21/2012 01:35 PM, Aldy Hernandez wrote:
The pass at fault here is the combine stack adjustment RTL pass. I
have not looked into why this is happening, but I wanted to get this
test into the branch lest we forget about it.
Is this OK for the branch? Is my understanding correct?
Fine
On 03/21/2012 01:35 PM, Aldy Hernandez wrote:
In the test below, we cannot cache either [x] or [y] neither before
the load of flag1 nor the load of flag2. This is because the
corresponding store/release can flush a different value of x or y:
+ if (__atomic_load_n (&flag1, __ATOMIC_ACQUIRE))
