gcc-10.2.0-r5 has a regression which got triggered in the git version of s25rttr: [ 40%] Building CXX object libs/s25main/CMakeFiles/s25Main.dir/TerrainRenderer.cpp.o /tmp/s25client/libs/s25main/GamePlayer.cpp: In member function ‘void GamePlayer::Deserialize(SerializedGameData&)’: /tmp/s25client/libs/s25main/GamePlayer.cpp:328:22: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] 328 | toolsSetting = sgd.PopUnsignedChar(); | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~ /tmp/s25client/libs/s25main/GamePlayer.cpp:328:22: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] /tmp/s25client/libs/s25main/GamePlayer.cpp:328:22: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] /tmp/s25client/libs/s25main/GamePlayer.cpp:328:22: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] [ 40%] Building CXX object libs/s25main/CMakeFiles/s25Main.dir/Timer.cpp.o this was fixed in trunk https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=r11-1183 but was not backported yet. I'm filling this backport mostly to allow it blocking the gcc-10 stable tracker, but feel free to comment everyone.
Created attachment 681562 [details] minimal example written by Alexander Grund, member of the s25rttr team g++-10.2.0 -O3 -Werror -c minimal-example1.cpp
It's a large patch. If it gets backported to gcc-10 branch upstream we will pull it in. Feel free to prod or help at upstream bug report at https://gcc.gnu.org/PR95353. I would like to avoid gentoo-specific backporting of big nontrivial patches to avoid regressions and mmerge problems for future patches. It should be easy to workaround the failure by avoiding -Werror=stringop-overflow on gcc-10.
yeah I know that patch is really big, and please not that I never asked for someone to actually pick it up before the backport is merged into gcc-10 by upstream. It is only one of many problems with parts of -O3 optimization it seems, and I'm kind of worried that gcc-10.2.0 will go stable regardless.
I would say that bad diagnostic while tedious to deal with is not a stable blocker. I don't think this regression is tied to -O3. Upstream bug report specifically has -O2 example on binutils. Given that -O3 is less tested that default -O2 (for both goo upstream and users' upstreams) it is natural to have more bugs there. The only way to get -O3 better is to test, report and fix bugs in software. But I would also say that -O3-only bugs should not block gcc stabilization either.
A decent compromise would be pinging us when it's in.
