Bah, rappelez-moi quand Clang pourra compiler Qt et KDE de manière fonctionnelle…
Pourquoi tant d'égocentrisme et une vision aussi réductrice de llvm ? D'une part, ça n'est pas parce que clang++ ne sait pas (selon tes dires, du moins) compiler Qt et KDE que c'est un compilo jouet, et d'autre part, il y a
beaucoup de choses utiles dans l'infrastructure LLVM qui n'ont pas d'équivalent dans l'infrastructure GCC ou même d'autres infrastructures.
Et puis leur frontend C++ est totalement strict, ils refusent de gérer même les fonctionnaités du C99 comme les VLAs. 
De deux choses l'une: soit les VLAs sont définis en C++ par le dernier standard C++ en date, auquel cas clang++ n'est pas conforme, soit ils ne sont pas explicitement définis par le dernier standard C++ en date, auquel cas on ne peut pas formellement reprocher à clang++ de ne pas les supporter
à l'heure actuelle.
Le frontend C et la machine virtuelle (
http://llvm.org/docs/LangRef.html ) les supportent depuis des années ("scoped automatic variable sized arrays"), en tout cas. J'ai vérifié.
#include <stdio.h>
int main(int argc, char * argv[]) {
char * array[argc+1];
int i;
fprintf(stdout,"%d\n", argc);
for (i = 0; i <= argc; i++) {
array[ i] = argv[ i];
}
for (i = 0; i <= argc; i++) {
fprintf(stdout, "\"%s\"\n", array[ i]);
}
return 0;
}
Etre plus strict que g++ dans le respect du standard C++ n'est pas forcément un mal. Même s'ils les enlèvent petit à petit, il y avait un nombre certain d'extensions non documentées (et pour certaines, pas forcément explicitement voulues) au C++, ce qui créait des problèmes de portabilité entre g++ et d'autres compilos d'une part, peut-être aussi entre versions de g++ d'autre part.
Quant à tous les morceaux non-libres dans les distros Linux... heureusement pour les utilisateurs qu'ils sont là pour permettre d'exploiter le hardware beaucoup plus à fond de ses capacités.