From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-157719-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 9047 invoked by alias); 6 Nov 2009 09:47:20 -0000
Received: (qmail 9037 invoked by uid 22791); 6 Nov 2009 09:47:19 -0000
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (212.99.106.210)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Nov 2009 09:47:09 +0000
Received: from localhost (localhost [127.0.0.1]) 	by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 5D6AC29003A; 	Fri,  6 Nov 2009 10:47:07 +0100 (CET)
Received: from mel.act-europe.fr ([127.0.0.1]) 	by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) 	with ESMTP id zOaRuzy7y1s3; Fri,  6 Nov 2009 10:47:01 +0100 (CET)
Received: from [192.168.1.2] (83-153-87-54.rev.libertysurf.net [83.153.87.54]) 	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) 	(No client certificate requested) 	by mel.act-europe.fr (Postfix) with ESMTP id DC457290065; 	Fri,  6 Nov 2009 10:46:56 +0100 (CET)
From: Eric Botcazou <ebotcazou@adacore.com>
To: Michael Matz <matz@suse.de>
Subject: Re: Do BLKmode bit-fields still exist?
Date: Fri, 06 Nov 2009 09:47:00 -0000
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
Cc: gcc@gcc.gnu.org
References: <Pine.LNX.4.64.0911051725440.15566@wotan.suse.de>
In-Reply-To: <Pine.LNX.4.64.0911051725440.15566@wotan.suse.de>
MIME-Version: 1.0
Content-Type: text/plain;   charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200911061046.50176.ebotcazou@adacore.com>
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/msg00119.txt.bz2

> 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

  type Rec1 is record
    I1 : Integer;
    I2 : Integer;
    I3 : Integer;
  end record;

  type R2 is record
    B : Boolean;
    R : Rec1;
  end record;
  pragma Pack (R2);

end P;

(gdb) p debug_tree(0x2aaaaab2bdc0)
 <field_decl 0x2aaaaab2bdc0 r
    type <record_type 0x2aaaaabc64d0 p__rec1 sizes-gimplified visited BLK
        size <integer_cst 0x2aaaaab27f90 constant visited 96>
        unit size <integer_cst 0x2aaaaabd7d20 constant visited 12>
        align 32 symtab 0 alias set -1 canonical type 0x2aaaaabc64d0
        fields <field_decl 0x2aaaaab2bb40 i1 type <integer_type 0x2aaaaabc6580 
integer>
            nonaddressable SI file p.ads line 4 col 5
            size <integer_cst 0x2aaaaaaf1420 constant visited 32>
            unit size <integer_cst 0x2aaaaaaf1090 constant visited 4>
            align 32 offset_align 64
            offset <integer_cst 0x2aaaaaaf1b40 constant visited 0>
            bit offset <integer_cst 0x2aaaaaaf1b70 constant 0> context 
<record_type 0x2aaaaabc64d0 p__rec1> chain <field_decl 0x2aaaaab2bbe0 i2>> 
Ada size <integer_cst 0x2aaaaab27f90 96>
        reference_to_this <reference_type 0x2aaaaabc6630> chain <type_decl 
0x2aaaaab34540 p__rec1>>
    external packed bit-field BLK file p.ads line 11 col 5 size <integer_cst 
0x2aaaaab27f90 96> unit size <integer_cst 0x2aaaaabd7d20 12>
    align 8 offset_align 64 offset <integer_cst 0x2aaaaaaf1b40 0>
    bit offset <integer_cst 0x2aaaaaaf1180 type <integer_type 0x2aaaaab010b0 
bit_size_type> constant visited 8> bit_field_type <record_type 0x2aaaaabc64d0 
p__rec1> context <record_type 0x2aaaaabc6790 p__r2>>

We set DECL_BIT_FIELD in the front-end because the field is misaligned.

-- 
Eric Botcazou