The OpenNET Project / Index page

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

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

07.05.2024 13:55

После года разработки опубликован релиз свободного набора компиляторов GCC 14.1, первый значительный выпуск в новой ветке GCC 14.x. В соответствии со схемой нумерации выпусков, версия 14.0 использовалась в процессе разработки, а незадолго до выхода GCC 14.1 уже ответвилась ветка GCC 15.0, на базе которой будет сформирован следующий значительный релиз GCC 15.1.

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

  • Значительно расширены возможности для статического анализа кода на языке Си, доступные через опцию "-fanalyzer" (статический анализ для языка С++ пока не доведён до должного вида). Усилен анализ операций со строками и проверка наличия завершающего строку нулевого символа. Добавлено новое предупреждение "-Wanalyzer-infinite-loop" для выявления бесконечных циклов. Добавлена серия предупреждений "-Wanalyzer-tainted-*" для выявления проблем с проверкой входных данных. Расширены возможности предупреждения "-Wanalyzer-out-of-bounds" для выявления переполнений буфера, например, добавлена возможность отображения диаграммы с визуализацией состояния, приводящего к переполнению.
  • Добавлена новая сборочная опция "--enable-host-pie" для сборки исполняемых файлов компилятора в режиме PIE (Position Independent Executable), а также опция "--enable-host-bind-now" для связывания с опциями "-Wl,-z,now".
  • Добавлена новая опция "-fhardened", включающая флаги для усиления безопасности (-D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -ftrivial-auto-var-init=zero -fPIE -pie -Wl,-z,relro,-z,now -fstack-protector-strong -fstack-clash-protection -fcf-protection=full).
  • Добавлена опция "-fharden-control-flow-redundancy" для добавления в конец функций кода для выявления некоторых форм неопределённого поведения, которые потенциально могут привести к нарушению нормального порядка выполнения (control flow) в результате применения эксплоитов, изменяющих хранимые в памяти указатели на функции и передающих управление в середину функций.
  • Добавлен новый атрибут типов "hardbool", позволяющий переопределить значения, сопоставленные с признаками true и false, для затруднения некоторых видов атак.
  • Добавлен новый атрибут типов strub для управление обнулением кадров стека с данными функций и переменных после выхода из функции или срабатывания исключения.
  • Добавлена опция -finline-stringops для включения inline-раскрытия функций memcmp, memcpy, memmove и memset, даже когда это не нужно для оптимизации.
  • Добавлен новый атрибут функций null_terminated_string_arg(PARAM_IDX) для пометки параметров, которые следует трактовать как строки, заканчивающиеся нулевым символом.
  • В векторизаторе реализована поддержка векторизации циклов, содержащих выражения "break".
  • Добавлена начальная поддержка предварительной версии спецификации OpenMP 6.0 (Open Multi-Processing) и продолжена реализация стандартов OpenMP 5.0, 5.1 и 5.2, определяющих API и способы применения методов параллельного программирования на многоядерных и гибридных (CPU+GPU/DSP) системах с общей памятью и блоками векторизации (SIMD).
  • Улучшена реализация спецификаций параллельного программирования OpenACC 2.7 и 3.2, определяющих средства для выноса операций (offloading) на GPU и специализированные процессоры, такие как NVIDIA PTX.
  • Для C, C++ и Objective-C реализована поддержка расширений "__has_feature" и "__has_extension", применяемых в Clang.
  • Реализованы возможности, определённые в будущем Си-стандарте C23, такие как типы "_BitInt (N)" и "unsigned _BitInt (N))". Структуры, объединения и перечисления разрешено определять более одного раза в одной области видимым с одним и тем же содержимым и повторяющимся тегом. Добавлена поддержка заголовочного файла stdckdint.h. Для включения поддержки элементов C23 предложены флаги "-std=c23", "-std=gnu23" и "-Wc11-c23-compat".
  • Для языка Си добавлено выражение "#pragma GCC novector", отключающее векторизацию анотированных циклов.
  • Добавлены возможности, связанные со стандартом C++23. Добавлена поддержка механизма "Deducing this", позволяющего использовать в шаблоне параметры с признаком "this" и дающего возможность из функции класса узнать категорию выражения (например, является ли константой), для которого эта функция вызвана. Реализовано требование, в соответствии с которым все функции, вызывающие функции с признаком consteval тоже становятся consteval, т.е. выполняются при компиляции. Ослаблены некоторые требования к "constexpr".
  • Добавлены возможности, связанные с будущим стандартом C++2с (C++26). Например, предоставлена возможность использования строковых литералов в контексте, в котором они не используются для инициализации массива символов и не попадают в результирующий код, а применяются только во время компиляции для диагностических сообщений и препроцессинга. Добавлена возможность использования сразу нескольких переменных-заполнителей с именем "_" в одной области видимости. Переведено в разряд устаревших выполнение неявных преобразований перечисляемых значений в арифметических вычислениях.
  • В libstdc++ улучшена поддержка стандартов C++20, C++23 и C++26.
  • В компиляторе для языка Fortran началась работа над поддержкой стандарта Fortran 2023 (-std=f2023).
  • Объявлена устаревшей поддержка расширения GCC, позволяющего указывать гибкий элемент-массив (массив неопределённого размера, например, "int b[]") не в самом конце структуры (Flexible Array Members). Массив неопределённого размера в дальнейшем можно будет использовать только в конце структуры.
  • В бэкенде для архитектуры AArch64 реализована поддержка CPU Ampere-1B (ampere1b), Arm Cortex-A520 (cortex-a520), Arm Cortex-A720 (cortex-a720), Arm Cortex-X4 (cortex-x4) и Microsoft Cobalt-100 (cobalt-100). Для использования в опциях "-mcpu=" и "-mtune=" добавлены новые идентификаторы CPU generic, generic-armv8-a и generic-armv9-a. Добавлена поддержка расширений Arm SME и SME2 (Streaming Matrix Extensions). Реализованы специфичные для архитектуры AArch64 оптимизации.
  • В бэкенде для архитектуры ARM добавлена поддержка CPU Cortex-M52 (cortex-m52 в опциях "-mcpu=" и "-mtune=").
  • В бэкенде генерации кода для GPU AMD Radeon (GCN) реализована поддержка GPU AMD Radeon gfx90c (GCN5), gfx1030, gfx1036 (RDNA2), gfx1100 и gfx1103 (RDNA3). Повышена производительность для устройств AMD серий MI100 и MI200. По умолчанию активирована архитектура устройств gfx900 (Vega).
  • В бэкенд для архитектуры x86 добавлена поддержка расширений архитектуры набора команд Intel AVX10.1, Intel APX (частично), Intel AVX-VNNI-INT16, Intel SHA512, Intel SM3, Intel SM4, Intel USER_MSR.

    Добавлена поддержка CPU AMD на базе ядра Zen 5 (-march=znver5), а также процессоров Intel Clearwater Forest (-march=clearwaterforest), Arrow Lake (-march=arrowlake), Arrow Lake S (-march=arrowlake-s), Lunar Lake (-march=lunarlake) и Panther Lake (-march=pantherlake). Добавлена опция "-m[no-]evex512" для управления задействованием 512-битных векторов (по умолчанию включается при поддержке AVX512F. Объявлена устаревшей поддержка CPU Intel Xeon Phi.

  • Расширены возможности бэкендов для платформ LoongArch, AVR и RISC-V.
  • Расширены возможности вывода диагностики в формате SARIF, основанном на JSON. Формат SARIF можно использовать для получения результатов статического анализа (GCC -fanalyzer), а также для получения сведений о предупреждениях и ошибках.
  • Переведена в разряд устаревших и будет удалена в следующем релизе GCC поддержка целевых архитектур ia64 и nios2, применяемых в процессорах Intel Itanium и Nios II.
  • Для кода на языке Си, собираемом с выставлением стандартов новее C89, некоторые выведенные из стандарта С99 конструкции теперь приводят к выводу ошибок, а не предупреждений. Например, среди подобных возможностей неявное использование типа int (-Werror=implicit-int), обращение к необъявленным функциям (-Werror=implicit-function-declaration), неверные названия типов в объявлениях функций (-Werror=declaration-missing-parameter-type), некорректное использование выражения return (-Werror=return-mismatch), использование указателей как чисел (-Werror=int-conversion) и сочетание разных типов указателей (-Werror=incompatible-pointer-types).


  1. Главная ссылка к новости (https://gcc.gnu.org/pipermail/...)
  2. OpenNews: Доступен набор компиляторов LLVM 18
  3. OpenNews: Уязвимость в GCC, позволяющая обойти защиту от переполнения стека
  4. OpenNews: Для GCC подготовлены патчи для сборки универсальных исполняемых файлов
  5. OpenNews: Проект GCC принял кодекс поведения разработчиков
  6. OpenNews: Релиз набора компиляторов GCC 13
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/61132-gcc
Ключевые слова: gcc
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (180) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 14:26, 07/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +15 +/
    > Добавлено новое предупреждение "-Wanalyzer-infinite-loop" для выявления бесконечных циклов

    Они решили проблему остонова! Вот что значит энтузиасты, вот что значит сообщество, миллиардеры из гаража!

     
     
  • 2.15, Sw00p aka Jerom (?), 15:25, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • –6 +/
    находят конструкцию while (true), дальше ищут в ней break, если не нашли - infinite-loop, если нашли, то проверяют на наличие условий always-true или always-false. Самый примитивный случай.
     
     
  • 3.25, Аноним (25), 15:59, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +8 +/
    while (true) if (false) break;
     
     
  • 4.27, Fracta1L (ok), 16:08, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Штош, добавим и такую проверку.
     
     
  • 5.47, Аноним (47), 17:29, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    while (true) {
    #define break continue
      break;
    }
     
     
  • 6.54, unknown (??), 18:21, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Анализируется AST после препроцессинга
     
  • 6.57, kravich (ok), 18:34, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ты же понимаешь, что AST уже после прохода препроцессора строится?
     
  • 6.61, Аноним (-), 18:55, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +11 +/
    > while (true) {
    > #define break continue
    >  break;
    > }

    Решил как-то анон компилер препроцессором обдурить. А оказалось что обдурили его - компилер после препроцессора работает! Вот что бывает если маны не читать.

     
  • 6.90, Аноним (47), 22:22, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Неужели до сих непонятно?! После препроцессора работает! Пойми наконец, ну! Да что ж ты бестолковый такой, ну?!
     
  • 6.132, Аноним (132), 10:51, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Коллеги, кто ещё о препроцессоре не написал? Просьба не затягивать, отписаться по возможности скорее.
     
     
  • 7.141, Sw00p aka Jerom (?), 12:40, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Коллеги, кто ещё о препроцессоре не написал? Просьба не затягивать, отписаться по
    > возможности скорее.

    а препроцессор это обызательная часть компилятора ЯП?

     
     
  • 8.144, Аноним (144), 13:57, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Именно компилятора С - да, обязятельная ... текст свёрнут, показать
     
  • 8.172, Аноним (-), 23:45, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В случае С и C это тупо часть стандарта Должен быть, иначе это noncompliant ... текст свёрнут, показать
     
  • 4.71, Sw00p aka Jerom (?), 19:24, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > while (true) if (false) break;

    ну да самый примитивный случай, выявляется в compile-time.

     
  • 3.106, 12yoexpert (ok), 00:50, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    чего только не придумают, лишь бы goto не юзать
     
  • 3.152, Аноним (152), 15:23, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    goto?
     
     
  • 4.163, Sw00p aka Jerom (?), 20:44, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > goto?

    если че, это безусловный переход.

     
     
  • 5.168, Аноним (168), 22:00, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Та по сути while в итоге превратится в тот же goto, только условие ещё будет проверять))
    Ну зато адепты кода без goto будут уверены что то что в скобочках - безопасно.
     
     
  • 6.170, Sw00p aka Jerom (?), 22:57, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    разница в том, что если юзать goto, то по определению уже возможен бесконечный ц... большой текст свёрнут, показать
     
  • 6.213, Аноним (213), 17:00, 15/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В случае с goto дело не в небезопасности, а лапшекодовости.
     
     
  • 7.215, n00by (ok), 19:32, 15/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В случае goto дело в том, что аббревиатура КА не гуглится в Википедии.
     
  • 2.60, Nv (?), 18:52, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > миллиардеры из гаража

    Ты в каком мире фантазии. Это было сделано с условием что либо получить. Пока ничего нету так что скоро уезжаю.

     

  • 1.2, Аноним (2), 14:26, 07/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Почему чтение файла в коде, скомпилированном gcc-O2, в 2 раза быстрее чем в clang? Такая разница делает мне некомфортно. Вот это фрагмент, да

    https://books.google.ru/books?id=xlkPDAAAQBAJ&lpg=PT413&ots=Un50rB7_J3&hl=ru&p

     
     
  • 2.10, n00by (ok), 15:11, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Почему чтение файла в коде, скомпилированном gcc-O2, в 2 раза быстрее чем
    > в clang?

    Потому что это наброс?

    > Такая разница делает мне некомфортно.

    "Такая", в смысле, воображаемая? Пока нет результатов тестов, нет разницы.

     
     
  • 3.12, Аноним (2), 15:15, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • –9 +/
    Я привёл код, вперёд, воспроизводи. Почитай в интернете про ядерные кэши и планирование эксперимента заодно.
     
     
  • 4.122, n00by (ok), 09:54, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Я привёл код, вперёд, воспроизводи.

    "Воспроизвести" означает "повторить опыт" за тобой. Результаты ты не привёл, стало быть и опыт не ставил.

    > Почитай в интернете про ядерные кэши.

    Кеши ядер процессора не имеют отношения к файловым операциям. А вот файловый вполне влияет и заметно. Ты не слышал про прогрев? :)

    > и планирование эксперимента заодно.

    Этот твой ответ вполне укладывается в допустимую погрешность. ;)

     
     
  • 5.142, Sw00p aka Jerom (?), 12:44, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > "Воспроизвести" означает "повторить опыт" за тобой. Результаты ты не привёл, стало быть
    > и опыт не ставил.

    какой хитрец, результаты ему заранее давай, чтоб он подвел под них собственные, в этом то и интрига. И по вашим результатам ясно будет, вроводили вы их или нет, может с потолка взяли, как говорили нам в школе :)

     
  • 5.157, Аноним (2), 18:14, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Но ведь это не мне надо. Если тебе так тяжело написать мейкфайл на 20 строк (ещё 20 строк на тесты) и 60 строк достаточно примитивного кода (40 из которых скопировать), то, может быть, это всё просто не твоё. Но, видишь тут какое дело, я не могу _гарантировать_ воспроизводимость, только то, что ситуация имеет место. Зависит от оборудования, тестовых данных, и так далее. А может, у тебя там тулчейн без libcxx или руки кривые, много вариантов. И неплохо бы посмотреть на твои результаты, прежде чем продолжать разговор.
     
     
  • 6.183, n00by (ok), 12:13, 10/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В смысле, не тебе Тебя кто-то заставил задать вопрос, якобы тебе интересен отве... большой текст свёрнут, показать
     
     
  • 7.187, Аноним (2), 15:01, 10/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален На этом можно и закончить разговор Ты некомпетентен и с... большой текст свёрнут, показать
     
     
  • 8.188, n00by (ok), 16:01, 10/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Так будь последователен, закончи Зачем ты написал следом простыню Возомнил, чт... текст свёрнут, показать
     
     
  • 9.189, Аноним (2), 16:14, 10/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Именно это я и сделал, попутно поставив все точки и указав на определённые когни... текст свёрнут, показать
     
     
  • 10.197, n00by (ok), 10:12, 12/05/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Спасибо, показал цену своих слов написал закончил и следом два сообщения Это... текст свёрнут, показать
     
  • 2.16, Пряник (?), 15:26, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Возьми да сравни код на ассемблере. Или нам за тебя это делать? Мне лень.
     
     
  • 3.20, Аноним (2), 15:44, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Так я вижу в дизассемблере, но это не ответ на вопрос "почему".
     
     
  • 4.33, Аноним (33), 16:20, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я тебе тайну открою, возможно. Под MacOS и iOS оно, вероятно, более оптимально компиляет ;)
     
  • 4.45, Пряник (?), 17:27, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если видишь, тогда сравнивай по одной команде. Всё познаётся в сравнении.
     
     
  • 5.126, n00by (ok), 09:58, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это бессмысленное сравнение. Если уж сравнивать, то время исполнения одной (любой) команды и время чтения с накопителя.
     
  • 2.73, Ivan7 (ok), 19:36, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что код криво написан. Это и дураку ясно.
     
     
  • 3.75, Аноним (2), 19:39, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Почему все эти корпорации не могут написать clang не криво? Гнутый опенсорсный компилятор унижает всех этих корпоративных разработчиков.
     
     
  • 4.77, Ivan7 (ok), 19:50, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Там код по ссылке "кривой", поэтому работает медленно. Такое часто бывает, что код, использующий стандартную библиотеку работает медленно. К сожалению реализация стандартных библиотек С++ в Clang и GCC оставляет желать лучшего. Либо надо где-то что-то настраивать. Для достижения лучшей производительности часто приходится переписывать какую-то функциональность самостоятельно вместо того, чтобы воспользоваться ею из стандартной библиотеки С++. Своя реализация, бывает, что в разы и даже в десятки раз работает быстрее... Как-то так. Мне казалось, что стандартную библиотеку должны писать профессионалы, но нет...
     
     
  • 5.82, тыквенное латте (?), 21:01, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Там код по ссылке "кривой", поэтому работает медленно. Такое часто бывает, что
    > код, использующий стандартную библиотеку работает медленно. К сожалению реализация стандартных
    > библиотек С++ в Clang и GCC оставляет желать лучшего. Либо надо
    > где-то что-то настраивать. Для достижения лучшей производительности часто приходится
    > переписывать какую-то функциональность самостоятельно вместо того, чтобы воспользоваться
    > ею из стандартной библиотеки С++. Своя реализация, бывает, что в разы
    > и даже в десятки раз работает быстрее... Как-то так. Мне казалось,
    > что стандартную библиотеку должны писать профессионалы, но нет...

    без примера - ложь, звездёжь и провокация.

     
  • 5.92, Аноним (2), 22:24, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    К clang много вопросов, не догадывается до достаточно простых вещей В книге, кс... большой текст свёрнут, показать
     
     
  • 6.99, Прадед (?), 23:50, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Гцц лучше в лайкли/анлайкли. Такое чувство что в шланге его пустым местом оставили
     
  • 6.110, Ivan7 (ok), 03:46, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Переписывание тупо в лоб не особенно эффективно. Эффективно переосмысление задачи: изменение интерфейса какого-то функционала вместе с изменением модели его использования, что позволяет сделать более эффективную реализацию. В таком случае преимущество по производительности и/или памяти можно получить в разы и даже в десятки раз по сравнению со стандартными библиотеками С и С++, причём часто вместе с улучшением удобства использования. Иногда можно немного урезать функционал или гибкость, но сильно поднять производительность. В таком духе. Тем более программный интерфейс у стандартной библиотеки С++ такой себе, на любителя, часто очень многословный и плохо читаемый.
     
  • 4.96, Аноним (96), 22:54, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ой все, типа никто не знает что гцц пишет красношапка .
     
     
  • 5.97, Аноним (2), 23:06, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Сомневаюсь, у неё были только разработчики для avahi, но они перебрались в Майрософт.
     
  • 5.102, Аноним (102), 00:31, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Когда-то точно писала. В эпоху форка под названием egcs точно было. Но и сами они тогда были настоящей опенорсной компанией.
     

     ....большая нить свёрнута, показать (25)

  • 1.4, тыквенное латте (?), 14:38, 07/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    лучший
     
  • 1.5, НяшМяш (ok), 14:55, 07/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > для выявления переполнений буфера, например, добавлена возможность отображения диаграммы с визуализацией состояния, приводящего к переполнению

    Так стоп, оставьте свои диагностики и диаграммы растовикам. Настоящий сяшник обязан ещё в голове избежать переполнения буфера - вон сколько софта без багов написали.

     
     
  • 2.30, Fracta1L (ok), 16:12, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Похоже, с сишниками стало всё плохо, если им начали диаграммы со стрелочками рисовать)

    (я имею в виду реальных сишников, а не фэнтезийных из комментов на опеннете)

     

  • 1.7, 12yoexpert (ok), 15:04, 07/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    наканецта можно нормально с++23 пощупать, до этого больше всего с++23 в гомо-msvc++ поддерживались
     
     
  • 2.38, eugene_martein (ok), 16:29, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    import std; вроде так и не завезли
     
     
  • 3.74, Аноним (74), 19:38, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не, не завезли. И я очень опечален этим. В новых книжках повсеместно описывают работу с модулями и для этого рекомендуют использовать MSVC.
     
     
  • 4.79, eugene_martein (ok), 20:42, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да и то, под CMake'ом всё равно пока очень тяжело заставить работать этот import std;
    Может вот-вот в CMake 3.30 сделают простой способ его включения. Тогда можно будет параллельно читать книгу Крэга Скотта про CMake и Ivor'а Horton'а по C++23
     
     
  • 5.105, 12yoexpert (ok), 00:47, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    да сейчас в принципе выбор книг по 23 плюсам невелик
     
  • 4.104, 12yoexpert (ok), 00:46, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Не, не завезли. И я очень опечален этим

    аналогично, читаю beginning c++23, а там такое:

    https://github.com/Apress/beginning-cpp23/issues?q=is%3Aissue

     
  • 3.78, Аноним (78), 20:09, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ближайшие лет 5-10 можете про модули не вспоминать. Разве что на коленке поиграться ради интереса.
     

  • 1.13, Аноним (13), 15:19, 07/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    What changed All of these were either invalid in C99, invalid even in C89, or e... большой текст свёрнут, показать
     
  • 1.14, nc (ok), 15:22, 07/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё хочу чтобы они сделали __declspec(property), удобная же штука, а уж GCC славится всяческими полезными расширениями (многие из которых просто можно брать готовые и вносить в стандарт языка)
     
     
  • 2.41, Аноним (41), 16:34, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Лишь бы [[gnu::]] не использовать. Позаимствовано из C++.
     
     
  • 3.118, nc (ok), 08:40, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да пускай как угодно называется, главное чтобы сама фича была.
     
  • 2.186, rtfm (?), 14:33, 10/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    RTFM https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
     

  • 1.18, Аноним (18), 15:34, 07/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Как там с поддержкой раста уже?
     
     
  • 2.22, Hck3r (?), 15:54, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    С поддержкой D давно порядок
     
     
  • 3.29, Аноним (33), 16:12, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже на то, что средства работы с AST ещё не перетянули с DMD. Или у меня неточные представления?
     
  • 3.205, Аноним (205), 23:03, 12/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, не подскажете, куда Dшники с сайта https://lhs-blog.info/ перебрались? А то домен вообще перестал определяться.
     
  • 2.24, Аноним (24), 15:57, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пока растовики не пришлют патч - никак.
     
  • 2.49, Аноним (49), 17:37, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Уже все забыли что в gcc реально добавляют раст - gccrs.

    Вот даже ссылка на ежемесячные отчеты с прогрессом. Есть milestone-ы до весны 2025... Может в gcc 16 войдет полная версия компилятора.
    https://opennet.ru/57491-rust
    https://rust-gcc.github.io/

     
     
  • 3.51, Аноним (24), 18:11, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Такой прекрасный язык, что даже оба компилятора для него написаны на С++
     
     
  • 4.59, Anon62513512124 (?), 18:48, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    разве rust еще не self-hosted?
     
     
  • 5.63, Аноним (63), 19:02, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Давным-давно. И первые версии на Ocaml, а не на дырявом были написаны.
     
     
  • 6.135, Аноним (135), 12:02, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Rust зависит от llvm, так что он не self-hosted.
     
     
  • 7.148, Аноним (96), 14:39, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    gcc зависит от  binutils, тоже не сильно самостоятельный проект.
     
     
  • 8.206, Аноним (205), 23:05, 12/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ага, не путай тёплое с мокрым, компилятор с линкером ... текст свёрнут, показать
     
  • 6.166, Аноним (166), 21:14, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Давным-давно. И первые версии на Ocaml, а не на дырявом были написаны.

    Вперся кому ваш эзотерик, аж два раза. А вулны в компилере... не хочу вас расстраивать, но если проект решил вас при сборке поиметь, эксплуатация вулна в компилере это какой-то сложный и эзотеричный способ достойный фанатов ocaml. Более приземленные личности, вон, "тесткейсов" в билд систему запихнули - и в дамках.

     
  • 5.111, cheburnator9000 (ok), 04:38, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Rust под собой использует llvm, а он как раз написан на C++. Благодаря llvm у rust есть возможность поддерживать все его архитектуры CPU. В отличие от Go, когда который только начинали создавать у llvm не было всех возможностей необходимые для Go, а вот сейчас уже давно есть.
     
  • 4.123, Советский инженер (ok), 09:55, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    как ни странно, но все нормальные компиляторы С тоже на С++ написаны
     
     
  • 5.150, Аноним (150), 15:11, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Tiny C Compiler и pcc - написаны на Си :-P
     
     
  • 6.178, Bottle (?), 18:23, 09/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Tiny C Compiler не является нормальным компилятором по причине скорости генерируемого кода. Но проект занятный, да.
     
     
  • 7.194, Аноним (194), 16:53, 11/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    По таким строгим критериям тогда и единственный пригодный компилятор Rust не является нормальным.
     
  • 5.159, Аноним (24), 19:21, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Только по одной причине - AST разбирать с помощью STL проще
     
  • 2.62, Аноним (-), 18:58, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Как там с поддержкой раста уже?

    gccrs весьма активно пилят. Читай фороникс, там про это есть - и GSoC актуальный по этой теме весьма приличный, например.

     
     
  • 3.87, Аноним (24), 21:54, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А вот скажи почему этот самый gccrs пилят на С++, а не на расте?
     
     
  • 4.94, errandrunner (?), 22:29, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Бутстрапить проще, да и на расте реализация раста уже есть.
     
     
  • 5.151, Аноним (150), 15:12, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    То есть в расте есть какие-то проблемы с бутстрапом? А говорят Сишку заменить хочет
     
     
  • 6.191, errandrunner (?), 20:38, 10/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > То есть в расте есть какие-то проблемы с бутстрапом? А говорят Сишку
    > заменить хочет

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

    Бутстрап rustc, конечно, долго (а на всяких эзотерических сетапах ещё и муторно) делать, но большинство людей с этим вообще не сталкиваются.

     
     
  • 7.195, Аноним (194), 16:58, 11/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А в Си проблем с бутстрапом нет, вот и не делают.
     
  • 2.101, Прадед (?), 00:29, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Там жёсткая привязка к шлангу, говорят. Раньше-то он в сишку сначала гонялся, а потом компиляй-нехочу.
     

  • 1.19, Аноним (19), 15:35, 07/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    ждём новых багов и проблем в различном программном обеспечении. Я до сих пор помню, как frrouting версии 7.5 крашился при sh ip ospf interface. А текже пог рандомно крашнутся, при анонсировании l3vpn через bgp.
     
     
  • 2.67, Аноним (67), 19:11, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  ждём новых багов и проблем в различном программном обеспечении. Я до сих пор
    > помню, как frrouting версии 7.5 крашился при sh ip ospf interface. А текже
    > пог рандомно крашнутся, при анонсировании l3vpn через bgp.

    Багов бояться - разработкой софта не заниматься. А если вам надо стабильность - в чем ваша проблема юзать какой-нибудь стабильный дистр, проверив раз в дохрена что все ок - получите 4-8 лет спокойной жизни, а может и больше. А если вы хотели все сами компилять распоследним компилером распоследней версии софта - все новые баги будут ваши! Простите, бесплатный сыр - только второй мышке. Жаль что вам про это не рассказали.

     

  • 1.21, Аноним (21), 15:46, 07/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Спасибо. Как обновится w64devkit и если VirusTotal не найдет там чего-то страшного (а то я очкую, даже зная, что скорее всего это ложное срабатывание), то тогда поюзаю эту штуку.
     
  • 1.23, Аноним (25), 15:56, 07/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Модули С++20 походу никогда нормально не заработают
     
     
  • 2.26, Дед (??), 16:08, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    На модули в плюсах можно смело забивать. Быстрее рак на горе засыестит, чем их полноценно реализуют...
     
  • 2.28, Аноним (33), 16:09, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А метаклассы в каком стандарте ждать? Я даже не про реализацию, а, хотя бы, про стандартизацию.
     
     
  • 3.53, Аноним (53), 18:17, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    лучше сразу мета-мета классы
     
  • 2.31, Fracta1L (ok), 16:14, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А что с ними не так?
     
     
  • 3.34, Аноним (33), 16:22, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    STL же ещё препроцессором, а не модулями.
     
     
  • 4.46, Fracta1L (ok), 17:27, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Это досадно, конечно (без сарказма), но разве фатальная преграда?
     
     
  • 5.65, Аноним (33), 19:04, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Без препроцессора ожидаемо повышение скорости компиляции.
     
  • 3.91, Аноним (91), 22:22, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    https://en.cppreference.com/w/cpp/compiler_support/20

    На деле только Visual Studio более менее полноценно реализовал модули, но и там IntelliSence не работает, если в проекте есть модули

     
  • 3.127, n00by (ok), 10:05, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Напоминают export template.
     
  • 2.35, Аноним (-), 16:25, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Модули С++20 походу никогда нормально не заработают

    Это уже Паскаль головного мозга. Бывшим паскальщикам, в своё время надо было переходить на Джаву, а не C++.

     
     
  • 3.48, Аноним (48), 17:34, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Кто поумнее, так и сделал.
     
  • 3.56, Bottle (?), 18:31, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Как будто что-то плохое. Модули нужны в первую очередь для ускорения и без того медленной компиляции.
     
     
  • 4.85, Аноним (85), 21:47, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > для ускорения
    > и без того медленной

    Взаимоисключающие параграфы.

     
     
  • 5.129, n00by (ok), 10:11, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> для ускорения
    >> и без того медленной
    > Взаимоисключающие параграфы.

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

     
  • 4.128, n00by (ok), 10:09, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Как будто что-то плохое. Модули нужны в первую очередь для ускорения и
    > без того медленной компиляции.

    То есть они нужны не тем, кто программы пишет, а кто собирает из чужих исходников.

     
     
  • 5.134, Bottle (?), 11:43, 08/05/2024 Скрыто ботом-модератором     [к модератору]
  • +/
     
     
  • 6.145, n00by (ok), 14:14, 08/05/2024 Скрыто ботом-модератором     [к модератору]
  • –2 +/
     
  • 5.138, Аноним (138), 12:16, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Какая разница из своих/несвоих? Скорость очень не помешает тем, кто свою систему собирает из исходников. Кдешники-гентушники возрадуются!
     
     
  • 6.146, n00by (ok), 14:16, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Разница существенная. Программисты используют язык, что бы создавать программное обеспечение. Если нет ПО, то собирать нечего. Потому в данном вопросе в приоритете программисты.
     
  • 5.175, Аноним (48), 12:14, 09/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Из чужих исходников программа собирается один раз, а из своих — сто двадцать один (за день).
     
     
  • 6.181, Буратино (?), 02:03, 10/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Сто двадцать раз на дню компилируют вот такие персонажи:
    >Разгадку подсказал мне однажды сам кандидат: он объяснил, что обычно, когда пишет код, то сразу же пытается его запускать и редактирует вусмерть, пока хоть как-то не заработает. ... Когда удалось нашаманить, чтобы текст компилировался, то можно выпускать бета-версию, а когда программа сможет хоть раз не упасть и не зависнуть — финальный релиз. Остальные баги найдут пользователи.
     
     
  • 7.185, n00by (ok), 12:41, 10/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Он в vim редактирует? Ошибки синтаксиса обычно редактор подсвечивает. Но местные умельцы скомпилировать 121 раз банально врут: сначала у них "дооооолго компилируется", а потом оказывается, что менее 3-х минут.
     
  • 6.184, n00by (ok), 12:20, 10/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Собирается программа из объектников, а не из исходников. Но откуда тебе это знать?
     
  • 2.149, Серб (ok), 14:55, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем они такие нужны?

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

    Но стандарт приняли таким, что такие зависимости модулей недопустимы.

    Так какую проблему они могут решить?

     
     
  • 3.182, Аноним (91), 05:47, 10/05/2024 Скрыто ботом-модератором     [к модератору]
  • +2 +/
     

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

  • 1.32, Аноним (-), 16:20, 07/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Реализованы возможности, определённые в будущем Си-стандарте C23

    Кто в курсе ратификация стандарта в этом году состоится? Почему комитет до сих пор держит стандарт в качестве черновика?

     
     
  • 2.55, Аноним (55), 18:30, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    потомучто. держу в курсе!
     
  • 2.58, тыквенное латте (?), 18:41, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >>Реализованы возможности, определённые в будущем Си-стандарте C23
    > Кто в курсе ратификация стандарта в этом году состоится?

    open-std.org/jtc1/sc22/wg14/www/docs/n3156.pdf
    :)

    > Почему комитет до сих пор держит стандарт в качестве черновика?

    а ты хочешь еще один С11? куда спешить, вечность впереди.

     
     
  • 3.66, Аноним (33), 19:10, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Почему бы самый последний ратифицированный стандарт не использовать? В Сишке не так много (мало) нововведений в стандарты вносят, компиляторы с реализацией поспевают. Ну кроме чьего-то пальца, препятствий не видно.
     
     
  • 4.72, тыквенное латте (?), 19:27, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Почему бы самый последний ратифицированный стандарт не использовать? В Сишке не так
    > много (мало) нововведений в стандарты вносят, компиляторы с реализацией поспевают. Ну
    > кроме чьего-то пальца, препятствий не видно.

    вы о чем?

    P.S. а касательно стандарта - убери пдф из ссылки, и глянь другие, датированные 24 годом.
    Работа кипит. Надеюсь, таймлайн что по ссылке скинул ранее они отодвинут. Не хотелось бы еще один С11 получить, когда они два дня назад обсуждают фичу.

     
  • 2.130, n00by (ok), 10:13, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>Реализованы возможности, определённые в будущем Си-стандарте C23
    > Кто в курсе ратификация стандарта в этом году состоится? Почему комитет до
    > сих пор держит стандарт в качестве черновика?

    Что бы можно было скачать и не жаловаться потом на цену.)

     

  • 1.42, Аноним (135), 16:57, 07/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Лучше c99 ничего нет.
     
     
  • 2.44, anonymous (??), 17:24, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ты еще сидишь на ядре 2.6 с GNOME 2 и пишешь это из какого-нибудь Firefox 10, да?
     
     
  • 3.64, тыквенное латте (?), 19:02, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Ты еще сидишь на ядре 2.6 с GNOME 2 и пишешь это
    > из какого-нибудь Firefox 10, да?

    охосспаде. кто о чем, а вшивый о бане.

     
  • 3.80, User (??), 20:56, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну, у меня для вас плохие новости, да. 2.6.32 от какого-нибудь 5.15 в части стандарта c отличается вот "никак" и оба используют - та-дааам! С89.
    Но вы конечно можете этим ретроградам объяснить, как и в чем они не правы..
     
     
  • 4.199, anonymous (??), 15:57, 12/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    И все же с 5.18 (или самая ранняя LTS - 6.1) используется C11 :)
     
     
  • 5.208, User (??), 07:01, 13/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > И все же с 5.18 (или самая ранняя LTS - 6.1) используется
    > C11 :)

    В курсе - по этому и ограничился "каким-нибудь 5.15"

     
  • 4.200, anonymous (??), 16:00, 12/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А вообще с точки зрения компилятора везде разные требования к версии GCC. Так что даже, если стандарт одинаков (C89), не факт, что какой-нибудь GCC 4.4 сможет собрать обе ветки.
     
     
  • 5.207, User (??), 07:01, 13/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > А вообще с точки зрения компилятора везде разные требования к версии GCC.
    > Так что даже, если стандарт одинаков (C89), не факт, что какой-нибудь
    > GCC 4.4 сможет собрать обе ветки.

    Не, ну это прям отдельная печальная история - костыли, велосипеды, компиляторы C и linux kernel... Вот уже ажно "ANSI - стандарт" на язык есть - а собрать чем угодно всё одно, нельзя.

     
  • 2.68, Аноним (67), 19:13, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучше c99 ничего нет.

    Без static assert'ов то? :) Не, их конечно можно и самому сделать но вот чтобы с нормальной диагностикой - уже сложнее, да...

     
  • 2.70, тыквенное латте (?), 19:16, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Лучше c99 ничего нет.

    не-не-не, с89 - ессенция. пишешь свой компилер? с89 - база. с99 напишешь уже на с89.

     
     
  • 3.76, Аноним (48), 19:47, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Так-то с K&R надо начинать, а все эти ваши 89, 99 — баловство.
     
     
  • 4.81, тыквенное латте (?), 20:58, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Так-то с K&R надо начинать, а все эти ваши 89, 99 — баловство.

    унылый троллинг. c89 образно говоря, включает в себя субсет K&R, без особой модификации кода (сравни первую и вторую редакцию настольной книги). Более того, K&R такой, blunt standard (не стандарт вовсе), в результате чего семантика языка становится спекулятивна для интерпретации каждым поставщиком компилятора. с89 уравнивает компиляторы в этом.

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

     

  • 1.50, Аноним (50), 17:44, 07/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    и что? код, сгенеренный этим компиллятором, быстрее получается, чем, когда превидущие генерировали?
     
     
  • 2.52, Аноним (24), 18:13, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, быстрее в некоторых случаях из-за улучшенной оптимизации. А ещё диагностика ошибок стала лучше
     
  • 2.69, Аноним (2), 19:14, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Каждая версия приносит заметные улучшения. Самое впечатляющее в районе 9 версии случилось, генерировать PGO для произвольного кода стало намного проще. Просто собираешь программу как обычно, используешь во всех интересующих применениях, и пересобираешь с целевыми оптимизациями 2 раз. Жалко только для сишки хорошо работает. GCC с PGO даёт код в 100% случаев более быстрый и эффективный (в частности, задействует оптимизации 3 уровня только там, где они точно необходимы). Но появлялись ещё дополнительные оптимизации (например, очень эффективные для питона) и разного рода защиты.
     

  • 1.83, Аноним (83), 21:03, 07/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А, вот интересно, кто знает:
    почему u-boot от 2017г., собраный (под armv7) gcc 6 работает, а gcc 11 не работает?
    Хотя ошибок сборки нет.
     
     
  • 2.95, Аноним (95), 22:51, 07/05/2024 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Потому что типичная кодовая база системного ПО на Си - UB, хаки, расширения компилятора. В этот раз UB звезды сложились по-другому, возможно, компилятор выкинул что-то нужное.

    Неплохо бы проверить, заработает ли с -O0.

     
     
  • 3.139, Аноним (138), 12:20, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >хаки, расширения компилятора

    Если бы вот это вот поменялось, то тупо не скомпилировалось бы. А не то, что только не работает.

     
  • 2.114, Аноним с Оболони (?), 06:21, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > не работает

    Что ты имеешь ввиду? Мы не телепаты.

     
     
  • 3.131, Аноним (131), 10:40, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А чего тут иметь в виду? Всё как обычно по мануалу, кросс-компиляция:  

        make clean  
        make defconfig  
        make all  
        dd бинарник на sd-карту  

    После gcc 6 загрузка есть, после gcc 11 загрузки нет. Исходники одни и те же.  
    (для rk3288 например это так)

     
     
  • 4.140, Аноним (138), 12:36, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А что линкер одной и той же версии при разных GCC?
     
  • 2.121, Аноним (-), 09:53, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > почему u-boot от 2017г., собраный (под armv7) gcc 6 работает, а gcc 11 не работает?

    А у тебя новый тулчейн - того же triple'а? Т.е. например armhf -> armhf, none-eabi -> none-eabi, ... а иначе уже возможны варианты.

     
     
  • 3.133, Аноним (131), 10:56, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Да, нее, gcc в стандартной поставке "из коробки".
    На fedora 31-35 пробовал собирать, u-boot не стартует.
    Специально старую fedora 25 поставил с gcc 6, u-boot стартует.

    Более древние инструменты требуют более древних сред.
    Не стал с этим заморачиваться.

    Получается сам u-boot под древний инструмент писался?
    Ну, просто, с последними версиями u-boot такая же ерунда -
    новыми инструментами собирается, но не работает.

     
     
  • 4.167, Аноним (-), 21:31, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну хз, под мои железки 12-м GCC из Debian - нормуль билдуется И работает Но я ... большой текст свёрнут, показать
     
     
  • 5.177, Аноним (177), 18:17, 09/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо, заработало!
    Хм, в доке написано, что u-boot поддерживает LTO, но для девелоперских целей, можно указать NO_LTO=1 make. Старанно всё это.
     
     
  • 6.180, Аноним (180), 18:36, 09/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Офигеть попал пальцем в небо Или что называется, системный скилл таки говори... большой текст свёрнут, показать
     
  • 2.174, Аноним (48), 12:03, 09/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Никогда такого не было и тут опять!
     

  • 1.98, Прадед (?), 23:29, 07/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > обращение к необъявленным функциям (-Werror=implicit-function-declaration),

    Свершилось

     
  • 1.112, Аноним (-), 06:09, 08/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Объявлена устаревшей поддержка CPU Intel Xeon Phi.

    А на чём под него теперь компилять, тем более, что его хоть купить можно стало?

     
     
  • 2.115, Аноним (48), 07:44, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Предыдущие версии компилятора из интернетов удалили?
     
  • 2.117, Аноним (117), 08:36, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Фирменным конь пилятором от Интел. Он же icc пишут что он загнулся, но вроде ещё дышит.
     
  • 2.137, Аноним (138), 12:09, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Срочно писать разрабам GCC челобитную с приложением подтверждения факта наличия в продаже Xeon Phi. (На Aliexpress?) Чтоб не спешили с выкидыванием.
     
     
  • 3.155, Есенин (-), 17:38, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Куча Xeon-ов попала на мировой рынок по причине того, что хозяева центров обработки данных решили сделать апргрейд своего оборудования. А старые процессоры по дешёвке распродают. Да-да, Xeon устарел. И не забудьте прикупить к Xeon-у совместимую материнскую плату.
     
     
  • 4.173, Аноним (48), 12:02, 09/05/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не Xeon, а Xeon Phi. Это не процессор в привычном понимании. И он не устарел, он просто никому не нужен.
     
     
  • 5.210, Аноним (210), 18:46, 13/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Xeon Phi. Это не процессор в привычном понимании.

    А что же это за зверь?

     

  • 1.119, Вы забыли заполнить поле Name (?), 08:59, 08/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Значительно расширены возможности для статического анализа кода на языке Си

    Почему бы не взять для этого OCaml?

     
     
  • 2.136, Аноним (138), 12:04, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    На OCaml написать статические анализаторы для лругих языков из GCC? Но для начала надо сам фронтенд OCaml туда запилить.
     

  • 1.143, Аноним (143), 13:19, 08/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >В компиляторе для языка Fortran началась работа над поддержкой стандарта Fortran 2023

    Для чего он нужен-то?

     
     
  • 2.147, Аноним (147), 14:20, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Программы писать на нём. Наверное.
     
  • 2.156, Есенин (-), 17:42, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем 2024 году Фортран? Значит, где-то что-то пишется на этом языке. Помните, внезапно оказалось, что более половины работающего софта мировых банков написан на Коболе. Я думаю, что ниша Фортрана это академические круги. Скорей всего старые математики.
     
     
  • 3.158, Аноним (2), 18:22, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Фортран по-прежнему лидирует в областях, где надо складывать матрицы, в частности, при вычислениях на суперкомпьютерах. Эффективней ничего не придумали. Погоду там считать, ядерные реакции, белки наверно, и так далее. Ну и NVIDIA последние годы активно занимается популяризацией, у неё правда свой компилятор и он поверх LLVM.
     
     
  • 4.160, Аноним (147), 19:33, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Фортран по-прежнему лидирует в областях, где надо складывать матрицы, в частности, при вычислениях на суперкомпьютерах. Эффективней ничего не придумали.

    А если я реализую то же самое умножение матриц, только на Си, это будет менее эффективно? :)

     
     
  • 5.161, 1 (??), 19:40, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    за много десятилетий на фортране написале очень много библитек для научных расчетов. сам факт непрекращающегося развития фортрана говорит о его востребованности
     
     
  • 6.162, 1 (??), 19:41, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    и да, эти библиотеки отлажены и я думаю даже очень "вылизаны"
     
  • 6.171, Аноним (-), 23:33, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > за много десятилетий на фортране написале очень много библитек для научных расчетов.
    > сам факт непрекращающегося развития фортрана говорит о его востребованности

    Широко известный в узких кругах. Где-то сразу за коболом. Xnec2c приветы передавал... таки - переписали, вот. С openacc и проч даеж зело щустрее стало.

     
  • 5.164, Аноним (2), 20:58, 08/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще, да. Обычно, если избавляются от фортрана (по разным причинам), то заменяют его на кресты. С переменным успехом.
     
  • 5.176, Аноним (176), 12:39, 09/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    не реализуешь
     
  • 5.179, Bottle (?), 18:28, 09/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Только если не забудешь ключевое слово "restrict", делающее эквивалентными указатели в сишке и фортране.
     
  • 3.211, Вы забыли заполнить поле Иаше (?), 21:53, 13/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    тут так смешно про модули в С++ рассуждают, а в фортране они есть уже 30 лет как...

    Причём на любой вкус: можно как в Си сигнатуры отдельно, реализации отдельно (субмодули), можно всё в один файл пихать.

    Ещё вот тут: https://fortran-lang.org/learn/rosetta_stone/ рядом код на Питоне и Фортране, делающий примерно одно и то же, выглядит не то чтобы сильно длиннее.

     
     
  • 4.212, n00by (ok), 12:30, 14/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    В Си (и плюсах) "модули" реализованы препроцессором и линкером, вот что самое смешное.
     
  • 4.214, Аноним (213), 18:00, 15/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >тут так смешно про модули в С++ рассуждают, а в фортране они есть уже 30 лет как...

    Ну так а шо вы хотели? Сишконаследие...

     
  • 2.196, Аноним (194), 17:05, 11/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Если даже на нем пишут мало что нового все еще нужно поддерживать то что работает и во что вложены большие деньги, например прогнозы погоды всякие. Это тебе не hello world переписать, туда миллионы вложены.
     

  • 1.192, awg (?), 22:23, 10/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > После года разработки опубликован релиз свободного набора компиляторов GCC 14.1, первый
    > значительный выпуск в новой ветке GCC 14.x. В соответствии с новой
    > схемой нумерации выпусков, версия 14.0 использовалась в процессе разработки, а незадолго
    > до выхода GCC 14.1 уже ответвилась ветка GCC 15.0, на базе
    > которой будет сформирован следующий значительный релиз GCC 15.1...
    > Подробнее: https://www.opennet.me/opennews/art.shtml?num=61132

    жду в trixie и собирать ванильное ядро с -fhardened >:-F

     
     
  • 2.201, cheburnator9000 (ok), 17:38, 12/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ftrivial-auto-var-init=zero в некоторых ситуациях в работе с буферами может снизить производительность кода до 35%, скорость можно вернуть переписав код, но как пишут не всегда возможно да и не всегда получишь оригинальную производительность.
     
     
  • 3.202, awg (?), 19:36, 12/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > ftrivial-auto-var-init=zero в некоторых ситуациях в работе с буферами может снизить производительность
    > кода до 35%, скорость можно вернуть переписав код, но как пишут
    > не всегда возможно да и не всегда получишь оригинальную производительность.

    а разве mitigations, уже реализованные, не снижают производительность?
    плюс к ним сет -fhardened.
    вообщем жду не дождусь когда пайплайн в trixie зарелизит gcc-14

     
     
  • 4.203, cheburnator9000 (ok), 20:03, 12/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> ftrivial-auto-var-init=zero в некоторых ситуациях в работе с буферами может снизить производительность
    >> кода до 35%, скорость можно вернуть переписав код, но как пишут
    >> не всегда возможно да и не всегда получишь оригинальную производительность.
    > а разве mitigations, уже реализованные, не снижают производительность?
    > плюс к ним сет -fhardened.
    > вообщем жду не дождусь когда пайплайн в trixie зарелизит gcc-14

    Нет. Это совсем другое. mitigations в разных случаях по разному влияют на работу CPU снижая эффективность спекулятивного выполнения кода.

    https://serge-sans-paille.github.io/pythran-stories/trivial-auto-var-init-expe

    Этот флаг же в свою очередь заставляет всегда инициировать память объектов стека нулями. Постоянное пересоздание буферов в циклах в таких случаях приведёт к неминуемой потери скорости из-за затирания блока памяти нулями. Да это спасает от проблем когда кто-то захочет сразу прочитать буфер без записи в него новых данных (получит нули), без флага же он получит рандомные мусорные данные.

     
  • 4.204, awg (?), 20:24, 12/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >> ftrivial-auto-var-init=zero в некоторых ситуациях в работе с буферами может снизить производительность
    >> кода до 35%, скорость можно вернуть переписав код, но как пишут
    >> не всегда возможно да и не всегда получишь оригинальную производительность.
    > а разве mitigations, уже реализованные, не снижают производительность?
    > плюс к ним сет -fhardened.
    > вообщем жду не дождусь когда пайплайн в trixie зарелизит gcc-14

    $ zgrep -i zero /proc/config.gz
    CONFIG_DM_ZERO=m
    CONFIG_HID_U2FZERO=m
    CONFIG_HID_ZEROPLUS=m
    CONFIG_ZEROPLUS_FF=y
    # CONFIG_USB_ZERO is not set
    CONFIG_CC_HAS_AUTO_VAR_INIT_ZERO_BARE=y
    CONFIG_CC_HAS_AUTO_VAR_INIT_ZERO=y
    CONFIG_INIT_STACK_ALL_ZERO=y
    CONFIG_CC_HAS_ZERO_CALL_USED_REGS=y
    # CONFIG_ZERO_CALL_USED_REGS is not set

    оно, не? это running image, vanilla 6.8.9 @ localhost

     

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



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

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