[llvm-commits] [125160] Better support for variable size struct fields.

[Duncan Sands]

On Sunday 25 March 2007 10:43:57 Duncan Sands wrote:
> > Is this already fixed?

Here is my proposed fix.  The problem was due to zero-sized
bitfields, such as
	struct Z { int :0; } z;
Historically, no field was created for such a bitfield, and
getLLVMFieldFor would return ~0U, i.e no field found.  In my
patch "Better support for variable size struct fields" I added
an assertion that checks that getLLVMFieldFor always finds a
field, and of course it fires in this case.  How to solve this?
There are basically two choices: (1) accept that sometimes there
is no field, and return ~0U; (2) make sure that a field always
exists.  I chose (2) because it is more uniform, and means that
the rest of llvm-gcc doesn't need to know about special cases of
gcc fields that don't map to an LLVM field.  [You could object
that in C it is not possible to access such a field, so the rest
of the llvm-gcc code would not need to worry about seeing a ~0U
index; however we are not dealing with C, we are dealing with gimple
and many languages, and it is not clear to me that such a field can
never be referred to].

With this patch a gcc field is mapped to an LLVM field if and only if
it has a constant offset from the start of the struct.

While writing it I discovered some other related fun ways to crash the
compiler, so the patch fixes them too (this explains the large number
of attached testcases).  There are basically three changes:
(1) use DECL_SIZE to determine if a field has zero size, not TYPE_SIZE.
Using TYPE_SIZE here was almost certainly a bug (DECL_SIZE is used
everywhere else, and is what the gcc documentation says you should use),
though it could be a subtlety.  As a result of this change, a zero-width
bitfield is now considered to be a zero size field, which wasn't the case
before.
(2) if a zero-width field doesn't live inside an existing field, output a
zero width struct for it.  This has to be done, since such a bitfield could
be the only field, and at least one field is needed.  Thus the above example
maps to { {} }.  This part of the patch also fixes a long-standing bug in
which a bitfield following a zero-sized struct in a packed struct would cause
an assert failure.
(3) fix getLLVMFieldFor so it can handle the following possibilities:
(a) a zero-sized field follows padding (this means that CurFieldNo may need
to be advanced over the padding); (b) a zero-sized field lives inside a non-zero
sized field.

Bootstraps and passes "make check".  Doesn't cause any build failures in the
full testsuite (the run-time failures I'm seeing seem to be due to the current
InstCombine issues).

Best wishes,

Duncan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2007-03-26-MultipleZeroWidthBitfields.c
Type: text/x-csrc
Size: 60 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20070326/cdef912c/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2007-03-26-ZeroWidthBitfield.c
Type: text/x-csrc
Size: 52 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20070326/cdef912c/attachment-0001.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2007-03-26-ZeroWidthBitfieldAfterPadding.c
Type: text/x-csrc
Size: 68 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20070326/cdef912c/attachment-0002.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2007-03-26-SandwichedZeroWidthBitfield.c
Type: text/x-csrc
Size: 93 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20070326/cdef912c/attachment-0003.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2007-03-26-BitfieldAfterZeroWidth.c
Type: text/x-csrc
Size: 107 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20070326/cdef912c/attachment-0004.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zero_width.diff
Type: text/x-diff
Size: 4281 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20070326/cdef912c/attachment.diff>