------- 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