Not only does gcc often produce faster running programs as referenced in the post, it has mature OpenMP support (although llvm/clang is moving pretty fast on OMP development), and has a Fortan compiler. These are important for numerical computing.

Does it?

http://imagine-rt.blogspot.co.uk/2014/12/c-compiler-benchmar...

As the original author of that benchmark, I should point out that that was LLVM SVN (unreleased) against GCC 4.8 & 4.9 - I couldn't get GCC 5.0 SVN to build, so it's possible 5.0 will be faster again than LLVM in certain situations.

However, I would also say that generally I've found LLVM is now producing faster code than GCC in most code I've tested both compilers with.

That is very interesting, because LLVM developers themselves admit LLVM generates slower code than GCC (in average). This is plain if you read LLVM Developers' Meeting talks.

I think it is completely possible that LLVM developers are using wrong benchmarks. Benchmarks are mostly SPEC and some large Google C++ codebases; in some sense both are quite atypical. But then, entire problem is to understand how typical codebases look like.

I can hopefully settle this (as a developer of both).

Assuming we stick to x86/x64, nowadays (literally, let's say as of January 2015) GCC and LLVM are within the noise for most people on most code (IE 1-2% of each other).

You can certainly find benchmarks were LLVM does badly. Some are important to some people, some aren't. It is harder to find benchmarks where GCC does badly.

Yes it does. Did you read my links?

Small benchmarks can go either way, but for large codebase (especially C++) inliner is more important than just about anything else. So GCC wins, because it has better inliner.

Yep - you evidently didn't read mine as 165 k lines of c++ isn't exactly a small benchmark :)

Anecdotal, but I've seen similar improvements over g++ in my code.

There are many measures of benchmark sizes. One important measure is size of codes that account for 99% of execution time. If your codebase is a million lines but your hotspot is a thousand lines, benchmark result is sensitive to optimization quirks and in some sense benchmark is small.

More on this idea here: http://blog.pyston.org/2014/12/05/python-benchmark-sizes/

Why yes, yes it does. There are exceptions of course, you seem to have found one. Here are some others: http://www.phoronix.com/scan.php?page=article&item=gcc49_com...