This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR libstdc++/67843 set shared_ptr lock policy at build-time


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 gcc@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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]