jstov

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

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

@hd44780

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

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

0

@OVY-srok

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

0

@div

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

0

@div

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

0

@hd44780

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

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

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

0

@dikor

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

0

@vt340

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

0

@hd44780

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

0

@vt340

Легко )gcc 5.3.1, всё нормально

0

@u37

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

0

@vt340

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

0

@u37

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

0

@dikor

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

0

@moksir

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

0

@Ymk

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

0

@OVY-srok

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

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

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

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

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

0

@Ymk

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

0

@hd44780

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

0

@vt340

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

0