Re: gfortran tree walking issue

[Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>]

Dear Tobias,

I am very hard pressed right now, trying to complete the class array
work and to go through Mikael's patches for approval.

Maybe we should decide a priority order?  Your patch and those of
Mikael could cause regressions other than in code involving OOP.  I
would suggest, therefore, that we should find a fix for your problem
below and get these patches committed first.  I will still try to get
mine completed before the end of Stage 1 but it will not matter as
much if I am a week or so late.

Cheers

Paul

On Tue, Nov 1, 2011 at 2:13 AM, Tobias Burnus <burnus@net-b.de> wrote:
> 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
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
? ? ?? --Hitchhikers Guide to the Galaxy