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.

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

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

Сколько помню, он всегда это умел (когда-то может и не умел, но, видимо, давно).

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

То есть autotools умеет не гадить(в том числе не плодить свои «конфиги») в директории с исходниками? :)

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

Умеет. Хотя, о каких именно конфигах идёт речь, я не понял. Если о configure, то это часть исходников, которая их собирает и не должна быть отдельно.

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

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

не нужно.

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

Исходные файлы обычно в src.

> ls
src include doc build
> cd build
> ../configure
> make

В отличии от CMake, это покажет инфо как настроить сборку(какие либы включить, какие выключить, другое) для своего проекта:

> ./configure --help
tp_for_my_bunghole ()
Последнее исправление: tp_for_my_bunghole (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

да хоть на суахили или функционально-эльфийском. твои поделки все равно никто, кроме тебя, не собирает. потому и проблем нет

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

В отличии от CMake, это покажет инфо как настроить сборку(какие либы включить, какие выключить, другое) для своего проекта:

для cmake есть ccmake, который не только покажет, но и поможет переключить. это не главное

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

Зачем ты агришься на просто толстенного тролля? У него уже был почти провал. Никто целый день на него не реагировал, а ты пришёл и покормил.

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

для cmake есть ccmake, который не только покажет, но и поможет переключить. это не главное

Или cmake-qt-gui, уже третья утилита.

Даже у cmake зависимостей много. ldd /usr/bin/cmake.

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

Грубо говоря, если я скачаю исходники программы (programsrc). Могу ли я сделать?

$ mkdir build
$ path_to/programsrc/autogen.sh
$ make
И в директории path_to/programsrc после этого останется в нетронутом состоянии? :)

И да, бонусный вопрос: Как правильно собирать автотулс проект? :)
- autogen.sh?
- configure?
- auto*...

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

Даже у cmake зависимостей много. ldd /usr/bin/cmake.

Шел 2016й год, диски были размерами несколько терабайт, а ретрограды продолжали считать мегабайты.

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

С autogen.sh не думаю (да и autoreconf есть давно), там должен лежать configure и с ним так сделать можно. В этом принципиальное отличие от cmake и подобных, что система сборки не нужна в месте назначения и нет проблем с её версией. В установочном пакете, который должен делаться `make dist`, всегда будет configure и out-of-tree билд не проблема.

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

Если Вы не разработчик Clang, то какая разница в данном случае?

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

Да выучи наконец макросы и модули в CMake.

Поверь, выучил. Написал, и не один (модуль). Я неплохо разбираюсь в CMake, не надо меня посылать на RTFM.

Так-то и в плюсах можно городить проект в одном файле, но нахрена?

CMakeLists.txt начинают

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

С autogen.sh не думаю (да и autoreconf есть давно), там должен лежать configure и с ним так сделать можно.

Целый зоопарк из скриптов в одной системе сборки и каждый делает всё по-своему.

В этом принципиальное отличие от cmake и подобных, что система сборки не нужна в месте назначения

Какая разница какой пакет ставить? Кроме того m4 нужен.

и нет проблем с её версией.

autoconf-2.13, autoconf-2.69 или какие там версии были...

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

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

Да это на любом крупном проекте заметно

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

Шел 2016й год, диски были размерами несколько терабайт, а ретрограды продолжали считать мегабайты.

А ты не считай мегабайты.

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

Один фиг GCC на многие порядки мощнее, чем Clang. Clang просто не может побить GCC исключительно из-за своей архитектуры.

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

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

И работает в итоге медленнее. Ню-ню.

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

alexferman> а теперь, когда clang начал парировать gcc по производительности генерируемого кода

Ага. На парочке бенчмарков, которые оптимизированы под шланг. Та же история, как с Julia vs R. Шланг by design не может обеспечить тот же уровень возможностей и такую же высокую производительность как GCC.

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

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

Это ты больной.

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

Где ж ты там костыли углядел? Если нужны исконно сборочная система, можешь хоть waf использовать, хоть scons, хоть ещё что.

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

tp_for_my_bunghole> Для современной ОС нужен простой системный язык с модульностью, ООП и быстрой компиляцией.

Для современной ОС не нужен язык с ООП. Факт.

tp_for_my_bunghole> Язык не требующий больших изменений из-за недостатков обратной совместимости, который был во многом продуман изначально. Это только Free Pascal.

Может тогда Oberon припомнить? Можо ещё Limbo вспомнить, если на то пошло. Для описанных тобой целей тот же Limbo лучше, чем Free Pascal.

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

kirk_johnson> А чем лучше автолулзов? :)

Поцерингофилищам всегда лучше отсутствие универсальности, комбайновость и переусложнённость. Потому systemd и появился и так много у Поцеринга подсосов.

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

bbk123> И тебя тоже уже не вылечат. Как жаль.

Глаза разуй, если у тебя они вообще есть.

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

Clang просто не может побить GCC исключительно из-за своей архитектуры.

Хотелось бы увидеть обоснование этого утверждения.

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

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

Уж лучше Java-программы на десктопе, чем ссанина на дотнете и сисярпе.

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

invy> В 95-м году было пол дюжины разных юниксов?

В то время их было даже больше, чем пол дюжины. SunOS (позже - Solaris), HP-UX, Tru64 (он же Digital Unix), Xenix, AIX, IRIX, SCO UNIX, ... И это только крупные коммерческие. Были и поменьше, и некоммерческие, и даже GNU/Linux тогда уже был с X Window System.

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

