Re: [GSoC][RFC] Extending C++ support in -fanalyzer

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
>