После шести месяцев разработки представлен релиз проекта LLVM 16.0 - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы...Подробнее: https://www.opennet.me/opennews/art.shtml?num=58817
Спасибо! Классный проект, и используется как бэкэнд еще более классного проекта Rust.
>В бэкенде для архитектуры ARM прекращена поддержка целевых платформ Armv2, Armv2A, Armv3 и Armv3M.И сюда гномеры пробрались!
Ну заброcили устаревшие платформы. А гномеры то тут при чём?
У них там офигеть архитектура - вся кодогенерация в одной огроменной суперлибе. Без разбивки на компоненты. Ну либа и стала под сто метров весом. Нормальная такая либа. Только вот вот сдохнет под своим весом. Вот и приходится хоть немного жир выпускать.Зато, вот, "Не надо держать 100500 сборгк gcc." (c) предыдущий оратор. Задача просто станет нерешаемой вообще :)))
Мне самому не нравится, что для добавления бэкенда нужно пересобирать clang, а нельзя сделать динамическую библиотеку. Можно предположить, что если растащить всё по динамическим библиотекам, то это будет намного труднее сопровождать, ибо каждую экспортируемую функцию надо проанотировать соответствующими макросами, в результате работа сведётся к поиску непроанотированных функций, их анотации и устранению циклических зависимостей (винда их не терпит). И так после каждого изменения внутренней структуры, которая происходит довольно часто.
Меня просто размер этой либы начинает пугать. Особенно если посмотреть на то сколько архитектур GCC тулчейны поддерживают и их еще нету в ЭТОМ. "Кадавр жрал" (c).
Похоже, что они никогда и не поддерхивались, а то, что компилятор принимал их как аргумент - это ошибка: он всё равнотгенерил код для поздних версий. https://github.com/llvm/llvm-project/issues/57486Так что если кому нужно v2 и v3, то пусть пилят поддержку, скорее всего её с радостью примут.
Это не гномеры. Это новостедел так написал.
Вот что в оригинале:
"-march values for targeting armv2, armv2A, armv3 and armv3M have been removed. Their presence gave the impression that Clang can correctly generate code for them, which it cannot."Они просто убрали из параметров таргеты, которые и так не поддерживались.
Читайте дальше в списке изменений:
Support for targeting Armv2, Armv2A, Armv3 and Armv3M has been removed. LLVM did not, and was not ever likely to generate correct code for those architecture versions so their presence was misleading.
Вы процитировали изменения из clang, а теперь посмотрите изменения из списка для llvm.
Капец, как же всё сложно стало в этом мире. Слишком много переменных, сущностей...
Вообще да, бесит конечно, что всё так сложно. Но сабж как раз делает создание кроссплатформенного софта проще
"Компьютеры позволили делать ошибки намного быстрее и массовее!"
Вот в неолите помню офигенно было!
То ли дело 1000 лет назад - полжизни монотонный труд, полжизни в армии. А потом в 40 лет помер от инфекции для пущей лёгкости.
Вот то ли дело в 1960х: более двадцати разных архитектур с полузакрытой документацией...
>Разрешено применение некоторых математических символов в идентификаторах, таких как "₊" (, например "double xₖ₊₁")Зачем? Всё равно человек написавший так в коде будет уволен с позором, а изменения откачены назад.
Вот вы и ищете программистов, а на самом деле вы уже всех нормальных программистов выгнали и они к вам больше не идут.
Не можете найти соответствующее место в стандарте? Поэтому кого-то надо уволить? Ну так то да.
Жуткий монстр из ада.
Зато получше устаревшего жопаэльного gcc будет.
Гцц тоже тот ещё монстр, но всё же не такой чудовищный, как этот.
А в чем собственно чудовищность llvm?
Новые архитектуры и языки добавлять легко*, что фронт, что бек.
Поэтому всякие экспериментальные языки создаются как раз на его базе.*Легко по сравнению с гцц при наличии достаточной компетентности.
Вам не ответят - то был типичный "эксперт opennet"
вот злодей, что то там гонит на студенческую поделку залитую баблом аппле лишь бы не как в гцц
И как бы аппле перевела весь свой софт на M1 без это студенческой поделки?
При чем тут гонит-не гонит? Гнать можно по разным причинам: лицензия не та, гнутые огороженные экстеншены в ядре хуже оптимизирует, не поддерживает давно умершие маргинальные платформы, и т.д.
Но это все можно сформулировать и как-то обосновать.
А тут получается "огонь плохой!!11"
После перехода FreeBSD на clang пересборка мира и ядра стала занимать процентов на 30 больше времени. Наблюдается снижение производительности системы. И самое гадкое это то, что слишком часто стали проскакивать сегфолты, чего ранее на фряхе было встретить крайне сложно. Если собирать GCC, то таких проблем не наблюдается. Вот вам и хвалёный llvm.
Нет.1. Во времена 3.4 шланга всё собиралось как раз быстрее, он тогда был совсем маленький.
2. С прогретым ccache на 8 ядерном райзене полная пересборка и переустановка системы занимает примерно 5 минут. Те собирается и устанавливается мир, потом собирается и устанавливается ядро (с drm - amdgpu и доп дровами сетевух и прошивками для amdgpu), потом обновляются загрузчики.
С не прогретым - не более получаса.3. Снижение производительности - ходили какие то слухи во времена 3.4, но с тех пор прошло много лет, и шланг отрастил оптимизации.
В общем ждём пруфов на бенчах со сежей фрёй собраной свежим шлангом из базы и свежим гцц из портов.4. У меня фря на десктопе и на серверах, никаких сегфолтов я не замечал.
Все падения что я видел, при разборе коредампов указывали на проблемы конкретных приложений.
Попробуйте перейти на память с ECC и вообще проверьте железо.
Это повсеместная проблема, я её не с потолка взял.
Но ссылки на них я тебе конечно же не покажу
Зачем их показывать когда каждому человеку на Земле доступен поиск по интернету?
Те правоту высказывания анонима, с которым я не согласен я должен сам искать и подтверждать?
В интеллект не способен? Твои не согласия твои личные проблемы. Или ты себя пупом мира возомнил что тебе все должны?
И кому же из вас верить, интересно?
Никому нельзя верить! Даже себе!
А вот мне - можно
https://www.phoronix.com/review/freebsd11-clang-gccИ это только малая часть проблем.
Статья свежак, буквально на днях вышла
Неужели ты думаешь, что за несколько лет он вдруг воспарил к звёздам и научился обращать воду в вино?
Бедняга... Как там в крио-камере?
Хотя, все относительно, 2016й был не таким уж плохим годом.
А зачем вам 11 фря в 2023 году!?
Летом уже 14 будет, 11 давно не поддерживается.
Маки (собранные llvm) повсеместно тормозят и сегфолтятся?Вы вообще о проблемах llvm представления не имеете, только слышали и собственный опыт+неверные выводы.
Я вот могу вам привести свои тикеты с проблемами llvm, оно уже всё решено.
У шланга проблемы с кодогенерацией. Но местами получше msvc, тем и живёт. Зачем корпам завязка на шланг я вижу, но зачем свободным людям отказываться от более качественного и эффективного гцц я не понимаю. Я, если что, лично профилировал получаемый код, и gcc+pgo победитель по всем параметрам.
Да, тормозят и сегфолтятятся. Куча багов в UI, файловой системе и драйверах. Оверпрайснутый шлак, который покупают по привычке, ведь раньше это были действительно неплохие компьютеры.
Каким образом тебе удалось собрать современную FreeBSD с помощью GCC? Расскажи, а.
Вроде поддержку не дропнули, хотя я не пробовал.
Раньше в /etc/make.conf надо было задать CC, CCX и вроде оно собирало любым указанным компилятором.
Обычно этим пользовались чтобы использовать шланг по свежее из портов, но думаю некоторые, как войд, могли туда гцц прописать.
Пробовал указывать в /etc/nake.conf:CC=/usr/local/bin/gcc12
CXX=/usr/local/bin/c++12
CPP=/usr/local/bin/cpp12Сборка базовой системы FreeBSD 13-STABLE обрывается по ошибке в исходнике:
% cd /usr/src/ && make cleandir buildworld
...
/usr/local/bin/gcc12 -c -O2 -pipe -frename-registers -fno-strict-aliasing -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.genoffset.o -MTgenoffset.o -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=address -Wno-error=aggressive-loop-optimizations -Wno-error=array-bounds -Wno-error=attributes -Wno-error=cast-qual -Wno-error=enum-compare -Wno-error=maybe-uninitialized -Wno-error=misleading-indentation -Wno-error=nonnull-compare -Wno-error=overflow -Wno-error=sequence-point -Wno-error=shift-overflow -Wno-error=tautological-compare -Wno-unused-but-set-variable -Wno-error=stringop-overflow -Wno-error=memset-elt-size -Wno-error=packed-not-aligned -Wno-address-of-packed-member -Wno-error=alloca-larger-than= -Wno-return-type -Wno-format-zero-length -fms-extensions -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fms-extensions -std=iso9899:1999 -fcommon /usr/src/sys/kern/genoffset.c
gcc12: error: unrecognized command-line option '-fformat-extensions'; did you mean '-fno-ms-extensions'?
*** Error code 1Stop.
А сборка ядра вообще невозможна:% cd /usr/src/ && make cleandir buildkernel
...
/usr/local/bin/gcc12 -c -O2 -pipe -frename-registers -fno-strict-aliasing -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.genoffset.o -MTgenoffset.o -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include -fdebug-prefix-map=./x86=/usr/src/sys/x86/include -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error=address -Wno-error=aggressive-loop-optimizations -Wno-error=array-bounds -Wno-error=attributes -Wno-error=cast-qual -Wno-error=enum-compare -Wno-error=maybe-uninitialized -Wno-error=misleading-indentation -Wno-error=nonnull-compare -Wno-error=overflow -Wno-error=sequence-point -Wno-error=shift-overflow -Wno-error=tautological-compare -Wno-unused-but-set-variable -Wno-error=stringop-overflow -Wno-error=memset-elt-size -Wno-error=packed-not-aligned -Wno-address-of-packed-member -Wno-error=alloca-larger-than= -Wno-return-type -Wno-format-zero-length -fms-extensions -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fms-extensions -std=iso9899:1999 -fcommon /usr/src/sys/kern/genoffset.c
gcc12: error: unrecognized command-line option '-fformat-extensions'; did you mean '-fno-ms-extensions'?
*** Error code 1Stop.
Кто тебе сказал, что я собирал последнюю версию. То была 10 или 11, точно не помню.
А давайте сразу 6.2 собирать! Заодно в 2007 вернемся!
Не с тобой разговариваю, чернь.
Мне бы для Windows XP. Такая сборка будет или мне дальше страдать, используя GCC^W MS Visual Studio?
Собери сам. clang поддерживает таргеттинг XP, нужно только флаги нужные задать. MonGW-w64 прекрасно работает на XP. Только есть проблема. XP был дропнут разрабами pthreads. Им, видите-ли не хочется runtime dispatch делать, а новое API - 1 (ОДНУ, Карл) функцию от Висты - использовать хочется. В любом случае можно попробовать поставить One Core API, которое эту функцию реализует.
При больом желании можно задействовать старую версию pthreads.
> При больом желанииМожно и как "больНом" интерпретировать
Можно не ставить весь One Core API (поскольку это так-себе удовольствие, очень уж в нём пока косяков много). Достаточно выдрать оттуда нужную DLL и подсунуть её тому бинарнику, который её хочет (если нужно, то поменять таблицу импорта). А ещё можно написать тупенький враппер, который пробрасывает все вызовы в оригинальную DLL, кроме одной функции, код которой дёрнуть из Wine.
Официально заявляю, никаких сборок для Windows XP мы больше никогда не будем делать. Спасибо за проявленный интерес.
,- раздался пронзительный с известной стороны.
Может пора подумать о будущем?
Как вы через 10 лет видите свою жизнь?)
>Как вы через 10 лет видите свою жизнь?Выкатывают open window — клон хп/семерки и все взявшись за руки переходят на него.
Замечу что ос это монолитное АПИ с гарантиями совместимости и безопасности. По такому критерю многие дистрибутивы линуха не являются полноценными ОС — у них нет своего апи поверх которого можно писать пригладные приложения. Есть интерфейс ядра, интерфейсы конкретных системных приложний работающих в нем(вроде тех же иксов), а прикладному софту приходится играть в угадайку с чем он может взаимоестовать и через какие костыли. Именно поэтому конпеляция не останавливается никогда, а в нормальных ОС приложения скомпилированые один раз просто работают годами.
Выйди реально что-то на уровня open win линухи потеряют и те 2% десктопа что имеют.
Смотря что считать стабильным API.
На уровне ядря и стандартных либ - у меня на фре всё стабильно.
Но ABI меняется, и я не вижу в этом проблемы, пока у меня опенсорсный софт который я сам собираю.Пока вы там молитесь чтобы ваши дряхлые бинарники запускались, я могу пересобрать всё свежим компилятором под свежее окружение.
В общем вы путаете подходы, качать готовые бинари с неизвестных локаций - это такое себе приемущество.
>я сам собираюМолодец, чо. Только не у всех есть время, желание и компетенция это делать. Им проще готовые бинарники давать, и чем дольше и стабильнее работают старые версии, тем меньше головной боли у разработчика и опционально админа.
В мире линухов не считается добродетелью экономить чужие мозговые ресурсы. Это не злой умысел, а простое отсутвие стабильного АПИ ОС помноженное на культуру полного контроля компьютера(казалось бы причем тут @на-льники?). Итог закономерен - 2% пользователей или 3-сигма в матстате, ибо очень необычным кадрам такое нравится.
Чем дольше гнилые бинарники совместимы - тем больше не решённых проблем под капотом и тем дороже это поддерживать.Вы возможно не застали переход с 9х венды на 2к/хр, а я застал, и помню как приходилось некоторые бинарники патчить для совместимости.
А уж какие эпичные легенты про Ченга ходят и то как он костылял bug-to-bug совместимость под каждое отдельное приложение вы наверняка тоже не знаете.
Ну и там всякие утилиты которые в реестр позволяет записать для каждого приложения какие и как баги эмулировать - это дальнейшее развитие темы.И отдельно, отладка приложений без исходников - это возня с file/reg/procmon и дебагером, что требует на порядки больше и времени квалификации чем читать и компелять из исходников.
Всё вместе это приводит к:
- бинарник ты наверное можешь перетащить, но рано или поздно он перестаёт работать на свежей ОС
- куча костылей которые нужно поддерживать ради совместимости
- отладка дебагером или всякими низкоуровневыми штуками, за долго и дорого, с патчингом на асме (тут я рекомендую почитать историю про нид фор спид 3 и как его энтузиаст патчил, и то это было возможно потому что в 98 году компилятор был без оптимизаций и асмовый код читается как сишный почти что)
Что до % - мне как то всё равно.
Отмечу только что лет 20 назад в инете были в основном обеспеченные, образованные и целеустремлённые люди, это потом туда пришли остальные 99,9% баласта.
Ещё маенький нюанс: то WinAPI которое вам так нравится, оно принадлежит МС и с этим ничего не поделать. Они в любой момент могут начать регулировать его реализации на законных основаниях.
Как принадлежит, так и распренадлежит))). Делов то.)))
Зачем им распренадлежать? Майки могут просто сделать правильный линукс как ОС. CBL-Mariner уже неплохой заход, только какбэ чуть с другой стороны, но направление верное.
Не могут.
Нормальный - это принадлежащий коммунити, что противоречит их традиционным моделям заработка.
Вообще, вон на абажуре они забили на идею впаривать его как рантайм для дотнет-онли. А потом забили и на идею продавать там только винду. И теперь более 70% виртуалок на нем - линух. Видимо ну вот не нравится народу винду ремотно менеджить и гонять в автопилоте. Боль это пониже спины, как ни крути.Наверное они и на остальное могут прогнуться. Даже на замену виндов на линукс, если так выгодней окажется. Ну вон абажур - сервисами барыжит, а не софтом в привычном понимании. И после того как они разрешили там произвольные оси вообще и линух в частности, бизнес пошел сильно бодрей. До этого момента абажур вообще не был даже намеком на конкурента другим крупным игрокам.
Вообще даже GPL сам по себе не особо мешает деньги зарабатывать. А идея продавать вот именно копии, вот именно байтиков - очень уж неестественно смотрится сейчас.
Попытатся что то отнять у богатой корпорации из америки - нуну.
Сказочник. МС обратную совместимость уже 30+ лет тянут.
С трудом им удается выкинуть лохматый код, чтобы юзвери не ныли.
В этих хтонических стандартах только ИИ разберётся теперь.
Да, навыдумывали всякой нечеловеческой х.е.р.н.и. Для себя, для разработчиков языка и стандартной либы. А на прикладных программистов поклали большой болт.
Ну конечно надо без стандарта положить болт как в расте.
Раст - дрянь, но C++ стандарт - дырявая дрянь с кучей undefined behaviour.
Растохейтеры: синтаксис раста сложный, то ли дело С++!В это время С++:
X(X const&) requires C<T> = default;
constexpr auto __sb = std::tuple<int>(1);
auto g() -> S<T*>::Ptr;
using P = bool(*)(int, int);
int x = a\N{abc});
Да они оба монстры.
Ну во-первых у тебя приведены не полные примеры, некоторые из них синтаксически не корректны.
Во-вторых, тут вполне нормальный синтаксис.Вот какое-нибудь ([](){})();, что является абсолютно корректным кодом на C++, это да. А у тебя всё вполне понятно.
> тут вполне нормальный синтаксисДля разработчика на С++ - да.
Но и раст, так-то, читается как с листа для тех, кто на него хотя бы две недели потратил )
Теорема Эскобара.
Зачем менять шило на мыло?
Раст хейтят как раз за то, что они очередное C++, но своё изобрели.