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

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

[mdorey at bluearc dot com]

------- Comment #8 from mdorey at bluearc dot com  2006-03-16 04:31 -------
(In reply to comment #5)
> Nathan could you comment on this bug.

Two years with no comment.  Is it because the Severity is set to Enhancement? 
I'm convinced that the warning is incorrect, not missing, so I think the
Severity should be Normal and (perhaps) the Summary shouldn't say "no warning".

Perhaps another example would help to convince:

martind@duezer:~/playpen$ cat ignoring-packed.cpp 
template <typename T>
struct A {
    A();
} __attribute__((packed));

typedef A<int> B;

struct C {
  //A<int> a;
  B b;
} __attribute__((packed));
martind@duezer:~/playpen$ g++-4.0 -c ignoring-packed.cpp 
ignoring-packed.cpp:10: warning: ignoring packed attribute on unpacked non-POD
field ?B C::b?
martind@duezer:~/playpen$ 

With gcc version 4.0.3 (Debian 4.0.3-1).

The commented-out line compiles fine, though it should be equivalent to the
following line - the one which fails to compile.


-- 


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

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

[jason at gcc dot gnu dot org]

------- Comment #9 from jason at gcc dot gnu dot org  2006-07-06 02:09 -------
Subject: Bug 13983

Author: jason
Date: Thu Jul  6 02:09:02 2006
New Revision: 115217

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115217
Log:
        PR c++/13983
        PR c++/17519
        * stor-layout.c (finish_record_layout): Copy TYPE_PACKED to variants.
        * c-common.c (handle_packed_attribute): So don't copy it here.
        * c-decl.c (finish_struct): Don't copy TYPE_ALIGN.
        * cp/class.c (check_field_decls): Check TYPE_PACKED after
        stripping array types.
        (finish_struct_bits): Don't copy TYPE_SIZE here.

Added:
    trunk/gcc/testsuite/g++.dg/ext/packed10.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-common.c
    trunk/gcc/c-decl.c
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/class.c
    trunk/gcc/stor-layout.c


-- 


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

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

[jason at gcc dot gnu dot org]

------- Comment #10 from jason at gcc dot gnu dot org  2006-07-06 02:21 -------
Subject: Bug 13983

Author: jason
Date: Thu Jul  6 02:21:17 2006
New Revision: 115219

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115219
Log:
        PR c++/13983
        PR c++/17519
        * stor-layout.c (finish_record_layout): Copy TYPE_PACKED to variants.
        * cp/class.c (check_field_decls): Check TYPE_PACKED after
        stripping array types.

Added:
    branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/packed10.C
      - copied unchanged from r115217,
trunk/gcc/testsuite/g++.dg/ext/packed10.C
Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/cp/ChangeLog
    branches/gcc-4_1-branch/gcc/cp/class.c
    branches/gcc-4_1-branch/gcc/stor-layout.c


-- 


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

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

[jason at gcc dot gnu dot org]

------- Comment #11 from jason at gcc dot gnu dot org  2006-07-06 03:33 -------
Subject: Bug 13983

Author: jason
Date: Thu Jul  6 03:33:20 2006
New Revision: 115220

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115220
Log:
        PR c++/13983
        PR c++/17519
        * stor-layout.c (finish_record_layout): Copy TYPE_PACKED to variants.
        * cp/class.c (check_field_decls): Check TYPE_PACKED after
        stripping array types.

Added:
    branches/gcc-4_0-branch/gcc/testsuite/g++.dg/ext/packed10.C
      - copied unchanged from r115219,
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/packed10.C
Modified:
    branches/gcc-4_0-branch/gcc/ChangeLog
    branches/gcc-4_0-branch/gcc/cp/ChangeLog
    branches/gcc-4_0-branch/gcc/cp/class.c
    branches/gcc-4_0-branch/gcc/stor-layout.c


-- 


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

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

[jason at gcc dot gnu dot org]

------- Comment #12 from jason at gcc dot gnu dot org  2006-07-06 03:44 -------
feexd


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-18 02:06 -------
*** Bug 23833 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Dmitry dot Chepel at acronis
                   |                            |dot com


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

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

[mdorey at bluearc dot com]

------- Additional Comments From mdorey at bluearc dot com  2005-04-26 19:53 -------
(In reply to comment #5)
> Nathan could you comment on this bug.

This bug may be related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17519

There's an interesting discussion in that bug, including comments from Nathan.

-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-03-29 22:16 -------
Nathan could you comment on this bug.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nathan at gcc dot gnu dot
                   |                            |org


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

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

[mdorey at bluearc dot com]

------- Additional Comments From mdorey at bluearc dot com  2004-03-29 21:26 -------
At the risk of annoying particularly Andrew Pinski, who does such a sterling job
with triaging all my idiot bugs, I wonder if I can set the severity back to
normal, as I'm claiming - in comment #3 - that this isn't a missing warning but
an incorrect warning, as was originally submitted?

...

Darn, it seems I can't.  Perhaps this bug is doomed to languish unread.


-- 


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

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

[mdorey at bluearc dot com]

------- 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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-02-02 17:02 -------
Actually the warning is correct, the problem is that the warning is not on the other structs for some 
reason when it should be as non-POD's ignore the packed attribute.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |diagnostic
   Last reconfirmed|0000-00-00 00:00:00         |2004-02-02 17:02:03
               date|                            |
            Summary|packed attribute does not   |no warning on some non-POD
                   |take effect when using      |struct with packed attribute
                   |typedef                     |


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