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

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

[nathan]

Synopsis: Changed bitfield allocation strategy in g++ 3.1.1

Responsible-Changed-From-To: unassigned->nathan
Responsible-Changed-By: nathan
Responsible-Changed-When: Mon Jul 29 08:50:30 2002
Responsible-Changed-Why:
    patching
State-Changed-From-To: open->analyzed
State-Changed-By: nathan
State-Changed-When: Mon Jul 29 08:50:30 2002
State-Changed-Why:
    confirmed.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7432

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

[Nathan Sidwell]

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

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

[nathan]

Synopsis: Changed bitfield allocation strategy in g++ 3.1.1

State-Changed-From-To: analyzed->closed
State-Changed-By: nathan
State-Changed-When: Mon Jul 29 10:52:24 2002
State-Changed-Why:
    not a bug - see attached mail for description

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7432

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

[grigory]

>Number:         7432
>Category:       c++
>Synopsis:       Changed bitfield allocation strategy in g++ 3.1.1
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 29 05:26:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Grigory Zagorodnev
>Release:        3.1.1
>Organization:
>Environment:
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ./configure --enable-threads
>Description:
Attached test case expecting the size of complete structure C to be 16 bytes.

  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).

I do not see any reason to enlarge space taken by the structure C, moreover I do not see any ABI acknowledgment for this. 

So, the bitfield allocation strategy looks to be erroneously changed.
>How-To-Repeat:
$g++ foo.cpp
$a.out

Actuall results (output):
sizeof(C) = 24
offsetof(C, d) = 17

Expected results (output):
sizeof(C) = 16
offsetof(C, d) = 13
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: