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.