Seriously, the core devs hate free software
Speaking as a member of the FreeBSD Core Team, who contributes code to a GNU project (GNUstep) and has signed an FSF copyright assignment for the purpose, and who was the one to make the disable-gcc-by-default commit, I have to say: What?
Yes, well known and accepted. The craptastic GCC developers have been hurting its improvements for years. They have serious control freak issues and as such, GCC has fallen well behind the curve. This isn't a new topic of discussion.
I'm a clang developer and you're a troll. Clang is faster than GCC on some benchmarks. GCC is faster than clang on others. The new autovectorisation code in Clang is usually faster than GCC, sometimes a lot faster, occasionally slower. Clang doesn't yet have the OpenMP support upstream. In most real-world code you won't see a difference of more than 10% between them, and even then you won't see a consistent winner.
I don't like GCC, and I don't use GCC (except on MIPS, where clang isn't quite ready), but GCC is not 'well behind the curve', it still gives acceptable performance. It was never the fastest player (ICC, XLC and Open64 were all faster), but it's pretty respectable.
I was a clang committer before I joined the FreeBSD project. I became a clang committer because I wanted an Objective-C compiler that supported a modern dialect of the language for non-Apple platforms. I took a look at the Objective-C code in gcc. It mingles parsing, semantic analysis and code generation in a convoluted knot. After a week of failing to understand it, I took at look at clang. At the time, Clang has parsing support for Objective-C, but no code generation support at all. Within a week, having never looked at the Clang codebase before, I had it generating code for a superset of the language that GCC supported.
I've also use clang to do syntax highlighting, to inspect files for type information for use in an FFI for a JIT-compiled language, and as a static analyser. How many tools have you seen that are based on GCC and aren't compilers?
Performance isn't the only metric by which you judge compilers, although I agree that it's an important one. OpenMP support affects a very small number of programs. Intel has just open sourced (BSDL) their OpenMP runtime and is pushing patches into clang, so that support should appear soon. The rest of the benchmarks show very little performance difference between clang 3.3 (which is in FreeBSD 10.0) and gcc 4.8, and neither is a clear winner in all cases. In comparison to the last GPLv2 GCC (4.2.1), which FreeBSD currently ships, both are significantly faster. If you need OpenMP today, gcc 4.8 is in ports, so just install the lang/gcc48 port and use it.
However, as I said, performance is not the only metric. Clang has full support for C++11 and supports more of C11 than GCC (for example, it correctly supports _Atomic and it supports _Generic). In FreeBSD, we're now using _Generic in a number of system headers and so you get better error reporting if your compiler supports them (fallback code exists if it doesn't). We found a few logic bugs in ports as a result of this, some of which have existed on other platforms and compiled without warnings for years. So, if you want to use the latest versions of C, C++, or Objective-C, clang is a better choice for you. We're also now shipping libc++ as the default C++ standard library, so we have a complete C++11 stack.
If you're developing C-family code and don't have a Coverity license, then having the clang static analyser around is also very helpful (it's built into clang, so you get it as part of the default install).
Practical people would be more practical if they would take a little more time for dreaming. -- J. P. McEvoy