Notice the store of <j> *after* the store to <atomi>. I consider
this a bug and have put this on my laundry list.

Seems plausible, though I don't know the details of the x86_64 memory
model well enough to be sure that it would be possible to observe this
reordering. But then, if your test fails I guess it is. :)

I have not looked into why it happens, just that it does so incorrectly. So I'm just as stumped :).

for (int i=0; i < SIZE; ++i)
x[i].store(666, memory_order_relaxed);

This is the test in the attached atomics-3.C.

I don't think that's testing what you want to test; those stores are to
the same array, but not to the same memory location.

Ahh, poop, yeah. I had a simpler test, but it's pretty hard to trick GCC to not eliminate the first store if they're both to the same location. I've removed this test, and only committed the first one.

Thanks for looking into this.
Aldy

Reply via email to