Официальный релиз LLVM 3.3

[sys_int64]

В предыдущем clang была проблема с юникодом, но в этой версии проблему решили. Все же статья больше по Clang ежели про LLVM, но все равно интересно было читать.

[DmitryBabokin]

Если под клангом подразумевать сам компилятор, а не только фронт-энд, то он включает в себя практически весь LLVM :)

[sys_int64]

CUDA тоже включает в себя LLVM, да и вообще много языков сейчас в себя включаюи LLVM, наверное правильноее было бы просто тепу назвать «Официальный релиз LLVM & Clang 3.3».

[Maratyszcza]

А над поддержкой MIC в LLVM кто-нибудь работает?

[DmitryBabokin]

Для текушего поколения Xeon Phi — нет. Для следующего — следите за анонсами :))

[AxisPod]

А стандартная библиотека для clang уже есть для всех платформ или до сих пор от GCC цеплять надо?

[Gorthauer87]

Linux нормально держит. Windows не пробовал.

[anton_ai_ivanov]

gcc то же недавно с помпой сообщил о полной поддержки C++11. Действительно польза конкуренции. И все-таки, кто же из них первый?

[DmitryBabokin]

Согласно gcc.gnu.org/ у них полная поддержка начиная с 4.8.1, который они зарелизили 31 мая, а саму поддержку добавили 1 апреля. Выходит обскакали Clang :)

[Halt]

Спасибо за новость. Вы случайно не в курсе как обстоят дела с поддержкой JIT на ARM?

[sys_int64]

Вроде бы давно он там есть.

[Halt]

stackoverflow.com/questions/6665966/is-it-possible-to-compile-llvm-libraries-to-android-arm

Антон Коробейников, имеющий непосредственное отношение к разработке LLVM, пишет:

While you can surely compile LLVM on ARM (it's pretty trivial — just ordinary configure + make system), you're still out of luck: JIT on ARM is still work-in-progress, so I'd not expect it working for everything non-trivial.

[sys_int64]

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

[gribozavr]

Сообщение датировано 2011 годом. MCJIT на ARM сейчас вполне работает, IIRC.

[Halt]

Это хорошо, просто с тех пор я не нашел упоминаний обратного

[gribozavr]

Я отвечу кодом. Вот тесты:
llvm.org/viewvc/llvm-project/llvm/trunk/test/ExecutionEngine/MCJIT/

Вот конфиг системы тестирования, в котором написано, на каких платформах тесты запускать:
llvm.org/viewvc/llvm-project/llvm/trunk/test/ExecutionEngine/MCJIT/lit.local.cfg?revision=183143&view=markup

[Halt]

Ну тогда вообще здорово. Буду тестировать llst в том числе и на андроиде =)

[NeoCode]

Когда-же у них под винду появится официальная не экспериментальная реализация (и желательно не зависящая от MinGW)?

[alexeyknyshev]

Через день после выхода MSVC под *nix.

[DmitryBabokin]

Никогда. А точнее пока это не понадобится зачем-то Майкрософту или какой-то другой очень большой компании. Ну то есть всё-таки никогда.

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

[NeoCode]

Лично я очень надеюсь, что компания Digia возьмется:) Они вроде должны быть заинтерсованы — Qt кроссплатформенный, на многих платформах clang основной компилятор… еще они вроде хотели использовать средства llvm для Qt Creator. Почему-бы заодно не сделать доброе дело для сообщества?

[DmitryBabokin]

Не думаю, что они возьмутся и осилят. ИМХО получить поддержку продуктового уровня можно только с благословения MS — слишком много подводных камней. Хотя опять же смотря о чём мы говорим. Если о компиляторе как таковом, то он не отличается от Линукса практически ничем — те же самые инструкции исполняются на там же самом железе. А вот как дело касается библиотек, поддержки системных хидеров, WinAPI и иже с ним — вот тут начинается самое интересное. И тут надо быть совместимым на уровне багов со всем чудесатым многолетним наследием. Вот как раз это практически невозможно сделать. Ну и плюс MS-специфичные расширения языка и MS-специфичная трактовка стандартов (которая необходима для тех же хидеров и библиотек).

