The OpenNET Project / Index page

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



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

"Релиз набора компиляторов GCC 9"  +/
Сообщение от opennews (?), 04-Май-19, 01:22 
После года разработки опубликован (https://gcc.gnu.org/ml/gcc-announce/2019/msg00001.html) релиз свободного набора компиляторов GCC 9.1 (https://gcc.gnu.org/gcc-9), первый значительный выпуск в новой ветке GCC 9.x. В соответствии с новой схемой (https://gcc.gnu.org/develop.html#num_scheme) нумерации выпусков, версия 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 .


Основные изменения (https://gcc.gnu.org/gcc-9/changes.html):

-  Добавлена поддержка языка программирования D. В основной состав GCC включены фронтэнд с компилятором GDC (https://gdcproject.org/) (Gnu D Compiler) и runtime-библиотеки (libphobos), которые позволяют использовать штатный GCC для сборки программ на языке программирования D. Процесс включения поддержки языка D в GCC начался (https://www.opennet.me/opennews/art.shtml?num=28607) ещё в 2011 году, но затянулся (http://dconf.org/2017/talks/buclaw.pdf) из-за необходимости приведения кода к соответствию требованиям 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. Повышена точность и агрессивность разделения "холодного" и "горячего" кода. Улучшена масшабируемость для очень больших единиц трансляции (https://ru.wikipedia.org/wiki/%D0%95%D0%...) (например, при применении оптимизации на этапе связывания к большим программам);

-  Улучшен механизм оптимизации на основе результатов профилирования кода (PGO - Profile-guided optimization), который генерирует более оптимальный код на основе анализа особенностей выполнения кода. Сводная опция "-fprofile-use (https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Optimize-Option...)" теперь включает режимы оптимизации "-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 оптимизации позволили (http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inte...) примерно на 5% сократить время компиляции  Firefox 66 и LibreOffice 6.2.3. Размер объектных файлов снизился на 7%. Время связывания на 8-ядерном CPU уменьшилось  на 11%. Последовательная стадия оптимизации на этапе связывания теперь выполняется на 28% быстрее и потребляет на 20% меньше памяти. Потребление памяти каждого обработчика распараллеливаемой стадии LTO  снизилось на 30%;

-  Для языков C, C++ и Fortran реализована бо́льшая часть спецификации  параллельного программирования OpenACC 2.5 (https://gcc.gnu.org/wiki/OpenACC), определяющей средства для выноса операций (offloading)  на GPU и специализированные процессоры, такие как NVIDIA PTX;

-  Для С и С++ реализована частичная поддержка стандарта OpenMP 5.0 (https://www.opennet.me/opennews/art.shtml?num=49585) (Open Multi-Processing), определяющего API и способы применения методов параллельного программирования для языков Си, Си++ и Фортран на многоядерных и гибридных (CPU+GPU/DSP) системах с общей памятью и блоками векторизации (SIMD);

-  Для языка Си добавлены новые предупреждения: "-Waddress-of-packed-member (https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Warning-Options...)" (невыравненное значение указателя на упакованный элемент структуры или объединения) и
"-Wabsolute-value (https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Warning-Options...)" (при обращении к функциям вычисления абсолютного значения, если для указанного аргумента имеется более подходящая функция, например, вместо 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++ определённые в стандарте библиотечные функции близки к полной реализации;

-  Продолжена реализация (https://gcc.gnu.org/projects/cxx-status.html#cxx2a) элементов будущего стандарта 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 добавлен режим защиты от пересечения стека и кучи (https://www.opennet.me/opennews/art.shtml?num=46724) ("-fstack-clash-protection")....

URL: https://gcc.gnu.org/ml/gcc-announce/2019/msg00001.html
Новость: https://www.opennet.me/opennews/art.shtml?num=50622

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

Оглавление

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


1. "Релиз набора компиляторов GCC 9"  +1 +/
Сообщение от пгуыыцрщ (?), 04-Май-19, 01:22 
Ммм, а -fipa-pta так и не починили?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Релиз набора компиляторов GCC 9"  –3 +/
Сообщение от старик (?), 04-Май-19, 01:36 
Кхх гм ну что ж хорошая новость.Сейчас перекомпилирую 1041 исходный текст.Жаль только что опять OpenACC ни как а я уж по старости своей наивной понадеился на свою rx580 заместо процессора.  
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Релиз набора компиляторов GCC 9"  +15 +/
Сообщение от A.Stahl (ok), 04-Май-19, 04:28 
>ни как, понадеился, заместо

Ух!

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

5. "Релиз набора компиляторов GCC 9"  –1 +/
Сообщение от Аноним (5), 04-Май-19, 05:39 
стухл
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

37. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Аноним (37), 06-Май-19, 06:20 
мда, чую как корабль назовешь так оно и поплывет
еще не допилили, а уже сТУх
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

8. "Релиз набора компиляторов GCC 9"  +4 +/
Сообщение от Аноним (8), 04-Май-19, 11:08 
>реализована бо́льшая часть спецификации параллельного программирования OpenACC 2.5

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

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

3. "Релиз набора компиляторов GCC 9"  –1 +/
Сообщение от Аноним (3), 04-Май-19, 03:23 
А что там в C2k нового? Какие интересности завезли?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Релиз набора компиляторов GCC 9"  +3 +/
Сообщение от Аноним (7), 04-Май-19, 08:26 
utf8, constexpr, auto.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

9. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Аноним (8), 04-Май-19, 11:11 
constexpr и auto уже в 11-м были, не?
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

10. "Релиз набора компиляторов GCC 9"  +3 +/
Сообщение от An0Nm (?), 04-Май-19, 11:15 
C2x это сишный стандарт.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Релиз набора компиляторов GCC 9"  +1 +/
Сообщение от Аноним (11), 04-Май-19, 11:26 
В плюсах были, в C нет.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

40. "Релиз набора компиляторов GCC 9"  –1 +/
Сообщение от Аноним (40), 06-Май-19, 09:26 
Долбо* неразличающий сиплюсплюс и чистый си
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Аноним (6), 04-Май-19, 06:41 
Печально, но в OBS-репозитории devel:gcc/SLE_11 его уже не будет. Из-за прекращения основной поддержки. А жаль. Было очень удобно использовать компилятор оттуда для билд-фермы. А devtoolset для CentOS не настолько удобный
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Релиз набора компиляторов GCC 9"  +3 +/
Сообщение от Crazy Alex (ok), 04-Май-19, 14:44 
D и бэкэнды для AMD GPU и OpenRISC? Добротный релиз, ничего не скажешь
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Релиз набора компиляторов GCC 9"  –1 +/
Сообщение от старик2 (?), 04-Май-19, 18:03 
Ну все перекомпилировал не собрался 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 часов ушло наверно тротлил хад.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Аноним (14), 04-Май-19, 20:59 
Только qt с графитом потом рандомно крашится и зависает, в кедах особенно классно сидеть. И вообще фигня, ни одна программа не показала выигрыша в производительности с ним. Лто хотя бы бинарники меньше делает, для плюсовых программ хорошо. А вот пго топчик, оптимизирует без заморочек написанный код (ручками можно того же добиться).

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

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

36. "Релиз набора компиляторов GCC 9"  –1 +/
Сообщение от пгуыыцрщ (?), 06-Май-19, 00:47 
Не надо обобщать. У меня не крашится например.
Может дело в кедах?
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

15. "Релиз набора компиляторов GCC 9"  –1 +/
Сообщение от старик2 (?), 04-Май-19, 23:13 
Хмм возможно и так но проблем с крашами не наблюдал ну скорее всего нет большого количества специфичных программ для серьезной работы где нужна стабильность.Так себе небольшой сервер и мультимедиа десктоп.Да конечно в продакшен с такими флагами ни ни согласен.А лто да еще года четыре назад юзал сравнивал размер бинарников ну и т.д.Главная проблема лто в роллинг бэйс операционках (при обновленнии системы)это изменение версий программ и их кода что ведет по моему опыту к неработоспособности и глюкам программ так как слетает линковка всяких там библиотек или удаление из исходника того что должно работать с другой частью зависимого кода glibc например что и приводит в итоге к глючному бинарнику.Вот как пример собрал не давно лису с лто -march=native -02 и gold линкером (ни какого хардкора)и что в лисе перестал сохранятся масштаб текста и всего отображаемого на странице выставлял +200% при перезагрузке браузера опять 100% -это нужно для больших экранов при просмотре с расстояния чтоб увеличить размер всего на странице.По моему скромному мнению лто хорош на специальных проектах собрал и забыл.Да конечно есть автоматизированный си-ай интегрейшн но это работает в конторах (постоянная сборка пересборка мержка и т.д)а дома лто ну его нафиг нет времени разбираться в багах и зависимостях денег за это не заплатят а система упадет.  
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Релиз набора компиляторов GCC 9"  –1 +/
Сообщение от старик2 (?), 04-Май-19, 23:37 
Гм с профилированием PGO надо по думать.Только оно т.е пго для для небольшого количества программ предназначено (ну в gentoo например).Да предполагаю что любой код можно профилировать но это надо вносить изменения в средство разработки или в билды и т.д.Да и с сценарием работы кода тоже не ясно какая последовательность выполнения модулей блоков алгоритмов чаще выполняется.Набрать статистику работы можно но это не решает всех возможных вариантов работы программы.Так что вопросов очень много.Возможно надо придерживаться золотой середины.  
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Релиз набора компиляторов GCC 9"  –1 +/
Сообщение от старик2 (?), 04-Май-19, 23:59 
Да и с графитом не понятно я не кодер.Какие циклы в каком коде если С++ как часто повторяются и есть ли смысл их обьеденять сокращать и т.д  что это даст?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Релиз набора компиляторов GCC 9"  –5 +/
Сообщение от Аноним (18), 05-Май-19, 11:32 
>case 2: how = 205; break; case 3: how = 305; break;

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

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

22. "Релиз набора компиляторов GCC 9"  +5 +/
Сообщение от Ordu (ok), 05-Май-19, 12:35 
Нет. В реальном коде это выглядит обычно так:

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, код либо продолжает работать, либо выкидывает варнинги/ошибки в процессе компиляции.

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

23. "Релиз набора компиляторов GCC 9"  +/
Сообщение от старик2 (?), 05-Май-19, 14:27 
Про EXPECTO_PATRONUM осилил эхх тяжело мне новые знания даются с трудом ну ни чего прорвемся все собираюсь собираюсь начать учить C++ и все никак старик как ни как.Спасибо за разьяснения.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

25. "Релиз набора компиляторов GCC 9"  +5 +/
Сообщение от Ordu (ok), 05-Май-19, 15:26 
Иди лучше русский изучи, дедунь. Я вот тоже не знаю, куда ставить запятые, а куда нет, но если ты их совсем не ставишь, читать крайне сложно. Если по другим твоим сообщениям посмотреть, то тебе и тему слитно/раздельно следует освежить в памяти. Изучи русский. Забей на IT, это не для тебя.
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

26. "Релиз набора компиляторов GCC 9"  +1 +/
Сообщение от старик3 (?), 05-Май-19, 15:34 
Мне уже 74 год что ты хочешь.Вот доживешь до мои годков тогда посмотрим.А русский я плохо знаю так как родился в Киеве а вырос в германии.Не обижайся если что.  
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

27. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Ordu (ok), 05-Май-19, 15:55 
> Вот доживешь до мои годков тогда посмотрим.

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

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

32. "Релиз набора компиляторов GCC 9"  +1 +/
Сообщение от НяшМяш (ok), 05-Май-19, 21:22 
Мне кажется, что в немецком письменном также принято ставить запятые и пробелы после запятых и точек. 74 года - не оправдание.
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

57. "Релиз набора компиляторов GCC 9"  +/
Сообщение от SohnEinesOffiziers (?), 07-Май-19, 15:52 
> Мне уже 74 год что ты хочешь.Вот доживешь до мои годков тогда
> посмотрим.А русский я плохо знаю так как родился в Киеве а
> вырос в германии.

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


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

29. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Аноним (18), 05-Май-19, 16:26 
>Запросто может не быть единой формулы для всех 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;
};

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

30. "Релиз набора компиляторов GCC 9"  –1 +/
Сообщение от Ordu (ok), 05-Май-19, 18:59 
> Не надо просто валить всё в кучу. Если есть подобная структура в
> енамах, то это говорит о том, что иут надо не в
> 1 енам всё мешать, а разделить по разным полям в структуре
> и передавать не инты, а структуры.
> надо не в 1 енам...
> надо

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

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

31. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Аноним (18), 05-Май-19, 21:16 
>если значения нашего enum'а взяты из /etc/services

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

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

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

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

35. "Релиз набора компиляторов GCC 9"  +1 +/
Сообщение от Ordu (ok), 05-Май-19, 22:28 
>>если значения нашего enum'а взяты из /etc/services
> ЩИТО? в /etc/services нет перечислений, там только номера портов

Да, там только перечисление номеров портов с именами сервисов и комментами. Вещь которую напрашивается оттранслировать в массив, но как ссылаться на элементы? Можно указателями, но если у нас есть основания полагать, что мы ещё и по имени захотим ссылаться туда?

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

Мозг включи, пожалуйста. Как раз именно перечислением здесь и пахнет. Это ты пытаешься всю информацию запихать в непосредственное значение, которое будет #[derive(Copy,Clone)]. Мне эта идея может показаться удачной только тогда, когда я стопудов уверен, что всё что надо влезет, и что потом мне не потребуется затем пихать туда больше информации, и что это не кончится тем, что структура вылезет за пределы 128 бит, и вопрос о том, что структура тут лишняя, встанет ребром. И перечисление спеллов -- это явно вещь, которая очень быстро распухнет так, что она не влезет ни в 128 бит, ни в 256, если туда пихать информацию о том, offensive оно или defensive; может быть использовано к механической цели, или только к белковой; называется на букву 'а' или на какую-другую; и тп.

Тебе какой пример больше нравится? С авадой кедаврой или с /etc/services?
Давай я на втором, он тебе более непонятен оказался почему-то. Как с /etc/services работать из C?
Есть разные варианты (скажем поискать существующие API -- один из самых перспективных), но я предлагаю следующий:
1. пишем скрипт, который из /etc/services делает ./services-generated.h с содержанием типа:
enum Service {
    TCPMUX = 1,
        COMPRESSNET = 2,
        RJE = 5,
        ...
}

static struct ServiceDescription {
    char *name;
    char *description;
} _descriptions[] = {
    [TCPMUX] = { .name = "tcpmux", .description = "TCP port service multiplexer" },
    [COMPRESSNET] = { ...
    ...
};

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

2. пишем services.h:
#include "./services-generated.h"

static inline int service_port(enum Service s) {
    return (int)s; // в нашем случае маппинг тривиален, но это не обязательно
}
static inline char *service_name(enum Service s) {
    return _descriptions[s].name
}
static inline char *service_description(enum Service s) {
    return _descriptions[s].description
}

Помимо этого у нас могут быть функции типа:

// NB: will return NULL if decoder is unimplemented
static inline struct PacketDecoder *service_decoder(enum Service s) {
    // ...
}
static inline bool service_encrypted(enum Service s) {
    // ...
}

Что ещё у нас может быть мне лень придумывать, потому что я не знаю, что это за программа такая и какие функции она выполняет. Но я думаю этого достаточно. Какие-то из этих функций могут использовать индексацию массива, если этот массив создаётся одним и тем же "поставщиком" что и сам enum (в нашем случае это скрипт), то есть если способ создания массива даёт гарантию соответствия индексов записям в массиве. Другие функции просто неразумно делать таким образом, потому что они могут обрабатывать небольшое количество значений enum'а -- скажем service_decoder может возвращать декодеры для десятка протоколов, и такой декодер может иметь пяток-десяток указателей на функции внутри с сопутствующей информацией, то есть занимать десятки байт, но выделять память под сотни структур таблички там, где будет достаточно десятка... ну это не самый удачный подход. Там можно повыкобениваться с табличкой указателей на структуры (всего по восемь байт на каждый указатель там, в том числе и NULL), но это уже декларативные глупости: для таких целей switch понятнее и, можно надеятся, короче в смысле количества байт в бинаре, требуемых на реализацию.

Третьи функции, которые вовсе не в нашей библиотеке объявлены, а в другом приложении, которое нашей библиотекой пользуются, вообще не могут полагаться на значения enum'а. Они даже не могут полагаться на то, что значением HTTP будет 80, а не что-то ещё, если конечно мы не гарантируем это в документации, потому что это внутренняя деталь реализации, которая может измениться завтра, когда нам в голову придёт другая какая-нибудь идея. Например, чтобы значение enum'а вычислялось бы по формуле: ip_port * 2 + (tcp ? 0 : 1). В смысле если это tcp порт, то номер сервиса -- это удвоенный порт, а если udp, то удвоенный и увеличенный на 1. Или не, ещё круче будет использовать бит знака для этого, чтобы tcp сервисы были бы положительными, а udp отрицательными.

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

42. "Релиз набора компиляторов GCC 9"  +1 +/
Сообщение от meantraitor (?), 06-Май-19, 12:53 
> _descriptions было бы круто спрятать из .h файла куда-нибудь, но тогда не удастся следующие
> функции заинлайнить статически (это дурацкие ограничения C, их может быть можно обойти инлайном
> в линк-тайме, но я не знаю об этом ничего -- слышал звон, да не знаю где он).

extern struct ServiceDescription _descriptions[];

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

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

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

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

43. "Релиз набора компиляторов GCC 9"  –4 +/
Сообщение от Ordu (ok), 06-Май-19, 13:00 
> А за написание в хедере
> static struct ServiceDescription { ... } _descriptions[] = { ... }
> обычно бьют канделябром по голове, потому в каждом .c, включившем этот .h
> оседает своя
> собственная копия _descriptions[]

А, да, я забыл. Видишь, это именно те самые глупости в C, которые делают его окаменевшим дерьмом мамонта.

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

46. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Урри (?), 06-Май-19, 13:52 
Неосилятор, или табы правильно расставляй в своей молодежной огороженной песочнице.
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

48. "Релиз набора компиляторов GCC 9"  –1 +/
Сообщение от Ordu (ok), 06-Май-19, 14:13 
> Неосилятор, или табы правильно расставляй в своей молодежной огороженной песочнице.

Ты пробовал когда-нибудь переключаться между языками? C'шная идея include'ов -- это c'шная идея, которая несколько перпендикулярна идее модуля. Когда ты привыкаешь к модулям, нужно некоторое время, чтобы вернуться к мышлению уровня конкатенации файлов.

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

61. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Аноним (61), 08-Май-19, 14:06 
> C'шная идея include'ов

Вообще-то изначально не сишная, а плюсовая.

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

54. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Аноним (11), 07-Май-19, 11:14 
Да-да-да, это не ты болтливая бестолочь, это C плохой.
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

55. "Релиз набора компиляторов GCC 9"  –3 +/
Сообщение от Ordu (ok), 07-Май-19, 12:13 
> Да-да-да, это не ты болтливая бестолочь, это C плохой.

Это настолько очевидно, что я не вижу даже что тебя подвинуло об этом писать.

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

44. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Аноним (44), 06-Май-19, 13:44 
> Как с /etc/services работать из C?

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

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

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

49. "Релиз набора компиляторов GCC 9"  –1 +/
Сообщение от Ordu (ok), 06-Май-19, 14:14 
>> Как с /etc/services работать из C?
> Это же азы С - struct servent *getservbyname(cont char *name, const char
> *proto);
> А у вас что это за треш навелосипедился?

Дитятко, я выше специально сделал оговорку ради этого. Вот специально: я был уверен, что найдётся вундеркинд типа тебя.

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

45. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Урри (?), 06-Май-19, 13:51 
Вы, извиняюсь, на чем пишете?

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

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

50. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Ordu (ok), 06-Май-19, 14:15 
> Вы, извиняюсь, на чем пишете?
> Потому как при изменении хидера полюбому надо пересобирать проект - что с
> оптимизацией, что без, код не будет соответствовать новым условиям.

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

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

56. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Аноним (56), 07-Май-19, 15:46 
> мы получим нелокальный баг --
> ты вносишь изменения в один файл, а баг привносится в совершенно
> другой файл, может быть даже в другом проекте.

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

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

58. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Ordu (ok), 07-Май-19, 17:27 
> Ошибка второго порядка?

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

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

19. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Аноним (18), 05-Май-19, 11:40 
>Currently devices using Nvidia PTX (nvptx) are supported, and AMD GCN device support is in development.

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

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

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

33. "Релиз набора компиляторов GCC 9"  +/
Сообщение от НяшМяш (ok), 05-Май-19, 21:25 
Если у тебя 450W блок питания уже 10 лет, то очень скоро он может перестать тянуть даже то самое, поставленное те же 10 лет назад. Если в нем заменить электролиты, то спокойно будет тянуть системник вида 9700 (без К) и 1060. Они укладываются в 250 ватт потребления.
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

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

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

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

24. "Релиз набора компиляторов GCC 9"  +1 +/
Сообщение от Аноним (24), 05-Май-19, 15:15 
Правильная ссылка: https://cmake.org/cmake/help/latest/prop_tgt/C_STANDARD.html
Безобразие, конечно: позавчера вышел компилятор, а в вышедшую две недели назад версию сборочной системы его новые фичи ещё не завезли!
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

28. "Релиз набора компиляторов GCC 9"  –2 +/
Сообщение от Аноним (18), 05-Май-19, 16:10 
Вообще-то впилить можно было бы сразу после того, как определились с названием стандарта, так как флаг выводится из него.
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

51. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Совершенно другой аноним (?), 06-Май-19, 16:35 
Там с самим стандартом ещё не очень определились.
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

53. "Релиз набора компиляторов GCC 9"  –2 +/
Сообщение от Аноним (53), 07-Май-19, 07:36 
> Безобразие, конечно: позавчера вышел компилятор, а в вышедшую две недели назад версию сборочной системы его новые фичи ещё не завезли!

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

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

59. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Аноним (61), 08-Май-19, 14:01 
Ты вообще в курсе, для чего autocrap и cmake придуманы? Вот как раз для того, чтобы не надо было все эти параметры ручками указывать, к тому же во время сборки (собирает юзер, который знать не знает, какой там стандарт нужен). Но в autocrap для сишных стандартов макроса вообще не завезли, только для плюсов есть ax_cxx_compile_stdcxx. Так что чья б корова мычала.
Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

60. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Аноним (61), 08-Май-19, 14:04 
P. S. для особо одарённых: конечно же, можно сделать cmake -DCMAKE_C_FLAGS=-std=c2x. Но это неправильное решение.
Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

21. "Релиз набора компиляторов GCC 9"  –1 +/
Сообщение от Аноним (18), 05-Май-19, 11:53 
>Прекращена поддержка архитектур Armv2, Armv3, Armv5 и Armv5E

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

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

47. "Релиз набора компиляторов GCC 9"  –1 +/
Сообщение от Урри (?), 06-Май-19, 13:54 
Просто пользуемся предыдущей версией. Никаких исправлений тут все равно нету, одни мало кому нужные фичи.
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

34. "Релиз набора компиляторов GCC 9"  –2 +/
Сообщение от Анонимчик (?), 05-Май-19, 21:39 
i686 Еше жива...ужось.)
Вы же тут поголовно ценители прогресса.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

38. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Крикет (?), 06-Май-19, 08:02 
Мне P-II надо чтобы работал!
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

39. "Релиз набора компиляторов GCC 9"  –1 +/
Сообщение от Совершенно другой аноним (?), 06-Май-19, 09:21 
Есть такая линейка процессоров от Intel - Atom-ы называются. Там только сравнительно недавно x86-64 завезли, а до того, считай, тот i686 и только и был.
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

41. "Релиз набора компиляторов GCC 9"  +2 +/
Сообщение от InuYasha (?), 06-Май-19, 11:52 
Среди всех этих новостей про жавы, руби, электроны... Хоть что-то краСИвое, вечное, доброе!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

52. "Релиз набора компиляторов GCC 9"  +2 +/
Сообщение от Аноним (52), 06-Май-19, 18:18 
>Процесс включения поддержки языка D в GCC начался ещё в 2011 году, но затянулся

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

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

62. "Релиз набора компиляторов GCC 9"  +/
Сообщение от Аноним (62), 08-Май-19, 18:56 
>> Armv5 и Armv5E

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

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

63. "Релиз набора компиляторов GCC 9"  +/
Сообщение от iZENemail (ok), 10-Май-19, 13:46 
/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++

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

65. "Релиз набора компиляторов GCC 9"  +/
Сообщение от iZENemail (ok), 07-Июл-19, 22:22 
> firefox

JavaScript error: resource:///modules/sessionstore/SessionStore.jsm, line 1215: uncaught exception: 2147746065

###!!! [Parent][MessageChannel] Error: (msgtype=0x1E0076,name=PBrowser::Msg_RealMouseMoveEvent) Channel error: cannot send/recv


###!!! [Parent][MessageChannel] Error: (msgtype=0x1E0074,name=PBrowser::Msg_StopIMEStateManagement) Channel error: cannot send/recv


###!!! [Parent][MessageChannel] Error: (msgtype=0x1E008F,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv

[Child 4303, Chrome_ChildThread] WARNING: pipe error (3): Socket is not connected: file /tmp/ports/usr/ports/www/firefox/work/firefox-68.0/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 358

— почему информация времени компиляции firefox попала в его рантайм? (firefox-68.0 откомпилирован gcc9-9.1.0)

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

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

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




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

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