dblaikie added a comment. In D119051#3302125 <https://reviews.llvm.org/D119051#3302125>, @rnk wrote:
> Looks like the test fails on the Windows pre-merge bot: > https://buildkite.com/llvm-project/premerge-checks/builds/77696#1836f181-a998-4695-b587-a832392222ea > > The debian bot seems to be failing for unrelated (clang tooling) reasons. Ah, legit failure - should've caught that locally. Seems I'm not really sure what POD rules GCC is using... https://godbolt.org/z/oczvTrdTM My understanding is that this is C++03 non-POD, but C++11 POD: struct t1 { protected: int a; }; And this is also C++03 non-POD, but C++11 POD: struct t1 { t1() = default; // C++11 POD, <C++11 non-POD int a; }; Well, I guess, arguably, the second example has no definition in C++03, since it uses a C++11 feature, but we backport that as an extension. So perhaps our backport doesn't capture the POD-ness in the same way GCC does? Because the original (`FieldClass->isPOD()`) classifies the first example as non-POD and the second example as POD, and the `isCXX11PODType` does the opposite, if I'm understanding the results of my program correctly. So I'm not sure what property to test for here to correctly model GCC's behavior. Perhaps I need to go and change Clang's definition for `FieldClass->isPOD()` Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D119051/new/ https://reviews.llvm.org/D119051 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
