From patchwork Fri Feb 17 12:15:17 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kai Tietz X-Patchwork-Id: 141813 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 7A578B6F13 for ; Fri, 17 Feb 2012 23:15:42 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1330085743; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:Received:Date:Message-ID:Subject:From:To: Cc:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=OvvaCWX HazmH4t8Kaw0FD/rkEag=; b=m2f/edIYNmP7hpIrzG73yi107Ce/UljGIV8DBCh aSVLtmqkJqGLMe/Le+VOxQD+IRyEWBoeO7uD0U6iXeRkbVI78ct6DTQprZQ2TztB 4gI8/FCal2pJe6S3SfB2a17zN4mGTyAbN+EqHLtQsYfoQ+EvQuPHGFIogJMtb/Oo xbnM= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:MIME-Version:Received:Received:Date:Message-ID:Subject:From:To:Cc:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=QhwtLHVLaEPktIAk3KWQqoRQ1OTeMmrFbYlL78I5x5HzKsfisj58B83js21m59 rMRI1Kgwna2HYw2CCqmo/RTqNTSNn7Ers80K5is+iPoiiZln2DpcifNJJKFf3Zvm 4q4RPOJp7rhAAGdR/dhDGQdYgZ6Y46dsadZFtOSaiXads=; Received: (qmail 12926 invoked by alias); 17 Feb 2012 12:15:34 -0000 Received: (qmail 12917 invoked by uid 22791); 17 Feb 2012 12:15:32 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-tul01m020-f175.google.com (HELO mail-tul01m020-f175.google.com) (209.85.214.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 17 Feb 2012 12:15:18 +0000 Received: by obhx4 with SMTP id x4so4609072obh.20 for ; Fri, 17 Feb 2012 04:15:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.36.35 with SMTP id n3mr4740024obj.66.1329480917657; Fri, 17 Feb 2012 04:15:17 -0800 (PST) Received: by 10.182.141.74 with HTTP; Fri, 17 Feb 2012 04:15:17 -0800 (PST) Date: Fri, 17 Feb 2012 13:15:17 +0100 Message-ID: Subject: [patch stor-layout]: Fix PR 52238 - -mms-bitfields: __attribute__ ((aligned (n))) ignored for struct members From: Kai Tietz To: GCC Patches Cc: Richard Guenther , Richard Henderson X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi, this patch fixes old regression about ms-bitfields structure layout. This patch was verified by VLC community and libAV people (as to see in bug-report). The result of the structure-layout was also compared to VC's 32-bit and 64-bit result by VLC people. ChangeLog 2012-02-17 Kai Tietz PR target/52238 * stor-layout.c (place_field): Handle desired_align for ms-bitfields, too. 2012-02-17 Kai Tietz * gcc.dg/bf-ms-layout-3.c: New testcase. Tested for i686-w64-mingw32, x86_64-w64-mingw32, i686-pc-cygwin. Ok for apply? Regards, Kai + Index: gcc/gcc/stor-layout.c =================================================================== --- gcc.orig/gcc/stor-layout.c +++ gcc/gcc/stor-layout.c @@ -1141,15 +1141,14 @@ place_field (record_layout_info rli, tre } /* Does this field automatically have alignment it needs by virtue - of the fields that precede it and the record's own alignment? - We already align ms_struct fields, so don't re-align them. */ - if (known_align < desired_align - && !targetm.ms_bitfield_layout_p (rli->t)) + of the fields that precede it and the record's own alignment? */ + if (known_align < desired_align) { /* No, we need to skip space before this field. Bump the cumulative size to multiple of field alignment. */ - if (DECL_SOURCE_LOCATION (field) != BUILTINS_LOCATION) + if (!targetm.ms_bitfield_layout_p (rli->t) + && DECL_SOURCE_LOCATION (field) != BUILTINS_LOCATION) warning (OPT_Wpadded, "padding struct to align %q+D", field); /* If the alignment is still within offset_align, just align @@ -1171,7 +1170,8 @@ place_field (record_layout_info rli, tre if (! TREE_CONSTANT (rli->offset)) rli->offset_align = desired_align; - + if (targetm.ms_bitfield_layout_p (rli->t)) + rli->prev_field = NULL; } /* Handle compatibility with PCC. Note that if the record has any Index: gcc/gcc/testsuite/gcc.dg/bf-ms-layout-3.c =================================================================== --- /dev/null +++ gcc/gcc/testsuite/gcc.dg/bf-ms-layout-3.c @@ -0,0 +1,47 @@ +/* Test for MS bitfield layout */ +/* { dg-do run { target *-*-interix* *-*-mingw* *-*-cygwin* i?86-*-darwin* } } */ +/* { dg-options "-mms-bitfields" } */ + +extern void abort(); + +struct { + char a; + char b __attribute__ ((aligned (16))); +} s1; + +struct { + char a; + char b; +} s2; + +struct { + char a : 6; + char b __attribute__ ((aligned (16))); +} s3; + +struct { + char a : 6; + char b __attribute__ ((aligned (2))); +} s4; + +struct { + char a : 6; + char b __attribute__ ((aligned (1))); +} s5; + +__PTRDIFF_TYPE__ offs (const void *a, const void *b) +{ + return (__PTRDIFF_TYPE__) ((const char*)a - (const char*)b); +} + +int main() +{ + if (offs (&s1.b, &s1) != 16 + || offs (&s2.b, &s2) != 1 + || offs (&s3.b, &s3) != 16 + || offs (&s4.b, &s4) != 2 + || offs (&s5.b, &s5) != 1) + abort (); + return 0; +}