Discussion:
[Gc] Fwd: unable to compile GC using Apple's llvm-gcc (from XCode 4)
(too old to reply)
Asst. Prof. Dmitrii (Dima) Pasechnik
2011-04-09 04:21:01 UTC
Permalink
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 <***@ntu.edu.sg>
Date: 9 April 2011 03:19
Subject: unable to compile GC using Apple's llvm-gcc (from XCode 4)
To: ***@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 <***@hp.com>
to "Dmitrii V Pasechnik (Asst Prof)" <***@ntu.edu.sg>,
Marius Schamschula <***@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 ***@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

CONFIDENTIALITY: This email is intended solely for the person(s) named and may be confidential and/or privileged. If you are not the intended recipient, please delete it, notify us and do not copy, use, or disclose its content. Thank you.

Towards A Sustainable Earth: Print Only When Necessary
Ivan Maidanski
2011-04-09 08:53:28 UTC
Permalink
Hi Dima,
Post by Asst. Prof. Dmitrii (Dima) Pasechnik
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 ----------
Date: 9 April 2011 03:19
Subject: unable to compile GC using Apple's llvm-gcc (from XCode 4)
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.
I'd tried the CVS version with llvm-gcc-2.7 and got the same problem with GAS on x86, so I've added a workaround.
I haven't tested with x64.
Post by Asst. Prof. Dmitrii (Dima) Pasechnik
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.
I think using "unsigned long long" instead of "unsigned" could work. Could you try this workaround?
Post by Asst. Prof. Dmitrii (Dima) Pasechnik
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
unsupported inline asm: input constraint with a matching output
constraint of incompatible type!
make[1]: *** [os_dep.lo] Error 1
Yes, it's known.
Post by Asst. Prof. Dmitrii (Dima) Pasechnik
Just in case you might know how to deal with this.
Thanks,
Dmitrii
-------------------------------------------------------------------------------
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
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
CONFIDENTIALITY: This email is intended solely for the person(s) named and may
be confidential and/or privileged. If you are not the intended recipient,
please delete it, notify us and do not copy, use, or disclose its content.
Thank you.
Towards A Sustainable Earth: Print Only When Necessary
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Asst. Prof. Dmitrii (Dima) Pasechnik
2011-04-09 17:53:06 UTC
Permalink
Hi Ivan,

On 9 April 2011 16:53, Ivan Maidanski <***@mail.ru> wrote:
[...]
Post by Ivan Maidanski
Post by Asst. Prof. Dmitrii (Dima) Pasechnik
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.
I'd tried the CVS version with llvm-gcc-2.7 and got the same problem with GAS on x86, so I've added a workaround.
I haven't tested with x64.
Post by Asst. Prof. Dmitrii (Dima) Pasechnik
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.
I think using "unsigned long long" instead of "unsigned" could work. Could you try this workaround?
It doesn't work: the only difference is a slightly different assembly
error message:

libtool: compile: gcc -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-//ccRXPOFj.s:427:Incorrect
register `%rax' used with `b' suffix
/var/folders/qW/qWY+4Ku1GF0WXrOsV+IDvk+++TM/-Tmp-//ccRXPOFj.s:768:Incorrect
register `%rax' used with `b' suffix

(same happens if I try "unsigned long")

[...]

Best,
Dmitrii

CONFIDENTIALITY: This email is intended solely for the person(s) named and may be confidential and/or privileged. If you are not the intended recipient, please delete it, notify us and do not copy, use, or disclose its content. Thank you.

Towards A Sustainable Earth: Print Only When Necessary
Ivan Maidanski
2011-04-10 07:03:48 UTC
Permalink
Hi Dima,

I think the correct is that processed by gcc-x86[_64] w/o error:

unsigned char oldval;
__asm__ __volatile__("xchgb %0, %1"
: "=q"(oldval), "=m"(*addr)
: "0"(0xff), "m"(*addr) : "memory");

Please post the question to llvm-gcc & clang folks.

Regards.
Hi,
google hints at a similar problem fixed in llvm-gcc few years ago.
I don't know whether it is a coincidence.
I also tried using clang (Apple clang version 2.0
(tags/Apple/clang-138) (based on LLVM 2.9svn))
which looks like a very fresh version of llvm, and saw essentially the
same behaviour.
(error messages look different, but say the same thing)
Could it be a compiler bug? I do not know the x86 assembly language to
be of any help here,
unfortunately, but would be happy to test things.
Best,
Dmitrii
Hi,
I don't have any more idea how to fix this.
Regards.
Sun, 10 Apr 2011 01:53:06 +0800  "Asst. Prof. Dmitrii (Dima) Pasechnik"
Post by Asst. Prof. Dmitrii (Dima) Pasechnik
Hi Ivan,
[...]
Post by Ivan Maidanski
Post by Asst. Prof. Dmitrii (Dima) Pasechnik
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.
I'd tried the CVS version with llvm-gcc-2.7 and got the same problem with
GAS on x86, so I've added a workaround.
Post by Ivan Maidanski
I haven't tested with x64.
Post by Asst. Prof. Dmitrii (Dima) Pasechnik
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
Post by Asst. Prof. Dmitrii (Dima) Pasechnik
Post by Ivan Maidanski
Post by Asst. Prof. Dmitrii (Dima) Pasechnik
register `%eax' used with `b' suffix
/var/folders/qW/qWY+4Ku1GF0WXrOsV+IDvk+++TM/-Tmp-//ccTVEUmt.s:767:Incorrect
Post by Asst. Prof. Dmitrii (Dima) Pasechnik
Post by Ivan Maidanski
Post by Asst. Prof. Dmitrii (Dima) Pasechnik
register `%eax' used with `b' suffix
make[1]: *** [os_dep.lo] Error 1
which I cannot figure out at all.
I think using "unsigned long long" instead of "unsigned" could work.
Could
Post by Asst. Prof. Dmitrii (Dima) Pasechnik
you try this workaround?
It doesn't work: the only difference is a slightly different assembly
libtool: compile:  gcc -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-//ccRXPOFj.s:427:Incorrect
register `%rax' used with `b' suffix
/var/folders/qW/qWY+4Ku1GF0WXrOsV+IDvk+++TM/-Tmp-//ccRXPOFj.s:768:Incorrect
register `%rax' used with `b' suffix
(same happens if I try "unsigned long")
[...]
--
Dmitrii Pasechnik
-----
DISCLAIMER: Any text following this sentence does not constitute a
part of this message, and was added automatically during transmission.
Ivan Maidanski
2011-04-10 12:01:21 UTC
Permalink
Hi,

