From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-157720-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 12213 invoked by alias); 6 Nov 2009 09:54:42 -0000
Received: (qmail 12201 invoked by uid 22791); 6 Nov 2009 09:54:41 -0000
X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 	tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from mail-pw0-f57.google.com (HELO mail-pw0-f57.google.com) (209.85.160.57)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Nov 2009 09:53:13 +0000
Received: by pwi7 with SMTP id 7so583847pwi.16         for <gcc@gcc.gnu.org>; Fri, 06 Nov 2009 01:53:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.162.11 with SMTP id k11mr108376rve.53.1257501191695; Fri,  	06 Nov 2009 01:53:11 -0800 (PST)
In-Reply-To: <200911061046.50176.ebotcazou@adacore.com>
References: <Pine.LNX.4.64.0911051725440.15566@wotan.suse.de> 	 <200911061046.50176.ebotcazou@adacore.com>
Date: Fri, 06 Nov 2009 09:54:00 -0000
Message-ID: <84fc9c000911060153m4fbd86efqaa823c71d15543b6@mail.gmail.com>
Subject: Re: Do BLKmode bit-fields still exist?
From: Richard Guenther <richard.guenther@gmail.com>
To: Eric Botcazou <ebotcazou@adacore.com>
Cc: Michael Matz <matz@suse.de>, gcc@gcc.gnu.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2009-11/txt/msg00120.txt.bz2

On Fri, Nov 6, 2009 at 10:46 AM, Eric Botcazou <ebotcazou@adacore.com> wrot=
e:
>> In a desparate try to get some testcases which do have BLKmode bit-fields
>> I bootstrapped and regtested the below patch (as part of a larger patch,
>> though) on seven architectures with all languages (on two without Ada).
>
> Yet it's easy in Ada on platforms with strict alignment, e.g. SPARC:
>
> package P is
>
> =A0type Rec1 is record
> =A0 =A0I1 : Integer;
> =A0 =A0I2 : Integer;
> =A0 =A0I3 : Integer;
> =A0end record;
>
> =A0type R2 is record
> =A0 =A0B : Boolean;
> =A0 =A0R : Rec1;
> =A0end record;
> =A0pragma Pack (R2);
>
> end P;
>
> (gdb) p debug_tree(0x2aaaaab2bdc0)
> =A0<field_decl 0x2aaaaab2bdc0 r
> =A0 =A0type <record_type 0x2aaaaabc64d0 p__rec1 sizes-gimplified visited =
BLK
> =A0 =A0 =A0 =A0size <integer_cst 0x2aaaaab27f90 constant visited 96>
> =A0 =A0 =A0 =A0unit size <integer_cst 0x2aaaaabd7d20 constant visited 12>
> =A0 =A0 =A0 =A0align 32 symtab 0 alias set -1 canonical type 0x2aaaaabc64=
d0
> =A0 =A0 =A0 =A0fields <field_decl 0x2aaaaab2bb40 i1 type <integer_type 0x=
2aaaaabc6580
> integer>
> =A0 =A0 =A0 =A0 =A0 =A0nonaddressable SI file p.ads line 4 col 5
> =A0 =A0 =A0 =A0 =A0 =A0size <integer_cst 0x2aaaaaaf1420 constant visited =
32>
> =A0 =A0 =A0 =A0 =A0 =A0unit size <integer_cst 0x2aaaaaaf1090 constant vis=
ited 4>
> =A0 =A0 =A0 =A0 =A0 =A0align 32 offset_align 64
> =A0 =A0 =A0 =A0 =A0 =A0offset <integer_cst 0x2aaaaaaf1b40 constant visite=
d 0>
> =A0 =A0 =A0 =A0 =A0 =A0bit offset <integer_cst 0x2aaaaaaf1b70 constant 0>=
 context
> <record_type 0x2aaaaabc64d0 p__rec1> chain <field_decl 0x2aaaaab2bbe0 i2>>
> Ada size <integer_cst 0x2aaaaab27f90 96>
> =A0 =A0 =A0 =A0reference_to_this <reference_type 0x2aaaaabc6630> chain <t=
ype_decl
> 0x2aaaaab34540 p__rec1>>
> =A0 =A0external packed bit-field BLK file p.ads line 11 col 5 size <integ=
er_cst
> 0x2aaaaab27f90 96> unit size <integer_cst 0x2aaaaabd7d20 12>
> =A0 =A0align 8 offset_align 64 offset <integer_cst 0x2aaaaaaf1b40 0>
> =A0 =A0bit offset <integer_cst 0x2aaaaaaf1180 type <integer_type 0x2aaaaa=
b010b0
> bit_size_type> constant visited 8> bit_field_type <record_type 0x2aaaaabc=
64d0
> p__rec1> context <record_type 0x2aaaaabc6790 p__r2>>
>
> We set DECL_BIT_FIELD in the front-end because the field is misaligned.

Isn't it enough to specify DECL_PACKED here?  The tree.h docs
about DECL_BIT_FIELD are a bit unspecific compared to
DECL_PACKED.

/* Nonzero in a FIELD_DECL means it is a bit field, and must be
accessed   specially.  */

vs.

/* In a FIELD_DECL, indicates this field should be bit-packed.  */

where it seems, as your field isn't a bitfield, using DECL_PACKED
looks more appropriate?

Richard.

> --
> Eric Botcazou
>