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

[Jonathan Wakely]

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

Here's what I plan to commit to trunk tomorrow.


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