From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 8BB2C385780C for ; Fri, 29 Apr 2022 11:11:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8BB2C385780C Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-330-Rprsb3LDMzKueJ3ZhF7BQA-1; Fri, 29 Apr 2022 07:11:37 -0400 X-MC-Unique: Rprsb3LDMzKueJ3ZhF7BQA-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 938463834C00; Fri, 29 Apr 2022 11:11:36 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 547824022EE; Fri, 29 Apr 2022 11:11:36 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 23TBBX0l3151682 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 29 Apr 2022 13:11:33 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 23TBBWh33151681; Fri, 29 Apr 2022 13:11:32 +0200 Date: Fri, 29 Apr 2022 13:11:31 +0200 From: Jakub Jelinek To: Richard Biener Cc: Jeff Law , gcc-patches@gcc.gnu.org, Jan Hubicka Subject: Re: [PATCH] alias: Fix -fcompare-debug issues caused by compare_base_symbol_refs [PR105415] Message-ID: Reply-To: Jakub Jelinek References: <40s7492-n890-1p16-p649-3936sp85qo89@fhfr.qr> <38426n6-341s-9n1-p1p7-r9o03p3847so@fhfr.qr> MIME-Version: 1.0 In-Reply-To: <38426n6-341s-9n1-p1p7-r9o03p3847so@fhfr.qr> X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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, 29 Apr 2022 11:11:40 -0000 On Fri, Apr 29, 2022 at 12:58:12PM +0200, Richard Biener wrote: > So we don't have varpool nodes for the constant pool decls? Are they Depends. DECL_IN_CONSTANT_POOL decls can appear 2 ways, through tree_output_constant_def which does create a varpool node for them and is generally invoked during GIMPLE passes or so, and using output_constant_def, which is called during expansion or later and doesn't have varpool nodes created unless say alias.cc creates those for them. > CONST_DECLs at least? I think that's reasonable though ideally we'd No, they are VAR_DECLs, mostly created as something to refer to in SYMBOL_REFs created for the constant pool constants. varasm.cc (build_constant_desc) creates them. Changing those from VAR_DECLs to CONST_DECLs could be a lot of work. Given that tree_output_constant_def created DECL_IN_CONSTANT_POOL nodes do have varpool nodes, it might be better to do get first, if it returns NULL return 0; for !DECL_IN_CONSTANT_POOL otherwise use x_decl2 = x_decl. > be able to assert that there is a symtab node for the decls ... > > > I'll need to do some extra checking on whether we don't really lose any > > useful debug info with the second patch. > > At least it was surprisingly simple ;) Jakub