From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 863053858D39 for ; Mon, 3 Apr 2023 16:46:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 863053858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x629.google.com with SMTP id o11so28655840ple.1 for ; Mon, 03 Apr 2023 09:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680540407; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Bd+kvzSrYusxQiyygtmED9HLlh3hysndwhGVrT86M5E=; b=Kg6EsNXfhZAZ4yrp2hxfetnZ5jmc8HIArK5bkJSCqTkIBmUNq90Q7nKkY8JxF6a2+v 27+/1RCW+VK2AIieWGi4W/7vEpFP3rj5ry4y8z3Jiq516q0Cg/1SG2CCT3obJnel19Fw tN85dqxYDlaehL6jspE2Fe93zy5EEJbMouxYtyxTLwBUfYbmXUndnfM78XMl62GNGBkN oDO5Zo1w8QsAR6h4hcxfYFoNTmzaalB+es7/FrtRVJHUcxQ6wwOS8NBPEJ6td0XHzTwf +LjP03XzngfIiAeZ394MUC6wUUck0RsJuKW0ND1uuiZx9Rg+MZLqT/eB4Nni9lYtIiki ov5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680540407; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Bd+kvzSrYusxQiyygtmED9HLlh3hysndwhGVrT86M5E=; b=jJiCDhAIpuIsw+AXzE0+euKehQ+UOBVKahgfozGJNbklc2R42X64nB2PwENsVl0Tx7 uQMZZN+Z89dWEEH+72rzx5n5mN0Q/p/JJrCqc1pN3xh2xN3rA8ZBmxGD4w5prvegr7nA HptTJjt/Ij+OphHB17iQ9ErpoK3308P+U3wlRrZO91C8dSxHEe6iwFDd7cGY4etoUhH8 Jufu3sl2XLHS/L2E7ZEFjCFqUajoruvTEObhrjQl9pjkvTGx1L68aU2hhIBBAzjkTwAb pMm0K4H6hMbxG6Q3N9wg9RzxaMoGWwUadxefd76CQYMWTsaMlX62VONsnc1LWJdPvit4 Krow== X-Gm-Message-State: AAQBX9dnU+Vsjv8A5y8XGvJBp3QiVnNUBByvQnJ2JS74xx5tY+7uyY32 NgRGkIjqFWdqhIlXLUHf5vImuiaQWUPQGgoiIPZi3woRcQZLR6w= X-Google-Smtp-Source: AKy350bo9qgG1HZo34Lhag1KIoY4P6B7B3qBLl4xderUxju+nRZ6AOKnwbYI/KQA60sCbdf/FeZdl2Bg9EcOzaoAt0s= X-Received: by 2002:a17:903:489:b0:1a2:8c7e:f325 with SMTP id jj9-20020a170903048900b001a28c7ef325mr5174663plb.11.1680540407246; Mon, 03 Apr 2023 09:46:47 -0700 (PDT) MIME-Version: 1.0 References: <53f74a943ae616e5ad2f02e11b013268d3554e97.camel@redhat.com> In-Reply-To: From: Benjamin Priour Date: Mon, 3 Apr 2023 18:46:36 +0200 Message-ID: Subject: Re: [GSoC][analyzer-c++] Submission of a draft proposal To: David Malcolm Cc: gcc@gcc.gnu.org Content-Type: multipart/alternative; boundary="00000000000001328c05f8714e22" X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --00000000000001328c05f8714e22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Following last mail, a classic I forgot to link my draft ! https://docs.google.com/document/d/1MaLDo-Rt8yrJIvC1MO8SmFc6fp4eRQM_JeSdv-1= kbsc/edit?usp=3Dsharing Best, Benjamin. On Mon, Apr 3, 2023 at 6:44=E2=80=AFPM Benjamin Priour wrote: > Hi David, > > On Mon, Apr 3, 2023 at 12:38=E2=80=AFAM David Malcolm wrote: > >> >> To be fair, C ones can be as well; the analyzer's exploded graphs tend >> to get very big on anything but the most trivial examples. >> >> >> > [...snip...] > > >> >> Indeed - you'll have to do a lot of looking at gimple IR dumps, what >> the supergraph looks like, etc, for all of this. >> >> > Yep. I have already tried my hands on them, but to be fair I'm still often > troubled by them. Still, > doing so have already provided essential insight on the analyzer. > > [...snip...] > > >> > 4. Extension of out-of-bounds >> > ( - Extending -Wout-of-bounds to the many vec<...> might be a >> > requirement. >> > However I have to look into more details for that one, I don't see >> > yet how >> > it could be done without a similar reuse of the assertions as for the >> > libstdc++.) >> > >> > From what I saw, despite the bugs not being FIXED, vfuncs seem to be >> > working nicely enough after the fix from GSoC 2021. >> >> IIRC I was keeping those bugs open because there's still a little room >> for making the analyzer smarter about the C++ type system e.g. if we >> "know" that a foo * is pointing at a particular subclass, maybe we know >> things about what vfunc implementations could be called. >> >> We could even try an analysis mode where we split the analysis path at >> a vfunc call, where we could create an out-edge in the egraph for each >> known concrete subclass for foo *, so that we can consider all the >> possible subclasses and the code that would be called. (I'm not sure >> if this is a *good* idea, but it intrigues me) >> > > Like adding a flag to run in a non-standard mode, to debug when an > unexpected vfunc analysis occurs ? TBH I didn't look that much into vfuncs > support, as my dummy tests behave OK and I assumed it was fixed after last > GSoC. > > >> >> > >> > Unfortunately I couldn't devote as much time as I wanted to gcc >> > yesterday, >> > I plan to send a proposal draft tomorrow evening. Sincerely sorry for >> > the >> > short time frame before the deadline. >> >> Sound promising. Note that the deadline for submitting proposals to >> the official GSoC website is April 4 - 18:00 UTC (i.e. this coming >> Tuesday) and that Google are very strict about that deadline; see: >> https://developers.google.com/open-source/gsoc/timeline >> >> I believe you've already had a go at posting gcc patches to our mailing >> list: that's a great thing to mention in your application. >> > Thanks for the tip, I added it to my draft ! > >> >> Good luck! >> Dave >> >> Thanks ! BTW here is my draft proposal (in a google doc, I hope this is > OK). > If you can find the time to give me some feedback (as always), I would > greatly appreciate it ! > Below I will dump the "project goals" part, so that it's openly available > on the mail list. > Note that I've annotated some sections with [RFC], it's for your > easy-of-use when reviewing part I'm explicitly asking for feedback. Just = do > a Ctrl-F on the string [RFC] > > A bit out of context, but since you always sign your mails 'Dave', should > I address you that way ? Unsure about that. > > Best, > Benjamin. (see below for the dump) > > The aim of this project is to enable the analyzer to self-analyze itself. > To do so, the following items should be implemented (m: minor, M: Major > feature) > > Generalize gcc.dg/analyzer tests to be run with both C and C++ [PR96395] > [M] > > Support the options relative to checker sm-malloc > -Wanalyser-double-free should behave properly for C++ allocations > pairs new, new[], delete and delete[] both throwing and non-throwing > versions. > At the moment, only their non-throwing counterparts are somewhat > handled, yet incorrectly as the expected -Wanalyzer-double-free is replac= ed > by -Wanalyzer-use-after-free [m] and an incorrect > -Wanalyzer-possible-null-dereference is emitted [fixed]. > I filed it as bug PR109365 [2]. > > Add support for tracking unique_ptr null-dereference [M]. While > smart_ptr is correctly handled, the code snippet below demonstrates that > this warning is not emitted for unique_ptr [4]. > Figure 1 - First test case for unique_ptr support > struct A {int x; int y;}; > int main () { > std::unique_ptr a; > a->x =3D 12; /* -Wanalyzer-null-dereference missing */ > return 0; > } > > Improve the diagnostic path for the standard library, with shared_ptr as > a comparison point, so that they do not wander through the standard libra= ry > code. [M] > Figure 2 - Reproducer to demonstrate unnecessarily long diagnostic paths > when using the standard library. > struct A {int x; int y;}; > int main () { > std::shared_ptr a; > a->x =3D 4; /* Diagnostic path should stop here rather than going to > shared_ptr_base.h */ > return 0; > } > [RFC] I believe this could be a 350-hours project as time flies by > quickly, but I=E2=80=99m more than open to your suggestions to support > self-analysis. I=E2=80=99ve read your idea on splitting at vfunc points, = I=E2=80=99m > currently looking into it. > An additional goal I have considered is to add out-of-bounds support for > the auto_vec. This would include supporting templates, but a shallow > testing on my box proved them to be somewhat handled already. > > May-be solved alongside > > > Support of new placements sizes, emitting warning on incorrect pairing > of placement new/delete, as part of goal {2}. > --00000000000001328c05f8714e22--