[NeoCode]

Не понял что вы имеете в виду. Я имею в виду очень простую вещь — возможность сборки кроссплатформенных проектов (скажем, написанных на Qt или на «чистом С/С++») не только компиляторами msvc и mingw, но еще и clang.
Разработчики mingw, насколько я знаю, не имеют никакой «поддержки продуктового уровня» и никакие баги от MS не воспроизводят:)

[DmitryBabokin]

Что такое чистый С/C++? Что такое для вас кроссплатформенность? Вы хотите окошки? Вам нужен WinAPI? Вам нужна совместимость с существующими библиотеками? Думаю вам всё это нужно, а значит сразу куча проблем, которые я описал.

[NeoCode]

Чистый с/с++ — это консольные приложения, использующие только стандартную библиотеку Си и STL (а это часть языка). Если нужны окошки — то Qt. Если WinAPI — то оно как-то сделано в mingw, причем все работает.
Все остальное (к примеру MFC) не нужно.

[DmitryBabokin]

Это всё должно уже работать сейчас без проблем.

[NeoCode]

Желательна поддержка средами разработки (хотя-бы Qt Creator, и чтобы ставилось «из коробки», как mingw). Собственно, о чем и мое первое сообщение.

[DmitryBabokin]

В Cygwin он, по-моему, доступен. MinGW не пользовался, не знаю. Но желание разрабатывать на винде не под MSVC мне кажется странным. Всё кроме MSVC на винде не родное и это сильно заметно. Если хочется просто консольные вещи собирать — можно скомпилить кланг самостоятельно, поставить Cygwin/Mingw чтобы в консоли можно было хоть как-то жить и редактировать, например в gvim.

Но это только если приложения консольные.

Кстати, кланг на винде собрать не так сложно.

[NeoCode]

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

[DmitryBabokin]

Ну так тогда надо использовать родной компилятор для каждой платформы. MSVC на Винде, gcc — на Линуксе, clang — на Маке. На Линуксе можно использовать и clang, и gcc.

На счёт самостоятельной сборки компилятора согласен — это удовольствие на любителя :)

[impwx]

… после релиза С++11 нашлось несколько досадных огрехов...

Есть ссылка на статью? Интересно было бы почитать.

[DmitryBabokin]

Надо копать, сейчас не могу найти ссылки. Это где-то в выступлениях на конференция всплывало. Если найду — сюда отпишусь.

[valexey]

Начнём с поддержки C++11. Заявлена полная поддержка, включая библиотечную поддержку таких важных фич, как например, std::regex.

Врут.

Не реализовано:

1. Minimal support for garbage collection and reachability-based leak detection
2. Abandoning a process and at_quick_exit
3. Extended integral types

clang.llvm.org/cxx_status.html

[DmitryBabokin]

Там сказано чёрным по белому — N/A — not applicable, т.е. это можно трактовать «это не к нам». Про всё точно не скажу, но N2670 в стандарт не вошёл. at_quick_exit — следы реализации в кланге точно есть, почему сказано что N/A — это надо копать глубже и в первую очередь сам стандарт. N1988 — тоже не совсем поянтно, к тому же это требует изменения ABI, от чего могли намеренно отказаться.

Стандарт: www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3376.pdf

[tangro]

А тем временем после релиза Qt 5.1RC их спросили не планируют ли они поддерживать Clang, на что был ответ «Ну, когда оно перестанет быть экспериментальной поделкой и станет компилятором, то да, может быть». Всё же дофига всего в Clang ещё нету.

[gribozavr]

Ну-ну. Например?

[tangro]

OpenMP

[DmitryBabokin]

Работа над этим кипит.

[gribozavr]

Это не имеет никакого значения для Qt.

[tangro]

Да, не имеет. Мне просто показалось, что вопрос «Например?» был задан безотносительно Qt.

[sys_int64]

так то с 3.3 он присутствует: llvm.org/devmtg/2013-04/bokhanko-bataev-slides.pdf
в LLVM это реализованно через метаданные: lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20120928/aaca2b70/attachment-0001.pdf

[DmitryBabokin]

Оно ещё не готово, но работа кипит.

