public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "matz at suse dot de" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?) Date: Thu, 19 Jan 2006 14:44:00 -0000 [thread overview] Message-ID: <20060119144421.11828.qmail@sourceware.org> (raw) In-Reply-To: <bug-22275-3760@http.gcc.gnu.org/bugzilla/> ------- Comment #32 from matz at suse dot de 2006-01-19 14:44 ------- Mark, I agree that it's saner when both structures (with #pragma pack and attribute packed) have the same length of 8 on i686 and x86_64 (because the bitfield was declared 'int' in difference to 'long' for instance). Then I have a question to clarify if I understood correctly: by remembering the original maximum_field_alignment and using that for zero-sized bitfields you want to use the absolute first, default, m_f_a, or the one last set before the innermost #pragma pack? Consider an example like so, and lets assume the initial max field alignment was 4: mfa == 4 #pragma pack(2) // 1 mfa == 2 #pragma pack(1) // 2 mfa == 1 #pragma pack() // 3 mfa == 4 #pragma pack (push,2) // 4 mfa == 2 #pragma pack (push,1) // 5 mfa == 1 #pragma pop // 6 mfa == 2 #pragma pop // 7 mfa == 4 With what would you constrain the alignment of a zero sized bitfield at each of the seven points? What if the initial mfa is 0 (i.e. not set)? Should -fpack-struct=... (which influences the initial mfa) influence that constraint too, or not? My opinion is, that at each of the seven points above we should constrain with the initial mfa (i.e. 4 in the example above), as adjusted by the -fpack-struct command line option. That would have the effect of aligning zero sized bitfield at max to the architecture default (possibly adjusted globally by the cmdline option), while effectively ignoring all #pragma packs in effect. I think that is what we want the semantics of a zero-sized bitfield to be. Agreed? Another point: If we make the structure with attribute packed on both x86 and x86-64 be eight long (to agree with the behaviour of using pragma), then we do add another variant unfortunately. In pre 3.4 that structure was 12 on x86-64 (which I think was an actual error). Wine itself uses only #pragma pack AFAIK, so it wouldn't be affected by this change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
next prev parent reply other threads:[~2006-01-19 14:44 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-22275-3760@http.gcc.gnu.org/bugzilla/> 2005-10-17 15:09 ` [Bug middle-end/22275] [3.4/4.0/4.1 " steven at gcc dot gnu dot org 2005-10-31 3:57 ` mmitchel at gcc dot gnu dot org 2005-10-31 7:21 ` steven at gcc dot gnu dot org 2005-10-31 7:44 ` mark at codesourcery dot com 2005-10-31 17:31 ` steven at gcc dot gnu dot org 2005-10-31 23:02 ` pinskia at gcc dot gnu dot org 2005-10-31 23:14 ` steven at gcc dot gnu dot org 2005-11-01 16:42 ` janis at gcc dot gnu dot org 2005-11-01 16:44 ` steven at gcc dot gnu dot org 2005-11-01 16:57 ` pinskia at gcc dot gnu dot org 2005-11-05 19:56 ` pinskia at gcc dot gnu dot org 2005-11-07 17:19 ` steven at gcc dot gnu dot org 2005-12-20 2:34 ` [Bug middle-end/22275] [3.4/4.0/4.1/4.2 " mmitchel at gcc dot gnu dot org 2006-01-14 13:56 ` steven at gcc dot gnu dot org 2006-01-14 13:57 ` steven at gcc dot gnu dot org 2006-01-14 14:48 ` steven at gcc dot gnu dot org 2006-01-14 15:17 ` steven at gcc dot gnu dot org 2006-01-14 15:35 ` steven at gcc dot gnu dot org 2006-01-14 15:55 ` steven at gcc dot gnu dot org 2006-01-16 10:23 ` rguenth at gcc dot gnu dot org 2006-01-16 15:14 ` matz at suse dot de 2006-01-16 23:31 ` steven at gcc dot gnu dot org 2006-01-16 23:33 ` steven at gcc dot gnu dot org 2006-01-17 21:07 ` hubicka at gcc dot gnu dot org 2006-01-17 22:12 ` matz at suse dot de 2006-01-17 22:31 ` matz at suse dot de 2006-01-18 23:00 ` mark at codesourcery dot com 2006-01-18 23:08 ` steven at gcc dot gnu dot org 2006-01-18 23:28 ` mark at codesourcery dot com 2006-01-19 14:44 ` matz at suse dot de [this message] 2006-01-19 16:59 ` mark at codesourcery dot com 2006-01-19 17:40 ` steven at gcc dot gnu dot org 2006-01-19 19:14 ` mark at codesourcery dot com 2006-01-20 14:01 ` matz at suse dot de 2006-01-20 16:36 ` matz at suse dot de 2006-01-20 18:02 ` mark at codesourcery dot com 2006-01-23 10:32 ` matz at suse dot de 2006-01-23 11:21 ` matz at suse dot de 2006-01-23 11:23 ` matz at suse dot de 2006-01-23 11:28 ` matz at suse dot de 2006-01-27 23:25 ` rguenth at gcc dot gnu dot org 2006-02-09 23:02 ` [Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change steven at gcc dot gnu dot org 2006-02-10 22:34 ` david dot moore at intel dot com 2006-02-11 0:14 ` david dot moore at intel dot com 2006-02-12 3:59 ` matz at suse dot de 2006-02-13 22:42 ` mmitchel at gcc dot gnu dot org 2006-02-13 22:59 ` mmitchel at gcc dot gnu dot org 2006-02-14 16:13 ` matz at gcc dot gnu dot org 2006-02-14 17:39 ` [Bug middle-end/22275] [3.4/4.0/4.2 " jakub at gcc dot gnu dot org 2006-02-15 12:20 ` matz at gcc dot gnu dot org 2006-02-15 12:24 ` matz at suse dot de 2006-02-15 12:25 ` [Bug middle-end/22275] [3.4/4.0 " rguenth 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=20060119144421.11828.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).