* [Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions
[not found] <bug-85813-4@http.gcc.gnu.org/bugzilla/>
@ 2021-12-09 18:36 ` redi at gcc dot gnu.org
2021-12-09 23:29 ` cvs-commit at gcc dot gnu.org
2021-12-09 23:36 ` redi at gcc dot gnu.org
2 siblings, 0 replies; 3+ messages in thread
From: redi at gcc dot gnu.org @ 2021-12-09 18:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 3+ messages in thread* [Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions
[not found] <bug-85813-4@http.gcc.gnu.org/bugzilla/>
2021-12-09 18:36 ` [Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions redi at gcc dot gnu.org
@ 2021-12-09 23:29 ` cvs-commit at gcc dot gnu.org
2021-12-09 23:36 ` redi at gcc dot gnu.org
2 siblings, 0 replies; 3+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-12-09 23:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 3+ messages in thread