public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "mcvick_e at iname dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/28763] sizeof macro appears broken when bitfields are in structures Date: Tue, 22 Aug 2006 16:42:00 -0000 [thread overview] Message-ID: <20060822164214.6038.qmail@sourceware.org> (raw) In-Reply-To: <bug-28763-8046@http.gcc.gnu.org/bugzilla/> ------- Comment #8 from mcvick_e at iname dot com 2006-08-22 16:42 ------- To try to be more helpful here, after doing a large amount of investigation into the signature of this problem, it's been observed that the GNU compiler simply defines (or appears to define) a bitfield (regardless of it's type (char, short, int)) as nothing more than a byte aligned entity. Now if the structure has a larger constituent primitive type (short, int) then the structure will align to the largest primitive type. For example. One of the tests that I performed was simply to define two structures. struct foo1 { unsigned int bar1 : 10; unsigned int bar2 : 10; unsigned int bar3 : 12; unsigned short bar4; unsigned char bar5; }; struct foo2 { unsigned int bar1 : 10; unsigned int bar2 : 10; unsigned int bar3 : 12; unsigned short bar4; unsigned char bar5; unsigned char bar6; }; foo1 will report the size as being 0x8 (which is correct), where as foo2 will report the size as 0xA which is incorrect. It's correct if the structure has short alignment, however according to the ABI the structure should align to a 32-bit alignment because of the unsigned int bitfield. Taking the same example above, if you substitute an unsigned int for the unsigned short, then you get the alignment that you expect across all situations. Merely because an integer primitive type is embedded within the structure. I hope this helps some. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763
next prev parent reply other threads:[~2006-08-22 16:42 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2006-08-17 17:44 [Bug c++/28763] New: " mcvick_e at iname dot com 2006-08-17 18:02 ` [Bug c++/28763] " pinskia at gcc dot gnu dot org 2006-08-17 18:04 ` [Bug target/28763] " pinskia at gcc dot gnu dot org 2006-08-17 22:18 ` mcvick_e at iname dot com 2006-08-17 22:20 ` pinskia at gcc dot gnu dot org 2006-08-17 22:28 ` mcvick_e at iname dot com 2006-08-17 22:35 ` mcvick_e at iname dot com 2006-08-18 0:03 ` mcvick_e at iname dot com 2006-08-22 16:42 ` mcvick_e at iname dot com [this message] 2009-06-16 16:25 ` [Bug target/28763] wrong size of struct with some bit-fields on ppc-eabi mcvick_e at iname dot com 2009-06-16 16:27 ` pinskia at gcc dot gnu dot org 2009-06-16 16:30 ` mcvick_e at iname dot com 2009-06-16 16:31 ` pinskia at gcc dot gnu dot org 2009-06-16 16:55 ` mcvick_e at iname dot com 2009-06-16 17:27 ` [Bug target/28763] sizeof() and __attribute__ broken with " joseph at codesourcery dot com 2009-06-16 17:43 ` mcvick_e at iname dot com 2009-06-16 20:03 ` joseph at codesourcery dot com
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=20060822164214.6038.qmail@sourceware.org \ --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: linkBe 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).