From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 78D6F385781B; Wed, 30 Dec 2020 07:43:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 78D6F385781B From: "linkw at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/98464] [11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in tree_nop_conversion_p, at tree.c:12825 by r11-4637 Date: Wed, 30 Dec 2020 07:43:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: linkw at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: linkw at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc 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: Wed, 30 Dec 2020 07:43:47 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98464 Kewen Lin changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |rguenth at gcc dot gnu.org --- Comment #3 from Kewen Lin --- My commit exposed one issue in FRE. The reason why the ICE occurs is that o= ne SSA_NAME used in loop's nb_iterations is actually in free list. (unsigned long) _54 - (unsigned long) v$ptr__25 arg:0 nothrow def_stmt version:54 in-free-list>> I noticed that FRE already has some codes to handle loop's nb_iterations, b= ut there are some inconsistence which cause FRE unable to replace the one in loop's nb_iterations but later replace all uses of _54. When FRE is processing BB 19, it's able to replace _54 with _53 like: [local count: 789698041]: ... if (_26 !=3D v$D4172$_M_impl$D4082$_M_finish$ptr__54) goto ; [89.00%] =3D> [local count: 789698041]: ... if (_26 !=3D __new_finish$ptr__53) goto ; [89.00%] since it calls eliminate_stmt which works with def_bb instead of current bb: sprime =3D eliminate_avail (gimple_bb (SSA_NAME_DEF_STMT (use)), use) while rpo_vn_valueize only works with vn_context_bb. For this particular case, _54's def_bb is BB 13, _53's def_bb is BB 11, it'= s ok for dominated_by_p_w_unex check. While vn_context_bb is BB 19, dominated_by_p_w_unex check returns false for it.=