[PATCH] D119051: Extend the C++03 definition of POD to include defaulted functions

David Blaikie via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Feb 11 13:45:59 PST 2022

dblaikie added a comment.

In D119051#3314138 <https://reviews.llvm.org/D119051#3314138>, @Bhramar.vatsa wrote:

> Sorry, but I can only add a bit more confusion: https://godbolt.org/z/fT19KTh34
> There are two cases, only differing in terms of user-defined constructor.
> Gcc and clang differs in the two cases. Gcc at least packs the second case (without user defined constructor), but clang (trunk version) doesn't.

Right - but with this proposed patch applied, Clang's answer is consistent with GCC's behavior, I believe?

> Uncomment/define macro 'PROPS' to check that the type-traits indicate in both cases that it can be considered POD.

Yes, I believe/understand that both of these types are C++11 POD, but the first example is not C++98/03 POD (and the second example isn't valid C++98/03, but as an extension, it is supported in C++98/03 and as far as I can tell (see the switch example in https://reviews.llvm.org/D119051#3305511 ) GCC deems the defaulted constructor to be still be C++98/03 POD, as an extension).

So, I believe your example is consistent with the theory I gave at the start of this patch: GCC is using the C++98/03 definition of POD, with an extension for defaulted functions, to determine whether to pack/align a member or not, and changing Clang's definition of 98/03 POD to match GCC's (by adding an extension for defaulted functions) is probably the right thing to do, so far as I can gather.

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list