После года разработки опубликован релиз свободного набора компиляторов GCC 14.1, первый значительный выпуск в новой ветке GCC 14.x. В соответствии с новой схемой нумерации выпусков, версия 14.0 использовалась в процессе разработки, а незадолго до выхода GCC 14.1 уже ответвилась ветка GCC 15.0, на базе которой будет сформирован следующий значительный релиз GCC 15.1...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61132
> Добавлено новое предупреждение "-Wanalyzer-infinite-loop" для выявления бесконечных цикловОни решили проблему остонова! Вот что значит энтузиасты, вот что значит сообщество, миллиардеры из гаража!
находят конструкцию while (true), дальше ищут в ней break, если не нашли - infinite-loop, если нашли, то проверяют на наличие условий always-true или always-false. Самый примитивный случай.
while (true) if (false) break;
Штош, добавим и такую проверку.
while (true) {
#define break continue
break;
}
Анализируется AST после препроцессинга
Ты же понимаешь, что AST уже после прохода препроцессора строится?
> while (true) {
> #define break continue
> break;
> }Решил как-то анон компилер препроцессором обдурить. А оказалось что обдурили его - компилер после препроцессора работает! Вот что бывает если маны не читать.
Неужели до сих непонятно?! После препроцессора работает! Пойми наконец, ну! Да что ж ты бестолковый такой, ну?!
Коллеги, кто ещё о препроцессоре не написал? Просьба не затягивать, отписаться по возможности скорее.
> Коллеги, кто ещё о препроцессоре не написал? Просьба не затягивать, отписаться по
> возможности скорее.а препроцессор это обызательная часть компилятора ЯП?
Именно компилятора С - да, обязятельная.
>> Коллеги, кто ещё о препроцессоре не написал? Просьба не затягивать, отписаться по
>> возможности скорее.
> а препроцессор это обызательная часть компилятора ЯП?В случае С и C++ это тупо часть стандарта. Должен быть, иначе это noncompliant.
> while (true) if (false) break;ну да самый примитивный случай, выявляется в compile-time.
чего только не придумают, лишь бы goto не юзать
goto?
> goto?если че, это безусловный переход.
Та по сути while в итоге превратится в тот же goto, только условие ещё будет проверять))
Ну зато адепты кода без goto будут уверены что то что в скобочках - безопасно.
> Та по сути while в итоге превратится в тот же goto, только
> условие ещё будет проверять))разница в том, что если юзать goto, то по определению уже возможен бесконечный цикл. И это используется осознанно. А кто-то разве запрещал в программе бесконечные циклы?
А вот в случае с условным циклов, должно быть задано условие конечности (если не иначе) цикла, и вот тут если есть возможность статически предположить бесконечность цикла, то заранее сообщить ворнингом, вероятно непредвиденное (неожиданное) поведение. А как предположить? попыткой вычислить условное выражение на вечную-истину или вечную-ложь.
В англ вики дан вот такой пример:
"""
For example, in pseudocode, the programwhile (true) continue
does not halt; rather, it goes on forever in an infinite loop. On the other hand, the program
"""
Это что за ересь? Они считают, что ненайдется алгоритм (статический анализатор), который может точно сказать, что это бесконечный цикл? Эт что за пример?
В случае с goto дело не в небезопасности, а лапшекодовости.
В случае goto дело в том, что аббревиатура КА не гуглится в Википедии.
> миллиардеры из гаражаТы в каком мире фантазии. Это было сделано с условием что либо получить. Пока ничего нету так что скоро уезжаю.
Почему чтение файла в коде, скомпилированном gcc-O2, в 2 раза быстрее чем в clang? Такая разница делает мне некомфортно. Вот это фрагмент, даhttps://books.google.ru/books?id=xlkPDAAAQBAJ&lpg=PT413&ots=...
> Почему чтение файла в коде, скомпилированном gcc-O2, в 2 раза быстрее чем
> в clang?Потому что это наброс?
> Такая разница делает мне некомфортно.
"Такая", в смысле, воображаемая? Пока нет результатов тестов, нет разницы.
Я привёл код, вперёд, воспроизводи. Почитай в интернете про ядерные кэши и планирование эксперимента заодно.
> Я привёл код, вперёд, воспроизводи."Воспроизвести" означает "повторить опыт" за тобой. Результаты ты не привёл, стало быть и опыт не ставил.
> Почитай в интернете про ядерные кэши.
Кеши ядер процессора не имеют отношения к файловым операциям. А вот файловый вполне влияет и заметно. Ты не слышал про прогрев? :)
> и планирование эксперимента заодно.
Этот твой ответ вполне укладывается в допустимую погрешность. ;)
> "Воспроизвести" означает "повторить опыт" за тобой. Результаты ты не привёл, стало быть
> и опыт не ставил.какой хитрец, результаты ему заранее давай, чтоб он подвел под них собственные, в этом то и интрига. И по вашим результатам ясно будет, вроводили вы их или нет, может с потолка взяли, как говорили нам в школе :)
Но ведь это не мне надо. Если тебе так тяжело написать мейкфайл на 20 строк (ещё 20 строк на тесты) и 60 строк достаточно примитивного кода (40 из которых скопировать), то, может быть, это всё просто не твоё. Но, видишь тут какое дело, я не могу _гарантировать_ воспроизводимость, только то, что ситуация имеет место. Зависит от оборудования, тестовых данных, и так далее. А может, у тебя там тулчейн без libcxx или руки кривые, много вариантов. И неплохо бы посмотреть на твои результаты, прежде чем продолжать разговор.
> Но ведь это не мне надо.В смысле, не тебе? Тебя кто-то заставил задать вопрос, якобы тебе интересен ответ?
> Если тебе так тяжело написать мейкфайл
> на 20 строк (ещё 20 строк на тесты) и 60 строк
> достаточно примитивного кода (40 из которых скопировать), то, может быть, это
> всё просто не твоё.Мейкфайл для сборки одной единицы трансляции? Это не просто тяжело, мне такую бессмысленную деятельность религия не позволяет.
> Но, видишь тут какое дело, я не могу _гарантировать_ воспроизводимость,
> только то, что ситуация имеет место. Зависит от
> оборудования, тестовых данных, и так далее.Естественно, зависит. Потому ты и должен указать, что именно, чем, с какими ключами собирал. Что бы каждый мог тупо скопировать и посмотреть, так ли это в его случае. Это позволяет локализовать проблему.
> А может, у тебя там тулчейн без libcxx или руки кривые, много вариантов.
Вот потому ты и должен указать, какой у тебя "тулчейн", что бы повторяли именно с ним.
> И неплохо бы
> посмотреть на твои результаты, прежде чем продолжать разговор.Для продолжения разговора с тобой мне результаты не требуются - априори ясно, что ты не ставил эксперимент. Ты можешь с важным видом написать любую чушь: мне этого достаточно, что бы ответить, как оно принято в метрологии. Если настроение окажется подходящим.
>[оверквотинг удален]
> ли это в его случае. Это позволяет локализовать проблему.
>> А может, у тебя там тулчейн без libcxx или руки кривые, много вариантов.
> Вот потому ты и должен указать, какой у тебя "тулчейн", что бы
> повторяли именно с ним.
>> И неплохо бы
>> посмотреть на твои результаты, прежде чем продолжать разговор.
> Для продолжения разговора с тобой мне результаты не требуются - априори ясно,
> что ты не ставил эксперимент. Ты можешь с важным видом написать
> любую чушь: мне этого достаточно, что бы ответить, как оно принято
> в метрологии. Если настроение окажется подходящим.На этом можно и закончить разговор. Ты некомпетентен и способен только заниматься пустословием и глупо переводить стрелки. Да, меня интересует, почему используется такой неэффективный код в индустриально принятом компиляторе, но и только. Может быть, я что-то упускаю и этому есть оправдание.
Кстати, для сведения, мейкфайл прекрасно подходит для автоматизации пересборки 1 единицы трансляции, из которой получается десяток отдельных бинарей, не содержащих постороннего кода, а также для организации исполнения после сборки.
Твоё желание зачем-то спорить с очевидным вообще странно выглядит. Я за полчаса собрал и протестировал все варианты во всех интересующих условиях (разные носители, разный размер файла) несколькими тулчейнами, изучил их в дизассемблере и выяснил много интересного благодаря тому же cachegrind, в котором видно, что именно создаёт задержки в коде.
И мне было вполне интересно выяснить наиболее эффективные приёмы чтения файлов и по какой причине в одних компиляторах они ощутимо более эффективны, чем в других. Если ты не способен воспроизвести такой элементарный эксперимент, то говорить тут просто не о чем, и тебе определённо стоит прекратить тратить своё и чужое время.
> На этом можно и закончить разговор.Так будь последователен, закончи. Зачем ты написал следом простыню? Возомнил, что я буду читать, когда ты не указал условия эксперимента?
Именно это я и сделал, попутно поставив все точки и указав на определённые когнитивные ошибки, а также абсолютную необоснованность домыслов. Немного приятно, что мои собственные домыслы о твоих способностях оказались корректными.
Спасибо, показал цену своих слов: написал "закончил" и следом два сообщения. Это понятнее для зрителя, чем отсылка к метрологии.
Возьми да сравни код на ассемблере. Или нам за тебя это делать? Мне лень.
Так я вижу в дизассемблере, но это не ответ на вопрос "почему".
Я тебе тайну открою, возможно. Под MacOS и iOS оно, вероятно, более оптимально компиляет ;)
Если видишь, тогда сравнивай по одной команде. Всё познаётся в сравнении.
Это бессмысленное сравнение. Если уж сравнивать, то время исполнения одной (любой) команды и время чтения с накопителя.
Потому что код криво написан. Это и дураку ясно.
Почему все эти корпорации не могут написать clang не криво? Гнутый опенсорсный компилятор унижает всех этих корпоративных разработчиков.
Там код по ссылке "кривой", поэтому работает медленно. Такое часто бывает, что код, использующий стандартную библиотеку работает медленно. К сожалению реализация стандартных библиотек С++ в Clang и GCC оставляет желать лучшего. Либо надо где-то что-то настраивать. Для достижения лучшей производительности часто приходится переписывать какую-то функциональность самостоятельно вместо того, чтобы воспользоваться ею из стандартной библиотеки С++. Своя реализация, бывает, что в разы и даже в десятки раз работает быстрее... Как-то так. Мне казалось, что стандартную библиотеку должны писать профессионалы, но нет...
> Там код по ссылке "кривой", поэтому работает медленно. Такое часто бывает, что
> код, использующий стандартную библиотеку работает медленно. К сожалению реализация стандартных
> библиотек С++ в Clang и GCC оставляет желать лучшего. Либо надо
> где-то что-то настраивать. Для достижения лучшей производительности часто приходится
> переписывать какую-то функциональность самостоятельно вместо того, чтобы воспользоваться
> ею из стандартной библиотеки С++. Своя реализация, бывает, что в разы
> и даже в десятки раз работает быстрее... Как-то так. Мне казалось,
> что стандартную библиотеку должны писать профессионалы, но нет...без примера - ложь, звездёжь и провокация.
К clang много вопросов, не догадывается до достаточно простых вещей. В книге, кстати, рассматривается также и "переписывать какую-то функциональность самостоятельно", но что-то не впечатляет. Можно предположить, что только 1 вариант неплохо работает (но он ощутимо медленнее "улучшенных" вариантов):
time -p ./bin/readfile_string.gcc "$TESTFILE"
time -p ./bin/readfile_string.gcc "$TESTFILE"
time -p ./bin/readfile_string.gcc "$TESTFILE"
---
real 12.70
user 1.54
sys 1.93
---
real 6.53
user 1.59
sys 1.76
---
real 5.95
user 1.63
sys 1.59
time -p ./bin/readfile_string.clang "$TESTFILE"
time -p ./bin/readfile_string.clang "$TESTFILE"
time -p ./bin/readfile_string.clang "$TESTFILE"
---
real 11.67
user 0.92
sys 1.96
---
real 6.69
user 0.87
sys 1.68
---
real 5.73
user 0.88
sys 1.68
time -p ./bin/readfile_resize.gcc "$TESTFILE"
time -p ./bin/readfile_resize.gcc "$TESTFILE"
time -p ./bin/readfile_resize.gcc "$TESTFILE"
---
real 10.72
user 0.12
sys 1.33
---
real 1.14
user 0.14
sys 0.99
---
real 1.14
user 0.15
sys 0.98
time -p ./bin/readfile_resize.clang "$TESTFILE"
time -p ./bin/readfile_resize.clang "$TESTFILE"
time -p ./bin/readfile_resize.clang "$TESTFILE"
---
real 10.79
user 0.42
sys 1.44
---
real 1.35
user 0.47
sys 0.87
---
real 1.32
user 0.43
sys 0.87
time -p ./bin/readfile_assign.gcc "$TESTFILE"
time -p ./bin/readfile_assign.gcc "$TESTFILE"
time -p ./bin/readfile_assign.gcc "$TESTFILE"
---
real 11.03
user 0.41
sys 1.86
---
real 3.86
user 0.44
sys 1.61
---
real 3.84
user 0.40
sys 1.56
time -p ./bin/readfile_assign.clang "$TESTFILE"
time -p ./bin/readfile_assign.clang "$TESTFILE"
time -p ./bin/readfile_assign.clang "$TESTFILE"
---
real 11.04
user 0.76
sys 2.03
---
real 3.99
user 0.71
sys 1.55
---
real 5.06
user 0.71
sys 1.70
time -p ./bin/readfile_whileread.gcc "$TESTFILE"
time -p ./bin/readfile_whileread.gcc "$TESTFILE"
time -p ./bin/readfile_whileread.gcc "$TESTFILE"
---
real 31.52
user 29.94
sys 0.77
---
real 30.23
user 29.93
sys 0.25
---
real 30.20
user 29.90
sys 0.26
time -p ./bin/readfile_whileread.clang "$TESTFILE"
time -p ./bin/readfile_whileread.clang "$TESTFILE"
time -p ./bin/readfile_whileread.clang "$TESTFILE"
---
real 101.05
user 93.37
sys 4.81
---
real 90.21
user 83.18
sys 4.93
---
real 89.42
user 83.58
sys 4.34
Гцц лучше в лайкли/анлайкли. Такое чувство что в шланге его пустым местом оставили
Переписывание тупо в лоб не особенно эффективно. Эффективно переосмысление задачи: изменение интерфейса какого-то функционала вместе с изменением модели его использования, что позволяет сделать более эффективную реализацию. В таком случае преимущество по производительности и/или памяти можно получить в разы и даже в десятки раз по сравнению со стандартными библиотеками С и С++, причём часто вместе с улучшением удобства использования. Иногда можно немного урезать функционал или гибкость, но сильно поднять производительность. В таком духе. Тем более программный интерфейс у стандартной библиотеки С++ такой себе, на любителя, часто очень многословный и плохо читаемый.
Ой все, типа никто не знает что гцц пишет красношапка .
Сомневаюсь, у неё были только разработчики для avahi, но они перебрались в Майрософт.
Когда-то точно писала. В эпоху форка под названием egcs точно было. Но и сами они тогда были настоящей опенорсной компанией.
лучший
> для выявления переполнений буфера, например, добавлена возможность отображения диаграммы с визуализацией состояния, приводящего к переполнениюТак стоп, оставьте свои диагностики и диаграммы растовикам. Настоящий сяшник обязан ещё в голове избежать переполнения буфера - вон сколько софта без багов написали.
Похоже, с сишниками стало всё плохо, если им начали диаграммы со стрелочками рисовать)(я имею в виду реальных сишников, а не фэнтезийных из комментов на опеннете)
наканецта можно нормально с++23 пощупать, до этого больше всего с++23 в гомо-msvc++ поддерживались
import std; вроде так и не завезли
Не, не завезли. И я очень опечален этим. В новых книжках повсеместно описывают работу с модулями и для этого рекомендуют использовать MSVC.
Да и то, под CMake'ом всё равно пока очень тяжело заставить работать этот import std;
Может вот-вот в CMake 3.30 сделают простой способ его включения. Тогда можно будет параллельно читать книгу Крэга Скотта про CMake и Ivor'а Horton'а по C++23
да сейчас в принципе выбор книг по 23 плюсам невелик
> Не, не завезли. И я очень опечален этиманалогично, читаю beginning c++23, а там такое:
Ближайшие лет 5-10 можете про модули не вспоминать. Разве что на коленке поиграться ради интереса.
What changed?All of these were either invalid in C99, invalid even in C89, or extremely dubious. Compilers just tolerated them as quasi-extensions until now to avoid disruption.
Clang 15 makes the following errors by default:
-Werror=int-conversionClang 16 (released March 2023) makes the following errors by default:
-Werror=implicit-function-declaration
-Werror=implicit-int
-Werror=incompatible-function-pointer-types (GCC does not have a specific equivalent error (PR109835), use -Werror=incompatible-pointer-types instead when testing)GCC 14 (to be released appx. April/May 2024) makes the following errors by default:
-Werror=int-conversion
-Werror=implicit-function-declaration
-Werror=implicit-int
-Werror=incompatible-pointer-types
-Werror=return-mismatch ('new' warning in GCC 14, split out from -Wreturn-type)
-Werror=declaration-missing-parameter-type (new warning in GCC 14)
Всё хочу чтобы они сделали __declspec(property), удобная же штука, а уж GCC славится всяческими полезными расширениями (многие из которых просто можно брать готовые и вносить в стандарт языка)
Лишь бы [[gnu::]] не использовать. Позаимствовано из C++.
Да пускай как угодно называется, главное чтобы сама фича была.
RTFM https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
Как там с поддержкой раста уже?
С поддержкой D давно порядок
Похоже на то, что средства работы с AST ещё не перетянули с DMD. Или у меня неточные представления?
Кстати, не подскажете, куда Dшники с сайта https://lhs-blog.info/ перебрались? А то домен вообще перестал определяться.
Пока растовики не пришлют патч - никак.
Уже все забыли что в gcc реально добавляют раст - gccrs.Вот даже ссылка на ежемесячные отчеты с прогрессом. Есть milestone-ы до весны 2025... Может в gcc 16 войдет полная версия компилятора.
https://opennet.ru/57491-rust
https://rust-gcc.github.io/
Такой прекрасный язык, что даже оба компилятора для него написаны на С++
разве rust еще не self-hosted?
Давным-давно. И первые версии на Ocaml, а не на дырявом были написаны.
Rust зависит от llvm, так что он не self-hosted.
gcc зависит от binutils, тоже не сильно самостоятельный проект.
Ага, не путай тёплое с мокрым, компилятор с линкером.
> Давным-давно. И первые версии на Ocaml, а не на дырявом были написаны.Вперся кому ваш эзотерик, аж два раза. А вулны в компилере... не хочу вас расстраивать, но если проект решил вас при сборке поиметь, эксплуатация вулна в компилере это какой-то сложный и эзотеричный способ достойный фанатов ocaml. Более приземленные личности, вон, "тесткейсов" в билд систему запихнули - и в дамках.
Rust под собой использует llvm, а он как раз написан на C++. Благодаря llvm у rust есть возможность поддерживать все его архитектуры CPU. В отличие от Go, когда который только начинали создавать у llvm не было всех возможностей необходимые для Go, а вот сейчас уже давно есть.
как ни странно, но все нормальные компиляторы С тоже на С++ написаны
Tiny C Compiler и pcc - написаны на Си :-P
Tiny C Compiler не является нормальным компилятором по причине скорости генерируемого кода. Но проект занятный, да.
По таким строгим критериям тогда и единственный пригодный компилятор Rust не является нормальным.
Только по одной причине - AST разбирать с помощью STL проще
> Как там с поддержкой раста уже?gccrs весьма активно пилят. Читай фороникс, там про это есть - и GSoC актуальный по этой теме весьма приличный, например.
А вот скажи почему этот самый gccrs пилят на С++, а не на расте?
Бутстрапить проще, да и на расте реализация раста уже есть.
То есть в расте есть какие-то проблемы с бутстрапом? А говорят Сишку заменить хочет
> То есть в расте есть какие-то проблемы с бутстрапом? А говорят Сишку
> заменить хочетА сишники часами только сидят и бустрапят компиляторы? В последний раз я проверял, это делают только разработчики компиляторов и мейнтейнеры пакетов.
Бутстрап rustc, конечно, долго (а на всяких эзотерических сетапах ещё и муторно) делать, но большинство людей с этим вообще не сталкиваются.
А в Си проблем с бутстрапом нет, вот и не делают.
Там жёсткая привязка к шлангу, говорят. Раньше-то он в сишку сначала гонялся, а потом компиляй-нехочу.
ждём новых багов и проблем в различном программном обеспечении. Я до сих пор помню, как frrouting версии 7.5 крашился при sh ip ospf interface. А текже пог рандомно крашнутся, при анонсировании l3vpn через bgp.
> ждём новых багов и проблем в различном программном обеспечении. Я до сих пор
> помню, как frrouting версии 7.5 крашился при sh ip ospf interface. А текже
> пог рандомно крашнутся, при анонсировании l3vpn через bgp.Багов бояться - разработкой софта не заниматься. А если вам надо стабильность - в чем ваша проблема юзать какой-нибудь стабильный дистр, проверив раз в дохрена что все ок - получите 4-8 лет спокойной жизни, а может и больше. А если вы хотели все сами компилять распоследним компилером распоследней версии софта - все новые баги будут ваши! Простите, бесплатный сыр - только второй мышке. Жаль что вам про это не рассказали.
Спасибо. Как обновится w64devkit и если VirusTotal не найдет там чего-то страшного (а то я очкую, даже зная, что скорее всего это ложное срабатывание), то тогда поюзаю эту штуку.
Модули С++20 походу никогда нормально не заработают
На модули в плюсах можно смело забивать. Быстрее рак на горе засыестит, чем их полноценно реализуют...
А метаклассы в каком стандарте ждать? Я даже не про реализацию, а, хотя бы, про стандартизацию.
лучше сразу мета-мета классы
А что с ними не так?
STL же ещё препроцессором, а не модулями.
Это досадно, конечно (без сарказма), но разве фатальная преграда?
Без препроцессора ожидаемо повышение скорости компиляции.
https://en.cppreference.com/w/cpp/compiler_support/20На деле только Visual Studio более менее полноценно реализовал модули, но и там IntelliSence не работает, если в проекте есть модули
Напоминают export template.
>Модули С++20 походу никогда нормально не заработаютЭто уже Паскаль головного мозга. Бывшим паскальщикам, в своё время надо было переходить на Джаву, а не C++.
Кто поумнее, так и сделал.
Как будто что-то плохое. Модули нужны в первую очередь для ускорения и без того медленной компиляции.
> для ускорения
> и без того медленнойВзаимоисключающие параграфы.
>> для ускорения
>> и без того медленной
> Взаимоисключающие параграфы.Показательно, да. Сами не понимают, что пишут, повторяя за кем-то мантры. Если бы "для ускорения медленной", тогда бы имело смысл.
> Как будто что-то плохое. Модули нужны в первую очередь для ускорения и
> без того медленной компиляции.То есть они нужны не тем, кто программы пишет, а кто собирает из чужих исходников.
Товарищ нуби когда-нибудь поумнеет, чтобы осознать важность быстрой сборки программ для тех, кто пишет код.
Может и ты когда-нибудь найдёшь у меня на гитхапе и поймёшь, что если 15 лет назад я сделал header-only стандартную библиотеку на плюсах, то я ещё тогда экспертных баек наслушался. Показать свой проект, который дооооолго собирается, понятное дело, не сможешь.
Какая разница из своих/несвоих? Скорость очень не помешает тем, кто свою систему собирает из исходников. Кдешники-гентушники возрадуются!
Разница существенная. Программисты используют язык, что бы создавать программное обеспечение. Если нет ПО, то собирать нечего. Потому в данном вопросе в приоритете программисты.
Из чужих исходников программа собирается один раз, а из своих — сто двадцать один (за день).
Сто двадцать раз на дню компилируют вот такие персонажи:
>Разгадку подсказал мне однажды сам кандидат: он объяснил, что обычно, когда пишет код, то сразу же пытается его запускать и редактирует вусмерть, пока хоть как-то не заработает. ... Когда удалось нашаманить, чтобы текст компилировался, то можно выпускать бета-версию, а когда программа сможет хоть раз не упасть и не зависнуть — финальный релиз. Остальные баги найдут пользователи.
Он в vim редактирует? Ошибки синтаксиса обычно редактор подсвечивает. Но местные умельцы скомпилировать 121 раз банально врут: сначала у них "дооооолго компилируется", а потом оказывается, что менее 3-х минут.
Собирается программа из объектников, а не из исходников. Но откуда тебе это знать?
А зачем они такие нужны?Единственное для чего они могли бы использоваться - разруливание циклических зависимостей.
Но стандарт приняли таким, что такие зависимости модулей недопустимы.
Так какую проблему они могут решить?
Тебе то ничего не нужно, когда у тебя проект из одного файла
>Реализованы возможности, определённые в будущем Си-стандарте C23Кто в курсе ратификация стандарта в этом году состоится? Почему комитет до сих пор держит стандарт в качестве черновика?
потомучто. держу в курсе!
>>Реализованы возможности, определённые в будущем Си-стандарте C23
> Кто в курсе ратификация стандарта в этом году состоится?open-std.org/jtc1/sc22/wg14/www/docs/n3156.pdf
:)> Почему комитет до сих пор держит стандарт в качестве черновика?
а ты хочешь еще один С11? куда спешить, вечность впереди.
Почему бы самый последний ратифицированный стандарт не использовать? В Сишке не так много (мало) нововведений в стандарты вносят, компиляторы с реализацией поспевают. Ну кроме чьего-то пальца, препятствий не видно.
> Почему бы самый последний ратифицированный стандарт не использовать? В Сишке не так
> много (мало) нововведений в стандарты вносят, компиляторы с реализацией поспевают. Ну
> кроме чьего-то пальца, препятствий не видно.вы о чем?
P.S. а касательно стандарта - убери пдф из ссылки, и глянь другие, датированные 24 годом.
Работа кипит. Надеюсь, таймлайн что по ссылке скинул ранее они отодвинут. Не хотелось бы еще один С11 получить, когда они два дня назад обсуждают фичу.
>>Реализованы возможности, определённые в будущем Си-стандарте C23
> Кто в курсе ратификация стандарта в этом году состоится? Почему комитет до
> сих пор держит стандарт в качестве черновика?Что бы можно было скачать и не жаловаться потом на цену.)
Лучше c99 ничего нет.
Ты еще сидишь на ядре 2.6 с GNOME 2 и пишешь это из какого-нибудь Firefox 10, да?
> Ты еще сидишь на ядре 2.6 с GNOME 2 и пишешь это
> из какого-нибудь Firefox 10, да?охосспаде. кто о чем, а вшивый о бане.
Ну, у меня для вас плохие новости, да. 2.6.32 от какого-нибудь 5.15 в части стандарта c отличается вот "никак" и оба используют - та-дааам! С89.
Но вы конечно можете этим ретроградам объяснить, как и в чем они не правы..
И все же с 5.18 (или самая ранняя LTS - 6.1) используется C11 :)
> И все же с 5.18 (или самая ранняя LTS - 6.1) используется
> C11 :)В курсе - по этому и ограничился "каким-нибудь 5.15"
А вообще с точки зрения компилятора везде разные требования к версии GCC. Так что даже, если стандарт одинаков (C89), не факт, что какой-нибудь GCC 4.4 сможет собрать обе ветки.
> А вообще с точки зрения компилятора везде разные требования к версии GCC.
> Так что даже, если стандарт одинаков (C89), не факт, что какой-нибудь
> GCC 4.4 сможет собрать обе ветки.Не, ну это прям отдельная печальная история - костыли, велосипеды, компиляторы C и linux kernel... Вот уже ажно "ANSI - стандарт" на язык есть - а собрать чем угодно всё одно, нельзя.
> Лучше c99 ничего нет.Без static assert'ов то? :) Не, их конечно можно и самому сделать но вот чтобы с нормальной диагностикой - уже сложнее, да...
> Лучше c99 ничего нет.не-не-не, с89 - ессенция. пишешь свой компилер? с89 - база. с99 напишешь уже на с89.
Так-то с K&R надо начинать, а все эти ваши 89, 99 — баловство.
> Так-то с K&R надо начинать, а все эти ваши 89, 99 — баловство.унылый троллинг. c89 образно говоря, включает в себя субсет K&R, без особой модификации кода (сравни первую и вторую редакцию настольной книги). Более того, K&R такой, blunt standard (не стандарт вовсе), в результате чего семантика языка становится спекулятивна для интерпретации каждым поставщиком компилятора. с89 уравнивает компиляторы в этом.
но лучше бы ты опять что-то сморозил про коре два дуо, и дидов.
и что? код, сгенеренный этим компиллятором, быстрее получается, чем, когда превидущие генерировали?
Да, быстрее в некоторых случаях из-за улучшенной оптимизации. А ещё диагностика ошибок стала лучше
Каждая версия приносит заметные улучшения. Самое впечатляющее в районе 9 версии случилось, генерировать PGO для произвольного кода стало намного проще. Просто собираешь программу как обычно, используешь во всех интересующих применениях, и пересобираешь с целевыми оптимизациями 2 раз. Жалко только для сишки хорошо работает. GCC с PGO даёт код в 100% случаев более быстрый и эффективный (в частности, задействует оптимизации 3 уровня только там, где они точно необходимы). Но появлялись ещё дополнительные оптимизации (например, очень эффективные для питона) и разного рода защиты.
А, вот интересно, кто знает:
почему u-boot от 2017г., собраный (под armv7) gcc 6 работает, а gcc 11 не работает?
Хотя ошибок сборки нет.
Потому что типичная кодовая база системного ПО на Си - UB, хаки, расширения компилятора. В этот раз UB звезды сложились по-другому, возможно, компилятор выкинул что-то нужное.Неплохо бы проверить, заработает ли с -O0.
>хаки, расширения компилятораЕсли бы вот это вот поменялось, то тупо не скомпилировалось бы. А не то, что только не работает.
> не работаетЧто ты имеешь ввиду? Мы не телепаты.
А чего тут иметь в виду? Всё как обычно по мануалу, кросс-компиляция:make clean
make defconfig
make all
dd бинарник на sd-картуПосле gcc 6 загрузка есть, после gcc 11 загрузки нет. Исходники одни и те же.
(для rk3288 например это так)
А что линкер одной и той же версии при разных GCC?
> почему u-boot от 2017г., собраный (под armv7) gcc 6 работает, а gcc 11 не работает?А у тебя новый тулчейн - того же triple'а? Т.е. например armhf -> armhf, none-eabi -> none-eabi, ... а иначе уже возможны варианты.
Да, нее, gcc в стандартной поставке "из коробки".
На fedora 31-35 пробовал собирать, u-boot не стартует.
Специально старую fedora 25 поставил с gcc 6, u-boot стартует.Более древние инструменты требуют более древних сред.
Не стал с этим заморачиваться.Получается сам u-boot под древний инструмент писался?
Ну, просто, с последними версиями u-boot такая же ерунда -
новыми инструментами собирается, но не работает.
> Более древние инструменты требуют более древних сред.
> Не стал с этим заморачиваться.
> Получается сам u-boot под древний инструмент писался?
> Ну, просто, с последними версиями u-boot такая же ерунда -
> новыми инструментами собирается, но не работает.Ну хз, под мои железки 12-м GCC из Debian - нормуль билдуется. И работает. Но я знаю что делаю и таки более-менее трекаю состояние платформ и тулчейнов. А не так что раз - и через 5 версий прыгнули и гадай что, где и когда отпало.
По нормальному билды делаются по ходу пьесы, а когда что-то отваливается - апстрим информируется о баге и баг чинится. В таком режиме все просто, логично и понятно. И надо то - изредка билд пинать, раз в релиз тулчейна может.
А если вообще не стартит - ну печалька, смотреть чем-то типа JTAG или (если воспроизводится, в qemu с GDB дебаг хостом) где оно висит и делать выводы. Самое очевидное: у вас LTO не активен случайно по дефолту? С федористов станется а в бутлоадере и проч он могет и лишнего убить, в бутлоадере то.
Или как вариант посмотреть несколько версий тулчейна и понять где отвалилось. Если не лениво - bisect сделать. Благо это не особо долго и сложно. Если оно нужно.
Спасибо, заработало!
Хм, в доке написано, что u-boot поддерживает LTO, но для девелоперских целей, можно указать NO_LTO=1 make. Старанно всё это.
> Спасибо, заработало!Офигеть :) попал пальцем в небо. Или что называется, системный скилл таки говорит за себя сам.
> Хм, в доке написано, что u-boot поддерживает LTO, но для девелоперских целей,
> можно указать NO_LTO=1 make. Старанно всё это.Теоретиески, LTO может работать с кернелами, фирмварями, бутлоадерами и проч.
Практически, если кто-то что-то где-то проморгает или что-то пойдет не так, он может запросто убабахать якобы-unused код какого-нибудь interrupt (или чего там еще) handler'а, вызываемого ЖЕЛЕЗОМ - что компилеру не видно - как якобы-unusued. И вот тут можно малость обломаться если прошляпить этот момент. Мне LTO как-то выпилил таблицу векторов в фирмвари. Ну а что, ее никто из софта и правда не юзает. А то что она нужна железу... ээ... ну компилер то не телепат, грохнул dead code/data :)
Если что затыкается __attribute__((used)). А, да, к сожалению это нестандартный экстеншн. Ну вот нет в стандарте варианта как форсануть нужность энного объекта для оптимизера "потому что юзается железом".
Никогда такого не было и тут опять!
> обращение к необъявленным функциям (-Werror=implicit-function-declaration),Свершилось
>Объявлена устаревшей поддержка CPU Intel Xeon Phi.А на чём под него теперь компилять, тем более, что его хоть купить можно стало?
Предыдущие версии компилятора из интернетов удалили?
Фирменным конь пилятором от Интел. Он же icc пишут что он загнулся, но вроде ещё дышит.
Срочно писать разрабам GCC челобитную с приложением подтверждения факта наличия в продаже Xeon Phi. (На Aliexpress?) Чтоб не спешили с выкидыванием.
Куча Xeon-ов попала на мировой рынок по причине того, что хозяева центров обработки данных решили сделать апргрейд своего оборудования. А старые процессоры по дешёвке распродают. Да-да, Xeon устарел. И не забудьте прикупить к Xeon-у совместимую материнскую плату.
Не Xeon, а Xeon Phi. Это не процессор в привычном понимании. И он не устарел, он просто никому не нужен.
>Xeon Phi. Это не процессор в привычном понимании.А что же это за зверь?
> Значительно расширены возможности для статического анализа кода на языке СиПочему бы не взять для этого OCaml?
На OCaml написать статические анализаторы для лругих языков из GCC? Но для начала надо сам фронтенд OCaml туда запилить.
>В компиляторе для языка Fortran началась работа над поддержкой стандарта Fortran 2023Для чего он нужен-то?
Программы писать на нём. Наверное.
Зачем 2024 году Фортран? Значит, где-то что-то пишется на этом языке. Помните, внезапно оказалось, что более половины работающего софта мировых банков написан на Коболе. Я думаю, что ниша Фортрана это академические круги. Скорей всего старые математики.
Фортран по-прежнему лидирует в областях, где надо складывать матрицы, в частности, при вычислениях на суперкомпьютерах. Эффективней ничего не придумали. Погоду там считать, ядерные реакции, белки наверно, и так далее. Ну и NVIDIA последние годы активно занимается популяризацией, у неё правда свой компилятор и он поверх LLVM.
> Фортран по-прежнему лидирует в областях, где надо складывать матрицы, в частности, при вычислениях на суперкомпьютерах. Эффективней ничего не придумали.А если я реализую то же самое умножение матриц, только на Си, это будет менее эффективно? :)
за много десятилетий на фортране написале очень много библитек для научных расчетов. сам факт непрекращающегося развития фортрана говорит о его востребованности
и да, эти библиотеки отлажены и я думаю даже очень "вылизаны"
> за много десятилетий на фортране написале очень много библитек для научных расчетов.
> сам факт непрекращающегося развития фортрана говорит о его востребованностиШироко известный в узких кругах. Где-то сразу за коболом. Xnec2c приветы передавал... таки - переписали, вот. С openacc и проч даеж зело щустрее стало.
Вообще, да. Обычно, если избавляются от фортрана (по разным причинам), то заменяют его на кресты. С переменным успехом.
не реализуешь
Только если не забудешь ключевое слово "restrict", делающее эквивалентными указатели в сишке и фортране.
тут так смешно про модули в С++ рассуждают, а в фортране они есть уже 30 лет как...Причём на любой вкус: можно как в Си сигнатуры отдельно, реализации отдельно (субмодули), можно всё в один файл пихать.
Ещё вот тут: https://fortran-lang.org/learn/rosetta_stone/ рядом код на Питоне и Фортране, делающий примерно одно и то же, выглядит не то чтобы сильно длиннее.
В Си (и плюсах) "модули" реализованы препроцессором и линкером, вот что самое смешное.
>тут так смешно про модули в С++ рассуждают, а в фортране они есть уже 30 лет как...Ну так а шо вы хотели? Сишконаследие...
Если даже на нем пишут мало что нового все еще нужно поддерживать то что работает и во что вложены большие деньги, например прогнозы погоды всякие. Это тебе не hello world переписать, туда миллионы вложены.
> После года разработки опубликован релиз свободного набора компиляторов GCC 14.1, первый
> значительный выпуск в новой ветке GCC 14.x. В соответствии с новой
> схемой нумерации выпусков, версия 14.0 использовалась в процессе разработки, а незадолго
> до выхода GCC 14.1 уже ответвилась ветка GCC 15.0, на базе
> которой будет сформирован следующий значительный релиз GCC 15.1...
> Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61132жду в trixie и собирать ванильное ядро с -fhardened >:-F
ftrivial-auto-var-init=zero в некоторых ситуациях в работе с буферами может снизить производительность кода до 35%, скорость можно вернуть переписав код, но как пишут не всегда возможно да и не всегда получишь оригинальную производительность.
> ftrivial-auto-var-init=zero в некоторых ситуациях в работе с буферами может снизить производительность
> кода до 35%, скорость можно вернуть переписав код, но как пишут
> не всегда возможно да и не всегда получишь оригинальную производительность.а разве mitigations, уже реализованные, не снижают производительность?
плюс к ним сет -fhardened.
вообщем жду не дождусь когда пайплайн в trixie зарелизит gcc-14
>> ftrivial-auto-var-init=zero в некоторых ситуациях в работе с буферами может снизить производительность
>> кода до 35%, скорость можно вернуть переписав код, но как пишут
>> не всегда возможно да и не всегда получишь оригинальную производительность.
> а разве mitigations, уже реализованные, не снижают производительность?
> плюс к ним сет -fhardened.
> вообщем жду не дождусь когда пайплайн в trixie зарелизит gcc-14Нет. Это совсем другое. mitigations в разных случаях по разному влияют на работу CPU снижая эффективность спекулятивного выполнения кода.
https://serge-sans-paille.github.io/pythran-stories/trivial-...
Этот флаг же в свою очередь заставляет всегда инициировать память объектов стека нулями. Постоянное пересоздание буферов в циклах в таких случаях приведёт к неминуемой потери скорости из-за затирания блока памяти нулями. Да это спасает от проблем когда кто-то захочет сразу прочитать буфер без записи в него новых данных (получит нули), без флага же он получит рандомные мусорные данные.
>> 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