This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
- From: "steven at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 14 Jan 2006 13:56:33 -0000
- Subject: [Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
- References: <bug-22275-3760@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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