On 28/11/18 12:30 +0000, Jonathan Wakely wrote:
3) We could change libstdc++'s configure to automatically override --with-libstdcxx-lock-policy for arm-linux so it always uses "atomic" (because we know the kernel helpers are available). That causes an ABI change for a GCC built for --target=armv5t-*-linux* so I didn't do that by default. Packagers who want that can use the --with option explicitly to build a libstdc++ with atomic refcounting that can be used on any armv5t or later CPU, allowing users to choose a newer -march for their own code. (Until my patch that didn't work, because
[...]
Option 3) is not my call to make. If the ARM maintainers want to change the default older arm-linux targets I have no objections.
Another way to approach option 3) that we discussed at Cauldron, and which I want to start a separate discussion about on g...@gcc.gnu.org, is to change the value of __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 et al when we have kernel helpers to implement those operations. The shared_ptr code doesn't care if an atomic CAS comes from the CPU or a kernel helper in libgcc. If the atomic CAS is supported via kernel helpers, let's use it! But those predefined macros only tell you about native CPU support (for the current target selected by -march). It's worth noting that all this shared_ptr code predates libatomic, so we couldn't just say "always use atomics, and link to libatomic if needed". If __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 was not defined, we had to assume no CAS *at all*. Not native, not provided by libatomic, nothing. I'd love to simply rely on std::atomic in std::shared_ptr, but that would be an ABI break for targets currently using a mutex, and would add new dependencies on libatomic for some targets. (It might also pessimize some single-threaded programs on targets that do use atomic ref-counts, because currently some updates are non-atomic when __gthread_active_p() == false).
