On target mvebu, between r7474 - r7488, built with O3, using ssh or scp causes dropbear to peg (100%) a single core on either a rango and mamba, with no timeout of the ssh client. Looking at the commit log nothing really leaps out as a likely suspect, not sure why the LTO stuff would have an impact here, but nothing other than backing off to Os seems to resolve the issue.
Wondering if anyone else is seeing this issue, just trying to narrow down on the cause. Maybe I'll take a kick at ath79 on C7V2 to check for same behaviour.
Should have stated that I have been using O3 for a long time with no issues, on targets mvebu, ar71xx and recently on ath79 (but not since this reared its head). This is a recent occurrence, without an obvious case as to the regression, so looking to address what may have occurred.
There are some or probably many packages that strip of the -O options or does set it´s own (always the last one is used) optimization. For example openssl or openvpn...
For the kernel you could also not set -O3, you will have only the option for performance (-O2) or for size (-Os)...
Don´t think it´s worth the not very huge performance gain for some not heavily used user space packages.
Especially on a router device that should work without issues and does the most work in kernel space.
There are a few packages that greatly benefits using O3 such as zlib (option available), OpenSSL (option available), LAME (option available), ffmpeg (not available) to name a few.