[Bug fortran/46313] [OOP] class container naming collisions

[janus at gcc dot gnu.org]

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;
+       }
+    }
 }