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

28.04.2021 13:40

После года разработки опубликован релиз свободного набора компиляторов GCC 11.1, первый значительный выпуск в новой ветке GCC 11.x. В соответствии с новой схемой нумерации выпусков, версия 11.0 использовалась в процессе разработки, а незадолго до выхода GCC 11.1 уже ответвилась ветка GCC 12.0, на базе которой будет сформирован следующий значительный релиз GCC 12.1.

GCC 11.1 примечателен переходом на использование по умолчанию формата отладочных файлов DWARF 5, включением по умолчанию стандарта C++17 ("-std=gnu++17"), значительным улучшением поддержки стандарта C++20, экспериментальной поддержкой C++23, улучшениями, связанными с будущим стандартом языка Си (C2x), новыми оптимизациями производительности.

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

Режим по умолчанию для языка C++ переключён на использование стандарта C++17 (-std=gnu++17) вместо ранее предлагавшегося C++14. Возможно выборочное отключение нового поведения C++17 при обработке шаблонов, в которых в качестве параметра используются другие шаблоны (-fno-new-ttp-matching).
Добавлена поддержка аппаратного ускорения работы инструмента AddressSanitizer, позволяющего определить факты обращения к освобождённым областям памяти, выхода за пределы границ выделенного буфера и некоторые другие типы ошибок при работе с памятью. Аппаратное ускорение пока доступно только для архитектуры AArch64 и сосредоточено на использовании при компиляции ядра Linux. Для включения аппаратного ускорения AddressSanitizer при сборке компонентов пространства пользователя добавлен флаг "-fsanitize=hwaddress", а ядра - "-fsanitize=kernel-hwaddress".
При генерации отладочной информации по умолчанию задействован формат DWARF 5, по сравнению с прошлыми версиями позволяющий генерировать на 25% более компактные отладочные данные. Для полной поддержки DWARF 5 требуется binutils как минимум версии 2.35.2. В отладочных инструментах формат DWARF 5 поддерживается начиная с GDB 8.0, valgrind 3.17.0, elfutils 0.172 и dwz 0.14. Для генерации отладочных файлов с использованием других версий DWARF можно использовать опции "-gdwarf-2", "-gdwarf-3" и "-gdwarf-4".
Повышены требования к компиляторам, которые можно использовать для сборки GCC. Компилятор теперь должен поддерживать стандарт C++11 (ранее требовался C++98), т.е. если для сборки GCC 10 достаточно было наличия GCC 3.4, то для сборки GCC 11 теперь требуется как минимум GCC 4.8.
Изменено наименование и размещение файлов для сохранения дампов, временных файлов и дополнительной информации, необходимой для проведения LTO-оптимизации. Подобные файлы теперь всегда сохраняются в текущем каталоге, если путь явно не изменён через параметры "-dumpbase", "-dumpdir" и "-save-temps=*".
Объявлена устаревшей и скоро будет удалена поддержка бинарного формата BRIG, предназначенного для использования с языком HSAIL (Heterogeneous System Architecture Intermediate Language).
Расширены возможности режима ThreadSanitizer (-fsanitize=thread), предназначенного для обнаружения состояния гонки при совместном доступе к одним и тем же данным из различных нитей многопоточного приложения. В новом выпуске добавлена поддержка альтернативных runtime и окружений, а также поддержка отладочного инструмента KCSAN (Kernel Concurrency Sanitizer), предназначенного для динамического выявления состояний гонки внутри ядра Linux. Добавлены новые опции "--param tsan-distinguish-volatile" и "--param tsan-instrument-func-entry-exit".
Номера столбцов в диагностических сообщениях теперь отражают не счётчик байт от начала строки, а действительно номера столбцов, учитывающих многобайтовые символы и символы занимающие несколько позиций в строке (например, символ 🙂 занимает две позиции и кодируется 4 байтами). Аналогично символы табуляции теперь обрабатываются как определённое число пробелов (настраивается через опцию -ftabstop, по умолчанию 8). Для восстановления старого поведения предложена опция "-fdiagnostics-column-unit=byte", а для определения начального значения (нумерация с 0 или 1) - опция "-fdiagnostics-column-origin=".
В векторизаторе обеспечен учёт всего содержимого функции и добавлена обработка возможностей, связанных с пересечениями и отсылками к предыдущим блокам в графе потока управления (CFG, control-flow graph).
В оптимизаторе реализована возможность преобразования в выражение switch серии условных операций, в которых сравнивается одна и та же переменная. В дальнейшем выражение switch может быть закодировано с применением инструкций битового тестирования (для управления подобным преобразованием добавлена опция "-fbit-tests").
Улучшены межпроцедурные оптимизации. Добавлен новый проход IPA-modref (-fipa-modref) для отслеживания побочных эффектов при вызове функций и повышения точности анализа. Улучшена реализация прохода IPA-ICF (-fipa-icf), в котором сокращено потребление памяти при компиляции и увеличено число унифицированных функций, для которых выполняется объединение идентичных блоков кода. В проходе IPA-CP (Interprocedural constant propagation) улучшена эвристика по прогнозированию с учётом известных границ и особенностей работы циклов.
В реализации оптимизаций на этапе связывания (LTO) формат байткода оптимизирован для сокращения размера и повышения скорости обработки. Уменьшено пиковое потребление памяти на этапе связывания.
В механизме оптимизации на основе результатов профилирования кода (PGO - Profile-guided optimization), позволяющем генерировать более оптимальный код на основе анализа особенностей выполнения, сокращён размер файлов с данными GCOV за счёт более компактной упаковки нулевых счётчиков. Улучшен режим "-fprofile-values", благодаря отслеживанию большего числа параметров при косвенных вызовах.
Продолжена реализация стандарта OpenMP 5.0 (Open Multi-Processing), определяющего API и способы применения методов параллельного программирования на многоядерных и гибридных (CPU+GPU/DSP) системах с общей памятью и блоками векторизации (SIMD). Добавлена начальная поддержка директивы allocate и возможность использования неоднородных циклов в конструкциях OpenMP. Реализована поддержка переменной окружения OMP_TARGET_OFFLOAD.
Улучшена предоставляемая для языков C, C++ и Fortran реализация спецификации параллельного программирования OpenACC 2.6, определяющей средства для выноса операций (offloading) на GPU и специализированные процессоры, такие как NVIDIA PTX.
Для языков семейства Си реализован новый атрибут "no_stack_protector", предназначенный для пометки функций для которых не следует включать защиту стека ("-fstack-protector"). Атрибут "malloc" расширен поддержкой идентификации пар вызовов для выделения и освобождения памяти (allocator/deallocator), что используется в статическом анализаторе для определения типовых ошибок работы с памятью (утечки памяти, использование после освобождения, двойной вызов функции free и т.п.) и в предупреждениях компилятора "-Wmismatched-dealloc", "-Wmismatched-new-delete" и "-Wfree-nonheap-object", информирующих о несогласованности операций освобождения и выделения памяти.
Для языка Си добавлены новые предупреждения:
- "-Wmismatched-dealloc" (включён по умолчанию) - предупреждает об операциях освобождения памяти в которых используется указатель, не сочетающийся с функциями выделения памяти.
- "-Wsizeof-array-div" (включается при указании "-Wall") - предупреждает о делении двух операторов sizeof, если делитель не соответствует размеру элемента массива.
- "-Wstringop-overread" (включён по умолчанию) - предупреждает о вызове строковой функции, читающей данные из области вне границы массива.
- "-Wtsan" (включён по умолчанию) - предупреждает о использовании возможностей (таких как std::atomic_thread_fence), не поддерживаемых в ThreadSanitizer.
- "-Warray-parameter" и "-Wvla-parameter" (включается при указании "-Wall") - предупреждает о переопределении функций с не сочетающимся объявлением аргументов, связанных с массивами фиксированной и переменной длины.
- Предупреждение "-Wuninitialized" теперь определяет попытки чтения из неинициализированной динамически выделенной памяти.
- В предупреждении "-Wfree-nonheap-object" расширен спектр определяемых случаев вызова функций освобождения памяти с указателем, полученным не через функции динамического выделения памяти.
- В предупреждении "-Wmaybe-uninitialized" расширено выявление передачи в функции указателей, ссылающихся на неинициализированные области памяти.
Для языка Си реализована порция новых возможностей, развиваемых в рамках стандарта C2X (включается через указание -std=c2x и -std=gnu2x): макросы BOOL_MAX и BOOL_WIDTH, необязательность указания имён неиспользуемых параметров в определениях функций (как в C++), атрибут "[[nodiscard]]", оператор препроцессора "__has_c_attribute", макросы FLT_IS_IEC_60559, DBL_IS_IEC_60559, LDBL_IS_IEC_60559, __STDC_WANT_IEC_60559_EXT__, INFINITY, NAN, FLT_SNAN, DBL_SNAN, LDBL_SNAN, DEC_INFINITY и DEC_NAN, NaN=макросы для FloatN, _FloatNx и _DecimalN, возможность указания меток перехода до объявлений и в конце составных операторов.
Для C++ реализована порция изменений и новшеств, предложенных в стандарте C++20, включая виртуальные функции "consteval virtual", псевдодеструкторы окончания жизненного цикла объектов, использование класса enum и вычисление размера массива в выражении "new".
Для C++ добавлена экспериментальная поддержка некоторых улучшений, развиваемых для будущего стандарта C++23 (-std=c++23, -std=gnu++23, -std=c++2b, -std=gnu++2b). Например, появилась поддержка литерального суффикса "zu" для знаковых значений size_t.
В libstdc++ улучшена поддержка стандарта C++17, включая появление реализации std::from_chars и std::to_chars для типов с плавающей запятой. Реализованы новые элементы стандарта C++20, включая std::bit_cast, std::source_location, атомарные операции wait и notify, <barrier>, <latch>, <semaphore>, <syncstream>, а также элементы будущего стандарта C++23 (std::to_underlying, std::is_scoped_enum). Добавлена экспериментальная поддержка типов для параллельной обработки данных (SIMD, Data-Parallel Types). Ускорена реализация std::uniform_int_distribution.
Снят признак альфа-качества с libgccjit, разделяемой библиотеки для встраивания генератора кода в другие процессы и использования для организации JIT-компиляции байткода в машинный код. Добавлена возможность сборки libgccjit для MinGW.
Добавлена поддержка архитектуры AArch64 Armv8-R (-march=armv8-r). Для архитектур AArch64 и ARM добавлена поддержка процессоров (параметры -mcpu и -mtune): Arm Cortex-A78 (cortex-a78), Arm Cortex-A78AE (cortex-a78ae), Arm Cortex-A78C (cortex-a78c), Arm Cortex-X1 (cortex-x1), Arm Neoverse V1 (neoverse-v1) и Arm Neoverse N2 (neoverse-n2). Также добавлены CPU Fujitsu A64FX (a64fx) и Arm Cortex-R82 (cortex-r82), поддерживающие только архитектуру AArch64.
Добавлена поддержка использования SIMD-инструкций Armv8.3-a (AArch64/AArch32), SVE (AArch64), SVE2 (AArch64) и MVE (AArch32 M-profile) для автовекторизации операций, выполняющих сложение, вычитание, умножение и варианты сложения/вычитания над комплексными числами. Для ARM добавлена начальная поддержка автовекторизации с использованием набора инструкций MVE.
Для ARM-платформ предоставлен полный набор встроенных в компилятор Си-функций (Intrinsics), заменяемых на расширенные векторные инструкции (SIMD), охватывающий все инструкции NEON, документированные в спецификации ACLE Q3 2020.
В бэкенд для генерации кода для GPU AMD на базе микроархитектуры GCN добавлена поддержка GPU gfx908.
Добавлена поддержка новых процессоров и реализованных в них новых расширений набора инструкций:
- Intel Sapphire Rapids (-march=sapphirerapids, включает поддержку инструкций MOVDIRI, MOVDIR64B, AVX512VP2INTERSECT, ENQCMD, CLDEMOTE, SERIALIZE, PTWRITE, WAITPKG, TSXLDTRK, AMT-TILE, AMX-INT8, AMX-BF16 и AVX-VNNI).
- Intel Alderlake (-march=alderlake, включает поддержку инструкций CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, KEYLOCKER, AVX-VNNI и HRESET).
- Intel Rocketlake (-march=rocketlake, аналог Rocket Lake без поддержки SGX).
- AMD Zen 3 (-march=znver3).
Для систем IA-32/x86-64 на базе процессоров Intel добавлена поддержка новых процессорных инструкций TSXLDTRK, SERIALIZE, HRESET, UINTRKEYLOCKER, AMX-TILE, AMX-INT8, AMX-BF16, AVX-VNNI.
Добавлена поддержка флагов "-march=x86-64-v[234]" для выбора уровней архитектуры x86-64 (v2 - охватывает расширения SSE4.2, SSSE3, POPCNT и CMPXCHG16B; v3 - AVX2 и MOVBE; v4 - AVX-512).
Добавлена поддержка систем RISC-V с порядком следования байт "big-endian". Добавлена опция "-misa-spec=*" для выбора версии спецификации архитектуры набора команд RISC-V. Добавлена поддержка AddressSanitizer и защиты стека при помощи канареечных меток.
Продолжено усовершенствование режима статического анализа "-fanalyzer", который выполняет ресурсоёмкий межпроцедурный анализ путей выполнения кода и потоков данных в программе. Режим способен на этапе компиляции выявлять такие проблемы, как двойной вызов функции free() для одной области памяти, утечки файловых дескрипторов, разыменование и передачу нулевых указателей, обращение к освобождённым блокам памяти, использование неинициализированных значений и т.п. В новой версии:
- Полностью переписан код для отслеживания состояния программы. Решены проблемы с проверкой очень больших Си-файлов.
- Добавлена начальная поддержка C++.
- Анализ выделения и освобождения памяти абстрагирован от конкретных функций malloc и free, и теперь поддерживает new/delete и new[]/delete[].
- Добавлены новые предупреждения: -Wanalyzer-shift-count-negative, -Wanalyzer-shift-count-overflow, -Wanalyzer-write-to-const и -Wanalyzer-write-to-string-literal.
- Добавлены новые отладочные опции -fdump-analyzer-json и -fno-analyzer-feasibility.
- Реализована возможность расширения анализатора через плагины к GCC (например, подготовлен плагин для проверки некорректного использования глобальной блокировки (GIL) в CPython).

