http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606
--- Comment #7 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-03-21 08:48:38 UTC --- (In reply to comment #6) > (In reply to comment #5) > > What was the motivation for this hashing scheme, BTW? Linkers already > > support > > 1) long symbol names (I read somewhere that OpenOffice has symbols up to > > 4000 > > (!!!) characters long) 2) various symbol hashing schemes (see e.g. > > DT_GNU_HASH). > > I think the idea was to have legible dumps (i.e. avoid hashing everything) but > also to fit them into the various name[GFC_MAX_SYMBOL_LEN] variables which > simply do not take longer names. > > If you think one can/should improve the scheme, feel free to propose something > better. Well, the obvious fix would be to not try cramming mangled identifiers into buffers which are statically sized only to hold unqualified identifiers, no? Essentially, Steven B's proposal in #c1 would fix this as a side-effect. Adding insult to injury, a workaround for this design mistake is enshrined in our ABI.. *sigh*. Grepping for GFC_MAX_SYMBOL_LEN shows 118 occurences, so it would be quite a large patch, but probably quite mechanical for the most part. Steven, are you planning to fix this?
