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

[Harald van Dijk via cfe-dev]

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.

Cheers,
Harald van Dijk