[PATCH] D18035: [GCC] PR23529 Mangler part of attrbute abi_tag support

[Dmitry Polukhin via cfe-commits]

On Wed, May 4, 2016 at 12:26 AM, Richard Smith <richard at metafoo.co.uk>
wrote:

> On Tue, May 3, 2016 at 12:51 PM, Dmitry Polukhin via cfe-commits <
> cfe-commits at lists.llvm.org> wrote:
>
>> DmitryPolukhin added a comment.
>>
>> Richard, could you please share your counterexample so I could test it on
>> my patch and GCC?
>>
>
> Sure:
>
>   struct __attribute__((abi_tag("X"))) Foo {};
>   void __attribute__((abi_tag("X"))) f(Foo) {}
>
> This should not generate an ABI tag for 'f', because there's one implied
> by the first parameter type. But as far as I can see, this patch doesn't
> look at the parameter types at all until after it's already streamed out
> the mangling for the function name.
>

In this example ABI tag X is explicit tag for function 'f' so it must be
always emitted. Moreover even implicit tag case handled correctly i.e. no
implicit tag for function if the tag is already used in function
parameters. Here is my example and both GCC and Clang with my patch gives
identical mangling:

struct __attribute__((abi_tag("X"))) Foo {};

// _Z1fB1X3FooB1X pretty printed 'f[abi:X](Foo[abi:X])'
void __attribute__((abi_tag("X"))) f(Foo) {}

// _Z2f13FooB1X pretty printed 'f1(Foo[abi:X])'
Foo f1(Foo) {}

As for not looking for function arguments before emitting function name.
Please take a look to makeAdditionalTagsForFunction that handles this case.
It calls getTagsFromPrefixAndTemplateArguments also takes into account
function parameters (it disables implicit tags from return type and mangles
function declaration).

I think a reasonable way to deal with this is:
>
> 1) Collect the ABI tags for the overall entity. Whenever we subsequently
> emit an ABI tag (or emit an inline namespace and suppress emitting its ABI
> tags), remove that tag from our list of ABI tags for the overall entity (if
> it's there).
> 2) Mangle up to and including the name of the entity. If there are any ABI
> tags left for the entity, do subsequent mangling into a temporary buffer
> instead of directly into the output stream.
> 3) Mangle the rest of the declaration.
> 4) If there are any ABI tags left for the overall entity, and we have not
> already mangled the return type, then mangle it to a scratch buffer (which
> we'll throw away).
> 5) If we mangled to a temporary buffer, emit any remaining ABI tags now
> followed by the contents of the temporary buffer.
>
> As for separate pass, it was my first reaction on the original patch from
>> Stefan but soon I realized that I'll have to copy parts of magnler to some
>> simplified mangler but with high probability of forgetting something and
>> with code duplication. So now I think approach which runs full mangler in
>> special mode is better and less error prone.
>>
>>
>> http://reviews.llvm.org/D18035
>>
>>
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160504/4d0fe99c/attachment.html>