This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]