Hi,
We have this interesting ABI change between GCC 3.3 and GCC 3.4, which
we are tracking in PR22275. A test case for the problem is this:
--------------------------------------------
typedef unsigned long size_t;
#ifndef offsetof
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
#endif
extern void abort (void) __attribute__((noreturn));
#pragma pack(1)
typedef struct
{
int a : 16;
int : 0;
int b;
} c;
int
main (void)
{
printf ("%d\n", offsetof (c, b));
if (sizeof (c) != 8)
abort ();
}
--------------------------------------------
GCC 3.3 and earlier pass this test case. The offset of field "b" is 4
and the size of "c" is 8. But GCC 3.4 and later give "b" an offset of
2 and the size of "c" is now 6. The change in behavior is the result
of a patch from Jason from 2 and a half years ago, and the test case
was reduced from WINE.
I believe this piece of C code is valid C99, because of C99's 6.7.2.1
sub 3, which says:
"The expression that specifies the width of a bit-field shall be an
integer constant expression that has nonnegative value that shall not
exceed the number of bits in an object of the type that is specified
if the colon and expression are omitted. If the value is zero, the
declaration shall have no declarator."
Of course, the semantics of "int : 0" are not defined by C99 for packed
structs. As far as I can tell, extend.texi doesn't discuss this case,
so we need to come up with something that makes sense.
We discussed this briefly on IRC. We have only two options AFAICT:
1) ignore the ": 0" field completely. This is what we seem to do
since Jason's patch was commited.
2) when we see :0 align to the next unit, which seems to be the
behavior of GCC pre-3.4.
Jason suggested that it looks like they want it to mean "align the
next field despite pragma pack". So that is option (2),
Is this acceptable to everyone here?
Gr.
Steven
P.S. Just as an interesting observation: Intel ICC 8.0 follows the GCC
3.3 behavior, but ICC 9.0 breaks in the same way that GCC 3.4 and
later do :-)
