https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 61493 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61493&action=edit gcc16-pr117785-wip.patch Very early WIP patch. This can right now handle a trivial exception throwing + catching, e.g. struct S { constexpr S (); constexpr S (const S &); constexpr ~S (); }; struct T : public S { constexpr T (); constexpr T (int); constexpr T (const T &); constexpr ~T (); }; constexpr S::S () {} constexpr S::S (const S &) {} constexpr S::~S () {} constexpr T::T () {} constexpr T::T (int) {} constexpr T::T (const T &) {} constexpr T::~T () {} constexpr int foo () { try { throw T (1); } catch (int &a) { return 1; } catch (const S &b) { return 2; } catch (...) { return 3; } return 4; } constexpr int a = foo (); static_assert (a == 2); As the IL constexpr evaluation sees already uses calls to __cxa_{allocate_exception,free_exception,throw,rethrow,begin_catch,end_catch} I've implemented it so far as if they were magic constexpr builtins. Guess for some parts of the library implementation we'll need to add further builtins, but many of the libsupc++ headers have methods implemented out of line in libsupc++.a/libstdc++.so, so not sure how to deal with their constexpr definition when we want to call the out of line implementation with ABI compatible name unless if consteval. On the compiler side, I guess the largest task is probably to pass jump_target unconditionally (so drop the default argument) and deal with throws (jump_target) in tons of places - the existing "jumps" like switch/break/continue/return were expected to happen only in statements, not arbitrary subexpressions (although that actually isn't the case for say ({ if (something) return; 42; }) in arbitrary subexpressions), but e.g. for binary expressions too chose a random example we will need if (throws (jump_target)) return NULL_TREE; or so after evaluating the arguments before evaluating the rest.
