From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D50D03836C04; Mon, 18 Jan 2021 19:21:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D50D03836C04 From: "jamborm at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/98078] ICE in cgraph_add_edge_to_call_site_hash, at cgraph.c:698 since r6-1705-gd88511aec7338a93 Date: Mon, 18 Jan 2021 19:21:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jamborm at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 19:21:54 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98078 --- Comment #3 from Martin Jambor --- Here is what happens. An IPA-CP clone for a particular devirtualziation context is created but all devirtualziations based on it are speculative. Then the clone is inlined at one of its call sites and the devirtualization turns out to be exactly right. The following goes on in cgraph_edge::set_call_stmt which gets a direct call as the statement. We end up in the update_speculative condition, which calls itself on all the corresponding speculative edges. First at the direct, which then is removed and inserted into the call hash. Then at the indirect, which is not removed from the has because it is not the one in there. At this point, we figure out we have a direct call statement at our hands and so we call make_direct at the edge, which in turn simply resolves the speculation and returns the direct branch, which we store to e. And then we try to add e to call_site_hash, which is already there and the assert condition does not take that possibility into account. (gdb) p/r *slot $42 =3D (cgraph_edge *) 0x7ffff74d6478 (gdb) p/r e $43 =3D (cgraph_edge *) 0x7ffff74d6478 So the simplest fix is probably just adding if (*slot =3D=3D e) return; before the assert.=