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