On Sat, 2026-03-07 at 00:56 +0530, Saksham Gupta via Gcc wrote: > Hi David and the GCC team, > > Since my last email, I’ve been diving deeper into the -fanalyzer > internals > to better understand the region model and svalue mapping. > > To gain some hands-on experience, I took a look at PR 114798 (ICE: in > convert_svalue_from_summary_1, at analyzer/call-summary.cc:290). I > was able > to reproduce the crash on an aarch64-apple-darwin system using the > provided > test case and -fanalyzer-call-summaries.
Excellent. > > I’ve developed a patch that addresses the ICE by allowing the call- > summary > replay to bail out gracefully with nullptr when encountering nested > function static chains that aren't present in the parameter cache, > rather > than triggering a gcc_assert failure. > > I have attached the patch to this email Thanks; I see it. > (and also uploaded it to the > Bugzilla ticket). FWIW I don't see it attached to the ticket. Thanks for the patch. Basic formatting and presentation looks good (you correctly provided a ChangeLog, linked to the bug, and Signed-Off-By). A confession: I don't fully understand how nested functions are supposed to work in GCC, so unfortunately it's not clear to me what the analyzer should do with them, and, in the case of this bug, how it should summarize them. So a high-level issue with this bug is that I worry that we could be "papering over" problems, rather than letting them fail loudly. > The patch includes: > > 1. A fix for the SK_INITIAL assertion failure. As noted above, I worry this is papering over an issue. I'd like input from another GCC expert on how nested functions are meant to work. So this might not be the best bug to focus on right now; sorry. > 2. A fallback for unknown svalue kinds in the default switch case. FWIW I want to leave that assertion in-place, so that it fails loudly if we ever add a new SK_* kind and forget to update this switch statement. > 3. A new test case in gcc/testsuite/gcc.dg/analyzer/pr114798.c. The testcase looks good. Given that the intent of the test is merely that we don't crash, maybe call it "ice-pr114798.c"? (or put a comment to that effect at the top). > > I would appreciate any feedback on the patch as I continue preparing > my > formal GSoC proposal for the CPython API checker. When posting a patch, it's good to state what level of testing it's had. I'm not expecting this for a first patch, but the ideal here is that a patch should be "bootstrapped" and "regression tested": do a bootstrap build of gcc and (assuming it succeeds!) run the full testsuite via "make check". The analyzer also has its own integration testing suite which I try to run when making significant changes. Testing has been a pain-point for new contributors in the past, but we now have a "forge" instance that supports pull requests, with some CI support - though I can't find the link right now, sorry. Thanks again for the patch; hope this is constructive. Let me know if you have further questions. Dave > > Best regards, > Saksham Gupta > https://github.com/am-saksham > > > On Fri, 6 Mar 2026 at 23:32, Saksham Gupta > <[email protected]> > wrote: > > > Hi everyone, > > > > My name is Saksham Gupta, and I am a 3rd-year Computing Science & > > Engineering student. I am writing to express my strong interest in > > contributing to GCC for GSoC 2026, specifically under the project > > "Extending the static analysis pass" to add checking for the > > CPython API, > > mentored by David Malcolm. > > > > I have a strong background in C++ and Python, alongside a deep > > interest in > > vulnerability analysis and cybersecurity. I have previously > > developed risk > > analysis models to detect systemic vulnerabilities, and extending > > -fanalyzer to catch reference-counting bugs and memory leaks in > > C/C++ > > Python extensions feels like a natural and exciting progression of > > that > > work. > > > > To prepare for this proposal, I have completed the prerequisites > > outlined > > in the "Before you apply" guide: > > > > - I have successfully checked out the GCC source. > > - I built GCC locally from source natively on an Apple Silicon > > Mac > > (using Iain Sandoe's gcc-darwin-arm64 branch, as I noted > > mainline lacks > > full native support). > > - I have successfully run the testsuite. > > - I've experimented with dumping the GIMPLE trees (-fdump-tree- > > all) to > > understand the intermediate representation flow. > > - I have read through the "Analyzer Internals" and "Debugging > > the > > Analyzer" documentation. > > > > Before I begin drafting my formal proposal, I would love to start > > contributing code. Could anyone point me toward a "good first > > issue" or a > > relatively isolated bug in the gcc/analyzer/ directory that I could > > attempt > > to patch to familiarize myself with the workflow? > > > > Thank you for your time and for maintaining such an incredible > > project. > > > > Best regards, > > Saksham Gupta > > https://github.com/am-saksham > > https://www.linkedin.com/in/am-saksham-gupta/ > >
