Do BLKmode bit-fields still exist?

[Michael Matz <matz@suse.de>]

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);
     }