From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) by sourceware.org (Postfix) with ESMTPS id 795C03857C48 for ; Sat, 30 Jan 2021 02:56:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 795C03857C48 Received: by mail-qv1-xf34.google.com with SMTP id r13so1085114qvm.11 for ; Fri, 29 Jan 2021 18:56:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hSxGbvNlBzk9zbydPxjGs3tv3Lrg1OckuI4ZFEfVafA=; b=KKO03aKlBtP1obxFNoaaLxunGleRYaj4pVfEikKDfjEzoZamCBXVamMlvKKvZIJ/U1 9ukRlzzb4tqF/4UHCTw7RkAESfaB1AzRuJcByqIky75+KG2vzHxp/uMNOUi2FZ7/+ub3 pjqZULwbDNYSj0Sp5ggiCOfHy0ggEb1EzcJALFr6e5M1PWJOG8TbbLx5xdDmrVDtl/w6 PVvE/SkdXYiKpEPdq3uY5XB4llPCpp0kVxuZBl+Jir02mtlaHeafI2hW7yJdImvZ0ZBm k4XRW2nj2KPkf5SZuKm8y8m4KH0/8Y6crDvwFxrHfoyBXRIV5GqrmxQ2zPsQhJxk7jJM iATw== X-Gm-Message-State: AOAM531je3mz4Hisvluj73dFasn6d/KIb3C128jzZ2KAngraEilI9bGl V1TAPayKLmPPxpGFB17vDHXt8szKoBw= X-Google-Smtp-Source: ABdhPJz1D6v+LR1sZWYuRiW8/wVB4XYIul7W4F5W4x00/UP0c6Eza91rsSKIXHsDHgtSOEud+ubUPg== X-Received: by 2002:a05:6214:b33:: with SMTP id w19mr6446957qvj.35.1611975404892; Fri, 29 Jan 2021 18:56:44 -0800 (PST) Received: from [192.168.0.41] (184-96-239-30.hlrn.qwest.net. [184.96.239.30]) by smtp.gmail.com with ESMTPSA id k12sm7647790qkj.72.2021.01.29.18.56.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Jan 2021 18:56:44 -0800 (PST) From: Martin Sebor Subject: PING [PATCH] improve warning suppression for inlined functions (PR 98465, 98512) To: gcc-patches References: <2e49b6c6-a403-a207-c41e-58f78df96b84@gmail.com> <945093c7-de5e-0350-6030-e4e79ea41161@gmail.com> Message-ID: <6bbc8ff7-8ca4-915b-0f75-a67bed3defd0@gmail.com> Date: Fri, 29 Jan 2021 19:56:42 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <945093c7-de5e-0350-6030-e4e79ea41161@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2021 02:56:46 -0000 Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564060.html On 1/21/21 4:46 PM, Martin Sebor wrote: > The initial patch I posted is missing initialization for a couple > of locals.  I'd noticed it in testing but forgot to add the fix to > the patch before posting it.  I have corrected that in the updated > revision and also added the test case from pr98512, and retested > the whole thing on x86_64-linux. > > On 1/19/21 11:58 AM, Martin Sebor wrote: >> std::string tends to trigger a class of false positive out of bounds >> access warnings for code GCC cannot prove is unreachable because of >> missing aliasing constrains, and that ends up expanded inline into >> user code.  Simply inserting the contents of a constant char array >> does that.  In GCC 10 these false positives are suppressed due to >> -Wno-system-headers, but in GCC 11, to help detect calls rendered >> invalid by user code passing in either incorrect or insufficiently >> constrained arguments, -Wno-system-header no longer has this effect >> on invalid access warnings. >> >> To solve the problem without at least partially reverting the change >> and going back to the GCC 10 way of things for the affected subset >> of calls (just memcpy and memmove), the attached patch enhances >> the #pragma GCC diagnostic machinery to consider not just a single >> location for inlined code but all locations at which an expression >> and its callers are inlined all the way up the stack.  This gives >> each author of a function involved in inlining the ability to >> control a warning issued for the code, not just the user into whose >> code all the calls end up inlined.  To resolve PR 98465, it lets us >> suppress the false positives selectively in std::string rather >> than across the board in GCC. >> >> The solution is to provide a new pair of overloads for warning >> functions that, instead of taking a single location argument, take >> a tree node from which the location(s) are determined.  The tree >> argument is indirect because the diagnostic machinery doesn't (and >> cannot without more intrusive changes) at the moment depend on >> the various tree definitions.  A nice feature of these overloads >> is that they do away with the need for the %K directive (and in >> the future also %G, with another enhancement to accept a gimple* >> argument). >> >> This patch depends on the fix for PR 98664 (already approved but >> not yet checked in).  I've tested it on x86_64-linux. >> >> To avoid fallout I tried to keep the changes to a minimum, and >> so the design isn't as robust as I'd like it ultimately to be. >> I plan to enhance it in stage 1. >> >> Martin >