================
@@ -11772,6 +11772,31 @@ bool VectorExprEvaluator::VisitCastExpr(const CastExpr
*E) {
return false;
return Success(ResultEls, E);
}
+ case CK_IntegralToFloating:
+ case CK_FloatingToIntegral:
+ case CK_IntegralCast:
+ case CK_FloatingCast:
+ case CK_FloatingToBoolean:
+ case CK_IntegralToBoolean: {
+ // These casts apply element-wise when the source is a vector type.
+ assert(SETy->isVectorType() && "expected vector source type");
+ APValue SrcVal;
+ if (!EvaluateVector(SE, SrcVal, Info))
+ return Error(E);
+
+ assert(SrcVal.getVectorLength() == NElts);
+ QualType SrcEltTy = SETy->castAs<VectorType>()->getElementType();
+ QualType DstEltTy = VTy->getElementType();
+ const FPOptions FPO = E->getFPFeaturesInEffect(Info.Ctx.getLangOpts());
+
+ SmallVector<APValue, 4> ResultEls(NElts);
+ for (unsigned I = 0; I < NElts; ++I) {
+ if (!handleScalarCast(Info, FPO, E, SrcEltTy, DstEltTy,
+ SrcVal.getVectorElt(I), ResultEls[I]))
+ return false;
----------------
llvm-beanz wrote:
I struggled a bit with this myself as I was writing the patch. I'm not super
familiar with this corner of clang, but my concern was that there isn't really
consistent usage of `Error(E)` vs `false`. I _think_ using `Error(E)` in the
wrong place could cause duplicated diagnostics, so I just matched the way other
calls to `handleScalarCast` are handled in the code. It seems like generally
`handleScalarCast` emits diagnostics within itself.
Despite writing a few tests that run through this line I haven't been able to
observe any differences in diagnostic output. So maybe my understanding here is
wrong.
I'll apply your suggestion in my next update with an additional test case that
triggers errors through this path.
https://github.com/llvm/llvm-project/pull/195173
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
