The OpenNET Project / Index page

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

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

03.05.2019 23:31

После года разработки опубликован релиз свободного набора компиляторов GCC 9.1, первый значительный выпуск в новой ветке GCC 9.x. В соответствии с новой схемой нумерации выпусков, версия 9.0 использовалась в процессе разработки, а незадолго до выхода GCC 9.1 уже ответвилась ветка GCC 10.0, на базе которой будет сформирован следующий значительный релиз GCC 10.1.

GCC 9.1 примечателен стабилизацией поддержки стандарта C++17, продолжением реализации возможностей будущего стандарта C++20 (кодовое название C++2a), включением в состав фронтэнда для языка D, частичным обеспечением поддержки OpenMP 5.0, почти полной поддержкой OpenACC 2.5, увеличением масштабируемости межпроцедурных оптимизаций и оптимизаций на этапе связывания, расширением средств диагностики и добавлением новых предупреждений, бэкендами для OpenRISC, C-SKY V2 и AMD GCN GPU .

Основные изменения:

  • Добавлена поддержка языка программирования D. В основной состав GCC включены фронтэнд с компилятором GDC (GNU D Compiler) и runtime-библиотеки (libphobos), которые позволяют использовать штатный GCC для сборки программ на языке программирования D. Процесс включения поддержки языка D в GCC начался ещё в 2011 году, но затянулся из-за необходимости приведения кода к соответствию требованиям GCC и проблем с передачей прав на интеллектуальную собственность компании Digital Mars, развивающей язык программирования D;
  • Внесены улучшения в генератор кода. Например, реализовано применение разных стратегий раскрытия выражений Switch (jump table, bit test, decision tree) в зависимости от ситуаций. Добавлена возможность трансформации линейных функций, включающих выражение Switch, с использованием оптимизации "-ftree-switch-conversion" (например, конструкция вида "case 2: how = 205; break; case 3: how = 305; break;" будет преобразована в "100 * how + 5";
  • Улучшены межпроцедурные оптимизации. Настройки inline-развёртывания адаптированы для современных кодовых баз на C++ и расширены новыми параметрами max-inline-insns-small, max-inline-insns-size, uninlined-function-insns, uninlined-function-time, uninlined-thunk-insns и uninlined-thunk-time. Повышена точность и агрессивность разделения "холодного" и "горячего" кода. Улучшена масшабируемость для очень больших единиц трансляции (например, при применении оптимизации на этапе связывания к большим программам);
  • Улучшен механизм оптимизации на основе результатов профилирования кода (PGO - Profile-guided optimization), который генерирует более оптимальный код на основе анализа особенностей выполнения кода. Сводная опция "-fprofile-use" теперь включает режимы оптимизации "-fversion-loops-for-strides", "-floop-interchange", "-floop-unroll-and-jam" и "-ftree-loop-distribution". Удалено включение в файлы гистограмм со счётчиками, что позволило сократить размер файлов с профилями (гистограммы теперь генерируются на лету при выполнении оптимизаций во время связывания);
  • Расширены оптимизации на этапе связывания (LTO). Обеспечено упрощение типов перед генерацией результата, что позволило существенно сократить размер объектных файлов LTO, уменьшить потребление памяти на этапе связывания и улучшить распараллеливание операций. Число разделов по умолчанию (--param lto-partitions) увеличено с 32 до 128, что повысило эффективность работы на системах с большим числом потоков в CPU. Для управления числом процессов оптимизатора добавлен параметр "--param lto-max-streaming-parallelism";

    В итоге, по сравнению с GCC 8.3 внесённые в GCC 9 оптимизации позволили примерно на 5% сократить время компиляции Firefox 66 и LibreOffice 6.2.3. Размер объектных файлов снизился на 7%. Время связывания на 8-ядерном CPU уменьшилось на 11%. Последовательная стадия оптимизации на этапе связывания теперь выполняется на 28% быстрее и потребляет на 20% меньше памяти. Потребление памяти каждого обработчика распараллеливаемой стадии LTO снизилось на 30%;

  • Для языков C, C++ и Fortran реализована бо́льшая часть спецификации параллельного программирования OpenACC 2.5, определяющей средства для выноса операций (offloading) на GPU и специализированные процессоры, такие как NVIDIA PTX;
  • Для С и С++ реализована частичная поддержка стандарта OpenMP 5.0 (Open Multi-Processing), определяющего API и способы применения методов параллельного программирования для языков Си, Си++ и Фортран на многоядерных и гибридных (CPU+GPU/DSP) системах с общей памятью и блоками векторизации (SIMD);
  • Для языка Си добавлены новые предупреждения: "-Waddress-of-packed-member" (невыравненное значение указателя на упакованный элемент структуры или объединения) и "-Wabsolute-value" (при обращении к функциям вычисления абсолютного значения, если для указанного аргумента имеется более подходящая функция, например, вместо abs(3.14) следует использовать fabs(3.14)). Для C++ добавлены новые предупреждения: "-Wdeprecated-copy", "-Winit-list-lifetime", "-Wredundant-move", "-Wpessimizing-move" и "-Wclass-conversion". Расширены многие ранее доступные предупреждения;
  • Добавлена экспериментальная поддержка части будущего стандарта языка Си, развиваемого под кодовым именем C2x. Для включения поддержки C2x следует использовать опции "-std=c2x" и "-std=gnu2x" (для включения расширений GNU). Стандарт пока на ранней стадии развития, поэтому из его возможностей поддерживается только выражение _Static_assert с одним аргументом (_Static_assert c двумя аргументами стандартизировано в C11);
  • Объявлена стабильной поддержка стандарта C++17. Во фронтэнде языковые возможности C++17 реализованы полностью, а в libstdc++ определённые в стандарте библиотечные функции близки к полной реализации;
  • Продолжена реализация элементов будущего стандарта C++2a. Например, добавлена возможность включения диапазонов при инициализации, реализованы расширения для лямбда-выражений, добавлена поддержка пустых членов структур данных и атрибутов likely/unlikely, обеспечена возможность вызова виртуальных функций в условных выражениях и т.п. Для включения поддержки C++2a следует использовать опции "-std=c++2a" и "-std=gnu++2a". В libstdc++ для C++2a добавлены заголовочные файлы bit и version, типажи std::remove_cvref, std::unwrap_reference, std::unwrap_decay_ref, std::is_nothrow_convertible и std::type_identity, функции std::midpoint, std::lerp, std::bind_front, std::visit, std::is_constant_evaluated и std::assume_aligned, добавлена поддержка типа char8_t, реализована возможность проверки префикса и суффикса строк (starts_with, ends_with);
  • Добавлена поддержка новых процессоров ARM Cortex-A76, Cortex-A55, Cortex-A76 DynamIQ big.LITTLE и Neoverse N1. Добавлена поддержка появившихся в Armv8.3-A инструкций для работы с комплексными числами, генерации псевдослучайных чисел (rng) и теггирования памяти (memtag), а также инструкций для блокирования атак, связанных со спекулятивным выполнением и работой блока предсказания переходов. Для архитектуры AArch64 добавлен режим защиты от пересечения стека и кучи ("-fstack-clash-protection"). Для использования особенностей архитектуры Armv8.5-A добавлена опция "-march=armv8.5-a"
  • В состав включён бэкенд для генерации кода для GPU AMD на базе микроархитектуры GCN. Реализация пока ограничена компиляцией однопоточных приложений (поддержка выноcа многопоточных вычислений через OpenMP и OpenACC будет предложена позднее) и поддержкой GPU Fiji и Vega 10;
  • Добавлен новый бэкенд для процессоров OpenRISC;
  • Добавлен бэкенд для процессоров C-SKY V2, выпускаемых одноимённой китайской компанией для различных потребительских устройств;
  • Во всех опциях командной строки, оперирующих байтовыми значениями, обеспечена поддержка суффиксов kb, KiB, MB, MiB, GB и GiB;
  • Реализована опция "-flive-patching=[inline-only-static|inline-clone]", позволяющая добиться безопасной компиляции для систем горячего наложения патчей (live-patching) за счёт многоуровневого управления применением межпроцедурных (IPA) оптимизаций;
  • Добавлена опция "--completion" для тонкого управления автодополнением опций при использовании bash;
  • В средствах диагностики обеспечено отображение отрывков исходных текстов с указанием номера строки и с наглядной пометкой сопутствующей информации, такой как типы операндов. Для отключения вывода номеров строк и меток предусмотрены опции "-fno-diagnostics-show-line-numbers" и "-fno-diagnostics-show-labels";
  • Расширены инструменты для диагностики ошибок в коде на C++, улучшена читаемость сведений о причинах ошибок и подсветка проблемных параметров;
  • Добавлена опция "-fdiagnostics-format=json", позволяющая формировать диагностический вывод в машиночитаемом формате (JSON);
  • Добавлены новые опции профилирования "-fprofile-filter-files" и "-fprofile-exclude-files" для выбора обрабатываемых файлов с исходными текстами;
  • В AddressSanitizer обеспечена генерация более компактного проверочного кода для автоматических переменных, что позволило снизить потребление памяти проверяемым исполняемым файлом;
  • Улучшен вывод в режиме "-fopt-info" (детализация информации о добавленных оптимизациях). Добавлены новые префиксы "optimized" и "missed", помимо ранее доступного префикса "note". Добавлен вывод сведений о принятии решения по inline-развёртыванию и векторизации циклов;
  • Добавлена опция "-fsave-optimization-record", при указании которой GCC сохраняет файл SRCFILE.opt-record.json.gz с описанием решений по применению тех или иных оптимизаций. От режима "-fopt-info" новая опция отличается включением дополнительных метаданных, таких как информация о профиле и inline-цепочках;
  • Добавлены опции "-fipa-stack-alignment" и "-fipa-reference-addressable" для управления при межпроцедурных оптимизациях выравниванием стека и применением режимов адресации (только запись или точно чтение) для статических переменных;
  • Представлены новые встроенные функции для управления привязкой атрибутов, а также поведением, связанным с предсказанием переходов и спекулятивным выполнением инструкций: "__builtin_has_attribute", "__builtin_expect_with_probability" и "__builtin_speculation_safe_value". Для функций, переменных и типов добавлен новый атрибут copy;
  • Для языка Fortran реализована полноценная поддержка асинхронного ввода/вывода;
  • Объявлена устаревшей и будет удалена в следующем значительном выпуске поддержка платформ Solaris 10 (*-*-solaris2.10) и Cell/B.E (Cell Broadband Engine SPU). Прекращена поддержка архитектур Armv2, Armv3, Armv5 и Armv5E. Прекращена поддержка расширения Intel MPX (Memory Protection Extensions).


  1. Главная ссылка к новости (https://gcc.gnu.org/ml/gcc-ann...)
  2. OpenNews: Влияние несущественных изменений кода на производительность при использовании GCC
  3. OpenNews: Релиз набора компиляторов GCC 8
  4. OpenNews: Компания AMD выпустила оптимизирующий C/C++ компилятор AOCC 1.2
  5. OpenNews: Открыт код C++ компилятора Zapcc
  6. OpenNews: Релиз набора компиляторов LLVM 8.0
Лицензия: CC-BY
Тип: Интересно / Программы
Ключевые слова: gcc, compile
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (64) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, пгуыыцрщ (?), 01:22, 04/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ммм, а -fipa-pta так и не починили?
     
  • 1.2, старик (?), 01:36, 04/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Кхх гм ну что ж хорошая новость.Сейчас перекомпилирую 1041 исходный текст.Жаль только что опять OpenACC ни как а я уж по старости своей наивной понадеился на свою rx580 заместо процессора.  
     
     
  • 2.4, A.Stahl (ok), 04:28, 04/05/2019 [^] [^^] [^^^] [ответить]  
  • +15 +/
    >ни как, понадеился, заместо

    Ух!

     
     
  • 3.5, Аноним (5), 05:39, 04/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    стухл
     
     
  • 4.37, Аноним (37), 06:20, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    мда, чую как корабль назовешь так оно и поплывет
    еще не допилили, а уже сТУх
     
  • 2.8, Аноним (8), 11:08, 04/05/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >реализована бо́льшая часть спецификации параллельного программирования OpenACC 2.5

    Эх, старик, трах тебя тибедох. (C) Прочитай новость в более сильных очках.

     

  • 1.3, Аноним (3), 03:23, 04/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А что там в C2k нового? Какие интересности завезли?
     
     
  • 2.7, Аноним (7), 08:26, 04/05/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    utf8, constexpr, auto.
     
     
  • 3.9, Аноним (8), 11:11, 04/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    constexpr и auto уже в 11-м были, не?
     
     
  • 4.10, An0Nm (?), 11:15, 04/05/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    C2x это сишный стандарт.
     
  • 4.11, Аноним (11), 11:26, 04/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В плюсах были, в C нет.
     
  • 2.40, Аноним (40), 09:26, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Долбо* неразличающий сиплюсплюс и чистый си
     

  • 1.6, Аноним (6), 06:41, 04/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Печально, но в OBS-репозитории devel:gcc/SLE_11 его уже не будет. Из-за прекращения основной поддержки. А жаль. Было очень удобно использовать компилятор оттуда для билд-фермы. А devtoolset для CentOS не настолько удобный
     
  • 1.12, Crazy Alex (ok), 14:44, 04/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    D и бэкэнды для AMD GPU и OpenRISC? Добротный релиз, ничего не скажешь
     
  • 1.13, старик2 (?), 18:03, 04/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ну все перекомпилировал не собрался qtcore-5.11.2.А 1040 текстов собралось без проблем пока глюков программ нет.COMMON_FLAGS="-march=native -O2 -fgraphite -fgraphite-identity -floop-interchange -floop-nest-optimize -ftree-loop-distribution -fomit-frame-pointer -pipe"Правда долго очень процессор у меня очень стар как и я тоже.FX-9590 DDR3-2133 asus-V-Formula-Z. 14 часов ушло наверно тротлил хад.
     
     
  • 2.14, Аноним (14), 20:59, 04/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Только qt с графитом потом рандомно крашится и зависает, в кедах особенно классно сидеть. И вообще фигня, ни одна программа не показала выигрыша в производительности с ним. Лто хотя бы бинарники меньше делает, для плюсовых программ хорошо. А вот пго топчик, оптимизирует без заморочек написанный код (ручками можно того же добиться).

    Короче, отключайте всю эту дpянь.

     
     
  • 3.36, пгуыыцрщ (?), 00:47, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не надо обобщать. У меня не крашится например.
    Может дело в кедах?
     

  • 1.15, старик2 (?), 23:13, 04/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Хмм возможно и так но проблем с крашами не наблюдал ну скорее всего нет большого количества специфичных программ для серьезной работы где нужна стабильность.Так себе небольшой сервер и мультимедиа десктоп.Да конечно в продакшен с такими флагами ни ни согласен.А лто да еще года четыре назад юзал сравнивал размер бинарников ну и т.д.Главная проблема лто в роллинг бэйс операционках (при обновленнии системы)это изменение версий программ и их кода что ведет по моему опыту к неработоспособности и глюкам программ так как слетает линковка всяких там библиотек или удаление из исходника того что должно работать с другой частью зависимого кода glibc например что и приводит в итоге к глючному бинарнику.Вот как пример собрал не давно лису с лто -march=native -02 и gold линкером (ни какого хардкора)и что в лисе перестал сохранятся масштаб текста и всего отображаемого на странице выставлял +200% при перезагрузке браузера опять 100% -это нужно для больших экранов при просмотре с расстояния чтоб увеличить размер всего на странице.По моему скромному мнению лто хорош на специальных проектах собрал и забыл.Да конечно есть автоматизированный си-ай интегрейшн но это работает в конторах (постоянная сборка пересборка мержка и т.д)а дома лто ну его нафиг нет времени разбираться в багах и зависимостях денег за это не заплатят а система упадет.  
     
  • 1.16, старик2 (?), 23:37, 04/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Гм с профилированием PGO надо по думать.Только оно т.е пго для для небольшого количества программ предназначено (ну в gentoo например).Да предполагаю что любой код можно профилировать но это надо вносить изменения в средство разработки или в билды и т.д.Да и с сценарием работы кода тоже не ясно какая последовательность выполнения модулей блоков алгоритмов чаще выполняется.Набрать статистику работы можно но это не решает всех возможных вариантов работы программы.Так что вопросов очень много.Возможно надо придерживаться золотой середины.  
     
  • 1.17, старик2 (?), 23:59, 04/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Да и с графитом не понятно я не кодер.Какие циклы в каком коде если С++ как часто повторяются и есть ли смысл их обьеденять сокращать и т.д  что это даст?
     
  • 1.18, Аноним (18), 11:32, 05/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    >case 2: how = 205; break; case 3: how = 305; break;

    Это - говнокод, оптимизировать его так смысла не имеет. Имеет смысл уволить того, кто такое пишет, так как оптимизированный компилятором вариант проще для понимания, чем исходный.

     
     
  • 2.22, Ordu (ok), 12:35, 05/05/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Нет. В реальном коде это выглядит обычно так:

    enum {
        AVADA_KEDAVRA = 2,
        ALOHOMORA = 3,
        STUPEFY = 4,
        /* ... */
    };

    и дальше где-то:

    case AVADA_KEDAVRA: how = 205; break;
    case EXPECTO_PATRONUM: how = 1234; break;
    case STUPEFY: how = 405; break;
    case SECTUM_SEMPRA: how = 1005; break;
    case ALOHOMORA: how = 305; break;

    Запросто может не быть единой формулы для всех case'ов, но даже если она и есть, использование такой формулы может быть глупостью, потому что потом кто-нибудь изменит enum в хидере, и твоя формула пойдёт лесом, она начнёт работать неправильно. То есть мы получим нелокальный баг -- ты вносишь изменения в один файл, а баг привносится в совершенно другой файл, может быть даже в другом проекте. Что плохо -- он привносится молчаливо, и вся надежда на то, что тесты смогут его выявить. Если не смогут, то ты подаришь этот баг пользователям, когда зарелизишь свои полезнейшие изменения.

    Вариант с case'ами лучше тем, что меньше шансов сломать его нелокально, а если C умеет проверять case'ы на полное покрытие значений enum'а (он умеет? а если не умеет, то статический анализатор должен помочь), то тогда вообще всё получается почти идеально. Ты меняешь enum, код либо продолжает работать, либо выкидывает варнинги/ошибки в процессе компиляции.

     
     
  • 3.23, старик2 (?), 14:27, 05/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Про EXPECTO_PATRONUM осилил эхх тяжело мне новые знания даются с трудом ну ни чего прорвемся все собираюсь собираюсь начать учить C++ и все никак старик как ни как.Спасибо за разьяснения.
     
     
  • 4.25, Ordu (ok), 15:26, 05/05/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Иди лучше русский изучи, дедунь. Я вот тоже не знаю, куда ставить запятые, а куда нет, но если ты их совсем не ставишь, читать крайне сложно. Если по другим твоим сообщениям посмотреть, то тебе и тему слитно/раздельно следует освежить в памяти. Изучи русский. Забей на IT, это не для тебя.
     
     
  • 5.26, старик3 (?), 15:34, 05/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мне уже 74 год что ты хочешь.Вот доживешь до мои годков тогда посмотрим.А русский я плохо знаю так как родился в Киеве а вырос в германии.Не обижайся если что.  
     
     
  • 6.27, Ordu (ok), 15:55, 05/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот доживешь до мои годков тогда посмотрим.

    Это ты излишне оптимистично использовал тут множественное число.

     
  • 6.32, НяшМяш (ok), 21:22, 05/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мне кажется, что в немецком письменном также принято ставить запятые и пробелы после запятых и точек. 74 года - не оправдание.
     
  • 6.57, SohnEinesOffiziers (?), 15:52, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне уже 74 год что ты хочешь.Вот доживешь до мои годков тогда
    > посмотрим.А русский я плохо знаю так как родился в Киеве а
    > вырос в германии.

    Ja ne, is klar!
    Mein lieber Herr Gesangsverein, Sachen jibt's dat jibt's gar nit!


     
  • 3.29, Аноним (18), 16:26, 05/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Запросто может не быть единой формулы для всех case'ов, но даже если она и есть, использование такой формулы может быть глупостью, потому что потом кто-нибудь изменит enum в хидере

    Не надо просто валить всё в кучу. Если есть подобная структура в енамах, то это говорит о том, что иут надо не в 1 енам всё мешать, а разделить по разным полям в структуре и передавать не инты, а структуры. Если нужно сэкономить место, то битовые поля к вашим услугам.

    enum class SpellGroup:uint8_t{
       undefined=0
       offensive=1,
       defensive=2,
       service=3
    };

    struct spell{
      SpellGroup offensive:2;
      union{
        OffensiveSpellId offensive;
        DefensiveSpellId defensive;
        ServiceSpellId service;
      } id:7;
    };

     
     
  • 4.30, Ordu (ok), 18:59, 05/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Не надо просто валить всё в кучу. Если есть подобная структура в
    > енамах, то это говорит о том, что иут надо не в
    > 1 енам всё мешать, а разделить по разным полям в структуре
    > и передавать не инты, а структуры.
    > надо не в 1 енам...
    > надо

    Кому надо? Зачем надо? Ты уверен, что этот подход сработает всегда? Скажем, если значения нашего enum'а взяты из /etc/services или ещё откуда? Ты уверен, что вся информация связанная с константой обязательно влезет в машинное слово, в том числе и каноническое имя для этой константы, и ещё описание для пользователя, если он захочет больше подробностей? С переводами на пару десятков языков.

     
     
  • 5.31, Аноним (18), 21:16, 05/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >если значения нашего enum'а взяты из /etc/services

    ЩИТО? в /etc/services нет перечислений, там только номера портов

    >Ты уверен, что вся информация связанная с константой обязательно влезет в машинное слово, в том числе и каноническое имя для этой константы, и ещё описание для пользователя, если он захочет больше подробностей? С переводами на пару десятков языков.

    Вы вообще о чём? Мы говорим о перечислениях и о конкретной оптимизации и о том, почему лучше уволить разраба, к коду которого она применима. Если вам надо таскать всю указанную информацию, то перечислением и той конкретной оптимизацией тут и не пахнет.

     
     
  • 6.35, Ordu (ok), 22:28, 05/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, там только перечисление номеров портов с именами сервисов и комментами Вещь... текст свёрнут, показать
     
     
  • 7.42, meantraitor (?), 12:53, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > _descriptions было бы круто спрятать из .h файла куда-нибудь, но тогда не удастся следующие
    > функции заинлайнить статически (это дурацкие ограничения C, их может быть можно обойти инлайном
    > в линк-тайме, но я не знаю об этом ничего -- слышал звон, да не знаю где он).

    extern struct ServiceDescription _descriptions[];

    и все отлично инлайнится.
    А за написание в хедере

    static struct ServiceDescription { ... } _descriptions[] = { ... }

    обычно бьют канделябром по голове, потому в каждом .c, включившем этот .h оседает своя
    собственная копия _descriptions[]

     
     
  • 8.43, Ordu (ok), 13:00, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    А, да, я забыл Видишь, это именно те самые глупости в C, которые делают его ока... текст свёрнут, показать
     
     
  • 9.46, Урри (?), 13:52, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Неосилятор, или табы правильно расставляй в своей молодежной огороженной песочни... текст свёрнут, показать
     
     
  • 10.48, Ordu (ok), 14:13, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты пробовал когда-нибудь переключаться между языками C шная идея include ов -- ... текст свёрнут, показать
     
     
  • 11.61, Аноним (61), 14:06, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще-то изначально не сишная, а плюсовая ... текст свёрнут, показать
     
  • 9.54, Аноним (11), 11:14, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да-да-да, это не ты болтливая бестолочь, это C плохой ... текст свёрнут, показать
     
     
  • 10.55, Ordu (ok), 12:13, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Это настолько очевидно, что я не вижу даже что тебя подвинуло об этом писать ... текст свёрнут, показать
     
  • 7.44, Аноним (44), 13:44, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Как с /etc/services работать из C?

    Это же азы С - struct servent *getservbyname(cont char *name, const char *proto);

    А у вас что это за треш навелосипедился?

     
     
  • 8.49, Ordu (ok), 14:14, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дитятко, я выше специально сделал оговорку ради этого Вот специально я был уве... текст свёрнут, показать
     
  • 3.45, Урри (?), 13:51, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вы, извиняюсь, на чем пишете?

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

     
     
  • 4.50, Ordu (ok), 14:15, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы, извиняюсь, на чем пишете?
    > Потому как при изменении хидера полюбому надо пересобирать проект - что с
    > оптимизацией, что без, код не будет соответствовать новым условиям.

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

     
  • 3.56, Аноним (56), 15:46, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > мы получим нелокальный баг --
    > ты вносишь изменения в один файл, а баг привносится в совершенно
    > другой файл, может быть даже в другом проекте.

    Ошибка второго порядка?

     
     
  • 4.58, Ordu (ok), 17:27, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Ошибка второго порядка?

    Я не знаю, есть ли для таких ошибок специальное название. Может быть "не локальная ошибка"?

     

  • 1.19, Аноним (18), 11:40, 05/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Currently devices using Nvidia PTX (nvptx) are supported, and AMD GCN device support is in development.

    Чувствую я, владельцев старых карты вообще прокинут и во всех новых приложениях будет требование post-gcn карт.

    Я бы может быть и купил бы карту (очень жаль, что купить новую кар у за сколько там тыщ будет дешевле, чем работать фуллтайм над допилом всего того софта, её дропнувшего, а потом убеждать всяких **** включить в дистрибутивы софт с лишними функциями, не нужными 99,99% пользователей. потому что у всех уже новые карты), но мой блок питания (450 W, охренеть, почти полкиловатта системник потреблял 10 лет назад, что де теперь творится?) впритык тянет всё то говно, что понапихано в мой системник.

     
     
  • 2.33, НяшМяш (ok), 21:25, 05/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если у тебя 450W блок питания уже 10 лет, то очень скоро он может перестать тянуть даже то самое, поставленное те же 10 лет назад. Если в нем заменить электролиты, то спокойно будет тянуть системник вида 9700 (без К) и 1060. Они укладываются в 250 ватт потребления.
     

  • 1.20, Аноним (18), 11:44, 05/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >Добавлена экспериментальная поддержка части будущего стандарта языка Си, развиваемого под кодовым именем C2x. Для включения поддержки C2x следует использовать опции "-std=c2x" и "-std=gnu2x" (для включения расширений GNU).

    В CMake ещё не впилили: https://cmake.org/cmake/help/latest/prop_tgt/CXX_STANDARD.html

     
     
  • 2.24, Аноним (24), 15:15, 05/05/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Правильная ссылка: https://cmake.org/cmake/help/latest/prop_tgt/C_STANDARD.html
    Безобразие, конечно: позавчера вышел компилятор, а в вышедшую две недели назад версию сборочной системы его новые фичи ещё не завезли!
     
     
  • 3.28, Аноним (18), 16:10, 05/05/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вообще-то впилить можно было бы сразу после того, как определились с названием стандарта, так как флаг выводится из него.
     
     
  • 4.51, Совершенно другой аноним (?), 16:35, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Там с самим стандартом ещё не очень определились.
     
  • 3.53, Аноним (53), 07:36, 07/05/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Безобразие, конечно: позавчера вышел компилятор, а в вышедшую две недели назад версию сборочной системы его новые фичи ещё не завезли!

    Это проблема сборочной системы, которую надо править после каждого релиза компилятора. В автотулзах уже есть:
    CFLAGS=-std=c2x ./configure...

     
     
  • 4.59, Аноним (61), 14:01, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ты вообще в курсе, для чего autocrap и cmake придуманы? Вот как раз для того, чтобы не надо было все эти параметры ручками указывать, к тому же во время сборки (собирает юзер, который знать не знает, какой там стандарт нужен). Но в autocrap для сишных стандартов макроса вообще не завезли, только для плюсов есть ax_cxx_compile_stdcxx. Так что чья б корова мычала.
     
     
  • 5.60, Аноним (61), 14:04, 08/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    P. S. для особо одарённых: конечно же, можно сделать cmake -DCMAKE_C_FLAGS=-std=c2x. Но это неправильное решение.
     

  • 1.21, Аноним (18), 11:53, 05/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >Прекращена поддержка архитектур Armv2, Armv3, Armv5 и Armv5E

    Таким образом ведь и i686 дропнут.

     
     
  • 2.47, Урри (?), 13:54, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Просто пользуемся предыдущей версией. Никаких исправлений тут все равно нету, одни мало кому нужные фичи.
     

  • 1.34, Анонимчик (?), 21:39, 05/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    i686 Еше жива...ужось.)
    Вы же тут поголовно ценители прогресса.
     
     
  • 2.38, Крикет (?), 08:02, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Мне P-II надо чтобы работал!
     
  • 2.39, Совершенно другой аноним (?), 09:21, 06/05/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Есть такая линейка процессоров от Intel - Atom-ы называются. Там только сравнительно недавно x86-64 завезли, а до того, считай, тот i686 и только и был.
     

  • 1.41, InuYasha (?), 11:52, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Среди всех этих новостей про жавы, руби, электроны... Хоть что-то краСИвое, вечное, доброе!
     
  • 1.52, Аноним (52), 18:18, 06/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >Процесс включения поддержки языка D в GCC начался ещё в 2011 году, но затянулся

    Так затянулся, что через пару релизов пора будет депрекейтить, за ненадобностью

     
  • 1.62, Аноним (62), 18:56, 08/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >> Armv5 и Armv5E

    чего выкинули? (

     
  • 1.63, iZEN (ok), 13:46, 10/05/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    [code]/usr/src/contrib/libstdc++/src/bitmap_allocator.cc: At global scope:
    /usr/src/contrib/libstdc++/src/bitmap_allocator.cc:126:1: error: '_GLIBCXX_END_NAMESPACE' does not name a type
      126 | _GLIBCXX_END_NAMESPACE
          | ^~~~~~~~~~~~~~~~~~~~~~
    In file included from /usr/src/contrib/libstdc++/src/bitmap_allocator.cc:30:
    /usr/src/contrib/libstdc++/include/ext/bitmap_allocator.h: In instantiation of 'void bitmap_allocator<_Tp>::_M_deallocate_single_object(bitmap_allocator<_Tp>::pointer) [with _Tp = char; bitmap_allocator<_Tp>::pointer = char*]':
    /usr/src/contrib/libstdc++/src/bitmap_allocator.cc:123:18:   required from here
    /usr/src/contrib/libstdc++/include/ext/bitmap_allocator.h:963:54: error: '__real_p' cannot be used as a function
      963 |      (__real_p) (_S_mem_blocks[_S_last_dealloc_index]))
          |                                                      ^
    /usr/src/contrib/libstdc++/include/ext/bitmap_allocator.h: In instantiation of 'void bitmap_allocator<_Tp>::_M_deallocate_single_object(bitmap_allocator<_Tp>::pointer) [with _Tp = wchar_t; bitmap_allocator<_Tp>::pointer = wchar_t*]':
    /usr/src/contrib/libstdc++/src/bitmap_allocator.cc:124:18:   required from here
    /usr/src/contrib/libstdc++/include/ext/bitmap_allocator.h:963:54: error: '__real_p' cannot be used as a function
    /usr/src/contrib/libstdc++/src/bitmap_allocator.cc: In member function 'size_t* free_list::_M_get(size_t)':
    /usr/src/contrib/libstdc++/src/bitmap_allocator.cc:103:3: warning: control reaches end of non-void function [-Wreturn-type]
      103 |   }
          |   ^
    *** Error code 1

    Stop.
    make[4]: stopped in /usr/src/gnu/lib/libstdc++
    [/code]Не работает — чините.

     

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



    Спонсоры:
    MIRhosting
    Fornex
    Hosting by Ihor
    Хостинг:

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