I've added AO_XCHGB_RET_WORD to workaround a bug in llvm-gcc. It worked for me (llvm-gcc produced .bo files).

All AO_x macros are libatomic-specific.

Regards.
Ivan,
you added in
libatomic_ops/ChangeLog: Recognize AO_XCHGB_RET_WORD new macro (to
workaround a bug).
where is that AO_XCHGB_RET_WORD is coming from? Is it Linux-specific?
On MacOSX (64bit) it's not defined.
Post by Ivan Maidanski
unsigned char oldval;
__asm__ __volatile__("xchgb %0, %1"
: "=q"(oldval), "=m"(*addr)
: "0"(0xff), "m"(*addr) : "memory");
--
Dmitrii Pasechnik
-----
DISCLAIMER: Any text following this sentence does not constitute a
part of this message, and was added automatically during transmission.
CONFIDENTIALITY: This email is intended solely for the person(s) named and may
be confidential and/or privileged. If you are not the intended recipient,
please delete it, notify us and do not copy, use, or disclose its content.
Thank you.
Towards A Sustainable Earth: Print Only When Necessary
Ivan Maidanski
2011-04-10 13:24:53 UTC
Permalink
Hi,

It should be set in your scripts. I typically compile GC (for my project) directly calling gcc from app script w/o any GC configure/make. Eg.:

llvm-gcc --emit-llvm -g -Wall -I include -I libatomic_ops/src -DGC_THREADS -DAO_XCHGB_RET_WORD -c extra/gc.c

If you (or somebody else) want to add some configuration option in configure, send me please a patch for.

Regards.
sorry, I don't understand. I can only find
AO_XCHGB_RET_WORD
libatomic_ops/ChangeLog: Recognize AO_XCHGB_RET_WORD new macro (to
workaround a bug).
libatomic_ops/src/atomic_ops/sysdeps/gcc/x86.h:# ifdef AO_XCHGB_RET_WORD
libatomic_ops/src/atomic_ops/sysdeps/gcc/x86_64.h:# ifdef AO_XCHGB_RET_WORD
Where is it getting set?
Am I missing something?
Thanks,
Dmitrii
Post by Asst. Prof. Dmitrii (Dima) Pasechnik
AO_XCHGB_RET_WORD
--
Dmitrii Pasechnik
-----
DISCLAIMER: Any text following this sentence does not constitute a
part of this message, and was added automatically during transmission.
CONFIDENTIALITY: This email is intended solely for the person(s) named and may
be confidential and/or privileged. If you are not the intended recipient,
please delete it, notify us and do not copy, use, or disclose its content.
Thank you.
Towards A Sustainable Earth: Print Only When Necessary
Asst. Prof. Dmitrii (Dima) Pasechnik
2011-04-10 14:29:08 UTC
Permalink
omg, I thought it's some insanely clever (auto)configure trick that
should define it :-)
Post by Ivan Maidanski
Hi,
llvm-gcc --emit-llvm -g -Wall -I include -I libatomic_ops/src -DGC_THREADS -DAO_XCHGB_RET_WORD -c extra/gc.c
If you (or somebody else) want to add some configuration option in configure, send me please a patch for.
Regards.
sorry, I don't understand. I can only find
AO_XCHGB_RET_WORD
libatomic_ops/ChangeLog:        Recognize AO_XCHGB_RET_WORD new macro (to
workaround a bug).
libatomic_ops/src/atomic_ops/sysdeps/gcc/x86.h:# ifdef AO_XCHGB_RET_WORD
libatomic_ops/src/atomic_ops/sysdeps/gcc/x86_64.h:# ifdef AO_XCHGB_RET_WORD
Where is it getting set?
Am I missing something?
Thanks,
Dmitrii
Post by Asst. Prof. Dmitrii (Dima) Pasechnik
AO_XCHGB_RET_WORD
--
Dmitrii Pasechnik
-----
DISCLAIMER: Any text following this sentence does not constitute a
part of this message, and was added automatically during transmission.
CONFIDENTIALITY: This email is intended solely for the person(s) named and may
be confidential and/or privileged. If you are not the intended recipient,
please delete it, notify us and do not copy, use, or disclose its content.
Thank you.
Towards A Sustainable Earth: Print Only When Necessary
--
Dmitrii Pasechnik
-----
DISCLAIMER: Any text following this sentence does not constitute a
part of this message, and was added automatically during transmission.
Loading...