[cfe-dev] Making lambda function name consistent with GCC?

[Richard Smith via cfe-dev]

On Mon, 3 May 2021 at 10:36, Nathan Sidwell via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On 5/3/21 12:42 PM, David Blaikie via cfe-dev wrote:
> >
> >
> > On Mon, May 3, 2021 at 4:10 AM Nathan Sidwell via cfe-dev
> > <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> >
> >     On 4/30/21 1:52 PM, Fāng-ruì Sòng via cfe-dev wrote:
> >      > Redirect to cfe-dev.
> >      >
> >      > On Fri, Apr 30, 2021 at 9:42 AM Xun Li via llvm-dev
> >      > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >      >>
> >      >> Hi,
> >      >>
> >      >> I noticed that when compiling lambda functions, the generated
> >     function
> >      >> names use different conventions than GCC.
> >      >> Example: https://godbolt.org/z/5qvqKqEe6
> >     <https://godbolt.org/z/5qvqKqEe6>
> >      >> The lambda in Clang is named "_Z3barIZ3foovE3$_0EvT_", while the
> one
> >      >> in GCC is named "_Z3barIZ3foovEUlvE_EvT_". Their demangled names
> are
> >      >> also different ("void bar<foo()::$_0>(foo()::$_0)" vs "void
> >      >> bar<foo()::{lambda()#1}>(foo()::{lambda()#1})").
> >      >> Lambdas are not covered by the ABI so this is OK.
> >
> >     Actually, they are.  See 5.1.8 of the ABI doc
> >     (https://github.com/itanium-cxx-abi/cxx-abi
> >     <https://github.com/itanium-cxx-abi/cxx-abi>)
> >
> >     The reason is that these symbols do escape into object files with
> >     external linkage (not something originally anticipated).
> >
> >
> > Could you provide a quick example of this ABI break (where two files
> > compiled with matching compiler (GCC or Clang) link/run correctly, but
> > mismatching in either direction fails to link/run correctly)?
>
> hm, it turned out to be not quite the case I was thinking of:
>
> // header.h
> template<typename T> int bar (T) {static int i; return i++; }
>
> // the following lambda is attached to 'ctr', and therefore the
> // same type in every TU, you need gcc >= 10 to get this right.
> // not sure if clang models that correctly (given the template
> // mangling bug).  And yes, this idiom exists in header files
> // -- I'm looking at you, ranges library :)
> auto ctr = [](){};
>
> // TUa.cc
> #include "header.h"
>
> // these instantiations are _Z3barIN3ctrMUlvE_EEiT_ due to the
> // above-mentioned attachment
> int maker1 () { return bar (ctr); }
>
> // TUb.cc
> #include "header.h"
> int maker2 () { return bar (ctr); }
>
> Those maker[12] functions are calling the exact same bar instantiation,


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.

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.

so should see consistent numbering from the static variable.
>
> hope that helps.
> >
> >
> >      >> However there are use-cases where I find it very inconvenient
> when
> >      >> they generate different names. For example, if we are to compare
> the
> >      >> performance difference of the same software compiled under Clang
> and
> >      >> GCC, the perf stack traces will look very different because of
> the
> >      >> naming differences, making it hard to compare.
> >      >> Is there any particular reason that Clang uses a different naming
> >      >> convention for lambdas, and would there be push-backs if we were
> to
> >      >> make it consistent with GCC?
> >
> >     It would be good to have clang match the ABI.  I am not sure how much
> >     pain it would be for users to switch though -- perhaps having two
> >     manglings and therefore two distinct instances in the same
> executable.
> >     Other than code bloat most would not notice, unless someone put a
> >     static
> >     var into their lambda operator.
> >
> >      >> Thanks.
> >      >>
> >      >> --
> >      >> Xun
> >      >> _______________________________________________
> >      >> LLVM Developers mailing list
> >      >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> >      >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >     <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >      > _______________________________________________
> >      > cfe-dev mailing list
> >      > cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> >      > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >     <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> >      >
> >
> >
> >     --
> >     Nathan Sidwell
> >     _______________________________________________
> >     cfe-dev mailing list
> >     cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> >     https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >     <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
>
>
> --
> Nathan Sidwell
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210505/d977cabd/attachment-0001.html>