That's on the current status of Boehm GC support on Apple's llvm-gcc ---------- Forwarded message ---------- From: Asst. Prof. Dmitrii (Dima) Pasechnik <d...@ntu.edu.sg> Date: 9 April 2011 12:21 Subject: Fwd: unable to compile GC using Apple's llvm-gcc (from XCode 4) To: g...@linux.hpl.hp.com Cc: Marius Schamschula <mschamsch...@gmail.com>, hans.bo...@hp.com
Dear all, I post here my email to Hans Boehm and his reply (suggesting to post here, among other things) to me and to Marius Schamschula. It would be great to have a fix for this. Dmitrii ---------- Forwarded message ---------- From: Asst. Prof. Dmitrii (Dima) Pasechnik <d...@ntu.edu.sg> Date: 9 April 2011 03:19 Subject: unable to compile GC using Apple's llvm-gcc (from XCode 4) To: hans.bo...@hp.com Hi there, I am trying to build the GC using Apple's llvm-gcc (which is the default C compiler on the latest XCode 4). (on a 64-bit MacOSX 10.6.7) Nether the stable version, nor the latest CVS version compile. One place that is easy to fix is in libatomic_ops/src/atomic_ops/sysdeps/gcc/x86_64.h Namely, the workaround for LLVM 2.7 GAS is still needed (see lines around line 111 in the CVS version), but it needs a modification to the conditional statement # ifdef AO_XCHGB_RET_WORD (this one does not work). After I get past this problem, I get ... libtool: compile: cc -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -g -O2 -MT os_dep.lo -MD -MP -MF .deps/os_dep.Tpo -c os_dep.c -fno-common -DPIC -o .libs/os_dep.o /var/folders/qW/qWY+4Ku1GF0WXrOsV+IDvk+++TM/-Tmp-//ccTVEUmt.s:427:Incorrect register `%eax' used with `b' suffix /var/folders/qW/qWY+4Ku1GF0WXrOsV+IDvk+++TM/-Tmp-//ccTVEUmt.s:767:Incorrect register `%eax' used with `b' suffix make[1]: *** [os_dep.lo] Error 1 which I cannot figure out at all. It seems that these two problems are related, as without the LLVM-specific workaround working I get libtool: compile: cc -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -g -O2 -MT os_dep.lo -MD -MP -MF .deps/os_dep.Tpo -c os_dep.c -fno-common -DPIC -o .libs/os_dep.o ./libatomic_ops/src/atomic_ops/sysdeps/gcc/x86_64.h: In function 'AO_test_and_set_full': ./libatomic_ops/src/atomic_ops/sysdeps/gcc/x86_64.h:117: error: unsupported inline asm: input constraint with a matching output constraint of incompatible type! make[1]: *** [os_dep.lo] Error 1 Just in case you might know how to deal with this. Thanks, Dmitrii ------------------------------------------------------------------------------- from Boehm, Hans <hans.bo...@hp.com> to "Dmitrii V Pasechnik (Asst Prof)" <d...@ntu.edu.sg>, Marius Schamschula <mschamsch...@gmail.com> date 9 April 2011 04:23 subject RE: unable to compile GC using Apple's llvm-gcc (from XCode 4) Both of you pointed out the same problem to me. I strongly recommend posting to g...@linux.hpl.hp.com instead, since you are much more likely to find Mac experts there. It looks to me like the compiler and assembler have an inconsistent ideas of what xchgb returns, making it impossible to generate the instruction inline. If LLVM supports gcc's __sync_lock_test_and_set, that may be an acceptable workaround. It's probably safe to assume that on x86 it includes a full fence. I would manually verify that it indeed generates the xchgb instruction. But maybe that runs into the same assembler bug? Another plan might be to not include test_and_set_t_is_char.h on LLVM, and instead rely on the default word-sized implementation of test-and-set locations. That would require some adjustment to AO_test_and_set_full(). Hans -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
