From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19361 invoked by alias); 5 Nov 2009 17:42:09 -0000 Received: (qmail 19352 invoked by uid 22791); 5 Nov 2009 17:42:08 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Nov 2009 17:42:00 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nA5HfxN1019630; Thu, 5 Nov 2009 12:41:59 -0500 Received: from omfg.slc.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nA5HfwNu005484; Thu, 5 Nov 2009 12:41:58 -0500 Message-ID: <4AF30E82.1000309@redhat.com> Date: Thu, 05 Nov 2009 17:42:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: Michael Matz CC: gcc@gcc.gnu.org Subject: Re: Do BLKmode bit-fields still exist? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg00108.txt.bz2 On 11/05/09 10:02, Michael Matz wrote: > Hello, > > while working on factoring out very old code (expand_assignment, > store_expr, store_field) I stumbled over the above question. There's code > all over the compiler that tries to handle BLKmode bit-field FIELD_DECLs > in a certain way, but I can't for the life of me construct anything that > actually results in such fields and I meanwhile assume that over the years > we simply can't generate them anymore. > > In the various bit-field accessors we sometimes use VOIDmode to mark an > access to a real bit-field (otherwise we wouldn't be able to differ > between an byte-aligned bit-field from a normal field, when looking at > only bitpos + bitlength). I'm not talking about that. I'm specifically > talking about bit-field FIELD_DECLs with DECL_MODE == BLKmode. > > From the code that tries to handle these it seems that this once meant an > "unaligned bit-field", which doesn't really make sense (we can handle all > situations and combinations of bitofs+bitlength in generic code). The > handling in store_field is especially bogus, it tries to handle the case > where the target (being a register) is aligned, the bit-field unaligned, > and goes over memory for this. That's bollocks, we can do nice bit-magic > for registers, however "aligned" the bit pattern is. > > Trying to trace where we could possibly construct such field decls we are > often careful to not store BLKmode into DECL_MODE of field decls. The > only place where we could get BLKmode is if the TYPE_MODE of the field > decls type is BLKmode. > > Now, theoretically we can get TYPE_MODE == BLKmode very easily. But not > for types from which bit-fields can be constructed. I'm pretty sure that > we can construct bit field FIELD_DECLs only for integer types. All > targets always have QImode through TImode available (in terms of > machmode.def, some targets explicitely disallow using e.g. TImode). So > all integer types that a user can write have a non-BLKmode. And that mode > is used as the DECL_MODE for the bit field FIELD_DECL, no matter how > large (depending on the language, excess size will give an error or round > down to the max size of the underlying type). > > Sometimes we're also using mode_for_size to set DECL_MODEs of bit-fields > (indirectly through types), but for bit field sizes that actually can be > constructed we always have a mode available. > > Hence, I don't see how we ever can construct a BLKmode bit-field > FIELD_DECL. > > 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). > To no avail. > > I tried to directly construct testcases which would possibly generate > BLKmode at least for architectures which have very limited bitwidth (AVR), > ala: > > typedef unsigned int TIint __attribute__((mode(DI))); > struct Unaligned{ > int a:7; > TIint b:63; > int c:8; > }__attribute__((packed)); > > and reading/storing into the fields, varying the mode, the bitsizes and > the like. To no avail again. > > Can somebody else come up with a testcase for his pet-target that triggers > the gcc_unreachables() in the patch? Pretty please? > Perhaps the PA when returning small unaligned structures? Hmm, probably not, I think we just needed to support copying BLKmode objects to/from registers to make that work. Nevermind. jeff