http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938
--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Rafał Rawicki from comment #3)
> > This is a regression, because a more specific _GLIBCXX_ATOMIC_BUILTINS_4 was
> > defined (but is no longer available) and now there is defined
> > ATOMIC_INT_LOCK_FREE=1 (I think think the definition is correct, because
> > there were available _GLIBCXX_ATOMIC_BUILTINS_{1,2,4} and no
> > _GLIBCXX_ATOMIC_BUILTINS_8).
>
> But ATOMIC_INT_LOCK_FREE only refers to int, i.e. 4-byte integer, so if
> _GLIBCXX_ATOMIC_BUILTINS_4 was defined then I would expect atomic ops on int
> to always be lock-free, i.e. the macro should be defined to 2. It's
> independent of whether atomic ops for 8-byte types are supported.
yes. if an integer_type_node is 4 bytes, and the architecture has a 4 byte
compare and swap, it should be set to 2 regardless of the lack of an 8 byte
lock free operation.
this assert should never fail:
if (__atomic_always_lock_free(4, NULL) && (sizeof(int) == 4))
assert (ATOMIC_INT_LOCK_FREE == 2);
In theory _GLIBCXX_ATOMIC_BUILTINS_4 should have been the same as
ATOMIC_INT_LOCK_FREE as long as sizeof (int) == 4
>
> > The other thing is, std::exception_ptr availability should not depend on the
> > fact whether the platform has lock-free atomics or not.
>
> Without them you either need libatomic.so or you risk undefined behaviour
> such as leaking exception objects or worse, dangling references to
> destroyed exceptions.
