Displaying 3 results from an estimated 3 matches for "builtin_lfoor".
2010 Nov 09
0
[LLVMdev] Phronix does another speed test
On Mon, 8 Nov 2010 15:42:33 -0800 (PST)
Samuel Crow <samuraileumas at yahoo.com> 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
2010 Nov 08
3
[LLVMdev] Phronix does another speed test
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.
2010 Nov 09
2
[LLVMdev] Phronix does another speed test
...oncerned 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...