[PATCH] D119051: Fix pod-packed functionality to use the C++11 definition of pod-ness

David Blaikie via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Feb 7 17:59:45 PST 2022

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 {
    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()`

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list