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

Hans Aberg haberg-1 at telia.com
Wed Feb 29 07:18:18 PST 2012


On 29 Feb 2012, at 00:05, Boehm, Hans wrote:

> 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.

It seems to be a bug in 64-bit clang. I have run the program below, made by replacing the compiling line of the file misc.c with preprocessing, on various compilers. All produce the output
  1, 1
except clang in 64-bit mode, which produces
  -1, 1
Strangely, the ?: operator causes clang to produce the result to be 0.

The compilers I tried were
  clang -arch i386
  clang
  llvm-gcc-4.2
as in the post before, the compilers that on OS X 10.7.3 comes with Xcode 4.3.

(In this version of Xcode, /usr/bin/cc -> clang and /usr/bin/gcc -> llvm-gcc-4.2. Before that, also /usr/bin/cc pointed to llvm. So packages that call for cc, now will use clang instead of llvm-gcc.)

I also tried gcc-4.7 from the repository
  $ gcc --version
  gcc (GCC) 4.7.0 20120115 (experimental)

Hans


---- clang_test.c ----

#include <stdio.h>

typedef unsigned long word;
typedef char* ptr_t;

int main() {
#if 0
  /* Line that produces error in clang 64-bit mode */
  (void)sizeof(char[((ptr_t)(word)(-1) > (ptr_t)0)? 1 : -1]);
#endif
  
  int k = ((ptr_t)(word)(-1) > (ptr_t)0)? 1 : -1;
  int l = ((ptr_t)(word)(-1) > (ptr_t)0);
  
  printf("%d, %d\n", k, l);
  return 0;
}

--------




More information about the Gc mailing list