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)

Арифметика указателей в C и C++ разрешается только в пределах массивов, в соответствии со стандартами

Что имеется ввиду?

thunar ★★★★★
()

Арифметика указателей в C и C++ разрешается только в пределах массивов

Так:

int main()
{
	int a[2][2] = {};
	int i = 2;
	a[0][i] = 0;
}

ловит, но вот так:

int main()
{
	int a[2][2] = {};
	int i = 2;
	int* pi = &a[0][0];
	pi[i] = 0;
}

уже нет. :/

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

А должен? Сначала ты делаешь указатель типа int, а потом пытаешься работать с ним, как с массивом. Да ещё и 0 пытаешься задать в качестве адреса.

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

Нет, но хотелось бы, чтоб ловил и так тоже.

Каким образом, если a — массив, с известными в compile-time размерами, а pi — обычный указатель?

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

Каким образом

Без поддержки со стороны железа, думаю, никаким.

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

C/C++ - стабильность, надёжность, качество. Выберите 0.

забавно слышать такое от расто-фанатика, который использует плюсовый llvm… хотя нет, скорее закономерно.

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

int* pi = &a[0][0]; pi[i] = 0;

В первой строчке создаётся указатель на элемент массива a[0][0]. Во второй строчке идёт запись в указатель не разыменовывая его, то есть записывается новый адрес(указатель - это адрес).

Я не прав?

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

и что он по твоему «ловить» должен? [code=c] int main() { int a[2][2] = {{1,2},{3,4}}; int i = 2; int *p = &a[0][0]; printf(«%d\n», p[i]); }

$ ./a.out 3

[/code]

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

https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html#undefined-behavior-sanitizer-ubsan

Нельзя просто взять (c) и прибавить к указателю число. Только в некоторых случаях можно.

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

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

А вот за это действительно спасибо! Каждень день узнаю что-то новое.

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

out of range - это совсем про другое.

anonymous
()

Арифметика указателей в C и C++ разрешается только в пределах массивов, в соответствии со стандартами

Этот пункт плохо написан, может вводить в заблуждение.

Арифметика-то действительно всегда была запрещена вне массивов, но конкретно в этом релизе фактически запрещены только частные случаи: нельзя прибавлять к нулевому указателю, нельзя вычитать из указателя так чтобы получить нулевой. Если кто-то таким занимается - программа будет сломана.

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

Этот пункт плохо написан, может вводить в заблуждение.

Действительно. Я-то подумал ловят выход за границы массивов. А добавили проверку на какую-то фигню, реально не встречающуюся.

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

Я-то подумал ловят выход за границы массивов

Так его давно уже ловят. Если что-то не поймали - ну, не смогли.

А добавили проверку на какую-то фигню, реально не встречающуюся

Там дело скорее в другом: оптимизатор теперь полагается, что эта фигня не встречается. Наверняка где-то все равно встретится, сишники любят извращения.

anonymous
()

flang в этот выпуск так и не успели добавить.

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

Он только пришёл, а ты уже бабахнул. Да, ты прав, это закономерно.

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

В те времена выбор был либо Си, либо кресты. Из двух кучек говна выбрали ту, которая поменьше. Они не знали, что эта кучка будет расти в геометрической прогрессии.

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

Вот именно, что известными в compile-time размерами и индексом. Достаточно тривиально отследить то, как был получен указатель p и то, куда по нему пытаются писать, если все необходимое было известно в compile-time.

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

Почему UB?

Многомерные массивы идут же подряд.

int a[2][2];

равносилен

int a[4];

по структуре памяти.

Правильно тебе аноним написал…

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

страус труп перелогинься

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

Безопасность Rust основывается не на LLVM, а на статическом анализе кода. Если код удовлетворяет требованиям статического анализатора, а программистом соблюдены контракты при написании unsafe-кода (при наличии такового), и код при этом корректно скомпилирован LLVM, то код действительно будет безопасным. Проблемы LLVM проблемами Rust не являются, хотя и затрагивают его; нарушение контрактов – твой личный добровольный выстрел в ногу, ССЗБ.

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

а тут вы оба правы.

Если нужен занулённый массив, то:

В С нужно с 0 делать.

В С++ можно и просто скобочки и с нулём…

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

а тут вы оба правы.

что?

int a[2][2]; ТАК МОЖНО

int a[2][2] = {0}; ТАК МОЖНО

int a[2][2] = {}; ТАК НЕЛЬЗЯ у него в оригинале ТАК, и так НЕЛЬЗЯ

глаза разуйте

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

это говно не соответствует стандартам

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

Ты бредишь? Специально открыл VS 2019 и проверил:

скриншота не будет, лень винду ребутать, у меня MSVS во всех проектах на {} ругается и не дает собрать, даже с офф реп, и не только у меня

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

Ты забыл сказать версию msvs. На 2017 тоже работает.

anonymous
()
Ответ на: комментарий от RazrFalcon
using std::string_literals::operator""s;

"privet"s + zhopa
anonymous
()
Ответ на: комментарий от RazrFalcon

Сишники спорят как индексировать массив

Шел 2020. RazrFalcon по-прежнему не понимал, о чем говорят другие.

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

у меня MSVS во всех проектах на {} ругается и не дает собрать, даже с офф реп, и не только у меня

видимо намекают, что в крестах вообще не очень правильно использовать сишные массивы.

Lrrr ★★★★★
()

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

Это победа или предательство?

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

Напомни пожалуйста, а что по стандарту в случае

uint8_t *baseaddr = (uint8_t*)(DEVICE_BASE_ADDR);
baseaddr[1] = 0;

?

где DEVICE_BASE_ADDR - адрес начала блока в физическом адресном пространстве, где расположены регистры управления управления какой-либо периферией

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

Это си. Они откуда-то взяли, что арифметика указателей - это ub в с++ и носятся с этим, хотя с++ совместим с си и const char* какбы есть везде и работает без ub. Скорее всего им кто-то наврал, но шланг в последнее время становится все менее адекватным. Например на «abc» + 1 выдает совершенно неадекватное предупреждение. Причем я это встретил в исходниках lua, который не то чтобы васяны пишут, васяны скорее пишут шланг.

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