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

"Релиз набора компиляторов GCC 14"	+/–
Сообщение от opennews (??), 07-Май-24, 14:26
После года разработки опубликован релиз свободного набора компиляторов 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
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 07-Май-24, 14:26	+15 +/–
> Добавлено новое предупреждение "-Wanalyzer-infinite-loop" для выявления бесконечных циклов Они решили проблему остонова! Вот что значит энтузиасты, вот что значит сообщество, миллиардеры из гаража!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #60

2. Сообщение от Аноним (2), 07-Май-24, 14:26	–1 +/–
Почему чтение файла в коде, скомпилированном gcc-O2, в 2 раза быстрее чем в clang? Такая разница делает мне некомфортно. Вот это фрагмент, да https://books.google.ru/books?id=xlkPDAAAQBAJ&lpg=PT413&ots=...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10, #16, #73

4. Сообщение от тыквенное латте (?), 07-Май-24, 14:38	+3 +/–
лучший
Ответить | Правка | Наверх | Cообщить модератору

5. Сообщение от НяшМяш (ok), 07-Май-24, 14:55	+1 +/–
> для выявления переполнений буфера, например, добавлена возможность отображения диаграммы с визуализацией состояния, приводящего к переполнению Так стоп, оставьте свои диагностики и диаграммы растовикам. Настоящий сяшник обязан ещё в голове избежать переполнения буфера - вон сколько софта без багов написали.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #30

7. Сообщение от 12yoexpert (ok), 07-Май-24, 15:04	+/–
наканецта можно нормально с++23 пощупать, до этого больше всего с++23 в гомо-msvc++ поддерживались
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #38

10. Сообщение от n00by (ok), 07-Май-24, 15:11	+1 +/–
> Почему чтение файла в коде, скомпилированном gcc-O2, в 2 раза быстрее чем > в clang? Потому что это наброс? > Такая разница делает мне некомфортно. "Такая", в смысле, воображаемая? Пока нет результатов тестов, нет разницы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #12

12. Сообщение от Аноним (2), 07-Май-24, 15:15	–9 +/–
Я привёл код, вперёд, воспроизводи. Почитай в интернете про ядерные кэши и планирование эксперимента заодно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #122

13. Сообщение от Аноним (13), 07-Май-24, 15:19	–1 +/–
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-conversion     Clang 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)
Ответить | Правка | Наверх | Cообщить модератору

14. Сообщение от nc (ok), 07-Май-24, 15:22	+/–
Всё хочу чтобы они сделали __declspec(property), удобная же штука, а уж GCC славится всяческими полезными расширениями (многие из которых просто можно брать готовые и вносить в стандарт языка)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41, #186

15. Сообщение от Sw00p aka Jerom (?), 07-Май-24, 15:25	–6 +/–
находят конструкцию while (true), дальше ищут в ней break, если не нашли - infinite-loop, если нашли, то проверяют на наличие условий always-true или always-false. Самый примитивный случай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #25, #106, #152

16. Сообщение от Пряник (?), 07-Май-24, 15:26	+2 +/–
Возьми да сравни код на ассемблере. Или нам за тебя это делать? Мне лень.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #20

18. Сообщение от Аноним (18), 07-Май-24, 15:34	–4 +/–
Как там с поддержкой раста уже?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #22, #24, #49, #62, #101

19. Сообщение от Аноним (19), 07-Май-24, 15:35	–1 +/–
ждём новых багов и проблем в различном программном обеспечении. Я до сих пор помню, как frrouting версии 7.5 крашился при sh ip ospf interface. А текже пог рандомно крашнутся, при анонсировании l3vpn через bgp.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #67

20. Сообщение от Аноним (2), 07-Май-24, 15:44	–2 +/–
Так я вижу в дизассемблере, но это не ответ на вопрос "почему".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #33, #45

21. Сообщение от Аноним (21), 07-Май-24, 15:46	+1 +/–
Спасибо. Как обновится w64devkit и если VirusTotal не найдет там чего-то страшного (а то я очкую, даже зная, что скорее всего это ложное срабатывание), то тогда поюзаю эту штуку.
Ответить | Правка | Наверх | Cообщить модератору

22. Сообщение от Hck3r (?), 07-Май-24, 15:54	+3 +/–
С поддержкой D давно порядок
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #29, #205

23. Сообщение от Аноним (25), 07-Май-24, 15:56	+2 +/–
Модули С++20 походу никогда нормально не заработают
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26, #28, #31, #35, #149

24. Сообщение от Аноним (24), 07-Май-24, 15:57	+1 +/–
Пока растовики не пришлют патч - никак.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

25. Сообщение от Аноним (25), 07-Май-24, 15:59	+8 +/–
while (true) if (false) break;
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #27, #71

26. Сообщение от Дед (??), 07-Май-24, 16:08	+3 +/–
На модули в плюсах можно смело забивать. Быстрее рак на горе засыестит, чем их полноценно реализуют...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

27. Сообщение от Fracta1L (ok), 07-Май-24, 16:08	+7 +/–
Штош, добавим и такую проверку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #47

28. Сообщение от Аноним (33), 07-Май-24, 16:09	+1 +/–
А метаклассы в каком стандарте ждать? Я даже не про реализацию, а, хотя бы, про стандартизацию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #53

29. Сообщение от Аноним (33), 07-Май-24, 16:12	+/–
Похоже на то, что средства работы с AST ещё не перетянули с DMD. Или у меня неточные представления?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

30. Сообщение от Fracta1L (ok), 07-Май-24, 16:12	–4 +/–
Похоже, с сишниками стало всё плохо, если им начали диаграммы со стрелочками рисовать) (я имею в виду реальных сишников, а не фэнтезийных из комментов на опеннете)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

31. Сообщение от Fracta1L (ok), 07-Май-24, 16:14	+/–
А что с ними не так?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #34, #91, #127

32. Сообщение от Аноним (-), 07-Май-24, 16:20	+/–
>Реализованы возможности, определённые в будущем Си-стандарте C23 Кто в курсе ратификация стандарта в этом году состоится? Почему комитет до сих пор держит стандарт в качестве черновика?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #55, #58, #130

33. Сообщение от Аноним (33), 07-Май-24, 16:20	–1 +/–
Я тебе тайну открою, возможно. Под MacOS и iOS оно, вероятно, более оптимально компиляет ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

34. Сообщение от Аноним (33), 07-Май-24, 16:22	+1 +/–
STL же ещё препроцессором, а не модулями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #46

