После 6 месяцев разработки доступен (
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2012-Decemb... релиз проекта LLVM 3.2 (http://llvm.org) (Low Level Virtual Machine) - GCC совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод (http://llvm.org/docs/BitCodeFormat.html) RISC подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный платформонезависимый псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы.Основные новшества (http://llvm.org/releases/3.2/docs/ReleaseNotes.html) LLVM 3.2:
- В LLVM-фронтэнде Clang обеспечена полноценная поддержка стандарта C++'11 (https://www.opennet.ru/opennews/art.shtml?num=31476). В статический анализатор кода Clang добавлена поддержка внутрипроцедурного анализа. Улучшены средства диагностики. Расширена поддержка языка Objective-C, в том числе обеспечена поддержка новых литералов для работы с массивами и словарными типами данных;
- Представлена начальная реализация кода автоматичечкой векторизации (auto-vectorizer) циклов;
- Добавлены оптимизации для некоторых новых моделей процессоров на базе архитектуры ARM;
- Добавлен новый бэкенд NVPTX, созданный при участии компании NVIDIA, для генерации кода с использованием виртуальной системы команд (Instruction Set Architecture) псевдоязыка NVIDIA PTX (http://en.wikipedia.org/wiki/Parallel_Thread_Execution) (Parallel Thread Execution), используемого в окружении CUDA;
- Новый алгоритм фазы компиляции SROA (Scalar Replacement of Aggregates);
- Расширена поддержка инструкций AVX2 (Advanced Vector Extensions) для процессоров x86;
- Значительно улучшена работа бэкенда MIPS, включая обеспечение поддержки интегрированного ассемблера и дизассемблера;
- Существенное улучшение поддержи формата ELF для архитектуры
PowerPC64;
Из параллельно развивающихся проектов, основанных на LLVM, можно отметить:
- KLEE (http://klee.llvm.org/) - символьный анализатор и генератор тестовых наборов;- Runtime-библиотека compiler-rt (http://compiler-rt.llvm.org/);
- llvm-mc (http://llvm.org/releases/2.6/docs/ReleaseNotes.html#mc) - автогенератор ассемблера, дизассемблера и других, связанных с машинным кодом компонентов, на основе описаний параметров LLVM-совместимых платформ.
- VMKit (http://vmkit.llvm.org/) - виртуальная машина для Java и .NET;
- Реализация функционального языка программирования Pure (http://pure-lang.googlecode.com/);
- LDC (http://www.dsource.org/projects/ldc) - компилятор для языка D;
- Roadsend PHP (http://code.roadsend.com/rphp) - оптимизатор, статический и JIT компилятор для языка PHP;
- Виртуальные машины для Ruby: Rubinius (http://rubini.us/) и MacRuby (http://www.macruby.org/);
- Unladen Swallow (http://code.google.com/p/unladen-swallow/) - реализация языка Python;
- LLVM-Lua (http://code.google.com/p/llvm-lua/)
- FlashCCompiler (http://llvm.org/devmtg/2008-08/Petersen_FlashCCompiler.pdf) - средство для компиляции кода на языке Си в вид пригодный для выполнения в виртуальной машине Adobe Flash;
- LLDB (http://lldb.llvm.org/) - новая (https://www.opennet.ru/opennews/art.shtml?num=26907) модульная инфраструктура отладки, использующая такие подсистемы LLVM как API для дизассемблирования, Clang AST (Abstract Syntax Tree), парсер выражений, генератор кода и JIT-компилятор. LLDB поддерживает отладку многопоточных программ на языках C, Objective-C и C++; отличается возможностью подключения плагинов и скриптов на языке Python; демонстрирует экстремально высокое быстродействие при отладке программ большого размера;
- emscripten (https://github.com/kripken/emscripten/wiki) - компилятор биткода LLVM в JavaScript, позволяющий преобразовать для запуска в браузере приложения, изначально написанные на языке Си. Например, удалось запустить Python, Lua, Quake, Freetype;
- sparse-llvm (https://github.com/penberg/sparse-llvm) - бэкенд, нацеленный (https://www.opennet.ru/opennews/art.shtml?num=31636) на создание Си-компилятора, способного собирать ядро Linux.
- Portable OpenCL (https://www.opennet.ru/opennews/art.shtml?num=32092) - открытая и независимая реализация стандарта OpenCL;
- CUDA Compiler (https://www.opennet.ru/opennews/art.shtml?num=33800) - позволяет сгенерировать GPU-инструкции из кода, написанного на языках Си, Си++ и Fortran;
- Julia (https://www.opennet.ru/opennews/art.shtml?num=33315) - открытый динамический язык программирования, использующий наработки проекта LLVM.
URL: http://lists.cs.uiuc.edu/pipermail/llvm-announce/2012-Decemb...
Новость: https://www.opennet.ru/opennews/art.shtml?num=35666
Я поначалу думал, что релиз FreeBSD 9.1 задерживается, потому что разработчики хотят включить в него Clang/LLVM 3.2. Но наверное те образы, которые выложены на фтп, уже не изменят.
его в 10й версии планируют ввести как основной, но gcc там будет по умолчанию
Кстати, опубликовали годовой отчет FreeBSD Foundation, там много интересного, а на opennet.ru новости почему-то нет. http://freebsdfoundation.org/press/2012Dec-newsletter.shtml
Самопиар забавный. У гражданина явно розовые очки на глазах.
> Кстати, опубликовали годовой отчет FreeBSD Foundation, там много интересного, а на opennet.ru
> новости почему-то нет.дык напиши, дел-то.
Прогресс clang очень радует.
Пора ему уже обгонять GCC. Или еще 10 лет надо? Он же такой хороший прехороший, такой модульный премодульный, такой понятный для новичка. Когда рвать GCC то начнет не на словах?
он уже сейчас рвет - static analyzer очень очень не плох.
ну и почему-то именно llvm используют в X.org для компиляции шейдеров, а gcc оказался не при делах..
На каких тестах рвёт? Пожалуйста, покажите.Пока ничего не видел.
> На каких тестах рвёт? Пожалуйста, покажите.
> Пока ничего не видел.покажите пожалуста статический анализатор в gcc - а потом поговорим :-) Этого у gcc нету и не будет..
>> На каких тестах рвёт?
>статический анализаторМы поняли, его анализы порвут люьые тесты!
> Этого у gcc нету и не будет..GCC настолько суров, что компиляет всё подряд без всяких анализов, ага.
>покажите пожалуста статический анализатор в gccА зачем он именно в компиляторе? Их существуют сотни, в том числе коммерческие, а прибивать конкретный анализатор гвоздями, по меньшей мере, глупо.
Кстати если он вам так нравится вы можете использовать Clang Static Analyzer вместе с GCC, без проблем.
>>покажите пожалуста статический анализатор в gcc
> А зачем он именно в компиляторе? Их существуют сотни, в том числе
> коммерческие, а прибивать конкретный анализатор гвоздями, по меньшей мере, глупо.
> Кстати если он вам так нравится вы можете использовать Clang Static Analyzer
> вместе с GCC, без проблем.ясна. как только показываешь чего не хватает - так сразу начинаются вопли - "не нужно".
Слышали уже такое - плавали..А зачем мне нужно использовать Clang Static Analyzer - с gcc? когда можно без gcc обойтись.
> можно без gcc обойтись.Поняли уже все, поскольку cxx11 в llvm нет, ты выдвигаешь новую Супер-Теорию, которая-таки портвердит, что cxx11 там есть. 300 грамм пирамидона пациенту в треуголке!
анонимусы всё считают, что компиляторы дебилами делаются...> А зачем он именно в компиляторе?
например, для реализации механизма ARC (http://en.wikipedia.org/wiki/Automatic_Reference_Counting) при компиляции кода objective-c.
> покажите пожалуста статический анализатор в gccИх отдельных как грязи. А вот код отдельной тулзой фиг соптимизируешь.
> ну и почему-то именно llvm используют в X.org для компиляции шейдеров
> X.org
> шейдеровНет в X.org никаких шейдеров, вас жестоко обманули. Шейдеры — это к Mesa и Gallium3D.
>> ну и почему-то именно llvm используют в X.org для компиляции шейдеров
>> X.org
>> шейдеров
> Нет в X.org никаких шейдеров, вас жестоко обманули. Шейдеры — это к
> Mesa и Gallium3D.которые часть xorg в сумме. но не суть важно - gcc такого не умеет.
Кэп напоминает, что gcc вообще-то и не предназначен для того, чтобы компилировать шейдеры. Да и LLVM не умеет прорвы из того, что умеет gcc. Оптимизацию, например. И поддержку архитектур.
> Кэп напоминает, что gcc вообще-то и не предназначен для того, чтобы компилировать
> шейдеры. Да и LLVM не умеет прорвы из того, что умеет
> gcc. Оптимизацию, например. И поддержку архитектур.Ну да. отмазки у нас по средам.
А архитектуры - в случае llvm - пишутся очень легко. Только кэп напоминает что основными архитектурами является x86 (очень дофига рынка), arm, и умирающий power pc и mips. Остальные платформы скорее для гиков. А все эти платформы llvm умеет. Видимо ваш кэп потерялся в прошлом?
>А архитектуры - в случае llvm - пишутся очень легкоСклько десятков лет еще нужно, чтобы они легко написались на деле а не на словах?
> Пора ему уже обгонять GCC. Или еще 10 лет надо? Он же
> такой хороший прехороший, такой модульный премодульный, такой понятный для новичка. Когда
> рвать GCC то начнет не на словах?http://gcc.gnu.org/gcc-4.7/cxx0x_status.html
а теперь сравниваем с
>>- В LLVM-фронтэнде Clang обеспечена полноценная поддержка стандарта C++'11
>>так что gcc начинает уже отставать... не тот он уже.. не тот..
А теперь сравниваем:
http://clang.llvm.org/cxx_status.html
Generalized attributes N2761 No
Inheriting constructors N2540 No
Concurrency - 50%
и тд
> А теперь сравниваем:
> http://clang.llvm.org/cxx_status.htmlLast updated: $Date: 2012-10-22 19:32:41 -0500 (Mon, 22 Oct 2012) $
Ну и там ни слова про Clang 3.2. Страницу видимо не обновляли.
Новость кривая. Нет пока полноценной поддержки. Читай оригинал:
http://llvm.org/releases/3.2/tools/clang/docs/ReleaseNotes.html
Вообще-то по ссылки новости не полноценная поддержка а
>Clang 3.2 supports most of the language features added in the latest ISO C++ standard.Да и в направлении Generalized attributes у них месяц назад даже работа не велась, судя по llvm-dev, а работы там достаточно должно быть.
> Улучшена работа библиотек libc++ и compiler_rt, которые распространяются под двойной лицензией MIT и UIUC.Что гарантирует что программы не будут зависеть - захочет Столман добавить linking exception для gcc или решит что все собранное при помощи gcc обязано быть GNU GPL vX (как уже было с v3).
А все что напечатано в ms word принадлежит M$ )))
тссс ... накаркаешь
> тссс ... накаркаешьОчкуете, хомячки? Это вы после инстаграма так? :)
> Что гарантирует что программы не будут зависетьА зависимость от эппла куда делась? Вон тут видно уже что к чему - непропорционально много внимания всяким левым objc и яблочным процам. А если кто вздумает отскрестись от асфальта и пойдет конкурировать всерьез - быстренько окажется без компилера и улучшений в нем. Со стороны яппла довольно умно.
> А зависимость от эппла куда делась?а она там была? разрабатывают не сотрудники, права на код принадлежат не Apple - в чем зависимость то?
Вот в GCC есть зависимость на GNU - как чихнут в там - так в gcc и будет.
За что разработчик уже не раз gcc комитет критиковали.> Вон тут видно уже что к чему - непропорционально много внимания всяким левым objc и яблочным процам.
Что вам не устравает? это открытый код - значит делает что как может.
вы забыли что один из типов оптимизации в gcc (которую дарил google) работает только на x86 - вас не удивляет такое предпочтение перед MIPS? меня например возмущает такая дискриминация.> А если кто вздумает отскрестись от асфальта и пойдет конкурировать всерьез - быстренько окажется без компилера и улучшений в нем.
Да ну? а что открытый код куда-то денется? его прям так сразу закроют? Вы это в серьез? неее.. вам надо провериться... Боюсь случай запущенный - но излечимый.
> А если кто вздумает отскрестись от асфальта и пойдет конкурировать всерьез
> - быстренько окажется без компилера и улучшений в нем.Вы кстати это придумали посмотрев на RedHat - как только Oracle стал с ним конкурирвать и купил splice (которую они тоже хотели купить) - так сразу из ядра сделали блоб - в котором никто не может разобраться. За одно подгадили другим открытым проектам.. Слава RedHat ?!
> непропорционально много внимания всяким левым objcа вот Objective C не надо ругать, отличный язык. и практически, и как пример правильного привинчивания ООП к С. я, правда, не смотрел на ObjC 2 (или какой там сейчас), не в курсе, чего туда досыпали. но правильную концепцию испортить достаточно сложно.
> и яблочным процамВыдыхайте, с каких пор ARM имеет отношение к Apple?
С момента основания ARM Holdings эпплом?
> Что гарантирует что программы не будут зависеть - захочет Столман добавить linking
> exception для gcc или решит что все собранное при помощи gcc
> обязано быть GNU GPL vX (как уже было с v3).Вас совсем не смущает то, что ошибку исправили, как только заметили?
> Вас совсем не смущает то, что ошибку исправили, как только заметили?нет, конечно: с такой поправкой уже не получается кричать, что «FSF и rms хотят поработить весь мир!»
Че-то таблицу по статусу C++11 не обновили
http://clang.llvm.org/cxx_status.htmlИ до сих пор крашится на variadic template (одна из частей стандарта C++11)
template <typename, typename ...Ts>
int const (&make_zod())[sizeof...(Ts)+1] { return {42}; }int main(int argc, char *argv[])
{
make_zod<int>();
return 0;
}
Ну яблоку нафиг си++11 не упал. У них там objc. Ему и досталось.
Парсер не крахнулся, за генератор кода не скажу.
> Парсер не крахнулся, за генератор кода не скажу.В джире до сих пор issue не закрыт.
Url не помню, ищется по ключевому слову "C++11". Пишу с мобильного.
вреш ты все. никто не крашится - только не компилирует..bash-3.2$ clang++ -Wc++11-extensions 1.c++
1.c++:1:30: warning: variadic templates are a C++11 extension [-Wc++11-extensions]
template <typename, typename ...Ts>
^
1.c++:2:51: warning: generalized initializer lists are a C++11 extension [-Wc++11-extensions]
int const (&make_zod())[sizeof...(Ts)+1] { return {42}; }
^~~~
1.c++:2:51: error: reference to type 'const int [1]' cannot bind to an initializer list
int const (&make_zod())[sizeof...(Ts)+1] { return {42}; }
^~~~
1.c++:6:5: note: in instantiation of function template specialization 'make_zod<int, >' requested here
make_zod<int>();
^
2 warnings and 1 error generated.
> никто не крашится - только не компилирует..Неправильно выразился, проблема в том, что данный код с точки зрения C++11 корректный и должен компилироваться.
Блин, кто новость писал. В оригинале
Clang 3.2 supports _most_ of the language features added in the latest ISO C++ standard,C++ 2011.
Но никак не полноценная поддержка.
Следующие фичи были добавлены по сравнению с clang 3.1:
- Implemented the C++11 discarded value expression rules for volatile lvalues.
- Support for the C++11 enum forward declarations.
- Handling of C++11 attribute namespaces (automatically).
- Implemented C++11 [conv.prom]p4: an enumeration with a fixed underlying type has integral promotions to both its underlying type and to its underlying type's promoted type.
> - Implemented the C++11 discarded value expression rules for volatile lvalues.- просто пофиксили багу (правда сейчас редко кто использует volatile, но да ладно - пофиксили и молодцы)
> - Support for the C++11 enum forward declarations.уже есть в gcc (N2764)
> - Handling of C++11 attribute namespaces (automatically).n2761 в gcc уже было
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53528
> - Implemented C++11 [conv.prom]p4: an enumeration with a fixed underlying type has
> integral promotions to both its underlying type and to its underlying
> type's promoted type.Просто пофиксили багу, gcc этим не страдал
Отличная новость!Желаю проекту удачи и, наконец, взять под основное крыло дебаггер!
молодцы, хорошо идут. кто-нибудь проверял, как дела с армами? да, мне самому лень.p.s. имею в виду — «в сравнении с gcc».
GCC побеждает, да и к тому же за ним проект Linaro, одна из целей которого - улучшение работы GCC под армамиhttp://www.phoronix.com/scan.php?page=article&item=llvm_gcc_...
> GCC побеждаетэто старая версия кланга/ллвм. а мне интересно, много ли в новой улучшений. только из армов под рукой сейчас лишь N900, лень для него clang/llvm собирать, даже под скратчбоксом.
> GCC побеждает, да и к тому же за ним проект Linaro, одна
> из целей которого - улучшение работы GCC под армами
> http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_...сам себя не похвалишь - никто не похвалит ? :)
Интересно, насколько легко/понятно декомпилируется байт-код llvm?
Шесть дней назад LLVM/Clang 3.2 закоммичен в HEAD FreeBSD 10-CURRENT. Релиз FreeBSD 9.1 задерживается, видимо, из-за подготовки бэкпортирования LLVM/Clang 3.2 в 9-STABLE и последующей сборки релиза с новой версией компилятора.
LLVM/Clang 3.2 10 января 2013 года портированы на FreeBSD:
http://www.freshports.org/devel/llvm/
http://www.freshports.org/lang/clang/
14 января 2013 года в базовой системе FreeBSD 9.1-STABLE обновлён LLVM/Clang 3.1 до версии 3.2.
http://svnweb.freebsd.org/base?view=revision&sortby=date&rev...