Hi Edwin,>> http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_dragonegg28&num=1 >> as of version 2.8, LLVM is generating slower code than the newer GCCs >> but generates the code more quickly. >> > > I would be more concerned about the 'unable to compile', or 'compiled > code not working correctly' issues. It would help if they filed bugs.I analysed the dragonegg compile failures. The graphicsmagick, imagemagick, lame and x264 failures were all failures to link, due undefined references to builtin_lfoor and/or builtin_lceil. Recent gcc turns calls to floor/ceil followed by a cast to long or long long into a call to an lfloor/lceil builtin. These were not being recognised by dragonegg, so were just being passed on as is, resulting in the link failures. I just added support for these builtins and now all of the above programs compile on x86-64 linux. All of the remaining failures (crafty, libgcrypt11 and openssl) were due to using FD_ZERO which on some linux systems like mine uses a rather bogus inline asm which dragonegg rejects: error: unsupported inline asm: input constraint with a matching output constraint of incompatible type! The reason that this is not seen with llvm-gcc is that llvm-gcc uses a fix-includes to correct the definition of FD_ZERO. Adding support for this kind of funky asm is PR3373. It was done already in clang, but not yet in llvm-gcc or dragonegg. Ciao, Duncan.
>>> http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_dragonegg28&num=1 >>> as of version 2.8, LLVM is generating slower code than the newer GCCs >>> but generates the code more quickly. >>> >> >> I would be more concerned about the 'unable to compile', or 'compiled >> code not working correctly' issues. It would help if they filed bugs.It is claimed that the Byte Unix benchmarks compile with llvm-gcc but do not work. They built and worked fine for me with TOT on Darwin X86-64. (I could not find version 3.6; 3.11 is in common use, and has been since at least 2003. There are some comments in the code that call it 3.6, however, and others [dated 1991] that call it 3.9, so I think we're talking about the same thing. But maybe not.) It's also claimed they don't build with Clang. This is true: ./src/hanoi.c:65:3: error: non-void function 'mov' should return a value [-Wreturn-type] return; ^ The function in question is logically void but is declared without a return type (thus implicit int), a style that was common pre-C89 but is now rare. It's clearly legal in both C89 and C99, but last time this came up there was sentiment that rejecting it anyway was the best thing for users. Whatever you think of that, it means we can't build this benchmark.
Now that I've hunted a little harder in the Phoronix site, I see they do have a downloadable copy of the benchmarks: http://www.phoronix-test-suite.com/index.php?k=downloads Their harness, unfortunately, is GPL3, which means I can't use it. On Nov 9, 2010, at 1:39 PMPST, Dale Johannesen wrote:>>>> http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_dragonegg28&num=1 >>>> as of version 2.8, LLVM is generating slower code than the newer GCCs >>>> but generates the code more quickly. >>>> >>> >>> I would be more concerned about the 'unable to compile', or 'compiled >>> code not working correctly' issues. It would help if they filed bugs.