invy> Шел 2016й год, диски были размерами несколько терабайт, а ретрограды продолжали считать мегабайты.

Ты долбанулся? Сейчас до сих пор вовсю в ходу «диски» в 4-512 килобайт. И то, что кто-то идёт на систему с хардом на десяток-другой терабайт, не значит, что этот кто-то может себе позволить как попало транжирить драгоценные вычислительные ресурсы и делать hello world с минимальными требованиями в виде 5GHz процессора, 32Gb RAM, 1Tb HDD и 4k-дисплея 120 Гц. Пошёл ты нахрен.

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

DELIRIUM> Хотелось бы увидеть обоснование этого утверждения.

Clang не может компилировать код отличный от C и C++. Clang не умеет дофига аппаратных архитектур и никогда уметь не будет. Clang - очень сомнительный инструмент для embedded.

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

Может тогда Oberon припомнить? Можо ещё Limbo вспомнить, если на то пошло. Для описанных тобой целей тот же Limbo лучше, чем Free Pascal.

Limbo это чушь. FPC лучше чем Oberon.

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

tp_for_my_bunghole> Limbo это чушь.

Тогда Free Pascal чушь по сравнению с Visual Basic 6.0

tp_for_my_bunghole> FPC лучше чем Oberon.

Э... Компилятор сравниваешь с языком?

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

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

по ссылке то ходил? или ты Ъ? есть что по теме, без перехода на личности сказать?

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

Один фиг GCC на многие порядки мощнее, чем Clang. Clang просто не может побить GCC исключительно из-за своей архитектуры.

Обоснуёшь?

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

Clang не может компилировать код отличный от C и C++

А g++ не умеет компилировать код отличный от C++. А gcj не умеет компилировать код отличный от Java. Ты о чем вообще? clang это фронтенд для llvm, для языков C и C++. Он только парсит исходный код, всю работу делает llvm. Для llvm уже сделали больше языков чем для gcc, начиная от академических поделок, заканчивая растом.

Шланг by design не может обеспечить тот же уровень возможностей и такую же высокую производительность как GCC

Есть такая embedded архитектура, называется MSP430, так вот llvm на ней быстрее gcc в полтора раза. И даже чуть быстрее чем IAR. В багтрекере gcc этот баг висит уже больше двух лет и никто не собирается его фиксить.

Clang не умеет дофига аппаратных архитектур и никогда уметь не будет.

Старья всякого конечно не будет, а свежее уже появляется быстрее чем в gcc, потому что написать бэкенд для llvm проще. В llvm уже есть пара тройка таргетов которых нет в gcc.

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

Clang не может компилировать код отличный от C и C++

С таким уровнем знаний и аргументации - иди лучше борщ вари. Clang он сравнивает с GNU Compiler Collection, LOL

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

Ну и к слову, Clang - это еще Objective C и Objective C++, если что.

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

Целый зоопарк из скриптов в одной системе сборки и каждый делает всё по-своему.

Нету такого. autogen.sh это раньше было, давно есть autoreconf на замену, но по инерции используется первое иногда (сейчас оно часто просто дёргает autoreconf или выводит сообщение, что его надо использовать).

каждый делает всё по-своему.

Вот это на cmake больше похоже, где намного меньше стандартизации в файлах.

Какая разница какой пакет ставить? Кроме того m4 нужен.

Ну хватит уже фантазировать, а? Не нужен m4, так как наряду с configure будут и in-файлы. m4 преобразует configure.ac -> configure и Makefile.am -> Makefile.in.

autoconf-2.13, autoconf-2.69 или какие там версии были...

И? Системная версия роли не играет. Каждый набор исходников самодостаточный и хоть 100 разных версий в разных пакетах будут себе работать абсолютно независимо. А если оно пробует переконфигурировать себя, то это бок сборки пакета, там timestamps поехали скорее всего из-за системы контроля версий, так как собирали каким-нибудь `git export` или `tar` вместо `make dist`.

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

В багтрекере gcc этот баг висит уже больше двух лет и никто не собирается его фиксить.

Ну это совсем не аргумент. В багтрекере всех больших проектов куча баг репортов. В том же llvm открыл наугад и легко нашёл баги с адекватным описанием без единого ответа, которые там ещё с 2008-2012.

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

Круто, чо. А в AVR/STM-8 он тоже умеет ?

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

Хотелось бы увидеть обоснование этого утверждения.

Он, конечно, мусор написал. Но если знать детали, то он прав.

Основная проблема, что для нормальных сообщений об ошибках и некотрых методов оптимизации архитектура разделения на уровни плохо подходит. gcc именно из за необходимости использования хаков выбрал свою архитектуру. Создатели llvm больше затачивались на понимания и легкость. Поэтому единственной проблемой gcc вляется накапливающаяся сложность. А проблема llvm - невозможность достичь уровня gcc.

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

для нормальных сообщений об ошибках и некотрых методов оптимизации архитектура разделения на уровни плохо подходит. gcc именно из за необходимости использования хаков выбрал свою архитектуру

А что, gcc не разделен на уровни? Frontend, middle-end, backend - не уровни?

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

Сейчас до сих пор вовсю в ходу «диски» в 4-512 килобайт. Я тебя разочарую. configure от автотулза туда не влезет.

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