Re: GCC GSoC 2022: Call for project ideas and mentors

[Thomas Schwinge <thomas@codesourcery.com>]

Hi David!

On 2022-01-07T12:41:17-0500, David Malcolm via Fortran <fortran@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 <dmalcolm@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