After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 652148 - tests/refcount broken on OSX
tests/refcount broken on OSX
Status: RESOLVED NOTABUG
Product: glib
Classification: Platform
Component: build
unspecified
Other Mac OS
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-06-08 22:24 UTC by Christophe Fergeau
Modified: 2012-03-21 20:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
make check log (6.79 KB, text/plain)
2011-06-09 08:48 UTC, Christophe Fergeau
Details

Description Christophe Fergeau 2011-06-08 22:24:57 UTC
Running make check in this directory has stopped working after commit 

83821352657a9481dbff6ab04e8ae60566c17d5e
glib: Rewrite gatomic.[ch]
Comment 1 Christophe Fergeau 2011-06-08 22:34:41 UTC
$ 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
Comment 2 Matthias Clasen 2011-06-09 01:02:18 UTC
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.
Comment 3 Matthias Clasen 2011-06-09 02:49:38 UTC
How is it failing ? Just randomly ?
Comment 4 Christophe Fergeau 2011-06-09 08:48:53 UTC
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.
Comment 5 Christophe Fergeau 2011-06-09 09:27:24 UTC
(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)
Comment 6 Matthias Clasen 2012-03-18 03:56:49 UTC
I assume this is fixed now ?
Comment 7 Kristian Rietveld 2012-03-21 20:59:07 UTC
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.