The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Релиз набора компиляторов LLVM 6.0

08.03.2018 21:56

После шести месяцев разработки представлен релиз проекта LLVM 6.0 (Low Level Virtual Machine) - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы.

Напомним, что в соответствии с новой нумерацией версий осуществлён уход от разделения значительных и функциональных выпусков. В каждом функциональном обновлении теперь меняется первая цифра (например, осенью состоится релиз LLVM 7.0.0). Для обеспечения совместимости с существующими системами разбора номеров версий LLVM корректирующие обновления, как и раньше приводят к увеличению третьей цифры (6.0.1, 6.0.2, 6.0.3).

Из новых возможностей LLVM 6.0 отмечается включение в Clang по умолчанию стандарта C++14 ("-std=gnu++14" вместо "-std=gnu++98"), обеспечение поддержки некоторых возможностей будущего стандарта C++2a, интеграция патчей retpoline для блокирования второго варианта уязвимости Spectre, значительное улучшение поддержки отладочной информации CodeView для Windows, включение по умолчанию фреймворка GlobalISel для архитектуры AArch64 при сборке с уровнем оптимизации "-O0", добавление новых предупреждений компилятора.

Улучшения в Clang 6.0:

  • В качестве диалекта языка C++ по умолчанию установлен gnu++14 ("-std=gnu++14") вместо ранее применявшегося gnu++98 ("-std=gnu++98"), что позволяет по умолчанию компилировать код, в котором присутствуют возможности, определённые в стандарте C++14, включая специфичные расширения GNU;
  • Добавлены некоторые возможности, развиваемые для будущего стандарта C++20 (кодовое название C++2a):
    • Макрос __VA_OPT__ для адаптивного раскрытия вариативных макросов в зависимости от наличия токенов в вариативном аргументе;
    • Поддержка оператора "<=>" для трехстороннего сравнения;
    • Поддержка инициализаторов элементов по умолчанию для битовых полей;
    • Возможность лямбда-захвата выражений "*this";
    • Вызов элементов по указателю (Pointer-to-member), используя определённые через выражение "const &" указатели на временные объекты;
    • Оператор delete с деструктором, описанный в документе P0722R1, но пока не одобренный для включения в спецификацию C++2a;

    Для включения поддержки C++2a следует использовать опцию "-std=c++2a", при этом все указанные возможности, кроме __VA_OPT__ и "<=>", доступны и в других режимах C++, но приводят к выводу предупреждения;

  • Для блокирования в приложениях второго варианта уязвимости Spectre (CVE-2017-5715) в состав включён механизм Retpoline, основанный на применении специальной последовательности инструкций, исключающей вовлечение механизма спекулятивного выполнения для косвенных переходов (использование инструкции RET вместо JMP). Включение защиты осуществляется при помощи флага "-mretpoline" или "-mretpoline-external-thunk" при необходимости более тонкой настройки работы Retpoline;
  • Добавлена поддержка конфигурационных файлов, в которых можно размещать коллекции из применяемых при сборке опций. Для использования настроек из файла конфигурации можно использовать опцию "--config foo.cfg" или создать исполняемый файл вида "foo-clang". Перечисленные в файле конфигурации опции включаются до опций, перечисленных в командной строке. Основным назначением файлов конфигурации является упрощение организации кросс-компиляции;
  • Добавлены новые флаги "-fdouble-square-bracket-attributes" и "-fno-double-square-bracket-attributes" для включения и выключения атрибутов, задаваемых в двойных квадратных скобках, в любых языковых режимах;
  • Для обеспечения совместимости с GCC добавлены языковые режимы "-std=c17", "-std=gnu17" и "-std=iso9899:2017" для включения поддержки нового стандарта языка Си. Режимы c17 и c11 отличаются только значением макроса __STDC_VERSION__, так как в новой спецификации отмечается только исправление ошибок;
  • Добавлены флаги "-fexperimental-isel" и "-fno-experimental-isel" для включения и выключения нового фреймворка выбора инструкций GlobalISel. Данный фреймворк включен по умолчанию для архитектуры AArch64 при установке уровня оптимизации "-O0";
  • Добавлен флаг "-nostdlib++" для отключения связывания со стандартной библиотекой C++ (действие аналогично вызову clang вместо clang++, но не отключает "-lm");
  • Большая часть атрибутов Clang теперь доступна как в нотации GNU (__attribute((name))), так и в нотации Clang ([[clang::name]]). Добавлен встроенный макрос препроцессора __has_c_attribute() для динамической проверки доступности в режиме Си атрибутов, задаваемых в двойных квадратных скобках (данный синтаксис атрибутов включается флагом "-fdouble-square-bracket-attributes");
  • Добавлена начальная поддержка сборки для платформы Windows на системах ARM64;
  • Расширены возможности, связанные с поддержкой OpenCL и OpenMP;
  • Прекращена поддержка операционной системы Bitrig, так как данный форк воссоединился с OpenBSD;
  • Для обеспечения совместимости с заголовочными файлами стандартной библиотеки Visual Studio 2015 и 2017 значение _MSC_VER по умолчанию изменено с 1800 до 1911;
  • По умолчанию в исполняемые файлы теперь добавляется секция ".init_array", если в системе не установлен GCC. Если наличие GCC обнаружено и версия старее 4.7.0, то как и раньше подставляется секция ".ctors";
  • Добавлены новые встроенные макросы препроцессора __is_target_arch, __is_target_vendor, __is_target_os и __is_target_environment, которые могут применяться для определения отдельных характеристик целевой платформы;
  • Расширены возможности для диагностики. Например, добавлена опция "-Wpragma-pack" для выявления проблем, возникающих при использовании директивы "#pragma pack", и опция "-Wtautological-constant-compare" для информирования о сравнении целочисленной переменной и целочисленной константой того же типа, имеющей наименьшее или наиболее из возможных для данного типа значений;
  • В clang-format добавлена опция IndentPPDirectives для расстановки отступов для директив препроцессора, содержащих условные выражения (if/endif), а также опция IncludeBlocks для перегруппировки блоков заголовочных файлов;
  • В статическом анализаторе обеспечено корректное определение и диагностика применения унарных операторов инкремента/декремента над неинициализированным значением;
  • В linter clang-tidy добавлена большая порция новых проверок и обеспечена поддержка стандарта кодирования High Integrity C++ Coding Standard;
  • Добавлен минимальный runtime для компонента UBSan (Undefined Behavior Sanitizer) с реализацией детектора неопределенного поведения, выявляющего во время выполнения программы ситуации, когда поведение программы становится неопределенным. Runtime предоставляет только простые функции ведения лога событий во время выполнения и дедупликацию выводимых в лог записей ("-fsanitize=vptr" не поддерживается).

