[Bug c++/99821] New: __attribute__((packed)) ignored on struct with a field of post-C++11-POD and non-(some_old)-POD

["yumeyao at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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.