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]

Re: [PATCH] Remove gratuitous demangler differences


>>>>> "Daniel" == Daniel Berlin <dberlin@redhat.com> writes:

> On 11 Feb 2001, Jason Merrill wrote:

>> >>>>> "Gabriel" == Gabriel Dos Reis <gdr@codesourcery.com> writes:
>> 
>> > If your change is mandated by the ABI (that wasn't clear from your
>> > original message) then it is fine
>> 
>> It isn't.  The ABI makes no attempt to mandate the output of the demangler.

> However, the ABI does, as I pointed out say j is "unsigned int", not
> "unsigned", and v is "void", not "void unless the parameter list is
> empty".

Yes.  But IMO that should not be taken to indicate anything about the
committee's intent.  In fact, Alex Samuel, who wrote the new demangler,
also wrote most of the ABI mangling document.

>> Daniel's changes are intended to make the new demangler output look like
>> the old demangler output.  This seems reasonable to me, though another way
>> to handle this would be to fix the GDB tests to match the new demangler.

> I don't believe it's just GDB that expects this.

Is anyone aware of another example?

> But, regardless, this is *not* a simple task. You really have to come up
> with new regular expressions just to match the output, because it's not
> just whitespace differences (which would be relatively easy to handle).

> A compromise would be to make it output "unsigned int" for j, and "void"
> always for v. Then you'd only be left with whitespace differences.

I can certainly imagine that 'unsigned int' would be easier to catch using
regexps, avoiding confusion with other unsigned types, so this change makes
sense to me (for C++STYLE as well as the demangler).

'void' doesn't seem as clear, though.  grepping for '()' seems just as easy
as grepping for '(void)', and more accurate than grepping for just 'void'.

> Or, i'll happily make it DMGL_GDB or DMGL_COMPAT or something of the sort.

I'm opposed to this.

Jason


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