35. Сообщение от Аноним (-), 07-Май-24, 16:25	+1 +/–
>Модули С++20 походу никогда нормально не заработают Это уже Паскаль головного мозга. Бывшим паскальщикам, в своё время надо было переходить на Джаву, а не C++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #48, #56

38. Сообщение от eugene_martein (ok), 07-Май-24, 16:29	+3 +/–
import std; вроде так и не завезли
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #74, #78

41. Сообщение от Аноним (41), 07-Май-24, 16:34	+/–
Лишь бы [[gnu::]] не использовать. Позаимствовано из C++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #118

42. Сообщение от Аноним (135), 07-Май-24, 16:57	+/–
Лучше c99 ничего нет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44, #68, #70

44. Сообщение от anonymous (??), 07-Май-24, 17:24	+/–
Ты еще сидишь на ядре 2.6 с GNOME 2 и пишешь это из какого-нибудь Firefox 10, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #64, #80

45. Сообщение от Пряник (?), 07-Май-24, 17:27	+1 +/–
Если видишь, тогда сравнивай по одной команде. Всё познаётся в сравнении.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #126

46. Сообщение от Fracta1L (ok), 07-Май-24, 17:27	+/–
Это досадно, конечно (без сарказма), но разве фатальная преграда?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #65

47. Сообщение от Аноним (47), 07-Май-24, 17:29	–1 +/–
while (true) { #define break continue   break; }
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #54, #57, #61, #90, #132

48. Сообщение от Аноним (48), 07-Май-24, 17:34	+2 +/–
Кто поумнее, так и сделал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

49. Сообщение от Аноним (49), 07-Май-24, 17:37	+1 +/–
Уже все забыли что в gcc реально добавляют раст - gccrs. Вот даже ссылка на ежемесячные отчеты с прогрессом. Есть milestone-ы до весны 2025... Может в gcc 16 войдет полная версия компилятора. https://opennet.ru/57491-rust https://rust-gcc.github.io/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #51

50. Сообщение от Аноним (50), 07-Май-24, 17:44	–2 +/–
и что? код, сгенеренный этим компиллятором, быстрее получается, чем, когда превидущие генерировали?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #52, #69

51. Сообщение от Аноним (24), 07-Май-24, 18:11	+1 +/–
Такой прекрасный язык, что даже оба компилятора для него написаны на С++
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #59, #123

52. Сообщение от Аноним (24), 07-Май-24, 18:13	+1 +/–
Да, быстрее в некоторых случаях из-за улучшенной оптимизации. А ещё диагностика ошибок стала лучше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

53. Сообщение от Аноним (53), 07-Май-24, 18:17	+/–
лучше сразу мета-мета классы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

54. Сообщение от unknown (??), 07-Май-24, 18:21	+4 +/–
Анализируется AST после препроцессинга
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

55. Сообщение от Аноним (55), 07-Май-24, 18:30	+/–
потомучто. держу в курсе!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

56. Сообщение от Bottle (?), 07-Май-24, 18:31	+/–
Как будто что-то плохое. Модули нужны в первую очередь для ускорения и без того медленной компиляции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #85, #128

57. Сообщение от kravich (ok), 07-Май-24, 18:34	+3 +/–
Ты же понимаешь, что AST уже после прохода препроцессора строится?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

58. Сообщение от тыквенное латте (?), 07-Май-24, 18:41	+/–
>>Реализованы возможности, определённые в будущем Си-стандарте C23 > Кто в курсе ратификация стандарта в этом году состоится? open-std.org/jtc1/sc22/wg14/www/docs/n3156.pdf :) > Почему комитет до сих пор держит стандарт в качестве черновика? а ты хочешь еще один С11? куда спешить, вечность впереди.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #66

59. Сообщение от Anon62513512124 (?), 07-Май-24, 18:48	+/–
разве rust еще не self-hosted?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #63, #111

60. Сообщение от Nv (?), 07-Май-24, 18:52	+/–
> миллиардеры из гаража Ты в каком мире фантазии. Это было сделано с условием что либо получить. Пока ничего нету так что скоро уезжаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

