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
