Username or EmailPassword
Back when Snow Leopard shipped and introduced me to Clang/LLVM, C++ wasn't supported. From reading the release announcement, it looks like this is the first C++ & ObjC++ release.
The progress and success of the LLVM project is just plain impressive. Who knew there was so much room left for innovation in compilation? One thing that's a bit disappointing with this release though is the lack of love the LLVM Machine Code subsystem is getting for ELF. Maybe a Linux developer will come along to mirror all that goodness Darwin (Mach-O?) users are getting now. Jealous.
I'd just like to say that I wish people would stop using the word "love" when they mean "attention".
I know they won't, but I had to say it anyway. Go ahead & vote me down; I feel much better now. :-)
Well, they don't say "uber" any more, and "SKU" seems to be on the way out. This one, as all cliches do, will also come to pass.
The ELF work is now in HEAD, would probably mature enough to go into 2.9 release.
What about software patents ?
Apple is a big contributor to LLVM.
They have many patents citing LLVM by name inside them.
This is very dangerous as the licence isn't GPLv3 and doesn't protect users from being sued.
Maybe he is actually a developer or prospective developer.
Maybe you should take your own advice.
You mean these "LLVM" patents? http://www.freeishsoftware.org/index.php/component/content/article/...
Turns out the people spreading rumors about there being patents on LLVM are a bunch of liars spreading FUD about LLVM. Edited 2010-10-10 01:37 UTC
No patents about LLVM ? And what about this ?
Edit: Oh, and it is not a patent (at least not yet), it is only a patent application. Edited 2010-10-10 13:47 UTC
GCC is still the best.
Based on what metric?
I'm not saying it isn't, as GCC is a very mature and robust compiler suite, with many many years of development behind it, but I'm sure it isn't better in every metric.
Unless you're trolling, in which case, MSVC is better than GCC.
When you were looking for information, did you consider reading the release notes?
Trolling about compilers, seriously???
Maybe in terms of code generation, but adding a frontend to gcc at first sight seems a nightmare in comparison to llvm (I am a fan of stallman/GPL). I hope they change it or prove me wrong. Switching to C++ sounds interesting and possibly rewarding.
Best at what? I thought it was common knowledge that icc is better for performance.
GCC is of course more portable but I wouldn't call it the best.
Talk is cheap, real benchmarks are more telling.
The one I provided was from 2009.
Here's another from 2010:
Here is another:
Here is someone showing how clamav can be recompiled with icc for a significant performance boost:
I see no reason why I should believe that GCC will create a faster binary in most cases. But if you would like to convince me otherwise then pick some commonly used open source programs and create your own benchmarks.
A lot of these are outdated. They use GCC 4.3, 4.2, and, would you believe it, one (clamAV) even uses GCC 3.4 ! ^^'
The sole test using up-to-date GCC is the 2010 one, and it shows that GCC 4.5 is often pretty close to ICC in terms of performance, although compilation is much slower.
Two concerns :
-This was a svn, pre-beta build of GCC, so compilation performance has probably improved a bit (though one should test this).
-Also, I would like to know how code generated by ICC behaves on AMD processors.
You do have a point about ICC not being outdated, and being faster on at least some Intel processors, though. Edited 2010-10-08 18:48 UTC
According to what criterium? llvm, clang, etc. make it a whole lot easier to add IDE plugins, write debuggers, static analysers, etc.
Every compiler has it's strengths and weaknesses. E.g., compile a very large array of structs. gcc will become a monstrosity, taking enormous amounts of memory, while VC++ effortlessly compiles it in a VM with only 512MB RAM.
It's not exactly clear-cut. But the fact is that gcc until recently didn't have a decent system for plugins to avoid proprietary plugins, and LLVM has forced them to offer such functionality to compete. Edited 2010-10-09 10:32 UTC
What I'm really surprised about is how quickly they got C++ support in it given that many compilers even to this day their compilers fail to conform to many of the C++ standards that have existed for many years. Hopefully more operating systems will jump on board and expand the support further; maybe we'll see LLVM/Clang become the official compiler for *BSD's and their ports some time in the future, with many of the GNU/GCC'isms finally removed from open source code and replaced with open standards code that allow it to be compiled with any compiler. Edited 2010-10-08 05:01 UTC
Oh, and another almost-mandatory compiler extension to C and derivatives that's not properly described by the relevant standards : inline assembly. As awful as GCC's syntax for it can be, it's often much better than keeping separate .s files and writing headers for them, because...
-Doing so is overkill for those assembly snippets of less than 10 lines that form most of CPU-specific code.
-When you're writing ASM, you don't write portable code anyway.
-It's better for code clarity.
-Except for that class of tiny CPU-specific code chunks, ASM is often used for high-performance code, that kind of code where even a CALL's penalty can be too much... Edited 2010-10-08 17:00 UTC
Assembly place is on .s files.
I for one vote for not having inline assembly.
I don't see any problem with having to write a few external functions.
Clang has been committed to FreeBSD -CURRENT, and can compile the kernel + world. Not quite ready for the ports tree, but one can boot and use a FreeBSD system compiled twice by Clang. It's self-hosting!!
gcc -pedantic -Wall -Wextra
A "standard" is more often than not somebody else's "nasty hacks and work arounds."
But at least a set of "nasty hacks and workarounds" where at least some group could agree on, and a whole contingent of programmers has to conform to.
It really makes life easier, and sometimes makes progress slower.