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

[Jonathan Wakely]

On 16/12/16 17:52 +0000, Jonathan Wakely wrote:
>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.

We also need to adjust the linker script to avoid adding new exports
to old symbol versions, revised patch attached. I think it would be
better to make configure define a macro like
HAVE_EXCEPTION_PTR_SINCE_GCC6 and use that in the linker script
instead of testing __GCC_ATOMIC_INT_LOCK_FREE directly. I'll work on
that.




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