From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0A9643945064; Fri, 20 Mar 2020 02:56:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0A9643945064 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1584672992; bh=zmVmNUu3y6BCJZH+Fgi/ZhuBZkTx8JzQW7rvdbTHqTQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mh/KUr/jCOe2HImQoZgueW/prbX8gc6Z53HLn+LZNcQKPg9mDeUGjtXgBxzsED0SK pgpji3eotYL1Y6sFW5gZdxjD99ZyAKRGBM9O8zCY/HsCkTiWItN2CDC45NW7YuRCtc 8TYkuCncTnBUCIenQVEkJCZEVQOlwPCTvUyZHGNA= From: "linkw at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/94043] [9/10 Regression] ICE in superloop_at_depth, at cfgloop.c:78 Date: Fri, 20 Mar 2020 02:56:31 +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: 10.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: 9.4 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: Fri, 20 Mar 2020 02:56:32 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94043 --- Comment #4 from Kewen Lin --- This was just exposed from my commit, it can also be reproduced without my commit but with -fno-vect-cost-model. Some loops we have for this case: ;; Loop 1 ;; header 3, latch 10 ;; depth 1, outer 0 ;; nodes: 3 10 8 23 25 34 35 26 29 32 33 38 4 11 37 31 ;; Loop 2 ;; header 4, latch 11 ;; depth 2, outer 1 ;; nodes: 4 11 ;; Loop 4 ;; header 26, latch 29 ;; depth 2, outer 1 ;; nodes: 26 29 When we are doing versioning for loop4 required for aliasing check, the rel= ated scalar_loop_iters is based on e2.2_31, which is defined in BB 4, that is: [local count: 4343773762]: # e2.2_31 =3D PHI <_15(11), 1(37)> # ivtmp_14 =3D PHI For the codes: if ((def_bb =3D gimple_bb (SSA_NAME_DEF_STMT (USE_FROM_PTR (use_p))= )) && flow_bb_inside_loop_p (outermost, def_bb)) outermost =3D superloop_at_depth (loop, bb_loop_depth (def_bb) + = 1) bb_loop_depth is 2, the +1 make the assertion in superloop_at_depth fail si= nce the current loop 4 only has the depth 2. I think the existing code has the assumption that all operands in stmts of cond_expr_stmt_list are defined in some outer loop of current, but the assumption breaks in this case. I guess the current scalar_loop_iters is valid? Then the fix can be: --- a/gcc/tree-vect-loop-manip.c +++ b/gcc/tree-vect-loop-manip.c @@ -3312,7 +3312,13 @@ vect_loop_versioning (loop_vec_info loop_vinfo, FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, SSA_OP_USE) if ((def_bb =3D gimple_bb (SSA_NAME_DEF_STMT (USE_FROM_PTR (use_p))= )) && flow_bb_inside_loop_p (outermost, def_bb)) - outermost =3D superloop_at_depth (loop, loop_depth (outermost) + = 1); + { + /* Def block can be in either one outer loop of loop_to_version= or + one sibling of outer loop of loop_to_version. */ + class loop *common_loop + =3D find_common_loop (def_bb->loop_father, loop); + outermost =3D superloop_at_depth (loop, loop_depth (common_loop= ) + 1); + } }=