[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support

["amacleod at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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.