Do BLKmode bit-fields still exist?

[Jeff Law]

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