------- Comment #2 from pault at gcc dot gnu dot org 2008-06-05 19:45 -------
> At the moment, I cannot see what draws these together. Nor can I see any
> difference in the .mod files for the cases that work....
Ah... go it! gcc-4.2 had a derived type list for each namespace and care was
taken to apply the same backend_decl to each like derived type in all
namespaces, including formal namespaces. gcc-4.3 onwards uses a single list,
generate in resolve.c. This was failing to check derived type components, with
the result that they could be missed in formal namespaces.
This fixes the problem:
Index: gcc/fortran/resolve.c
===================================================================
*** gcc/fortran/resolve.c (revision 136412)
--- gcc/fortran/resolve.c (working copy)
*************** resolve_fl_derived (gfc_symbol *sym)
*** 7637,7642 ****
--- 7637,7647 ----
return FAILURE;
}
+ /* Ensure that all the derived type components are put on the
+ derived type list; even in formal namespaces. */
+ if (c->ts.type == BT_DERIVED && c->ts.derived)
+ resolve_fl_derived (c->ts.derived);
+
if (c->pointer || c->allocatable || c->as == NULL)
continue;
It's mine! If it regtests OK, I'll apply it as obvious.
Paul
--
pault at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2008-05-29 12:05:35 |2008-06-05 19:45:48
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36366
