This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 01 Dec 2011 11:23:41 +0000
- Subject: [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
- Auto-submitted: auto-generated
- References: <bug-50325-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325
--- Comment #26 from rguenther at suse dot de <rguenther at suse dot de> 2011-12-01 11:23:41 UTC ---
On Thu, 1 Dec 2011, iains at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325
>
> --- Comment #23 from Iain Sandoe <iains at gcc dot gnu.org> 2011-12-01 10:10:10 UTC ---
> there is nothing in the ABI doc:
>
> http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/LowLevelABI/100-32-bit_PowerPC_Function_Calling_Conventions/32bitPowerPC.html#//apple_ref/doc/uid/TP40002438-SW20
>
> that would suggest a different layout of bitfields in the two cases you cite.
>
> For varargs and K&R style function calls - it can be that double/vect values
> end up with a 4 byte alignment on the stack, when they are also passed in regs.
> (see PR 34311) - but I doubt that is relevant to this case.
store_bit_field/extract_bit_field are not about bitfields in the C
sense (despite their names). They are for setting/extracting a
subset of bits. Any structure layout issue wrt bitfields has to be
taken into account by the caller (so have any function-argument
layout specialities).
Richard.