После шести месяцев разработки представлен релиз проекта LLVM 21.1.0, развивающего инструментарий (компиляторы, оптимизаторы и генераторы кода), компилирующий программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован в машинный код для заданной целевой платформы или использован JIT-компилятором для формирования машинных инструкций непосредственно во время выполнения программы. На базе технологий LLVM проектом развивается компилятор Clang, поддерживающий языки программирования C, C++ и Objective-C. Начиная с ветки 18.x проект перешёл на новую схему формирования номеров версий, в соответствии с которой нулевой выпуск ("N.0") используется в процессе разработки, а первая стабильная версия снабжается номером "N.1"...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63783
> (void)(void)1;Кто, где и зачем так пишут?🤔😶🌫️
> Устранено неопределённое поведение при (void)(void)1;Кто и зачем так пишут стандарты, что шаг вправо-влево приводит к UB?
>КтоТебе ФИО нужно?
>зачемНу потому что эти люди живут в реальности, где UB - это проблема программиста. Но с тех пор много воды утекло и мир живет в реальности, где UB - это проблема языка.
UB это проблемы созданные компиляторами, т. к. не смотря на явное указание архитектуры и процессора они ведут себя неадекватно, ссылаясь - в стандарте не описано поведение, но в стандарте все не описано т. к. нельзя охватить поведение для всех возможных текущих и будущих архитектур. потому и получается, что сдвиг 64 битного числа вправо на константу 32 на 64 битной машине с 64 битными регистрами приводит в компиляторе к UB, потому этот сдвиг при оптимизации О3 выкидывается.
выкинуть меньшее из зол, часть компиляторов просто обнуляют значение, т. к. приводят оба операнда к 32 битам
не знаю выводят ли компиляторы сейчас предупреждение при компиляции с O3, что выкинули или доработали пользуясь UB, раньше таких сообщений не было.
Не очень понял в этом примере логику компилятора, почему он выкидывает эту операцию?
На первый взгляд звучит как очевидный баг оптимизации
> потому и получается, что сдвиг 64 битного числа вправо на константу 32 на 64 битной машине с 64 битными регистрами приводит в компиляторе к UB, потому этот сдвиг при оптимизации О3 выкидывается.я хочу подробности с кодом. или имеется ввиду знаковый сдвиг вправо? он кстати implemented defined (должно быть описано в реализации).
> (void)(void)1;А что это значит? Я не могу распарсить это выражение.
В новости же сказано, что компилятор тоже не понимает для чего это, поэтому неопределённое поведение.
Это не так работает. UB - это "слишком сложно, непонятно что делать, нужны доп. сведения". А то что в новости - это "хз че это, Васян, фиг разберешься, давай напишем что UB, фиг кто разберется".
Это же Си, могу предположить, что каким-то чудом может через макросы получиться такая конструкция.
А ты уже погуглил? В github/gitlab поискал примеры? У ИИ спросил?
А вообще, замечательная новость, мы рады, что C/C++ не стоят на месте. 🥰😘🤗
Чему радоваться? Вот если бы это в нашей стране делали компиляторы и языки, то можно было порадоваться
Так делают, 1С, Глагол, ДРАКОН вот только зачем они нужны остальному миру?
> ДРАКОН
> зачем они нужны остальному миру?Медики, экономисты и бизнесу он нужен, они его юзают. Неплохой язык для не программистов.
https://link.springer.com/article/10.1007/s10209-022-00934-3
Так вот же, делают: https://gitflic.ru/project/alekseinedoria/trivil-0 😉
Да, спасибо, интересный проект. Надо всем поизучать
Печально, что до сил пор пишут С и С++ вместе. Это разные языки и сходятся они чисто ситуативно.
> auto [x, y, ...rest] = f();Новые сишные фичи настолько "разделяют" Си и плюсЫ, что оно уже даже на жс весьма похоже( даже типизации не требуется или, привет, "auto". Ещё немного - и додумаются до констант и изменяемых переменных )
Например:
// Объявляем "на коленке" ту самую функцию, что что-то возвращает
let f = () => [ 1, 2, 3, 5, "ololo" ]
// Собсно, "В x будет записан первый элемент, в y - второй,
// а в rest - третий( весь остаток, но можно и конкретно третий )
// Только в жс это называется "деструктуризация" "const [x, y, ...rest] = f();
// x = 1, y = 2, rest = [ 3, 5, "ololo" ]
В Clang 8 внедрили часть стандарта C++ касающуюся модулей. С тех пор уже 13 релизов никак не доделали эту поддержку. Зато бегут реализовывать ещё не одобренный C++26.
майки модули высрали - пусть сами и реализуют
У них то в компиляторе как раз таки реализовано на 100%. А фича реально интересная и удобная. Насколько знаю GCC потихоньку идёт чтобы всё доделать, но там очень медленно. Про движение со стороны CLang не в курсе.
А чем интересная и удобная? Наоборот, это противоестесственно для C++, потому что он не является языком модульного программирования. Организация исходного текста в C++ - блочная, и C++ никогда не откажется от этого, а попытка совместить блочную и модульную архитектуру ведёт к усложнению и неразберихе.
Идея в том, чтобы избавиться от сишного наследия, которое уже плохо проявляет себя в крупных проектах. Опять же, время сборки ядра Линукса как пример, и все эти бесконечные header-only библиотеки. Быть может, через двадцать лет люди вовсе не будут знать, что такое хедеры. И это хорошо.
> Опять же, время сборки ядра Линукса как пример, и все эти бесконечные header-only библиотеки.Э... А как же разделы для экспорта. Насколько я понимаю ничто не мешает делать то же самое использую модули. Модули - только сахар не решающие не одну проблему.
Это типа как в Паскале, да? Уже не первый раз встречаю такую штуку, когда кто то что то хейтит, а потом вдруг оказывается, что он не прав.
А разве Паскаль за модули хейтят? В первую очередь, за некраткость begin-end'ов.
> за некраткость begin-end'овИ это проблема у сишников, которые пишут пятикаскадные семиэтажные шаблонные шаблонные идентификаторы длиною длиннее паскалевской программы?
он привел реальный аргумент и перманентную причинуа ты привел один из вариантов горбатого использования конкретным разработчиком
разницу чувствуешь?
Было бы всё нормально с инструментом и руками, люди бы не стали изобретать паскалеподобный раст.
> через двадцать лет люди вовсе не будут знать, что такое хедерНормальные прогеры уже сегодня пишут на Ди и C# - никаких "хэдеров" ;P
"Разрешено не завершать файл с исходным кодом символом новой строки" -А что, раньше было такое жёсткое требование? Зачем?
Не жесткое требоване, но при опечатках в #inclue файлах можно было долго искать место с ошибкой, причем найти в весьма неожиданном файле.
Было бы лучше если бы компилятор после каждого include-включения сам добавлял перевод строки
дак скорее всего так оно теперь и происходит
а если мне не нужен этот \n, я просто хочу несколькими инклюдами слепить цельный идентификатор из нескольких частей, например?
Ну значит перестанешь хотеть. А то с вашими хотелками мы договоримся до того, что надо детям разрешать поднимать с пола каку и тянуть в рот. Им же хочется! Прям как тебе.
Вот flex обычно сегфолтится, если в конце файла нет новой строки.
вся суть сишников в одной фразе :)
Я нуб. Подскажите, куда копать, чтобы сделать код на gcc с extended asm и всякими другими расширениями совместимым с clang? Extended asm поддерживается? Мб есть какой-то заголовочный файл, где расширения gcc типа __attribute__((packed)) объявляются как какие-то константы. Нашел кстати недоработку в extended asm. Было бы прикольно, если бы можно было вставить сегментный регистр переменной в памяти. Полезно, когда у тебя стек не flat и следовательно есть разница, в каком регистре хранится указатель.
Сгементный регистр же можно в памяти сохранить. Вариант mov такой точно есть.
> asm((std::string_view("nop")) ::: (std::string_view("memory")));А что за оператор такой :::
Что-то новенькое?
Всё ближе к брейнфаку приближается. Без таблицы-дешифратора уже не поймёшь, что за набор символов в коде.
старенькое
двоеточиями выражения в ассемблерном блоке разделяются
если часть выражений опускается то можно писать слитно разделители
вне ассемблерных вставок это не используется нигде
Да это синтаксис ассемблерных вставок такой дебильный у gcc."Код":"выходные параметры":"входные параметры":"то, что этот код портит"
Хороший проект. Желаю ему и дальше развиваться. Надеюсь, что со временем LLVM и Clang смогут стать основным тулчейном Linux и архаичный GNU toolchain канит в лету.
А ты для LLVM пробовал написать простенький компилер?? Я - да. После этого в LLVM ни ногой!
Куда же ты теперь ногой? На что переписал свой "простенький компилер"?
"ни ногой" - наверно писал свой супер супер С++ и отстрелил себе одну ногу?
Вот Си - вроде бы примитивный язык, "высокоуровневый ассемблер"! Но попробуй научись всем "фичам" его "гнутого" варианта - офигеешь!