61. Сообщение от Аноним (-), 07-Май-24, 18:55	+11 +/–
> while (true) { > #define break continue >  break; > } Решил как-то анон компилер препроцессором обдурить. А оказалось что обдурили его - компилер после препроцессора работает! Вот что бывает если маны не читать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

62. Сообщение от Аноним (-), 07-Май-24, 18:58	+/–
> Как там с поддержкой раста уже? gccrs весьма активно пилят. Читай фороникс, там про это есть - и GSoC актуальный по этой теме весьма приличный, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #87

63. Сообщение от Аноним (63), 07-Май-24, 19:02	–1 +/–
Давным-давно. И первые версии на Ocaml, а не на дырявом были написаны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #135, #166

64. Сообщение от тыквенное латте (?), 07-Май-24, 19:02	+2 +/–
> Ты еще сидишь на ядре 2.6 с GNOME 2 и пишешь это > из какого-нибудь Firefox 10, да? охосспаде. кто о чем, а вшивый о бане.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

65. Сообщение от Аноним (33), 07-Май-24, 19:04	+/–
Без препроцессора ожидаемо повышение скорости компиляции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

66. Сообщение от Аноним (33), 07-Май-24, 19:10	+/–
Почему бы самый последний ратифицированный стандарт не использовать? В Сишке не так много (мало) нововведений в стандарты вносят, компиляторы с реализацией поспевают. Ну кроме чьего-то пальца, препятствий не видно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #72

67. Сообщение от Аноним (67), 07-Май-24, 19:11	+1 +/–
>  ждём новых багов и проблем в различном программном обеспечении. Я до сих пор > помню, как frrouting версии 7.5 крашился при sh ip ospf interface. А текже > пог рандомно крашнутся, при анонсировании l3vpn через bgp. Багов бояться - разработкой софта не заниматься. А если вам надо стабильность - в чем ваша проблема юзать какой-нибудь стабильный дистр, проверив раз в дохрена что все ок - получите 4-8 лет спокойной жизни, а может и больше. А если вы хотели все сами компилять распоследним компилером распоследней версии софта - все новые баги будут ваши! Простите, бесплатный сыр - только второй мышке. Жаль что вам про это не рассказали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

68. Сообщение от Аноним (67), 07-Май-24, 19:13	+/–
> Лучше c99 ничего нет. Без static assert'ов то? :) Не, их конечно можно и самому сделать но вот чтобы с нормальной диагностикой - уже сложнее, да...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

69. Сообщение от Аноним (2), 07-Май-24, 19:14	+/–
Каждая версия приносит заметные улучшения. Самое впечатляющее в районе 9 версии случилось, генерировать PGO для произвольного кода стало намного проще. Просто собираешь программу как обычно, используешь во всех интересующих применениях, и пересобираешь с целевыми оптимизациями 2 раз. Жалко только для сишки хорошо работает. GCC с PGO даёт код в 100% случаев более быстрый и эффективный (в частности, задействует оптимизации 3 уровня только там, где они точно необходимы). Но появлялись ещё дополнительные оптимизации (например, очень эффективные для питона) и разного рода защиты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

70. Сообщение от тыквенное латте (?), 07-Май-24, 19:16	+1 +/–
> Лучше c99 ничего нет. не-не-не, с89 - ессенция. пишешь свой компилер? с89 - база. с99 напишешь уже на с89.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #76

71. Сообщение от Sw00p aka Jerom (?), 07-Май-24, 19:24	+/–
> while (true) if (false) break; ну да самый примитивный случай, выявляется в compile-time.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

72. Сообщение от тыквенное латте (?), 07-Май-24, 19:27	+/–
> Почему бы самый последний ратифицированный стандарт не использовать? В Сишке не так > много (мало) нововведений в стандарты вносят, компиляторы с реализацией поспевают. Ну > кроме чьего-то пальца, препятствий не видно. вы о чем? P.S. а касательно стандарта - убери пдф из ссылки, и глянь другие, датированные 24 годом. Работа кипит. Надеюсь, таймлайн что по ссылке скинул ранее они отодвинут. Не хотелось бы еще один С11 получить, когда они два дня назад обсуждают фичу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

73. Сообщение от Ivan7 (ok), 07-Май-24, 19:36	+1 +/–
Потому что код криво написан. Это и дураку ясно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #75

74. Сообщение от Аноним (74), 07-Май-24, 19:38	+/–
Не, не завезли. И я очень опечален этим. В новых книжках повсеместно описывают работу с модулями и для этого рекомендуют использовать MSVC.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #79, #104

75. Сообщение от Аноним (2), 07-Май-24, 19:39	–3 +/–
Почему все эти корпорации не могут написать clang не криво? Гнутый опенсорсный компилятор унижает всех этих корпоративных разработчиков.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #77, #96

76. Сообщение от Аноним (48), 07-Май-24, 19:47	+/–
Так-то с K&R надо начинать, а все эти ваши 89, 99 — баловство.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #81

77. Сообщение от Ivan7 (ok), 07-Май-24, 19:50	–1 +/–
Там код по ссылке "кривой", поэтому работает медленно. Такое часто бывает, что код, использующий стандартную библиотеку работает медленно. К сожалению реализация стандартных библиотек С++ в Clang и GCC оставляет желать лучшего. Либо надо где-то что-то настраивать. Для достижения лучшей производительности часто приходится переписывать какую-то функциональность самостоятельно вместо того, чтобы воспользоваться ею из стандартной библиотеки С++. Своя реализация, бывает, что в разы и даже в десятки раз работает быстрее... Как-то так. Мне казалось, что стандартную библиотеку должны писать профессионалы, но нет...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #82, #92

78. Сообщение от Аноним (78), 07-Май-24, 20:09	+/–
Ближайшие лет 5-10 можете про модули не вспоминать. Разве что на коленке поиграться ради интереса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

79. Сообщение от eugene_martein (ok), 07-Май-24, 20:42	+/–
Да и то, под CMake'ом всё равно пока очень тяжело заставить работать этот import std; Может вот-вот в CMake 3.30 сделают простой способ его включения. Тогда можно будет параллельно читать книгу Крэга Скотта про CMake и Ivor'а Horton'а по C++23
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #105

80. Сообщение от User (??), 07-Май-24, 20:56	+3 +/–
Ну, у меня для вас плохие новости, да. 2.6.32 от какого-нибудь 5.15 в части стандарта c отличается вот "никак" и оба используют - та-дааам! С89. Но вы конечно можете этим ретроградам объяснить, как и в чем они не правы..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #199, #200

81. Сообщение от тыквенное латте (?), 07-Май-24, 20:58	+2 +/–
> Так-то с K&R надо начинать, а все эти ваши 89, 99 — баловство. унылый троллинг. c89 образно говоря, включает в себя субсет K&R, без особой модификации кода (сравни первую и вторую редакцию настольной книги). Более того, K&R такой, blunt standard (не стандарт вовсе), в результате чего семантика языка становится спекулятивна для интерпретации каждым поставщиком компилятора. с89 уравнивает компиляторы в этом. но лучше бы ты опять что-то сморозил про коре два дуо, и дидов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

82. Сообщение от тыквенное латте (?), 07-Май-24, 21:01	+2 +/–
> Там код по ссылке "кривой", поэтому работает медленно. Такое часто бывает, что > код, использующий стандартную библиотеку работает медленно. К сожалению реализация стандартных > библиотек С++ в Clang и GCC оставляет желать лучшего. Либо надо > где-то что-то настраивать. Для достижения лучшей производительности часто приходится > переписывать какую-то функциональность самостоятельно вместо того, чтобы воспользоваться > ею из стандартной библиотеки С++. Своя реализация, бывает, что в разы > и даже в десятки раз работает быстрее... Как-то так. Мне казалось, > что стандартную библиотеку должны писать профессионалы, но нет... без примера - ложь, звездёжь и провокация.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

83. Сообщение от Аноним (83), 07-Май-24, 21:03	+/–
А, вот интересно, кто знает: почему u-boot от 2017г., собраный (под armv7) gcc 6 работает, а gcc 11 не работает? Хотя ошибок сборки нет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #95, #114, #121, #174

85. Сообщение от Аноним (85), 07-Май-24, 21:47	+/–
> для ускорения > и без того медленной Взаимоисключающие параграфы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #129

87. Сообщение от Аноним (24), 07-Май-24, 21:54	+1 +/–
А вот скажи почему этот самый gccrs пилят на С++, а не на расте?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #94

90. Сообщение от Аноним (47), 07-Май-24, 22:22	+5 +/–
Неужели до сих непонятно?! После препроцессора работает! Пойми наконец, ну! Да что ж ты бестолковый такой, ну?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

91. Сообщение от Аноним (91), 07-Май-24, 22:22	+/–
https://en.cppreference.com/w/cpp/compiler_support/20 На деле только Visual Studio более менее полноценно реализовал модули, но и там IntelliSence не работает, если в проекте есть модули
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

92. Сообщение от Аноним (2), 07-Май-24, 22:24	+/–
К 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
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #99, #110

94. Сообщение от errandrunner (?), 07-Май-24, 22:29	+/–
Бутстрапить проще, да и на расте реализация раста уже есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #151

95. Сообщение от Аноним (95), 07-Май-24, 22:51	–2 +/–
Потому что типичная кодовая база системного ПО на Си - UB, хаки, расширения компилятора. В этот раз UB звезды сложились по-другому, возможно, компилятор выкинул что-то нужное. Неплохо бы проверить, заработает ли с -O0.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #139

96. Сообщение от Аноним (96), 07-Май-24, 22:54	+/–
Ой все, типа никто не знает что гцц пишет красношапка .
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #97, #102

97. Сообщение от Аноним (2), 07-Май-24, 23:06	+/–
Сомневаюсь, у неё были только разработчики для avahi, но они перебрались в Майрософт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

98. Сообщение от Прадед (?), 07-Май-24, 23:29	+1 +/–
> обращение к необъявленным функциям (-Werror=implicit-function-declaration), Свершилось
Ответить | Правка | Наверх | Cообщить модератору

99. Сообщение от Прадед (?), 07-Май-24, 23:50	+/–
Гцц лучше в лайкли/анлайкли. Такое чувство что в шланге его пустым местом оставили
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

101. Сообщение от Прадед (?), 08-Май-24, 00:29	+/–
Там жёсткая привязка к шлангу, говорят. Раньше-то он в сишку сначала гонялся, а потом компиляй-нехочу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

102. Сообщение от Аноним (102), 08-Май-24, 00:31	+/–
Когда-то точно писала. В эпоху форка под названием egcs точно было. Но и сами они тогда были настоящей опенорсной компанией.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

104. Сообщение от 12yoexpert (ok), 08-Май-24, 00:46	+/–
> Не, не завезли. И я очень опечален этим аналогично, читаю beginning c++23, а там такое: https://github.com/Apress/beginning-cpp23/issues?q=is%3...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

105. Сообщение от 12yoexpert (ok), 08-Май-24, 00:47	+/–
да сейчас в принципе выбор книг по 23 плюсам невелик
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

106. Сообщение от 12yoexpert (ok), 08-Май-24, 00:50	+4 +/–
чего только не придумают, лишь бы goto не юзать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

110. Сообщение от Ivan7 (ok), 08-Май-24, 03:46	+/–
Переписывание тупо в лоб не особенно эффективно. Эффективно переосмысление задачи: изменение интерфейса какого-то функционала вместе с изменением модели его использования, что позволяет сделать более эффективную реализацию. В таком случае преимущество по производительности и/или памяти можно получить в разы и даже в десятки раз по сравнению со стандартными библиотеками С и С++, причём часто вместе с улучшением удобства использования. Иногда можно немного урезать функционал или гибкость, но сильно поднять производительность. В таком духе. Тем более программный интерфейс у стандартной библиотеки С++ такой себе, на любителя, часто очень многословный и плохо читаемый.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

111. Сообщение от cheburnator9000 (ok), 08-Май-24, 04:38	+2 +/–
Rust под собой использует llvm, а он как раз написан на C++. Благодаря llvm у rust есть возможность поддерживать все его архитектуры CPU. В отличие от Go, когда который только начинали создавать у llvm не было всех возможностей необходимые для Go, а вот сейчас уже давно есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

112. Сообщение от Аноним (-), 08-Май-24, 06:09	+/–
>Объявлена устаревшей поддержка CPU Intel Xeon Phi. А на чём под него теперь компилять, тем более, что его хоть купить можно стало?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #115, #117, #137

114. Сообщение от Аноним с Оболони (?), 08-Май-24, 06:21	+1 +/–
> не работает Что ты имеешь ввиду? Мы не телепаты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #131

115. Сообщение от Аноним (48), 08-Май-24, 07:44	+/–
Предыдущие версии компилятора из интернетов удалили?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

117. Сообщение от Аноним (117), 08-Май-24, 08:36	+1 +/–
Фирменным конь пилятором от Интел. Он же icc пишут что он загнулся, но вроде ещё дышит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

118. Сообщение от nc (ok), 08-Май-24, 08:40	+/–
Да пускай как угодно называется, главное чтобы сама фича была.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

119. Сообщение от Вы забыли заполнить поле Name (?), 08-Май-24, 08:59	–1 +/–
> Значительно расширены возможности для статического анализа кода на языке Си Почему бы не взять для этого OCaml?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #136

121. Сообщение от Аноним (-), 08-Май-24, 09:53	+/–
> почему u-boot от 2017г., собраный (под armv7) gcc 6 работает, а gcc 11 не работает? А у тебя новый тулчейн - того же triple'а? Т.е. например armhf -> armhf, none-eabi -> none-eabi, ... а иначе уже возможны варианты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #133

122. Сообщение от n00by (ok), 08-Май-24, 09:54	+/–
> Я привёл код, вперёд, воспроизводи. "Воспроизвести" означает "повторить опыт" за тобой. Результаты ты не привёл, стало быть и опыт не ставил. > Почитай в интернете про ядерные кэши. Кеши ядер процессора не имеют отношения к файловым операциям. А вот файловый вполне влияет и заметно. Ты не слышал про прогрев? :) > и планирование эксперимента заодно. Этот твой ответ вполне укладывается в допустимую погрешность. ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #142, #157

