This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][C++] Fix PR29433, make C++ use a lot less time/memory


Richard Guenther wrote:
> This patch is the Nth try to attack the problems around 
> classtype_mangled_name and the testcase in PR29433 which happens to
> use 1GB of identifiers:

Nice patch.

As an FYI, mangle_class_name_for_template has nothing to do with
name-mangling, in the usual sense.  It's a misnamed routine.  (I've
vaguely meant to rename for about ten years.)  It's actual job is to
create human-readable names for class template specializations.

Semantically, you should be able to completely remove this routine, and
not see any testsuite failures.  If that were to cause problems, then
we've got something depending on names that shouldn't depend on that at
all.

I bet the only place where we use the value computed is in generating
debugging information, as the name of a class template specialization.
We may also use it when printing error messages, but that machinery can
print template arguments itself, so it should be easy to avoid needing
it just for diagnostics.

So, if you want an even bigger win: arrange to have the debugging
information callback to the front end when it actually needs the pretty
name.  One mechanism would be a hook that is called for all types to
return a name; by default, or if the hooks is NULL, it just returns
DECL_NAME.

However, I think the idea of your patch is fine -- if you ensure that
the error-message machinery doesn't use this value.  The reason I thin
that's important is that if the user does:

template <int I>
void f() {
  ... C<I> ... // error here
}

and gets an error about "C<J>" that's very confusing -- especially if
there's another "J" in scope.  I like the EDG approach of saying "C<#1>
[#1 = I]" in this kind of situation.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]