From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2063) id ABE2D3851C3D; Tue, 3 Aug 2021 03:13:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ABE2D3851C3D MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" From: Kewen Lin To: gcc-cvs@gcc.gnu.org Subject: [gcc r12-2680] tree-cfg: Fix typos on dloop in move_sese_region_to_fn X-Act-Checkin: gcc X-Git-Author: Kewen Lin X-Git-Refname: refs/heads/master X-Git-Oldrev: 724adffe65e1268e8b3f2ab538660020f7572114 X-Git-Newrev: daaed9e365a2b1371e30f619c7d9f19d1558a01b Message-Id: <20210803031335.ABE2D3851C3D@sourceware.org> Date: Tue, 3 Aug 2021 03:13:35 +0000 (GMT) X-BeenThere: gcc-cvs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-cvs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 03:13:35 -0000 https://gcc.gnu.org/g:daaed9e365a2b1371e30f619c7d9f19d1558a01b commit r12-2680-gdaaed9e365a2b1371e30f619c7d9f19d1558a01b Author: Kewen Lin Date: Mon Aug 2 22:12:00 2021 -0500 tree-cfg: Fix typos on dloop in move_sese_region_to_fn As mentioned in [1], there is one pre-existing issue before the refactoring of FOR_EACH_LOOP_FN. The macro will always set the given LOOP as NULL at the end of iterating unless there is some early break inside, obviously there is no early break and dloop will be set as NULL after the loop iterating. It's kept as NULL after the factoring. I tried to debug the test case gcc.dg/graphite/pr83359.c with commit 555758de90074 (also reproduced the ICE with 555758de90074~), and noticed the compilation of the test case only covers the hunk: else { moved_orig_loop_num[dloop->orig_loop_num] = -1; dloop->orig_loop_num = 0; } it doesn't touch the if condition hunk to increase "moved_orig_loop_num[dloop->orig_loop_num]". So the following hunk guarded with if (moved_orig_loop_num[orig_loop_num] == 2) using dloop for dereference doesn't get executed. It explains why the problem doesn't get exposed before. By looking to the code using dloop, I think it's a copy paste typo, the modified assertion codes have the same words as the above condition check. In that context, the expected original number has been assigned to variable orig_loop_num by extracting from the arg0 of the call IFN_LOOP_DIST_ALIAS. [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576367.html gcc/ChangeLog: * tree-cfg.c (move_sese_region_to_fn): Fix typos on dloop. Diff: --- gcc/tree-cfg.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c index 48ee8c011ab..9883eaaa9bf 100644 --- a/gcc/tree-cfg.c +++ b/gcc/tree-cfg.c @@ -7747,9 +7747,8 @@ move_sese_region_to_fn (struct function *dest_cfun, basic_block entry_bb, /* Fix up orig_loop_num. If the block referenced in it has been moved to dest_cfun, update orig_loop_num field, otherwise clear it. */ - class loop *dloop = NULL; signed char *moved_orig_loop_num = NULL; - for (class loop *dloop : loops_list (dest_cfun, 0)) + for (auto dloop : loops_list (dest_cfun, 0)) if (dloop->orig_loop_num) { if (moved_orig_loop_num == NULL) @@ -7787,11 +7786,10 @@ move_sese_region_to_fn (struct function *dest_cfun, basic_block entry_bb, /* If we have moved both loops with this orig_loop_num into dest_cfun and the LOOP_DIST_ALIAS call is being moved there too, update the first argument. */ - gcc_assert ((*larray)[dloop->orig_loop_num] != NULL - && (get_loop (saved_cfun, dloop->orig_loop_num) - == NULL)); + gcc_assert ((*larray)[orig_loop_num] != NULL + && (get_loop (saved_cfun, orig_loop_num) == NULL)); tree t = build_int_cst (integer_type_node, - (*larray)[dloop->orig_loop_num]->num); + (*larray)[orig_loop_num]->num); gimple_call_set_arg (g, 0, t); update_stmt (g); /* Make sure the following loop will not update it. */