Hi,
I'd like to propose a project for GSoC 2026 extending C++ support in
GCC's static analyzer, mentored by David Malcolm. This would be a large
(350-hour) project.
Project description
-------------------
GCC 16 adds initial exception handling support to -fanalyzer, but catch
clauses currently only match exception types exactly (i.e. Throwing a
derived class and catching by base reference is not recognized). This
causes the analyzer to miss bugs inside catch blocks (false negatives)
and to incorrectly report resources as leaked when they are actually
handled (false positives).
The root cause is that the analyzer has no way to query C++ class
hierarchies. This also limits virtual function resolution - the analyzer
can resolve virtual calls when the concrete type is fully known, but
cannot reason about possible callees through a base pointer.
I propose to fix this by:
1. Implementing exception subclass matching (PR119697)
2. Improving virtual function resolution (PR97114)
3. Addressing additional C++ items from the PR97110 tracker as time
permits.
Technical approach
------------------
Exception subclass matching (PR119697):
The fix will be in exception_matches_type_p in ops.cc, which currently
does pointer equality on types. It needs to answer "is the thrown type a
subclass of the catch type?" following the C++ [except.handle] rules.
Rather than duplicating the matching logic from gcc/cp/except.cc
(can_convert_eh) in the analyzer, I propose extending the language hook
interface in analyzer-language.h with a method like
type_matches_for_catch_p, implemented by the C++ frontend. This keeps
the analyzer language-agnostic and avoids maintaining two copies of the
same C++ semantics. Alternatively, a new interface can be added.
If this proves problematic (i.e., frontend state dependencies), a
fallback approach would be walking BINFO directly in the analyzer. I'd
like to discuss this design choice during community bonding.
Virtual function resolution (PR97114):
The existing OBJ_TYPE_REF handling resolves virtual calls when the
concrete type is known. I'd extend this by using type hierarchy
information to enumerate possible callees when only the base type is
known, potentially reusing logic from ipa-devirt.cc as David suggested
in the original bug report . I'll investigate this during the second
half of the project and scope it with David based on how the exception
work goes.
Timeline
--------
I'm finishing my last semester at IST (University of Lisbon) through
June, so May will be at reduced capacity (~15hrs/week), with increasing
availability through June as course projects wrap up. July-August will
be full-time.
Community bonding (May 1-24):
Extend my existing gcc1plus Neovim plugin and scripts for analyzer
testing. Investigate the language hook vs BINFO design question.
Discuss approach with David.
Weeks 1-2 (May 25 - Jun 7):
Implement the language hook infrastructure or BINFO walking and
initial exception_matches_type_p fix for the basic case (derived
caught by base reference).
Weeks 3-5 (Jun 8 - Jun 28):
Handle remaining [except.handle] edge cases: catch by pointer,
cv-qualification, multiple inheritance/ambiguous bases. Write or reuse
DejaGnu tests for each case.
Weeks 6-7 (Jun 29 - Jul 12): [Midterm]
Finish exception subclass work, clean up patches for review, address
feedback. Submit patches.
Weeks 8-10 (Jul 13 - Aug 2):
Begin virtual function resolution improvements. Investigate
ipa-devirt.cc integration. Handle the case where concrete type is
inferrable from recent allocations.
Weeks 11-12 (Aug 3 - Aug 24):
Continue vfunc work. Pick up smaller items from the PR97110 tracker
(i.e., PR109365, PR98830, PR97116). Final cleanup and patch
submission.
The timeline is conservative. If exception subclass matching goes faster
than expected, I'll spend more time on virtual function resolution and
the stretch goals.
About me
--------
I've had around a dozen patches merged into GCC 16's C++ frontend since
October, working primarily with Jason Merrill and Patrick Palka on fixes
across template instantiation, SFINAE, partial specialization, and
concepts. I attended Cauldron in Porto last year (where I met several
maintainers) and FOSDEM'26.
I've confirmed the current PR119697 behavior by running -fanalyzer on
test cases with subclass catch clauses and examining the supergraph and
exploded graph output.
I'm familiar with middle-end IR/SSA theory from Engineering a Compiler
(Cooper & Torczon) and from implementing my own compilers with SSA IR
and CFG-based passes (https://github.com/riogu/henceforth,
https://github.com/riogu/fumo-compiler). I can also closely follow the
C++ standard during the implementation.
I will be available for the full standard coding period (May 25 - August
24).
Thanks, Egas
