The OpenNET Project / Index page

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



"Релиз набора компиляторов LLVM 6.0"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от opennews on 09-Мрт-18, 00:01 
После шести месяцев разработки представлен (http://lists.llvm.org/pipermail/llvm-announce/2018-March/000...) релиз проекта LLVM 6.0 (http://llvm.org/) (Low Level Virtual Machine) - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы.

Напомним, что в соответствии с  новой нумерацией версий (https://www.opennet.ru/opennews/art.shtml?num=45690) осуществлён уход от разделения значительных и функциональных выпусков. В каждом функциональном обновлении теперь меняется первая цифра (например, осенью состоится релиз 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",  добавление новых предупреждений компилятора.


Улучшения (http://releases.llvm.org/6.0.0/tools/clang/docs/ReleaseNotes...) в Clang 6.0:

-  В качестве диалекта языка C++ по умолчанию установлен gnu++14 ("-std=gnu++14") вместо ранее применявшегося  gnu++98 ("-std=gnu++98"), что позволяет по умолчанию компилировать код, в котором присутствуют возможности, определённые в стандарте C++14 (https://www.opennet.ru/opennews/art.shtml?num=40408), включая специфичные расширения GNU;
-  Добавлены некоторые возможности, развиваемые для будущего стандарта C++20 (кодовое название C++2a):  


-  Макрос __VA_OPT__ для адаптивного раскрытия вариативных макросов в зависимости от наличия токенов в вариативном аргументе;
-  Поддержка оператора "‹=›" для трехстороннего сравнения;
-  Поддержка инициализаторов элементов по умолчанию  для битовых полей;
-  Возможность лямбда-захвата выражений "*this";
-  Вызов элементов по указателю (Pointer-to-member), используя определённые через выражение "const &" указатели на временные объекты;
-  Оператор delete с деструктором, описанный в документе P0722R1 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p072...), но пока не одобренный для включения в спецификацию  C++2a;


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


-  Для блокирования в приложениях второго варианта уязвимости Spectre (CVE-2017-5715) в состав включён механизм Retpoline (https://support.google.com/faqs/answer/7625886),
основанный на применении специальной последовательности инструкций, исключающей вовлечение механизма спекулятивного выполнения для косвенных переходов (использование инструкции RET вместо JMP). Включение защиты осуществляется при помощи флага "-mretpoline" или "-mretpoline-external-thunk" при необходимости более тонкой настройки работы Retpoline;

-  Добавлена поддержка конфигурационных файлов, в которых можно размещать коллекции из применяемых при сборке опций. Для использования настроек из файла конфигурации можно использовать опцию "--config foo.cfg" или создать исполняемый файл вида "foo-clang". Перечисленные в файле конфигурации опции включаются до опций, перечисленных в командной строке. Основным назначением файлов конфигурации является упрощение организации кросс-компиляции;

-  Добавлены новые флаги "-fdouble-square-bracket-attributes" и "-fno-double-square-bracket-attributes" для включения и выключения атрибутов (http://releases.llvm.org/6.0.0/tools/clang/docs/AttributeRef...), задаваемых в двойных квадратных скобках, в любых языковых режимах;
-  Для обеспечения совместимости с GCC добавлены языковые режимы "-std=c17", "-std=gnu17" и "-std=iso9899:2017" для включения поддержки нового стандарта языка Си. Режимы c17  и c11 отличаются только значением макроса __STDC_VERSION__, так как в новой спецификации отмечается только исправление ошибок;
-  Добавлены флаги "-fexperimental-isel" и "-fno-experimental-isel" для включения и выключения нового фреймворка выбора инструкций GlobalISel (https://llvm.org/docs/GlobalISel.html). Данный фреймворк включен по умолчанию  для архитектуры 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 (https://www.opennet.ru/opennews/art.shtml?num=41188), так как данный форк воссоединился с 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 добавлена (http://releases.llvm.org/6.0.0/tools/clang/tools/extra/docs/...) большая порция новых проверок и обеспечена поддержка стандарта кодирования  High Integrity C++ Coding Standard (http://www.codingstandard.com/section/index/);
-   Добавлен минимальный runtime для компонента UBSan (Undefined Behavior Sanitizer) с реализацией детектора неопределенного поведения (http://ru.wikipedia.org/wiki/%D0%9D%D0%B...), выявляющего во время выполнения программы ситуации, когда поведение программы становится неопределенным. Runtime предоставляет только простые функции ведения лога событий во время выполнения и дедупликацию выводимых в лог записей ("-fsanitize=vptr" не поддерживается).


Основные новшества (http://llvm.org/releases/6.0....

URL: http://lists.llvm.org/pipermail/llvm-announce/2018-March/000...
Новость: https://www.opennet.ru/opennews/art.shtml?num=48223

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Релиз набора компиляторов LLVM 6.0"  +9 +/
Сообщение от Named on 09-Мрт-18, 00:01 
> В каждом функциональном обновлении теперь меняется первая цифра...  корректирующие обновления, как и раньше приводят к увеличению третьей цифры.

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от Аноним (??) on 09-Мрт-18, 01:09 
> Непонятно, зачем в последнее время многие переходят на такую нумерацию.

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

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

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Релиз набора компиляторов LLVM 6.0"  +5 +/
Сообщение от YetAnotherOnanym (ok) on 09-Мрт-18, 02:00 
> Глобальных изменений в софте больше не происходит

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

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

8. "Релиз набора компиляторов LLVM 6.0"  –2 +/
Сообщение от Аноним (??) on 09-Мрт-18, 09:12 
> Уверен, через какое-то время от второй цифры тоже избавятся: будут просто брать последний коммит в нужной ветке

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

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

23. "Релиз набора компиляторов LLVM 6.0"  –1 +/
Сообщение от Аноним (??) on 09-Мрт-18, 17:02 
> Последний коммит - это тоже слишком сложно.
> Просто перейдут на блокчейны и смарт-контракты - все станет просто и понятно.

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

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

27. "Релиз набора компиляторов LLVM 6.0"  +4 +/
Сообщение от Аноним (??) on 09-Мрт-18, 20:03 
>блокчейны и смарт-контракты

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

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

6. "Релиз набора компиляторов LLVM 6.0"  +1 +/
Сообщение от Тот_Самый_Анонимус on 09-Мрт-18, 06:09 
Первое число — на ветку с длительным сроком поддержки. Второе — на выпуски между первыми ветками, третье — на исправления.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

11. "Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от пох on 09-Мрт-18, 09:26 
> Непонятно, зачем в последнее время многие переходят на такую нумерацию.

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

14. "Релиз набора компиляторов LLVM 6.0"  +2 +/
Сообщение от Аноним (??) on 09-Мрт-18, 10:08 
> есть же четкая схема: первая цифра - значительные функциональные изменения (возможно, с нарушением обратной совместимости), вторая - изменения с обеспечением совместимости, 3-я - багфиксы.

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

15. "Релиз набора компиляторов LLVM 6.0"  +6 +/
Сообщение от Аноним (??) on 09-Мрт-18, 11:33 
И поэтому программы превращаются в непрерывную недоделку.
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

22. "Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от Nexmean on 09-Мрт-18, 16:46 
То ли дело было раньше, пусть программа и была недоделкой, зато дискретной!
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

25. "Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от Аноним (??) on 09-Мрт-18, 17:19 
> И поэтому программы превращаются в непрерывную недоделку.

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

2. "Релиз набора компиляторов LLVM 6.0"  –14 +/
Сообщение от Гоги on 09-Мрт-18, 00:01 
LLVM так хорошо развивается, что уже два раза почешешь репу, подо что писать новый язык - под дотнет (с кучей готовых либ) или нэтив, но зато с полным гемороем по написанию ВСЕГО.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

28. "Релиз набора компиляторов LLVM 6.0"  –1 +/
Сообщение от Вареник on 09-Мрт-18, 20:58 
Для аппликух есть .NET и JDK.

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

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "Релиз набора компиляторов LLVM 6.0"  –1 +/
Сообщение от leap42 (ok) on 09-Мрт-18, 02:13 
> Добавлена предварительная поддержка санитайзеров (ASan, UBsan, те, которых никто не знает)

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Релиз набора компиляторов LLVM 6.0"  +7 +/
Сообщение от Аноним (??) on 09-Мрт-18, 13:33 
>Поддержка оператора "‹=›" для трехстороннего сравнения;

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

31. "Релиз набора компиляторов LLVM 6.0"  +1 +/
Сообщение от 0xd34df00d (??) on 10-Мрт-18, 05:25 
Вам так нравится писать от 6 до бесконечности операторов сравнения руками?
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

33. "Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от Аноним (??) on 10-Мрт-18, 22:56 
А как это должно уменьшить объём писанины?
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;
}

Единственное "достоинство" — выглядит не по-сишному.
Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

34. "Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от 0xd34df00d (??) on 10-Мрт-18, 23:50 
Это уменьшает объём писанины в первую очередь для автора класса, а не для клиента. Для кучи практически полезных случаев компилятор способен сгенерировать определение оператора (и всех выражающихся через него) сам. Можно посмотреть в пропозалах или на cppreference ( http://en.cppreference.com/w/cpp/language/default_comparisons ) подробнее.

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

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

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

37. "Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от Аноним (??) on 11-Мрт-18, 12:33 
Ну ок, убедил.
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

39. "Релиз набора компиляторов LLVM 6.0"  –1 +/
Сообщение от Аноним (??) on 11-Мрт-18, 18:20 
> Где бы это было полезно в чистом клиентском коде, я сходу не могу придумать.

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

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

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

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

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

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

19. "Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от Iaaa (ok) on 09-Мрт-18, 14:31 
> По умолчанию в исполняемые файлы теперь добавляется секция ".init_array", если в системе не установлен GCC. Если наличие GCC обнаружено и версия старее 4.7.0, то как и раньше подставляется секция ".ctors";

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от Аноним (??) on 09-Мрт-18, 15:08 
Ты бы почитал про .init_array сначала, прежде чем чушь писать.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

21. "Релиз набора компиляторов LLVM 6.0"  +3 +/
Сообщение от Iaaa (ok) on 09-Мрт-18, 15:14 
У анонима, как обычно, апломба вагон и знаний тележка.

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

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

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

24. "Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от Аноним (??) on 09-Мрт-18, 17:17 
Костылестроение во все поля...
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

32. "Релиз набора компиляторов LLVM 6.0"  +1 +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 10-Мрт-18, 18:17 
+1. Вообще эта магия внутри шланга с gcc подзадалбывает. Развернули у нас на производстве, понимаешь, clang вместо gcc и его стандартной библиотеки. Так этот грёбанный clang, как его не корми опциями, всё равно время от времени умудряется отыскать в системе gcc и что-то из него утянуть. Причём даже нельзя угадать из какой именно из установленных в системе версий gcc утянет.
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

35. "Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от пох on 11-Мрт-18, 09:48 
> Вообще эта магия внутри шланга с gcc подзадалбывает.

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

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

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

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

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

38. "Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от Аноним (??) on 11-Мрт-18, 12:39 
> а разработчиков, вместо билдхоста собирающих что-то даже для тестов на собственной хз
> как хз для чего настроенной системе - надо давить поганым давилом.

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

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

40. "Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от пох on 13-Мрт-18, 15:20 
> Вот я даже не представляю, как при таком поведении компилятора можно собрать что-то без помощи
> докера

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

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


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

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

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

29. "Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от Fleonis on 10-Мрт-18, 01:19 
Я что то не смог найти ничего по поводу оператора <=> . кто знает, поясните пожлуйста.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

30. "Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от Аноним84701 (ok) on 10-Мрт-18, 01:58 
> Я что то не смог найти ничего по поводу оператора <=> . кто знает, поясните пожлуйста.

http://en.cppreference.com/w/cpp/language/operator_comparison

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.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

36. "Релиз набора компиляторов LLVM 6.0"  +/
Сообщение от Аноним (??) on 11-Мрт-18, 09:56 
Больше шланга, хорошего и разного. А гадкое гнутое гцц выкинуть!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Что-то пока не фонтан этот clang/clang++ :-("  +/
Сообщение от Ne01eX (ok) on 15-Мрт-18, 12:45 
Где-то в соседней теме какой-то умник кричал, что дескать с помощью 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. Опять же, - меня слабо интересуют искусственные попугаи, мне реально интересно, где использование clang/clang++ даст хоть какой-то плюс. Пускай это будет даже +1% по производительности и -1% по объёму. Может подскажете такое ПО? :-)

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

43. "Что-то пока не фонтан этот clang/clang++ :-("  +1 +/
Сообщение от Andrey Mitrofanov on 16-Мрт-18, 11:19 
> Где-то в соседней теме какой-то умник кричал, что дескать с помощью 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.... везде.

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

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

44. "Что-то пока не фонтан этот clang/clang++ :-("  +/
Сообщение от Ne01eX (ok) on 16-Мрт-18, 12:15 
>[оверквотинг удален]
> ...а вот же, например:
>    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.... везде.
> Для fun-а
>    https://duckduckgo.com/?q=diverse+double+compilation
>    https://www.schneier.com/blog/archives/2006/01/countering_tr...
> //
>    https://lists.gnu.org/archive/html/guile-user/2017-11/msg000...

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

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

45. "Что-то пока не фонтан этот clang/clang++ :-("  +/
Сообщение от Andrey Mitrofanov on 16-Мрт-18, 13:23 
>>    https://www.schneier.com/blog/archives/2006/01/countering_tr...
>> //
>>    https://lists.gnu.org/archive/html/guile-user/2017-11/msg000...
> Вообще в точку попал, спасибо! По предпоследней ссылке: Там чувак (Dan) в
> комментах в одном абзаце всю статью рассказал (мне понравился коммент как
> пример лаконичности). :-)

Самый фан в --

" 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) " --https://www.schneier.com/blog/archives/2006/01/countering_tr...

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

Наука!

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

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

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

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

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

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

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

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

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

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

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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