From: Jonathan Wakely <jwakely@redhat.com>
To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: [committed] libstdc++: Make std::make_exception_ptr work with -fno-exceptions [PR85813]
Date: Thu, 9 Dec 2021 23:30:54 +0000 [thread overview]
Message-ID: <20211209233054.1569594-1-jwakely@redhat.com> (raw)
Tested powerpc64le-linux, pushed to trunk.
This allows std::make_exception_ptr to be used in a translation unit
compiled with -fno-exceptions. This works because the new implementation
added for PR 68297 doesn't need to throw or catch anything. The catch is
there to handle exceptions from the constructor of the exception object,
which we can assume won't happen in a -fno-exceptions TU and so use the
__catch macro instead. If the constructor does throw (because it's
defined in a different TU which was compiled with exceptions enabled)
then that exception will propagate to the make_exception_ptr caller.
That seems acceptable for a program that is trying to mix & match TUs
compiled with and without exceptions, and using types that throw when
constructed. That should be rare, and can't reasonably be expected to
have sensible behaviour.
This also enables the new implementation for targets that use a
non-standard calling convention for the exceptionDestructor callback
(specifically, mingw, which uses __thiscall). All we need to do is mark
the __dest_thunk function template with the right calling convention.
Finally, the useless no-op definition of make_exception_ptr (which is
only used if both RTTI and exceptions are disabled) is marked
always_inline, to ensure that the linker won't keep that definition and
discard the functional ones when both definitions of the function are
present in the link. An alternative would be to add the abi_tag
attribute to the useless definition, but making it always_inline should
work, and it's small enough to always be inlined reliably.
libstdc++-v3/ChangeLog:
PR libstdc++/85813
* libsupc++/exception_ptr.h (__dest_thunk): Add macro for
destructor calling convention.
(make_exception_ptr): Enable non-throwing implementation for
-fno-exceptions and for non-standard calling conventions. Use
always_inline attribute on the useless no-rtti no-exceptions
definition.
* testsuite/18_support/exception_ptr/64241.cc: Add -fno-rtti so
the no-op implementation is still used.
---
libstdc++-v3/libsupc++/exception_ptr.h | 30 ++++++++++++-------
.../18_support/exception_ptr/64241.cc | 2 +-
2 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/libstdc++-v3/libsupc++/exception_ptr.h b/libstdc++-v3/libsupc++/exception_ptr.h
index f59752478b1..8c700e64265 100644
--- a/libstdc++-v3/libsupc++/exception_ptr.h
+++ b/libstdc++-v3/libsupc++/exception_ptr.h
@@ -225,6 +225,7 @@ namespace std
/// @cond undocumented
template<typename _Ex>
+ _GLIBCXX_CDTOR_CALLABI
inline void
__dest_thunk(void* __x)
{ static_cast<_Ex*>(__x)->~_Ex(); }
@@ -233,28 +234,28 @@ namespace std
} // namespace __exception_ptr
/// Obtain an exception_ptr pointing to a copy of the supplied object.
+#if (__cplusplus >= 201103L && __cpp_rtti) || __cpp_exceptions
template<typename _Ex>
- exception_ptr
+ exception_ptr
make_exception_ptr(_Ex __ex) _GLIBCXX_USE_NOEXCEPT
{
-#if __cpp_exceptions && __cpp_rtti && !_GLIBCXX_HAVE_CDTOR_CALLABI \
- && __cplusplus >= 201103L
- using _Ex2 = typename remove_reference<_Ex>::type;
+#if __cplusplus >= 201103L && __cpp_rtti
+ using _Ex2 = typename decay<_Ex>::type;
void* __e = __cxxabiv1::__cxa_allocate_exception(sizeof(_Ex));
(void) __cxxabiv1::__cxa_init_primary_exception(
__e, const_cast<std::type_info*>(&typeid(_Ex)),
__exception_ptr::__dest_thunk<_Ex2>);
- try
+ __try
{
- ::new (__e) _Ex2(std::forward<_Ex>(__ex));
- return exception_ptr(__e);
+ ::new (__e) _Ex2(__ex);
+ return exception_ptr(__e);
}
- catch(...)
+ __catch(...)
{
__cxxabiv1::__cxa_free_exception(__e);
return current_exception();
}
-#elif __cpp_exceptions
+#else
try
{
throw __ex;
@@ -263,10 +264,17 @@ namespace std
{
return current_exception();
}
-#else // no RTTI and no exceptions
- return exception_ptr();
#endif
}
+#else // no RTTI and no exceptions
+ // This is always_inline so the linker will never use this useless definition
+ // instead of a working one compiled with RTTI and/or exceptions enabled.
+ template<typename _Ex>
+ __attribute__ ((__always_inline__))
+ exception_ptr
+ make_exception_ptr(_Ex) _GLIBCXX_USE_NOEXCEPT
+ { return exception_ptr(); }
+#endif
#undef _GLIBCXX_EH_PTR_USED
diff --git a/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc b/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc
index 486b16c8dcc..034a0a08a8c 100644
--- a/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc
+++ b/libstdc++-v3/testsuite/18_support/exception_ptr/64241.cc
@@ -15,7 +15,7 @@
// with this library; see the file COPYING3. If not see
// <http://www.gnu.org/licenses/>.
-// { dg-options "-fno-exceptions -O0" }
+// { dg-options "-fno-exceptions -fno-rtti -O0" }
// { dg-do run { target c++11 } }
#include <exception>
--
2.31.1
reply other threads:[~2021-12-09 23:31 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211209233054.1569594-1-jwakely@redhat.com \
--to=jwakely@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).