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 B47313858D33 for ; Wed, 1 Mar 2023 00:22:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B47313858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677630164; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g8TrR3fgBk6/l9w5dm26kQB3ALTMHSW9iMwnAzHbTlw=; b=YdNNtAZ9dz6EJ5uVuVq7TDNuj7/7R6t2+y3llT9x8QGpJwJpucsZ3/U093FkOg4jHZxZFg lmwcQ3jonbvLY9FSHYMwwNLt7hKoYD2vIlgbdRM1gc4FQSrnLbtPzyXajBB9mOXilXIJ33 OIsClZxOb+CVJcD5y2NkyhcUes7Uz7k= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-262-jgLqlGvNOPqoP45ybaf_dg-1; Tue, 28 Feb 2023 19:22:43 -0500 X-MC-Unique: jgLqlGvNOPqoP45ybaf_dg-1 Received: by mail-qt1-f200.google.com with SMTP id z22-20020ac86b96000000b003bfc3f97097so5626249qts.14 for ; Tue, 28 Feb 2023 16:22:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677630162; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=g8TrR3fgBk6/l9w5dm26kQB3ALTMHSW9iMwnAzHbTlw=; b=wfTOu4/ErK2Tnb2c9AmtvG4YFPo4f8m1cbHVih3iUToTiSlwHDG0sKDKCvZCXkgLxj zieUsZgSIYrG2nCvxExcUH3Z6XlFzF6JY4AMQEGR6+h4xj8n3ZLbi+fd+6j/3G+npy4/ A1HSy5sVnXXkG//n+5Q7swOxcr4MvLhN1MQ7P1We03aew4L6rAZfCr9fn+9GWrjRytbE 0Sk0yj1ZyGW9HIk2froVT9yNrR0nc5dESYrI3QpuMyWVvsiYAML7zkr6TTFr3Mm2nXru yCWJ+VhFG4cDSGYBcVz7q5rSXFEQftNwx09I91bFo6PbC8oV3iM6PFjr1cLOB7npQIuW YL8A== X-Gm-Message-State: AO0yUKWKh5FeRuAzUHN2oOUT7N+llKtXHyCj0vIp4U0SnwAVmsy9Qc1D DuWkvQO7ttC0c6CsAs4xCioWDUZZidw9JP78rO78HPgcg20xOF804Npudf8VkQCwXxIGZu7uOMF Zc11Y9dKYER5S X-Received: by 2002:a05:622a:134f:b0:3bf:a7c1:46a9 with SMTP id w15-20020a05622a134f00b003bfa7c146a9mr8704563qtk.40.1677630162200; Tue, 28 Feb 2023 16:22:42 -0800 (PST) X-Google-Smtp-Source: AK7set+pLi9Ukfuk9J9H6/QD5G+cgl2vzO7BpESxrValbU4cqEnuc8jedyfR+Ltl9RQ5uUrGyaZdyw== X-Received: by 2002:a05:622a:134f:b0:3bf:a7c1:46a9 with SMTP id w15-20020a05622a134f00b003bfa7c146a9mr8704540qtk.40.1677630161868; Tue, 28 Feb 2023 16:22:41 -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 n15-20020ac81e0f000000b003b691385327sm5781021qtl.6.2023.02.28.16.22.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Feb 2023 16:22:41 -0800 (PST) Message-ID: <0e6a972dac60ad290d21a82b428cc76c4e8565e9.camel@redhat.com> Subject: Re: [GSoC][Static Analyzer] Ideas for proposal From: David Malcolm To: Shengyu Huang Cc: GCC Development Date: Tue, 28 Feb 2023 19:22:40 -0500 In-Reply-To: References: <960EE623-1B17-4321-B77E-FBCD9496BE1F@gmail.com> <40fbb064f56845908f797400e5d9443b6cf97fe4.camel@redhat.com> User-Agent: Evolution 3.44.4 (3.44.4-1.fc36) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: On Tue, 2023-02-28 at 15:46 +0100, Shengyu Huang wrote: > Hi Dave, >=20 > > On 22 Feb 2023, at 15:11, Shengyu Huang > > wrote: > >=20 > > > But a better place to look would probably be in our bugzilla; see > > > the > > > links on the wiki page: > > > =C2=A0https://gcc.gnu.org/wiki/StaticAnalyzer=C2=A0 > > > The "open bugs" list currently has 41 "RFE" bugs ("request for > > > enhancement" i.e. ideas for new features), some of which might > > > make > > > suitable GSoC ideas, and/or be of interest to you (ideally both!) > > >=20 > > > Also, the GSoC wiki page has some project ideas: > > > =C2=A0https://gcc.gnu.org/wiki/SummerOfCode#Selected_Project_Ideas > > >=20 > >=20 > > Yeah I was also searching for interesting ideas on the bugzilla, > > and I will communicate to you once I have any more concrete ideas. >=20 > I spent some time searching through Bugzilla this weekend while > familiarizing with the analyzer internals, and I found the following > things interesting, and it=E2=80=99d be great if you can give me some > preliminary feedback: Great; thanks. >=20 > 1. I am not sure why we added the class > `shift_count_negative_diagnostic` in region-model.cc > , because there is a similar warning issued > from c/c-typeck.cc , and when I compiled with - > fanalyzer that has the code `b =3D b << -1`, I got two warnings that > mean the same thing.=C2=A0 The analyzer works based on execution paths, and so can potentially find more things that a purely AST-based approach. That said, I'm not happy with the signal:noise ratio of that analyzer warning; maybe it needs some tuning? > Maybe interestingly, when I compiled my test case with -O2, I got the > warning from -Wshift-count-negative but not from -Wanalyzer-shift- > count-negative. Would it be considered as a false negative for the > analyzer?=20 The analyzer runs relatively late compared to most analyzers, on the gimple-ssa representation after some optimizations have already run, so that's probably why you didn't get the warning at -O2. >=20 > 2. Something related to 1. is PR98447 > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98447) >=20 > 3. PR104955 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104955) > still takes a long without -Wno-analyzer-double-free. I=E2=80=99d be > interested in further investigating the problem (probably as you said > sharing one feasible_graph can fix the problem). That one involves deep surgery that could affect every analyzer warning, so I'm worried that it could turn out to be too hard to do as a first project on the analyzer. Also, some warnings that have grown a pending_diagnostic::check_valid_fpath_p vfunc since I wrote that comment, which could complicate the implementation :-/ >=20 > 4. What=E2=80=99s the most interesting to me are PR103533 > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103533), Turning on taint detection by default would be a great project. It would be good to run the integration tests: https://github.com/davidmalcolm/gcc-analyzer-integration-tests to see if anything regresses, or if it adds noise - so this might be a bit of an open-ended project, in that we'd want to fix whatever issues show up there, as well as the known ones that are documented in that bug. > PR104940 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104940) I've actually been prototyping SMT solver support in a private branch, but based on writing out SMT-LIB scripts and invoking z3 as a subprocess, and parsing the results, which is much slower than it could be, as I'm reevaluating all the constraints as each one is added, rather than using an API and sharing/pushing/popping state. Taking my SMT prototype and turning it into something usable could be a good project, I think. I'll look at posting what I've got somewhere public if you're interested. > because I focus on formal methods in my university studies, and I=E2=80= =99m > currently looking into Dafny internals for my semester project. >=20 > 5. PR105891 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105891) > seems fitted to get started during the project phase, or be used as a > warm-up before the official project phase. Yeah, but probably would only count as part of full GSoC project. Last year Tim Lange did a highly successful GSoC project on the analyzer which was a grab-bag of adding various new warnings, each of which wasn't quite a full project. Could be a good warmup; though I wonder what would show up when running it on real world C examples (e.g. via my integration test suite). >=20 > 6. PR106147 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106147) > says you are implementing a prototype already, so I guess I=E2=80=99ll le= ave > it out, but I am also quite interested in this analysis.=C2=A0 GCC 13 has the infinite recursion detection, but I didn't get the infinite loop detection ready before feature freeze. If you're interested, I can post my prototype of the latter if you or someone else wants to take it up and finish it. > At a glimpse I am not quite sure why infinite recursion and infinite > loop should be treated differently (maybe it=E2=80=99ll become clearer to= me > once I am more familiar with the internals). In addition, a simple > function that looks like this >=20 > void re (int c) > { > =C2=A0 if (c > 0) > =C2=A0=C2=A0=C2=A0 re (c + 1); > =C2=A0 else > =C2=A0=C2=A0=C2=A0 re (1); > } >=20 > can also be concluded as infinite recursion because there is no base > case in all possible paths. Bother, we don't complain about that yet; so fixing that could be part of a GSoC project, and would be a good fit with the infinite loop idea. FWIW I'm about to commit a fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108935 (assuming it passes testing) so the inf-recursion warning is about to change implementation slightly. >=20 > 7. Other PRs that interest me: PR106006 > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106006)=C2=A0 i.e. RFE: analyzer should treat data from a socket as "tainted"=20 This might work well with the "Turning on taint detection by default" project (PR103533). > and PR107017 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107017, > already mentioned in the GSoC page). i.e. "RFE: support printf-style formatted functions in -fanalyzer" yeah, having someone work on this would be most welcome. Hope this is helpful; I think there are quite a few viable GSoC projects in the above. Thanks Dave