The motivation behind this patch is that the analyzer wants to use this method to check [except.handle] when analyzing GIMPLE generated by the C++ frontend, and I noticed the pointer branch doesn't implement the full qualification/ptm conversion rules. It might also be missing usage of TYPE_PTR_OR_PTRMEM_P.
The related analyzer patch can be found here: https://gcc.gnu.org/pipermail/gcc-patches/2026-June/720960.html Is can_convert_eh meant be a canonical type-level [except.handle] predicate, or is it diagnostic approximation? Also, I wasn't sure what tests I could add with this patch (maybe some extra caught diagnostics because of the addition?) so I didn't attach any new test. Bootstrapped and regtested on x86_64-pc-linux-gnu. -- >8 -- can_convert_eh implements the [except.handle] matching rules, but did not cover the case of a std::nullptr_t exception being caught by a handler of pointer or pointer-to-member type. Add it. gcc/cp/ChangeLog: * except.cc (can_convert_eh): Handle a nullptr_t exception caught by a pointer or pointer-to-member handler. Signed-off-by: Egas Ribeiro <[email protected]> --- gcc/cp/except.cc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/cp/except.cc b/gcc/cp/except.cc index 4f40a49ae3f..9c4cb37b6e6 100644 --- a/gcc/cp/except.cc +++ b/gcc/cp/except.cc @@ -982,6 +982,9 @@ can_convert_eh (tree to, tree from) if (same_type_ignoring_top_level_qualifiers_p (to, from)) return true; + if (TREE_CODE (from) == NULLPTR_TYPE && TYPE_PTR_OR_PTRMEM_P (to)) + return true; + if (TYPE_PTR_P (to) && TYPE_PTR_P (from)) { to = TREE_TYPE (to); -- 2.54.0
