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

> Что-то ещё?

Дадада, нестандартные расширения от gcc все конечно же полезные и нужные, а если от Apple, то сразу нунах?

Ты давай, сначала за LTO, static analysis и code completion отчитайся, ламерье ущербное.

> Не разработчик вообще,

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

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

А скорость и качество кода как раз от качества отпимизаций и анализа и зависит.

тебе привести список всех нестандартных расширений в GCC, или сам найдёшь?
в чём поинт использования каждого такого расширения, например, в ядре Linux?
если можно писать на plain C99 как те же BSD?
в чём поинт такого сравнения вообще, меряемся у кого список нестандартных расширений толще?
или нужен список того, что «просто работает»?

> Компилируются примерно 90% драйверов ядра, многие работают

Гениально.

У тебя бугурт, уйди.

А скорость и качество кода как раз от качества отпимизаций и анализа и зависит.

Только вот почему-то так всё выглядит только в теории, а на практике старый, жирный и непонятный GCC по производительности скомпилированного кода уделывает все остальные opensource-компиляторы.

> У тебя бугурт, уйди.

Продолжаешь тявкать, животное? Усохни.

Только вот почему-то так всё выглядит только в теории, а на практике старый, жирный и непонятный GCC по производительности скомпилированного кода уделывает все остальные opensource-компиляторы.

На практике, с LTO у clang+llvm бинарники получаются иногда в два раза меньше, чем у gcc. А для всяких embedded и mobile устройств это весьма важно.

Да и что ты такое, чтобы вякать про «практику», а, не-разработчик? Ты ж тупой и не знаешь вообще ни черта.

И еще, придурок. Догадайся, почему разработчики под Mac OS X предпочитают пользоваться clang при отладке, и только release собирают gcc.

> в отличие от скорости и работоспособности скомпилированного кода.

ты будешь смеяться, но на похорониксе (можно уже сразу /0) интересная статья вышла. Про сравнение тёплого с мягким. На форумах. В общем, человек поставил себе С компиляторы pcc, tcc, open64, gcc, llvm (clang), icc. И устроил бенчмарк, ггг, скомпилированного кода. Жаль, в openwatcom поддержки x86_64 нет и не предвидится (хотя я собрал x86 компилятор на x86_64 линуксе, там не очень сложно) — тоже было бы полезно сравнить (только вот найти такой тест, который openwatcom собирает).
Похороникс тут хорош тем, что у них есть openbenchmarking.org, как раз про сравнение тёплого с мягким. Можно скачать phoronix-test-suite, запустить у себя, потом в настройках указать профиль на openbenchmarking.org, он сам закачает на сайт. Можно набигать на сайт и сравнивать результаты, отбирая других тестеров с похожим железом.

В общем, результаты тестов весёлые у него получились — tcc и pcc вообще без оптимизаций всех зарулили. Не по скорости конпеляции, а по скорости сконпелированного кода. Если добавлять оптимизации, картина немного меняется. Но осложняется тем, что для каждого отдельного конпелятора нужно подбирать свой набор флагов оптимизации.

В итоге, чёго он там своим тестом мерил — никто так и не понял. Хорошая иллюстрация про сравнение яблоков с апельсинами. Опять же, разница в производительности кода сферического бенчмарка, собранного pcc/tcc/gcc не столь велика, как казалось, если уж код вообще собрался из-за отсутствия gcc-измов и различий в понимании того же С++ (поэтому сравнения С компиляторов адекватнее).

http://phoronix.com/forums/showthread.php?29090-CompilerDeathMatch-surprising...

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

Недоумок, да кого колышет производительность?

Clang нужен разработчикам. Чтобы проще было ядро, блин, разрабатывать. Компили его потом чем хочешь, придурок.

> Clang в любом случае проигрывает в производительности

/0
странно у тебя понималка работает.

Он не может собрать ядро -> разработка невозможна -> он не нужен. И да, производительность волнует всех, кроме тебя. А теперь уйди.

Ну оно же тут уже призналось, что «вообще не разработчик». Добавь к этому тот факт, что оно все же осмелилось всунуться в дискуссию о компиляторах, и получишь адекватное представление об интеллектуальном уровен этого убожества.

Всё что понял из википедии: «Комбинация Clang и LLVM предоставляет большую часть тулчейна, позволяя полностью заменить GCC»
Получаеться, что война этих компиляторов больше идеалогическая, ведь:
«Clang изначально спроектирован для максимального сохранения информации в ходе процесса компиляции» (проприетарщина), в то время как джикакой обычно собирают то, что распространяеться вместе с исходниками ИМХО

