[Bug c++/28763] New: sizeof macro appears broken when bitfields are in structures

[Bug c++/28763] New: sizeof macro appears broken when bitfields are in structures

[mcvick_e at iname dot com]

I have compiled a sample application that demonstrates my problem (see below
for the sample code).

Basically when I have two structures, one that contains a bitfield and one that
does not, the sizeof macro acts differently between the two structures.
These structures are identical as far as content (size allocated), yet sizeof
fails for the structure containing the bitfield.

Accoding to the standards sizeof should report the total number of bytes within
a structure (including pad bytes for alignment).  However it appears as though
when the bitfield mechanism is used, this fails.

Here's a sample code specimen that duplicates the problem...


-------------------- sample app ----------------------------

struct foo1 {
   unsigned int     bar1 : 10;
   unsigned int     bar2 : 16;
   unsigned int     bar3 : 6;
   unsigned short   bar4;
};

struct foo2 {
   unsigned int    bar1;
   unsigned short  bar2;
};

int main(void) {

   static foo1   fubar1 = { 1, 2, 3, 4 };
   static foo2   fubar2 = { 1, 2 };

   static int    sizeofFubar1 = sizeof(foo1);
   static int    sizeofFubar2 = sizeof(foo2);

   return 0;
}

------------------------ end sample app -----------------------

Compile the application with:

c++ -gstabs+ -O2 -mno-bit-align -mcpu=603 -mtune=603 -mstrict-align -nostdlib
-fno-use-cxa-atexit -fcheck-new -fno-rtti -fno-exceptions -fsigned-char -c
sampleApp.cc -o sampleApp.o

if you run objdump -D -C -s -x -z sampleApp.o you will see that:

sizeof(foo1) reports 6
sizeof(foo2) reports 8

even though the two structures are identical in size and alignment
requirements.

We have 6600 occurrances of the sizeof macro in our software, so manually
padding or using the __attribute__((aligned(4))) isn't very tempting to
overcome this problem.

Thanks!


-- 
           Summary: sizeof macro appears broken when bitfields are in
                    structures
           Product: gcc
           Version: 4.0.1
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mcvick_e at iname dot com
 GCC build triplet: powerpc-eabi
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: powerpc-unknown-eabi


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

[Bug c++/28763] sizeof macro appears broken when bitfields are in structures

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-08-17 18:01 -------
Actually I don't think they have the same alignment requirement.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal


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

[Bug target/28763] sizeof macro appears broken when bitfields are in structures

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-08-17 18:04 -------
Can you quote the ABI document that says they have the same alignment?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |target
           Keywords|                            |ABI


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

[Bug target/28763] sizeof macro appears broken when bitfields are in structures

[mcvick_e at iname dot com]

------- Comment #3 from mcvick_e at iname dot com  2006-08-17 22:17 -------

Are you telling me that if I put two of those structures side by side in memory
that GNU will mis-align them even though I pass the flag -mstrict-align?  That
couldn't possibly be since the align flag states to use strict type alignment.

The GNU documentation also states that it will align to the smallest base type
of the bitfield.  Thus an 8-bit bitfield has 8-bit alignment, a 16-bit has
16-bit alignment, and a 32-bit has 32-bit alignment.

In the example I have shown, it clearly shows that a 32-bit bitfield is
defaulting to byte alignment as far as size allocation is concerned.

I've ran objdump on the file, and even though the size is reported as smaller,
it ALLOCATES all 32-bits for alignment reasons.

According to the C-Speficiation (which applies to C++ as well) ...

The size of an object of a structure type is the amount of storage necessary to
represent all components of that type, including any unused padding space
between or after the components. The rule is that the structure will be padded
out to the size the type would occupy as an element of array of such types.

So if you had an array of foo1's and an array of foo2's you would see exactly
the same alignment in memory.  Just that sizeof reports something incorrect. 
Thus if you were wanting to walk the array by say a byte pointer, and then went
to increment that byte pointer by the sizeof the structure, in one case you
would get correct behavior, and in the other you would get undefined or
incorrect behavior.


-- 


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

[Bug target/28763] sizeof macro appears broken when bitfields are in structures

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2006-08-17 22:19 -------
-mstrict-align does not do what you think it does.  What it does is say the
alignment requirements for loads/stores cannot be violated.


-- 


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

[Bug target/28763] sizeof macro appears broken when bitfields are in structures

[mcvick_e at iname dot com]

------- Comment #5 from mcvick_e at iname dot com  2006-08-17 22:28 -------

Additional information, if you insist on having an ABI then please go to this
link and look at pages 3-8 and 3-9.  It states that bitfields have the same
alignment restrictions as their base types (int for int) (short for short) etc.

http://refspecs.freestandards.org/elf/elfspec_ppc.pdf#search=%22powerpc%20abi%22


-- 


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

[Bug target/28763] sizeof macro appears broken when bitfields are in structures