исправить +53 +/–

Лицензия: CC BY 3.0

Короткая ссылка: https://opennet.ru/55035-gcc

Ключевые слова: gcc

При перепечатке указание ссылки на opennet.ru обязательно

Обсуждение (107)

1.1, ryoken (ok), 14:11, 28/04/2021 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ] [к модератору]	+/–

2.2, Корец (?), 14:24, 28/04/2021 Скрыто ботом-модератором [к модератору]	–1 +/–

3.6, Аноним (-), 14:31, 28/04/2021 Скрыто ботом-модератором [к модератору]	–1 +/–

2.4, Mike Lee (?), 14:26, 28/04/2021 Скрыто ботом-модератором [к модератору]	+/–

3.7, ryoken (ok), 14:42, 28/04/2021 Скрыто ботом-модератором [к модератору]	–2 +/–

....ответы скрыты (4)

1.3, Аноним (3), 14:26, 28/04/2021 [ответить] [﹢﹢﹢] [ · · · ]

–1 +/–

Я так понимаю использование

>режима статического анализа "-fanalyzer"

переводит Rust в статус deprecated.

2.14, Аноним (-), 15:41, 28/04/2021 [^] [^^] [^^^] [ответить]

–12 +/–

> Я так понимаю использование
>> режима статического анализа "-fanalyzer"
> переводит Rust в статус deprecated.

