From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 08789385BF84 for ; Mon, 21 Feb 2022 18:01:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 08789385BF84 Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-380-0FJiPmB6OOK8BFriOXcNqg-1; Mon, 21 Feb 2022 13:01:22 -0500 X-MC-Unique: 0FJiPmB6OOK8BFriOXcNqg-1 Received: by mail-qv1-f72.google.com with SMTP id cg14-20020a05621413ce00b0042c2706a4beso17912157qvb.23 for ; Mon, 21 Feb 2022 10:01:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=uJeJ9wvpeuvoevHfYNr+jQmLxGWPjyZ5+QBrBkDcj0Y=; b=M1SPWznX3IrMkUl1KRNYkQssvMql+arCNzP2g3+tX7p2sMNffACQ+RUTel8U4j2OF5 XoOC+MRSYU9B++plCyJnhZgVIR8Rt/KwxS5sOnKZazdFd8xkZi/3zuNiwv/U9FIxnxkP 819PVZ43VISLSGErADMOSuDGOkh/NBMgzSM/ReTDDCjg5p8rNj14XxcVHI4hFUR68nxw 9qSs1IBbuEejY1+GTR1sCkyA13R/SJijxCO8aU2SqvtCn3w19SUht2UuY55DPommQ3Ps 9vP+eQkqb8wF4sNk4twVS1S0SNv/d06yEwoLSSKgCLKAjM99gL4LLl/8Ewbk31HCVSZ+ Eplg== X-Gm-Message-State: AOAM530k34NtojTNEZi1kYbAIV0dcO+MTm+X/wNptExEJiUCskR29zcw Dse5hLXiS9CxWE9AkHKuUWb7TftD0TYnM9MV4Mlla5k2H0tZy49eD/++VHvaWiZ5RBV0BuCx/j/ rOydVgfM= X-Received: by 2002:ad4:4dcf:0:b0:42d:512d:ee33 with SMTP id cw15-20020ad44dcf000000b0042d512dee33mr15661947qvb.105.1645466481978; Mon, 21 Feb 2022 10:01:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJzK/o9fg1NBLgsO5c2ynSBnXIW0I3GWn789DMBW6UGlqAU/sn9yjTnC4yt2V1ce9hw4Hve8bw== X-Received: by 2002:ad4:4dcf:0:b0:42d:512d:ee33 with SMTP id cw15-20020ad44dcf000000b0042d512dee33mr15661921qvb.105.1645466481673; Mon, 21 Feb 2022 10:01:21 -0800 (PST) Received: from t14s.localdomain (c-73-69-212-193.hsd1.ma.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id x83sm7553637qkb.68.2022.02.21.10.01.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Feb 2022 10:01:21 -0800 (PST) Message-ID: Subject: Re: GCC GSoC 2022: Call for project ideas and mentors From: David Malcolm To: Thomas Schwinge Cc: Martin Jambor , gcc@gcc.gnu.org Date: Mon, 21 Feb 2022 13:01:19 -0500 In-Reply-To: <875yp9pyyx.fsf@euler.schwinge.homeip.net> References: <875yp9pyyx.fsf@euler.schwinge.homeip.net> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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: Mon, 21 Feb 2022 18:01:25 -0000 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 < > 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 > > 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