From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29341 invoked by alias); 19 Jan 2006 19:14:13 -0000 Received: (qmail 29313 invoked by alias); 19 Jan 2006 19:14:11 -0000 Date: Thu, 19 Jan 2006 19:14:00 -0000 Message-ID: <20060119191411.29312.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?) In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mark at codesourcery dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-01/txt/msg01985.txt.bz2 List-Id: ------- Comment #35 from mark at codesourcery dot com 2006-01-19 19:14 ------- Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?) steven at gcc dot gnu dot org wrote: > - Older HP compilers and MS compilers use zero-length bit-fields to force > the following member of a struct to the next natural (is that GCC's > BITS_PER_WORD?) boundary. > - XLC and HP on IA-64 force alignment corresponding to the type of the bit > field, of which IBM says it is essentially the same, but this is not true > for GCC with e.g. long long on ix86. That's essentially the PCC_BITFIELD_TYPE_MATTERS distinction; the HP/MS compilers in the first bullet point are not using the pcc-style bitfields. Your research is interesting. However, I'm not too worried about our handling of zero-width bitfields by themselves; the various psABIs specify that behavior, so we have a clear guideline. It's when we throw in various GCC extensions (#pragma pack, __attribute__((aligned)), etc.) that it gets complicated and hard. I'm hoping that since Michael and I independently came to the same conclusion about how things should work, and since there were no objections to my initial proposal to change things back on the mailing list, we're actually pretty close to a patch. Michael, do you plan to revise your patch to implement the semantics on which we've agreed? Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275