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

["iains at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #24 from Iain Sandoe <iains at gcc dot gnu.org> 2011-12-01 10:25:33 UTC ---
well.. sorry, that might be a bogus comment 
- it depends on whether the following can be interpreted to allow a different
layout on the stack from 'normal' memory.

Since the embedding alignment of bitfields doesn't seem to be specifically
referenced in the struct. layout section (pp10 in the pdf) - other than saying
that it's 'natural' if the first element and 4 bytes otherwise.

but page14 in the pdf of the ABI doc has:

1. All nonvector parameters are aligned on 4-byte boundaries. 
2. Vector parameters are aligned on 16-byte boundaries. 
3. Noncomposite parameters (that is, parameters that are not arrays or data
structures) smaller than 4 bytes 
occupy the high-order bytes of their 4-byte area. 
4. Composite parameters (arrays, structures, and unions) 1 or 2 bytes in size
occupy the low-order bytes 
of their 4-byte area. They are preceded by padding to 4 bytes. 
This rule is inconsistent with other 32-bit PowerPC binary inter faces. In AIX
and Mac OS 9 (and earlier), 
padding bytes always follow the data structure even in the case of composite
parameters smaller than 
4 bytes. 
5. Composite parameters 3 bytes or larger in size occupy the high-order bytes
of their 4-byte area. They 
are followed by padding to make a multiple of 4 bytes, with the padding bytes
being undefined. 

again no specific mention of bitfields ...