Статус готовности CLang к сборке ядра Linux

> Clang намного меньше

Когда он будет поддерживать столько же архитектур, сколько и gcc, тогда посмотрим на его размер.

> Когда он будет поддерживать столько же архитектур, сколько и gcc

на данный момент он умеет:

X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore

> Почему ни один фанатик до сих пор не сказал, что же за мифически плюшки оно имеет?

Откуда столько дебилов, не умеющих читать?

У gcc множество архитектурных недостатков:

- Слишком много промежуточных представлений. В llvm же только один уровень.

- Отсутствие единообразного метода для написания преобразований

- Не разделяется код между языковыми frontend-ами

- Много древнего кода, который уже давно никто не понимает

- Написано на Си, с множеством костылей

- Платформозависимые части размазаны по всем уровням

В clang и llvm все эти недостатки отсутствуют. Очень четкое разделение по уровням абстракции. Легко добавляются произвольные преобразования между этими уровнями. Как результат - есть довольно мощный и легкоуправляемый статистический анализатор кода. Есть полноценная, работающая link time optimization (то убожество, что есть в gcc, еще лет 5 допиливать до рабочего состояния будут). Clang и llvm очень маленькие и понятные, один разработчик легко может добавить новую функциональность, не тратя годы на разборки с нагромождениями древнего хлама.

А вы, придурки, все про лицензии бухтите. Не важно это. Важны только технические характеристики.

Поддержка для новой архитектуры добавляется элементарно, и занимает очень мало места. Посмотри на код.

>Открой свою ссылку и узри, что поддержка C99 в GCC неполная.

Ты говоришь так, как будто есть несферический компилятор с полной поддержкой стандартов C/C++

> Зачем нужен clang?

И про главную плюшку забыл: возможность использования компонентов компилятора внешними приложениями. Например, IDE. В XCode очень неплохой code completion сделан на основе clang, к VIM его тоже прикрутили уже. С gcc это нереально, он слишком монолитный.

Мне как простому пользователю нравятся вменяемые сообщения об ошибках, такие бы да в gcc.

В треде одни сплошные Ъ (включая mono, подтвердившего новость) и никто не заметил, что ссылка ведет не туда. :D

не знаю про все стандарты, но в сановском компиляторе поддержка С99 полная.

> Вот интересно, они адаптируют clang до совместимости с GCC-костылями или пишут патчи для ядра, чтобы лучше соответствовало стандартам?

The LLL folks «prefer adding things to Clang rather than patching the kernel», Lelbach said.

Рекомендую всё-таки сходить по ссылке и почитать, там довольно интересно.

Смотри внимательнее.. инфа с которой написана новость там в самом конце статьи. Если так важно, сейчас добавлю прямую ссылку на LLL.

Не всегда. например на такой код:

bind1st(mem_fun(&A::check), a);

где A::check принимает ссылку, оба компилятора выдают сообщения далекие от истинной причины ошибки.

> Смотри внимательнее.. инфа с которой написана новость там в самом конце статьи. Если так важно, сейчас добавлю прямую ссылку на LLL.

Вижу-вижу. Так я её, собственно, и нашёл. :) Зачем давать ссылку на кучу всего не по теме новости? Лучше сразу на http://lwn.net/Articles/441018/

знатный велосипед

Ну и нафига это чудо? Ненужно.

Не нужен ты, тупорылый ламер.

В gcc много проходов, и только в одном из них (GIMPLE-SSA) используется SSA. В LLVM он везде, в том числе и при кодогенерации и register allocation.

BSD и PCC компилируется. У них есть такое правило, что использовать только ANSI C. Это единственное что мне нравится в стане BSD.

и как твой ответ связан с моим вопросом?

> Ну и нафига это чудо? Ненужно.

Вы не только не утруждаете себя чтением по указанной ссылке, но и не читаете комментарии выше. Какой смысл в вашем вопросе, если вы все равно не прочтете ответ?

Ну если ты связи не видишь, то ты просто запредельно тупой и недоразвитый. Задумайся об этом.

