Remember the browser wars? In the beginning we had IE with its layout problems and Netscape which crashed. Now we have WebKit, Gecko, IE 8, and Opera. They're all stable, fast, support a useful set of standards, and run nice development tools.
Now that Clang is "production ready", do you think the GCC devs are going to sit on their hands? We're going to see a few *nix distros switch over their defaults (BSDs, Arch, Gentoo?). We'll see rapid C1x compliance, we'll get better dev tools, and nicer standards compliance. C programming will be a better experience even if you don't touch Clang.
Right now I'd like to make my projects show clean results under the Clang analyzer, but it seems that most of that work is sticking the right attributes on functions (ex. you need to explicitly mark a function "noreturn" even if it always calls longjmp, or you'll see a bunch of junk error messages).
Unless there has been some improbable advancements in the 3 months since I last compared them, GCC generates better code in most cases, and Clang chokes on some advanced templates.
Even so, I'm rooting for Clang/LLVM for having the better architecture.
clang, because it actually shows where in instantiated macros errors are (gcc just tells you it's somewhere in the macro.) Plus the error messages are much faster to read.
>>9
Yes, C++ sucks. This is common knowledge.
(the fact that that so many people say LLVM's source code is one of the best written C++ codebases reinforces my own refusal to have anything to do with the language)
>>13
llvm tends to do better with intrinsics, but that's about it.
The Intel compiler and several different Intel function libraries have suboptimal performance on AMD and VIA processors. The reason is that the compiler or library can make multiple versions of a piece of code, each optimized for a certain processor and instruction set, for example SSE2, SSE3, etc. The system includes a function that detects which type of CPU it is running on and chooses the optimal code path for that CPU. This is called a CPU dispatcher. However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string. If the vendor string is "GenuineIntel" then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version.
This vendor-specific CPU dispatching decreases the performance on non-Intel processors of software built with an Intel compiler or an Intel function library - possibly without the knowledge of the programmer. This has allegedly led to misleading benchmarks. A legal battle between AMD and Intel over this and other issues has been settled in November 2009. In addition to this, the US Federal Trade Commission has filed an antitrust complaint against Intel.
>>23
icc is intel's compiler, what on earth could give you the impression that it would support ARM?
Anyway, llvm-gcc does support ARM eabi. I made a patch for clang to support the appropriate linux triple for ARM eabi but I've been too lazy to poke people about it.
Also, clang doesn't really support cross-compiling except between OS X architectures, so you'd really need to host it on ARM and fuck that.