From: jeffdbREMOVETHIS AT goodnet DOT com (Mikey) Subject: Re: structure packing/allingment 29 Apr 1998 18:07:24 -0700 Message-ID: <3547c180.23407674.cygnus.cygwin32.developers@smtp.goodnet.com> References: Reply-To: jeffdbREMOVETHIS AT goodnet DOT com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: cygwin32-developers AT cygnus DOT com -fno-strength-reduce Because a long time ago when this was a problem under linux I read several articles that pointed out that with the paucity of general purpose registers in the x86 strength reduction was of dubious benefit at best, and probably actually slowed down the code because of forcing extra moves to memory. (That's a remembered quote BTW :) #define PCC_BITFIELD_TYPE_MATTERS 0 this was defined in the emx port, and the guy apparently knows what he is doing with structure alignment. ( I couldn't run the test at the end because I don't have cl.exe :) If this is handeled somewhere else in the gcc config files, I couldn't find it. Would someone who has vc++ please compile the example at the end and report the results? `PCC_BITFIELD_TYPE_MATTERS' Define this if you wish to imitate the way many other C compilers handle alignment of bitfields and the structures that contain them The behavior is that the type written for a bitfield (`int', `short', or other integer type) imposes an alignment for the entire structure, as if the structure really did contain an ordinary field of that type. In addition, the bitfield is placed within the structure so that it would fit within such a field, not crossing a boundary for it. Thus, on most machines, a bitfield whose type is written as `int' would not cross a four-byte boundary, and would force four-byte alignment for the whole structure. (The alignment used may not be four bytes; it is controlled by the other alignment parameters.) If the macro is defined, its definition should be a C expression; a nonzero value for the expression enables this behavior. Note that if this macro is not defined, or its value is zero, some bitfields may cross more than one alignment boundary. The compiler can support such references if there are `insv', `extv', and `extzv' insns that can directly reference memory. The other known way of making bitfields work is to define `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then every structure can be accessed with fullwords. Unless the machine has bitfield instructions or you define `STRUCTURE_SIZE_BOUNDARY' that way, you must define `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value. If your aim is to make GNU CC use the same conventions for laying out bitfields as are used by another compiler, here is how to investigate what the other compiler does. Compile and run this program: struct foo1 { char x; char :0; char y; }; struct foo2 { char x; int :0; char y; }; main () { printf ("Size of foo1 is %d\n", sizeof (struct foo1)); printf ("Size of foo2 is %d\n", sizeof (struct foo2)); exit (0); } If this prints 2 and 5, then the compiler's behavior is what you would get from `PCC_BITFIELD_TYPE_MATTERS'. On Wed, 29 Apr 1998 14:10:49 -0500 (CDT), you wrote: >On Tue, 28 Apr 1998, Mikey wrote: > >> Ok, I tried the following changes with >> egcs 1.0.2 + link-compat-ld + Mumit's __declspec.dif >> and they seem to work, at least bitmaps >> open without __attribute__((packed)) >> added to the SDK headers. FINALLY!!! > >I believe my #pragma was rejected a long time ago that did this, but that >was before days of egcs. > >> add -m486 like this >> >> -#define CPP_PREDEFINES "-Di386 -D_WIN32 \ >> +#define CPP_PREDEFINES "-m486 -Di386 -D_WIN32 \ > >Thanks for trying this out, and hash out pshpack8.h etc. We do need a more >general scheme than having to define -m486 etc however. I haven't looked >at this problem in a *long* time, so don't know what the current status >is. > >> +/* Bitfields may cross alignment boundaries. */ >> +#undef PCC_BITFIELD_TYPE_MATTERS >> +#define PCC_BITFIELD_TYPE_MATTERS 0 > >Why this? > >> *cc1: >> %(cc1_cpu) -fno-strength-reduce -malign-jumps=2 -malign-loops=2 -malign-functions=2 >> >> *cc1plus: >> -fno-strength-reduce -malign-jumps=2 -malign-loops=2 -malign-functions=2 >> > >Out of curiosity, why are you using -fno-strength-reduce for egcs? As far >as I know, it's not a problem anymore since the patches in 2.7.2.3+. Or is >the bug still there in some form? > >Mumit > ===================================================== Linux a platform built by, and for users, standing on the firm legs of reliability, and speed. Microsoft Windows, a platform without a leg to stand on. (jeffdbREMOVETHIS AT goodnet DOT com) delete REMOVETHIS from the above to reply Mikey