User forums > General (but related to Code::Blocks)
Integration with LLVM/clang
killerbot:
a couple of hours ago I was attending a talk at fosdem about LLVM/clang.
Interesting I heard was, that the gcc options are also supported (well some might be lacking).
I made a little duplication of the gcc settings and changed the compiler executables, and I could build the CB generated console application.
So I am going to add a test support for it in CB, all catches or hints are very welcome.
I did notice already one drawback, seems the moment I activate the stdC++0x option, it no longer compile the simple console application (hello world) , it blocks with errors on its own header files. :-(
Question : what is the replacement for the archiver "ar' ?
flebber:
--- Quote from: JohnBaptist on October 05, 2009, 03:56:40 am ---I don't know if it works with Boost or the STL yet, but this being worked on, and the fact that work is not complete shouldn't dissuade us from implementing support for the compiler in Code::Blocks. We should get started now, so that when it is finished, this will be the first fully *nix-based IDE that fully supports LLVM/clang.
--- End quote ---
http://blog.llvm.org/2010/05/clang-builds-boost.html
Justin Brimm:
--- Quote from: JohnBaptist on October 05, 2009, 02:06:32 am ---From my perspective as a developer, LLVM/clang offers a lot of advantages over the gcc suite. It has much more advanced static analysis features and better error reporting. It's capable of graphically showing flow control errors (for example, a function that should but doesn't return a value), as is currently done in XCode. It compiles faster than gcc, uses less memory, and produces faster code.
--- End quote ---
LLVM/Clang certainly compiles faster than GCC and uses far less memory, but the resulting binaries are definitely not faster than what GCC can produce. As an example, here's a series of tests run on the binaries produced by GCC and LLVM. The graphs can be a little confusing as they mix graphs with different measurements (graphs measuring time in seconds, lower is better; graphs using unit/s, higher is better).
This was before the release of GCC 4.6.x as well; LLVM has seen some incremental speed increases since those tests were run, but GCC 4.6.x was known to have major speed increases in its produced binaries over older versions. Especially on newer Intel platforms as that was a point of focused development by the GCC team, since Intel now dominates the desktop processor market. Apple exclusively uses Intel chipsets and with AMD recently announcing that they'll no longer be developing future desktop processors, Intel will maintain its position until another manufacturer comes along.
Don't get me wrong, I love the LLVM/Clang project and there will be a day when LLVM will supplant GCC as the king of compilers (for C bases languages), and I think it would be foolish not to be forward thinking and also implement support for LLVM/Clang, but for now GCC still produces superior binaries.
reckless:
Still trying to fix a few bugs but based on xunxun's work i made the dragonegg plugins availiable for all languages but java.
Atm the 64 bit version works fine most of the time but the 32 bit version of the plugins causes linker errors (still investigating).
reckless:
The linker error was a bug in dragonegg related to how mingw works and its fixed now by duncan sands. So dragonegg works on mingw now :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version