> Т.е. вы хотите, чтобы clang сразу моментально был похож на gcc один в один.

Ну, вообще, я почему-то нескромно считаю что если проводится бенчмарк - было бы хорошо если бы участники оного не фэйлили тесты для начала. На GCC тоже можно в принципе понаезжать за это, но меньше и в основном на девел версию.

> Не смотря на общую динамику развития.

Динамика - это хорошо. Кто б спорил. Вот только учтя что почти все разработчики в эппле - вопрос в том в чью пользу эта динамика будет.

> Просто разработчики сосредоточились на выявлении конкретных несовместимостей при сборке
> конкретного ПО. А не просто на тестах ради тестов.

Ну, в моем понимании, компилер претендующий на полноценность все-таки должен осиливать сборку софта типа x264.  

> Кроме того, те фичи, допустим в Линукс-ядре, которые собираются ценой уродства
> архитектуры gcc - можно выкинуть из самого (например) Линукса, а не пытаться
> портить новый компилятор ради поддержки дурных решений.

Нет, безусловно, идеальный мир - это хорошо. Вот только понятия о "дурных решениях" может и не совпадать у разных индивидуалов. Это вас не смущает? :) И, собссно, а что убедит ядерщиков проделать этот объем работ? Заява каких-то конкретных индивидуалов "%s - дурное решение" имхо вообше не котируется, как минимум без хорошего технического обоснования.

> Просто многоие поклонники этих gcc-ориентированных убогостей

А на основании чего - "убогостей"? То что для вас - убогости, для других может быть и рулезом. А истина - как обычно где-то посередине.

> из-за шаблонности своего мышления не догадываются, что у разработчиков
> компиляторов всегда есть такой ход, как не поддерживать те фичи, которые  им не нравятся.

А знаете, у разработчиков софта есть такой ход как потребовать пререквизиты для сборки. И можно указать среди них конкретный компилер с конкретными фичами, например, если разработчики других компилеров не хотят идти навстречу и реализовывать фичи а эти фичи используются. И, кстати, оснований у разработчиков ядра потребовать фичи от компилера - ровно столько же сколько у разработчиков компилера на это положить с прибором :).

Можно, конечно, понаезжать что это портит портабельность. Но гцц есть под все платформы под которые есть LLVM и еще под кучу, под которые LLVM еще и в проекте нет. Так что наезд не очень то и сильный. Да и все другие мало-мальски крупные ядра компилятся 1-2 компилерами без больших плясок с бубнами, так что опять же. Можно конечно по этому поводу заявить что "все пи..сы!", но на этот счет есть довольно жизненный анекдот.

> Что неминуемо повлечет за собой переделку самого софта,

И что же НЕМИНУЕМО сподвигнет разработчиков? Нож? Или пистолет? oO

> который подобные угробищные фичи поддерживает.

Опять же - понятия о прекрасном у всех разные. Как-то за всех решать что для них угробищно а что нет - некультурно, знаете ли. Готов поспорить что разработчики сами выберут для себя - что угробищно, а что - нет. Можете попробовать обосновать почему те или иные фичи угробищны, однако врядли кого-то убедят сами по себе вопли "%s - угробище!". Если кто-то поюзал фичу - очевидно, он не считал ее угробищной.

> А вовсе не допиливания самого компилятора в целях соответствия какому-то очередному
> убожетсву.

Ну, если считается что линуксное ядро - убожество, недостойное нормально компилиться Единственно Правильным Компилером (тм), то что же тогда сподвигнет разработчиков этого ядра шевелиться насчет поддержки этого компилера? Как-то ну совсем нелогично, вы не находите? oO