123. Сообщение от Советский инженер (ok), 08-Май-24, 09:55	+3 +/–
как ни странно, но все нормальные компиляторы С тоже на С++ написаны
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #150, #159

126. Сообщение от n00by (ok), 08-Май-24, 09:58	+/–
Это бессмысленное сравнение. Если уж сравнивать, то время исполнения одной (любой) команды и время чтения с накопителя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

127. Сообщение от n00by (ok), 08-Май-24, 10:05	+/–
Напоминают export template.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

128. Сообщение от n00by (ok), 08-Май-24, 10:09	+/–
> Как будто что-то плохое. Модули нужны в первую очередь для ускорения и > без того медленной компиляции. То есть они нужны не тем, кто программы пишет, а кто собирает из чужих исходников.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #134, #138, #175

129. Сообщение от n00by (ok), 08-Май-24, 10:11	+/–
>> для ускорения >> и без того медленной > Взаимоисключающие параграфы. Показательно, да. Сами не понимают, что пишут, повторяя за кем-то мантры. Если бы "для ускорения медленной", тогда бы имело смысл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

130. Сообщение от n00by (ok), 08-Май-24, 10:13	–1 +/–
>>Реализованы возможности, определённые в будущем Си-стандарте C23 > Кто в курсе ратификация стандарта в этом году состоится? Почему комитет до > сих пор держит стандарт в качестве черновика? Что бы можно было скачать и не жаловаться потом на цену.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

