Re[4]: [Gc] Fwd: unable to compile GC using Apple's llvm-gcc(from XCode4)

Ivan Maidanski ivmai at mail.ru
Sun Apr 10 00:03:48 PDT 2011


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.

Sun, 10 Apr 2011 14:56:57 +0800  "Asst. Prof. Dmitrii (Dima) Pasechnik" <dima at ntu.edu.sg>:

> 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
> 
> 
> On 10 April 2011 03:48, Ivan Maidanski <ivmai at mail.ru> wrote:
> > 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"
> <dima at ntu.edu.sg>:
> >
> >> Hi Ivan,
> >>
> >> On 9 April 2011 16:53, Ivan Maidanski <ivmai at mail.ru> wrote:
> >> [...]
> >> >> 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.
> >> >
> >> >>
> >> >> 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")
> >>
> >> [...]
> -- 
> Dmitrii Pasechnik
> -----
> DISCLAIMER: Any text following this sentence does not constitute a
> part of this message, and was added automatically during transmission.



More information about the Gc mailing list