================
@@ -116,6 +116,11 @@ class CIRBaseBuilderTy : public mlir::OpBuilder {
}
mlir::TypedAttr getZeroInitAttr(mlir::Type ty) {
+ if (auto bitFieldTy = mlir::dyn_cast<cir::BitFieldType>(ty)) {
+ assert(bitFieldTy.ownsBytes() &&
----------------
andykaylor wrote:
This is substantially different from the other cases you cite. This is a
function in the builder and is called from code generator contexts, not a
verifier, and so we don't really have a clean way to report the error here. If
this function is called for a bitfiled type that doesn't own data, that's a
programming error, not a parsing error, so an assert is appropriate here.
If you try to create an initializer using a `#cir.zero` for a bitfield with no
storage, it gets rejected during parsing. For instance,
```
!s32i = !cir.int<s, 32>
!u8i = !cir.int<u, 8>
!rec_S = !cir.struct<"S" {
bitfield !cir.bitfield<!u8i, [#cir.bitfield_decl<!s32i, 3>]>,
empty !cir.bitfield<[#cir.bitfield_decl<!s32i, 0, unnamed>]>,
bitfield !cir.bitfield<!u8i, [#cir.bitfield_decl<!s32i, 3>]>}>
module {
cir.global external dso_local @s = #cir.const_record<{
#cir.int<1> : !u8i,
#cir.zero : !u8i,
#cir.int<0> : !u8i}> : !rec_S {alignment = 4 : i64}
}
```
Give me this:
```
zero.cir:8:55: error: number of elements must match
cir.global external dso_local @s = #cir.const_record<{
```
You get the same error if you try to explicitly use `#cir.zero :
!cir.bitfield<[#cir.bitfield_decl<!s32i, 0, unnamed>]>` in the initializer.
https://github.com/llvm/llvm-project/pull/221030
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
