https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99821
Bug ID: 99821
Summary: __attribute__((packed)) ignored on struct with a field
of post-C++11-POD and non-(some_old)-POD
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yumeyao at gmail dot com
Target Milestone: ---
This is probably not an issue, but something could be done to improve the
warning message.
Consider the following code snippet(https://godbolt.org/z/n7458hcos):
struct empty {};
struct B : empty { // B is still a POD
int x;
};
struct D {
char c;
B b; // ignoring packed attribute because of unpacked non-POD field 'B
D::b'
} __attribute__((packed));
bool is_pod() { return __is_pod(B); } // on gcc5 and below it's false
int sizeofD() { return sizeof(D); }
struct B is considered as POD on C++11 onwards, but gcc gives warning like
this:
warning: ignoring packed attribute because of unpacked non-POD field 'B D::b'
and as a consequence, struct D is not packed, with sizeof(D) == 8.
When I asked for account creation, @Jonathan Wakely replied me the term
"non-POD" shall refer to "POD for the purposes of layout" as defined in the
ABI. I've looked into the document and found this under the corresponding
section:
There have been multiple published revisions to the ISO C++ standard,
and each one has included a different definition of POD. To ensure
interoperation of code compiled according to different revisions of the
standard, it is necessary to settle on a single definition for a platform.
A platform vendor may choose to follow a different revision of the standard,
but by default, the definition of POD under this ABI is the definition from
the 2003 revision (TC1).
So I guess this might not be an issue, but I think there is something worth
discussing:
1. We can improve the warning message, to change the word 'non-POD' to
something like 'non-POD(c++03)'. As inferred from the description above and
current behavior, gcc is choosing POD definition in C++03 as the ABI-level "POD
for the purposes of layout" .
2. As also shown in the code above, gcc6 and above reports __is_pod(B) == true,
and gcc5 and below reports __is_pod(B) == false. While I am aware that this is
the implementation detail used by std::is_pod<T> in <type_traits> therefore
__is_pod() reflects the C++ standard specified in gcc command line, I think it
might be helpful to provide some intrinsic to tell something about the ABI
level. A possible extension might be __is_pod(type_name, cxx_std_ver =
"current"), whereas cxx_std_ver can be specified with "c++03" to get that.
I do think this issue is linked to #60972 as the class A in that issue is
obviously non-POD on c++03.
