[Gc] test_stack on powerpc (power7)

Lennart Sorensen lsorense at csclub.uwaterloo.ca
Wed Jan 29 07:00:47 PST 2014

On Wed, Jan 29, 2014 at 07:05:43AM +0000, Boehm, Hans wrote:
> Interesting.
> I suspect a memory ordering bug in atomic_ops_stack.c, or possibly a subtle miscompilation.  As the rest of the comment states, the scenario you describe should be impossible, because the first note on the list was added to the blacklist.  Thus it could have been removed, but not reinserted (without low-order-bit-twiddling) by another thread.  If any of this had happened, the compare_and_swap should have failed.
> The algorithm and correctness argument (for a hypothetical sequentially consistent machine) are described in a PODC 2004 paper (see http://www.hpl.hp.com/techreports/2004/HPL-2004-105.pdf).    Not that PODC papers are always correct; but they have to be close enough to convince smart referees.  And the fact that this only fails on Power7 suggests memory ordering issues rather than an outright algorithmic bug to me.
> I'm somewhat concerned whether the store in the AO_compare_and_swap_acquire() in AO_stack_pop_explicit_aux_acquire() is actually ordered before the subsequent loads of first_ptr and next.  The acquire is enforced with an lwsync, which normally doesn't order a store followed by a load.  Since the store is atomic with a load, it may do the right thing; I'm not sure.  Can you try inserting a "sync" and see if that helps?
> I would also check that the recheck of first against AO_load(list) appears in the assembly code where it should.

I can try to disassemble the binary if I knew which bit to look for.

I tried building with -O0 to disable the compiler from trying to optimize
things.  No change.

> There could easily be yet a different issue that could explain this.  I don't immediately see anything that would definitely explain it.  But given the subtleties of the Power memory model, and the fact that libatomic_ops' semantics aren't as carefully defined as they should be (or as carefully as the later C++11 primitives), there seem to be plenty of bug opportunities here.

If you can tell me what to add where I can very quickly test it.

len Sorensen

More information about the Gc mailing list