>> Когда он будет поддерживать столько же архитектур, сколько и gcc

на данный момент он умеет:

X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore

а также кодогенерацию в С через
llc -march=c program.bc -o program.c
сс program.c -lstdc++
http://www.llvm.org/docs/FAQ.html#translatecxx

вопрос, ну и чем оно отличается от того же Comeau C++ зhttp://en.wikipedia.org/wiki/Comeau_C++ а $50 ,http://www.comeaucomputing.com/faqs/genfaq.html#howmuch , который давно умеет конпелировать через кодогенерацию в plain С?

> опрос, ну и чем оно отличается от того же Comeau C++ зhttp://en.wikipedia.org/wiki/Comeau_C++ а $50 ,http://www.comeaucomputing.com/faqs/genfaq.html#howmuch , который давно умеет конпелировать через кодогенерацию в plain С?

Тем, дурик, что умеет кодогенерацию не только через plain C.

> BSD и PCC компилируется. У них есть такое правило, что использовать только ANSI C.

кстати, как дела с конкурсом? http://bsdfund.org/bundle/

Ядро Linux ещё PCC не собирается из коробки, попробовал вот и обломался на п gсс-измы. Радует, что у Clanga ситуация в целом получше, может что-то и для dev-lang/pcc тоже пригодится.

export в template? а что ещё оно умеет по сравнению с llc -march=c ?

icc еще можно

о! оно умеет Plan 9 !! http://www.comeaucomputing.com/4.3.0/minor/plan9/como43101.html

А вообще, единственное хорошее, что выйдет из этого проекта - поддержка полезных gcc-измов в Clang :)

я вообще про то, что если кому-то сильно не хватает какой-то архитектуры среди поддерживаемых LLVM — то он прям вот сейчас может брать C backend и допиливать его напильником, при этом придётся пересобрать все С++ библиотеки из-за несовместимостей ABI C backend-а с C++ ABI . При этом все 100 с лишним проходов оптимизаций LLVM никуда не денутся, просто придётся после оптимизаций генерировать С код и собирать С компилятором.
LLVM вообще много чего умеет. Вот только с поддержкой стандартов и gcc-змов не всё до конца ясно, в отличие от того же Comeau.
А ты про что?

* запасаюсь попкорном и жду, кто первый крикнет «gcc-измы не нужны, лучше бы ведро допилили до стандартного C99».

Да там много чего хорошего может выйти.

Например, компактное ядро, собранное с LTO. Наверняка много ошибок в ядре найдут и исправят. Новые тулзы для разработки ядра могут появиться - всякие там call graphs с Clang-ом строить не в пример проще чем с gcc.

Разве в ведре только Си?

Был вопрос, «чем оно отличается от Comeau». Вот тем и отличается, что C backend там только для поиграться (он еще и неподдерживаемый, кстати, и очень глючный). И обычных для других backend-ов оптимизаций (того же register allocation) он не делает.

ну да, вот например ту приблуду что Линус писал со временем жизни указателей и аннотациями, вдохновившись BitC и Cyclone, вполне можно делать статическим анализатором вроде Klee.

> Новые тулзы для разработки ядра могут появиться - всякие там call graphs с Clang-ом строить не в пример проще чем с gcc.

Это уже другой вопрос... понятно, что в роли «библиотечного компилятора» у LLVM конкурентов просто нет. Но меня-то интересует широкое распространение полезных gcc-измов вроде "({".

Самые полезные gcc-измы уже давно в clang есть (те же indirect goto targets).

(26.10.2010 22:21:33):

с помощью Clang удалось собрать работоспособное ядро Linux версии 2.6.36 с поддержкой многопроцессорных систем (SMP)

Работоспособны следующие компоненты ядра:

    Базовый код ядра, файловые системы, поддержка шин, в том числе и PCI, ACPI
    SMP, SMT, SysV, pThreads и POSIX IPC
    NUMA, управление памятью и SWAP
    Сетевой стек IPv4, за исключением IPSec
    Некоторые драйверы и прошивки

