From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11496 invoked by alias); 16 Jan 2006 15:14:30 -0000 Received: (qmail 11468 invoked by uid 48); 16 Jan 2006 15:14:28 -0000 Date: Mon, 16 Jan 2006 15:14:00 -0000 Message-ID: <20060116151428.11467.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: "matz at suse dot de" 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/msg01554.txt.bz2 List-Id: ------- Comment #23 from matz at suse dot de 2006-01-16 15:14 ------- The x86-64 ABI itself doesn't talk about zero-sized bitfields. So both behaviours are correct regarding the ABI. It talks about unnamed bitfields (which zero-sized ones must be) not influencing the overall alignment of structures or unions, but the problem here is different. Having said that I agree with Marks mail on gcc@ that the pre-3.4 behaviour made more sense. Unfortunately I'm also no stor-layout.c expert, so can't really comment on how the best approach is to implement it. I assume Jason would be the best to comment here, as he changed that behaviour. Stevens latest patch changes the evaluation of EMPTY_FIELD_BOUNDARY vs. PCC_BITFIELD_TYPE_MATTERS, so someone needs to make sure that this is okay. Additionally I don't know how stor-layout tracks alignment, i.e. if desired_align contains the alignment for the _current_ field, or for the _next_ field. A zero-sized bitfield should influence alignment of the next field (although due to the size of zero this shouldn't make a difference). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275