Я так понимаю, очередной опеннетный комментатор с познаниями уровня "слышал звон"?
https://www.opennet.dev/opennews/art.shtml?num=53208
> Релиз статического анализатора cppcheck 2.1

https://clang-analyzer.llvm.org/
> The Clang Static Analyzer is a source code analysis tool that finds bugs in C, C++, and Objective-C programs.

https://www.frama-c.com/
https://coccinelle.gitlabpages.inria.fr/website/
...

3.15, Аноним (15), 15:45, 28/04/2021 Скрыто ботом-модератором [к модератору]	+3 +/–

4.36, Аноним (-), 17:42, 28/04/2021 Скрыто ботом-модератором [к модератору]	+/–

3.22, Аноним (3), 16:14, 28/04/2021 [^] [^^] [^^^] [ответить]	–6 +/–
Это статические анализаторы, которые смотрят ошибки по тексту кода. А "-fanalyzer" компилирует код и по ходу выполнения смотрит ошибки, что, как я понима делает и компилятор Rust. В это смысле достугается паритет. Достугнут он лили нет - вряд ли - не берусь судить.

4.26, ranen (?), 16:33, 28/04/2021 [^] [^^] [^^^] [ответить]	+5 +/–
Компилятор Rust так не делает.

5.91, Аноним (91), 01:36, 01/05/2021 [^] [^^] [^^^] [ответить]	+/–
> так не делает. делает всё не так :)

