Note: I'm not entirely happy with the text of the diagnostics and I'm open to suggestions.
Fixes PR23505: Large bitfield: Assertion `getActiveBits() <= 64 && "Too many bits for uint64_t"' failed
Differential D71142
[Sema] Validate large bitfields Authored by Mordante on Dec 6 2019, 12:23 PM.
Details
Note: I'm not entirely happy with the text of the diagnostics and I'm open to suggestions. Fixes PR23505: Large bitfield: Assertion `getActiveBits() <= 64 && "Too many bits for uint64_t"' failed
Diff Detail Event TimelineComment Actions It seems fine and reasonable to reject this as a violation of an implementation limit. Can we actually support the full range 2^64 bits range, or would it be wiser to pick a smaller limit? (There's at least no point in allowing bit-widths that would mean the size of the bitfield doesn't fit in size_t, which means no more than 35 bits for a 32-bit target.)
Comment Actions The limits according to C are the size of the field's declared type (C17 6.7.2.1p4), but it seems that C++ decided it would make sense to turn the bits into padding bits (http://eel.is/c++draft/class.bit#1.sentence-6), so I guess a reasonable implementation limit would be SIZE_MAX for the target architecture (aka, sizeof(size_t) * CHAR_BIT bits).
Comment Actions Further testing revealed the Codegen already has decided the limit. struct CGBitFieldInfo {
/// The offset within a contiguous run of bitfields that are represented as
/// a single "field" within the LLVM struct type. This offset is in bits.
unsigned Offset : 16;
/// The total size of the bit-field, in bits.
unsigned Size : 15;So I'll look at using that limit. I also want to look at improving the diagnostics a bit more.
Comment Actions Maybe a bit offtopic, but it would be good to diagnose this case too: enum A {a, b, c = 8};
struct T {
enum A field : 2;
};GCC catches this bug. Comment Actions I created https://bugs.llvm.org/show_bug.cgi?id=44251 and will look at adding this warning. Comment Actions There are outstanding review comments, so I'm waiting for the patch author to address those, unless I've missed a question somewhere? | ||||||||||||||||||||||||
I feel like this situation should be an error rather than a warning -- what could the code possibly have meant?