From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 3B2413858D35 for ; Sun, 20 Feb 2022 11:19:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3B2413858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: azcTbcEBuPkw48ZJjHODF2jEdtlOHFps/te4eKxjKf0uOYAXgxvACXZ4O5rXfV/rcxM0+I6/U/ XOG8+dh7mwCYovFpAtuwlE8aVPGBLCYqla4YAjv59krYdaM2vPEdiM3wL1NQqdUkRwnQURVyaw t4gI2OSCjNJHe68HAbrui8sA1sebKqQqeidnEPxIS6hIIkZ6dE8lOHmdQCw8IOp717ZX94aZzm zUl/KmN9lkvy6ivyLPY4QlOV/cf9a0Hrq05+0ikRzjjp4qhOmT6bMNeiNG6rU61Eg1Bg+C2OqF rJ0PTi1/RB3iDCgxTAIkWbA2 X-IronPort-AV: E=Sophos;i="5.88,383,1635235200"; d="scan'208";a="72058437" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 20 Feb 2022 03:19:29 -0800 IronPort-SDR: 8EN0/t6wDT59RZkN/y27QK0ZHrOAOxUOAOklHu+wQw9t5Wo/Z5ftK5Hm0f0Yo53miUDp+z+ZFG kWCpa/gHJRXAKhTaoIv4CD6QMh3ViaLFg6j54XMSmvMny925ZKze5+7Z30sdxzONLItmdkXP0l ht70FgBD2YlfhP86w5qy5xmnstlkPFgg9FDKwN4zX+DmiUdhhqnZ3mTqfVuTiYDRCSAwyMiKWi S7u0wnesKxobogKdoERhuEVJjU6b6nuJzf8m6IhJk41yYVdWQqFH0c4p2N/y2yy3Hx13E7gu/J buE= From: Thomas Schwinge To: David Malcolm CC: Martin Jambor , Subject: Re: GCC GSoC 2022: Call for project ideas and mentors In-Reply-To: References: User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Sun, 20 Feb 2022 12:19:18 +0100 Message-ID: <875yp9pyyx.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-15.mgc.mentorg.com (139.181.222.15) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2022 11:19:32 -0000 Hi David! On 2022-01-07T12:41:17-0500, David Malcolm via Fortran 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 I had said: On 2019-11-16T21:42:25+0100, I wrote: > On 2019-11-15T20:22:47-0500, David Malcolm 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=C3=BC=C3=9Fe Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955