[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)

["hubicka at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #26 from hubicka at gcc dot gnu dot org  2006-01-17 21:07 -------
Hi,
I've looked into it for some time, so here is my POV of this ugly issue.
It seems to me that from documentation of EMPTY_FIELD_BOUNDARY in gccint it is
clear that it
should be ignored when PPC_BITFIELD_TYPE_MATTERS is set.  This seems pretty
correct in Jason's version of code to me.

Corcerning the value of EMPTY_FIELD_BOUNDARY in i386.h, I actually introduced
it back in 2001 while doing the 64bit changes.  I am pretty sure I didn't much
worried about actual meaning of the value,
I just looked for "32" and was trying to decide whether the value means "32" or
size of word.  The alignment seemed to be more word related.
The behaviour in 3.0.4 is to set the alignment according to type of bitfield
(is PPC_BITFIELD_TYPE_MATTERS).  So struct a {char a; short :0;} has size 2. 
This seems to be handled by the last hunk overwriting EMPTY_FIELD_BOUDNARY
Steven quotes in his analysis that has no equivalent in Jason's code.
I think it should be added into the conditional PPC_BITFIELD_TYPE_MATTERS in
stor layout at the place PPC_BITFIELD_TYPE_MATTERS is processed now, so I will
try to test the patch tomorrow.
I would also suggest removing the ignored EMPTY_FIELD_BOUNDARY from i386.h.

Does something from the above seem to make sense? (this is really slipperly)
Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275