public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Jonathan Wakely <redi@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org, libstdc++-cvs@gcc.gnu.org
Subject: [gcc r12-5880] libstdc++: Make std::make_exception_ptr work with -fno-exceptions [PR85813]
Date: Thu,  9 Dec 2021 23:29:39 +0000 (GMT)	[thread overview]
Message-ID: <20211209232939.9382A3858027@sourceware.org> (raw)

https://gcc.gnu.org/g:a8e02a00a0fcac42657c8ef7921566e42db8ef49

commit r12-5880-ga8e02a00a0fcac42657c8ef7921566e42db8ef49
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Dec 9 18:37:38 2021 +0000

    libstdc++: Make std::make_exception_ptr work with -fno-exceptions [PR85813]
    
    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.

Diff:
---
 libstdc++-v3/libsupc++/exception_ptr.h             | 30 ++++++++++++++--------
 .../testsuite/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>


                 reply	other threads:[~2021-12-09 23:29 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=20211209232939.9382A3858027@sourceware.org \
    --to=redi@gcc.gnu.org \
    --cc=gcc-cvs@gcc.gnu.org \
    --cc=libstdc++-cvs@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).