Пока не удалось добиться работы следующих подсистем:

    CryptoAPI, а следовательно, и SELinux, Posix ACLs, IPSec, eCrypt
    Стека IPv6 и код Netfilter/Router из-за зависимости от CryptoAPI
    Виртуализации (поддержки гипервизора Xen)
    Поддержки загружаемых модулей

В целом:

    Удалось получить работающую сборку ядер 2.6.37 и 2.6.38 (для некоторых конфигураций)
    KVM и Xen использовать нельзя, причем последний пока даже не компилируется
    Компилируются примерно 90% драйверов ядра, многие работают
    Некоторые поставляемые сторонними вендорами драйвера (Broadcom, NVIDIA) работают отлично
    Можно использовать многопроцессорные конфигурации (правда, только на x86), однако в некоторых случаях они требуют дополнительных усилий по доработке компилируемого кода

Зачем нужен велосипед CLang, если есть свободный GCC?

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

> И обычных для других backend-ов оптимизаций (того же register allocation) он не делает.

а как ты себе представляешь выделение регистров в C бекенде? наподобие gcc-измов в асм вставках или #pragma aux в Watcom? какой тогда профит именно от С? это уже С компилятор на последней фазе должен делать, по идее.
Опять непонятно. Вот взяли LLVM BC биткод, прогнали его через opt, наложив нужные оптимизации, получив на выходе LLVM BC биткод. Этот последний через C бекенд выгнали в С и собрали С компилятором. Вопрос, что такого должен уметь или не уметь С бекенд, чтобы оптимизации не похерились. Ну то есть вопрос, насколько все эти 10500 оптимизаций composable.

> Зачем нужен велосипед CLang, если есть свободный GCC?

ну например вот:

http://www.vim.org/scripts/script.php?script_id=3302

> а как ты себе представляешь выделение регистров в C бекенде?

Там переменные регистрами служат. И их генерится до нечитабельности много.

Вопрос, что такого должен уметь или не уметь С бекенд, чтобы оптимизации не похерились.

Навскидку - потеряются tail calls.

Оптимизации backend-а и оптимизации на уровне LLVM IR - это две большие разницы. Проблема cbe в том, что он не стандартный llvm backend, а просто тупо pass.

>Очень четкое разделение по уровням абстракции. Легко добавляются произвольные преобразования между этими уровнями. Как результат - есть довольно мощный и легкоуправляемый статистический анализатор кода. Есть полноценная, работающая link time optimization (то убожество, что есть в gcc, еще лет 5 допиливать до рабочего состояния будут).

Ну оочень неочевидные «преимущества». Тем более, они все нивелируются, если вспомнить, что Clang в сравнении с GCC ничего не умеет.

ничего не умеет из gcc-измов?

> Ну оочень неочевидные «преимущества»

LTO - это «неочевидное преимущество»? Что тогда преимущество, по твоему? Ты вообще хоть что-либо в компиляторах понимаешь, чтобы нести такую чушь? Много своего кода в gcc и в clang закоммитил?

Ну оочень неочевидные «преимущества»

И чего он такого нужного не умеет? Fortran77?

а как у него с оптимизацией? На сколько хороший и быстрый код выдает по сравнению с gcc? Инлайнить хорошо умеет?

наоборот, это GCC не умеет, например, блоки http://en.wikipedia.org/wiki/Blocks_(C_language_extension)
ну их можно до какой-то степени эмулировать вложенными функциями, но блоки — это почти полноценные замыкания, в отличие от.

> Инлайнить хорошо умеет?

http://en.wikipedia.org/wiki/Link-time_optimization пройди по ссылкам для GCC и LLVM, и найди 6 отличий(начиная со слов «Issues» и «просто работает»)

>Blocks are a nonstandard extension added by Apple Inc.

Что-то ещё?

В llvm на самом деле никакого даже специального link time optimization не надо, достаточно оптимизации на уровне модулей и линкера, чтобы собрать все модули в один.

Не разработчик вообще, поэтому всё это(в том числе и педантичная поддержка стандартов) мне до лампочки, в отличие от скорости и работоспособности скомпилированного кода.