gfortran tree walking issue

[Tobias Burnus]

Tobias Burnus wrote:
> While the patch should have no major regressions nor missing features, 
> it is not yet regression free. Currently known issues (see link above 
> for details):
> - gfortran.dg/class_21.f03: ICE on valid code.

This issue turned out to be independent of my patch. The problem is that
    gfc_traverse_ns (ns, resolve_symbol);
assumes that the symtree-tree starting at "ns->sym_root" remains 
unchanged. However, that's not the case. The generation of vtables via 
gfc_find_derived_vtab will cause new elements to be added - and that can 
cause a rebalancing of the the tree.

Result: One does not walk all elements of the symtree - which causes in 
my case an ICE.

For class_21.f03's resolve_symbol the effect is dramatic: only the 
symbols t, __class_m_T_p, __def_init_m_T, and __vtab_m_T are resolved, 
while __vtype_m_T (new!), default_t (the one causing problems), m, null, 
and t are not resolved. (Twice t: once for BT_DERIVED and once for 
attr.generic.)


I tried a brute-force approach by going multiple times through the list 
to ensure that every item gets really gets touched once. However, that 
ends up in an endless loop at:

compile_file () at /home/tob/projects/gcc-trunk-checkout/gcc/toplev.c:567
581       lang_hooks.decls.final_write_globals ();

which is gfc_write_global_declarations() in f95-lang.c; that get's 
somehow trapped in varpool_finalize_decl/htab_find_slot_with_hash.


The endless loop is vanishes if one adds to gfc_create_module_variable a 
"if (sym->attr.vtab) return;" - but that has the side effect that one 
does not create any __m_MOD___vtab_m_T, which causes a link-time failure.

Any ideas how to solve this?

Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: treewalk.diff
Type: text/x-patch
Size: 2921 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20111101/639de401/attachment.bin>