http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325
--- Comment #16 from Iain Sandoe <iains at gcc dot gnu.org> 2011-11-19 14:56:09 UTC --- I had a quick look... actually, I suspect that the BLKmode constraint you originally had is, in fact, correct. we are talking about bit fields - i.e contiguous blocks of bits - so, if memory serves me correctly, we are not in the realm of padding rules (but I need to double-check the ABI doc). so: When BIG-Endian && !BLKMode ... you are copying the data in reverse order (pushing the bitfield into the least significant bits of the destination) - ergo the remaining fragment needs to be stored at the "higher" sub-address of the fragmented last word. When BE && BLKmode you are copying in ascending address order (i.e. aligning the bits to the MS) .. ergo the remaining fragment needs to be copied to the "lower" sub-address of the last fragmented word. In saying this, of course, that does not imply that I've checked that the basic choice is correct.