131. Сообщение от Аноним (131), 08-Май-24, 10:40	+/–
А чего тут иметь в виду? Всё как обычно по мануалу, кросс-компиляция:       make clean       make defconfig       make all       dd бинарник на sd-карту   После gcc 6 загрузка есть, после gcc 11 загрузки нет. Исходники одни и те же.   (для rk3288 например это так)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #140

132. Сообщение от Аноним (132), 08-Май-24, 10:51	+4 +/–
Коллеги, кто ещё о препроцессоре не написал? Просьба не затягивать, отписаться по возможности скорее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #141

133. Сообщение от Аноним (131), 08-Май-24, 10:56	+/–
Да, нее, gcc в стандартной поставке "из коробки". На fedora 31-35 пробовал собирать, u-boot не стартует. Специально старую fedora 25 поставил с gcc 6, u-boot стартует. Более древние инструменты требуют более древних сред. Не стал с этим заморачиваться. Получается сам u-boot под древний инструмент писался? Ну, просто, с последними версиями u-boot такая же ерунда - новыми инструментами собирается, но не работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #167

134. Сообщение от Bottle (?), 08-Май-24, 11:43    Скрыто ботом-модератором	+/–
Товарищ нуби когда-нибудь поумнеет, чтобы осознать важность быстрой сборки программ для тех, кто пишет код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #145

135. Сообщение от Аноним (135), 08-Май-24, 12:02	–1 +/–
Rust зависит от llvm, так что он не self-hosted.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #148

136. Сообщение от Аноним (138), 08-Май-24, 12:04	+/–
На OCaml написать статические анализаторы для лругих языков из GCC? Но для начала надо сам фронтенд OCaml туда запилить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119

137. Сообщение от Аноним (138), 08-Май-24, 12:09	+/–
Срочно писать разрабам GCC челобитную с приложением подтверждения факта наличия в продаже Xeon Phi. (На Aliexpress?) Чтоб не спешили с выкидыванием.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #155

138. Сообщение от Аноним (138), 08-Май-24, 12:16	+/–
Какая разница из своих/несвоих? Скорость очень не помешает тем, кто свою систему собирает из исходников. Кдешники-гентушники возрадуются!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #146

139. Сообщение от Аноним (138), 08-Май-24, 12:20	+1 +/–
>хаки, расширения компилятора Если бы вот это вот поменялось, то тупо не скомпилировалось бы. А не то, что только не работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95

140. Сообщение от Аноним (138), 08-Май-24, 12:36	+/–
А что линкер одной и той же версии при разных GCC?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131

141. Сообщение от Sw00p aka Jerom (?), 08-Май-24, 12:40	+/–
> Коллеги, кто ещё о препроцессоре не написал? Просьба не затягивать, отписаться по > возможности скорее. а препроцессор это обызательная часть компилятора ЯП?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #144, #172

142. Сообщение от Sw00p aka Jerom (?), 08-Май-24, 12:44	+1 +/–
> "Воспроизвести" означает "повторить опыт" за тобой. Результаты ты не привёл, стало быть > и опыт не ставил. какой хитрец, результаты ему заранее давай, чтоб он подвел под них собственные, в этом то и интрига. И по вашим результатам ясно будет, вроводили вы их или нет, может с потолка взяли, как говорили нам в школе :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

143. Сообщение от Аноним (143), 08-Май-24, 13:19	+/–
>В компиляторе для языка Fortran началась работа над поддержкой стандарта Fortran 2023 Для чего он нужен-то?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #147, #156, #196

144. Сообщение от Аноним (144), 08-Май-24, 13:57	+/–
Именно компилятора С - да, обязятельная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141

145. Сообщение от n00by (ok), 08-Май-24, 14:14	–2 +/–
Может и ты когда-нибудь найдёшь у меня на гитхапе и поймёшь, что если 15 лет назад я сделал header-only стандартную библиотеку на плюсах, то я ещё тогда экспертных баек наслушался. Показать свой проект, который дооооолго собирается, понятное дело, не сможешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134

146. Сообщение от n00by (ok), 08-Май-24, 14:16	+/–
Разница существенная. Программисты используют язык, что бы создавать программное обеспечение. Если нет ПО, то собирать нечего. Потому в данном вопросе в приоритете программисты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138

147. Сообщение от Аноним (147), 08-Май-24, 14:20	+/–
Программы писать на нём. Наверное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

148. Сообщение от Аноним (96), 08-Май-24, 14:39	+/–
gcc зависит от  binutils, тоже не сильно самостоятельный проект.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #206

149. Сообщение от Серб (ok), 08-Май-24, 14:55	+/–
А зачем они такие нужны? Единственное для чего они могли бы использоваться - разруливание циклических зависимостей. Но стандарт приняли таким, что такие зависимости модулей недопустимы. Так какую проблему они могут решить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #182

150. Сообщение от Аноним (150), 08-Май-24, 15:11	+/–
Tiny C Compiler и pcc - написаны на Си :-P
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #178

151. Сообщение от Аноним (150), 08-Май-24, 15:12	+/–
То есть в расте есть какие-то проблемы с бутстрапом? А говорят Сишку заменить хочет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #191

152. Сообщение от Аноним (152), 08-Май-24, 15:23	+/–
goto?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #163

155. Сообщение от Есенин (-), 08-Май-24, 17:38	+/–
Куча Xeon-ов попала на мировой рынок по причине того, что хозяева центров обработки данных решили сделать апргрейд своего оборудования. А старые процессоры по дешёвке распродают. Да-да, Xeon устарел. И не забудьте прикупить к Xeon-у совместимую материнскую плату.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #173

156. Сообщение от Есенин (-), 08-Май-24, 17:42	+/–
Зачем 2024 году Фортран? Значит, где-то что-то пишется на этом языке. Помните, внезапно оказалось, что более половины работающего софта мировых банков написан на Коболе. Я думаю, что ниша Фортрана это академические круги. Скорей всего старые математики.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143 Ответы: #158, #211

157. Сообщение от Аноним (2), 08-Май-24, 18:14	–1 +/–
Но ведь это не мне надо. Если тебе так тяжело написать мейкфайл на 20 строк (ещё 20 строк на тесты) и 60 строк достаточно примитивного кода (40 из которых скопировать), то, может быть, это всё просто не твоё. Но, видишь тут какое дело, я не могу _гарантировать_ воспроизводимость, только то, что ситуация имеет место. Зависит от оборудования, тестовых данных, и так далее. А может, у тебя там тулчейн без libcxx или руки кривые, много вариантов. И неплохо бы посмотреть на твои результаты, прежде чем продолжать разговор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #183

