[Gc] Re: [bdwgc] 7.2alpha6 fails to compile with clang (#14)

Ivan Maidanski ivmai at mail.ru
Mon Feb 27 23:05:40 PST 2012

Hi Adrian,

28 02 2012, 00:30 Adrian Petrescu <reply+i-3407693-a5909733cc9e503df98b25186b651d2cd8b88eda-460469 at reply.github.com>:
> Users of Homebrew have noticed the following problems when compiling with the default clang: [1](https://github.com/mxcl/homebrew/issues/10539#issuecomment-4202076) and [2](https://github.com/mxcl/homebrew/issues/10453).
> The issue seems to be around the following macro:
> ```
> libtool: compile:  /usr/bin/clang -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -Os -w -pipe -march=native -Qunused-arguments -c os_dep.c  -fno-common -DPIC -o .libs/os_dep.o
> misc.c:943:7: error: array size is negative
>       GC_STATIC_ASSERT((ptr_t)(word)(-1) > (ptr_t)0);
>       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./include/private/gc_priv.h:2143:51: note: expanded from macro 'GC_STATIC_ASSERT'
> # define GC_STATIC_ASSERT(expr) (void)sizeof(char[(expr)? 1 : -1])
>                                                   ^~~~~~~~~~~~~~
> 1 error generated.
> ```

This macro is intended to check whether compiler treats pointer comparison as unsigned integer comparison or not.
BDWGC requires pointers to be treated as unsigned integers in comparisons (this really matters if data address space occupies both halves of 4 GiB space).

It seems that used version of clang is broken regarding this issue (we can add a workaround (like we've done for ancient Borland compiler) in the hope that the produced executable won't be used in environments with both halves of 4 GiB space.

The alternative, better, solution is to cast pointers to word whenever compared (requires a lot of work).

BTW. What's the version of that 'default' clang?

I tried:
clang version 1.1 (branches/release_27)
Target: i386-pc-linux-gnu

It works ok except for test_stack - something wrong with the atomic intrinsics.


> Nobody is quite sure what that macro is intended to be doing (whether it is a bug in clang or a bug in the macro which clang exposes), but in either case it seems like something we should report upstream.
> It compiles cleanly with LLVM.
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/ivmai/bdwgc/issues/14

More information about the Gc mailing list