Clang and GCC disagree on whether lambda closure type is "POD for the purpose of layout"

[hubert-reinterpretcast]

Similar to #46056, Clang and GCC disagree on "POD for the purpose of layout": in this case, on closure types.

It appears that, in the case below, GCC considers the first closure type to be "POD for the purpose of layout" and does not allocate additional subobjects of the derived class into the tail padding. Clang does allocate into the tail padding, resulting in a smaller size of 8 for the derived class instead of 12.

https://godbolt.org/z/4T8f1sbMr

SOURCE (<stdin>):

template <typename ...T>
struct Callables : T ... {
  Callables(T ...t) : T(t) ... {}
  using T::operator() ...;
};

inline auto f(int x, char y) {
  Callables callables([x, y](void) {}, [y](int) {});
  static_assert(sizeof(callables) == 12);
  return callables;
}

int main(void) { f(0, 1)(42); }

COMPILER INVOCATION:

clang++ --target=x86_64-unknown-linux-gnu -xc++ -fsyntax-only -

ACTUAL OUTPUT:

<stdin>:9:3: error: static assertion failed due to requirement 'sizeof (callables) == 12'
  static_assert(sizeof(callables) == 12);
  ^             ~~~~~~~~~~~~~~~~~~~~~~~
<stdin>:9:35: note: expression evaluates to '8 == 12'
  static_assert(sizeof(callables) == 12);
                ~~~~~~~~~~~~~~~~~~^~~~~
1 error generated.

EXPECTED OUTPUT:

Clean compile.

COMPILER VERSION INFO (clang++ -v):

clang version 16.0.0 (https://github.com/llvm/llvm-project.git a72d8d704178118b254d9ff84a78afb18813b888)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/wandbox/clang-head/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Candidate multilib: .;@m64
Selected multilib: .;@m64

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[dwblaikie]

Wonder if this could be a GCC bug, though maybe they'll consider it part of their ABI at this point, I'm not sure.

[dwblaikie]

Clang considers the lambda type non-pod (in the C++ language sense, not the ABI sense):

llvm-project/clang/include/clang/AST/DeclCXX.h

Lines 428 to 431 in 3465f02

	// C++1z [expr.prim.lambda]p4:
	// This class type is not an aggregate type.
	Aggregate = false;
	PlainOldData = false;

But also that Clang makes the member variables/fields of the lambda private which makes the type non-pod. With these changes, the test case passes:

diff --git a/clang/include/clang/AST/DeclCXX.h b/clang/include/clang/AST/DeclCXX.h
index feee56017da5..a9e792f0f575 100644
--- a/clang/include/clang/AST/DeclCXX.h
+++ b/clang/include/clang/AST/DeclCXX.h
@@ -424,11 +424,6 @@ private:
           NumExplicitCaptures(0), HasKnownInternalLinkage(0), ManglingNumber(0),
           MethodTyInfo(Info) {
       IsLambda = true;
-
-      // C++1z [expr.prim.lambda]p4:
-      //   This class type is not an aggregate type.
-      Aggregate = false;
-      PlainOldData = false;
     }
   };
 
diff --git a/clang/lib/Sema/SemaLambda.cpp b/clang/lib/Sema/SemaLambda.cpp
index a22708df5dbe..65c352294c8c 100644
--- a/clang/lib/Sema/SemaLambda.cpp
+++ b/clang/lib/Sema/SemaLambda.cpp
@@ -1778,7 +1778,7 @@ FieldDecl *Sema::BuildCaptureField(RecordDecl *RD,
     }
   }
   Field->setImplicit(true);
-  Field->setAccess(AS_private);
+  Field->setAccess(AS_public);
   RD->addDecl(Field);
 
   if (Capture.isVLATypeCapture())

[dwblaikie]

Based on itanium discussion, seems like this is maybe a GCC bug - so I filed one here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109114

Might be worth testing the non-capture case too, to check it's non-aggregate (non-pod?) in Clang and GCC too, maybe there's a different bug in that case.