================
@@ -14770,15 +14770,16 @@ bool
ArrayExprEvaluator::VisitCXXParenListOrInitListExpr(
Value = SL->getCodeUnit(I);
if (DestTy->isIntegerType()) {
Result.getArrayInitializedElt(ArrayIndex) = APValue(Value);
- } else {
- assert(DestTy->isFloatingType() && "unexpected type");
+ } else if (DestTy->isRealFloatingType()) {
const FPOptions FPO =
Init->getFPFeaturesInEffect(Info.Ctx.getLangOpts());
APFloat FValue(0.0);
if (!HandleIntToFloatCast(Info, Init, FPO, EmbedS->getType(), Value,
DestTy, FValue))
return false;
Result.getArrayInitializedElt(ArrayIndex) = APValue(FValue);
+ } else {
+ return false;
----------------
efriedma-quic wrote:
An `#embed` is formally, according to the standard, purely a preprocessor
construct: it just produces a sequence of comma-separated integers. As an
optimization, we don't actually represent it this way in init lists: we
optimize it to an EmbedExpr. And then when SemaInit analyzes the
initialization, it decides whether to keep it as a single array, or separate it
out into individual elements. If it's simple, it keeps a single array; if it's
too complicated to analyze, it splits the EmbedExpr into multiple EmbedExprs
for each field. For example, the following gets split:
```
struct S { int x,y;};
struct S s[] = {
#embed "/tmp/z"
};
```
-----
InitListChecker::CheckArrayType chooses whether to keep an EmbedExpr intact,
or split it. My suggestion is that we should split more aggressively. Keeping
EmbedExprs intact is just a performance optimization, and we should only care
about preserving that performance optimization if the user is doing something
reasonable. We don't care about the performance of initializing an array of
pointers with `#embed`.
https://github.com/llvm/llvm-project/pull/182257
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
