From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 237D1388C00A; Mon, 4 Jan 2021 15:58:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 237D1388C00A From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/98514] New: ICE in insert_operand_rank Date: Mon, 04 Jan 2021 15:58:20 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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, 04 Jan 2021 15:58:21 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98514 Bug ID: 98514 Summary: ICE in insert_operand_rank Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- When building gmic on i686-linux (or other 32-bit arches) with LTO, one get= s: gmic.cpp: In member function '_run.isra': gmic.cpp:4981:7: internal compiler error: in insert_operand_rank, at tree-ssa-reassoc.c:367 4981 | gmic& gmic::_run(const CImgList& commands_line, unsigned int& position, | ^ It is in 101th partition and the function is huge, so am not going to reduc= e, but it seems a general reassoc issue on 32-bit hosts. The function in question has 104549 SSA_NAMEs and 36954 basic blocks. Now, the bb ranks are computed as: /* Give each default definition a distinct rank. This includes parameters and the static chain. Walk backwards over all SSA names so that we get proper rank ordering according to tree_swap_operands_p. */ for (i =3D num_ssa_names - 1; i > 0; --i) { tree name =3D ssa_name (i); if (name && SSA_NAME_IS_DEFAULT_DEF (name)) insert_operand_rank (name, ++rank); } /* Set up rank for each BB */ for (i =3D 0; i < n_basic_blocks_for_fn (cfun) - NUM_FIXED_BLOCKS; i++) bb_rank[bbs[i]] =3D ++rank << 16; and bb_rank as well as everything else that deals with ranks is long, so obviously it can't work properly in any function which has more than 32767 (num_ssa_names + n_basic_blocks_for_fn (cfun)). Either we should punt on trying to reassociate such functions, but that wou= ld make 32-bit hosts behave differently from 64-bit hosts even when targeting = the same target, or my preferred way out of this is make the ranks just HOST_WIDE_INTs, yes, it will need more memory on 32-bit hosts and will be slightly slower, but it will be consistent with 64-bit hosts. We have vect= ors of ssa names and basic blocks and those have int length, so even on 64-bit hosts we can't support more than 4 billion ssa names and more than 4 billion basic blocks.=