https://www.opennet.dev/openforum/vsluhforumID3/113774.html После шести месяцев разработки представлен (http://lists.llvm.org/pipermail/llvm-announce/2018-March/000077.html) релиз проекта LLVM 6.0 (http://llvm.org/) (Low Level Virtual Machine) - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы. <br><br><br><br>Напомним, что в соответствии с новой нумерацией версий (https://www.opennet.ru/opennews/art.shtml?num=45690) осуществлён уход от разделения значительных и функциональных выпусков. В каждом функциональном обновлении теперь меняется первая цифра (например, осенью состоится релиз LLVM 7.0.0). Для обеспечения совместимости с существующими системами разбора номеров версий LLVM корректирующие обновления, как и раньше приводят к увеличению третьей ц https://www.opennet.dev/openforum/vsluhforumID3/113774.html#46 Fri, 16 Mar 2018 11:18:22 GMT &gt;[оверквотинг удален]<br>&gt; а пишем минимальный, маленький и обозримый в одно лицо компилятор, достаточный <br>&gt; и работоспособный только на ... stage1 gcc или tinycc, достаточный для <br>&gt; сборки stage1 gcc.<br>&gt; И кста, твой комментатор исходил из "имеем исходники gcc, которым не доверяем" <br>&gt; и совсем не отразил это (=что мы не читаем исходники и <br>&gt; не знаем, не лежит ли хак в них) в гадальной части, <br>&gt; типа: ...или хак находится в недоверенных исходниках, или его там нет. <br>&gt; А у тов.Wheeller-а про _недоверие_ таки именно к исходникам gcc не было: <br>&gt; он-то ловит "самораспространяющийся хак (патченную сборку) бинарника", не _обсуждая_ <br>&gt; хаки в исходниках. В отличие "упростившего всё" от комментатора Dan.<br><br>Ладно, лирика это всё. На практике тому же gcc абсолютно всё равно какие флаги используются в stage1. Он всё равно напихает своих при конфигурации. О какой повторяемости результата stage1/stage2 вообще тогда может быть и речь?<br><br>Короче вечером попробую повторить, собрав только базовую инфраструктуру и Си https://www.opennet.dev/openforum/vsluhforumID3/113774.html#45 Fri, 16 Mar 2018 10:23:19 GMT &gt;&gt; https://www.schneier.com/blog/archives/2006/01/countering_trus.html <br>&gt;&gt; //<br>&gt;&gt; https://lists.gnu.org/archive/html/guile-user/2017-11/msg00040.html <br>&gt; Вообще в точку попал, спасибо! По предпоследней ссылке: Там чувак (Dan) в <br>&gt; комментах в одном абзаце всю статью рассказал (мне понравился коммент как <br>&gt; пример лаконичности). :-) <br><br>Самый фан в --<br><br>[I]" If they produce the same binary, then either they are both non malicious, or they are both malicious in the exact same way (which we are guessing is relatively unlikely since they don't share any of the same code) "[/I] --https://www.schneier.com/blog/archives/2006/01/countering_trus.html#c37840<br><br>-- то есть либо оба норм, либо оба прохаканы, но одинаково. Мы можем только гадать, но отметаем неудобный вариант, как ... маловероятный.<br><br>Наука!<br><br>Wheeler trick обходит _это_ с "completely independent compilers: A and T" -- независимы настолько, что одного хака в двух быть не может.<br><br>...<br>У автора Mes более надёжный подход: исходим не из 2ух недов https://www.opennet.dev/openforum/vsluhforumID3/113774.html#44 Fri, 16 Mar 2018 09:15:44 GMT &gt;[оверквотинг удален]<br>&gt; ...а вот же, например: <br>&gt; https://gcc.gnu.org/ml/gcc/2015-05/msg00028.html <br>&gt; https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00973.html <br>&gt; https://gcc.gnu.org/ml/gcc/2014-10/msg00269.html <br>&gt; и далее https://duckduckgo.com/?q=with+clang+bootstrap+site:gcc.gnu.org/ml%2F везде. <br>&gt; Для fun-а <br>&gt; https://duckduckgo.com/?q=diverse+double+compilation <br>&gt; https://www.schneier.com/blog/archives/2006/01/countering_trus.html <br>&gt; // <br>&gt; https://lists.gnu.org/archive/html/guile-user/2017-11/msg00040.html <br><br>Вообще в точку попал, спасибо! По предпоследней ссылке: Там чувак (Dan) в комментах в одном абзаце всю статью рассказал (мне понравился коммент как пример лаконичности). :-)<br><br> https://www.opennet.dev/openforum/vsluhforumID3/113774.html#43 Fri, 16 Mar 2018 08:19:48 GMT &gt; Где-то в соседней теме какой-то умник кричал, что дескать с помощью clang <br>&gt; можно собрать gcc. Несколько лет назад я пробовал собрать этот набор<br>&gt;компиляторов (gcc) с помощью clang, но не взлетело.<br><br>"Обычно" неродным компилятором собирают только stage1 gcc<br> https://gcc.gnu.org/install/build.html<br>- бутстрапят из другого компилятора, а не билдят целиком.<br><br>С т.з. банальной эрудиции, FreeBSD, собирающая базу с системным clang, _должна_ же [успешно] собирать gcc-[67890] в портах системным clang-ом. Хотя они и "второй системный" gcc-4.2.1 попользуют -- недорого возьмут.<br><br>...а вот же, например:<br> https://gcc.gnu.org/ml/gcc/2015-05/msg00028.html<br> https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00973.html<br> https://gcc.gnu.org/ml/gcc/2014-10/msg00269.html<br>и далее https://duckduckgo.com/?q=with+clang+bootstrap+site:gcc.gnu.org/ml%2F везде.<br><br>Для fun-а<br> https://duckduckgo.com/?q=diverse+double+compilation<br> https://www.schneier.com/blog/archives/2006/01/countering_trus.html<br>//<br> https://list https://www.opennet.dev/openforum/vsluhforumID3/113774.html#42 Thu, 15 Mar 2018 09:45:05 GMT Где-то в соседней теме какой-то умник кричал, что дескать с помощью clang можно собрать gcc. Несколько лет назад я пробовал собрать этот набор компиляторов (gcc) с помощью clang, но не взлетело. В этот раз, исключительно just for fun озадачился сборкой gcc-7.3.0 с помощью clang clang++.<br><br>Собственно, я и не ожидал что сборка зайдёт дальше непосредственно gcc и g++, но clang не смог сделать даже это.<br><br>Пробовал с llvm-6.0.0 на x86_64 и i586. Чуть попозже попробую ещё раз, подойдя более серъёзно (реально интересует такая возможность).<br><br>Ну и пока что... Я, опять же, just for fun попробовал сравнить эффективность сборки (размер ELF и его производительность) gcc/g++ и clang/clang++ около 20 пакаджей (с флажками -O2 и -O3, всего по четыре каждого для двух платформ - i586 и x86_64). Чё-то всё пока не пользу clang. Опять же, - [b]меня слабо интересуют искусственные попугаи, мне реально интересно, где использование clang/clang++ даст хоть какой-то плюс. Пускай это будет даже +1% по производительности и -1% по объё https://www.opennet.dev/openforum/vsluhforumID3/113774.html#41 Thu, 15 Mar 2018 08:56:12 GMT &gt;[оверквотинг удален]<br>&gt; эта магия просто не для вас предназначена, а для обычного пользователя - <br>&gt; которому нужно чтобы инструмент просто работал, собирая здесь и сейчас - <br>&gt; и не ломался о модуль, собранный рядомстоящим компиляторами.<br>&gt; а разработчиков, вместо билдхоста собирающих что-то даже для тестов на собственной хз <br>&gt; как хз для чего настроенной системе - надо давить поганым давилом. <br>&gt; (потому что дальше начинаются докеры, полная операционная система внутри пакета, и прочий <br>&gt; мусор вида "у меня на домашнем ноуте все работает, сделайте мне!" <br>&gt; ) <br>&gt;&gt; Причём даже нельзя угадать из какой именно из установленных в системе версий gcc утянет.<br>&gt; можно. просто вы не умеете. И низачем не нужно.<br><br>Что самое, сцуко пародоксальное, то бардак в дистрибутивах наблюдается только в RPM-based. И частично в бубунте с дебиан. И почти никак в Slackware. Другими словами, - всё зависит от вендоров. Как правило, - чем жирнее дистрибутив, тем больше хаоса. Тем нужнее LXC и.т.п.<br><br>Впрочем, непосредственно с ком https://www.opennet.dev/openforum/vsluhforumID3/113774.html#40 Tue, 13 Mar 2018 12:20:11 GMT &gt; Вот я даже не представляю, как при таком поведении компилятора можно собрать что-то без помощи<br>&gt; докера<br><br>да в том и дело, что прекрасно соберется, и будет работать - даже если пара .o произведена не тем компилятором.<br><br>Переносу на соседнюю машину - да, подлежать совсем не будет, потому что зависит от хз какой libgcc_s и еще аллах ведает, чего. Но пользователю - оно и не надо. А непользователь говорит "дурак я, что-ли, на своем ноуте ЭТО делать, он же греется и руки обжигает", и делает push. Там за него само все соберется и результат пришлет.<br><br><br>&gt; Впрочем, при необходимости полностью выпилить gnu-стек и докер не сильно помогает.<br><br>а его пока и нельзя выпилить полностью - даже если кому-то повезло с платформой, и он может обойтись без gnu ld (freebsd вот - пока не может, не смотря на все старания), без прослойки совместимости в трансляторе - не обойдешься в любом случае (то есть те же gcc_s и прочее все равно притащит) - ну и было бы тогда, за что бороться?<br><br> https://www.opennet.dev/openforum/vsluhforumID3/113774.html#39 Sun, 11 Mar 2018 15:20:47 GMT &gt; Где бы это было полезно в чистом клиентском коде, я сходу не могу придумать.<br><br>Самый простой пример &#8212; сравнение строк:<br><br>switch (str1 &lt;=&gt; str2) {<br>// ...<br>}<br><br>будет значительно эффективнее, чем<br><br>if (str1 &lt; str2) {<br> // ...<br>} else if (str1 &gt; str2) {<br> // ...<br>} else {<br> // ...<br>}<br><br>Есть, конечно, функции типа strcmp(), но:<br>1) для неравенства строк стандарт определяет только знак возвращаемого значения, так что вариант со switch-ем отпадает (скорее мелкое неудобство, чем реальный недостаток, но всё же);<br>2) сишные функции не годятся для строк, не оканчивающихся на '\0' (std::string_view и пр.), и строк, которые сами знают свою длину и могут содержать '\0' в любом месте.<br> https://www.opennet.dev/openforum/vsluhforumID3/113774.html#38 Sun, 11 Mar 2018 09:39:12 GMT &gt; а разработчиков, вместо билдхоста собирающих что-то даже для тестов на собственной хз <br>&gt; как хз для чего настроенной системе - надо давить поганым давилом. <br><br>Вот я даже не представляю, как при таком поведении компилятора можно собрать что-то без помощи докера или аналога, позволяющего создать минимальное воспроизводимое сборочное окружение. Впрочем, при необходимости полностью выпилить gnu-стек и докер не сильно помогает.<br>