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

Boehm, Hans hans.boehm at hp.com
Tue Feb 28 15:05:54 PST 2012


We seem to be having several parallel conversations about this.  Please keep further posts on the gc mailing list.

I think the crucial question is whether clang thinks

(char *)(size_t)(-1) > (char *)0

evaluates to 0 or 1, which should be a pretty simple test.  That may depend on whether you're using a 32-bit or 64-bit compilation model and possibly on other compiler flags.  We all think 1 is the right answer, though no standard requires that.  (Except possibly clang claims to be gcc, and gcc says so?)  Could someone for whom this is failing confirm that the answer is zero and post the compilation flags?

Hans

> -----Original Message-----
> From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com]
> On Behalf Of Ivan Maidanski
> Sent: Monday, February 27, 2012 11:06 PM
> To: Adrian Petrescu
> Cc: gc at linux.hpl.hp.com
> Subject: [Gc] Re: [bdwgc] 7.2alpha6 fails to compile with clang (#14)
> 
> 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.
> 
> Regards.
> 
> >
> > 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
> >
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/



More information about the Gc mailing list