This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Tree Versioning Question


Hello,
I am using cgraph_function_versioning() to create a duplicate
function, e.g. a clone.  This usually has worked well for me in the
past, but I have run into an interesting case where the
tree_function_versioning() code is performing a split_edge() on the
successor of the entry basic block.  What I am left with is a gimple
dump of:

go.foo_package.NewThing2.cloned.0 ()
{
  struct T * D.562;
  struct T * $ret1;
  struct T * t;

<bb 4>:

<bb 2>:
  $ret1_1 = 0B;
  t_2 = __go_new (16);
  foo_package.NewMember.pN16_go.foo_package.T (t_2);
  foo_package.setID (t_2, 1);
  $ret1_3 = t_2;
  D.562_4 = $ret1_3;

<L0>:
  return D.562_4;

}

The code is just a test routine I am using for testing how my plugin
for region-based memory handles packages.  Anyways, the important part
(I think) is that <bb 4> is the result of the split_edge call
mentioned earlier when I clone NewThing2, and that BB is just empty, a
fall-thru.  When the gimple_cfg_expand() pass kicks-in
find_bb_boundaries() is called in find_many_sub_basic_blocks() and <bb
5>'s loop father is referenced.  Well, that loop_father instance is
NULL.  And gcc is dying in add_bb_to_loop().  I think I can avoid this
if I were to remove <bb 4>  But I am not entirely sure.  I am not even
sure why BB5 is even created as 0 is the Entry and 1 is the exit
block.  I am running gcc 4.7.1 and am a bit lost as to what to do.

-Matt


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]