После шести месяцев разработки представлен релиз проекта LLVM 13.0 - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы...Подробнее: https://www.opennet.me/opennews/art.shtml?num=55898
Супер! Молодцы!
Ждем во фряшечке. Вот и свежий зен подвезли.
Проверил. В портах уже добавили.
> Проверил. В портах уже добавили.Нет. В портах - все еще RC4.
Точно. Со слепу просмотрел. Спасибо!
Теперича таки в портах.
В портах само по себе не сильно интересно, интереснее когда затащат в базу и когда для месы начнут юзать.
Согласен. Но с чего-то надо начинать...
судя по номеру таки production ready
Почему он так долго компи лируется начиная с 12? Судя по логу ощущение что он зависает часов на 20, но это не так и нужно ждать.
Или надо просто выкинуть свой Pentium 4 и компилировать на современном железе.
> Или надо просто выкинуть свой Pentium 4 и компилировать на современном железе.11 то нормально компилируется
Я посмотрел, 16 часов против 50 минут.
Пора переписывать на Rust.
Это ты со сборками линуксов перепктал. В бсдях все православно. Патриархально. Профессура шалить не дает.
И что, в БЗДях ещё не вкатили Rust?
Как в линуксе? Неее.
Они там неосиляторы. Все как один - профессора.
Чтобы компилилось так же или ещё дольше.
Это явно баг, но если вы об этом не сообщие в их багзилу https://llvm.org/docs/HowToSubmitABug.html то никто об этом не узнает и не исправит.
Тут советовали включать USE="pgo" вдруг поможет. Сейчас синкну и посмотрю. Ешё ccache есть,но я его не осилил.(
2021-08-24T10:07:01 >>> sys-devel/llvm: 4 hours, 31 minutes, 59 seconds
2021-08-24T10:07:01 >>> sys-devel/llvm-12.0.1: 4 hours, 31 minutes, 59 seconds
Не тот.(
2021-08-24T10:07:01 >>> sys-devel/llvm-12.0.1: 4 hours, 31 minutes, 59 seconds
2021-10-05T15:10:42 >>> sys-devel/llvm-13.0.0: 4 hours, 5 minutes, 29 seconds
> 2021-08-24T10:07:01 >>> sys-devel/llvm-12.0.1: 4 hours, 31 minutes, 59 seconds
> 2021-10-05T15:10:42 >>> sys-devel/llvm-13.0.0: 4 hours, 5 minutes, 29 secondsТак llvm у меня полчаса компилируется. А вот шланг…
2021-07-10T21:20:55 >>> sys-devel/clang-12.0.1: 1 hour, 11 minutes, 32 seconds
2021-10-06T04:47:40 >>> sys-devel/clang-13.0.0: 4 hours, 24 minutes, 36 seconds2021-08-23T14:38:16 >>> dev-lang/rust-1.54.0: 6 hours, 4 minutes, 37 seconds
26 seconds2021-09-30T13:39:08 >>> dev-lang/rust-1.55.0: 5 hours, 32 minutes, 20 seconds
Profile-guided optimization (PGO) https://ru.wikipedia.org/wiki/Profile-guided_optimization
наоборот увеличивает время компиляции (поскольку делает это дважды). И для sys-devel/llvm такой USE не вижу. Есть для sys-devel/gcc.А с ccache какие сложности?
Добавляется в /etc/portage/make.conf
FEATURES="${FEATURES} ccache"
CCACHE_DIR="/var/tmp/ccache"
KBUILD_BUILD_TIMESTAMP='00:00:00'и вроде всё. Последняя строка не обязательна - она позволяет использовать ccache для сборки ядра.
Ну и ccache сконфигурировать для /var/tmp/ccache (или где будет кеш).
Для ГСС этот флаг им же и собирается. ЛЛВМ не все может собрать.
Имею ввиду, что в ebuild для llvm USE-флаг pdo отсуствует. То есть он ничего не даёт.$ grep -A1 IUSE /var/db/repos/gentoo/sys-devel/llvm/llvm-13.0.0.ebuild
IUSE="debug doc exegesis gold libedit +libffi ncurses test xar xml z3
kernel_Darwin"
Как я понимаю этот флаг создает некий профиль и потом компилит изменения при следующей компиляции если компилить с ГСС. Тот же ЛЛВМ тоже будет собираться быстрее.
А, теперь понял, что имелось ввиду. Да, Вы правы. Если GCC собрать с PGO, он будет собирать быстрее. Но ускорение не в разы.
Я бы предположил, что у тебя оперативка кончилась, и процесс сборки начал свопиться. Хотя, конечно, это гадание на кофейной гуще.
Вполне возможно, но нет никакой дисковой активности и висит 1 процесс по 10+ часов -- вывод никак не меняется. Попробовал уполовинить число потоков, стало ощутимо дольше.
Вон у меня сейчас как раз, "по счастливому совпадению", собирается llvm-13. Вот как раз когда я писал эти строки, он мергался в систему из билд-диры. Сложно оценить сколько именно он собирался, потому что время я не засекал, даже не знаю точно когда он начал собираться, просто пару часов назад я видел его где-то в начале сборки (там две фазы сборки, первая ~1000 объектов собирает, вторая под 2k, вот где-то в середине первой фазы я видел), и потом ещё отправлял его поспать на некоторое время, пока я поиграюсь в игрушку на сон грядущий. Но, думаю, не больше двух часов. На железе 10+ летней давности. С жёсткого диска, не с SSD. И я не замечал за ним, чтобы он резко увеличивал время сборки на какой-то версии, впрочем, опять же, я не следил -- emerge что-то там собирает, я лишь примерно оцениваю общее время сборки с точностью плюс-минус лапоть, а время сборки индивидуальных пакетов оцениваю методом "интуитивный Монте-Карло": чем чаще я вижу, что emerge собирает какой-то пакет, тем дольше значит он собирается.Скорее всего, это какая-то особенность твоей системы, но чтобы хотя бы предположить какая -- нужна информация о том, что происходит. Чем больше, тем лучше. Что за 1 процесс? clang? lld? Загрузка процессора 100%? Какого типа загрузка -- user, sys, iowait? Опции сборки, флаги компилятору какие-то передаёшь? Мне не хочется продолжать гадать на кофейной гуще.
Со сборкой llvm у меня проблем нет, сопоставимо с gcc по веремени. У меня проблема со сборкой clang. И rust тоже слишком долго компилируется.
Хотя не, gcc 15 минут и llvm 60 минут, в 4 раза медленнее выходит.
От 40 до 60.
Ну я могу лишь посочувствовать.
> Сложно оценить сколько именно он собирался, потому что время
> я не засекал, даже не знаю точно когда он начал собиратьсяМожно посмотреть
qlop llvm
это из app-portage/portage-utils
qlop -vHt rust
Так с версией покажет.
Забавно. Не знал про такое. Два с половиной часа для всех с 9 по 13 версию, отдельные выбросы до трёх -- это скорее всего я останавливал его сборку зачем-то.
Нужно закрыть хлебало, прежде чем указывать людям, что им выкинуть, а что нет. Как оплатишь разработку и производство процессора под их нужды и подаришь им его бесплатно - так сразу и выкинут.
Это СПО - делаешь сам, на чистом энтузиазме. Какие деньги?
В ссылку тебя надо с такими комментариями.
Вспоминаю как на своей макоси собирал 11 версию (в Homebrew тогда бинарник ещё не завезли). Эта вещь пять часов компилировалась и из-за этого чуть не опоздал на работу.
Ты так говоришь, как буд-то в длительном конпелянии что-то плозое. Ты можешь откинуться на спинку стула и медитировать, глядя на пробегающие по экрану символы. Представлять, как буд-то и земля и небо все состоит из них.
А он под все доступные архитектуры собирается или только под нужные?
> ... или только под нужные?PDP-11 не поддерживает :(((
Ну это-то явное дно. Как можно без PDP-11?
> Как можно без PDP-11?Плохо без них, сильные программисты больше не нужны.
Есть такая проблема подтверждаю , но приходится выбирать "собирается дольше , но после ui летает" или "собирается по олд стандартной модели быстро собирается , но позже собранная библиотека хуже и тормознее работает" , но есть идея пере собрать сами компиляторы C++20 с помощью C++2a или C++2b и вернуть в олд стандарт по причине сборки в общем никто не говорил что будет легко , а как известно в россии то уж тем более это не работает тут все хотят только деньги получать при том сразу и не работать т.е не заниматься пере сборкой пере меинфреимом
Ебилды уже есть. Идёт собирать...
Отлично проделанная работа. Долгих лет проекту.
> __attribute__((musttail)) ...Вот сейчас хорошо было
gcc это (tail-call optimization) вроде как уже 20 лет умеет, без всяких там __attribute__.Вот сейчас проверил, 4.1.2 точно оптимизирует. А версии ниже у меня под руками нет.
> gcc это (tail-call optimization) вроде как уже 20 лет умеетТак новость вроде про LLVM
Ну да - про ллвм, который научился с костылями делать то, что можно было научиться делать давным-давно и без костылей.
Знаток в треде?llvm выполнял tail-call оптимизации столько, сколько я с ним имел дело. Но, tail-call оптимизация -- это то, что компилятор может делать, может не делать. Как минимум, на его решение оптимизировать или нет влияет заказанный уровень оптимизации. Возможно влияет что-то ещё, тут я не скажу.
Атрибут musttail, что в gcc, что в llvm, делает tail-call оптимизацию обязательной. На любом уровне оптимизаций, даже на -O0. Предположу, что этот атрибут нужен для тех случаев, когда код, написанный в функциональном стиле, рекурсией обрабатывает огромные массивы, и из-за этого в debug-сборках переполняет все разумные размеры стека.
> Атрибут musttail, что в gcc, что в llvm, делает tail-call оптимизацию обязательной.int recursion(int x, int n)
{
if (n == 0)
return x;int r = x * recursion(x-2, n-1);
int q = n + recursion(x+2, n-1);return q * r;
}Оптимизируй "обязательно".
Ты ворвался в тред с обвинениями llvm в том, что он такую полезную фичу запилил только сейчас. Но теперь, ты доказываешь, что фича бесполезная. Либо фича полезная, и тогда ты сейчас несёшь бред. Либо фича бесполезная, и тогда ты бред нёс раньше.
Нет. Я угораю со знатоков, которые радуются, что шланг научился из любой рекурсии делать хвостовую.
> Нет. Я угораю со знатоков, которые радуются, что шланг научился из любой
> рекурсии делать хвостовую.Сам придумал, приписал другим, сам порадовался находке. Зачем парился писать об этом? Ты о каждой мастурбации своей тоже отчитываешься в рандомных уголках интернета?
>> tail-call оптимизацию обязательной.
> int r = x * recursion(x-2, n-1);
> int q = n + recursion(x+2, n-1);
> return q * r;
> Оптимизируй "обязательно"./0
Нэт. Оно работает и не 0 - проверить минута времени.
> Нэт. Оно работает и не 0 - проверить минута времени.Прочитать, что такое tail-call и перестать пороть чушь - тоже минута времени.
Еще один аноним прибежал преобразовывать функцию в обязательную хвостовую рекурсию?
Ну милости прошу, ждем решение.
>> Реализована поддержка гарантированных хвостовых вызовов (вызов подпрограммы в самом конце функции, образующий хвостовую рекурсию в случае, если подпрограмма вызывается саму себя). Поддержка гарантированных хвостовых вызовов обеспечена при помощи атрибута "[[clang::musttail]]" в C++ и "__attribute__((musttail))" в C, применяемых в выражении "return". Возможность позволяет реализовать оптимизации через развёртывание кода в плоскую итерацию для экономии расходования стека.***
>> Calls marked musttail must obey the following additional rules:
>> The call must immediately precede a ret instruction, or a pointer bitcast followed by a ret instruction.
>> The ret instruction must return the (possibly bitcasted) value produced by the call, undef, or void.
>> The calling conventions of the caller and callee must match.***
> Еще один аноним прибежал преобразовывать функцию в обязательную хвостовую рекурсию?Расскажи, в каких именно буковках ты сумел углядеть "преобразовывать функцию в обязательную хвостовую рекурсию"?
>> _гарантированных_ хвостовых вызовов
>> If a return statement is marked musttail, this indicates that the compiler must generate a tail call for the program to be correct, even when optimizations are disabled.
> gcc это (tail-call optimization) вроде как уже 20 лет умеет, без всяких там __attribute__.Т.е. в лучши традициях опеннета, ты либо не читал новость дальше заголовка, либо не знаешь, чем отличается _возможная_ tail call оптимизация от _гарантированной_?
> Вот сейчас проверил, 4.1.2 точно оптимизирует. А версии ниже у меня под руками нет.
Ну-ну.
https://www.mail-archive.com/gcc@gcc.gnu.org/msg95265.html
> Fri, 23 Apr 2021 12:45:18 -0700
> Would it be feasible to implement a "musttail" statement attribute in
> GCC to get a guarantee that tail call optimization will be performed?
> Such an attribute has just landed in the trunk of Clang
> (https://reviews.llvm.org/D99517).
>
> чем отличается _возможная_ tail call оптимизация от _гарантированной_?Оу, даже гарантированной? Ого, какие новые интересные глубины открывают анонимы опеннета.
А не оптимизирует ли гарантированно уважаемый гуру вот такую простую рекурсию?int recursion(int x, int n)
{
if (n == 0)
return x;int r = x * recursion(x-2, n-1);
int q = n + recursion(x+2, n-1);return q * r;
}А я пока схожу в магаз за попкорном.
> Ну-ну.
> https://www.mail-archive.com/gcc@gcc.gnu.org/msg95265.htmlСам по ссылке ходил то, аноним? Или нагуглил первое, не глядя тыкнул и "смааатрите, какой я Тузик, ой, Герой!"
Ссылка: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...
Большой разбор и в конце цитата:
---
One of the biggest caveats with this approach is that these beautiful assembly sequences get catastrophically pessimized if any non tail calls are present. Any non tail call forces a stack frame to be created, and a lot of data spills to the stack.
---Специально для тебя, анонимчик, повторю: IF ANY NON TAIL CALLS ARE PRESENT.
--------------------------
Все, вымерли программисты. Элементарнейшее понятие, - рекурсия, - им уже не знакомо.
>> чем отличается _возможная_ tail call оптимизация от _гарантированной_?
> Оу, даже гарантированной? Ого, какие новые интересные глубины открывают анонимы опеннета.
> А не оптимизирует ли гарантированно уважаемый гуру вот такую простую рекурсию?О, в лучших традициях опеннета пошли отмазки.
> int r = x * recursion(x-2, n-1);
> int q = n + recursion(x+2, n-1);
> return q * r;Т.е. ты не знаешь, что такое хвостовая рекурсия. Отлично.
>>> gcc это (tail-call optimization) вроде как уже 20 лет умеет, без всяких там __attribute__.
>> https://www.mail-archive.com/gcc@gcc.gnu.org/msg95265.html
>> Would it be feasible to implement a "musttail" statement attribute in GCC to get a guarantee that tail call optimization will be performed?
> Сам по ссылке ходил то, аноним? Или нагуглил первое, не глядя тыкнул и "смааатрите, какой я Тузик, ой, Герой!"Сказать-то что хотел, клоун?
> Ссылка: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...
> An exciting feature just landed in the main branch of the Clang compiler. Using the
> [[clang::musttail]] or __attribute__((musttail)) statement attributes, you can now get
> guaranteed tail calls in C, C++, and Objective-C.То ли ты и эту ссылку не читал, то ли это такой неуклюжий спрыг ...
> Большой разбор и в конце цитата:
Эк ты ловко пропустил
> Tail call optimization is not even new to Clang: like GCC and many other compilers, Clang was
> already capable of optimizing tail calls. In fact, the musttail attribute in our first example
> above did not change the output of the compiler at all: Clang would already have optimized the
> tail call under -O2.
> What is new is the guarantee. While compilers will often optimize tail calls successfully, this is best-effort, not something you can rely onи
> I very much hope that the attribute will catch on, spreading to GCC,---
> --------------------------
> Все, вымерли программисты. Элементарнейшее понятие, - хвостовая рекурсия, - им уже не знакомо.Экий ты самокритичный.
Ну и ладно: эта балаболка сломалась, вносите следующую!
Слив, как говорится, засчитан.Вместо подтверждения своих слов решением простейшей задачи аноним с криками "балаболка сломалась, ничего не вижу, бабабаба" убежал в кусты.
Впрочем, это было ожидаемо, ибо вы не умеете ничего решать, вы умеете только звездеть на форуме, ни уха ни хвоста не понимая в темах.
> Урри сел в лужу с "gcc это (tail-call optimization) вроде как уже 20 лет умеет"
> Урри сел в лужу с хвостовой рекурсией
> Урри важно надул щечки и сделал вид принимающего грязевую ванну
> Слив, как говорится, засчитан.Засчитан, засчитан. Ты главное, не огорчайся - ничего иного я от тебя уже и не ожидал.
> Впрочем, это было ожидаемо, ибо вы не умеете ничего решать, вы умеете только звездеть на форуме, ни уха ни хвоста не понимая в темах.Ты полностью раскрыл свое "понимание" темы своим же "примером". И походу даже сейчас до тебя не дошло, _что_ там не так.
>> чем отличается _возможная_ tail call оптимизация от _гарантированной_?
>> tail call оптимизация
> оптимизируй
> (x * recursion(x-2, n-1) * (n + recursion(x+2, n-1));---
https://wiki.haskell.org/Tail_recursion
> A recursive function is tail recursive if the final result of the recursive call is the final result of the function itself. If the result of the recursive call must be further processed (say, by adding 1 to it, or consing another element onto the beginning of it), it is not tail recursive.
> Here is formal definition of "tail recursive". ...
>
> (x * recursion(x-2, n-1) * (n + recursion(x+2, n-1));нэт. это не хвостовая рекурсия.
еще варианты?> Урри сел в лужу с хвостовой рекурсией
Как видим в луже сейчас барахтается анонн, но всем вопит что он не он.
Если что, то Урри уже 20 лет пишет рекурсии на лиспе и отлично знает как и что надо делать.
>>> tail call оптимизация
>> оптимизируй
>> (x * recursion(x-2, n-1) * (n + recursion(x+2, n-1));
> нэт. это не хвостовая рекурсия.Конечно же нет - это же твой п̵о̵п̵ы̵т̵к̵а̵ ̵н̵е̵у̵к̵л̵ю̵ж̵е̵г̵о̵ ̵с̵п̵р̵ы̵г̵а̵ "пример". Сам же цитировал "tail call оптимизация" и сам же предложил "А не оптимизирует ли" ... "это не хвостовая рекурсия".
То ли старческий маразм, то ли не менее классическое опеннетное "прочитал жопой, сам себе что-то придумал, сам себе что-то подтвердил, сам себе надул щечки".
> Если что, то Урри уже 20 лет рассказывает на опеннете, что пишет рекурсии на лиспеНикто и не сомневался в подвешенности твоего языка/пальцев, умения юлить и нести с умным видом бред.
Ты вот мне обьясни, зачем ты троллиреешь из под акка? Ведь априори все понимают, что ты пгосто шуткуешь:)
> Ты вот мне обьясни, зачем ты троллиреешь из под акка? Ведь априори
> все понимают, что ты пгосто шуткуешь:)Это нынче называется троллингом? Кек, я всегда любил троллей, а теперь просто обожаю. Люблю когда люди в разговоре со мной выглядят тупыми как пробка, но если они делают это намеренно, чтобы сделать приятно мне, то это вызывает чувство благодарности.
Троллинг тупостью. Есть такое.
> Ссылка: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...
> Большой разбор и в конце цитата:
> ---
> One of the biggest caveats with this approach is that these beautiful
> assembly sequences get catastrophically pessimized if any non tail calls are
> present. Any non tail call forces a stack frame to be
> created, and a lot of data spills to the stack.
> ---Вот листинг, к которому относится комментарий
ADDVN: # @ADDVN
push rbp
push r15
push r14
push r13
push r12
push rbx
push rax
mov r15, r9
mov r14, r8
mov rbx, rcx
mov r12, rsi
mov ebp, edi
movzx eax, dh
cmp dword ptr [r9 + 8*rax + 4], -12
jae .LBB0_1
.LBB0_2:
movzx eax, dl
movsd xmm0, qword ptr [r14 + 8*rax] # xmm0 = mem[0],zero
mov eax, ebp
addsd xmm0, qword ptr [r15 + 8*rax]
movsd qword ptr [r15 + 8*rax], xmm0
mov edx, dword ptr [rbx]
add rbx, 4
movzx eax, dl
movzx edi, dh
shr edx, 16
mov rax, qword ptr [r12 + 8*rax]
mov rsi, r12
mov rcx, rbx
mov r8, r14
mov r9, r15
add rsp, 8
pop rbx
pop r12
pop r13
pop r14
pop r15
pop rbp
jmp rax # TAILCALL
.LBB0_1:
mov edi, ebp
mov rsi, r12
mov r13d, edx
mov rcx, rbx
mov r8, r14
mov r9, r15
call fallback
mov edx, r13d
jmp .LBB0_2
"a lot of data spills to the stack" вижу (конвенция обязывает сохранить регистры из строк с rbp ... rbx; допустимо ли было это оптимизировать без inline подстановки вызываемой функции fallback или стоило перенести за метку .LBB0_1 - другой вопрос)."a stack frame" не вижу.
RBP используется как регистр общего назначения (mov ebp, edi).
Единственная операция с указателем стека (add rsp, 8) компенсирует push rax из 8-й строки.
В связи с последним возникает вопрос: на кой пихать аккумулятор в стек, если значение не нужно?
Что-то не то с этим кодом. Возможно, недоделка оптимизатора, или баг.
По поводу push rax смотрим AMD64 ABI Draft 1.03.2.2 The Stack Frame
"the value (%rsp + 8) is always a multiple of 16 (32 or 64) when control is transferred to the function entry point."
Требование обусловлено возможным сохранением в стеке 128-битных регистров (xmm).
Т.о. команда дополняет 6 предыдущих push, с учётом сохранения rip на стеке при call имеем выровненный указатель (насколько оправдано следовать требованиям, когда копилятор видит определение вызываемой функции, где отсутствует запись в стек 128-битных данных -- другой вопрос).
По поводу "add rsp, 8" смотрим 64-ia-32-architectures-optimization-manual.pdf3.4.2.6 Optimization for Decoded ICache
Assembly/Compiler Coding Rule 25. (M impact, M generality) Avoid putting explicit references to
ESP in a sequence of stack operations (POP, PUSH, CALL, RET).Правило исключать явное обращение к указателю стека из последовательностей push обусловлено в
2.4.2.4 Micro-op Queue and the Loop Stream Detector (LSD)
The Loop Stream Detector (LSD)
...
Cannot have mismatched stack operations. For example, more PUSH than POP instructions.Вопрос по "add rsp, 8" открыт.
Да, да, уже проанализировал с помощью PVS-Studio. Наслаждаюсь опечатками в коде LLVM. Пример:bool operator==(const BDVState &Other) const {
return OriginalValue == OriginalValue && BaseValue == Other.BaseValue &&
Status == Other.Status;
}Пишу статью.
Очень ждем! Всегда вас плюсую. Вы такой молодец!
Выше в треде кто-то ёрничал в духе "нужно переписать на Rust" (по другому поводу), только прикол в том, что clippy эту ошибку отлавливает:struct X {
a: usize,
b: usize,
}impl PartialEq for X {
fn eq(&self, other: &Self) -> bool {
self.a == self.a && self.b == other.b
}
}error: equal expressions as operands to `==`
--> src/main.rs:12:9
|
12 | self.a == self.a && self.b == other.b
| ^^^^^^^^^^^^^^^^
|
= note: `#[deny(clippy::eq_op)]` on by default
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#eq_opКто не в курсе, clippy поставляется с тулчейном.
Я ни к чему не призываю, тем более к переписыванию LLVM на Rust (упаси боже). Просто хотел поделиться достижениями прогресса и отметить профессионализм разработчиков, которые умудрились написать не только самый полезный компилятор (безотносительно ЯП), но и приличный статический анализатор в довесок.
Тут был ответ на мой комментарий (удалён):>>Я ни к чему не призываю, тем более к переписыванию LLVM на Rust (упаси боже).
>Ты же растаман! Почему ты ёрничаешь?Я не ёрничаю, просто понимаю, что переписать миллионы строк кода на любой ЯП - мало того, что очень трудозатратно, но вдобавок чревато внесением туевой хучи новых багов, чего мне категорически не хотелось бы видеть в компиляторах, использующих LLVM. Тоже относится к перписыванию Linux.
./test.cpp:6:16: warning: self-comparison always evaluates to true [-Wtautological-compare]
return value == value && value == other.value;
Я прошу прощения, за сообщение не совсем по теме новости. У clang есть документация (PDF, просто как страницы в Интернете)? Не "обрезанный" user's manual https://clang.llvm.org/docs/UsersManual.html, а что-то подобное документации GCC?
https://clang.llvm.org/docs/ - все что есть. Как в gcc чтобы - нет, такого нету.
"Код открытый, но корпорасты не хотят чтобы вы его легко изучили". Вот весь и ответ.
А чего тут не хватило?
https://clang.llvm.org/docs/
Сравните, например, описание -march и -mtune в документации GCC и в https://clang.llvm.org/docs/. Или описание -W{...} опций.
А вот и обещанная статья: Выявляем ошибки в релизе LLVM 13.0.0 - https://pvs-studio.com/ru/blog/posts/cpp/0871/
Скажите, пожалуйста, вы собираетесь сообщать о найденных ошибках сообществу? Или эта статья была только в целях PR вашего продукта?
Понимаю, что вы ничего никому не должны, просто любопытствую.
Спасибо.
https://bugs.llvm.org/show_bug.cgi?id=52120
А где-то еще llvm используется, окромя шланга?
Тебя в Гугле забанили? Или от природы такой "сообразительный"?