https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #6)
> (In reply to Jakub Jelinek from comment #3)
> > Jonathan, thoughts on the library side?
> > E.g. std::uncaught_exceptions is just declared in the header, but if it
> > needs to be constexpr it needs some inline definition but for ABI reasons
> > better should call the original function. std::current_exception is also
> > defined out of line, for constant evaluation it better use some helper
> > builtin which returns void * and construct exception_ptr from that.
>
> Interesting echoes of gnu_inline in this situation.
>
> You mention that you already treat some of the functions as magic builtins,
> is there a reason not to do that for these as well, and leave the library
> alone?
Right now the patch handles 10 __cxa_* extern "C" functions as magic builtins.
For most of them that was not easily avoidable because we already emit those in
the IL the constexpr evaluator uses.
Today I ran into:
--- libstdc++-v3/libsupc++/exception.h.jj 2025-04-08 14:10:30.519900011
+0200
+++ libstdc++-v3/libsupc++/exception.h 2025-05-27 15:25:32.521420068 +0200
@@ -61,13 +61,17 @@ namespace std _GLIBCXX_VISIBILITY(defaul
class exception
{
public:
- exception() _GLIBCXX_NOTHROW { }
+ _GLIBCXX26_CONSTEXPR exception() _GLIBCXX_NOTHROW { }
+#if __cplusplus >= 202100L
+ constexpr virtual ~exception() _GLIBCXX_TXN_SAFE_DYN _GLIBCXX_NOTHROW {}
+#else
virtual ~exception() _GLIBCXX_TXN_SAFE_DYN _GLIBCXX_NOTHROW;
+#endif
#if __cplusplus >= 201103L
- exception(const exception&) = default;
- exception& operator=(const exception&) = default;
- exception(exception&&) = default;
- exception& operator=(exception&&) = default;
+ _GLIBCXX26_CONSTEXPR exception(const exception&) = default;
+ _GLIBCXX26_CONSTEXPR exception& operator=(const exception&) = default;
+ _GLIBCXX26_CONSTEXPR exception(exception&&) = default;
+ _GLIBCXX26_CONSTEXPR exception& operator=(exception&&) = default;
#endif
/** Returns a C-style character string describing the general cause
where making the destructor constexpr and thus effectively inline would have
terrible effects, virtual tables of exception and similar classes now emitted
everywhere.
So sure, if you'd be ok with treating e.g. std::exception::~exception (),
std::exception::what (), similarly for std::bad_exception, std::bad_alloc,
std::bad_cast, std::bad_typeid and then also std::uncaught_exceptions(),
std::current_exception(), std::rethrow_exception() and maybe others
as magic constexpr builtins, that would probably simplify stuff. Though a
question is what libc++ will choose to do.
