https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125197
--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Jonathan Wakely from comment #13) > It's been reported now because the implicit linking to libatomic made people > notice it recently. And the issue is that the -m32 multilib of libstdc++.so has undefined references to symbols like __atomic_sub_fetch_4, which means it depends on libatomic.so, but the 32-bit libatomic.so assumes it's built for sparcv9. So libstdc++.so is built to work on older hardware by using libatomic.so instead of native v9 instructions, but libatomic.so doesn't actually work on older hardware. So something is wrong and makes no sense here. Either libatomic.so should work on pre-sparcv9 h/w or the 32-bit libstdc++ should default to sparcv9 (and if somebody explicitly wants to support older h/w by using -m32 they can build GCC with --with-cpu-32=cypress or similar).
