From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rguenther@suse.de>
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29])
 by sourceware.org (Postfix) with ESMTPS id 42823385735D
 for <gcc-patches@gcc.gnu.org>; Fri, 29 Apr 2022 11:23:47 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 42823385735D
Received: from relay2.suse.de (relay2.suse.de [149.44.160.134])
 by smtp-out2.suse.de (Postfix) with ESMTP id 6B9671F37F;
 Fri, 29 Apr 2022 11:23:46 +0000 (UTC)
Received: from murzim.suse.de (murzim.suse.de [10.160.4.192])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by relay2.suse.de (Postfix) with ESMTPS id 6424A2C141;
 Fri, 29 Apr 2022 11:23:46 +0000 (UTC)
Date: Fri, 29 Apr 2022 13:23:46 +0200 (CEST)
From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
cc: gcc-patches@gcc.gnu.org, Jan Hubicka <hubicka@ucw.cz>
Subject: Re: [PATCH] alias: Fix -fcompare-debug issues caused by
 compare_base_symbol_refs [PR105415]
In-Reply-To: <YmvKY1opDRHtzBMx@tucnak>
Message-ID: <69323snq-6417-5rp5-4qs3-o8998p32pq5r@fhfr.qr>
References: <YmuqXtJnV/ntWjPs@tucnak>
 <40s7492-n890-1p16-p649-3936sp85qo89@fhfr.qr> <YmuyKmXtrvJRAu8e@tucnak>
 <s119s3pq-n22q-r8rr-744r-97os1rq934rq@fhfr.qr> <YmvANHX2XbA41VPf@tucnak>
 <38426n6-341s-9n1-p1p7-r9o03p3847so@fhfr.qr> <YmvH41yur7C6e6//@tucnak>
 <YmvKY1opDRHtzBMx@tucnak>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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 <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2022 11:23:48 -0000

On Fri, 29 Apr 2022, Jakub Jelinek wrote:

> On Fri, Apr 29, 2022 at 01:11:31PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > 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.
> 
> Oh, and one thing I forgot.  The constant pool decls can be put into section
> anchors, so it is essential that we handle DECL_IN_CONSTANT_POOL decls
> there and don't just punt on those.

Ah, OK - that makes sense (maybe we should create varpool nodes at the
point we associate them with anchors, or alternatively use the varpool
node of the anchor?).

Richard.