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: "redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 17 May 2018 17:15:34 +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 #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Mathias Stearn from comment #7)
> > 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)?
That would move from an lvalue if called as:
E e;
std::make_exception_ptr<E&>(e);
I don't know if that's valid (I sent an email to the LWG reflector about that a
few minutes ago).
> I don't know why, but make_exception_ptr
> takes the exception by value rather than forwarding ref.
Probably so it decays (which "throw e;" will do anyway).
> 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
Without thinking about it too deeply, no I don't think it should have that. It
could have negative consequences on the optimization of other code around the
call to make_exception_ptr (which might be more important, non-error handling
code, that should be inlined in preference to the error-handling path).
> 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!
Rather than always_inline a better option might be to give it a different
mangled name when exceptions are disabled (or just not declare it at all, but
it might be too late for that as it would be a breaking change). That would
ensure the return-null version never gets chosen by the linker to replace the
real version.