Re: [PATCH] libstdc++: Allow using without lock free atomic int
On 4 January 2017 at 16:10, Jonathan Wakely wrote: > On 04/01/17 16:00 +0100, Christophe Lyon wrote: >> >> Hi Jonathan, >> >> On 4 January 2017 at 12:02, Jonathan Wakely wrote: >>> >>> On 03/01/17 15:32 +, 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 Indeed. > > 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. > That would be good, maybe Richard can post an example in bugzilla? Thanks, Christophe
Re: [PATCH] libstdc++: Allow using without lock free atomic int
On 04/01/17 16:00 +0100, Christophe Lyon wrote: Hi Jonathan, On 4 January 2017 at 12:02, Jonathan Wakely wrote: On 03/01/17 15:32 +, 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.
Re: [PATCH] libstdc++: Allow using without lock free atomic int
Hi Jonathan, On 4 January 2017 at 12:02, Jonathan Wakely wrote: > On 03/01/17 15:32 +, 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? Christophe
Re: [PATCH] libstdc++: Allow using without lock free atomic int
On 03/01/17 15:32 +, Jonathan Wakely wrote: Here's what I plan to commit to trunk tomorrow. Committed to trunk.
Re: [PATCH] libstdc++: Allow using without lock free atomic int
On 19/12/16 17:52 +, Jonathan Wakely wrote: On 16/12/16 17:52 +, 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 header from , 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. commit fa070e976709218d9927e2ed880bd29f7f98106f Author: Jonathan Wakely Date: Fri Dec 16 15:22:21 2016 + Support exception propagation without lock-free atomic int 2017-01-03 Pauli Nieminen Jonathan Wakely PR libstdc++/64735 * acinclude.m4 (GLIBCXX_CHECK_EXCEPTION_PTR_SYMVER): Define. * config.h.in: Regenerate. * config/abi/pre/gnu.ver [HAVE_EXCEPTION_PTR_SINCE_GCC46] (GLIBCXX_3.4.15, GLIBCXX_3.4.21, CXXABI_1.3.3, CXXABI_1.3.5): Make exports for exception_ptr, nested_exception, and future conditional. [HAVE_EXCEPTION_PTR_SINCE_GCC46] (GLIBCXX_3.4.23, CXXABI_1.3.11): Add exports for exception_ptr, nested_exception, and future conditional. * configure: Regenerate. * configure.ac: Use GLIBCXX_CHECK_EXCEPTION_PTR_SYMVER. * include/std/future: Remove check for ATOMIC_INT_LOCK_FREE * libsupc++/eh_atomics.h: New file for internal use only. (__eh_atomic_inc, __eh_atomic_dec): New. * libsupc++/eh_ptr.cc (exception_ptr::_M_addref) (exception_ptr::_M_release) (__gxx_dependent_exception_cleanup) (rethrow_exception): Use eh_atomics.h reference counting helpers. * libsupc++/eh_throw.cc (__gxx_exception_cleanup): Likewise. * libsupc++/eh_tm.cc (free_any_cxa_exception): Likewise. * libsupc++/exception: Remove check for ATOMIC_INT_LOCK_FREE. * libsupc++/exception_ptr.h: Likewise. * libsupc++/guard.cc: Include header for ATOMIC_INT_LOCK_FREE macro. * libsupc++/nested_exception.cc: Remove check for ATOMIC_INT_LOCK_FREE. * libsupc++/nested_exception.h: Likewise. * src/c++11/future.cc: Likewise. * testsuite/18_support/exception_ptr/*: Remove atomic builtins checks. * testsuite/18_support/nested_exception/*: Likewise. * testsuite/30_threads/async/*: Likewise. * testsuite/30_threads/future/*: Likewise. * testsuite/30_threads/headers/future/types_std_c++0x.cc: Likewise. * testsuite/30_threads/packaged_task/*: Likewise. * testsuite/30_threads/promise/*: Likewise. * test
Re: [PATCH] libstdc++: Allow using without lock free atomic int
On 16/12/16 17:52 +, 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 header from
, 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.
commit a19855aecf301a30bb1d6f6c39fe2a458baddd48
Author: Jonathan Wakely
Date: Fri Dec 16 15:22:21 2016 +
PR64735 support exception propagation without atomics
2016-12-19 Pauli Nieminen
Jonathan Wakely
PR libstdc++/64735
* config/abi/pre/gnu.ver [__GCC_ATOMIC_INT_LOCK_FREE > 1]
(GLIBCXX_3.4.15, GLIBCXX_3.4.21, CXXABI_1.3.3, CXXABI_1.3.5): Make
exports for exception_ptr, nested_exception, and future conditional.
[__GCC_ATOMIC_INT_LOCK_FREE <= 1] (GLIBCXX_3.4.23, CXXABI_1.3.11): Add
exports for exception_ptr, nested_exception, and future conditional.
* include/std/future: Remove check for ATOMIC_INT_LOCK_FREE
* libsupc++/eh_atomics.h: New file for internal use only.
(__eh_atomic_inc, __eh_atomic_dec): New.
* libsupc++/eh_ptr.cc (exception_ptr::_M_addref)
(exception_ptr::_M_release) (__gxx_dependent_exception_cleanup)
(rethrow_exception): Use eh_atomics.h reference counting helpers.
* libsupc++/eh_throw.cc (__gxx_exception_cleanup): Likewise.
* libsupc++/eh_tm.cc (free_any_cxa_exception): Likewise.
* libsupc++/exception: Remove check for ATOMIC_INT_LOCK_FREE.
* libsupc++/exception_ptr.h: Likewise.
* libsupc++/guard.cc: Include header for ATOMIC_INT_LOCK_FREE macro.
* libsupc++/nested_exception.cc: Remove check for
ATOMIC_INT_LOCK_FREE.
* libsupc++/nested_exception.h: Likewise.
* src/c++11/future.cc: Likewise.
* testsuite/18_support/exception_ptr/*: Remove atomic builtins checks.
* testsuite/18_support/nested_exception/*: Likewise.
* testsuite/30_threads/async/*: Likewise.
* testsuite/30_threads/future/*: Likewise.
* testsuite/30_threads/headers/future/types_std_c++0x.cc: Likewise.
* testsuite/30_threads/packaged_task/*: Likewise.
* testsuite/30_threads/promise/*: Likewise.
* testsuite/30_threads/shared_future/*: Likewise.
diff --git a/libstdc++-v3/config/abi/pre/gnu.ver b/libstdc++-v3/config/abi/pre/gnu.ver
index 8b0f67b..5da698e 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -1503,6 +1503,9 @@ GLIBCXX_3.4.15 {
Re: [PATCH] libstdc++: Allow using without lock free atomic int
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 header from , 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. commit e81e908deb699886e65cb4d614f6a0a1cf54662f Author: Jonathan Wakely Date: Fri Dec 16 15:22:21 2016 + PR64735 support exception propagation without atomics 2016-11-09 Pauli Nieminen Jonathan Wakely PR libstdc++/64735 * include/std/future: Remove check for ATOMIC_INT_LOCK_FREE * libsupc++/eh_atomics.h: New file for internal use only. (__eh_atomic_inc, __eh_atomic_dec): New. * libsupc++/eh_ptr.cc (exception_ptr::_M_addref) (exception_ptr::_M_release) (__gxx_dependent_exception_cleanup) (rethrow_exception): Use eh_atomics.h reference counting helpers. * libsupc++/eh_throw.cc (__gxx_exception_cleanup): Likewise. * libsupc++/eh_tm.cc (free_any_cxa_exception): Likewise. * libsupc++/exception: Remove check for ATOMIC_INT_LOCK_FREE. * libsupc++/exception_ptr.h: Likewise. * libsupc++/guard.cc: Include header for ATOMIC_INT_LOCK_FREE macro. * libsupc++/nested_exception.cc: Remove check for ATOMIC_INT_LOCK_FREE. * libsupc++/nested_exception.h: Likewise. * src/c++11/future.cc: Likewise. * testsuite/18_support/exception_ptr/*: Remove atomic builtins checks. * testsuite/18_support/nested_exception/*: Likewise. * testsuite/30_threads/async/*: Likewise. * testsuite/30_threads/future/*: Likewise. * testsuite/30_threads/headers/future/types_std_c++0x.cc: Likewise. * testsuite/30_threads/packaged_task/*: Likewise. * testsuite/30_threads/promise/*: Likewise. * testsuite/30_threads/shared_future/*: Likewise. diff --git a/libstdc++-v3/include/std/future b/libstdc++-v3/include/std/future index 8ba1306..b83d74b 100644 --- a/libstdc++-v3/include/std/future +++ b/libstdc++-v3/include/std/future @@ -192,8 +192,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION future<__async_result_of<_Fn, _Args...>> async(_Fn&& __fn, _Args&&... __args); -#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1) \ - && (ATOMIC_INT_LOCK_FREE > 1) +#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1) /// Base class and enclosing scope. struct __future_base @@ -1751,7 +1750,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION #endif // _GLIBCXX_ASYNC_ABI_COMPAT #endif // _GLIBCXX_HAS_GTHREADS && _GLIBCXX_USE_C99_STDINT_TR1 - // && ATOMIC_INT_LOCK_FREE // @} group futures _GLIBCXX_END_NAMESPACE_VERSION diff --git a/libstdc++-v3/libsupc++/eh_atomics.h b/libstdc++-v3/libsupc++/eh_atomics.h new file mode 100644 index 000..71b42a4 --- /dev/null +++
[PATCH] libstdc++: Allow using without lock free atomic int
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. ** libstdc++ test results x86_64 build from trunk@241870 resulted to exactly same results with and without patch. That is two localetest cases failing: FAIL: 22_locale/numpunct/members/char/3.cc execution test FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test of expected passes11941 of unexpected failures2 of expected failures 65 of unsupported tests 244 armv5tel from gcc-6-branch@241866 in qemu-arm-static -cpu arm926 resulted to following differences. Before patch: WARNING: program timed out. FAIL: 22_locale/locale/cons/12658_thread-2.cc execution test FAIL: 22_locale/numpunct/members/char/3.cc execution test FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test FAIL: 27_io/fpos/14775.cc execution test of expected passes10628 of unexpected failures4 of expected failures 66 of unsupported tests 390 After patch: WARNING: program timed out. FAIL: 22_locale/locale/cons/12658_thread-1.cc execution test WARNING: program timed out. FAIL: 22_locale/locale/cons/12658_thread-2.cc execution test FAIL: 22_locale/numpunct/members/char/3.cc execution test FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test FAIL: 27_io/fpos/14775.cc execution test of expected passes10831 of unexpected failures5 of expected failures 66 of unsupported tests 281 My cpu isn't fast enough to run 12658 thread tests in qemu. --- 2016-11-09 Pauli Nieminen * include/std/future: Remove check for ATOMIC_INT_LOCK_FREE * libsupc++/eh_ptr.cc (exception_ptr::_M_addref) (exception_ptr::_M_release) (__gxx_dependent_exception_cleanup) (rethrow_exception): Use atomicity.h reference counting helpers. * libsupc++/eh_throw.cc (__gxx_exception_cleanup): Likewise. * libsupc++/eh_tm.cc (free_any_cxa_exception): Likewise. * libsupc++/exception: Remove check for ATOMIC_INT_LOCK_FREE * libsupc++/exception_ptr.h: Likewise * libsupc++/nested_exception.cc: Likewise * libsupc++/nested_exception.h: Likewise * src/c++11/future.cc: Likewise * testsuite: Remove atomic builtins check from exception_ptr, nested_exception, future, promise, packaged_task, async and shared_future. --- libstdc++-v3/include/std/future| 4 +--- libstdc++-v3/libsupc++/eh_ptr.cc | 26 +- libstdc++-v3/libsupc++/eh_throw.cc | 9 libstdc++-v3/libsupc++/eh_tm.cc| 11 + libstdc++-v3/libsupc++/exception | 3 +-- libstdc++-v3/libsupc++/exception_ptr.h | 4 libstdc++-v3/libsupc++/nested_exception.cc | 2 -- libstdc++-v3/libsupc++/nested_exception.h | 4 libstdc++-v3/src/c++11/future.cc | 4 ++-- .../testsuite/18_support/exception_ptr/40296.cc| 1 - .../18_support/exception_ptr/60612-terminate.cc| 1 - .../18_support/exception_ptr/60612-unexpected.cc | 1 - .../testsuite/18_support/exception_ptr/62258.cc| 1 - .../testsuite/18_support/exception_ptr/64241.cc| 1 - .../18_support/exception_ptr/current_exception.cc | 1 - .../testsuite/18_support/exception_ptr/lifespan.cc | 1 - .../18_support/exception_ptr/make_exception_ptr.cc | 1 - .../exception_ptr/make_exception_ptr_2.cc | 1 - .../testsuite/18_support/exception_ptr/move.cc | 1 - .../18_support/exception_ptr/requirements.cc | 1 - .../18_support/exception_ptr/requirements_neg.cc | 1 - .../18_support/exception_ptr/rethrow_exception.cc | 1 - .../testsuite/18_support/nested_exception/51438.cc | 1 - .../testsuite/18_support/nested_exception/62154
