This is the mail archive of the
mailing list for the GCC project.
RE: [PATCH] MS Bitfields for Interix
- From: "Donn Terry" <donnte at microsoft dot com>
- To: "Joern Rennecke" <joern dot rennecke at superh dot com>
- Cc: "Douglas B Rupp" <rupp at gnat dot com>,<gcc-patches at gcc dot gnu dot org>,<aoliva at redhat dot com>
- Date: Mon, 9 Sep 2002 08:25:26 -0700
- Subject: RE: [PATCH] MS Bitfields for Interix
I haven't looked at the patch content yet, and may not be able to for a
while. However, I think, regardless of the patch, that the following
There are three possible states when both attribute packed and pragma
pack are both used:
1) __attribute__((__packed__)) wins.
2) #pragma pack(n) wins
3) You get what you get.
In EITHER case 1 or case 2, it will do something "wrong" (in terms of
compatability) sometimes. What you describe below is one of those. If
had turned off #pragma pack and on __attribute__((packed)) explicitly,
(clearly) have worked. If you want "native" (MS compatabile) packing
time, you cannot EVER turn on __attribute__((packed)) because gnu
much tighter that that from #pragma pack.
If an application needs to be binary compatible with both types of
it MUST explicitly control the packing of each structure that it cares
And I don't see that there's any particular benefit in choosing any one
the three choices above over any of the others, and #3 is certainly
(If you really care, then it should be an ERROR to turn on both at once;
although a bit of a nuisance to code, it at least avoids the
of state three.)
So... pick one.
There's a fix for the variable length members stuff coming (from Doug).
From: Joern Rennecke [mailto:email@example.com]
Sent: Monday, September 09, 2002 5:25 AM
To: Donn Terry
Cc: Douglas B Rupp; firstname.lastname@example.org; email@example.com
Subject: Re: [PATCH] MS Bitfields for Interix
Donn Terry wrote:
> The intent of the patch (and my belief about the way it's implemented)
> is that it does the right thing for code which uses MS bitfields and
> optionally #pragma
> pack. If the user uses __attribute__((packed)) alone, he gets what
> gcc definition of that is. If the user codes __attribute__((packed))
> the MS
> bitfields option, he gets what he gets. (I suspect that in fact he'd
> get something
> more-or-less reasonable, but it seems worthless to try to specify
> exactly what that
> is, because mixing the options is of no particular value to anyone
> cares about
> specific bitfield compatability.)
> (Even as of today, that's the case, when both #pragma pack and
> are specified the packing rules take both into account.)
> The intent of the statement in the documentation was simply trying to
> say "there be dragons here if you do this" without being quite that
> blunt. Alternate phrasing
> is solicited if you don't like what's there. (The proper, but
> incorrect statement is "Don't mix the two, all bets are off if you
That is not acceptable. For the sh64-elf tool chain, MS bitfield layout
is part of the ABI. And the packed attribute is a gcc feature that is
used quite a lot, and it should do the same target independently. With
your patch, when I recompile libgcc, I get a lot of regressions, because
the floating point emulation code (which is used e.g. for operating
systems that don't want to have the overhead of saving floating point
registers before entering kernel code) uses the packed attribute to
describe the layout of IEEE numbers.
I have attached a patch that goes on top of yours that re-instates the
It does not, however, fix the compilation of files with structures with
variable sized members. I don't know what the MS rules are for these
(or do they not exist there?).
SuperH (UK) Ltd.
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330