4.40, Аноним (-), 18:00, 28/04/2021 [^] [^^] [^^^] [ответить]

+1 +/–

> Это статические анализаторы, которые смотрят ошибки по тексту кода. А "-fanalyzer" компилирует код и по ходу выполнения смотрит ошибки, что, как я понима делает и компилятор Rust.
>> Clang Static Analyzer
>> It implements path-sensitive, inter-procedural analysis based on symbolic execution technique.

Как я и подозревал - анализ уровня "слышал звон". И даже по ссылкам не ходил.

> В это смысле достугается паритет.

Там нужно конкретно так смотреть на объем и качество анализа, иначе "ни о чем".

5.42, Аноним (42), 18:40, 28/04/2021 [^] [^^] [^^^] [ответить]	+/–
>> It implements path-sensitive, inter-procedural analysis based on symbolic execution technique. >Как я и подозревал - анализ уровня "слышал звон". И даже по ссылкам не ходил. Мда, как то эта информация прошла мимо :( Буду знать какой оказывается Clang Static Analyzer

2.19, Аноним (19), 15:57, 28/04/2021 [^] [^^] [^^^] [ответить]	+/–
Беда в том, что рантайм проверки очень дорогие для приложения. Если придумать некий специальный рантайм для плюсов, проблемы с производительностью у него будут ровно те же, что и у раста. В целом же, раст стоит расценивать исключительно как площадку для экспериментов по улучшению плюсов, а не как замену чему бы то ни было, поэтому выкидывать в ближайшее время ничего не будут.

3.20, Аноним (3), 16:08, 28/04/2021 [^] [^^] [^^^] [ответить]	+/–
Ну так опция -fanalyzer включается только в dev окружении и выключается в релизе.

3.21, Wladmis (ok), 16:12, 28/04/2021 [^] [^^] [^^^] [ответить]	+4 +/–
У Rust как раз-таки большинство проверок на этапе компиляции.

3.27, Маняним (?), 16:56, 28/04/2021 [^] [^^] [^^^] [ответить]	+2 +/–
Какие рантайм проверки? Вы хоть читайте. Это статический, компайл-тайм анализ кода на перечеслинные дефекты. Именно о чем кричат растофилы. Только для такого контроля не надо пердолиться с явным обозначением лайфтайма объектов в языке, изобретать ансейф-код для создания двух и более модифицирующих ссылок, даже в сингл-треде. Анализ кода во-время компиляции основывается на вычислениях во время компиляции и анализе путей исполнения кода. И у компилятора гораздо больше информации о путях исполнения кода чем у внешнего анализатора, которому по сути нужно проделять ту же самую работу чтобы получить её.

4.32, Аноним (19), 17:06, 28/04/2021 [^] [^^] [^^^] [ответить]	–6 +/–
Компайл тайм раста по сути бесполезен и является сахаром ради сахара -- сегодняшние анализаторы ничем не хуже. Весь профит в рантайм проверках.

5.37, Аноним (37), 17:46, 28/04/2021 [^] [^^] [^^^] [ответить]	+2 +/–
Компайл тайм раста, в отличие от обычных анализаторов, дает гарантии

6.43, Аноним (19), 19:06, 28/04/2021 [^] [^^] [^^^] [ответить]	–2 +/–
> Компайл тайм раста, в отличие от обычных анализаторов, дает гарантии Только на той неделе UB в safe исправляли -- так себе гарантии/

7.53, Аноним (53), 21:30, 28/04/2021 [^] [^^] [^^^] [ответить]	+1 +/–
C ++ появился в 1983. И базируется он на Си, который появился вообще в 1972. Rust появился в 2010 и сейчас активно развивается. Ничего удивительного что в нем находят огрехи. Вы лучше ответьте на вопрос, раз С++ так крут, как в нем решена проблема копирования перекрывающихся областей памяти в куче? Я вам сразу скажу - никак. В языке вся работа с памятью на указателях, и у компилятора нет гарантий, что копируемые участки гарантированно не пересекаются. А значит он не может провести часть оптимизаций и предрасчётов во время компиляции, не может векторизовать цикл копирования, и не может распараллелить его. В Rust эта и многие дугие проблемы изначально отсутствуют.

8.55, Аноним (19), 21:32, 28/04/2021 [^] [^^] [^^^] [ответить]	–5 +/–
Найс сравнение, ты ещё науку 5000 лет назад сравни с нынешней ... текст свёрнут, показать

8.71, n00by (ok), 11:00, 29/04/2021 [^] [^^] [^^^] [ответить]	+2 +/–
Проиллюстрируйте проблему примером кода, что бы было понятно, о чём речь ... текст свёрнут, показать

8.75, zzxc (?), 15:57, 29/04/2021 [^] [^^] [^^^] [ответить]	+2 +/–
В плюсах никак, потому-что это было решено еще в C memmove ... текст свёрнут, показать

8.78, Cooler (??), 20:33, 29/04/2021 [^] [^^] [^^^] [ответить]	+2 +/–
memmove и __restrict тебе помогут ... текст свёрнут, показать

8.93, Алкоганон (?), 05:07, 02/05/2021 [^] [^^] [^^^] [ответить]	+/–
- memcpy гарантирует неперекрываемость И очередное UB в случае перекрытия ... текст свёрнут, показать

8.96, uis (ok), 11:35, 02/05/2021 [^] [^^] [^^^] [ответить]	+/–
restrict RTFM ... текст свёрнут, показать

8.109, Аноним (-), 14:58, 11/05/2021 [^] [^^] [^^^] [ответить]	–1 +/–
Не понимаю проблему Я даже примитивный memmove накодил под baremetal Для рас... текст свёрнут, показать

9.111, Аноним (-), 00:07, 16/05/2021 [^] [^^] [^^^] [ответить]	+/–
Ничего удивительного - ты даже прочитать текст целиком не можешь, куда уж тут п... текст свёрнут, показать

6.46, Аноним (46), 20:22, 28/04/2021 [^] [^^] [^^^] [ответить]	–4 +/–
Единственные гарантии которые может дать rust это боль пониже спины у анонимных экспертов

2.33, ranen (?), 17:12, 28/04/2021 [^] [^^] [^^^] [ответить]	+/–
Я уверен, что ни один уважающий себя с-программист не будет использовать этот режим, иначе он испытает такое унижение, что никогда не будет больше программировать!

3.44, Noard (?), 19:46, 28/04/2021 [^] [^^] [^^^] [ответить]	–3 +/–
Маловероятно, в этом режиме ничто сложнее студенческих поделок не скомпилируется, си-ппограммисты настолько малоквалифицированны, в настоящее время, что не понимают, что весь объем легаси - это сплошные некорректные трюки (те-же трюки с кучей), а то, что еще может пройти проверку - безбожно тормозящее... и суть появления ржавчины - избавление от трюкачеств в легаси, да, эта проверка этому поможет, но "си-кодеры" не способны осознать, что проще - воспользоваться адекватным инструментом: ржавчиной или плюсами, чем приводить допотопный код на допотопном языке для допотопных контролеров в компилируемое состояние...

4.49, валяйте (?), 21:00, 28/04/2021 [^] [^^] [^^^] [ответить]	+/–
Есть примеры и код чтобы подтвердить или просто попердываешь?

4.67, ixrws (??), 09:37, 29/04/2021 [^] [^^] [^^^] [ответить]	+/–
Очередной ыксперт, сколько же вас развелось то. Никто бы не стал включать этот режим в gcc, если бы он годился только для просты семплов. Практика показывает, что если код работает корректно на хотя бы 2х различных платформах(а большинство системных С программ работает на хотя бы x86, x86_64, arm и mips), то неведомого трюкачества в коде очень мало и он вполне себе проходит статический анализ. Да, там могут быть косяки, но их крайне мало. А вы, уважаемый ыксперт, просто не знаете насколько много трюков и проблем приходится выпиливать из кода, когда он приколочен к одной ОС и к одной аппаратной платформе. Если же он не приколочен, то и трюков так сильно меньше, потому что та же арифметика указателей без понимания как она работает, хрена с два заработает без багов на разных платформах.

4.79, iZEN (ok), 20:36, 29/04/2021 [^] [^^] [^^^] [ответить]	+/–
> воспользоваться адекватным инструментом: ржавчиной или плюсами, чем приводить допотопный код на допотопном языке для допотопных контролеров в компилируемое состояние... Так они и ЯП Modula-3, на котором эти проблемы давно решили, не хотят знать. Куда им ржавчину вписывать?

2.35, Аноним (37), 17:40, 28/04/2021 [^] [^^] [^^^] [ответить]	–1 +/–
Статический анализатор конечно хорошо, но у раста он ещё и с гарантиями :)

