https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85813
--- Comment #3 from Mathias Stearn <redbeard0531 at gmail dot com> ---
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.
However, while testing the behavior of mixing -fno-exceptions TUs with normal
ones, I realized there may be a bigger problem due to ODR violations. In
particular, if you link these TUs without optimizations, one of the asserts
will trip depending on the link order:
// g++ -fno-exceptions -c
#include <exception>
#include <cassert>
void no_exceptions() {
assert(!std::make_exception_ptr(1));
}
// g++ -fexceptions
#include <exception>
#include <cassert>
void no_exceptions();
int main() {
assert(std::make_exception_ptr(1));
no_exceptions();
}
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.
