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

Richard Smith via cfe-commits cfe-commits at lists.llvm.org
Tue May 3 14:26:59 PDT 2016


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.

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/20160503/723e25ee/attachment.html>


More information about the cfe-commits mailing list