Не всегда! восьмиричные и шестнадцетиричные могут быть и unsigned, например если целое 16 бит то 0x7ffff - int, a 0x8000 уже unsigned, 0x7fffffff - long int, а 0x80000000 - unsigned long int и т.д. Для 32 битного int аналогично.

Да, действительно. Правильнее было наприсать "минимум int".

Вы намикаете, что надо писать 0x0000ffff или 0xffffUL вместо 0xffff?

Именно, немного ошибся в количестве f, но сути дела это не меняет. По крайней мере 0xffffUL переносимо.

Да это баг для Cortex-M3, на других ядрах работает нормально.

Ну да! Так под кортекс оптимизировать намного сложнее! Система комнад более гибкая, надо выбирать опрадвана ли будет 32 битная команда, еще IT блоки есть...

Тема про компилятор 5.40 или 5.41?
Я было плевался от 5.30 версии с ее оптимизцией (под ARM), думал тему создавать... А в 5.40 все поправили!

Я тестировал в 5.40 думаю в 5.41 тоже самое


Поточнее что вам не нравилось в 5.30 ?


На Cortex-M0 работает правильно
ю
Так маляву накатали в IAR? по гуглил инет нигде больше этот баг не обсуждается.

Письмо послано. Только не думаю, что быстро ответят.
Признавать ошибки - дело не легкое, да и неприятное.

Это точно, на мой баг репорт четыре года отвечали.

Да тоже самое! Я и 5.40 и последним 5.41 (январским)

Переключение THUMB/ARM.

Ну что, IAR ответил .

Следует отметить, что достаточно быстро.
Правда пришлось два письма посылать.
В первом, или я плохо объяснил, или он не напрягся, что бы понять.
Но на второе, более подробное, ответ пришел через час и представлен Вашему вниманию.



Итак, кому дороги время и репутация, 5.4 в топку.
Если пришлют патчи, то выложу.
А пока ждем 5.5.

Что то я не понял, как это относится к обсуждаемому здесь коду.

Я так понимаю, он не анализировал код,
а просто присваивал какие-то значения и,
в лучшем случае, в симуляторе смотрел результат.