Основные новшества LLVM 6.0:

  • Для архитектуры x86 добавлена поддержка CPU Intel Icelake и предоставляемых процессорами Intel расширенных инструкций VAES, GFNI, VPCLMULQDQ, AVX512VBMI2, AVX512BITALG и AVX512VNNI. Добавлена информация для планирования инструкций для процессоров Intel Sandy Bridge, Ivy Bridge, Haswell, Broadwell и Skylake. Улучшена модель планировщика для CPU AMD Jaguar. Улучшена генерация кода при сравнении областей памяти, умножении векторов i32, ротации целых векторов (XOP и AVX512), вычисления абсолютных скалярных целых значений, усечении векторов;
  • В компоновщике LLD продолжено решение проблем с совместимостью, улучшена поддержка форматов ELF и COFF, обеспечена возможность генерации компактной динамической relocation-таблицы в стиле Android, добавлена начальная поддержка WebAssembly (добавлен компоновщик wasm-ld), добавлены новые опции: --icf=none -z muldefs --plugin-opt --no-eh-frame-hdr --no-gdb-index --orphan-handling={place,discard,warn,error} --pack-dyn-relocs={none,android} --no-omagic --no-print-gc-sections --ignore-function-address-equality -z retpolineplt --print-icf-sections --no-pie;
  • Для платформы NetBSD на системах с архитектурой x86(_64) добавлена предварительная поддержка санитайзеров (ASan, UBsan, TSan, MSan, SafeStack, libFuzzer);
  • Значительно улучшено качество предоставления отладочной информации CodeView для Windows;
  • Для архитектур x86 и ARM добавлена поддержка включения обработки исключений SjLj (setjmp/longjmp) на платформах, в которых SjLj не применяется по умолчанию;
  • Внесены многочисленные улучшения в бэкенды для архитектур AArch64, ARM, AVR, Hexagon, MIPS и PowerPC. В том числе добавлена полная поддержка MIPS MT ASE, проведена работа по сокращению кода microMIPS, для AArch64 в режиме "-O0" включён по умолчанию фреймворк выбора инструкций GlobalISel.


  1. Главная ссылка к новости (http://lists.llvm.org/pipermai...)
  2. OpenNews: Релиз набора компиляторов LLVM 5.0
  3. OpenNews: Создатель LLVM и Swift уходит из компании Apple
  4. OpenNews: Проект LLVM переходит на новую схему нумерации выпусков
  5. OpenNews: Проект LLVM планирует сменить лицензию
  6. OpenNews: Релиз набора компиляторов GCC 7
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/48223-llvm
Ключевые слова: llvm, clang, compile
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (38) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Named (?), 00:01, 09/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    > В каждом функциональном обновлении теперь меняется первая цифра...  корректирующие обновления, как и раньше приводят к увеличению третьей цифры.

    А вторая цифра на что тогда?

    Непонятно, зачем в последнее время многие переходят на такую нумерацию. Особенно в профессиональных продуктах.
    Ведь есть же четкая схема: первая цифра - значительные функциональные изменения (возможно, с нарушением обратной совместимости), вторая - изменения с обеспечением совместимости, 3-я - багфиксы. Понятно по версии, чего можно ждать от обновления.

     
     
  • 2.3, Аноним (-), 01:09, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Непонятно, зачем в последнее время многие переходят на такую нумерацию.

    По сути, большего и не надо. Одно число обозначает ветку, второе - номер более-менее стабильного релиза в ветке.  Уверен, через какое-то время от второй цифры тоже избавятся: будут просто брать последний коммит в нужной ветке, а производители в ветки будут добавлять только исправления ошибок, а вообще все другие изменения отправлять в ещё не зарелизенную ветку.

    Глобальных изменений в софте больше не происходит. Это раньше было Windows 3.1, Windows 95, Windows NT, и периодически новое поколение вносило что-то принципиально новое. А сейчас одинаковые ветки без масштабных изменений. Linux 2.0, 2.2 и 2.4 отличались достаточно сильно, 2.6 уже не настолько отличалась от 2.4, а уж после 2.6 принципиальных изменений практически и не было. Точнее, были, но разбивались на мелкие куски и внедрялись постепенно непрерывным потоком, так что ничего глобального между смежными релизами не ощущалось.

    Психологически, мне было бы комфортнее с тремя цифрами. Зафиксировали бы просто старшую цифру, и меняли вторую и третью. Ну и что, что linux 3.127.11? Вооще не проблема. А возможность смены первой оставили бы на какой-нибудь глобальный случай, который сейчас и предусмотреть нельзя.

     
     
  • 3.4, YetAnotherOnanym (ok), 02:00, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Глобальных изменений в софте больше не происходит

    Уфффф... Ну наконец-то! А то они меня уже утомили.

     
  • 3.8, Аноним (-), 09:12, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Уверен, через какое-то время от второй цифры тоже избавятся: будут просто брать последний коммит в нужной ветке

    Последний коммит - это тоже слишком сложно.
    Просто перейдут на блокчейны и смарт-контракты - все станет просто и понятно.

     
     
  • 4.23, Аноним (-), 17:02, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Последний коммит - это тоже слишком сложно.
    > Просто перейдут на блокчейны и смарт-контракты - все станет просто и понятно.

    А что, это идея. Комитнул в проект - выполнил таск - прокатили тесткейсы - вот тебе бабло. А иначе иди и переделывай свою халтуру. А так чтобы протирать штаны, переваливать работу на других да еще и денег получать - опа-па!

     
  • 4.27, Аноним (-), 20:03, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >блокчейны и смарт-контракты

    экая мерзость

     
  • 2.6, Тот_Самый_Анонимус (?), 06:09, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Первое число — на ветку с длительным сроком поддержки. Второе — на выпуски между первыми ветками, третье — на исправления.
     
  • 2.11, пох (?), 09:26, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Непонятно, зачем в последнее время многие переходят на такую нумерацию.

    инвесторы (ну вы уже запомнили какое слово подставлять вместо) любят большие числа. А если ты им версию 2.7.2.1 - они резонно спрашивают "с какой ерундовой херней вы там копаетесь и не урезать ли вам финансирование". Потому что нет уже инвесторов, не осталось.

     
  • 2.14, Аноним (-), 10:08, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > есть же четкая схема: первая цифра - значительные функциональные изменения (возможно, с нарушением обратной совместимости), вторая - изменения с обеспечением совместимости, 3-я - багфиксы.

    Сейчас в моде "непрерывная разработка", все функциональные изменения вводятся постепенно, так что первая цифра просто никогда бы не менялась.

     
     
  • 3.15, Аноним (-), 11:33, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +6 +/
    И поэтому программы превращаются в непрерывную недоделку.
     
     
  • 4.22, Nexmean (?), 16:46, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    То ли дело было раньше, пусть программа и была недоделкой, зато дискретной!
     
  • 4.25, Аноним (-), 17:19, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > И поэтому программы превращаются в непрерывную недоделку.

    Зато быстрофиксы прилетают. А раньше надо было еще и ждать быстрофикса хрен знает сколько. Очень удобно курить бамбук полгода с известной проблемой.

     

  • 1.2, Гоги (?), 00:01, 09/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –14 +/
    LLVM так хорошо развивается, что уже два раза почешешь репу, подо что писать новый язык - под дотнет (с кучей готовых либ) или нэтив, но зато с полным гемороем по написанию ВСЕГО.
     
     
  • 2.28, Вареник (?), 20:58, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Для аппликух есть .NET и JDK.

    Для игр-3D-DeepLearning-Robotics-околонаучного-статистики-графиков есть C++ и интерфейсами либ на Python.

    с продвижением JS как средства все затормозить во всех этих категориях.

     

  • 1.5, leap42 (ok), 02:13, 09/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Добавлена предварительная поддержка санитайзеров (ASan, UBsan, те, которых никто не знает)

    можно начинать пользоваться

     
  • 1.18, Аноним (-), 13:33, 09/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    >Поддержка оператора "‹=›" для трехстороннего сравнения;

    Астанавитесь!!!

     
     
  • 2.31, 0xd34df00d (??), 05:25, 10/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вам так нравится писать от 6 до бесконечности операторов сравнения руками?
     
     
  • 3.33, Аноним (-), 22:56, 10/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А как это должно уменьшить объём писанины?


    if (a < b) {
        // ...
    } else if (a > b) {
        // ...
    } else {
        // ...
    }




    switch (a <=> b) {
    case std::partial_ordering::less:
        // ...
        break;
    case std::partial_ordering::greater:
        // ...
        break;
    default:
        // ...
        break;
    }


    Единственное "достоинство" — выглядит не по-сишному.
     
     
  • 4.34, 0xd34df00d (??), 23:50, 10/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это уменьшает объём писанины в первую очередь для автора класса, а не для клиента. Для кучи практически полезных случаев компилятор способен сгенерировать определение оператора (и всех выражающихся через него) сам. Можно посмотреть в пропозалах или на cppreference ( http://en.cppreference.com/w/cpp/language/default_comparisons ) подробнее.

    Где бы это было полезно в чистом клиентском коде, я сходу не могу придумать.

    Ну и, кроме того, иерархия типов определяемых порядков (частичный порядок, сильный порядок, вот это всё) — это интересно.

     
     
  • 5.37, Аноним (-), 12:33, 11/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну ок, убедил.
     
  • 5.39, Аноним (-), 18:20, 11/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Где бы это было полезно в чистом клиентском коде, я сходу не могу придумать.

    Самый простой пример — сравнение строк:

    switch (str1 <=> str2) {
    // ...
    }

    будет значительно эффективнее, чем

    if (str1 < str2) {
        // ...
    } else if (str1 > str2) {
        // ...
    } else {
        // ...
    }

    Есть, конечно, функции типа strcmp(), но:
    1) для неравенства строк стандарт определяет только знак возвращаемого значения, так что вариант со switch-ем отпадает (скорее мелкое неудобство, чем реальный недостаток, но всё же);
    2) сишные функции не годятся для строк, не оканчивающихся на '\0' (std::string_view и пр.), и строк, которые сами знают свою длину и могут содержать '\0' в любом месте.

     

  • 1.19, Iaaa (ok), 14:31, 09/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > По умолчанию в исполняемые файлы теперь добавляется секция ".init_array", если в системе не установлен GCC. Если наличие GCC обнаружено и версия старее 4.7.0, то как и раньше подставляется секция ".ctors";

    А домашний адрес, если обнаружен, автоматом в секции не проставляется? И как насчет полного списка установленных пакетов туда же, в отдельную секцию?

    Почему было не запилить для этой фичи флажок, вместо вот такого шпионажа?

     
     
  • 2.20, Аноним (-), 15:08, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ты бы почитал про .init_array сначала, прежде чем чушь писать.
     
     
  • 3.21, Iaaa (ok), 15:14, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    У анонима, как обычно, апломба вагон и знаний тележка.

    Я то в курсе для чего нужна секция ".init_array". А вот ты мне можешь объяснить, какое отношение имеет установленный или НЕ установленный в системе GCC наполнению этой секции?

    Особенно с учетом того, что я в любой момент могу гцц снести или доустановить, без какой-либо перекомпиляции своих, запланированных для сборки ТОЛЬКО шлангом, сорцов?

     
     
  • 4.24, Аноним (-), 17:17, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Костылестроение во все поля...
     
  • 4.32, all_glory_to_the_hypnotoad (ok), 18:17, 10/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    +1. Вообще эта магия внутри шланга с gcc подзадалбывает. Развернули у нас на производстве, понимаешь, clang вместо gcc и его стандартной библиотеки. Так этот грёбанный clang, как его не корми опциями, всё равно время от времени умудряется отыскать в системе gcc и что-то из него утянуть. Причём даже нельзя угадать из какой именно из установленных в системе версий gcc утянет.
     
     
  • 5.35, пох (?), 09:48, 11/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Вообще эта магия внутри шланга с gcc подзадалбывает.

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

    а разработчиков, вместо билдхоста собирающих что-то даже для тестов на собственной хз как хз для чего настроенной системе - надо давить поганым давилом.
    (потому что дальше начинаются докеры, полная операционная система внутри пакета, и прочий мусор вида "у меня на домашнем ноуте все работает, сделайте мне!" )

    > Причём даже нельзя угадать из какой именно из установленных в системе версий gcc утянет.

    можно. просто вы не умеете. И низачем не нужно.

     
     
  • 6.38, Аноним (-), 12:39, 11/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > а разработчиков, вместо билдхоста собирающих что-то даже для тестов на собственной хз
    > как хз для чего настроенной системе - надо давить поганым давилом.

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

     
     
  • 7.40, пох (?), 15:20, 13/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот я даже не представляю, как при таком поведении компилятора можно собрать что-то без помощи
    > докера

    да в том и дело, что прекрасно соберется, и будет работать - даже если пара .o произведена не тем компилятором.

    Переносу на соседнюю машину - да, подлежать совсем не будет, потому что зависит от хз какой libgcc_s и еще аллах ведает, чего. Но пользователю - оно и  не надо. А непользователь говорит "дурак я, что-ли, на своем ноуте ЭТО делать, он же греется и руки обжигает", и делает push. Там за него само все соберется и результат пришлет.


    > Впрочем, при необходимости полностью выпилить gnu-стек и докер не сильно помогает.

    а его пока и нельзя выпилить полностью - даже если кому-то повезло с платформой, и он может обойтись без gnu ld (freebsd вот - пока не может, не смотря на все старания), без прослойки совместимости в трансляторе - не обойдешься в любом случае (то есть те же gcc_s и прочее все равно притащит) - ну и было бы тогда, за что бороться?

     
  • 6.41, Ne01eX (ok), 11:56, 15/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > эта магия просто не для вас предназначена, а для обычного пользователя -
    > которому нужно чтобы инструмент просто работал, собирая здесь и сейчас -
    > и не ломался о модуль, собранный рядомстоящим компиляторами.
    > а разработчиков, вместо билдхоста собирающих что-то даже для тестов на собственной хз
    > как хз для чего настроенной системе - надо давить поганым давилом.
    > (потому что дальше начинаются докеры, полная операционная система внутри пакета, и прочий
    > мусор вида "у меня на домашнем ноуте все работает, сделайте мне!"
    > )
    >> Причём даже нельзя угадать из какой именно из установленных в системе версий gcc утянет.
    > можно. просто вы не умеете. И низачем не нужно.

    Что самое, сцуко пародоксальное, то бардак в дистрибутивах наблюдается только в RPM-based. И частично в бубунте с дебиан. И почти никак в Slackware. Другими словами, - всё зависит от вендоров. Как правило, - чем жирнее дистрибутив, тем больше хаоса. Тем нужнее LXC и.т.п.

    Впрочем, непосредственно с компиляторами это никак не связано.

     

  • 1.29, Fleonis (?), 01:19, 10/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я что то не смог найти ничего по поводу оператора <=> . кто знает, поясните пожлуйста.
     
     
  • 2.30, Аноним84701 (ok), 01:58, 10/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Я что то не смог найти ничего по поводу оператора <=> . кто знает, поясните пожлуйста.

    http://en.cppreference.com/w/cpp/language/operator_comparison
    [CODE]

    Three-way comparison
    The three-way comparison operator expressions have the form
    lhs <=> rhs (1)
    The expression returns an object such that
    (a <=> b) < 0 if lhs < rhs
    (a <=> b) > 0 if lhs > rhs
    (a <=> b) == 0 if lhs and rhs are equal/equivalent.[/CODE]

     

  • 1.36, Аноним (-), 09:56, 11/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Больше шланга, хорошего и разного. А гадкое гнутое гцц выкинуть!
     
  • 1.42, Ne01eX (ok), 12:45, 15/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Где-то в соседней теме какой-то умник кричал, что дескать с помощью clang можно собрать gcc. Несколько лет назад я пробовал собрать этот набор компиляторов (gcc) с помощью clang, но не взлетело. В этот раз, исключительно just for fun озадачился сборкой gcc-7.3.0 с помощью clang clang++.

    Собственно, я и не ожидал что сборка зайдёт дальше непосредственно gcc и g++, но clang не смог сделать даже это.

    Пробовал с llvm-6.0.0 на x86_64 и i586. Чуть попозже попробую ещё раз, подойдя более серъёзно (реально интересует такая возможность).

    Ну и пока что... Я, опять же, just for fun попробовал сравнить эффективность сборки (размер ELF и его производительность) gcc/g++ и clang/clang++ около 20 пакаджей (с флажками -O2 и -O3, всего по четыре каждого для двух платформ - i586 и x86_64). Чё-то всё пока не пользу clang. Опять же, - [b]меня слабо интересуют искусственные попугаи, мне реально интересно, где использование clang/clang++ даст хоть какой-то плюс. Пускай это будет даже +1% по производительности и -1% по объёму. Может подскажете такое ПО?[/b] :-)

    Интереса для попробую с -Ofast (это -O3 -ffast-math -fno-protect-parens -fstack-arrays). То что gcc это умеет, я не сомневаюсь. Умеет ли так clang?

    P.S. clang++ заваливается на сборке mariadb (хотя, теоретически не должен). Кто-нибудь собирал им mariadb 10.2.13 или 10.3.5 [b]с полным набором плагинов[/b]. Особенно интересуют плагины [b]rocksdb (собранный с jemalloc и zstd)[/b] и [b]tokudb[/b]. :-) У кого-нибудь получалось их собрать clang++?

     
     
  • 2.43, Andrey Mitrofanov (?), 11:19, 16/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Где-то в соседней теме какой-то умник кричал, что дескать с помощью clang
    > можно собрать gcc. Несколько лет назад я пробовал собрать этот набор
    >компиляторов (gcc) с помощью clang, но не взлетело.

    "Обычно" неродным компилятором собирают только stage1 gcc
       https://gcc.gnu.org/install/build.html
    - бутстрапят из другого компилятора, а не билдят целиком.

    С т.з. банальной эрудиции, FreeBSD, собирающая базу с системным clang, _должна_ же [успешно] собирать gcc-[67890] в портах системным clang-ом. Хотя они и "второй системный" gcc-4.2.1 попользуют -- недорого возьмут.

    ...а вот же, например:
       https://gcc.gnu.org/ml/gcc/2015-05/msg00028.html
       https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00973.html
       https://gcc.gnu.org/ml/gcc/2014-10/msg00269.html
    и далее https://duckduckgo.com/?q=with+clang+bootstrap+site:gcc.gnu.org/ml%2F везде.

    Для fun-а
       https://duckduckgo.com/?q=diverse+double+compilation
       https://www.schneier.com/blog/archives/2006/01/countering_trus.html
    //
       https://lists.gnu.org/archive/html/guile-user/2017-11/msg00040.html

     
     
  • 3.44, Ne01eX (ok), 12:15, 16/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > ...а вот же, например:
    >    https://gcc.gnu.org/ml/gcc/2015-05/msg00028.html
    >    https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00973.html
    >    https://gcc.gnu.org/ml/gcc/2014-10/msg00269.html
    > и далее https://duckduckgo.com/?q=with+clang+bootstrap+site:gcc.gnu.org/ml%2F везде.
    > Для fun-а
    >    https://duckduckgo.com/?q=diverse+double+compilation
    >    https://www.schneier.com/blog/archives/2006/01/countering_trus.html
    > //
    >    https://lists.gnu.org/archive/html/guile-user/2017-11/msg00040.html

    Вообще в точку попал, спасибо! По предпоследней ссылке: Там чувак (Dan) в комментах в одном абзаце всю статью рассказал (мне понравился коммент как пример лаконичности). :-)

     
     
  • 4.45, Andrey Mitrofanov (?), 13:23, 16/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>    https://www.schneier.com/blog/archives/2006/01/countering_trus.html
    >> //
    >>    https://lists.gnu.org/archive/html/guile-user/2017-11/msg00040.html
    > Вообще в точку попал, спасибо! По предпоследней ссылке: Там чувак (Dan) в
    > комментах в одном абзаце всю статью рассказал (мне понравился коммент как
    > пример лаконичности). :-)

    Самый фан в --

    [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

    -- то есть либо оба норм, либо оба прохаканы, но одинаково. Мы можем только гадать, но отметаем неудобный вариант, как ... маловероятный.

    Наука!

    Wheeler trick обходит _это_ с "completely independent compilers: A and T" -- независимы настолько, что одного хака в двух быть не может.

    ...
    У автора Mes более надёжный подход: исходим не из 2ух недоверенных компилеров, а пишем минимальный, маленький и обозримый в одно лицо компилятор, достаточный и работоспособный только на ... stage1 gcc или tinycc, достаточный для сборки stage1 gcc.

    И кста, твой комментатор исходил из "имеем исходники gcc, которым не доверяем" и совсем не отразил это (=что мы не читаем исходники и не знаем, не лежит ли хак в них) в гадальной части, типа: ...или хак находится в недоверенных исходниках, или его там нет.

    А у тов.Wheeller-а про _недоверие_ таки именно к исходникам gcc не было: он-то ловит "самораспространяющийся хак (патченную сборку) бинарника", не _обсуждая_ хаки в исходниках. В отличие "упростившего всё" от комментатора Dan.

     
     
  • 5.46, Ne01eX (ok), 14:18, 16/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > а пишем минимальный, маленький и обозримый в одно лицо компилятор, достаточный
    > и работоспособный только на ... stage1 gcc или tinycc, достаточный для
    > сборки stage1 gcc.
    > И кста, твой комментатор исходил из "имеем исходники gcc, которым не доверяем"
    > и совсем не отразил это (=что мы не читаем исходники и
    > не знаем, не лежит ли хак в них) в гадальной части,
    > типа: ...или хак находится в недоверенных исходниках, или его там нет.
    > А у тов.Wheeller-а про _недоверие_ таки именно к исходникам gcc не было:
    > он-то ловит "самораспространяющийся хак (патченную сборку) бинарника", не _обсуждая_
    > хаки в исходниках. В отличие "упростившего всё" от комментатора Dan.

    Ладно, лирика это всё. На практике тому же gcc абсолютно всё равно какие флаги используются в stage1. Он всё равно напихает своих при конфигурации. О какой повторяемости результата stage1/stage2 вообще тогда может быть и речь?

    Короче вечером попробую повторить, собрав только базовую инфраструктуру и Си компилятор.

    Пока у меня отдельно шуршит сборка gcc-7_20180315.

    clang пока тихо дожидается своего часа =)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру