Лучшее - враг хорошего?, Глюки при оптимизации компилятора KEIL Опции

[KnightIgor]

Привет, коллеги.

Следующая предыстория. Есть работающая, но и далее развиваемая программа на STM32F103RC на собственном железе. В ней много всего: поддержка FlashFS на microSD через SPI и на EEPROM через I2C, комбинированное USB устройство (HID/CDC/MassStorage), два радиомодуля на CC1101, и т.п. В какой-то момент код созрел до такой степени, что устаканившуюся часть его я решил "слить" в библиотеку, чтобы исключить длительные перекомпиляции исходников. Для этого создал новый проект, который собирает библиотеку, а основной проект её включает.

Все пошло. И тут начались неуловимые глюки и странности. Вроде все работает, но иногда файловая система сбоит - например, вдруг носитель якобы не содержит файлов. В некоторых условиях при интенсивном обмене по радиоканалам устройство может сброситься, и т.п. Начинаю скрупулезно сравнивать проекты и вдруг натыкаюсь на факт, что мой "библиотечный" проект имеет в опциях уровень оптимизации "по умолчанию". Так как основной проект собирается с -O0 (пока отлаживаюсь, оптимизация выключена, да и память не вышла вся еще), я включил -O0 и для библиотеки и... всё заработало без проблем.

Возникают вопросы:
1. Какой уровень оптимизации у KEIL по-умолчанию?
2. Глюки программы связаны с ошибками компилятора на высоких уровнях оптимизации?
3. Мой код имеет синтаксические недостатки, которые проявляются лишь при сильной оптимизации (например, нужно ли писать для переменных static volatile или достаточно static)?
4. Можно ли "смешивать" в результирующем коде различные уровни оптимизации?
5. Как откомпилированы в смысле оптимизации библиотеки RL от KEIL?

Каков ваш опыт, коллеги?

Сообщение отредактировал KnightIgor - May 30 2012, 08:32

[vlad_new]

Но что там оптимизатор может натворить?

А Вы его и спросите. К примеру sprintf(mas,"бла...бла", tmp); при объявленном локальном массиве char mas[10] и включенном оптимизаторе O1 просто не заработал. И передача адреса массива в другую функцию send(char *mas) то же не работало. Помог static.

Сообщение отредактировал vlad_new - May 31 2012, 13:49

[zuy]

А Вы его и спросите. К примеру sprintf(mas,"бла...бла", tmp); при объявленном локальном массиве char mas[10] и включенном оптимизаторе O1 просто не заработал. И передача адреса массива в другую функцию send(char *mas) то же не работало. Помог static.

Уверен, что косяк у вас в коде. Довольно часто использовал подобные конструкции на разных уровнях оптимизации, никогда проблем не было.
Думаю, что обьяснение данное выше KnightIgor довольно точно описывает причину происходящего.

[Lotor]

Уверен, что косяк у вас в коде.

С Кейлом знаком еще по 51 семейству, еще тогда были проблемы с локальными переменными, если их передавать в функции (при чем в свои, а не в sprintf) и не обозвать static. Для arm аналогично, будет время покопаю этот момент.

[aaarrr]

С Кейлом знаком еще по 51 семейству...

А ничего так, что это два совершенно разных компилятора от разных производителей?

99.9% "ошибок компилятора" и "багов оптимизатора" - это косяки в коде. Обратному можно верить только при наличии примера в виде код + дизассемблер.

[Lotor]

А ничего так, что это два совершенно разных компилятора от разных производителей?

Я это к тому, что еще с тех пор взял за правило ставить static у локальных переменных в функциях, если они идут дальше.

99.9% "ошибок компилятора" и "багов оптимизатора" - это косяки в коде. Обратному можно верить только при наличии примера в виде код + дизассемблер.

Я к этому мнению пришел недавно, намного позже, чем стал ставить static у локальных переменных. =) Поэтому и хочу при наличии времени поиграться именно с дизассемблером.

[_Артём_]

ставить static у локальных переменных в функциях

Очень странная идея.
Зачем оно надо?

P.S. volatile не пробовали для локальных? Это хоть не так нелогично.

[Lotor]

Очень странная идея.
Зачем оно надо?

P.S. volatile не пробовали для локальных? Это хоть не так нелогично.

Вы заблуждаетесь, логика присутствует.
При static локальная переменная будет жить в глобальной области памяти, а не на стеке. И именно поэтому проблемы исчезали.

PS: На работе попробовал по памяти набросать код, который вызывал когда-то проблемы (чтобы осмысленно глянуть в дизассемблер) - в функции локальный массив или указатель передается дальше. Но увы, всё работает, как надо при любой оптимизации. =) Помню, когда в последний раз такое случалось, я перенес аналогичный код в iar'овский компилятор - там без static работало. И т.к. это был не первый случай, то старался больше не рисковать и ставил static у локальных указателей и массивов, если они идут дальше (реентерабельность не требовалась). Прочитав эту тему по диагонали и заметив знакомую проблему, удивился что уважаемый aaarrr очень уверенно говорит, что дело не в компиляторе. Может оно и так, но помимо меня как минимум еще двое испытывают похожие проблемы.

[_Артём_]

Вы заблуждаетесь, логика присутствует.

Ну какая-то логика конечно присутствует, если программа всё-таки работает.

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

Зачем переменной "жить в глобальной области памяти"? Локальная переменная должна жить в стеке (за исключением особых случаев).
Вопрос в том, почему такие проблемы вообще возникают. Что-то делаете не так.
Согласен с мнением scifi

Это танцы с бубном. Так не интересно. Лучше докопаться до сути проблемы.

Каким-то образом вам удалось заткнуть проблему (с помощью static), но не факт что не вылезет где-нибудь в другом месте.

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

Если реентерабельность не требуется, то как бы и ладно, если по другому никак.
А как потребуется?
Или как такое будет работать в программе с ОС? Понятно что никак не будет.

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

aaarrr видимо прав на 100 %. Если у него таких проблем не возникает, то что-то эти "ещё двое" делают не правильно и дело не в компиляторе. Вообще за последние несколько лет не встречал чтобы дело было в компиляторе (правда я с iar работаю), 99% что виноват программист, ну и может доли процента можно оставить на глюки компилятора.