[PATCH] libstdc++: Allow using <future> without lock free atomic int

[Jonathan Wakely]

On 09/11/16 23:26 +0200, Pauli wrote:
>Compiling programs using std::future for old arm processors fails. The
>problem is caused by preprocessor check for atomic lock free int.
>
>Future can be changed to work correctly without lock free atomics with
>minor changes to exception_ptr implementation.
>
>Without lock free atomics there is question if deadlock can happen. But
>atomic operations can't call outside code preventing any ABBA or
>recursive mutex acquiring deadlocks.
>Deadlock could happen if throwing an exception or access
>is_lock_free() == false atomic from asynchronous signal handler.
>Throwing from signal handler is undefined behavior. I don't know about
>accessing atomics from asynchronous signal handler but that feels like
>undefined behavior if is_lock_free returns false.
>
>Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735
>
>differences to current if atomic builtins available:
>* Race detector annotations that are empty by default
>* Check for __gthread_active_p
>* Generate x86 code uses xadd instead of xsub
>This makes code a bit worse. But problem is duplicated to any other user
>of __exchange_and_add. The internal API implementation should be fixed
>to generate better code for all cases. But that is a follow up patch.

I'd prefer to do it so we don't change anything for the targets that
already work. Your follow-up patch missed the deadline for GCC 7 and
so will have to wait for GCC 8 now, and we don't want to pessimize
x86.

Also, I think your patch actually breaks some GNU/Linux targets,
because you removed the <atomic_lockfree_defines.h> header from
<exception>, which means that in libsupc++/guard.cc the macro
ATOMIC_INT_LOCK_FREE is no longer defined, and so _GLIBCXX_USE_FUTEX
doesn't get defined. Now arguably guard.cc should have been including
the header directly, but it still shows why such an invasive patch is
a bad idea at this stage of the GCC 7 process.

The attached patch attempts to make exception propagation work for all
targets, without changing anything if it already works.

Do you see any problems with this alternative approach?
Could you please test it for armv5te?

It passes all tests for x86_64-linux and ppc64le-linux.

For your follow-up patch, do you already have a copyright assignment
for contributions to GCC? We'll probably need that before it can be
accepted. We don't need one for this patch, because what remains of
your original patch is just the testsuite changes, which are
mechanical and not copyrightable.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 68760 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20161216/1636454c/attachment.bin>