[Bug c++/13983] no warning on some non-POD struct with packed attribute

["mdorey at bluearc dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From mdorey at bluearc dot com  2004-03-27 00:08 -------
(In reply to comment #2)
> non-POD's ignore the packed attribute.

We have a packed non-POD which abstracts byte-ordering which we use in lots of
packed structs.  Although the language spec doesn't talk about packing, being
able to do this efficiently is one of the key benefits of C++ for us.  Is it
really the case that *all* non-PODs ignore the packed attribute?  Nathan seemed
to contradict that in gcc/testsuite/g++.dg/ext/packed2.C, where he wrote:

  // July 2003
  // packing of non-pods is now only allowed if the non-pod is itself
  // packed. Also only such pods can be reference bound to non-consts

Which would let us do what we want to do just fine.  To the same end, in the
original(?) PR for packed2.C, Jason said:

    The problem is that the #pragma pack means that _GEIdx::addr
    might not have the usual alignment of an ftn_addr, so we
    can't just take the address of current.addr in order to bind
    it to a reference.  expand_expr knows this, and tries to
    make a bitwise copy and take the address of that.  But since
    ftn_addr has a copy constructor, we can't make bitwise
    copies, so we abort.

This is because "ftn_addr" isn't packed but it's being used to define a field in
a packed structure.  If they're both packed, then the alignment of "ftn_addr" is
always the same (1) and the need to copy won't arise.

If that's agreed, then can we go back to saying that this is a problem with
typedef?  This code compiles OK with 3.4.0 20040324:

template <class T>
struct A {
  A();
} __attribute__ ((packed));

//typedef A<int> Ai;

struct B {
  A<int> a;
} __attribute__ ((packed));

typedef A<int> Ai;

struct C {
  Ai a;
} __attribute__ ((packed));

But uncommenting the first typedef for Ai prevents it from compiling.

Perhaps it's to do with when the typedef is first seen?  If it's first seen
after the non-POD has already been used in a packed structure, the typedef seems
to be packed.  If before, then unpacked - even though the non-POD it's
typedef()d to is packed.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13983