[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[iains at gcc dot gnu.org]

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.