On 6/19/26 2:24 PM, Egas Ribeiro wrote:
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?
It's only been used for diagnostics, but it's better for it to be
accurate, I think it just never got updated.
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.
Yes,
try { throw nullptr; }
catch (void*) {}
catch (decltype (nullptr)) {}
should warn in check_handlers_1.
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);
