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 Mordante on Dec 6 2019, 12:23 PM. Authored by
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?