:ADDPATCH fortran:
This one is a bit odd. The compilation of the testcase was failing
because the version of the 'box' type that is available to the formal
namespace of 'cmp' when subroutine 'boxarray_sort' calls
'heapsort_box' is different from any other. To begin with, I thought
that the revamped derived type association mechanism was failing.
This turns out not to be the case; in fact it was not being used.
resolve_symbol has a flag 'formal_ns_flag', which when set allows
formal namespaces to be resolved. However, when a formal namespace is
resolved, the flag is reset and this prevents nested formal namepaces
from being resolved. Thus, resolve_derived winds up never seeing the
'box' in 'cmp' and so it never is put on the derived type list.
Removing the flagging mechanism and resolving all formal namespaces
nukes the regression test because nested formal namespaces appear to
be full of partial or broken symbols. Unfortunately, the reasons are
so various that I did not even try to start to fix them - mainly
because I just did not have time but also because the compiler rarely
seems to need these objects resolving. Happily, module.c seems to
populate formal namespaces with symbols that are entirely healthy and
so setting 'formal_ns_flag' to the 'use_assoc' attribute of the
symbol containg the formal namespace fixes the problem.
I have both commented on this in the patch and put a TODO - somebody,
sometime, should remove the flagging mechanism and go through the ICEs
and segfaults one after another to get this properly sorted out.
Bootstrapped and regtested on x86_ia64/fc5 - OK for trunk?
Paul