This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
binary
compatability) sometimes.  What you describe below is one of those.  If
you
had turned off #pragma pack and on __attribute__((packed)) explicitly,
it would
(clearly) have worked.  If you want "native" (MS compatabile) packing
all the
time, you cannot EVER turn on __attribute__((packed)) because gnu
packing is
much tighter that that from #pragma pack.

If an application needs to be binary compatible with both types of
packing,
it MUST explicitly control the packing of each structure that it cares
about.
And I don't see that there's any particular benefit in choosing any one
of
the three choices above over any of the others, and #3 is certainly
easier.

(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
possiblility
of state three.)

So... pick one.

There's a fix for the variable length members stuff coming (from Doug).

Donn

-----Original Message-----
From: Joern Rennecke [mailto:joern.rennecke@superh.com] 
Sent: Monday, September 09, 2002 5:25 AM
To: Donn Terry
Cc: Douglas B Rupp; gcc-patches@gcc.gnu.org; aoliva@redhat.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
the
> standard
> gcc definition of that is. If the user codes __attribute__((packed))
and
> 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
that
> cares about
> specific bitfield compatability.)
> 
> (Even as of today, that's the case, when both #pragma pack and
> __attribute__((packed))
> 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
possibly
> politcally
> incorrect statement is "Don't mix the two, all bets are off if you
> try".)

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
packed atribute.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]