> Он не может собрать ядро -> разработка невозможна -> он не нужен.

Да, пациент однозначно невменяемый.

Оно может собрать ядро. В достаточном для как минимум статического анализа объеме. А уж про всякий там code completion и говорить нечего, все хедеры парсятся отлично.

И да, производительность волнует всех, кроме тебя.

Ты тупой. Производительность release build - да, всех волнует. А вот производительность заинструментированного по самые гланды отладочного build-а не колышет вообще никого.

А теперь уйди.

Что-то сявка совсем развякалась. Даже не осознаешь, чмо, насколько ты себя уже опозорило.

> «Clang изначально спроектирован для максимального сохранения информации в ходе процесса компиляции» (проприетарщина),

Читать не умеешь, или прикидываешься? При чем тут «проприетарщина»?

В приведенной цитате речь идет о том, что GCC очень быстро опускается до чрезмерно низкого уровня, на котором невозможны уже ни всяческие хорошие оптимизации, ни полноценный анализ. LLVM же достаточно высокоуровневый, чтобы можно было восстановить многое из семантики исходного кода, что полезно для оптимизаций и необходимо для анализа.

джикака — это великолепно, да. этапять. почти как автолулзы.

Неужели с связанные с boost и stl ошибки в Clang не занимают 10 экранов терминала 80х25? Если нет — завтра же перехожу в ряды фанатиков Clang :))

> Неужели с связанные с boost и stl ошибки в Clang не занимают 10 экранов терминала 80х25?

Не занимают. Намного компактнее и понятнее.

Просто у поциента гента (головного моска).

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

Тогда просто покажи, в каком месте Clang ориентирован на разработчиков, в их роадмапе во главу угла поставлены end-user features.

a gcc не оптимизирует? Наверное на нём оси и пишут, т.к. он

опускается до чрезмерно низкого уровня.

Это вам не тетрис писать. В системном программировании так и должно быть, не?

> в каком месте Clang ориентирован на разработчиков

посмотри как просто прикрутили clang к vim, а теперь посмотри на потуги навроде gcc-xml, которые так и закончились ничем

> a gcc не оптимизирует?

Оптимизирует, и неплохо, но это его потолок возможностей. Архитектурно там некуда уже развиваться. Всякую там автоматическую векторизацию там уже почти нереально прикрутить.

Это вам не тетрис писать. В системном программировании так и должно быть, не?

Это вообще что за бред? Какое на фиг «системное программирование»? Какой к бесам тетрис?

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

> Тогда просто покажи, в каком месте Clang ориентирован на разработчиков, в их роадмапе во главу угла поставлены end-user features.

Ну ты баран. Для компилятора разработчики - это и есть end users.

В clang есть static code analysis, в gcc его нет. Эта фича разработчикам совершенно необходима.

В clang намного более вменяемые сообщения об ошибках, что облегчает жизнь разработчикам.

С llvm намного проще делать произвольное инструментирование кода - это абсолютно необходимо для разработчиков (и разработчиков ядра в особенности).

Clang элементарно интегрируется с IDE - а gcc не интегрируется никак.

Мало тебе этого, не-разработчик?

>Для компилятора разработчики - это и есть end users.

End-User Features:

* Fast compiles and low memory use

* Expressive diagnostics (examples)

* GCC compatibility

Да ну? Впрочем, предыдущий чуть менее хамоватый анонимус к месту дал ссылку на коллекцию пхорониксовских тестов, там у Clang'а почти везде неплохой выигрыш в работе с аудио и видео, надо будет попробовать.

GCC существует давно и проверен временем. Он соответствует стандартам, поддерживает кучу платформ, слывёт как надёжное решение для разработки и активно развивается. Но у него есть недостаток - его написала не Apple (с точки зрения Apple) и его использовать некошерно в BSD, ибо GNU (с точки зрения отморозков-бздунов) *ухмыляющаяся морда*

Но главная беда не в этом. Важно почему не спросили Вашего разрешения на создание нового компилятора.

>license bdsm??? БСД может?

Это я чисто машинально описАлся. По Фрейду

Да-да, дурень, конечно же expressive diagnostics - это не для разработчика, а для пользователя скомпилированного clang-ом бинарника. Скорость компиляции тоже очень нужна конечно же пользователям бинарника, а не разработчикам, ага.

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

> посмотри на потуги навроде gcc-xml, которые так и закончились ничем

Ты просто не в теме. gcc-xml стал полезным инструментом.

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

> Ты просто не в теме. gcc-xml стал полезным инструментом.

