LINUX.ORG.RU

LLVM 10.0

 , , ,


1

4

LLVM – платформа для разработки компиляторов и тулчейнов под лицензией Apache 2.0 с исключениями.

Некоторые изменения в clang:

  • Теперь по умолчанию компиляция не запускается в новом процессе как раньше.

  • Поддерживаются концепты C++20.

  • Арифметика указателей в C и C++ разрешается только в пределах массивов, в соответствии со стандартами. Добавлены соответствующие проверки в Undefined Behavior Sanitizer.

  • Улучшена поддержка OpenCL и OpemMP 5.0.

  • Поведение в ряде случаев приближено к поведению GCC.

Некоторые общие изменения в LLVM:

  • Новые intrinsics для генерации оптимизированных векторных инструкций.

  • Значительно расширены возможности межпроцедурной оптимизации в экспериментальном фреймворке Attractor.

  • Множество улучшений в поддержке различных архитектур (AArch64, ARM, MIPS, PowerPC, SystemZ, X86, WebAssembly, RISC-V).

А также различные улучшения в libclang, clangd, clang-format, clang-tidy, Static Analyzer, LLDB.

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

anonymous

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

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

отсчёт с нуля - классика, остальное чистый синтакс-сахар. Ненужный сахар. ИМХО.

Индексная переменная более логична при переборе (нумерации) предметов: первый, второй, третий, четвёртый, пятый…

По крайней мере, нумерация квартир в домах начинается не с «0», а с номера «1».

Ноль нужен лишь при обозначении количества предметов: 0 предметов, 1 предмет, 2 предмета, 3 предмета, 4 предмета, 5 предметов…

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

🤦‍♂️

Ладно. Чему будет равно i в следующем коде?

constexpr int nth(const int* pi, int n) { return pi[n]; }

int main()
{
	constexpr int ia[2][2] = { 0, 1, 2, 3, };
	constexpr int i = nth(&ia[0][0], 3);
}
utf8nowhere ★★★
()
Ответ на: 🤦‍♂️ от utf8nowhere

Ok, я тебя понял, почему ты считаешь так.

Но у нас есть то что элементы в массивах находятся подряд.

int main()
{
	constexpr int ia[2][2] = { 0, 1, 2, 3, };
	static_assert(&ia[0][0]+2 == &ia[1][0]);
}

и то что без constexpr никто никакой ошибки не видит.

Санитайзеры умны…

Есть над чем подумать…

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

Ok, я тебя понял, почему ты считаешь так.

Точно? И почему же?

Но у нас есть то что элементы в массивах находятся подряд.

Что это утверждение значит?

и то что без constexpr никто никакой ошибки не видит.

А почему при constexpr ошибка?

Есть над чем подумать…

Ага. Заодно попробуй доказать, что:

  • выражение в твоём static_assert является константным
  • что оно обязано вычисляться в true

(Я в курсе, что GCC, Clang и MSVC считают что оно константно и что значение его истинно. Только вот из стандарта это, похоже, не следует)

utf8nowhere ★★★
()
Последнее исправление: utf8nowhere (всего исправлений: 1)
Ответ на: комментарий от cvs-255

Но там вообще ад, там если у тебя массив начинается по адресу XXX0:0000, то после увеличения адреса на 65536 байт ты окажешься в XXX1:0000, что на самом деле на 16 байт отстоит от начала массива

Ад — это когда публикуют такие вбросы. Это называлось large или huge memory model, когда указатель состоял из двух частей: сегмент и смещение. Тогда и в голову никому не приходило, что это стоит трактовать как 32-битное целое.

Если хочешь чего-то более приближенного к аду, посмотри, как в Spectrum происходила адресация пикселя.

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

Возможно. Для обычного человека.

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

NULL-поинтер - все нули на адресной шине. Память тоже можно рассматривать как массив байт/бит/слов и т.п.

drfaust ★★★★★
()
Последнее исправление: drfaust (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.