2.110, Аноним (110), 18:30, 12/05/2021 [^] [^^] [^^^] [ответить]	+/–
Ценность Rust сильно опустит поддержка GCC опции -D_FORTIFY_SOURCE=3 пока есть только 2.

1.5, Аноним (-), 14:30, 28/04/2021 [ответить] [﹢﹢﹢] [ · · · ]

+2 +/–

>улучшениями, связанными с будущим стандартом языка Си (C2x), новыми оптимизациями производительности.

Последний стандарт 18 года, полностью поддерживается? На подходе С2x

Чистый Си рулит!

2.8, Анонин (?), 14:48, 28/04/2021 [^] [^^] [^^^] [ответить]	–1 +/–
Там нет особо изменений https://en.wikipedia.org/wiki/C2x

3.28, Аноним (28), 16:57, 28/04/2021 [^] [^^] [^^^] [ответить]	+5 +/–
Сишечка настолько идеальна, что туда нечего добавить.

4.31, Анонин (?), 17:05, 28/04/2021 [^] [^^] [^^^] [ответить]	+2 +/–
Да и убирать оттуда, тоже ничего не надо.

5.45, Аноним (45), 20:01, 28/04/2021 [^] [^^] [^^^] [ответить]	–4 +/–
Как насчёт убрать оттуда отвратительную работу со строками из 70-х годов, из-за которых каждая программа на Си кишит дырами и багами?

6.48, Аноним (48), 20:58, 28/04/2021 [^] [^^] [^^^] [ответить]	–3 +/–
Да и с макросами что-то делать нужно. Негоже это, когда они чем-то сторонним обрабатываюся. Надо бы, чтобы самим компилятором, чтобы получать адекватные сообщения о проблемах.

