On Wed, 2026-03-18 at 21:00 +0000, Egas Ribeiro wrote: > 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.
Thanks Egas. Looks good; I see the proposal in the GSoC website. Dave > > > 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 >
