$ gcc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5484)

(I didn't think it was that ancient)

gcc built-ins are not used as far as I can tell:

configure:26208: checking whether GCC supports build-in atomic intrinsics
configure:26225: gcc -o conftest -arch i386 -O0 -ggdb3 -mmacosx-version-min=10.5
 -Wall -I/Users/teuf/gtk/inst/include -DG_DISABLE_SINGLE_INCLUDES -D_REENTRANT -
L/Users/teuf/gtk/inst/lib -L/Users/teuf/gtk/inst/lib -arch i386 -mmacosx-version
-min=10.5 -Wl,-headerpad_max_install_names -framework Carbon conftest.c -lintl  
 >&5
conftest.c: In function 'main':
conftest.c:166: warning: implicit declaration of function '__sync_synchronize'
conftest.c:167: warning: implicit declaration of function '__sync_bool_compare_a
nd_swap'
conftest.c:168: warning: implicit declaration of function '__sync_fetch_and_add'
Undefined symbols:
  "___sync_bool_compare_and_swap", referenced from:
      _main in ccjhDHKR.o
  "___sync_fetch_and_add", referenced from:
      _main in ccjhDHKR.o
  "___sync_synchronize", referenced from:      _main in ccjhDHKR.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
configure:26225: $? = 1
configure:26233: result: no

Let me know what other info can be of use ;) Tomorrow I'll see if I can get a non-atomic-builtin linux build to see if I can reproduce

To do a non-builtin build on linux you can simply comment out 

#define G_ATOMIC_OP_USE_GCC_BUILTINS 1

in glib/glibconfig.h

I've just done that, and tests/refcount continues to work fine here, on a 64-bit dualcore machine.

How is it failing ? Just randomly ?

Created attachment 189535 [details]
make check log

The first test always fails, the other failures seem to be a bit more random (ie sometimes I get more failures), but running make check several times in a row resulted in these 2 failures everytime.

(In reply to comment #2)
> I've just done that, and tests/refcount continues to work fine here, on a
> 64-bit dualcore machine.

Yep, same here (64-bit dualcore machine too)

I assume this is fixed now ?

The tests from glib master run fine on a 64-bit dual core on Snow Leopard. The compiler was Apple GCC 4.2.1 from XCode 3.2.1.



I do have to mention that the commit Christophe refers to

    83821352657a9481dbff6ab04e8ae60566c17d5e
    glib: Rewrite gatomic.[ch]

does introduce a serious performance regression on OS X. configure does not detect the built-ins in the (archaic) gcc that Apple ships. On OS X glib will fallback to the mutex implementation of the atomic operations causing a serious performance regression.

From quick testing back in February, it did look like Apple GCC does support the necessary gcc built-ins (perhaps these were backported from newer GCC releases).  Perhaps an exception should be made in configure for Apple-specific GCC.

A bigger problem is however that Clang does not support these primitives. Ryan points this out in the commit message for aba0f0c38bbfa11ad48b5410ebdbed2a99e68c58. Given that Apple is switching to Clang by default now, this must be fixed one way or another.