7.57, Анонин (?), 21:51, 28/04/2021 [^] [^^] [^^^] [ответить]	+1 +/–
Легче новый язык создать.

7.69, ixrws (??), 09:47, 29/04/2021 [^] [^^] [^^^] [ответить]	+1 +/–
Макросы это макросы, они в принципе не разрабатывались так, чтобы их нужно было анализировать. Если захочется их анализировать, то возникнет вопрос что это должны быть за макросы, какими возможностями они будут обладать и возможно тогда наворотят такие макросы, что лучше всё же жить с макросами из прошлого века. Каждое решение имеет свои плюсы и свои минусы. Плюсов у С макросов достаточно, даже самый накаченный макросами код, компилируется очень быстро. Они просты, там просто нет ничего, но при этом выразительны.

6.59, pavlinux (ok), 01:26, 29/04/2021 [^] [^^] [^^^] [ответить]	+/–
Омномномнимов послушать, там ассемблер вообще язык дыр!

7.66, Анонин (?), 09:03, 29/04/2021 [^] [^^] [^^^] [ответить]	–2 +/–
Без разницы, нигде больше не используется.

8.98, pavlinux (ok), 16:59, 03/05/2021 [^] [^^] [^^^] [ответить]	+/–
Только программистам не рассказывай, а то зачмырят ... текст свёрнут, показать

6.68, ixrws (??), 09:44, 29/04/2021 [^] [^^] [^^^] [ответить]	+3 +/–
Зачем убирать? Что за привычка убирать что-то, из-за чего куча кода поломается. Ну давайте завтра давление в трубах поднимем до 10 атм или опустим до одной. Как там ваши смесители и бачки сливные у унитазов, будут работать? А ведь поднять до 10 и будет стабильнее водоснабжение на высоких этажах. И будете сами себе регуляторы давления ставить, чтобы смеситель не взорвало. Так вот, куча есть реализаций строк под различные требования. Берите и пользуйтесь. На кой чёрт тащить в стандарт это. Поймите, если вам нужна хорошая реализация строк, с хранением длины и прочего для юникода, то значительному количеству С кода из эмбеда нужны различные компактные реализации строк и они также вправе требовать их в стандарт. Ну и что получится, 20 реализаций и все в стандарт?

7.74, Аноним (-), 15:57, 29/04/2021 [^] [^^] [^^^] [ответить]	–2 +/–
переписыай под новые стандарты и не ной, показывая своё рукожопство.

6.72, n00by (ok), 11:13, 29/04/2021 [^] [^^] [^^^] [ответить]	+2 +/–
> Как насчёт убрать оттуда отвратительную работу со строками из 70-х годов, из-за > которых каждая программа на Си кишит дырами и багами? Расскажите в подробностях, кто и как заставляют Вас писать #include <string.h> Подумаем, что в такой ситуации делать.

6.77, adolfus (ok), 18:17, 29/04/2021 [^] [^^] [^^^] [ответить]	+1 +/–
strncpy strncat strxfrm И что со строками не так?

7.80, С (?), 22:25, 29/04/2021 [^] [^^] [^^^] [ответить]	–1 +/–
char abc[3]; strncpy(abc, "abc", 3); Эти функции изначально предназначались не для строк, а для "записей" (record), поэтому не просто копируют строки, но еще и добивают результат нулями до ширины поля. Или не добивают.

8.82, n00by (ok), 06:39, 30/04/2021 [^] [^^] [^^^] [ответить]	+/–
Что не так если не считать отсутствия в языке рекордов Вам не нравится, что... текст свёрнут, показать

9.84, С (?), 09:54, 30/04/2021 [^] [^^] [^^^] [ответить]	+/–
Записи не про язык, они больше про файлы В сишке представляются сишными структу... большой текст свёрнут, показать

10.85, n00by (ok), 10:57, 30/04/2021 [^] [^^] [^^^] [ответить]	+/–
Тут не экзамен, не надо выдавать почерпнутое из безусловно полезной книжки Вирта... большой текст свёрнут, показать

11.87, n00by (ok), 11:58, 30/04/2021 [^] [^^] [^^^] [ответить]	+1 +/–
В общем, вот это и есть проблема Низкоквалифицированные высокомотивированные лю... текст свёрнут, показать

11.89, С (?), 14:46, 30/04/2021 [^] [^^] [^^^] [ответить]	+/–
Не читал, осуждаю На заборе тоже сказано Наконец-то Именно об этом мы и го... большой текст свёрнут, показать

12.90, n00by (ok), 16:52, 30/04/2021 [^] [^^] [^^^] [ответить]	+/–
Это стандарт, а не забор Дальнейший твой текст читать не имеет смысла ... текст свёрнут, показать

13.99, pavlinux (ok), 17:16, 03/05/2021 [^] [^^] [^^^] [ответить]	+/–
Ви два дэбила В С ващэ нет функций Нет ля, строк ВААЩЕ, ТО ЕСТЬ САВСЕМ ... текст свёрнут, показать

14.104, n00by (ok), 08:32, 04/05/2021 [^] [^^] [^^^] [ответить]	–1 +/–
Иди проспись, а потом подумай над своим поведением ... текст свёрнут, показать

15.105, pavlinux (ok), 14:17, 04/05/2021 [^] [^^] [^^^] [ответить]	+/–
Мнение одминчега локалхоста важно Ти кто, пля, такой D ... текст свёрнут, показать

