From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32650 invoked by alias); 14 Jan 2006 13:56:34 -0000 Received: (qmail 32615 invoked by uid 48); 14 Jan 2006 13:56:33 -0000 Date: Sat, 14 Jan 2006 13:56:00 -0000 Message-ID: <20060114135633.32614.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: "steven at gcc dot gnu dot org" 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/msg01358.txt.bz2 List-Id: ------- Comment #16 from steven at gcc dot gnu dot org 2006-01-14 13:56 ------- With this patch we force the alignment, but I have to admit I have no idea if this approach is correct. The only other place in stor-layout.c where we look at EMPTY_FIELD_BOUNDARY is in layout_decl, but that code is never reached for targets that define PCC_BITFIELD_TYPE_MATTERS. Index: stor-layout.c =================================================================== --- stor-layout.c (revision 109701) +++ stor-layout.c (working copy) @@ -1235,6 +1235,20 @@ place_field (record_layout_info rli, tre rli->bitpos = bitsize_zero_node; rli->offset_align = MIN (rli->offset_align, desired_align); } +#ifdef EMPTY_FIELD_BOUNDARY + else if (integer_zerop (DECL_SIZE (field)) + && ! (*targetm.ms_bitfield_layout_p) (DECL_FIELD_CONTEXT (field))) + { + /* If FIELD is a zero-bit bitfield, force alignment on the next + EMPTY_FIELD_BOUNDARY. */ + tree x = size_binop (MINUS_EXPR, + build_int_cst (TREE_TYPE (DECL_SIZE (field)), + EMPTY_FIELD_BOUNDARY), + rli->bitpos); + rli->bitpos = size_binop (PLUS_EXPR, rli->bitpos, x); + normalize_rli (rli); + } +#endif else { rli->bitpos = size_binop (PLUS_EXPR, rli->bitpos, DECL_SIZE (field)); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275