From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53819 invoked by alias); 4 Mar 2019 12:23:55 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 53808 invoked by uid 89); 4 Mar 2019 12:23:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:1742, H*i:sk:CAFiYyc X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Mar 2019 12:23:54 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C353C8535C; Mon, 4 Mar 2019 12:23:52 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-117-64.ams2.redhat.com [10.36.117.64]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6A3185D9CC; Mon, 4 Mar 2019 12:23:52 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x24CNnbL009496; Mon, 4 Mar 2019 13:23:50 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x24CNmTH009495; Mon, 4 Mar 2019 13:23:48 +0100 Date: Mon, 04 Mar 2019 12:23:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: Jeff Law , Patrick Palka , GCC Development Subject: Re: GSoC Project Ideas Message-ID: <20190304122348.GJ7611@tucnak> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00021.txt.bz2 On Mon, Mar 04, 2019 at 01:13:29PM +0100, Richard Biener wrote: > > > * Make TREE_NO_WARNING more fine-grained > > > (inspired by comment #7 of PR74762 [3]) > > > TREE_NO_WARNING is currently used as a catch-all marker that inhibits all > > > warnings related to the marked expression. The problem with this is that > > > if some warning routine sets the flag for its own purpose, > > > then that later may inhibit another unrelated warning from firing, see for > > > example PR74762. Implementing a more fine-grained mechanism for > > > inhibiting particular warnings would eliminate such issues. > > Might be interesting. You'd probably need to discuss the details further. > > I guess an implementation could use TREE_NO_WARNING (or gimple_no_warning_p) > as indicator that there's out-of-bad detail information which could be stored as > a map keyed off either a location or a tree or gimple *. I guess on tree or gimple * is better, there would need to be some hook for copy_node/gimple_copy that would add the info for the new copy as well if the TREE_NO_WARNING or gimple_no_warning_p bit was set. Plus there could be some purging of this on the side information, e.g. once code is handed over from the FE to the middle-end (maybe do that only at free_lang_data time), for any warnings that are FE only there is no need to keep records in the on the side mapping that have info about those FE warnings only, as later on the FE warnings will not be reported anymore. The implementation could be e.g. a hash map from tree/gimple * (pointers) to bitmaps of warning numbers, with some hash table to ensure that the same bitmap is used for all the spots that need to have the same set of warnings disabled. Jakub