[Gc] Powerpc/m68k issue running test_stack
mcree at orcon.net.nz
Mon Sep 24 01:43:43 PDT 2012
On Sun 23 September 2012 21:44:34 Ivan Maidanski wrote:
> Hi Michael, Thorsten and Wouter,
> A couple of months, You reported libatomic_ops-7.3alpaha test_stack failure
> on Alpha, PowerPC and m68k: *
> * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680066
> 1. Could you please verify that the problem exists in the recent
On Alpha the test_stack failure is not present in the release-7_2 branch but
is present in master. It therefore looks like a regression.
The test_stack failure only happens when running under an SMP linux kernel.
In the testing I have just performed against git master it always resulted in
a detected fail in the test_stack test but the Debian packaged version can
result in a list item pointing to itself, thus an infinite loop in the
check_list() function in tests/test_stack.c.
I bisected between the head of the release-7_2 branch and master which results
cc51941b02fddc75952831eb8e28b06d340d2bef is the first bad commit
Author: Ivan Maidanski <ivmai at mail.ru>
Date: Mon Mar 26 08:06:19 2012 +0400
Use __builtin_expect in CAS failure loop condition checks (GCC only)
* src/atomic_ops.c (lock, block_all_signals): Use AO_EXPECT_FALSE.
* src/atomic_ops.h (AO_EXPECT_FALSE): New macro.
AO_XSIZE_fetch_and_add_release): Use AO_EXPECT_FALSE for CAS failure
* src/atomic_ops/generalize.h (AO_fetch_and_add_full,
AO_fetch_and_add_acquire, AO_fetch_and_add_release, AO_fetch_and_add,
AO_and_full, AO_or_full, AO_xor_full): Likewise.
* src/atomic_ops_stack.c (AO_stack_push_explicit_aux_release,
* src/atomic_ops/generalize-small.h: Regenerate.
:040000 040000 15676aef9361c647a597a25e8dd0e152d34681cb
a209c59999ae9072859594d532125236b898779c M src
Something really subtle must be going on as the only change in the commit is
to wrap if statement conditionals with AO_EXPECT_FALSE().
More information about the Gc