конечно не в теме, конечно стал, а то что он «мертв» - это дело такое, со всеми полезными инструментами бывает

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

Неправильный вопрос. Правильный: зачем нужен gcc? Ответ - кусок говнокода не нужен. Если бы не сланг, то эти «я боюсь что мой код своруют и потому пишу как можно хуже» до сих пор бы срали нам в рот. gcc пора закопать на свалку историю и вбить в него осиновый кол. И залить цементом.

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

Я, если ты не заметил, аноним. Так что уж поверь на слово - коммиты мои есть и в gcc (начиная еще с egcs, если помнишь, что это такое), и в llvm, и в clang. Правда, не ясно, какое это имеет отношение к обсуждаемой теме - ты ты тут херню несешь вполне себе прямым текстом, легко проверяемую. Никаких внешних пруфлинков не надо - ты тупой хотя бы просто по результатам этой дискуссии.

И, эцсамое, ты про низкое потребление памяти забыл, которое так важно разработчикам.

Естественно это важно разработчикам. Не забывай, что clang - модульный компилятор. Его часто встраивают в другие приложения (да в те же IDE, хотя бы), и конечно же разработчикам важно, чтобы он жрал поменьше памяти. Я уж молчу про всякую экзотику вроде реализаций OpenCL на основе clang (а все, кроме nvidia, именно на clang и сделаны) - там чем памяти меньше, тем лучше.

> Правильный: зачем нужен gcc?

Ну, хотя бы как коллекция исторически выстраданных оптимизаций, которые стоит и в более современные компиляторы перенести.

Да и там довольно таки много полезных идей. Так что как минимум историческую ценность gcc отрицать не стоит. А вот развивать его дальше действительно нет особого смысла, слишком дорого и сложно.

Ну ладно, ты меня почти убедил. Обещаю никогда больше не спорить о компиляторах.

Пикрелейтед. http://s53.radikal.ru/i139/1105/ad/b23d70b98ae0.jpg

> а то что он «мертв» - это дело такое, со всеми полезными инструментами бывает

Инструмент жив, пока им пользуются. Так что gcc-xml вполне жив, а ты сказал две глупости.

> Инструмент жив, пока им пользуются. Так что gcc-xml вполне жив, а ты сказал две глупости.

нет - прокомментировал одну твою, win95, например, тоже еще пользуются, если ты считаешь ее нужной и живой - дело твое конечно, можешь быть ее персональным фанатом и продлевать ее «нужность» вплоть до конца своей жизни своим существованием ( это образно было сказано )

> а теперь посмотри на потуги навроде gcc-xml, которые так и закончились ничем

ну почему сразу ничем. очень знатный велосипед получился, можно сравнить тот же «REPL для C» : на GCCXML.hs http://neugierig.org/software/c-repl и на базе LLVM: http://code.google.com/p/ccons/

другое дело, что GCCXML как бы немного сдох.

а то говорят тут, нет дескать, репла для C. просто C для репла не очень-то и подходит.

Clang разрабы wine активно используют для выявления ошибок( wine 1.3.18 ). Clang что-нибудь, кроме C etc, ещё поддерживается? Фортран есть? gfortran кстати по производительности скомпилированного кода сильно сливает ifort. Это к вопросу о gcc.

> можно сравнить тот же «REPL для C» : на GCCXML.hs http://neugierig.org/software/c-repl

видел его - до чего-либо рабочего оно так и не доросло

> И еще, придурок. Догадайся, почему разработчики под Mac OS X предпочитают пользоваться clang при отладке, и только release собирают gcc.

Разработчики под что ? Ты приводишь закрытую, тормозную х-ню в качестве примера для подражания ?

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

Почему кот лижет яйца? Потому что может. Были бы такие же удобные тулзы, как в XCode, во всяких там еклипсах, разработчики под лялих делали бы ровно то же самое.

Это хорошо или плохо?

> Почему кот лижет яйца? Потому что может. Были бы такие же удобные тулзы, как в XCode, во всяких там еклипсах, разработчики под лялих делали бы ровно то же самое.

Ну.. раз пошла такая песня. Xcode не видел. Он лучше Visual Studio ?

Никто так и не сказал зачем оно нужно. Видел только какие-то сомнительные сравнения архитектуры с оной гцц.

> Никто так и не сказал зачем оно нужно

да хотя бы просто как еще одна альтернатива - линукс ведь тем и хорош, что в нем есть выбор «комплектующих»

>Clang что-нибудь, кроме C etc, ещё поддерживается?

Название _C_lang как бы намекает.