LINUX.ORG.RU

Вышел LLVM/Clang 3.9

 ,


3

7

Что нового в LLVM:

  • разработчики отказались от поддержки autoconf в пользу CMake;
  • добавлена совместимость с ABI для GCC версии 5 и выше;
  • добавлен анализатор MemorySSA, который работает быстрее и точнее, чем MemoryDependenceAnalysis.
  • добавлена поддержка ThinLTO через ключ -flto=thin — по сравнению с обычным LTO кодогенерация намного быстрее, а итоговый код производительнее;
  • теперь возможно использование ключа -march=skylake-avx512, активирующего поддержку соответствующих процессоров Intel.
  • теперь присутствует полноценная поддержка ARM-архитектур Qualcomm's Kryo и Broadcom's Vulcan, начальная поддержка Cortex-R8 и ARMv8.2-A.
  • для бэкенда AMDGPU реализованы шейдеры OpenGL, буферы, атомарные счётчики, шейдерные расширения.

Что нового в Clang:

  • все возможности OpenCL 2.0 полностью реализованы;
  • полностью реализован ОpenMP 4.5 для CPU, ведётся работа над GPU-частью;
  • начато внедрение возможностей стандарта C++1z, которые активируются ключом -std=c++1z;
  • есть многочисленные изменения для ARM, MIPS и PowerPC.

>>> Подробности

Сборку с multilib в gentoo исправили? Или оно так же ругается, что выбранный процессор не умеет 64 бита?

mittorn ★★★★★ ()

Только вчера 3.8.1 собрал. :/

imul ★★★★★ ()

Вышел, да не весь. Пакаджей еще нет. Как грицца, «ждем ебилдов» ...

gns ★★★★ ()

Кстати, посмотрел я тут недавние тесты gcc vs clang на форониксе: http://www.phoronix.com/scan.php?page=article&item=freebsd11-clang-gcc&am...

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

alexferman ★★ ()
Ответ на: комментарий от alexferman

Так никто не мешает что clang, что gcc на этапе разработки запускать с -O0. А для быстрой сборки релизов можно и distcc использовать.

Deleted ()
Ответ на: комментарий от Deleted

Так никто не мешает что clang, что gcc на этапе разработки запускать с -O0. А для быстрой сборки релизов можно и distcc использовать.

Именно, более того - с включенной оптимизацией clang и раньше не особо быстрее gcc был.

anonymous ()

начато внедрение возможностей стандарта C++1z, которые активируются ключом -std=c++1z;

std::string_view.

Nested namespace definition

Folding expressions

A file system library based on boost::filesystem

Я знал что дождусь.

vertexua ★★★☆☆ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от Deleted

Просто это был их selling point, которым всех задалбывали длительное время этими же сравнениями, а теперь вот умолкли. Это то и забавно.

xaizek ★★★★★ ()
Ответ на: комментарий от anonymous

Не скажите. На gentoo с -O2 у меня Firefox компилировался цлангом в 2 раза быстрее, чем гэцацой.

alexferman ★★ ()

начато внедрение возможностей стандарта C++1z, которые активируются ключом -std=c++1z

Спасибо, я кончил.

Скажите кстате что там с Apple? В Xcode когда появится?

PS: а то всё gcc использую...

fornlr ★★★★★ ()
Последнее исправление: fornlr (всего исправлений: 1)

Даже не знаю, от чего блевать хочется больше — от автолулзов или от СMake.

kirk_johnson ★☆ ()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

От последнего. Хотя бы потому, что его авторы видели autotools и могли сделать лучше, а сделали CMake. У первого в качестве оправдания то, что он переиспользует код m4, у второго адекватных оправданий нет (я знаю, что они хотели сделать нечто близкое к autotools, но могли бы и не брать адский синтаксис).

xaizek ★★★★★ ()
Последнее исправление: xaizek (всего исправлений: 1)

Это не нужно, есть 8cc, на крайний случай tcc.

slon ()
Ответ на: комментарий от RazrFalcon

Казалось бы, причём тут система сборки?

Она фигурирует в новости. Прочитай ещё раз.

kirk_johnson ★☆ ()
Ответ на: комментарий от xaizek

в качестве оправдания то, что он переиспользует код m4

А что в этом плохого?
Я не девелопер, когда-то autotools постоянно бесил тем, что каждая свежая софтина требовала более свежего autotools. Который требовал более свежего... и т.д.

Shadow ★★★★★ ()
Ответ на: комментарий от bbk123

Больной человек. Мне его жаль.

Когда на тебя электронный ошейник с намордником накинут, вспомни эти слова, дебил.

anonymous ()
Ответ на: комментарий от Shadow

в качестве оправдания то, что он переиспользует код m4

А что в этом плохого?

В переиспользовании? Ничего. Я к тому, что там правила экранирования и разделения аргументов сложные, но тому есть вполне понятные причины, а подражателям не следовало копировать эти элементы, которые в autotools вынужденные.

