Hi David! On 2022-01-07T12:41:17-0500, David Malcolm via Fortran <fort...@gcc.gnu.org> wrote: > I'd like to (again) mentor a project relating to the GCC static > analyzer: > https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer > > I've updated the analyzer task ideas on: > https://gcc.gnu.org/wiki/SummerOfCode > but the ideas there are suggestions
May I suggest -- and add to that page if you agree to co-mentor :-) -- another GCC static analyzer project? Responding to your initial "RFC: Add a static analysis framework to GCC", in <http://mid.mail-archive.com/yxfpy2wfv9hq.fsf@hertz.schwinge.homeip.net> I had said: On 2019-11-16T21:42:25+0100, I wrote: > On 2019-11-15T20:22:47-0500, David Malcolm <dmalc...@redhat.com> wrote: >> [...] >> Specific state machines include: >> - a checker for malloc/free, for detecting double-free, resource leaks, >> use-after-free, etc (sm-malloc.cc), and > > I can immediately see how this can be useful for a bunch of > 'malloc'/'free'-like etc. OpenACC Runtime Library calls as well as source > code directives. ..., and this would've flagged existing code in the > libgomp OpenACC tests, which recently has given me some grief. Short > summary/examples: > > In addition to host-side 'malloc'/'free', there is device-side (separate > memory space) 'acc_malloc'/'acc_free'. Static checking example: don't > mix up host-side and device-side pointers. (Both are normal C/C++ > pointers. Hmm, maybe such checking could easily be implemented even > outside of your checker by annotating the respective function > declarations with an attribute describing which in/out arguments are > host-side vs. device-side pointers.) > > Then, there are functions to "map" host-side and device-side memory: > 'acc_map_data'/'acc_unmap_data'. Static checking example: you must not > 'acc_free' memory spaces that are still mapped. > > Then, there are functions like 'acc_create' (or equivalent directives > like '#pragma acc create') doing both 'acc_malloc', 'acc_map_data' > (plus/depending on internal reference counting). Static checking > example: for a pointer returned by 'acc_create" etc., you must use > 'acc_delete' etc. instead of 'acc_free', which first does > 'acc_unmap_data' before interal 'acc_free' (..., and again all that > depending on reference counting). (Might be "interesting" to teach your > checker about the reference counting -- if that is actually necessary; > needs further thought.) So, something like: "Extend the GCC static analyzer to understand OpenACC host vs. device memory" (plus an example or two, similar to what I quoted above). The project can scale depending on what we/applicant intends to do. I'm happy to advise on the OpenACC bits, but will need you for the general analyzer infrastructure. Opinions? Grüße Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
