-
Palmer Dabbelt authored
The RISC-V port requires libatomic to be linked in order to resolve various atomic functions, which results in builds that have "--with-libstdcxx-lock-policy=auto" defaulting to mutex-based locks. Changing this to direct atomics breaks the ABI, this forces the auto detection mutex-based atomics on RISC-V in order to avoid a silent ABI break for users. See Bug 84568 for more discussion. In the long run there may be a way to get the higher-performance atomics without an ABI flag day, but that's going to be a much more complicated operation. We don't even have support for the inline atomics yet, but given that some folks have been discussing hacks to make these libatomic routines appear implicitly it seems prudent to just turn off the automatic detection for RISC-V. libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_ENABLE_LOCK_POLICY): Force auto to mutex for RISC-V. * configure: Regenerate.
Palmer Dabbelt authoredThe RISC-V port requires libatomic to be linked in order to resolve various atomic functions, which results in builds that have "--with-libstdcxx-lock-policy=auto" defaulting to mutex-based locks. Changing this to direct atomics breaks the ABI, this forces the auto detection mutex-based atomics on RISC-V in order to avoid a silent ABI break for users. See Bug 84568 for more discussion. In the long run there may be a way to get the higher-performance atomics without an ABI flag day, but that's going to be a much more complicated operation. We don't even have support for the inline atomics yet, but given that some folks have been discussing hacks to make these libatomic routines appear implicitly it seems prudent to just turn off the automatic detection for RISC-V. libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_ENABLE_LOCK_POLICY): Force auto to mutex for RISC-V. * configure: Regenerate.