[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