158. Сообщение от Аноним (2), 08-Май-24, 18:22	+/–
Фортран по-прежнему лидирует в областях, где надо складывать матрицы, в частности, при вычислениях на суперкомпьютерах. Эффективней ничего не придумали. Погоду там считать, ядерные реакции, белки наверно, и так далее. Ну и NVIDIA последние годы активно занимается популяризацией, у неё правда свой компилятор и он поверх LLVM.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156 Ответы: #160

159. Сообщение от Аноним (24), 08-Май-24, 19:21	+/–
Только по одной причине - AST разбирать с помощью STL проще
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123

160. Сообщение от Аноним (147), 08-Май-24, 19:33	–1 +/–
> Фортран по-прежнему лидирует в областях, где надо складывать матрицы, в частности, при вычислениях на суперкомпьютерах. Эффективней ничего не придумали. А если я реализую то же самое умножение матриц, только на Си, это будет менее эффективно? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158 Ответы: #161, #164, #176, #179

161. Сообщение от 1 (??), 08-Май-24, 19:40	+/–
за много десятилетий на фортране написале очень много библитек для научных расчетов. сам факт непрекращающегося развития фортрана говорит о его востребованности
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #162, #171

162. Сообщение от 1 (??), 08-Май-24, 19:41	+/–
и да, эти библиотеки отлажены и я думаю даже очень "вылизаны"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

163. Сообщение от Sw00p aka Jerom (?), 08-Май-24, 20:44	+/–
> goto? если че, это безусловный переход.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #168

164. Сообщение от Аноним (2), 08-Май-24, 20:58	+/–
Вообще, да. Обычно, если избавляются от фортрана (по разным причинам), то заменяют его на кресты. С переменным успехом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

166. Сообщение от Аноним (166), 08-Май-24, 21:14	+/–
> Давным-давно. И первые версии на Ocaml, а не на дырявом были написаны. Вперся кому ваш эзотерик, аж два раза. А вулны в компилере... не хочу вас расстраивать, но если проект решил вас при сборке поиметь, эксплуатация вулна в компилере это какой-то сложный и эзотеричный способ достойный фанатов ocaml. Более приземленные личности, вон, "тесткейсов" в билд систему запихнули - и в дамках.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

167. Сообщение от Аноним (-), 08-Май-24, 21:31	+/–
> Более древние инструменты требуют более древних сред. > Не стал с этим заморачиваться. > Получается сам u-boot под древний инструмент писался? > Ну, просто, с последними версиями u-boot такая же ерунда - > новыми инструментами собирается, но не работает. Ну хз, под мои железки 12-м GCC из Debian - нормуль билдуется. И работает. Но я знаю что делаю и таки более-менее трекаю состояние платформ и тулчейнов. А не так что раз - и через 5 версий прыгнули и гадай что, где и когда отпало. По нормальному билды делаются по ходу пьесы, а когда что-то отваливается - апстрим информируется о баге и баг чинится. В таком режиме все просто, логично и понятно. И надо то - изредка билд пинать, раз в релиз тулчейна может. А если вообще не стартит - ну печалька, смотреть чем-то типа JTAG или (если воспроизводится, в qemu с GDB дебаг хостом) где оно висит и делать выводы. Самое очевидное: у вас LTO не активен случайно по дефолту? С федористов станется а в бутлоадере и проч он могет и лишнего убить, в бутлоадере то. Или как вариант посмотреть несколько версий тулчейна и понять где отвалилось. Если не лениво - bisect сделать. Благо это не особо долго и сложно. Если оно нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #177

168. Сообщение от Аноним (168), 08-Май-24, 22:00	+/–
Та по сути while в итоге превратится в тот же goto, только условие ещё будет проверять)) Ну зато адепты кода без goto будут уверены что то что в скобочках - безопасно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163 Ответы: #170, #213

170. Сообщение от Sw00p aka Jerom (?), 08-Май-24, 22:57	+/–
> Та по сути while в итоге превратится в тот же goto, только > условие ещё будет проверять)) разница в том, что если юзать goto, то по определению уже возможен бесконечный цикл. И это используется осознанно. А кто-то разве запрещал в программе бесконечные циклы? А вот в случае с условным циклов, должно быть задано условие конечности (если не иначе) цикла, и вот тут если есть возможность статически предположить бесконечность цикла, то заранее сообщить ворнингом, вероятно непредвиденное (неожиданное) поведение. А как предположить? попыткой вычислить условное выражение на вечную-истину или вечную-ложь. В англ вики дан вот такой пример: """ For example, in pseudocode, the program while (true) continue does not halt; rather, it goes on forever in an infinite loop. On the other hand, the program """ Это что за ересь? Они считают, что ненайдется алгоритм (статический анализатор), который может точно сказать, что это бесконечный цикл? Эт что за пример?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168

171. Сообщение от Аноним (-), 08-Май-24, 23:33	+/–
> за много десятилетий на фортране написале очень много библитек для научных расчетов. > сам факт непрекращающегося развития фортрана говорит о его востребованности Широко известный в узких кругах. Где-то сразу за коболом. Xnec2c приветы передавал... таки - переписали, вот. С openacc и проч даеж зело щустрее стало.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

172. Сообщение от Аноним (-), 08-Май-24, 23:45	+1 +/–
>> Коллеги, кто ещё о препроцессоре не написал? Просьба не затягивать, отписаться по >> возможности скорее. > а препроцессор это обызательная часть компилятора ЯП? В случае С и C++ это тупо часть стандарта. Должен быть, иначе это noncompliant.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141

173. Сообщение от Аноним (48), 09-Май-24, 12:02	+1 +/–
Не Xeon, а Xeon Phi. Это не процессор в привычном понимании. И он не устарел, он просто никому не нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155 Ответы: #210

174. Сообщение от Аноним (48), 09-Май-24, 12:03	+/–
Никогда такого не было и тут опять!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83

175. Сообщение от Аноним (48), 09-Май-24, 12:14	+/–
Из чужих исходников программа собирается один раз, а из своих — сто двадцать один (за день).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #181, #184

176. Сообщение от Аноним (176), 09-Май-24, 12:39	+/–
не реализуешь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

177. Сообщение от Аноним (177), 09-Май-24, 18:17	+/–
Спасибо, заработало! Хм, в доке написано, что u-boot поддерживает LTO, но для девелоперских целей, можно указать NO_LTO=1 make. Старанно всё это.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #180

178. Сообщение от Bottle (?), 09-Май-24, 18:23	+/–
Tiny C Compiler не является нормальным компилятором по причине скорости генерируемого кода. Но проект занятный, да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #194

179. Сообщение от Bottle (?), 09-Май-24, 18:28	+/–
Только если не забудешь ключевое слово "restrict", делающее эквивалентными указатели в сишке и фортране.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

180. Сообщение от Аноним (180), 09-Май-24, 18:36	+/–
> Спасибо, заработало! Офигеть :) попал пальцем в небо. Или что называется, системный скилл таки говорит за себя сам. > Хм, в доке написано, что u-boot поддерживает LTO, но для девелоперских целей, > можно указать NO_LTO=1 make. Старанно всё это. Теоретиески, LTO может работать с кернелами, фирмварями, бутлоадерами и проч. Практически, если кто-то что-то где-то проморгает или что-то пойдет не так, он может запросто убабахать якобы-unused код какого-нибудь interrupt (или чего там еще) handler'а, вызываемого ЖЕЛЕЗОМ - что компилеру не видно - как якобы-unusued. И вот тут можно малость обломаться если прошляпить этот момент. Мне LTO как-то выпилил таблицу векторов в фирмвари. Ну а что, ее никто из софта и правда не юзает. А то что она нужна железу... ээ... ну компилер то не телепат, грохнул dead code/data :) Если что затыкается __attribute__((used)). А, да, к сожалению это нестандартный экстеншн. Ну вот нет в стандарте варианта как форсануть нужность энного объекта для оптимизера "потому что юзается железом".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177

181. Сообщение от Буратино (?), 10-Май-24, 02:03	+/–
Сто двадцать раз на дню компилируют вот такие персонажи: >Разгадку подсказал мне однажды сам кандидат: он объяснил, что обычно, когда пишет код, то сразу же пытается его запускать и редактирует вусмерть, пока хоть как-то не заработает. ... Когда удалось нашаманить, чтобы текст компилировался, то можно выпускать бета-версию, а когда программа сможет хоть раз не упасть и не зависнуть — финальный релиз. Остальные баги найдут пользователи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175 Ответы: #185

182. Сообщение от Аноним (91), 10-Май-24, 05:47    Скрыто ботом-модератором	+2 +/–
Тебе то ничего не нужно, когда у тебя проект из одного файла
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149

183. Сообщение от n00by (ok), 10-Май-24, 12:13	+/–
> Но ведь это не мне надо. В смысле, не тебе? Тебя кто-то заставил задать вопрос, якобы тебе интересен ответ? > Если тебе так тяжело написать мейкфайл > на 20 строк (ещё 20 строк на тесты) и 60 строк > достаточно примитивного кода (40 из которых скопировать), то, может быть, это > всё просто не твоё. Мейкфайл для сборки одной единицы трансляции? Это не просто тяжело, мне такую бессмысленную деятельность религия не позволяет. > Но, видишь тут какое дело, я не могу _гарантировать_ воспроизводимость, > только то, что ситуация имеет место. Зависит от > оборудования, тестовых данных, и так далее. Естественно, зависит. Потому ты и должен указать, что именно, чем, с какими ключами собирал. Что бы каждый мог тупо скопировать и посмотреть, так ли это в его случае. Это позволяет локализовать проблему. > А может, у тебя там тулчейн без libcxx или руки кривые, много вариантов. Вот потому ты и должен указать, какой у тебя "тулчейн", что бы повторяли именно с ним. > И неплохо бы > посмотреть на твои результаты, прежде чем продолжать разговор. Для продолжения разговора с тобой мне результаты не требуются - априори ясно, что ты не ставил эксперимент. Ты можешь с важным видом написать любую чушь: мне этого достаточно, что бы ответить, как оно принято в метрологии. Если настроение окажется подходящим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #187

184. Сообщение от n00by (ok), 10-Май-24, 12:20	+/–
Собирается программа из объектников, а не из исходников. Но откуда тебе это знать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175

185. Сообщение от n00by (ok), 10-Май-24, 12:41	+/–
Он в vim редактирует? Ошибки синтаксиса обычно редактор подсвечивает. Но местные умельцы скомпилировать 121 раз банально врут: сначала у них "дооооолго компилируется", а потом оказывается, что менее 3-х минут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181

186. Сообщение от rtfm (?), 10-Май-24, 14:33	+/–
RTFM https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

187. Сообщение от Аноним (2), 10-Май-24, 15:01	+/–
>[оверквотинг удален] > ли это в его случае. Это позволяет локализовать проблему. >> А может, у тебя там тулчейн без libcxx или руки кривые, много вариантов. > Вот потому ты и должен указать, какой у тебя "тулчейн", что бы > повторяли именно с ним. >> И неплохо бы >> посмотреть на твои результаты, прежде чем продолжать разговор. > Для продолжения разговора с тобой мне результаты не требуются - априори ясно, > что ты не ставил эксперимент. Ты можешь с важным видом написать > любую чушь: мне этого достаточно, что бы ответить, как оно принято > в метрологии. Если настроение окажется подходящим. На этом можно и закончить разговор. Ты некомпетентен и способен только заниматься пустословием и глупо переводить стрелки. Да, меня интересует, почему используется такой неэффективный код в индустриально принятом компиляторе, но и только. Может быть, я что-то упускаю и этому есть оправдание. Кстати, для сведения, мейкфайл прекрасно подходит для автоматизации пересборки 1 единицы трансляции, из которой получается десяток отдельных бинарей, не содержащих постороннего кода, а также для организации исполнения после сборки. Твоё желание зачем-то спорить с очевидным вообще странно выглядит. Я за полчаса собрал и протестировал все варианты во всех интересующих условиях (разные носители, разный размер файла) несколькими тулчейнами, изучил их в дизассемблере и выяснил много интересного благодаря тому же cachegrind, в котором видно, что именно создаёт задержки в коде. И мне было вполне интересно выяснить наиболее эффективные приёмы чтения файлов и по какой причине в одних компиляторах они ощутимо более эффективны, чем в других. Если ты не способен воспроизвести такой элементарный эксперимент, то говорить тут просто не о чем, и тебе определённо стоит прекратить тратить своё и чужое время.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183 Ответы: #188

188. Сообщение от n00by (ok), 10-Май-24, 16:01	+/–
> На этом можно и закончить разговор. Так будь последователен, закончи. Зачем ты написал следом простыню? Возомнил, что я буду читать, когда ты не указал условия эксперимента?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #187 Ответы: #189

189. Сообщение от Аноним (2), 10-Май-24, 16:14	+/–
Именно это я и сделал, попутно поставив все точки и указав на определённые когнитивные ошибки, а также абсолютную необоснованность домыслов. Немного приятно, что мои собственные домыслы о твоих способностях оказались корректными.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188 Ответы: #197

191. Сообщение от errandrunner (?), 10-Май-24, 20:38	+/–
> То есть в расте есть какие-то проблемы с бутстрапом? А говорят Сишку > заменить хочет А сишники часами только сидят и бустрапят компиляторы? В последний раз я проверял, это делают только разработчики компиляторов и мейнтейнеры пакетов. Бутстрап rustc, конечно, долго (а на всяких эзотерических сетапах ещё и муторно) делать, но большинство людей с этим вообще не сталкиваются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151 Ответы: #195

192. Сообщение от awg (?), 10-Май-24, 22:23	+/–
> После года разработки опубликован релиз свободного набора компиляторов 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
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #201

194. Сообщение от Аноним (194), 11-Май-24, 16:53	+1 +/–
По таким строгим критериям тогда и единственный пригодный компилятор Rust не является нормальным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178

195. Сообщение от Аноним (194), 11-Май-24, 16:58	+/–
А в Си проблем с бутстрапом нет, вот и не делают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191

196. Сообщение от Аноним (194), 11-Май-24, 17:05	+/–
Если даже на нем пишут мало что нового все еще нужно поддерживать то что работает и во что вложены большие деньги, например прогнозы погоды всякие. Это тебе не hello world переписать, туда миллионы вложены.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

197. Сообщение от n00by (ok), 12-Май-24, 10:12	–1 +/–
Спасибо, показал цену своих слов: написал "закончил" и следом два сообщения. Это понятнее для зрителя, чем отсылка к метрологии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #189

199. Сообщение от anonymous (??), 12-Май-24, 15:57	+/–
И все же с 5.18 (или самая ранняя LTS - 6.1) используется C11 :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #208

200. Сообщение от anonymous (??), 12-Май-24, 16:00	+/–
А вообще с точки зрения компилятора везде разные требования к версии GCC. Так что даже, если стандарт одинаков (C89), не факт, что какой-нибудь GCC 4.4 сможет собрать обе ветки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #207

201. Сообщение от cheburnator9000 (ok), 12-Май-24, 17:38	+/–
ftrivial-auto-var-init=zero в некоторых ситуациях в работе с буферами может снизить производительность кода до 35%, скорость можно вернуть переписав код, но как пишут не всегда возможно да и не всегда получишь оригинальную производительность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192 Ответы: #202

202. Сообщение от awg (?), 12-Май-24, 19:36	+/–
> ftrivial-auto-var-init=zero в некоторых ситуациях в работе с буферами может снизить производительность > кода до 35%, скорость можно вернуть переписав код, но как пишут > не всегда возможно да и не всегда получишь оригинальную производительность. а разве mitigations, уже реализованные, не снижают производительность? плюс к ним сет -fhardened. вообщем жду не дождусь когда пайплайн в trixie зарелизит gcc-14
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201 Ответы: #203, #204

203. Сообщение от cheburnator9000 (ok), 12-Май-24, 20:03	+/–
>> ftrivial-auto-var-init=zero в некоторых ситуациях в работе с буферами может снизить производительность >> кода до 35%, скорость можно вернуть переписав код, но как пишут >> не всегда возможно да и не всегда получишь оригинальную производительность. > а разве mitigations, уже реализованные, не снижают производительность? > плюс к ним сет -fhardened. > вообщем жду не дождусь когда пайплайн в trixie зарелизит gcc-14 Нет. Это совсем другое. mitigations в разных случаях по разному влияют на работу CPU снижая эффективность спекулятивного выполнения кода. https://serge-sans-paille.github.io/pythran-stories/trivial-... Этот флаг же в свою очередь заставляет всегда инициировать память объектов стека нулями. Постоянное пересоздание буферов в циклах в таких случаях приведёт к неминуемой потери скорости из-за затирания блока памяти нулями. Да это спасает от проблем когда кто-то захочет сразу прочитать буфер без записи в него новых данных (получит нули), без флага же он получит рандомные мусорные данные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #202

204. Сообщение от awg (?), 12-Май-24, 20:24	+/–
>> 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
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #202

205. Сообщение от Аноним (205), 12-Май-24, 23:03	+/–
Кстати, не подскажете, куда Dшники с сайта https://lhs-blog.info/ перебрались? А то домен вообще перестал определяться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

206. Сообщение от Аноним (205), 12-Май-24, 23:05	+1 +/–
Ага, не путай тёплое с мокрым, компилятор с линкером.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148

207. Сообщение от User (??), 13-Май-24, 07:01	+/–
> А вообще с точки зрения компилятора везде разные требования к версии GCC. > Так что даже, если стандарт одинаков (C89), не факт, что какой-нибудь > GCC 4.4 сможет собрать обе ветки. Не, ну это прям отдельная печальная история - костыли, велосипеды, компиляторы C и linux kernel... Вот уже ажно "ANSI - стандарт" на язык есть - а собрать чем угодно всё одно, нельзя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200

208. Сообщение от User (??), 13-Май-24, 07:01	+/–
> И все же с 5.18 (или самая ранняя LTS - 6.1) используется > C11 :) В курсе - по этому и ограничился "каким-нибудь 5.15"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199

210. Сообщение от Аноним (210), 13-Май-24, 18:46	+/–
>Xeon Phi. Это не процессор в привычном понимании. А что же это за зверь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173

211. Сообщение от Вы забыли заполнить поле Иаше (?), 13-Май-24, 21:53	+/–
тут так смешно про модули в С++ рассуждают, а в фортране они есть уже 30 лет как... Причём на любой вкус: можно как в Си сигнатуры отдельно, реализации отдельно (субмодули), можно всё в один файл пихать. Ещё вот тут: https://fortran-lang.org/learn/rosetta_stone/ рядом код на Питоне и Фортране, делающий примерно одно и то же, выглядит не то чтобы сильно длиннее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156 Ответы: #212, #214

212. Сообщение от n00by (ok), 14-Май-24, 12:30	+/–
В Си (и плюсах) "модули" реализованы препроцессором и линкером, вот что самое смешное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #211

213. Сообщение от Аноним (213), 15-Май-24, 17:00	+/–
В случае с goto дело не в небезопасности, а лапшекодовости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168 Ответы: #215

214. Сообщение от Аноним (213), 15-Май-24, 18:00	+/–
>тут так смешно про модули в С++ рассуждают, а в фортране они есть уже 30 лет как... Ну так а шо вы хотели? Сишконаследие...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #211

215. Сообщение от n00by (ok), 15-Май-24, 19:32	+/–
В случае goto дело в том, что аббревиатура КА не гуглится в Википедии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213

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

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