[Gorthauer87]

Что за бред? Оно давно на маке им компилируется.

[tangro]

«Компилируется» — не значит «работает».
Баг не закрыт и всё еще висит.

[DmitryBabokin]

Баг про винду.

[tangro]

Типа, «ай, фигня, можно забыть»? Qt — кросплатформенная библиотека и Винда — одна из основных платформ. О какой полноценной работе можно говорить, если нельзя нормально класс экспортнуть? Это ведь не мелочь какая-то, фундамент работы.

[DmitryBabokin]

Вам говорят — что на маке Qt использует clang, а вы в ответ, что на винде dllexport не поддержан. Про винду вообще никто никому ничего не обещал. Поддерживается энтузиастами и волонтёрами там всё и никаких планов продуктизации на винде, как и у gcc. Но речь тут про родные для clang платформы, там он огого какой компилятор.

[tangro]

На счёт акцента именно на маке — согласен, упустил, моя вина.

[DmitryBabokin]

Clang уже вполне себе зрелый, им компилируется большой одной операционной системы по дефолту, в нём много чего есть что у других нет :)

[tangro]

Ну Вы зря мне это отвечаете — я только привёл мнение разработчиков Qt.

[timurrrr]

… а потом построенную на этом мнении собственную (предположительно, неверную) оценку?

Всё же дофига всего в Clang ещё нету.

[tangro]

Это мнение из той же дискуссии в комментах к релизу 5.1 RC.

[leventov]

Вы случаем не знаете, почему релиз задержался на 2 недели?

[DmitryBabokin]

Во-первых, там было сказано, что объявленные сроки — это *tentative* schedule, т.е. примерные сроки.
Во-вторых, сам релиз как таковой практически не задержался. Бранч, который tags/RELEASE_33/final появился то ли 5-го, то на следующий день. Всё остальное время заняла подготовка Release Notes, как я понял. А учитывая, что у них там был WWDC, то как раз как шумиха улеглась, так Крис и нашёл время закончить. Но лично свечку не держал, точно не знаю, могу лишь предполагать.

[DjOnline]

CLang 3.3 benchmark — www.phoronix.com/scan.php?page=article&item=llvm_clang33_3way
— OpenMP так и нет.
— много где медленнее либо одинаково с gcc
— чуть чуть быстрее только в Apache под Intel.

[DmitryBabokin]

Спасибо за ссылку, интересная.

— время компиляции заметно лучше, чем у gcc, иногда это важно.
— размер кода иногда заметно меньше. При сборке самого кланга — разница в полтора раза.
— благодаря модульной структуре и изначальной ориентированности на API, вокруг кланга образовалась целая экосистема крайне полезных тулов. Начиная с дебаггера и заканчивая clang-format.
— лучшая диагностика ошибок, чем в gcc. Это критично при отладке кода, использующего сложные шаблоны, макросы и т.д. и т.п., например ошибки которые лезут из неправильного использования STL.

В общем и целом вполне конкурентный компилятор, но переключаться ли на него с gcc — личное дело каждого, в зависимости от приоритетов, личных предпочтений и обстоятельств. Clang предлагает целый ряд интересных плюшек, которые могут соблазнить многих. И полезно быть в курсе этих плюшек. Лично я использую оба компилятора в повседневной разработке.

[alexeyknyshev]

В случае с с++ время компиляции у шланга лучше, нельзя не согласиться, однако если не использовать бездумно шаблоны (или то что тянет шаблоны, например буст) и не включать лишний раз хидеры в другие хидеры, то достоинства шланга с лихвой покрывают качество кода (скорость) генерируемого g++.

Размер бинарника на выходе обычно выше как раз у шланга.

Остальное — чистая правда, в кодовой базе gcc чёрт ногу сломит)

[Arjuna]

Кто-нибудь собирал его для ppc64 на Леопарде? А то у меня падает компиляция на этом (и 3.3, и 3.4 одинаково):

/opt/local/bin/ranlib: archive member: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-3.4/llvm-3.4/work/build/Release/lib/libLLVMCodeGen.a(AllocationOrder.o) offset in archive not a multiple of 8 (must be since member is an 64-bit object file)