This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions
- From: "redbeard0531 at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 17 May 2018 17:00:54 +0000
- Subject: [Bug libstdc++/85813] make_exception_ptr should support __cxa_init_primary_exception path even with -fno-exceptions
- Auto-submitted: auto-generated
- References: <bug-85813-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813
--- Comment #7 from Mathias Stearn <redbeard0531 at gmail dot com> ---
> 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.
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.
> ::new (__e) _Ex(std::forward<_Ex>(__ex));
Should that be std::move(__ex)? I don't know why, but make_exception_ptr takes
the exception by value rather than forwarding ref. I guess forward<_Ex> is fine
either way, and will stay correct if that defect gets fixed. It just seemed odd
to forward a value so I thought I'd mention it.
> Mix-and-match works if the function gets inlined.
Do you think this case warrants a [[gnu::always_inline]]? Given the sensitive
nature of error handling, it seems pretty bad if a correct usage of
make_exception_ptr() could be silently transformed to return the "no error"
value just by linking in a bad library. Even if that library never dynamically
executes make_exception_ptr(). I know I'd hate to be called in to debug that
issue...
I'm going to go make sure no code we link with uses -fno-exceptions!