После года разработки опубликован (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
Ммм, а -fipa-pta так и не починили?
Кхх гм ну что ж хорошая новость.Сейчас перекомпилирую 1041 исходный текст.Жаль только что опять OpenACC ни как а я уж по старости своей наивной понадеился на свою rx580 заместо процессора.
>ни как, понадеился, заместоУх!
стухл
мда, чую как корабль назовешь так оно и поплывет
еще не допилили, а уже сТУх
>реализована бо́льшая часть спецификации параллельного программирования OpenACC 2.5Эх, старик, трах тебя тибедох. (C) Прочитай новость в более сильных очках.
А что там в C2k нового? Какие интересности завезли?
utf8, constexpr, auto.
constexpr и auto уже в 11-м были, не?
C2x это сишный стандарт.
В плюсах были, в C нет.
Долбо* неразличающий сиплюсплюс и чистый си
Печально, но в OBS-репозитории devel:gcc/SLE_11 его уже не будет. Из-за прекращения основной поддержки. А жаль. Было очень удобно использовать компилятор оттуда для билд-фермы. А devtoolset для CentOS не настолько удобный
D и бэкэнды для AMD GPU и OpenRISC? Добротный релиз, ничего не скажешь
Ну все перекомпилировал не собрался 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 часов ушло наверно тротлил хад.
Только qt с графитом потом рандомно крашится и зависает, в кедах особенно классно сидеть. И вообще фигня, ни одна программа не показала выигрыша в производительности с ним. Лто хотя бы бинарники меньше делает, для плюсовых программ хорошо. А вот пго топчик, оптимизирует без заморочек написанный код (ручками можно того же добиться).Короче, отключайте всю эту дpянь.
Не надо обобщать. У меня не крашится например.
Может дело в кедах?
Хмм возможно и так но проблем с крашами не наблюдал ну скорее всего нет большого количества специфичных программ для серьезной работы где нужна стабильность.Так себе небольшой сервер и мультимедиа десктоп.Да конечно в продакшен с такими флагами ни ни согласен.А лто да еще года четыре назад юзал сравнивал размер бинарников ну и т.д.Главная проблема лто в роллинг бэйс операционках (при обновленнии системы)это изменение версий программ и их кода что ведет по моему опыту к неработоспособности и глюкам программ так как слетает линковка всяких там библиотек или удаление из исходника того что должно работать с другой частью зависимого кода glibc например что и приводит в итоге к глючному бинарнику.Вот как пример собрал не давно лису с лто -march=native -02 и gold линкером (ни какого хардкора)и что в лисе перестал сохранятся масштаб текста и всего отображаемого на странице выставлял +200% при перезагрузке браузера опять 100% -это нужно для больших экранов при просмотре с расстояния чтоб увеличить размер всего на странице.По моему скромному мнению лто хорош на специальных проектах собрал и забыл.Да конечно есть автоматизированный си-ай интегрейшн но это работает в конторах (постоянная сборка пересборка мержка и т.д)а дома лто ну его нафиг нет времени разбираться в багах и зависимостях денег за это не заплатят а система упадет.
Гм с профилированием PGO надо по думать.Только оно т.е пго для для небольшого количества программ предназначено (ну в gentoo например).Да предполагаю что любой код можно профилировать но это надо вносить изменения в средство разработки или в билды и т.д.Да и с сценарием работы кода тоже не ясно какая последовательность выполнения модулей блоков алгоритмов чаще выполняется.Набрать статистику работы можно но это не решает всех возможных вариантов работы программы.Так что вопросов очень много.Возможно надо придерживаться золотой середины.
Да и с графитом не понятно я не кодер.Какие циклы в каком коде если С++ как часто повторяются и есть ли смысл их обьеденять сокращать и т.д что это даст?
>case 2: how = 205; break; case 3: how = 305; break;Это - говнокод, оптимизировать его так смысла не имеет. Имеет смысл уволить того, кто такое пишет, так как оптимизированный компилятором вариант проще для понимания, чем исходный.
Нет. В реальном коде это выглядит обычно так: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, код либо продолжает работать, либо выкидывает варнинги/ошибки в процессе компиляции.
Про EXPECTO_PATRONUM осилил эхх тяжело мне новые знания даются с трудом ну ни чего прорвемся все собираюсь собираюсь начать учить C++ и все никак старик как ни как.Спасибо за разьяснения.
Иди лучше русский изучи, дедунь. Я вот тоже не знаю, куда ставить запятые, а куда нет, но если ты их совсем не ставишь, читать крайне сложно. Если по другим твоим сообщениям посмотреть, то тебе и тему слитно/раздельно следует освежить в памяти. Изучи русский. Забей на IT, это не для тебя.
Мне уже 74 год что ты хочешь.Вот доживешь до мои годков тогда посмотрим.А русский я плохо знаю так как родился в Киеве а вырос в германии.Не обижайся если что.
> Вот доживешь до мои годков тогда посмотрим.Это ты излишне оптимистично использовал тут множественное число.
Мне кажется, что в немецком письменном также принято ставить запятые и пробелы после запятых и точек. 74 года - не оправдание.
> Мне уже 74 год что ты хочешь.Вот доживешь до мои годков тогда
> посмотрим.А русский я плохо знаю так как родился в Киеве а
> вырос в германии.Ja ne, is klar!
Mein lieber Herr Gesangsverein, Sachen jibt's dat jibt's gar nit!
>Запросто может не быть единой формулы для всех 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;
};
> Не надо просто валить всё в кучу. Если есть подобная структура в
> енамах, то это говорит о том, что иут надо не в
> 1 енам всё мешать, а разделить по разным полям в структуре
> и передавать не инты, а структуры.
> надо не в 1 енам...
> надоКому надо? Зачем надо? Ты уверен, что этот подход сработает всегда? Скажем, если значения нашего enum'а взяты из /etc/services или ещё откуда? Ты уверен, что вся информация связанная с константой обязательно влезет в машинное слово, в том числе и каноническое имя для этой константы, и ещё описание для пользователя, если он захочет больше подробностей? С переводами на пару десятков языков.
>если значения нашего enum'а взяты из /etc/servicesЩИТО? в /etc/services нет перечислений, там только номера портов
>Ты уверен, что вся информация связанная с константой обязательно влезет в машинное слово, в том числе и каноническое имя для этой константы, и ещё описание для пользователя, если он захочет больше подробностей? С переводами на пару десятков языков.
Вы вообще о чём? Мы говорим о перечислениях и о конкретной оптимизации и о том, почему лучше уволить разраба, к коду которого она применима. Если вам надо таскать всю указанную информацию, то перечислением и той конкретной оптимизацией тут и не пахнет.
>>если значения нашего 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 отрицательными.
> _descriptions было бы круто спрятать из .h файла куда-нибудь, но тогда не удастся следующие
> функции заинлайнить статически (это дурацкие ограничения C, их может быть можно обойти инлайном
> в линк-тайме, но я не знаю об этом ничего -- слышал звон, да не знаю где он).extern struct ServiceDescription _descriptions[];
и все отлично инлайнится.
А за написание в хедереstatic struct ServiceDescription { ... } _descriptions[] = { ... }
обычно бьют канделябром по голове, потому в каждом .c, включившем этот .h оседает своя
собственная копия _descriptions[]
> А за написание в хедере
> static struct ServiceDescription { ... } _descriptions[] = { ... }
> обычно бьют канделябром по голове, потому в каждом .c, включившем этот .h
> оседает своя
> собственная копия _descriptions[]А, да, я забыл. Видишь, это именно те самые глупости в C, которые делают его окаменевшим дерьмом мамонта.
Неосилятор, или табы правильно расставляй в своей молодежной огороженной песочнице.
> Неосилятор, или табы правильно расставляй в своей молодежной огороженной песочнице.Ты пробовал когда-нибудь переключаться между языками? C'шная идея include'ов -- это c'шная идея, которая несколько перпендикулярна идее модуля. Когда ты привыкаешь к модулям, нужно некоторое время, чтобы вернуться к мышлению уровня конкатенации файлов.
> C'шная идея include'овВообще-то изначально не сишная, а плюсовая.
Да-да-да, это не ты болтливая бестолочь, это C плохой.
> Да-да-да, это не ты болтливая бестолочь, это C плохой.Это настолько очевидно, что я не вижу даже что тебя подвинуло об этом писать.
> Как с /etc/services работать из C?Это же азы С - struct servent *getservbyname(cont char *name, const char *proto);
А у вас что это за треш навелосипедился?
>> Как с /etc/services работать из C?
> Это же азы С - struct servent *getservbyname(cont char *name, const char
> *proto);
> А у вас что это за треш навелосипедился?Дитятко, я выше специально сделал оговорку ради этого. Вот специально: я был уверен, что найдётся вундеркинд типа тебя.
Вы, извиняюсь, на чем пишете?Потому как при изменении хидера полюбому надо пересобирать проект - что с оптимизацией, что без, код не будет соответствовать новым условиям.
> Вы, извиняюсь, на чем пишете?
> Потому как при изменении хидера полюбому надо пересобирать проект - что с
> оптимизацией, что без, код не будет соответствовать новым условиям.Проблема в том, что некоторые изменения хидера не решаются пересборкой проекта. Если хидер написан неудачно или используется не так, как задумано автором этого хидера (что тоже в общем-то попадает в категорию "неудачно написан"), то изменения хидера требуют аудита всего кода, который этим хидером пользуется.
> мы получим нелокальный баг --
> ты вносишь изменения в один файл, а баг привносится в совершенно
> другой файл, может быть даже в другом проекте.Ошибка второго порядка?
> Ошибка второго порядка?Я не знаю, есть ли для таких ошибок специальное название. Может быть "не локальная ошибка"?
>Currently devices using Nvidia PTX (nvptx) are supported, and AMD GCN device support is in development.Чувствую я, владельцев старых карты вообще прокинут и во всех новых приложениях будет требование post-gcn карт.
Я бы может быть и купил бы карту (очень жаль, что купить новую кар у за сколько там тыщ будет дешевле, чем работать фуллтайм над допилом всего того софта, её дропнувшего, а потом убеждать всяких **** включить в дистрибутивы софт с лишними функциями, не нужными 99,99% пользователей. потому что у всех уже новые карты), но мой блок питания (450 W, охренеть, почти полкиловатта системник потреблял 10 лет назад, что де теперь творится?) впритык тянет всё то говно, что понапихано в мой системник.
Если у тебя 450W блок питания уже 10 лет, то очень скоро он может перестать тянуть даже то самое, поставленное те же 10 лет назад. Если в нем заменить электролиты, то спокойно будет тянуть системник вида 9700 (без К) и 1060. Они укладываются в 250 ватт потребления.
>Добавлена экспериментальная поддержка части будущего стандарта языка Си, развиваемого под кодовым именем C2x. Для включения поддержки C2x следует использовать опции "-std=c2x" и "-std=gnu2x" (для включения расширений GNU).В CMake ещё не впилили: https://cmake.org/cmake/help/latest/prop_tgt/CXX_STANDARD.html
Правильная ссылка: https://cmake.org/cmake/help/latest/prop_tgt/C_STANDARD.html
Безобразие, конечно: позавчера вышел компилятор, а в вышедшую две недели назад версию сборочной системы его новые фичи ещё не завезли!
Вообще-то впилить можно было бы сразу после того, как определились с названием стандарта, так как флаг выводится из него.
Там с самим стандартом ещё не очень определились.
> Безобразие, конечно: позавчера вышел компилятор, а в вышедшую две недели назад версию сборочной системы его новые фичи ещё не завезли!Это проблема сборочной системы, которую надо править после каждого релиза компилятора. В автотулзах уже есть:
CFLAGS=-std=c2x ./configure...
Ты вообще в курсе, для чего autocrap и cmake придуманы? Вот как раз для того, чтобы не надо было все эти параметры ручками указывать, к тому же во время сборки (собирает юзер, который знать не знает, какой там стандарт нужен). Но в autocrap для сишных стандартов макроса вообще не завезли, только для плюсов есть ax_cxx_compile_stdcxx. Так что чья б корова мычала.
P. S. для особо одарённых: конечно же, можно сделать cmake -DCMAKE_C_FLAGS=-std=c2x. Но это неправильное решение.
>Прекращена поддержка архитектур Armv2, Armv3, Armv5 и Armv5EТаким образом ведь и i686 дропнут.
Просто пользуемся предыдущей версией. Никаких исправлений тут все равно нету, одни мало кому нужные фичи.
i686 Еше жива...ужось.)
Вы же тут поголовно ценители прогресса.
Мне P-II надо чтобы работал!
Есть такая линейка процессоров от Intel - Atom-ы называются. Там только сравнительно недавно x86-64 завезли, а до того, считай, тот i686 и только и был.
Среди всех этих новостей про жавы, руби, электроны... Хоть что-то краСИвое, вечное, доброе!
>Процесс включения поддержки языка D в GCC начался ещё в 2011 году, но затянулсяТак затянулся, что через пару релизов пора будет депрекейтить, за ненадобностью
>> Armv5 и Armv5Eчего выкинули? (
/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 1Stop.
make[4]: stopped in /usr/src/gnu/lib/libstdc++
> firefoxJavaScript 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)