This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]