http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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.
> 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.
