From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11418 invoked by alias); 5 Nov 2009 17:03:01 -0000 Received: (qmail 10704 invoked by uid 22791); 5 Nov 2009 17:02:59 -0000 X-SWARE-Spam-Status: No, hits=-7.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI X-Spam-Check-By: sourceware.org Received: from cantor.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Nov 2009 17:02:55 +0000 Received: from relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id BC2AF93EE3 for ; Thu, 5 Nov 2009 18:02:52 +0100 (CET) Date: Thu, 05 Nov 2009 17:03:00 -0000 From: Michael Matz To: gcc@gcc.gnu.org Subject: Do BLKmode bit-fields still exist? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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/msg00104.txt.bz2 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? Ciao, Michael. Index: expr.c =================================================================== --- expr.c (revision 153935) +++ expr.c (working copy) @@ -5795,6 +5887,7 @@ store_field (rtx target, HOST_WIDE_INT b if (bitsize != (HOST_WIDE_INT) GET_MODE_BITSIZE (GET_MODE (target))) emit_move_insn (object, target); + gcc_unreachable (); store_field (blk_object, bitsize, bitpos, mode, exp, type, alias_set, nontemporal); @@ -5979,7 +6012,10 @@ get_inner_reference (tree exp, HOST_WIDE if (!DECL_BIT_FIELD (field)) mode = DECL_MODE (field); else if (DECL_MODE (field) == BLKmode) - blkmode_bitfield = true; + { + blkmode_bitfield = true; + gcc_unreachable (); + } *punsignedp = DECL_UNSIGNED (field); }