On Sun, 2022-02-20 at 12:19 +0100, Thomas Schwinge wrote: > 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?
(replying onlist this time) Thanks; yes, I'd be happy to co-mentor such a project. To what extend does the OpenACC Runtime Library API differentiate between host-side and device-side pointers in the type system? This seems reminiscent of the user-space vs kernel-space pointers I tried to implement in: [PATCH 0/6] RFC: adding support to GCC for detecting trust boundaries https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584372.html Do any of my approaches there seem to overlap with the issues you're running into? Dave
