Would you mind to say why?

What I don't agree was this phrase.

    *much more common combination*

Why? no clue, no reason. But Clang with libc++? There're reasons.

The primary Clang user groups are Apple and FreeBSD communities. a.k.a. anti-GCC groups. Both of them really want to avoid any GCC stuff and are officially deprecating all the GCC stuff. Having dependency to GCC stuff is nonsense on these platforms. If common developers are sane enough, they' won't use libstdc++.

And other group is the Linux development. But I don't think there're really many developers who are using Clang for production on Linux. There's no big push from the platform, and also no big benefits. But there're many shortcomings for using Clang. It's not installed by default, not supported by platform, not tested much.

If there're some people want to adapt Clang on Linux even now, they won't hesitate to use libc++. And the others will just stays in good old GCC with libstdc++.

>"and also no big benefits"

I think there are several benefits in using clang tools. You might find useful the Chandler Carruth's talk on Going Native on which he demoed some great tools that doesn't really have alternative on the gnu toolchain.

http://channel9.msdn.com/Events/GoingNative/2013/The-Care-an...

Clang certainly has its advantages (the faster compile times are very nice), but for a typical user that just wants to compile stuff, there's really nothing huge—and as always they need to balanced against the disadvantages. In general it's often a wash, and you may as well just use whatever comes with your system or whatever your friends use...

For me, the killer is typically optimization: e.g. for a CPU-intensive app I work on, gcc generates a binary that is twice as fast as what clang generates (this has been true for ages and across many compiler versions). I can live with slightly pokey compiles, but having my program take one week to execute instead of two is pretty compelling...

Would you mind submitting a bug report (with a reproduction case, if you're able) to the Clang team or mailing list? IIRC, they have an automated test suite for performance and regression testing; I'm sure they would greatly appreciate you taking the time to submit a test case where clang is producing egregiously slow binaries.

I could try, but although the difference seems localized to a fairly small number of functions, I haven't been able to precisely identify why it's so slow (there's no single inner loop etc that's slow), and shrinking it to something minimal would be hard...

Many people prefer the error messages from clang

> The primary Clang user groups are Apple and FreeBSD communities. a.k.a. anti-GCC groups.

I think you meant to say anti-GPLv3 groups and you also forgot to include Linux kernel devs.