<div dir="ltr"><div dir="ltr">On Mon, 3 May 2021 at 10:36, Nathan Sidwell via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/3/21 12:42 PM, David Blaikie via cfe-dev wrote:<br>
> <br>
> <br>
> On Mon, May 3, 2021 at 4:10 AM Nathan Sidwell via cfe-dev <br>
> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> <mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>> wrote:<br>
> <br>
> On 4/30/21 1:52 PM, Fāng-ruì Sòng via cfe-dev wrote:<br>
> > Redirect to cfe-dev.<br>
> ><br>
> > On Fri, Apr 30, 2021 at 9:42 AM Xun Li via llvm-dev<br>
> > <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>> wrote:<br>
> >><br>
> >> Hi,<br>
> >><br>
> >> I noticed that when compiling lambda functions, the generated<br>
> function<br>
> >> names use different conventions than GCC.<br>
> >> Example: <a href="https://godbolt.org/z/5qvqKqEe6" rel="noreferrer" target="_blank">https://godbolt.org/z/5qvqKqEe6</a><br>
> <<a href="https://godbolt.org/z/5qvqKqEe6" rel="noreferrer" target="_blank">https://godbolt.org/z/5qvqKqEe6</a>><br>
> >> The lambda in Clang is named "_Z3barIZ3foovE3$_0EvT_", while the one<br>
> >> in GCC is named "_Z3barIZ3foovEUlvE_EvT_". Their demangled names are<br>
> >> also different ("void bar<foo()::$_0>(foo()::$_0)" vs "void<br>
> >> bar<foo()::{lambda()#1}>(foo()::{lambda()#1})").<br>
> >> Lambdas are not covered by the ABI so this is OK.<br>
> <br>
> Actually, they are. See 5.1.8 of the ABI doc<br>
> (<a href="https://github.com/itanium-cxx-abi/cxx-abi" rel="noreferrer" target="_blank">https://github.com/itanium-cxx-abi/cxx-abi</a><br>
> <<a href="https://github.com/itanium-cxx-abi/cxx-abi" rel="noreferrer" target="_blank">https://github.com/itanium-cxx-abi/cxx-abi</a>>)<br>
> <br>
> The reason is that these symbols do escape into object files with<br>
> external linkage (not something originally anticipated).<br>
> <br>
> <br>
> Could you provide a quick example of this ABI break (where two files <br>
> compiled with matching compiler (GCC or Clang) link/run correctly, but <br>
> mismatching in either direction fails to link/run correctly)?<br>
<br>
hm, it turned out to be not quite the case I was thinking of:<br>
<br>
// header.h<br>
template<typename T> int bar (T) {static int i; return i++; }<br>
<br>
// the following lambda is attached to 'ctr', and therefore the<br>
// same type in every TU, you need gcc >= 10 to get this right.<br>
// not sure if clang models that correctly (given the template<br>
// mangling bug). And yes, this idiom exists in header files<br>
// -- I'm looking at you, ranges library :)<br>
auto ctr = [](){};<br>
<br>
// TUa.cc<br>
#include "header.h"<br>
<br>
// these instantiations are _Z3barIN3ctrMUlvE_EEiT_ due to the<br>
// above-mentioned attachment<br>
int maker1 () { return bar (ctr); }<br>
<br>
// TUb.cc<br>
#include "header.h"<br>
int maker2 () { return bar (ctr); }<br>
<br>
Those maker[12] functions are calling the exact same bar instantiation,</blockquote><div><br></div><div>I don't think that's right -- this program contains an ODR violation due to redefinition of 'ctr' (with two different types) in TUa and TUb.</div><div><br></div><div>There is no ABI requirement to use a specific mangling for entities that are not externally visible, and Clang takes advantage of this to avoid strictly numbering lambdas that are only visible in a single TU. Though it's unfortunate that we put a '$' in the name in such cases; that seems to confuse some demanglers that incorrectly think that identifiers can contain only [A-Za-z0-9_], and results in a demangling that doesn't mention that we are inside a lambda.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
so should see consistent numbering from the static variable.<br>
<br>
hope that helps.<br>
> <br>
> <br>
> >> However there are use-cases where I find it very inconvenient when<br>
> >> they generate different names. For example, if we are to compare the<br>
> >> performance difference of the same software compiled under Clang and<br>
> >> GCC, the perf stack traces will look very different because of the<br>
> >> naming differences, making it hard to compare.<br>
> >> Is there any particular reason that Clang uses a different naming<br>
> >> convention for lambdas, and would there be push-backs if we were to<br>
> >> make it consistent with GCC?<br>
> <br>
> It would be good to have clang match the ABI. I am not sure how much<br>
> pain it would be for users to switch though -- perhaps having two<br>
> manglings and therefore two distinct instances in the same executable.<br>
> Other than code bloat most would not notice, unless someone put a<br>
> static<br>
> var into their lambda operator.<br>
> <br>
> >> Thanks.<br>
> >><br>
> >> --<br>
> >> Xun<br>
> >> _______________________________________________<br>
> >> LLVM Developers mailing list<br>
> >> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> >> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>><br>
> > _______________________________________________<br>
> > cfe-dev mailing list<br>
> > <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> <mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
> > <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
> <<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>><br>
> ><br>
> <br>
> <br>
> -- <br>
> Nathan Sidwell<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> <mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
> <<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>><br>
> <br>
> <br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
> <br>
<br>
<br>
-- <br>
Nathan Sidwell<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>