[mcvick_e at iname dot com]

------- Comment #6 from mcvick_e at iname dot com  2006-08-17 22:35 -------
The spec also has multiple examples of big versus little endian layouts and how
they map in memory and what their alignment is.


-- 


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

[Bug target/28763] sizeof macro appears broken when bitfields are in structures

[mcvick_e at iname dot com]

------- Comment #7 from mcvick_e at iname dot com  2006-08-18 00:03 -------
(In reply to comment #4)
> -mstrict-align does not do what you think it does.  What it does is say the
> alignment requirements for loads/stores cannot be violated.

That's fine for the -mstrict-align, however as I stated in my last two comments
the ABI for the Power PC state that this is clearly incorrect behavior.


-- 


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

[Bug target/28763] sizeof macro appears broken when bitfields are in structures

[mcvick_e at iname dot com]

------- Comment #8 from mcvick_e at iname dot com  2006-08-22 16:42 -------

To try to be more helpful here,  after doing a large amount of investigation
into the signature of this problem, it's been observed that the GNU compiler
simply defines (or appears to define) a bitfield (regardless of it's type
(char, short, int)) as nothing more than a byte aligned entity.  Now if the
structure has a larger constituent primitive type (short, int) then the
structure will align to the largest primitive type.

For example.  One of the tests that I performed was simply to define two
structures.

struct foo1 {
   unsigned int    bar1 : 10;
   unsigned int    bar2 : 10;
   unsigned int    bar3 : 12;
   unsigned short  bar4;
   unsigned char   bar5;
};

struct foo2 {
   unsigned int    bar1 : 10;
   unsigned int    bar2 : 10;
   unsigned int    bar3 : 12;
   unsigned short  bar4;
   unsigned char   bar5;
   unsigned char   bar6;
};

foo1 will report the size as being 0x8 (which is correct), where as foo2 will
report the size as 0xA which is incorrect.  It's correct if the structure has
short alignment, however according to the ABI the structure should align to a
32-bit alignment because of the unsigned int bitfield.

Taking the same example above, if you substitute an unsigned int for the
unsigned short, then you get the alignment that you expect across all
situations.  Merely because an integer primitive type is embedded within the
structure.

I hope this helps some.


-- 


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

[Bug target/28763] wrong size of struct with some bit-fields on ppc-eabi

[mcvick_e at iname dot com]

------- Comment #9 from mcvick_e at iname dot com  2009-06-16 16:24 -------
Similar behavior has been seen against version 4.3.2.

Using the __attribute__ mechanism in the past has forced the hand of the
alignment issue most all of the time.  I say most all of the time because we
have uncovered a case where the __attribute__ mechanism will NOT suffice to
correct the alignment issue.

As stated the ABI for the PPC Processor states what the alignment requirements
are for bitfields, however here is a case that is only correctable by
restructuring the bitfield.  This in my opinion is poor coding practice as well
(however the original developer has long since been gone).


Code Snippet:


enum Status {
   LOCKED = 1,
   UNLOCKED = 2
};


struct foo {
   Status          lockStatus :  2;
   unsigned char   id         :  8;
   unsigned char   rId        :  8;
   unsigned short  unused     : 14;
};

struct foo2 {
   Status          lockStatus :  2;
   unsigned char   id         :  8;
   unsigned char   rId        :  8;
   unsigned short  unused     : 14;
} __attribute__((aligned(4))) __attribute__((packed));

struct foo3 {
   Status          lockStatus :  2;
   unsigned short  id         :  8;
   unsigned short  rId        :  8;
   unsigned short  unused     : 14;
} __attribute__((aligned(4))) __attribute__((packed));


int main(void) {

   static foo bar   = { LOCKED, 2, 10, 0 };  // Wrong alignment (64-bits)
   static foo1 bar1 = { LOCKED, 2, 10, 0 };  // Wrong alignment (64-bits)
   static foo2 bar2 = { LOCKED, 2, 10, 0 };  // Correct 32-bit alignment!

   // Do something so the compiler will not optimize the variables out in
   // gcc 4.3.2
   bar.lockStatus  = LOCKED;
   bar1.lockStatus = LOCKED;
   bar2.lockStatus = LOCKED;

   return 0;
}


-- 

mcvick_e at iname dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major


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

[Bug target/28763] wrong size of struct with some bit-fields on ppc-eabi

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal


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

[Bug target/28763] wrong size of struct with some bit-fields on ppc-eabi

[mcvick_e at iname dot com]

------- Comment #10 from mcvick_e at iname dot com  2009-06-16 16:30 -------
The __attribute__ mechanism works in 4.0.1, but was broken in the 4.3 series.
I wanted to clarify this as I think it's an important hint as to the root cause
of the problem.  In 4.0.1, packing and aligning worked via __attribute__ in
4.3.2, packing and aligning is broken.


-- 

mcvick_e at iname dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major


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

[Bug target/28763] wrong size of struct with some bit-fields on ppc-eabi

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2009-06-16 16:31 -------
The alignment of the variable is different from the alignment of the type ...


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal


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

[Bug target/28763] wrong size of struct with some bit-fields on ppc-eabi

[mcvick_e at iname dot com]

------- Comment #12 from mcvick_e at iname dot com  2009-06-16 16:55 -------
Can you be a bit more succinct here?  Because the comment just made sounds like
a bunch of foo foo stuff made up to ignore a genuine bug in the compiler.

Type byte has a byte alignment.
Type short has a 16-bit alignment.
Type int has a 32-bit alignment.

Especially in the case where strict-align is used.  We have a
processor/environment that requires strict alignment and we force it via the
compiler flags.

Furthermore, as stated numerous comments back with a link to the actual PPC
ABI, bitfields are to have a 32-bit alignment period.  Are you implying that
the fields within the structure are considered variables?  If so that statement
is incorrect as they are fields of a type declaration, which sum total 32-bits
(which match the alignment requirement of the ABI).

The fact that it was working correctly in 4.0.1 (with the __attribute__
specifications) tells me that this is a bug introduced in the compiler
following that release.

I think the reason this bug has been ignored for a very long time (as in opened
in June of 2006, so 3 years now), is that some core component of the compiler
relies on the bug.

Yes it's great to save space when possible, but not at the cost of incorrectly
violating the ABI.  I guess we will have to roll back to 4.0.1 because we can
at least get the __CORRECT__ behavior out of the compiler.  Which is a shame as
the new compiler had features that we were hoping to utilize.

This is a bug, a critical one at that, and needs to be fixed.  If you don't
know how to then just state that and stop hiding behind the ABI which worked
against you, and some obtuse commentary that sounded like a politicians
statement which meant nothing.


-- 

mcvick_e at iname dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major


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

[Bug target/28763] sizeof() and __attribute__ broken with bit-fields on ppc-eabi

[joseph at codesourcery dot com]

------- Comment #13 from joseph at codesourcery dot com  2009-06-16 17:26 -------
Subject: Re:  wrong size of struct with some bit-fields on
 ppc-eabi

On Tue, 16 Jun 2009, mcvick_e at iname dot com wrote:

> Furthermore, as stated numerous comments back with a link to the actual PPC
> ABI, bitfields are to have a 32-bit alignment period.  Are you implying that

There's no point in quoting an ABI document when you have chosen to use an 
option (-mno-bit-align in the original bug report) whose sole purpose is 
to deviate from the ABI.  Or when you are using features such as 
attributes that are outside the scope of the ABI document (which is an ABI 
for ISO C).

In fact I can only reproduce the described symptoms with -mbit-align, not 
-mno-bit-align - it appears the handling of this option may have been 
broken in the conversion to .opt files, which would be a genuine 
regression.  The default, without ABI-breaking options, is that both have 
size 8, which is in accordance with the latest ABI draft being developed 
in the Power.org ABI working group.

That is, the default behavior (for the original case without attributes) 
is correct, but the option that gives the size being 6 should be 
-mno-bit-align not -mbit-align, and this appears to have been broken since 
4.1.


-- 


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

[Bug target/28763] sizeof() and __attribute__ broken with bit-fields on ppc-eabi

[mcvick_e at iname dot com]

------- Comment #14 from mcvick_e at iname dot com  2009-06-16 17:42 -------
Thanks for the update.  I finally feel as though this is getting some teeth.  I
don't know what the default behavior of the 4.3.2 compiler is, however the
command line that I used to invoke this behavior excluded any bit-align
directives to the compiler.  the only flags specified were: -O2 -mtune=603
-mstrict-align -nostdlib -mcpu=603.


-- 


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

[Bug target/28763] sizeof() and __attribute__ broken with bit-fields on ppc-eabi

[joseph at codesourcery dot com]

------- Comment #15 from joseph at codesourcery dot com  2009-06-16 20:03 -------
Subject: Re:  sizeof() and __attribute__ broken with
 bit-fields on ppc-eabi

On Tue, 16 Jun 2009, mcvick_e at iname dot com wrote:

> Thanks for the update.  I finally feel as though this is getting some teeth.  I
> don't know what the default behavior of the 4.3.2 compiler is, however the
> command line that I used to invoke this behavior excluded any bit-align
> directives to the compiler.  the only flags specified were: -O2 -mtune=603
> -mstrict-align -nostdlib -mcpu=603.

There are several different testcases in this bug report.  Please make 
clear exactly what code you compiled with those options and that compiler 
version, what you observe about the compiler output that you think is 
wrong, what you think it should be and how the compiler was configured.


-- 


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

[Bug target/28763] sizeof() and __attribute__ broken with bit-fields on ppc-eabi

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28763

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
No feedback in over 5 years now.