public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "mdorey at bluearc dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/13983] no warning on some non-POD struct with packed attribute
Date: Sat, 27 Mar 2004 00:08:00 -0000 [thread overview]
Message-ID: <20040327000807.4939.qmail@sources.redhat.com> (raw)
In-Reply-To: <20040202165443.13983.bkramer@ciprico.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
next prev parent reply other threads:[~2004-03-27 0:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-02 16:54 [Bug c++/13983] New: packed attribute does not take effect when using typedef bkramer at ciprico dot com
2004-02-02 16:56 ` [Bug c++/13983] " bkramer at ciprico dot com
2004-02-02 17:02 ` [Bug c++/13983] no warning on some non-POD struct with packed attribute pinskia at gcc dot gnu dot org
2004-03-27 0:08 ` mdorey at bluearc dot com [this message]
2004-03-29 21:27 ` mdorey at bluearc dot com
2004-03-29 22:16 ` pinskia at gcc dot gnu dot org
2005-04-26 19:53 ` mdorey at bluearc dot com
2005-09-18 2:06 ` pinskia at gcc dot gnu dot org
[not found] <bug-13983-7764@http.gcc.gnu.org/bugzilla/>
2006-03-16 4:31 ` mdorey at bluearc dot com
2006-07-06 2:09 ` jason at gcc dot gnu dot org
2006-07-06 2:21 ` jason at gcc dot gnu dot org
2006-07-06 3:33 ` jason at gcc dot gnu dot org
2006-07-06 3:44 ` jason at gcc dot gnu dot org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040327000807.4939.qmail@sources.redhat.com \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).