Re: c++/7432: Changed bitfield allocation strategy in g++ 3.1.1

[Nathan Sidwell <nathan@codesourcery.com>]

The following reply was made to PR c++/7432; it has been noted by GNATS.

From: Nathan Sidwell <nathan@codesourcery.com>
To: grigory@stl.sarov.ru
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/7432: Changed bitfield allocation strategy in g++ 3.1.1
Date: Mon, 29 Jul 2002 18:50:35 +0100

 grigory@stl.sarov.ru wrote:
 
 >   struct C {
 >     char c;
 >     int i : 67;
 >     char d;
 >   };
 > 
 > This is what been offered by GNU compiler for a long time. GCC 3.1.1
 > compiler gives another size of the structure (24 bytes).
 It turns out that gcc and g++ disagreed about this. the 3.1.1
 behaviour is the same for both (which is good).
 
 > I do not see any reason to enlarge space taken by the structure C,
 The behaviour should be the same for C and C++ (gory details to follow)
 
 > moreover I do not see any ABI acknowledgment for this.
 No, sorry - we had not realized this change had occurred.
 
 Intel's i86 C ABI allocates long longs in structures on a four byte
 boundary, even though the naked alignment of a long long is 8 bytes.
 Thus for the non-bitfield case
 	struct C {
 		char c;
 		long long i;
 		char e;
 	};
 will allocate i at offset 4 and e at offset 12, the size will be 16
 and the overall alignment will be 4. However, when we make i a 64 bit
 bitfield,
 	struct C {
 		char c;
 		long long i : 64;
 		char e;
 	};
 the behaviour is different. PCC_BITFIELD_TYPE_MATTERS comes into play
 and does not allow a bitfield of type T to straddle the natural
 alignment of T. So i is placed at offset 8.
 
 for your case
 	struct C {
 		char c;
 		int i : 67;
 		char e;
 	};
 as int has 32 bits, we find the largest integral type which has <= 67
 bits, this is long long. The bitfield is treated as a long long
 bitfield of 67 bits, that is 64 bits of accessible data and 3 bits
 of unreachable padding.
 
 G++'s behaviour now matches that of gcc - so PoD layouts are compatible.
 
 nathan
 
 -- 
 Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
          'But that's a lie.' - 'Yes it is. What's your point?'
 nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org