basic-block and tree statement iterator enums

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Hi,

  I've been pushing, locally, the compilation of GCC sources with g++.
So far, I've gotten past libiberty, fixincludes, libcpp, the C
front-end specific files, RTL files with no much pain.  However, the
files tree-* and associated headers seem to be the most resolutely C++
unfriendly (I guess I would have to change that judgment when I come
to some files in cp/ ;-)).

  My first attempt this morning met:

/home/gdr/redhat/libcpp.gcc/gcc/tree-cfg.c: In function 'void
bsi_insert_before(block_stmt_iterator*, tree_node*, bsi_iterator_update)':
/home/gdr/redhat/libcpp.gcc/gcc/tree-cfg.c:2935: error: cannot convert
'bsi_iterator_update' to 'tsi_iterator_update' for argument '3' to
'void tsi_link_before(tree_stmt_iterator*, tree_node*, tsi_iterator_update)'

The fragment in question is:

void
bsi_insert_before (block_stmt_iterator *i, tree t, enum bsi_iterator_update m)
{
  set_bb_for_stmt (t, i->bb);
  update_modified_stmts (t);
  tsi_link_before (&i->tsi, t, m);      // <=== HERE
}

Now, tsi_link_before() is declared to take "enum tsi_iterator_update" as
its third argument, so this is really a type violation or at least
looks very suspicious.  Chasing the definitions of both enums, I found

/* (from tree-flow.h)  */
enum bsi_iterator_update
{
  /* Note that these are intentionally in the same order as TSI_FOO. They
     mean exactly the same as their TSI_* counterparts.  */
  BSI_NEW_STMT,
  BSI_SAME_STMT,
  BSI_CHAIN_START,
  BSI_CHAIN_END,
  BSI_CONTINUE_LINKING
};

/* from tree-iterator.h */
enum tsi_iterator_update
{
  TSI_NEW_STMT,         /* Leave the iterator at the same statement. */
  TSI_SAME_STMT,        /* Only valid when single statement is added, move
                           iterator to it.  */
  TSI_CHAIN_START,      /* Only valid when chain of statements is added, move
                           iterator to the first statement in the chain.  */
  TSI_CHAIN_END,        /* Only valid when chain of statements is added, move
                           iterator to the last statement in the chain.  */
  TSI_CONTINUE_LINKING  /* Move iterator to whatever position is suitable for
                           linking other statements/chains of statements in
                           the same direction.  */
};


So, both enums are pretty similar, except for the names (of the type
and constants).  

Is there any particular reason why we cannot have just *one*
"iterator_update" enum, instead of two, and we have to cheat?
This duplication does not look to me like good thing we want to
have.  What am I overlooking?

-- Gaby