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

[Jonathan Wakely]

On 04/01/17 16:00 +0100, Christophe Lyon wrote:
>Hi Jonathan,
>
>On 4 January 2017 at 12:02, Jonathan Wakely <jwakely@redhat.com> wrote:
>> On 03/01/17 15:32 +0000, Jonathan Wakely wrote:
>>>
>>> Here's what I plan to commit to trunk tomorrow.
>>
>>
>> Committed to trunk.
>>
>>
>After this commit (r244051), I do see improvements, but also a few new failures.
>The big picture is at
>http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/244051/report-build-info.html
>
>Where the expected improvements for arm-none-eabi, with default cpu&fpu are:
>http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/244051/arm-none-eabi/diff-libstdc++-rh60-arm-none-eabi-default-default-default.txt
>
>New failures appear when forcing -march=armv5t in runtestflags (the 3
>red items in the 1st report):
>
>  - FAIL appears              [     => FAIL]:
>
>  18_support/exception_ptr/60612-terminate.cc execution test
>  18_support/exception_ptr/60612-unexpected.cc execution test
>  30_threads/packaged_task/members/at_thread_exit.cc execution test
>  30_threads/promise/members/at_thread_exit.cc execution test
>
>Note that in these cases we are compiling the test cases with
>-march=armv5t, but link
>with libraries built --with-cpu=cortex-a9, so there might be a mismatch?

Yes, this is probably the same issue as PR63829

Richard's comment on the bug report says that arm should always use
atomics, via kernel helpers if necessary, so that there is no ABI
change when using -march for older CPUs.

I don't know how to do that, but I hope we can make some progress on
it for gcc 8.