@llvm/issue-subscribers-clang-codegen

@llvm/issue-subscribers-c-17

First pass at this.

Not sure why the latter doesn't happen for other adjacent cases (like lambdas in default argument initializers in a class, or anywhere else for that matter)... yet to be looked into.

Hmm, nope, that seems to happen in the good cases too - so that's a slight red herring...

Ah:

Only mentions two out of the four cases listed in the Itanium spec:

* default arguments appearing in class definitions
* default member initializers
* the bodies of inline or templated functions
* the initializers of inline or templated variables

oh, it lists other cases later/elsewhere in the switch, but I guess doesn't fully/correctly implement the cases..

Huh, does GCC have a bug here too? I managed to fix the mangling, and I think the linkage too, but the symbols still differ from GCC and it looks like GCC's using internal linkage?

struct A {
  static constexpr auto foo = [] {
    static int bar;
    return &bar;
  };
};
int *f() { return A::foo(); }

$ diff <(clang++-tot lambda_bad.cpp -c && nm lambda_bad.o | c++filt) <(g++-12 lambda_bad.cpp -c && nm lambda_bad.o | c++filt)
1,4c1,4
< 0000000000000000 T f()
< 0000000000000000 V A::foo
< 0000000000000000 W A::{lambda()#1}::operator()() const
< 0000000000000000 V A::{lambda()#1}::operator()() const::bar
---
> 0000000000000011 T f()
> 0000000000000000 r A::foo
> 0000000000000000 t A::{lambda()#1}::operator()() const
> 0000000000000000 b A::{lambda()#1}::operator()() const::bar

if I'm reading this correctly, that is.

yeah, I have a small test case that changes behavior under optimizations with GCC (due to inlining) and not with Clang. Guess I could simplify it further and get it to have the wrong behavior even without optimization...

lambda.h:

struct A {
  static constexpr auto foo = [] {
    static int bar;
    return &bar;
  };
};

a.cpp:

#include "lambda.h"
int *f1() {
  return A::foo();
}

b.cpp:

#include "lambda.h"
int *f1();
int main() {
  return A::foo() != f1();
}

Returns 1 in a non-conforming implementation (GCC and Clang ToT) and 0 when conforming (with a prototype patch I have for clang), I think?

Should we be using the variable context mangling, though? GCC isn't - it's mangling without the variable name, using the class scope:

But it looks like from the example in the itanium spec, we should use the type name:

template<typename T> struct S {
  static int *x;
};
template<typename T> int *S<T>::x = []{static int x; return &x;}();
template int *S<int>::x;
  // [blaikie: modified the example above to be int* instead of int, 
  //  and the static local, so these mangling's don't quite line up]
  // Type of lambda in intializer of S<int>::x: N1SIiE1xMUlvE_E
  // Corresponding operator(): _ZNK1SIiE1xMUlvE_clEv

Hmm, GCC and Clang both get this ^ case right... oh, wait, no, GCC gets the mangling right (though it differs from GCC's handling of the non-template case) using the 'x' member, but gets the linkage different from Clang at least

$ clang++-tot lambda_spec.cpp -c && nm lambda_spec.o  | c++filt
0000000000000000 t __cxx_global_var_init
0000000000000000 V guard variable for S<int>::x
0000000000000000 V S<int>::x
0000000000000000 W S<int>::x::{lambda()#1}::operator()() const
0000000000000000 V S<int>::x::{lambda()#1}::operator()() const::x
$ g++-12 lambda_spec.cpp -c && nm lambda_spec.o  | c++filt
000000000000004b t _GLOBAL__sub_I_lambda_spec.cpp
0000000000000000 t __static_initialization_and_destruction_0(int, int)
0000000000000000 u guard variable for S<int>::x
0000000000000000 u S<int>::x
0000000000000000 W S<int>::x::{lambda()#1}::operator()() const
0000000000000000 u S<int>::x::{lambda()#1}::operator()() const::x

Are those ABI compatible linkages? (V and u?) Maybe those are fine & don't tell us anything about the broken non-template case... but I think they still point to the name mangling being incorrect in GCC, and that it should be using the variable name as part of the mangling.

GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107741
(turned out they missed the member variable scope, but also the numbering isn't scoped to the type, despite the name having the type scoping - lambdas in one type were causing the lambda number in later types to be incremented)

https://reviews.llvm.org/D138247

Fixed in e9c9db3

https://godbolt.org/z/sWo7EYsxP

@llvm/issue-subscribers-clang-frontend