We already correctly rejected:
typedef __attribute__((vector_size(16))) _BitInt(4) Ty;
but we would assert with:
typedef __attribute__((ext_vector_type(4))) _BitInt(4) Ty;
Now we issue the same error in both cases.
- Improve compile-times with large dynamic array allocations with trivial
constructors. This fixes
`Issue 56774 <https://github.com/llvm/llvm-project/issues/56774>`_.
+- No longer assert/miscompile when trying to make a vectorized ``_BitInt`` type
+ using the ``ext_vector_type`` attribute (the ``vector_size`` attribute was
+ already properly diagnosing this case).
Improvements to Clang's diagnostics
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
// We explictly allow bool elements in ext_vector_type for C/C++.
bool IsNoBoolVecLang = getLangOpts().OpenCL || getLangOpts().OpenCLCPlusPlus;
if ((!T->isDependentType() && !T->isIntegerType() &&
- !T->isRealFloatingType()) ||
+ !T->isRealFloatingType()) || T->isBitIntType() ||
(IsNoBoolVecLang && T->isBooleanType())) {
Diag(AttrLoc, diag::err_attribute_invalid_vector_type) << T;
return QualType();
// Reject vector types:
// expected-error@+1{{invalid vector element type '_BitInt(32)'}}
typedef _BitInt(32) __attribute__((vector_size(16))) VecTy;
+// expected-error@+1{{invalid vector element type '_BitInt(32)'}}
+typedef _BitInt(32) __attribute__((ext_vector_type(32))) OtherVecTy;
// Allow _Complex:
_Complex _BitInt(3) Cmplx;