Comments 58
В предыдущем clang была проблема с юникодом, но в этой версии проблему решили. Все же статья больше по Clang ежели про LLVM, но все равно интересно было читать.
А над поддержкой MIC в LLVM кто-нибудь работает?
А стандартная библиотека для clang уже есть для всех платформ или до сих пор от GCC цеплять надо?
gcc то же недавно с помпой сообщил о полной поддержки C++11. Действительно польза конкуренции. И все-таки, кто же из них первый?
Согласно gcc.gnu.org/ у них полная поддержка начиная с 4.8.1, который они зарелизили 31 мая, а саму поддержку добавили 1 апреля. Выходит обскакали Clang :)
Спасибо за новость. Вы случайно не в курсе как обстоят дела с поддержкой JIT на ARM?
Вроде бы давно он там есть.
stackoverflow.com/questions/6665966/is-it-possible-to-compile-llvm-libraries-to-android-arm
Антон Коробейников, имеющий непосредственное отношение к разработке LLVM, пишет:
Антон Коробейников, имеющий непосредственное отношение к разработке 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.
а ну да, ну зато можно компилировать нативные приложения, они же быстрее работают чем JIT.
Сообщение датировано 2011 годом. MCJIT на ARM сейчас вполне работает, IIRC.
Это хорошо, просто с тех пор я не нашел упоминаний обратного
Я отвечу кодом. Вот тесты:
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
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
Когда-же у них под винду появится официальная не экспериментальная реализация (и желательно не зависящая от MinGW)?
Через день после выхода MSVC под *nix.
Никогда. А точнее пока это не понадобится зачем-то Майкрософту или какой-то другой очень большой компании. Ну то есть всё-таки никогда.
Пока же всё держится на энтузиастах и волонтёрах, которые докручивают потихоньку.
Пока же всё держится на энтузиастах и волонтёрах, которые докручивают потихоньку.
Лично я очень надеюсь, что компания Digia возьмется:) Они вроде должны быть заинтерсованы — Qt кроссплатформенный, на многих платформах clang основной компилятор… еще они вроде хотели использовать средства llvm для Qt Creator. Почему-бы заодно не сделать доброе дело для сообщества?
Не думаю, что они возьмутся и осилят. ИМХО получить поддержку продуктового уровня можно только с благословения MS — слишком много подводных камней. Хотя опять же смотря о чём мы говорим. Если о компиляторе как таковом, то он не отличается от Линукса практически ничем — те же самые инструкции исполняются на там же самом железе. А вот как дело касается библиотек, поддержки системных хидеров, WinAPI и иже с ним — вот тут начинается самое интересное. И тут надо быть совместимым на уровне багов со всем чудесатым многолетним наследием. Вот как раз это практически невозможно сделать. Ну и плюс MS-специфичные расширения языка и MS-специфичная трактовка стандартов (которая необходима для тех же хидеров и библиотек).
Не понял что вы имеете в виду. Я имею в виду очень простую вещь — возможность сборки кроссплатформенных проектов (скажем, написанных на Qt или на «чистом С/С++») не только компиляторами msvc и mingw, но еще и clang.
Разработчики mingw, насколько я знаю, не имеют никакой «поддержки продуктового уровня» и никакие баги от MS не воспроизводят:)
Разработчики mingw, насколько я знаю, не имеют никакой «поддержки продуктового уровня» и никакие баги от MS не воспроизводят:)
Что такое чистый С/C++? Что такое для вас кроссплатформенность? Вы хотите окошки? Вам нужен WinAPI? Вам нужна совместимость с существующими библиотеками? Думаю вам всё это нужно, а значит сразу куча проблем, которые я описал.
Чистый с/с++ — это консольные приложения, использующие только стандартную библиотеку Си и STL (а это часть языка). Если нужны окошки — то Qt. Если WinAPI — то оно как-то сделано в mingw, причем все работает.
Все остальное (к примеру MFC) не нужно.
Все остальное (к примеру MFC) не нужно.
Это всё должно уже работать сейчас без проблем.
Желательна поддержка средами разработки (хотя-бы Qt Creator, и чтобы ставилось «из коробки», как mingw). Собственно, о чем и мое первое сообщение.
В Cygwin он, по-моему, доступен. MinGW не пользовался, не знаю. Но желание разрабатывать на винде не под MSVC мне кажется странным. Всё кроме MSVC на винде не родное и это сильно заметно. Если хочется просто консольные вещи собирать — можно скомпилить кланг самостоятельно, поставить Cygwin/Mingw чтобы в консоли можно было хоть как-то жить и редактировать, например в gvim.
Но это только если приложения консольные.
Кстати, кланг на винде собрать не так сложно.
Но это только если приложения консольные.
Кстати, кланг на винде собрать не так сложно.
Есть желание разрабатывать кроссплатформенный софт, в том числе и для винды. Есть желание использовать разные компиляторы и разные инструменты разработки (просто потому что это интересно; потому что каждый инструмент предоставляет какие-то возможности, которых нет у других; а также потому, что один компилятор нередко находят ошибки, которые другой не находит). А вот желания заниматься шаманством с бубном и собирать из исходников чужой софт самостоятельно, продираясь сквозь дебри всяких зависимостей и конфигов — нет.
… после релиза С++11 нашлось несколько досадных огрехов...
Есть ссылка на статью? Интересно было бы почитать.
Начнём с поддержки C++11. Заявлена полная поддержка, включая библиотечную поддержку таких важных фич, как например, std::regex.
Врут.
Не реализовано:
- Minimal support for garbage collection and reachability-based leak detection
- Abandoning a process and at_quick_exit
- Extended integral types
clang.llvm.org/cxx_status.html
Там сказано чёрным по белому — N/A — not applicable, т.е. это можно трактовать «это не к нам». Про всё точно не скажу, но N2670 в стандарт не вошёл. at_quick_exit — следы реализации в кланге точно есть, почему сказано что N/A — это надо копать глубже и в первую очередь сам стандарт. N1988 — тоже не совсем поянтно, к тому же это требует изменения ABI, от чего могли намеренно отказаться.
Стандарт: www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3376.pdf
Стандарт: www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3376.pdf
А тем временем после релиза Qt 5.1RC их спросили не планируют ли они поддерживать Clang, на что был ответ «Ну, когда оно перестанет быть экспериментальной поделкой и станет компилятором, то да, может быть». Всё же дофига всего в Clang ещё нету.
Ну-ну. Например?
OpenMP
Работа над этим кипит.
Это не имеет никакого значения для Qt.
так то с 3.3 он присутствует: llvm.org/devmtg/2013-04/bokhanko-bataev-slides.pdf
в LLVM это реализованно через метаданные: lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20120928/aaca2b70/attachment-0001.pdf
в LLVM это реализованно через метаданные: lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20120928/aaca2b70/attachment-0001.pdf
Что за бред? Оно давно на маке им компилируется.
«Компилируется» — не значит «работает».
Баг не закрыт и всё еще висит.
Баг не закрыт и всё еще висит.
Баг про винду.
Типа, «ай, фигня, можно забыть»? Qt — кросплатформенная библиотека и Винда — одна из основных платформ. О какой полноценной работе можно говорить, если нельзя нормально класс экспортнуть? Это ведь не мелочь какая-то, фундамент работы.
Вам говорят — что на маке Qt использует clang, а вы в ответ, что на винде dllexport не поддержан. Про винду вообще никто никому ничего не обещал. Поддерживается энтузиастами и волонтёрами там всё и никаких планов продуктизации на винде, как и у gcc. Но речь тут про родные для clang платформы, там он огого какой компилятор.
Clang уже вполне себе зрелый, им компилируется большой одной операционной системы по дефолту, в нём много чего есть что у других нет :)
Вы случаем не знаете, почему релиз задержался на 2 недели?
Во-первых, там было сказано, что объявленные сроки — это *tentative* schedule, т.е. примерные сроки.
Во-вторых, сам релиз как таковой практически не задержался. Бранч, который tags/RELEASE_33/final появился то ли 5-го, то на следующий день. Всё остальное время заняла подготовка Release Notes, как я понял. А учитывая, что у них там был WWDC, то как раз как шумиха улеглась, так Крис и нашёл время закончить. Но лично свечку не держал, точно не знаю, могу лишь предполагать.
Во-вторых, сам релиз как таковой практически не задержался. Бранч, который tags/RELEASE_33/final появился то ли 5-го, то на следующий день. Всё остальное время заняла подготовка Release Notes, как я понял. А учитывая, что у них там был WWDC, то как раз как шумиха улеглась, так Крис и нашёл время закончить. Но лично свечку не держал, точно не знаю, могу лишь предполагать.
CLang 3.3 benchmark — www.phoronix.com/scan.php?page=article&item=llvm_clang33_3way
— OpenMP так и нет.
— много где медленнее либо одинаково с gcc
— чуть чуть быстрее только в Apache под Intel.
— OpenMP так и нет.
— много где медленнее либо одинаково с gcc
— чуть чуть быстрее только в Apache под Intel.
Спасибо за ссылку, интересная.
— время компиляции заметно лучше, чем у gcc, иногда это важно.
— размер кода иногда заметно меньше. При сборке самого кланга — разница в полтора раза.
— благодаря модульной структуре и изначальной ориентированности на API, вокруг кланга образовалась целая экосистема крайне полезных тулов. Начиная с дебаггера и заканчивая clang-format.
— лучшая диагностика ошибок, чем в gcc. Это критично при отладке кода, использующего сложные шаблоны, макросы и т.д. и т.п., например ошибки которые лезут из неправильного использования STL.
В общем и целом вполне конкурентный компилятор, но переключаться ли на него с gcc — личное дело каждого, в зависимости от приоритетов, личных предпочтений и обстоятельств. Clang предлагает целый ряд интересных плюшек, которые могут соблазнить многих. И полезно быть в курсе этих плюшек. Лично я использую оба компилятора в повседневной разработке.
— время компиляции заметно лучше, чем у gcc, иногда это важно.
— размер кода иногда заметно меньше. При сборке самого кланга — разница в полтора раза.
— благодаря модульной структуре и изначальной ориентированности на API, вокруг кланга образовалась целая экосистема крайне полезных тулов. Начиная с дебаггера и заканчивая clang-format.
— лучшая диагностика ошибок, чем в gcc. Это критично при отладке кода, использующего сложные шаблоны, макросы и т.д. и т.п., например ошибки которые лезут из неправильного использования STL.
В общем и целом вполне конкурентный компилятор, но переключаться ли на него с gcc — личное дело каждого, в зависимости от приоритетов, личных предпочтений и обстоятельств. Clang предлагает целый ряд интересных плюшек, которые могут соблазнить многих. И полезно быть в курсе этих плюшек. Лично я использую оба компилятора в повседневной разработке.
В случае с с++ время компиляции у шланга лучше, нельзя не согласиться, однако если не использовать бездумно шаблоны (или то что тянет шаблоны, например буст) и не включать лишний раз хидеры в другие хидеры, то достоинства шланга с лихвой покрывают качество кода (скорость) генерируемого g++.
Размер бинарника на выходе обычно выше как раз у шланга.
Остальное — чистая правда, в кодовой базе gcc чёрт ногу сломит)
Размер бинарника на выходе обычно выше как раз у шланга.
Остальное — чистая правда, в кодовой базе gcc чёрт ногу сломит)
Кто-нибудь собирал его для 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)Sign up to leave a comment.
Официальный релиз LLVM 3.3