https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813
--- Comment #4 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.
Simply returning an empty exception_ptr is what happened before the PR 64241
change, so what we do now retains that behaviour. That might be the main reason
for it.
It would be possible to use the new throw-less implementation for the
-fno-exceptions case. It would be fine for types with a non-throwing move, at
least:
--- a/libstdc++-v3/libsupc++/exception_ptr.h
+++ b/libstdc++-v3/libsupc++/exception_ptr.h
@@ -185,7 +185,7 @@ namespace std
__exception_ptr::__dest_thunk<_Ex>);
try
{
- ::new (__e) _Ex(__ex);
+ ::new (__e) _Ex(std::forward<_Ex>(__ex));
return exception_ptr(__e);
}
catch(...)
@@ -203,7 +203,19 @@ namespace std
return current_exception();
}
#else // no RTTI and no exceptions
+#if __cplusplus >= 201103L
+ if _GLIBCXX17_CONSTEXPR (std::is_nothrow_move_constructible<_Ex>::value)
+ {
+ 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<_Ex>);
+ ::new (__e) _Ex(std::forward<_Ex>(__ex));
+ return exception_ptr(__e);
+ }
+#else
return exception_ptr();
+#endif
#endif
}
> Is that just accepted, implying the the whole program must be compiled with
> either -fexceptions or -fno-exeptions, rather than allowing mix-and-match?
> If so, I guess this whole point is moot.
Mix-and-match works if the function gets inlined.
But if you mix -fexceptions and -fno-exceptions then you do have to accept that
the resulting ODR violations might give surprising or undesirable results.
