Xref: utzoo gnu.gcc.bug:2574 comp.sys.hp:5610
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!hp4nl!ruuinf!piet
From: piet@cs.ruu.nl (Piet van Oostrum)
Newsgroups: gnu.gcc.bug,comp.sys.hp
Subject: Re: Bit field alignment on HP-UX
Message-ID: <3598@ruuinf.cs.ruu.nl>
Date: 13 Jul 90 08:16:46 GMT
References: <9007121103.AA19086@praxis.cs.ruu.nl>
Sender: news@ruuinf.cs.ruu.nl
Reply-To: piet@cs.ruu.nl (Piet van Oostrum)
Followup-To: gnu.gcc.bug
Distribution: gnu
Organization: Dept of Computer Science, Utrecht University, The Netherlands
Lines: 22
In-reply-to: piet@cs.ruu.nl (Piet van Oostrum)

I am still trying to get the whole scoop on bit-field alignment in the
HP-UX cc compiler on HP9000/300. I detected another case where the
bit-field was aligned, which is actually more in line with what others do -
if there were not a case that I don't understand -

struct test {
/*    char p;*/
    int a:14;
    int b:20;
    short c:5; } x;

This case (with the char p commented out) aligns b on a 2-byte boundary,
presumably because it would otherwise cross a 4-byte boundary, although
4-byte boundaries are not special in records. But if the char p is
inserted, no padding is done, the field a doesn't even start on a 2-byte
boundary. Now I don't understand what the underlying algorithm is. This
might even be a bug. 
-- 
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31-30-531806   Uucp:   uunet!mcsun!ruuinf!piet
Telefax:   +31-30-513791   Internet:  piet@cs.ruu.nl   (*`Pete')