16.106, n00by (ok), 14:42, 04/05/2021 [^] [^^] [^^^] [ответить]	+/–
Я здесь малость инкогнито, но кое-что обо мне не составляет труда найти если не... текст свёрнут, показать

17.107, n00by (ok), 06:00, 06/05/2021 [^] [^^] [^^^] [ответить]	+/–
... текст свёрнут, показать

16.108, n00by (ok), 06:55, 06/05/2021 [^] [^^] [^^^] [ответить]	–1 +/–
Так и не проспался Похоже, я тебя с другим человеком перепутал, получился поклё... текст свёрнут, показать

10.86, Аноним (-), 11:10, 30/04/2021 [^] [^^] [^^^] [ответить]	+/–
Исправил ... текст свёрнут, показать

2.97, uis (ok), 11:39, 02/05/2021 [^] [^^] [^^^] [ответить]	+/–
Там починили локализацию в многопотоке?

1.9, Аноним (19), 14:54, 28/04/2021 [ответить] [﹢﹢﹢] [ · · · ]	–4 +/–
Что-то кроме ворнингов ничего полезного, разве что улучшена поддержка армов. Все прошлые обновления добавляли интересных оптимизаций или хотя бы защит.

2.11, bi brother (?), 14:57, 28/04/2021 [^] [^^] [^^^] [ответить]	+4 +/–
ты точно прочел новость?

3.12, Аноним (19), 14:58, 28/04/2021 [^] [^^] [^^^] [ответить]	–2 +/–
Я что-то пропустил?

4.16, Аначик (?), 15:50, 28/04/2021 [^] [^^] [^^^] [ответить]	+1 +/–
Да.

5.25, Аноним (19), 16:18, 28/04/2021 [^] [^^] [^^^] [ответить]	–2 +/–
> Да. Исчерпывающий ответ и грамотная аргументированная позиция, аплодирую стоя. Я, в свою очередь, могу пояснить свою позицию: никаких видимых улучшений не добавили. У 10 были осязаемые улучшения PGO и lto (скажем, поддержка zstd), дополнительная заметная логика у ipa. В 9 добавили значительные усовершенствования для PGO и LTO (наверное, самые ощутимые за всё время gcc) В 8 добавили stack-clash-protection и cf-protection. В 7 и 6, ну, подсказки к ошибкам, например. В 5 no-semantic-interposition.

6.29, Аноним (-), 16:58, 28/04/2021 [^] [^^] [^^^] [ответить]	+/–
Вливайся в стан разработчиков. Пора братан пора.

1.10, Аноним (10), 14:56, 28/04/2021 [ответить] [﹢﹢﹢] [ · · · ]	+/–
>для для сборки GCC 11 теперь требуется как минимум GCC 4.8. Враньё, не собирается.

2.13, Мелкостан (?), 15:04, 28/04/2021 [^] [^^] [^^^] [ответить]	–10 +/–
минимум GCC 4.8 <- судьба жадных компании которые знали у кого была лучшая вариация

3.17, Аначик (?), 15:51, 28/04/2021 [^] [^^] [^^^] [ответить]	+9 +/–
>судьба жадных компании которые знали у кого была лучшая вариация Мой мозг не уловил в этом сообщении логический смысл.

4.50, валяйте (?), 21:02, 28/04/2021 [^] [^^] [^^^] [ответить]	–2 +/–
Значит ты еще безработный

3.51, Аноним (51), 21:05, 28/04/2021 [^] [^^] [^^^] [ответить]	+/–
ура опеннетные боты подъехали

1.18, Аноним (18), 15:54, 28/04/2021 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ] [к модератору]	–4 +/–

1.23, Jh (?), 16:14, 28/04/2021 [ответить] [﹢﹢﹢] [ · · · ]	–1 +/–
ебилды уже подвезли)

2.41, Jh (?), 18:22, 28/04/2021 [^] [^^] [^^^] [ответить]	+/–
в принципе, сам себя откомпилировал. 10 версия у меня пару пакетов собрать не могла. Посмотрим что с 11

3.47, Аноним (48), 20:54, 28/04/2021 [^] [^^] [^^^] [ответить]	+1 +/–
Какие, если не секрет, 10-я не смогла?

2.52, Аноним (51), 21:06, 28/04/2021 [^] [^^] [^^^] [ответить]	+/–
ура пересборка мира?

1.24, Аноним (24), 16:17, 28/04/2021 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ] [к модератору]	–4 +/–

2.30, Аноним (-), 17:01, 28/04/2021 Скрыто ботом-модератором [к модератору]	–1 +/–

2.34, Аноним (48), 17:21, 28/04/2021 Скрыто ботом-модератором [к модератору]	+1 +/–

2.39, mos87 (ok), 17:51, 28/04/2021 Скрыто ботом-модератором [к модератору]	+1 +/–

....ответы скрыты (3)

1.58, menangen (?), 23:05, 28/04/2021 [ответить] [﹢﹢﹢] [ · · · ]	+/–
А че никто не пишет про компилирование Go через GCC?

1.60, Аноним (60), 01:45, 29/04/2021 [ответить] [﹢﹢﹢] [ · · · ]	+3 +/–
Обожаю читать комментарии к таким новостям. Радостно, что столько профессионалов тут. Вот бы собрать всех в одной команде, это же дрим тим.

1.61, Аноним (61), 06:49, 29/04/2021 [ответить] [﹢﹢﹢] [ · · · ]	+2 +/–
Модули из "стандарта" С++20 хоть куда-нибудь завезли?

2.62, Аноним (-), 07:17, 29/04/2021 [^] [^^] [^^^] [ответить]	+/–
И ренджи тоже

