[Bug fortran/51809] [4.7 Regression][OOP] ICE (segfault) depending on USE statements order

["burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.