http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48291
janus at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Last reconfirmed| |2011.03.26 12:10:14 CC| |janus at gcc dot gnu.org AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Summary|internal compiler error, |[OOP] internal compiler |new_symbol(): Symbol name |error, new_symbol(): Symbol |too long |name too long Ever Confirmed|0 |1 --- Comment #5 from janus at gcc dot gnu.org 2011-03-26 12:10:14 UTC --- Thanks for the bug report, Adrian. (In reply to comment #4) > > Thus the inelegant solution would be to define GFC_MAX_SYMBOL_LEN to > > (63*2)+1+strlen("_def_init"). > > This won't happen because it doesn't scale. Right. Changing GFC_MAX_SYMBOL_LEN will definitely not happen. > It's also a known problem. Well, not really. In principle we solve this problem by replacing the derived type name by a hash string if the concatenated name becomes too long (cf. get_unique_hashed_string). However, this does not seem to work in this case (apparently because someone is unable to count properly ;) Here is the fix: Index: gcc/fortran/class.c =================================================================== --- gcc/fortran/class.c (revision 171181) +++ gcc/fortran/class.c (working copy) @@ -139,7 +139,7 @@ get_unique_hashed_string (char *string, gfc_symbol get_unique_type_string (&tmp[0], derived); /* If string is too long, use hash value in hex representation (allow for extra decoration, cf. gfc_build_class_symbol)*/ - if (strlen (tmp) > GFC_MAX_SYMBOL_LEN - 10) + if (strlen (tmp) > GFC_MAX_SYMBOL_LEN - 11) { int h = gfc_hash_value (derived); sprintf (string, "%X", h); With this patch, the test case gives me: call setNote(self, 'AnException', exception) 1 Error: There is no specific subroutine for the generic 'setnote' at (1)