rjmccall added a comment. In http://reviews.llvm.org/D11034#201981, @uweigand wrote:
> In http://reviews.llvm.org/D11034#201452, @rjmccall wrote: > > > Good catch! > > > > The better fix would be to ignore the bitfield's abstract storage alignment > > and instead use the base l-value's alignment, adjusted with > > alignmentAtOffset to the offset of the bitfield's storage. This ensures we > > get the right alignment when the base l-value is *over*-aligned: in a > > packed struct, bitfield storage at offset 0 will have alignment 1, but if > > the packed struct itself is known to have alignment 4 (e.g., if it is > > embedded in an unpacked struct), then we still know that the storage has > > alignment 4.alignmentAtOffset(0) == 4. > > > Good point. Unfortunately, at the point the access is generated, there > doesn't appear to be an easy way to retrieve the offset of the bitfield's > storage relative to the surrounding struct. This value is present as > "StartOffset" in CGRecordLowering::setBitFieldInfo, but is not actually > stored in the CGBitFieldInfo struct. Maybe instead of the StorageAlignment > field, the CGBitFieldInfo struct should instead have a StorageOffset field? Storing the offset makes sense. If this means that we don't otherwise need StorageAlignment — probably true — then we can drop that at the same time. http://reviews.llvm.org/D11034 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
