[cfe-dev] [RFC] Opt-in vector of bool type
Richard Sandiford via cfe-dev
cfe-dev at lists.llvm.org
Fri May 15 07:40:40 PDT 2020
"Keane, Erich via cfe-dev" <cfe-dev at lists.llvm.org> writes:
>> The way i see it you are open to supporting this feature in Clang but there are LLVM bugs for <N x i1> types, which we may hit more often as a result, and then there is this unrelated Clang lvalue bug for attribute((vector_size)).
>
> I don't take this as a proper summary of my position. I was warning you about the issues in LLVM, however the biggest issue is the fact that a vector of i1s isn't individually addressable. Unless you have a way to produce an address for each individual element (which we don't, and is why std::vector<bool> uses a proxy return type), I don't think this fits in the type system.
FWIW, I think taking the address of a vector_size element is already
an error in clang. E.g.
-----------------------------------------------------------------
typedef unsigned int vec __attribute__((vector_size(16)));
vec v;
unsigned int *foo(void) { return &v[1]; }
-----------------------------------------------------------------
gives:
-----------------------------------------------------------------
foo.c:3:34: error: address of vector element requested
unsigned int *foo(void) { return &v[1]; }
^~~~~
1 error generated.
-----------------------------------------------------------------
GCC does accept this, but like others have said, I think the natural
thing would be to make it an error for bools even if it isn't for
other types. The set of operations supported by a vector type is
inevitably going to be influenced by the element type.
Definitely agree that the semantics need to be spelled out though. :-)
Thanks,
Richard
More information about the cfe-dev
mailing list