From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105477 invoked by alias); 29 Jul 2019 16:03:56 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 105467 invoked by uid 89); 29 Jul 2019 16:03:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=fes, H*Ad:U*law, circumstance, spots 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, 29 Jul 2019 16:03:54 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AE32F7F770; Mon, 29 Jul 2019 16:03:53 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-108.ams2.redhat.com [10.36.116.108]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 39C4019C58; Mon, 29 Jul 2019 16:03:53 +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 x6TG3oG2031630; Mon, 29 Jul 2019 18:03:51 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x6TG3mAO031629; Mon, 29 Jul 2019 18:03:48 +0200 Date: Mon, 29 Jul 2019 16:10:00 -0000 From: Jakub Jelinek To: Martin Sebor Cc: Jeff Law , JiangNing OS , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization Message-ID: <20190729160348.GD15878@tucnak> Reply-To: Jakub Jelinek References: <187485ec-9c48-735e-54da-8b0820372fe2@redhat.com> <0f07b57e-9def-2758-c58b-ec9200fa4432@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0f07b57e-9def-2758-c58b-ec9200fa4432@gmail.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg01738.txt.bz2 On Wed, Jul 24, 2019 at 12:07:36PM -0600, Martin Sebor wrote: > > > There are a number of existing instances of setting TREE_NO_WARNING > > > to suppress -Wuninitialized, and some are the cause of known problems. > > > Bugs 51545, 58950, 74762, 74765 or 89697 are examples.  They all boil > > > down to the fact that there's just one bit for all warnings.  Jakub > > > mentioned adding a hash-map for this.  That seems like a simple and > > > good solution. > > I'm not sure how that really helps here. We marking the MEM on the LHS > > and that's not a shared object. I don't see how it's going to be > > significantly different using a hash map vs the bit in this circumstance. > > I don't know what Jakub had in mind but the mapping I envision is > one like hash_map that would make it possible to set > a bit for each distinct warning for every tree node. It would let > us set a bit for -Wuninitialized while leaving the bit for > -Warray-bounds (and all other warnings) clear. I had in mind something like a hash_map / hash_map (or just make it a ) where possibly the bitmaps would be shared, so have a hash table in which one would look up existing bitmaps containing particular sets of warnings and if not create a new one (and where the bitmaps would be const after creation). The TREE_NO_WARNING or gimple_no_warning bits would be a flag that one should look up the hash_map if needed, those bits clear would imply empty bitmap. Routines that copy trees or gimple stmts, like copy_node or gimple_copy would take care of adding the new tree/gimple * into the hash_map if needed too. And, because we have a lot of warnings that are only emitted in the FEs, or say before IPA and not afterwards, we could also have spots where we'd replace the bitmaps with ones that don't have any of the no longer interesting warning bits. Say during gimplification we could drop TREE_NO_WARNING bit or not set gimple_no_warning if the bitmap only contains FE warning bits, or (perhaps more questionable whether worth it) replace with a const_bitmap that doesn't have those). Jakub