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

[Tom Stellard via cfe-dev]

On 5/3/21 11:34 AM, Harald van Dijk via cfe-dev wrote:
> On 30/04/2021 18:52, 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> wrote:
>>>
>>> Hi,
>>>
>>> I noticed that when compiling lambda functions, the generated function
>>> names use different conventions than GCC.
>>> Example: 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.
>>> 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?
>>> Thanks.
> 
> Hi,
> 
> The layout of lambdas is different between GCC and clang. This already results in wrong code when some object files are compiled with GCC and others with clang in some corner cases:
> 
> test.h:
> 
>    extern int i;
>    extern int f();
> 
>    inline auto lambda = [](){
>      int &ref = i;
>      return [&]() { return ref; };
>    }();
> 
> test1.cc:
> 
>    #include "test.h"
>    int f() { return sizeof lambda; }
>    int i;
> 
> test2.cc:
> 
>    #include "test.h"
>    int main() { return f() != sizeof lambda; }
> 
> This program should return 0, returns 0 when test1.cc and test2.cc are both compiled with GCC, returns 0 when test1.cc and test2.cc are both compiled with clang, but returns 1 when one is compiled with GCC and the other with clang.
> 
> In more realistic cases where the different layout would cause problems, although not by design, the different naming has the benefit that it generally either avoids the problem by making GCC's and clang's types different, or clearly diagnoses it by causing a linker error. By aligning the names, we would get more cases where GCC and clang silently generate incompatible code that never gets diagnosed, but causes problems at runtime. In my opinion, it would be a bad idea to align mangling between GCC and clang until the types are actually compatible.
> 

There is a bug tracking this issue now: https://bugs.llvm.org/show_bug.cgi?id=50209
I think it might be good to move the discussion there so it's easier to track.

-Tom

> Cheers,
> Harald van Dijk
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev