From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.20.16]) by sourceware.org (Postfix) with ESMTPS id EC4133858D28 for ; Fri, 24 Mar 2023 13:29:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EC4133858D28 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=ucw.cz Authentication-Results: sourceware.org; spf=none smtp.mailfrom=kam.mff.cuni.cz Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 02EA328A394; Fri, 24 Mar 2023 14:29:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1; t=1679664563; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UHGuDyvVWrUAeQFH0uy7jLsvlmqd5trmAMxiiwBMaGg=; b=G4bWbfijA39oWlWG4GB+/erSPJ8ef72pJmV2HFKAdvB6mXatLB5lhStk4e2TNAVSlBljRy W/h6x1AUPAoDJKm3pSz5NiS1tpD2sGGbL8SQiNQvCFxPy2WQh1j04PgwD04zlexof5HYoA l7QopNoXIEHiP8RYQUGPv7gnx+kIjXk= Date: Fri, 24 Mar 2023 14:29:22 +0100 From: Jan Hubicka To: Martin Jambor Cc: Arsen =?iso-8859-2?Q?Arsenovi=E6?= , GCC Mailing List , Martin Liska Subject: Re: cgraph: does node->inlined_to imply node->clones is non-empty? Message-ID: References: <86bkkwude3.fsf@aarsen.me> <86cz55c15x.fsf@aarsen.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-11.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,GIT_PATCH_0,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, > > It seems to me that the most correct fix is to add to > walk_polymorphic_call_targets a check that the obtained possible target > is still referenced_from_vtable_p() - because the alias that was > originally a virtual function is referenced from a vtable that at this > point is also known to be gone. But the check looks like it is possibly > expensive, so I wanted to discuss this with Honza first (hopefully next > week). External vtables are bit special since they can refer to things that are not accessible in current unit (static functions from other translation units etc). We already have and test can_refer_decl_in_current_unit_p but we test it before alias resolution (which is there just to avoid artifically bumping up the number of possible targets) So perhaps following untested patch would work? diff --git a/gcc/ipa-devirt.cc b/gcc/ipa-devirt.cc index 14cf132c767..b33ec708d47 100644 --- a/gcc/ipa-devirt.cc +++ b/gcc/ipa-devirt.cc @@ -2420,7 +2420,8 @@ maybe_record_node (vec &nodes, alias_target = target_node->ultimate_alias_target (&avail); if (target_node != alias_target && avail >= AVAIL_AVAILABLE - && target_node->get_availability ()) + && target_node->get_availability () + && can_refer_decl_in_current_unit_p (target_node->decl, NULL)) target_node = alias_target; } I am at conference and will be able to test it only during weekend. Honza > > > > > I had already figured that an error could've likely been in > > reach-ability analysis, but my time ran low, and I had not confirmed > > anything, or as little as formalized a theory, so I just wrote the > > original email instead of following this trail of thought fully. > > > > Thank you for your guidance! Have a lovely night :) > > It is good thing that you asked, I also learned something new (that > virtual and non-virtual functions can be ICFed together). > > Martin