Я не девелопер, когда-то autotools постоянно бесил тем, что каждая свежая софтина требовала более свежего autotools. Который требовал более свежего... и т.д.

Сборка проекта на autotools не должна ничего требовать, в этом его прелесть. Если оно требовало для пересоздания каких-то файлов, то значит софт паковали неправильно (правильно это `make dist` или `make distcheck`). В таких случаях достаточно сделать несколько вызовов touch и всё соберётся без проблем.

xaizek ★★★★★ ()
Последнее исправление: xaizek (всего исправлений: 1)

разработчики отказались от поддержки autoconf в пользу CMake

Везде бы так. CMake божественен!

slovazap ★★★★★ ()
Ответ на: комментарий от kirk_johnson

Даже не знаю, от чего блевать хочется больше — от автолулзов или от СMake.

От CMake, естественно. Автотулзы хотя бы делали грамотные люди.

tailgunner ★★★★★ ()

Это что, можно наконец скомпилировать жыэс в жыэс чтобы быдло- и интересный код скрыть?

TooPar ()

CMake

Годно, нужно, прекрасно.

ThinLTO

same

гцц, RMS, швабодка

*пожимаю плечами*

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)

Да ну их в задницу. Писал бэкенд, все собиралось. Последний коммит в мае. Вчера попробовал пересобрать. Они поменяли половину api, ошибки в каждом файле. Юмористы блин.

upcFrost ★★★★★ ()

разработчики отказались от поддержки autoconf в пользу CMake;

фу, закопайте, больше не нужно

Harald ★★★★★ ()
Ответ на: комментарий от Harald

разработчики отказались от поддержки autoconf в пользу CMake;

фу, закопайте, больше не нужно

Тебе то какая разница?

anonymous ()
Ответ на: комментарий от tailgunner

Грамотные люди столько костылей не нагородят :)

invy ★★★★★ ()
Ответ на: комментарий от invy

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

tailgunner ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

tp_for_my_bunghole ()
Ответ на: комментарий от upcFrost

Да ну их в задницу. Писал бэкенд, все собиралось. Последний коммит в мае. Вчера попробовал пересобрать.

Писал на unreleased версии? Или попробовал перейти со старого релиза на новый?

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 2)

Сейчас C++ и Pascal как бы поменялись местами, по сравнению с ситуацией 80-х и начала 90-х.

Free Pascal проигрывает C++ только отсутствием специфических оптимизированных либ которые используют в бенчмарках производительности.

Для современной ОС нужен простой системный язык с модульностью, ООП и быстрой компиляцией. Язык для которого можно создавать хорошие IDE просто на основе парсера(в C typedef не позволяет), которые были бы на уровне Java IDE. Язык не требующий больших изменений из-за недостатков обратной совместимости, который был во многом продуман изначально. Это только Free Pascal.

tp_for_my_bunghole ()
Ответ на: комментарий от bbk123

Больной человек. Мне его жаль.

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

А зачем эти книги? Есть же wikipedia и stackoverflow с githu... aaaa, вот оно что...

tp_for_my_bunghole ()

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

pftBest ★★★★ ()
Ответ на: комментарий от kirk_johnson

Как минимум тем, что может в кросс-платформу без UNIX-овых костылей.

Хотя CMake та ещё неочевидная параша. А регистронезависимость ихнего DSL это вообще из винды что ли пришло?

EXL ★★★★★ ()
Ответ на: комментарий от tailgunner

попытался переползти с 3.8.1 (вроде, или 3.8.0) на нынешний 3.9. И сразу половина кода поплыла. Где-то теперь void вместо boolean, где-то нужно передавать указатель вместо объекта и наоборот, где-то инклюд перевесили в другую директорию и класс переименовали...

не, все фигня конечно, но это хрен в каждом чертовом файле по 20 раз.

upcFrost ★★★★★ ()
Ответ на: комментарий от tailgunner

У условиях военного времени под пулями?...

invy ★★★★★ ()
Ответ на: комментарий от kirk_johnson

Когда-нибудь пробовал компилять автотулзный проект под вендой? :)

И вообще cmake - ынтырпрайзненько :)

invy ★★★★★ ()
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от pftBest

сырые патчи не проходят

Сижу и ржу, вспоминая как я им прислал патч, исправляющий программную реализацию работы с плавающей точкой, а они его ещё и принимать не хотели. Тот код, что у них был, был «заверен» несколькими людьми и «протестирован», и при этом на половине входных данных выдавал мусор. Автор того участка даже не понимал, как работает двоично-дополнительный код, и делал отрицательное число положительным сбросом старшего бита. И такого там хватает, так что не надо покупаться на рекламный бред, который они несут.

xaizek ★★★★★ ()
Последнее исправление: xaizek (всего исправлений: 1)
Ответ на: комментарий от invy

ынтырпрайзненько

Ага. Как Java-программы на десктопе.

EXL ★★★★★ ()
Ответ на: комментарий от invy

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

Deleted ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.