[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions

[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Mathias Stearn from comment #3)
> My assumption was that if E(...) throws and it can't be caught, it should be
> treated as any other case when an -fno-exceptions TU calls a throwing
> function. In this case that would mean calling terminate() due to the
> noexcept, which seems better than returning a null exception_ptr.

Unfortunately, if E(...) throws and std::make_exception_ptr<E> was compiled
with -fno-exceptions, the noexcept on that function is ignored and the
exception propagates to the caller of std::make_exception_ptr. So exceptions
can propagate out of a noexcept function compiled with -fno-exceptions, which
is pretty counterintuitive because that's the last kind of function you'd
expect to throw when you call it! But that's not unique to
std::make_exception_ptr, it's true for any noexcept function compiled with
-fno-exceptions that calls that could throw.

(In reply to Mathias Stearn from comment #7)
> Silently dropping errors always skeeves me out. I'm not sure if anyone is
> well served by the current behavior. If it were up to me (and I know it
> isn't) I'd make that case call std::terminate() or similar rather than
> returning the "no error" value. That seems consistent with the behavior of
> the __throw* functions, but it is a breaking change. Or even better, since
> gcc seems fine throwing through functions marked noexcept in -fno-exceptions
> TUs, maybe in the (very rare) case where copying/moving an exception throws
> inside an -fno-exceptions TU, just let it bubble out.

I'm persuaded that if constructing the E throws, we should just let it bubble
out. We can't really do anything else.

But we still have the case of -fno-rtti -fno-exceptions case where we can't use
the newer non-throwing implementation of make_exception_ptr (because it uses
typeid) and we can't use the original throwing one (because it uses throw). So
that either has to terminate or return an empty exception_ptr, and either case
is a problem if you mix'n'match, so ...

> Do you think this case warrants a [[gnu::always_inline]]?

I now think the -fno-rtti -fno-exceptions case should be always_inline.

Here's what I'm considering ...

  /// Obtain an exception_ptr pointing to a copy of the supplied object.
#if (__cplusplus >= 201103L && __cpp_rtti) || __cpp_exceptions
  template<typename _Ex>
    exception_ptr
    make_exception_ptr(_Ex __ex) _GLIBCXX_USE_NOEXCEPT
    {
#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
        {
          ::new (__e) _Ex2(__ex);
          return exception_ptr(__e);
        }
      __catch(...)
        {
          __cxxabiv1::__cxa_free_exception(__e);
          return current_exception();
        }
#else
      try
        {
          throw __ex;
        }
      catch(...)
        {
          return current_exception();
        }
#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

Because only the no-op implementation is always_inline, there won't be any
bloat caused by inlining the working implementation into a hot path.

[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

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.

[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |12.0
         Resolution|---                         |FIXED

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Implemented for GCC 12.