> Вообще-то, это не прикол, это он имеет полное право так делать (например,
> для инициализации начального значения большой локальной переменной).1) "большой" - аж 16 байтов :)
2) Если static const сказать, это и воркэраундит такую "оптимизацию" и делает код меньше.
3) Я по-моему очень доходчиво -ffreestanding сказал, и дополнительно подкрепил nostdlib, no-builtin, nostartfiles и проч, потому что совершенно не желаю чтобы мне в мою фирмвару пытались поумничать через мою голову на кривой козе.
4) В этом тулчейне ... нет либы с реализацией memcpy :). Не, ну я конечно накодил свой, для сравнения code size такого комбо, любопытно было, но я ж вроде сказал явно - это freestanding. С фуя ли вызовы memcpy?
Да еще в случае вот именно LTO gcc'у башню так круто сносит. Вот так он memcpy видит, а вот так видимо грохает как unused, а потом - бдыщ - undefined reference.
Сорь, но от компилера я в такой ситуации ожидаю все же не такое поведение. И более того - если баги gcc копнуть, ЭТО даже чинили. Однако тот свич который заимплементили таки походу другое комбо оптимизаций :D и на мой сценарий никакого эффекта не оказал. Видимо баг вкрался для еще одного комбо опций и это комбо vs freestanding таки не заметили. А с LTO это умеет коллапсировать в довольно глючную спираль.
> to supply the memcmp, memcpy, memmove, and memset functions,
...и в принципе это катит, но с LTO эта скотина умудряется дополнительно поумничать, а потом таки сказать undefined reference, даже если я его и заимплементил, блин :))). И да, нет там никакого libgcc в baremetal тулчейн. И вообще, последнее что я хочу видеть в микроконтроллере это какой-то левый код впертый мне без спросу на кривой козе.
>> All code compiled with GCC *must* be linked with libgcc.
Пожелаю этим умникам напрогать bare metal фирмрварь для микроконтроля а потом умничать.
> Так что тут сугубо документированное поведение.
Это не делает его менее кривым или сколь-нибудь желательным. Даже сами прогеры gcc таки подтвердили в багтрекере на подобный баг что freestanding - вполне явно декларит реквест об отказе от таких навязчивых услуг. Но вот видимо для одного комбо опций это таки пролезло в каком-то другом куске оптимизатора.
> Далее, от -O3 код конечно-же пухнет, это же оптимизация по скорости, а не по размеру,
Просто код пухнет чуть не в разы а прибавка в скорости буквально единицы процентов, очень неудачный tradeoff на МК. Я надеялся что с LTO будет соотношение поинтереснее. А вместо этого код еще распух. Ну и смысла в таком комбо?! :)
Еще там бывает очень странная реакция если компил и линк разнесены в разные фазы, а тулчейн был кросс. Он как-то лихо так "plugin needed to handle object" - и все, болт. Если одним чихом компилять, нормально срабатывает.
> Хуже того, -O2 тоже обычно жирнее -Os.
Да, конечно, жирнее. Но и заметно шустрее. Вот тут разница уже процентов 30 была (в интенсивном алгоритме).
