http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51809
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-10
15:49:52 UTC ---
Some debugging. To make it easier, I split the test case into two files and I
look at the one which only consists of "module merry_ICE".
The ICE occurs for writing the .mod file of module merry_ICE. However, the
actual issue already occurs with reading. If one sets a break point in
mio_symbol, one sees that GCC reads the following symbols:
$1 = 0x2aaaacbf01e0 "__vtab_foo_Foo_t"
$2 = 0x2aaaacbf01c8 "__def_init_foo_Foo_t"
$3 = 0x2aaaacbf0258 "__vtab_bar_Bar_t"
$4 = 0x2aaaacbf0240 "__def_init_bar_Bar_t"
The issue is for the PARAMETER "__vtab_bar_Bar_t": its initializer (sym->value)
is a structure constructor consisting of _hash, _size, _extends etc. However,
during read in the _extends gets only a c->expr->symtree == NULL. Thus, during
write out, it crashes in mio_symtree_ref as that tries to access
symtree->n.sym.
If one reverts the order of the USE statements, one first reads the __vtab of
"bar" - again with symtree == NULL - and only then one reads __vtab of "foo".
Seemingly, only if the order is reversed the symtree fixing
(fixup/pointer_info) works.
The main change of the patch in comment 1 is that it changes FL_VARIABLE to
FL_PARAMETER. If one looks at mio_symbol, one sees:
if (sym->attr.flavor == FL_PARAMETER)
mio_expr (&sym->value);
One possibility is to revert the patch of comment 1 - and use the other variant
to set TREE_READONLY: http://gcc.gnu.org/ml/fortran/2011-11/msg00099.html
Alternatively - or additionally [as it can also affect other code] - one should
find out why the symtree is not fixed up.
