tree-cfg: Fix typos on dloop in move_sese_region_to_fn
authorKewen Lin <linkw@linux.ibm.com>
Tue, 3 Aug 2021 03:12:00 +0000 (22:12 -0500)
committerKewen Lin <linkw@linux.ibm.com>
Tue, 3 Aug 2021 03:12:00 +0000 (22:12 -0500)
commitdaaed9e365a2b1371e30f619c7d9f19d1558a01b
tree38032f26950cbb4e2dfa0fe754dfcd7c4832721f
parent724adffe65e1268e8b3f2ab538660020f7572114
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.
gcc/tree-cfg.c