2.63, fsb40000 (?), 07:43, 29/04/2021 [^] [^^] [^^^] [ответить]	+1 +/–
Да, в gcc 11 и в Visual Studio 2019. А clang всё шлангует...

2.92, Аноним (-), 08:49, 01/05/2021 [^] [^^] [^^^] [ответить]	–1 +/–
Про модули обычно пишет Паскальщик. Ты скрытый паскальщик?

1.64, fsb4000 (?), 07:45, 29/04/2021 [ответить] [﹢﹢﹢] [ · · · ]	+/–
И ренджи тоже в Visual Studio 2019 и gcc есть.

2.73, Аноним (-), 15:56, 29/04/2021 [^] [^^] [^^^] [ответить]	+1 +/–
>Visual Studio 2019 ничтожество зашкварилось.

1.65, xcode (?), 08:51, 29/04/2021 [ответить] [﹢﹢﹢] [ · · · ]	+/–
А кто нибудь в курсе, почему в gcc не реализовано расширение "свойства", которое есть в msvc и clang? вот это? __declspec( property( get=get_func_name, put=put_func_name ) ) штука весьма полезная и не перекрывается существующими возможностями (в частности перегрузкой операторов и т.п.)

2.81, fsb4000 (?), 00:47, 30/04/2021 [^] [^^] [^^^] [ответить]	+1 +/–
вполне перекрывается если знать С++...

2.102, Омномномним (?), 20:11, 03/05/2021 [^] [^^] [^^^] [ответить]	+/–
Не особо понятно, зачем вообще нужны "свойства", если они тривиальные. В C# эта фигня изрядно бесила, обычные мутаторы-инспекторы из С++ очевиднее и нагляднее. Имхо, properties - бесполезный сахар.

3.103, xcode (?), 00:18, 04/05/2021 [^] [^^] [^^^] [ответить]	+/–
Тривиальные и не нужны. А вот зачем нужны: есть огромный проект. Нужно его изучить. Если некоторое поле некоторой структуры/класса сделать свойством, и например в геттер и сеттер ставить точки останова, или вывод логов, то можно понять где и как это поле используется. Заодно компилятор отловит все места где есть попытки получить адрес этого поля. Т.е. помимо синтаксического сахара, еще и рефакторинг/отладка/анализ кода.

1.70, Ананоним (?), 10:46, 29/04/2021 [ответить] [﹢﹢﹢] [ · · · ]	–1 +/–
Самое главное что нужно знать: > Компилятор теперь должен поддерживать стандарт C++11 (ранее требовался C++98), т.е. если для сборки GCC 10 достаточно было наличия GCC 3.4, то для сборки GCC 11 теперь требуется как минимум GCC 4.8. Поясняю - разработчики сами пишут на старом стандарте языка, и всё у них прекрасно получается. Но вам навязывают новые стандарты. Ну что бы жиСь скучной не казалась.

2.76, Аноним (76), 17:09, 29/04/2021 [^] [^^] [^^^] [ответить]	+1 +/–
При этом браузер месячной давности уже протухает и не открывает свежайшие сайты.

3.83, вебмакака (?), 07:00, 30/04/2021 [^] [^^] [^^^] [ответить]	+/–
Ну так браузер мы как нада пишем - не только на наираспоследних версиях компилятора, но еще и придумали отдельный нескучный язычок, который вообще каждый день новый.

2.88, anonymous (??), 12:48, 30/04/2021 [^] [^^] [^^^] [ответить]	+2 +/–
Капец, прочитал предложение, перевернул смысл с ног на голову. Пиши хоть на C++98, тебе как пользователю компилятора никто не запрещает. Сам компилятор теперь для своей сборки требует C++11, а не для кода, который ты быдлокодишь.

1.94, Алкоганон (?), 05:50, 02/05/2021 [ответить] [﹢﹢﹢] [ · · · ]	+/–
> Добавлена экспериментальная поддержка типов для параллельной обработки данных (SIMD, Data-Parallel Types). Ну вот совершенно эталонное деръмо. Все эти SIMD очевино зависят от процессора, платформы и т. д. То есть фактически имеют уровень Ассемблера. Нет конечно ничего плохого в том чтобы компилятор производил оптимизацию с использованием этих инструкций (SIMD и тп) и даже очень приветствовалось бы, но вынос этого на уровень языка и соответственно забот программиста фактически вынуждает писать код уровня Ассемблера. Программиста вынуждает. Вместо компилятора. Опять же нет ничего особенно плохого в Ассемблере и его применении, но... Ассемблер и так доступен тем кому необходим. Здесь же разработчики компилятора по-видимому вынуждают программистов на C писать код фактически на Ассемблере, видимо потому что компилятор у них не способен, но этот фактически ассемблерный код ещё и предлагается оформлять не свойственным Ассемблеру образом. Очевидные проблемы скажем при переходе на другую платформу в итоге очевидно переходят в код на C (без всяких особых преимуществ взамен).

1.95, Алкоганон (?), 06:02, 02/05/2021 [ответить] [﹢﹢﹢] [ · · · ]	+/–
> Номера столбцов в диагностических сообщениях теперь отражают не счётчик байт от начала строки Ещё немного деръмеца в подливку...

2.101, Омномномним (?), 20:00, 03/05/2021 [^] [^^] [^^^] [ответить]	+/–
Шо, нравится байтики считать? Ну это пока в диагностический выхлоп Юникод не попадает, в особенности UTF-8, с его кодированием переменной длины.

игнорирование участников | лог модерирования

Добавить комментарий

Текст: