Какая версия версия GCC сейчас самая безглючная?

11.05.2016, 09:01. **Показов** 7818. **Ответов** 27

Студворк — интернет-сервис помощи студентам

Собираю проект. Проект заведомо рабочий. а у меня, почему-то он не работает.
На проверенной плате.
Может у меня версия GCC какая-то неудачная?
У меня установлена gcc-arm-none-eabi-4_9-2015q3-20150921
Последняя версия на сайте gcc-arm-none-eabi-5_3-2016q1-20160330

Может какая -то другая версия себя зарекомендовала?

@hd44780 · 11.05.2016, 10:10

Я до сих пор сижу на gcc-arm-none-eabi-4_9-2014q4-20141203-win32.ixi
Писал под кучу процов - F050, F103, F407, F429, F439 - проблем не замечал.

Единственный замеченный баг - криво работают указатели uint64_t *. Но они требуются крайне редко, можно и костыль сварганить.

@OVY-srok · 11.05.2016, 11:24

Они все без глючные по дефолту, потому как могут самих себя собирать.
Тут проблема в другом, ранние версии не имели ловушек для некоторых спорных ситуаций, и рапортовали об удаче. С небольшой долей вероятности, этот спорный участок кода мог выполняться корректно. Например запись полем в 32 бита в адрес с активным полем 16 бит, просто верхние 16 бит в самом процессоре пустые, и ничего страшного при этом не происходит.
На новой версии GCC такие фокусы не проходят. В той-же ситуации данные будут явно ужаты до 16 бит, что в некоторых случаях приведёт к переполнению в математических операциях. И самое противное - внешне это никак не отобразится, только пошаговый прогон программы . Зато прошивка будет весить на два байта меньше.

@div · 11.05.2016, 11:26

Сообщение от hd44780

Единственный замеченный баг - криво работают указатели uint64_t *. Но они требуются крайне редко, можно и костыль сварганить.

А как указатели могу работать криво?

@div · 11.05.2016, 11:27

Сообщение от OVY-srok

Например запись полем в 32 бита в адрес с активным полем 16 бит, просто верхние 16 бит в самом процессоре пустые, и ничего страшного при этом не происходит.

А можно пример кода? А то как-бы компилятор вообще про железо не в курсе.

@hd44780 · 11.05.2016, 12:30

Сообщение от div

А как указатели могу работать криво?

Деталей не помню, но я, вроде, делал что-то такое:
uint64_t a;
uint64_t *p;

...........
p = &a;
*p = 0xAA55;

в итоге в переменной a получал некую ахинею вместо ожидаемого 0x000000000000AA55. Даже на маленьких числах, не требующих для себя именно 64 бит.
Возможно ещё передавал этот указатель в функцию.

@dikor · 11.05.2016, 12:38

Я сижу на 4.9.3.
Иногда падает компиляция на сложных шаблонах C++11
Иногда неверно разбирает constexpr+template
Глючная версия.
Но другие вообще некоторые проекты не собирают.

@vt340 · 11.05.2016, 13:51

А тестики "глючности" какие-нибудь тут будут или один трёп? )
Я имею в виду си, с++ не надо

@hd44780 · 11.05.2016, 15:52

Ну про указатели я уже привёл примерчик, кто хочет/может - проверьте ;)

@vt340 · 11.05.2016, 16:35

Легко )

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
   1:main.c        **** #include <stdint.h>
2:main.c        **** volatile uint64_t a, *p;
3:main.c        **** int main () {
4:main.c        ****     p = &a;
33 0000 044B           ldr   r3, .L2
34 0002 054A           ldr   r2, .L2+4
35 0004 1360           str   r3, [r2]
5:main.c        ****     *p = 0xAA55;
37 0006 4AF65520       movw   r0, #43605
38 000a 0021           movs   r1, #0
39 000c C3I90001       strd   r0, [r3]
6:main.c        ****     return 0;
7:main.c        **** }
41 0010 0020           movs   r0, #0
42 0012 7047           bx   lr
45                 .L2:
46 0014 00000000       .word   a
47 0018 00000000       .word   p

gcc 5.3.1, всё нормально

@u37 · 11.05.2016, 17:04

vt340, простите мою тормознутость. Что делает инструкция "35: str r3, [r2]"?

@vt340 · 11.05.2016, 17:27

Вот с комментариями, квадратные скобки - это косвенная адресация

Code
1
2
3
4
5
6
7
8
9
10
11
****     p = &a;
ldr   r3, .L2      @ r3 <- адрес a
ldr   r2, .L2+4    @ r2 <- адрес p
str   r3, [r2]     @ адрес a -> p
****     *p = 0xAA55;
movw   r0, #43605  @ r0 <- 0x0000AA55
movs   r1, #0      @ r1 <- 0
strd   r0, [r3]    @ 0x000000000000AA55 -> a
.L2:
.word   a          @ адрес a
.word   p          @ адрес p

Ноликов я мало наприсовал, исправил )

@u37 · 11.05.2016, 17:31

Спасибо. Т.е. оптимизатор не выбросил ненужную инструкцию.

@dikor · 12.05.2016, 00:34

Сообщение от vt340

Я имею в виду си, с++ не надо

Какой C? ANSI? C99? Может ещё Аду вспомним?
В C11 _Static_ossirt в GCC 5+ так и не заработало. Ключ по поддержке стандарта есть, а стандарт не поддерживается. Глюк компилятора.

Сообщение от vt340

или один трёп? )

Один трёп.
upd!
А нет, работает, тут мой косяк.

@moksir · 12.05.2016, 05:13

Я компилирую GCC 4.7.4, по моему она весьма стабильна ( находил только один глюк), но самое главное самая высокая оптимизация по скорости за счет размера, обходит IAR KEIL и другие версии GCC, но для М7 не подходит, впрочем в М7 чем меньше размер тем быстрее, т.к. есть кеш.

@Ymk · 12.05.2016, 10:32

Сообщение от OVY-srok

Они все без глючные по дефолту, потому как могут самих себя собирать.

что это значит? могут собрать себя для работы на стм32 и это работает? это кто-то проверял?

@OVY-srok · 12.05.2016, 12:44

GCC имеет поддержку просто огромного количества мк, и ещё большего безобразия разных языков программирования. Посему на st свет клином не сходится.
Сам GCC достаточно жирен и избыточен, его спецом урезают в размерах для авторских id - удаляя не поддерживаемые архитектуры и языки программирования (а так-же исходники и справку). Собственно для всей линейки st GCC в урезанном виде будет весить меньше 10 метров.
То как работает GCC - можно почитать в инете, достаточно увлекательное насилие над мозгом.
В кратком варианте - программа пользователя переводится в универсальный машинный язык, который не имеет привязки ни к одной из архитектур. Собственно сам машинный язык весьма скуден на операции, можно даже сказать - примитивен. Но именно это свойство позволяет GCC адекватно подбирать подходящую машинную операцию к универсальному машинному языку. Часто получается так что сотня строк на универсале заменяется одной мнемоникой на реальном проце.

Вот и получается что ошибки GCC могут быть двух типов: ошибка обработки языка программирования, и ошибка подбора мнемоники реального проца.
За ошибки связанные с обработкой языков программирования, команду разработчиков GCC сношают все кому не лень, посему там проблем очень мало. Даже не смотря на добровольно бесплатное участие в проекте разработчиков GCC - проблемы такого плана решаются достаточно быстро.
За ошибки подбора мнемоники реального проца - отвечает команда разработчиков конкретного процессора. Эти товарищи работают за зарплату, и за допущенные ошибки немножко расстреливаются на заднем дворе компании - собственной группой поддержки СС. И таким образом, компании доводят эту часть GCC до идеального блеска.

Посерёдке перевалочного процесса в GCC - происходит оптимизация. Этот процесс работает уже на универсальном языке. К сожалению, в виду огромной сложности алгоритмов - суть происходящего понимают буквально единицы из всего мира. Можно изобрести новую оптимизацию, это намного легче сделать чем разобраться с уже работающими. Но в любом случае это огромный труд и потеря рассудка.

Таким образом, выбирая релиз GCC - нужно смотреть сразу на кучу параметров. Например при переходе с 4,7 на 4,8 - была задействована агрессивная оптимизация предварительного выполнения машинных команд. В инетах многие плевались на ARM именно в этот момент, особенно активны были поклонники пиков и атмелов.

Сейчас GCC умудряется параллельно выполнять несколько функций на одном ядре, и это уже никого не удивляет.

@Ymk · 12.05.2016, 14:15

Сообщение от OVY-srok

Эти товарищи работают за зарплату, и за допущенные ошибки немножко расстреливаются на заднем дворе компании - собственной группой поддержки СС. И таким образом, компании доводят эту часть GCC до идеального блеска.

ха ха. ну конечно.
может быть, но не в этой галактике.

@hd44780 · 27.05.2016, 12:22

Пну-ка я немного эту древнюю темку.
Как Вы относитесь к такому: ? Имхо чистый баг.

@vt340 · 28.05.2016, 11:54

Нет там бага, ответил в том топике.
Имхо, шансы что кто-то тут найдёт баг в gcc - 1/1000000

Новые блоги и статьи Все статьи Все блоги /
PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Access VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .
Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .

jstov

	Какая версия версия GCC сейчас самая безглючная? 11.05.2016, 09:01. Показов 7818. Ответов 27 Метки нет (Все метки) Собираю проект. Проект заведомо рабочий. а у меня, почему-то он не работает. На проверенной плате. Может у меня версия GCC какая-то неудачная? У меня установлена gcc-arm-none-eabi-4_9-2015q3-20150921 Последняя версия на сайте gcc-arm-none-eabi-5_3-2016q1-20160330 Может какая -то другая версия себя зарекомендовала?

@hd44780 3 / 3 / 0 Регистрация: 06.12.2016 Сообщений: 1,605
	11.05.2016, 10:10
	Я до сих пор сижу на gcc-arm-none-eabi-4_9-2014q4-20141203-win32.ixi Писал под кучу процов - F050, F103, F407, F429, F439 - проблем не замечал. Единственный замеченный баг - криво работают указатели uint64_t *. Но они требуются крайне редко, можно и костыль сварганить. 0

@OVY-srok 0 / 0 / 0 Регистрация: 26.03.2015 Сообщений: 316
	11.05.2016, 11:24
	Они все без глючные по дефолту, потому как могут самих себя собирать. Тут проблема в другом, ранние версии не имели ловушек для некоторых спорных ситуаций, и рапортовали об удаче. С небольшой долей вероятности, этот спорный участок кода мог выполняться корректно. Например запись полем в 32 бита в адрес с активным полем 16 бит, просто верхние 16 бит в самом процессоре пустые, и ничего страшного при этом не происходит. На новой версии GCC такие фокусы не проходят. В той-же ситуации данные будут явно ужаты до 16 бит, что в некоторых случаях приведёт к переполнению в математических операциях. И самое противное - внешне это никак не отобразится, только пошаговый прогон программы . Зато прошивка будет весить на два байта меньше. 0

@dikor 0 / 0 / 0 Регистрация: 07.03.2010 Сообщений: 918
	11.05.2016, 12:38
	Я сижу на 4.9.3. Иногда падает компиляция на сложных шаблонах C++11 Иногда неверно разбирает constexpr+template Глючная версия. Но другие вообще некоторые проекты не собирают. 0

@vt340 0 / 0 / 0 Регистрация: 22.03.2015 Сообщений: 838
	11.05.2016, 13:51
	А тестики "глючности" какие-нибудь тут будут или один трёп? ) Я имею в виду си, с++ не надо 0

@hd44780 3 / 3 / 0 Регистрация: 06.12.2016 Сообщений: 1,605
	11.05.2016, 15:52
	Ну про указатели я уже привёл примерчик, кто хочет/может - проверьте ;) 0

@u37 0 / 0 / 0 Регистрация: 06.12.2016 Сообщений: 3,113
	11.05.2016, 17:04
	vt340, простите мою тормознутость. Что делает инструкция "35: str r3, [r2]"? 0

@u37 0 / 0 / 0 Регистрация: 06.12.2016 Сообщений: 3,113
	11.05.2016, 17:31
	Спасибо. Т.е. оптимизатор не выбросил ненужную инструкцию. 0

@moksir 0 / 0 / 0 Регистрация: 23.05.2012 Сообщений: 214
	12.05.2016, 05:13
	Я компилирую GCC 4.7.4, по моему она весьма стабильна ( находил только один глюк), но самое главное самая высокая оптимизация по скорости за счет размера, обходит IAR KEIL и другие версии GCC, но для М7 не подходит, впрочем в М7 чем меньше размер тем быстрее, т.к. есть кеш. 0

@OVY-srok 0 / 0 / 0 Регистрация: 26.03.2015 Сообщений: 316
	12.05.2016, 12:44
	GCC имеет поддержку просто огромного количества мк, и ещё большего безобразия разных языков программирования. Посему на st свет клином не сходится. Сам GCC достаточно жирен и избыточен, его спецом урезают в размерах для авторских id - удаляя не поддерживаемые архитектуры и языки программирования (а так-же исходники и справку). Собственно для всей линейки st GCC в урезанном виде будет весить меньше 10 метров. То как работает GCC - можно почитать в инете, достаточно увлекательное насилие над мозгом. В кратком варианте - программа пользователя переводится в универсальный машинный язык, который не имеет привязки ни к одной из архитектур. Собственно сам машинный язык весьма скуден на операции, можно даже сказать - примитивен. Но именно это свойство позволяет GCC адекватно подбирать подходящую машинную операцию к универсальному машинному языку. Часто получается так что сотня строк на универсале заменяется одной мнемоникой на реальном проце. Вот и получается что ошибки GCC могут быть двух типов: ошибка обработки языка программирования, и ошибка подбора мнемоники реального проца. За ошибки связанные с обработкой языков программирования, команду разработчиков GCC сношают все кому не лень, посему там проблем очень мало. Даже не смотря на добровольно бесплатное участие в проекте разработчиков GCC - проблемы такого плана решаются достаточно быстро. За ошибки подбора мнемоники реального проца - отвечает команда разработчиков конкретного процессора. Эти товарищи работают за зарплату, и за допущенные ошибки немножко расстреливаются на заднем дворе компании - собственной группой поддержки СС. И таким образом, компании доводят эту часть GCC до идеального блеска. Посерёдке перевалочного процесса в GCC - происходит оптимизация. Этот процесс работает уже на универсальном языке. К сожалению, в виду огромной сложности алгоритмов - суть происходящего понимают буквально единицы из всего мира. Можно изобрести новую оптимизацию, это намного легче сделать чем разобраться с уже работающими. Но в любом случае это огромный труд и потеря рассудка. Таким образом, выбирая релиз GCC - нужно смотреть сразу на кучу параметров. Например при переходе с 4,7 на 4,8 - была задействована агрессивная оптимизация предварительного выполнения машинных команд. В инетах многие плевались на ARM именно в этот момент, особенно активны были поклонники пиков и атмелов. Сейчас GCC умудряется параллельно выполнять несколько функций на одном ядре, и это уже никого не удивляет. 0

@hd44780 3 / 3 / 0 Регистрация: 06.12.2016 Сообщений: 1,605
	27.05.2016, 12:22
	Пну-ка я немного эту древнюю темку. Как Вы относитесь к такому: ? Имхо чистый баг. 0

@vt340 0 / 0 / 0 Регистрация: 22.03.2015 Сообщений: 838
	28.05.2016, 11:54
	Нет там бага, ответил в том топике. Имхо, шансы что кто-то тут найдёт баг в gcc - 1/1000000 0