[cfe-dev] Making lambda function name consistent with GCC?
Richard Smith via cfe-dev
cfe-dev at lists.llvm.org
Wed May 5 11:28:11 PDT 2021
On Wed, 5 May 2021 at 10:57, Nathan Sidwell <nathan at acm.org> wrote:
> On 5/5/21 1:37 PM, Richard Smith wrote:
> > On Mon, 3 May 2021 at 10:36, Nathan Sidwell via cfe-dev
> > <cfe-dev at lists.llvm.org <mailto: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>
> > <mailto: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>
> > <mailto: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>
> > > <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>
> > > <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.
>
> Oh, I forgot to make 'ctr' inline -- that would remove that ODR, right?
> (Or am I just confusing trauma from header-units :) )
>
Yes, making 'ctr' inline would address that. It also causes Clang to mangle
the lambda following the ABI rule. Er... except, with that change:
GCC mangles i as _ZZ3barIN3ctrMUlvE_EEiT_E1i
Clang mangles i as _ZZ3barI3ctrMUlvE_EiT_E1i
The ABI document doesn't say how to mangle this case at all; the relevant
mangling rule seems (surprisingly) to be <data-member-prefix>, but that can
only appear after a <prefix>, which we don't have here. So it's unclear
whether this should be mangled as <data-member-prefix> <unqualified-name>
or as N <data-member-prefix> <unqualified-name> E.
I suppose we have to pick the latter (and that's what demanglers expect)
because ...I3ctrM... could also be ...<ctr, (some pointer-to-member
type)... -- so it looks like that's a Clang ABI bug and a bug in the ABI
document :) I've added a description of the latter to
https://github.com/itanium-cxx-abi/cxx-abi/issues/94.
> 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>
> > <mailto: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>
> > > <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>
> > <mailto: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>
> > > <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>
> > <mailto: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>
> > > <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 <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>
> >
>
>
> --
> Nathan Sidwell
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210505/6ab92dce/attachment-0001.html>
More information about the cfe-dev
mailing list