From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by sourceware.org (Postfix) with ESMTPS id 6890D3858CD1 for ; Mon, 31 Jul 2023 12:19:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6890D3858CD1 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-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-267fcd6985cso3076558a91.2 for ; Mon, 31 Jul 2023 05:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690805982; x=1691410782; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=JMAeoXkQMx3Xk7G/rTUZ4FV7IysiXNIKrlibtvj/bBc=; b=dvBdBLJdhriLsuocWgPapWZnP46ARxSiQfqWR0HuR9csOq+0oQLh2cWd/S8fmWVa0T /5lAuobWh+szvLJCoEBdY9aezehWwTbW8AgGgaYB5nYG9YhxerVzV27nMcp7LMkXUkTt Sm3xdyct43uf1ZGDLZ937+1/rPa65NOtaKofozyE76aZgA8IEsCxb0RkM6Tj2FFcjGai UW0g/5ovJuoJXstGcr3K5GVIudq8he9vK9Qrpp/05YJkPmfeNZGS9b2FMj1k6iWv+tUG h3Y2Hb7KzeezIDJ66d1Y9L8stQR89gO5ByhZOdWt0pQBHqm1IS2L2t4l9DkgOZK+nR/V km0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690805982; x=1691410782; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=JMAeoXkQMx3Xk7G/rTUZ4FV7IysiXNIKrlibtvj/bBc=; b=Aq9/FhQ9VM7H2EpwDB0kB4oNVsY++uxCgjwNQwp6BzV8ZREuQ2sUBAciJhhcrVd7LU vwUeo3xRRMgzY3SqTgR4uMu9HduGvxIDQdpP18B3fNRjgb7iHNHdKrR4Lwx8iTEjJl9H RcudB6+GLxylj0H302NA2/X0DBvFL13+A4hbkuwuzJ7cKwCg2GhMsWqjDMvQNWkkXasq hfpYv3yYCt39UZtEgWchEa6XNCSGjoDSTyOhTSmMb4nJSZZdCgQg+5EmiECqO6urVFmF s1/fFXyy8hbMPWhDRB5mrRSh/dMNdjDMmGVR93d6swD6U1Ioxcfg/Ra6F9mO0XOha1nT Yiqw== X-Gm-Message-State: ABy/qLYx56SRQxvYKe6+K3uGR9moDudGF3aHtuSPxwkVf1+0gQvjSbHI RgR5tWujP2qVRU9VYDocF87tTpvSBywfrAe3fw== X-Google-Smtp-Source: APBJJlFdS+EwVzOcQv8VIcK2aLBRqY5uCNfGn5Y+ei5bxKYpRoVFoGJ5AB4Y4n4ZSZso4+vZPQ0U/ueGnELimNZfLd0= X-Received: by 2002:a17:90a:17a5:b0:268:ac3:b1f6 with SMTP id q34-20020a17090a17a500b002680ac3b1f6mr8532821pja.24.1690805981869; Mon, 31 Jul 2023 05:19:41 -0700 (PDT) MIME-Version: 1.0 From: Benjamin Priour Date: Mon, 31 Jul 2023 14:19:30 +0200 Message-ID: Subject: analyzer: Weekly update and questions on extending c++ support. To: David Malcolm Cc: gcc@gcc.gnu.org Content-Type: multipart/alternative; boundary="000000000000eef8ed0601c7715b" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: --000000000000eef8ed0601c7715b Content-Type: text/plain; charset="UTF-8" Hi David, (subject's line totally stolen inspired from Eric's) Last week as you know had some special circumstances therefore not much has been done. I've changed my in-progress patch about trimming the system headers event to fit your suggestions from https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625245.html. I had suggested that we keep events (1) (2) (11) and (12) in the reproducer https://godbolt.org/z/sb9dM9Gqa but after comparing it to your first suggestion of only keeping (11), I don't know which one to keep. Just (11) has the benefit of being really concise and verbose enough in this case, mimicking the behavior of a raw pointer. However having the call site and return site might be helpful for the user, e.g. to understand what template arguments were deduced. I think we could still have events (11) and (12): what if for call and > return events we consider the location of both the call site and the > called function: we suppress if both are in a system header, but don't > suppress if only one is a system header. That way by default we'd show > the call into a system header and show the return from the system > header, but we'd suppress all the implementation details within the > system header. > > Does that seem like it could work? It works and is one the two implementations I have. Now we just have to decide which is better, and I'll submit the patch to the mail list. Some updates too on the added support of placement new What do you think of "null-dereference" superceding "use-of-unitialized-value" ? Both can occur at the same statement (see https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625844.html) If you think adding this supercedes_p to null-deref is acceptable, then I'll fix PR 110830 before submitting the placement new patch. Otherwise, I've been working on what we talked about last time, i.e. moving the tests under gcc.dg/analyzer to c-c++-common/analyzer. It is still in progress (about 100 tests done out of 700+). A question on that front: What is the purpose of test gcc.dg/analyzer/data-model-11.c ? int test (void) { unsigned char *s = (unsigned char *) "abc"; char *t = "xyz"; return s[1] + t[1]; } Are the non-constness of the strings being tested or only their sign ? Thanks Benjamin. --000000000000eef8ed0601c7715b--