From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id 9A04B3858D39 for ; Mon, 3 Apr 2023 16:44:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9A04B3858D39 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-pg1-x52c.google.com with SMTP id x37so17881966pga.1 for ; Mon, 03 Apr 2023 09:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680540258; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5Mynx5LEBsKi0ZUHTZSotasMzOfm+eYErCZwqBFENVM=; b=TG1wT5cVE+Z/1grQOad4zBn3xIMtsHMoO4uDEQGHwuts6vfVEljRoqeLm5cs8W/cZt 0Kl7s9rnHqZSLMwDoh8knObb779dSZ9WKr16SLgbe3yS71R7pMbmzzuGST4bPbbJIshT 9wAcQLg9F/KEGYEgsiF2XmOg4CmBHe2FdtUuj8Gh+2Y7qQhA1b/BhoGM3niylmdD2wTd e/Tt/vm3cgwViv7CruikS6SdwR3oQO5DKY8WONwOLrzJnwZ43MHe4xbizdRiSFa9DKOB EGiKkptWJhyW7lCXNit6BQpl8mV0VjqewBeg0+lflGkcZeboUEIsKtr3w8DhwImBnDNc SW5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680540258; 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=5Mynx5LEBsKi0ZUHTZSotasMzOfm+eYErCZwqBFENVM=; b=j4+9lIVbpc1PhubKhfwVkfGFzfbmwOttSmI+oobwhVo80FMQL3TWs0H5QwkN2++lAp 7H4NS3YY5Gt7kwc2LU804I2lK4rIpYpNGJpIA8SojXQB1znsEJhkvWJDVVL6FbbQhDUD ZHOVLjm0UhMGNU8AEXsx9hol84aWUcjDQyPkMfD0vL7kjuB6JrkfD0Ifjuh4Lu6BrHVL lRhuCGiyTNqbK3+/4oLZDwOih2x33AH2dxX+U4x38PIKY0IcgFvRWHG3fENDhtHJ20Ta ggsu+fXCxF6MTu+m2hNMGuyy1IJAcVJEqo5LxlHoByWVX9FY8R70K4lhGKXzqlND0v2n yJsQ== X-Gm-Message-State: AAQBX9d1BQTFtZajVTvPE0Wwvxk1zbmy0WVhkzohxs61N4XhvyC4NHnn A9H+n2xYMXePnz4O7OXHq8G8yLRP2D5S7DS78w== X-Google-Smtp-Source: AKy350YsiYMLPpm03yJ1rb27QoI91QNKy6Quw1eBatg5x146Hp7WciKZ29wm5I2otfB3rvrxu1fo8/AB8QB4HEL0T3o= X-Received: by 2002:a05:6a00:2d8f:b0:62d:ccc4:2e03 with SMTP id fb15-20020a056a002d8f00b0062dccc42e03mr7732642pfb.4.1680540258073; Mon, 03 Apr 2023 09:44:18 -0700 (PDT) MIME-Version: 1.0 References: <53f74a943ae616e5ad2f02e11b013268d3554e97.camel@redhat.com> In-Reply-To: <53f74a943ae616e5ad2f02e11b013268d3554e97.camel@redhat.com> From: Benjamin Priour Date: Mon, 3 Apr 2023 18:44:06 +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="0000000000001d013305f87145c0" X-Spam-Status: No, score=-0.7 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: --0000000000001d013305f87145c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 replaced 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 library 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}. --0000000000001d013305f87145c0--