Error: array has sizeless element type 'vint16m1_t' (aka '__rvv_int16m1_t')

[Shuangxie0708]

I want to define multiple variables of size vint16m1_t. so I use below :
vint16m1_t H_img[4][4], Wcal_real[4][4], Wcal_img[4][4];

But it has below error:
error: array has sizeless element type 'vint16m1_t' (aka '__rvv_int16m1_t')
vint16m1_t H_img[4][4], Wcal_real[4][4], Wcal_img[4][4];

How should I define the variables?

[eopXD]

The C standard states that

An array type describes a contiguously allocated nonempty set of objects with a
particular member object type, called the element type. 36)

With

36. Since object types do not include incomplete types, an array of incomplete type cannot be constructed.

Which incomplete types are defined as,

incomplete types (types that describe objects but lack information needed to determine their sizes).

The RVV types are size-less types and currently the compiler operates respects the language standard.

---

On the other hand, we do successfully have tuple types in the compiler, which is equivalent to declaring an array of RVV types with a known constant length. So I think this should be something we need to work through in the compiler, allowing a constant size array of RVV types to be declared.

This is currently left out in the specification, as we do not support this feature yet. This is indeed an item we can look into. Thank you for raising this.

[kito-cheng]

Just dump few note from my brain: It's not only implementation issue, but also a language spec issue, we need very carefully to review all array related part in the C/C++ spec when we decide to support array with scalable vector type.

[sh1boot]

I have the same problem with structs. If I want to wrap a vector type to add some static functions or consts, or even just to unique-ify a type for overloading, that's a no-go.

I also tried a std::tuple<> wrapper, but no luck there either.

[dzaima]

Some previous discussion of structs is at #110; but basically it breaks many things about structs (sizeof & offsetof would cease to be constants; reading fields, even non-vector ones, might involve vlenb computations).

(perhaps it might be easier for compilers to support structs that contain only a single member of an RVV type, and behave largely as that member and not as a struct (other than methods/overloading), though that's a separate discussion and would likely still be problematic or at least weird)

[dzaima]

On the original question here about array variables - even if vint32m1_t arr[4]; worked, you couldn't index the array with like arr[3] as indexing isn't defined for a pointer to a sizeless type.

And with the messiness of having to manually do pointer arithmetic with __riscv_vlenb() as-is, needing to write out the manual VLA char arr[__riscv_vlenb()*4]; isn't that significant of a problem imo (and really makes it easier as you can directly do pointer arith with a char* but not with a vint32m1_t*).

Defining indexing of a pointer to an RVV vector could make sense, but that's a pretty different discussion.