From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) by sourceware.org (Postfix) with ESMTPS id 8F8E039AD813 for ; Fri, 23 Jul 2021 16:48:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8F8E039AD813 Received: by mail-qt1-x834.google.com with SMTP id k13so2020795qth.10 for ; Fri, 23 Jul 2021 09:48:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YWcTc+Hnw/rKCtCHCbsY6Jpew2VH5uWGFS2DrXu8McI=; b=Ol/1NeSbgBDzlZQMPy9iE3C0csl7GlUro3vDVu39iKE6rNV2nkz9U1I9sHaaUqKIpx 4gC8XvI5vGaZz63FnLGb8tyFKD7ywIbxJg5fAz6FapRJSL1ZGDZJE8OuPpxR+dDD00oi uhDc+gAIAgoIyxC2xSuk9MwapoDpCvnVtDtkqmoyoUmbRWsUwKTaDXOxHzVqwotH9Hj4 SSIeadFKbNtvk8AF4revmqtdz9BT52Spl+fOnE5FoLPv8tlt5ie57SVRIZ9sh3StHHN+ hUWXJB8qz6RDpILI5oS2ezTH3AQlh2cSGxfYedvmFmneKQ7t1A+x2S2jwQNzYw5Xx7ab uNzA== X-Gm-Message-State: AOAM532XSUFK3Qe1N0K5Dyqzwy9S2cQIwA0Uq3r63UeMywfGhqzztdpt p5E5NKR1yGO5tIdeT8p62Te36COpl+o= X-Google-Smtp-Source: ABdhPJxjt9If4Q37HEmCYeY3/uS4raMaQn2kbc79hmQKupPhivXm7DtdkqXZyJOAZCfRNT8GFo3vUQ== X-Received: by 2002:ac8:528f:: with SMTP id s15mr4595745qtn.282.1627058916057; Fri, 23 Jul 2021 09:48:36 -0700 (PDT) Received: from [192.168.0.41] (75-166-102-22.hlrn.qwest.net. [75.166.102.22]) by smtp.gmail.com with ESMTPSA id 82sm11708439qkl.97.2021.07.23.09.48.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Jul 2021 09:48:35 -0700 (PDT) Subject: PING [PATCH] add access warning pass From: Martin Sebor To: gcc-patches References: Message-ID: Date: Fri, 23 Jul 2021 10:48:34 -0600 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 23 Jul 2021 16:48:38 -0000 Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575377.html On 7/15/21 4:39 PM, Martin Sebor wrote: > A number of access warnings as well as their supporting > infrastructure (compute_objsize et al.) are implemented in > builtins.{c,h} where they  (mostly) operate on trees and run > just before RTL expansion. > > This setup may have made sense initially when the warnings were > very simple and didn't perform any CFG analysis, but it's becoming > a liability.  The code has grown both in size and in complexity, > might need to examine the CFG to improve detection, and in some > cases might achieve a better S/R ratio if run earlier.  Running > the warning code on trees is also slower because it doesn't > benefit from the SSA_NAME caching provided by the pointer_query > class.  Finally, having the code there is also an impediment to > maintainability as warnings and builtin expansion are unrelated > to each other and contributors to one area shouldn't need to wade > through unrelated code (similar for patch reviewers). > > The attached change introduces a new warning pass and a couple of > new source and headers and, as the first step, moves the warning > code from builtins.{c,h} there.  To keep the initial changes as > simple as possible the pass only runs a subset of existing > warnings: -Wfree-nonheap-object, -Wmismatched-dealloc, and > -Wmismatched-new-delete.  The others (-Wstringop-overflow and > -Wstringop-overread) still run on the tree representation and > are still invoked from builtins.c or elsewhere. > > The changes have no functional impact either on codegen or on > warnings.  I tested them on x86_64-linux. > > As the next step I plan to change the -Wstringop-overflow and > -Wstringop-overread code to run on the GIMPLE IL in the new pass > instead of on trees in builtins.c. > > Martin > > PS The builtins.c diff produced by git diff was much bigger than > the changes justify.  It seems that the code removal somehow > confused it.  To make review easy I replaced it with a plain > unified diff of builtins.c that doesn't suffer from the problem.