Уже дышит в спину, уже наступает на пятки

Это тесты скорости сборки или работы собранных приложений?

оно будет работать нормально (не собираюсь спорить быстро или нет) под x86, amd64, powerpc и arm. список этот полностью ограничен сферой заинтересованности яблока и никогда не изменится в силу лицензии. ненужно

Работы естественно, собирает clang быстрее.

список этот полностью ограничен сферой заинтересованности яблока и никогда не изменится в силу лицензии

https://www.ohloh.net/p/llvm/contributors

никто тебе не мешает контрибутить, лицензия это не запрещает

Его разрабатывают в университете Иллинойса, Яббл лишь спонсор и таки бэкенды в различные архитектуры там проще прикручивать.

никогда не изменится в силу лицензии

А что там за лицензия такая?

единственный спонсор. не будут серьезно браться за это другие компании в силу лицензии. исключение - договору с яблом

Опережает незначительно, а в тестах где нужен openMP отстает в разы. Вот когда допилят, тогда и посмотрим.

Запасаюсь попкорном, чтобы посмотреть на эпическую битву неповоротливого комбайна, с комбайном, который не хочет признавать свою неповоротливость!

An easily retargettable code generator, which currently supports X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore.
A Just-In-Time (JIT) code generation system, which currently supports X86, X86-64, PowerPC and PowerPC-64.

http://llvm.org/Features.html

Между прочим, в gcc 4.8 сделают выхлоп (сообщения об ошибках) даже более качественный, чем в шланге. А ведь шланг этим гордился.

А ведь шланг этим гордился.

и сейчас гордится, про gcc такого сказать нельзя, вот будет - можно будет и сравнить, и кстати вот явный плюс от clang - в gcc наконец-то зачесались

это все конечно круто, но как по мне то с GCC история будет та же, что и с apache - даже при наличии лучших альтернатив он останется стандартом большинства.

в силу лицензии

потому что не bsd?

а апач сейчас где-то используется кроме как на домашних страничках васей пупкиных?

круто, но пока полли не заработает трубить не будем, когда заработает то всё гнукопец.

О_о эм вообщето нет,но да ладно.

Если не считать отсутствия поддержки openMP

Если не считать, что в системном блоке нет процессора, то комп в целом хороший.

хитрые плагины для llvm типа polly

Чем оно лучше графита?

там БСД а это значит бери то что хочешь и ничего не отдавай в замен. кому из проприетарщиков не нравится такая лицензия срочно продавайте бизнес!

шланг гордился не этим а тем что он использует ллвм, а для ллвм это таки да нативная фича.

У меня nginx с php-fpm заменили апач, но это стоило некоторых усилий. Например, rewrite там совсем иной.

для ллвм это таки да нативная фича.

вывод ошибок при компиляции C/C++/Obj-C - исключительно дело clang

пока ничем оба не работают.

за счёт анализатора кода ллвм. но таки да исключать это из плюсов кланга низзя.

ну да, на подавляющем большинстве хостингов.

с недавнего времени интересует следующий вопрос: каким образом у них реализованы парсеры языков? хардкод или через некий генератор?

Уже дышит в спину, уже наступает на пятки

...уже который год. И что?

Мм… А на что переползли коммерческие хостинги? Я что-то упустил, видимо, долго был в криокамере…

Не знаю, к счастья или к сожалению, но факт в том, что да, используется.

А это и не плохо совсем, в том плане что gcc никуда не денется, а соревнуясь между собой что clang что gcc будут лучше в итоге. Тем более если очень приспичит можно свободно перенести фичи clang в gcc если они есть вообще.

Да, на нём крутятся немало крупных проектов.

Даже очень крупные организации с высокой нагрузкой. Правда в связке с кеширующими прокси.

Уже дышит в спину, уже наступает на пятки

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

и кстати вот явный плюс от clang - в gcc наконец-то зачесались

Это да, однозначно:)

а для ллвм это таки да нативная фича

LLVM не имеет к этому ни малейшего отношения. Учи матчасть.

Синтаксический анализ кода - это не дело LLVM, он используется только для кодогенерации.

А анализ кода - это таки исключительно дело Clang.

Огорчу вас: есть сравнение на gcc.gnu.org, и оно не в пользу GCC.

Причём GCC-шники ещё и гордятся, что их компилятор выдаёт кучу варнингов на одной строчке, вместо того чтобы гасить лишние, вот что написано про две одинаковые ошибки в одной строке format:

GCC detects that there are two errors, while Clang only detects one

Если к этому добавить уже вышедший clang 3.2 с мелкими улучшениями диагностики и - самое главное! - доступность clang в виде библиотеки, то GCC просто никакой. Потому что внутри среды разработки clang может расставить диагностику прямо по коду, подчеркнуть точно нужные места и предложить исправления, пока gcc будет в лог всё кидать (хорошо, если среда лог распарсит и сама расставит вдоль кода).

Огорчу вас: есть сравнение на gcc.gnu.org, и оно не в пользу GCC.

Огорчу вас - 4.8 еще не вышел.

Чем оно лучше графита?

В gcc есть много опций оптимизации, которые нужно включать отдельно и следить, не начала ли программа падать. В clang из коробки всё нужное работает.

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

Вы меня не огорчили. Я болею за clang, и clang 3.2 вышел раньше нового GCC - а по ссылке сравнение clang 3.1 с GCC из будущего.

У обоих вручную написанный парсер. У gcc с этим целая история есть: первая версия GCC была написана на каком-то диалекте паскаля, затем переписали на C с ручным парсером, затем перешли на bison, а в итоге обратно на ручной парсер.

Я болею за clang

Выздоравливай.

P.S. случаи типа recursive.C ты проигнорировал. Наверное, это последствие твоей болезни.

clang, конечно интересен, но лично меня не устраивают 2 вещи:

1) нет openMP

2) использовние sse для операций с вещественными числами. В GCC, если нужно, можно пожертовать скоростью и включить -mfpmath=387. Есть ли такая возможность в clang? Чтение мана как-то не слишком помогло в этом вопросе.

P.S. случаи типа recursive.C ты проигнорировал.

Спасибо, не заметил, ваша правда. Примеры хорошие, схоронил к себе для тестов.

А вот в примере после recursive стоило бы обновить информацию, ибо clang 3.2 справляется с ним на ура - вот такие ошибки выдаёт.

template<class T> void f(T::type) { }
struct A { };
void g()
{
    A a;
    f<A>(a);
}

apache - даже при наличии лучших альтернатив он останется стандартом большинства.

Что сейчас есть такое же гибкое, расширяемое и стабильное?

nginx же.

компилятор выдаёт кучу варнингов на одной строчке, вместо того чтобы гасить лишние
лишние

не бывает лишних диагностических сообщений :)

А ведь шланг этим гордился.

Не только этим. Его еще легко можно использовать в качестве анализатора кода, чем и пользуются всякие xcode да clang_complete.

...уже который год. И что?

А то, что уже давно он основной компилятор для ios.

ладно я поверю вам также как и тому кто мне рассказал про обратное.