https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126918
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Target Milestone|--- |16.3
Last reconfirmed| |2026-08-17
Status|UNCONFIRMED |NEW
CC| |jason at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, at runtime the nullptr -> pointer-to-member case is handled in
libsupc++/pbase_type_info.cc (__do_catch):
else if (typeid (*this) == typeid(__pointer_to_member_type_info))
{
if (__pointee->__is_function_p ())
{
using pmf_type = void (__pbase_type_info::*)();
static const pmf_type pmf = nullptr;
*thr_obj = const_cast<pmf_type*>(&pmf);
return true;
}
else
{
using pm_type = int __pbase_type_info::*;
static const pm_type pm = nullptr;
*thr_obj = const_cast<pm_type*>(&pm);
return true;
}
}
Dunno where we handle the cv qual differences etc., supposedly through an
aliasing violation.
Now, for normal pointers (rather than pointer-to-member) this is a non-issue,
__cxa_begin_catch for pointers returns a pointer by value rather than an
address of an object with that type. But for pointer-to-member it returns an
address of something.
Unlike runtime, we obviously can't (at least not easily) do strict aliasing
violation during constexpr evaluation, so the question is if we create some
magic object like pmf and pm above, what will be the lifetime of it.
