http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46313
--- Comment #11 from janus at gcc dot gnu.org 2010-11-09 17:59:04 UTC ---
(In reply to comment #10)
> > One way to fix this is to use the top-level namespace (i.e. program or
> > module)
> > for the naming of the internal symbols, instead of the direct parent
> > namespace
> > of the derived type (patch below).
>
> Problem: This scheme produces wrong results for the following test case (which
> is similar to comment #0, case c), since the vtabs for both types coincide#:
... which can be fixed by including in the naming scheme the complete namespace
hierarchy (new patch below). This will definitely be unique. Downside: Can
result in long names (although I think it's most common to define derived types
globally in a module or program). Note: Also the hash value must be computed
from this full unique name, not just from the type name.
Index: gcc/fortran/class.c
===================================================================
--- gcc/fortran/class.c (revision 166480)
+++ gcc/fortran/class.c (working copy)
@@ -117,7 +118,19 @@ get_unique_type_string (char *string, gfc_symbol *
if (derived->module)
sprintf (string, "%s_%s", derived->module, derived->name);
else
- sprintf (string, "%s_%s", derived->ns->proc_name->name, derived->name);
+ {
+ gfc_namespace *ns;
+ char tmp[GFC_MAX_SYMBOL_LEN];
+ strcpy (&tmp[0], derived->name);
+ /* Walk namespace hierarchy. */
+ for (ns = derived->ns; ns; ns = ns->parent)
+ {
+ sprintf (string, "%s_%s", ns->proc_name->name, tmp);
+ strcpy (&tmp[0], string);
+ if (!ns->parent)
+ break;
+ }
+ }
}
