[Patch, fortran] PR28788 - derived type regressions

[THOMAS Paul Richard 169137]

:ADDPATCH fortran:

Martins,

You have both reported regressions that result from my patch to reform
derived type association.

PR28788 came about because gfc_use_derived was modifying the derived
type symbol and changing the references in the symbol symtree to suit
but not doing the same for the references in formal namespaces.  In
consequence, this latter goup were left hanging and the observed ICE
followed.

The fix is easy: in switch_types, a check is made to see if a symbol
has a non-NULL formal_ns field.  If it does, switch_types is called
for this subsidiary namespace.  The reporter's test has been added to
the testsuite.

Martin Tee's problem comes about because the same derived type in
sibling namespaces, where there is no host association, were not being
associated and so trans-types.c was creating different structures for
them.  Then, if assignments were made from one to the other, convert_fold
would fail and the observed ICE would occur.

The fix for this is a bit more complicated than that for PR28788, although
the principle is straightforward.  If a fixup does not succeed in the
parent namespace, a search is made for the derived type in sibling
namespaces.  If found, the treatment is the same as for a derived type
found in the parent namespace.  Similarly, a last ditch attempt is made to
look for renamed but identical derived types in sibling namespaces.  As with
renamed parent namespace symbols, the references are all reset the found
symbol but the symtree and its symbol in the current namespace are left
alone, to be cleaned up at the end of the compilation.  The reason for this
is that there can, in principle, be other references to the renamed symbol,
from other symtree entries. I have modified Erik Edelmann's test
derived_init_2.f90 to use modules and to check the fix of this regression.
If it is preferred that I separate the tests, this is easily accomplished.

I note that I did not add the cleanup of the .mod files at the end of the
tests used_types_[23].f90; this has been remedied.

The patch regtests OK on Cygwin_NT/PIV - I intend to apply the patch to
trunk and 4.1 tomorrow morning (CET), unless there are any objections.

Paul 

2006-08-23  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/28788
	* symbol.c (shift_types): Shift the derived type references in
	formal namespaces.
	(gfc_use_derived): Return if the derived type symbol is already
	in another namspace.  Add searches for the derived type in
	sibling namespaces.

2006-08-23  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/28788
	* gfortran.dg/used_types_4.f90: New test.
	* gfortran.dg/derived_init_2.f90: Modify to check sibling
	association of derived types.
	* gfortran.dg/used_types_2.f90: Add module cleanup.
	* gfortran.dg/used_types_3.f90: The same.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr28788.diff
Type: application/octet-stream
Size: 3334 bytes
Desc: pr28788.diff
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20060823/39ac843d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: used_types_4.f90
Type: application/octet-stream
Size: 1131 bytes
Desc: used_types_4.f90
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20060823/39ac843d/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: derived_init_2.f90
Type: application/octet-stream
Size: 1220 bytes
Desc: derived_init_2.f90
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20060823/39ac843d/attachment-0002.obj>