================
@@ -1138,24 +1139,44 @@ void CodeGenFunction::EmitNewArrayInitializer(
CharUnits StartAlign = CurPtr.getAlignment();
unsigned i = 0;
+ auto AdvanceToNextElement = [&]() {
+ CurPtr = Address(Builder.CreateInBoundsGEP(CurPtr.getElementType(),
+ CurPtr.emitRawPointer(*this),
+ Builder.getSize(1),
+ "array.exp.next"),
+ CurPtr.getElementType(),
+ StartAlign.alignmentAtOffset((++i) * ElementSize));
+ };
for (const Expr *IE : InitExprs) {
// Tell the cleanup that it needs to destroy up to this
// element. TODO: some of these stores can be trivially
// observed to be unnecessary.
if (EndOfInit.isValid()) {
Builder.CreateStore(CurPtr.emitRawPointer(*this), EndOfInit);
}
+ // An EmbedExpr can initialize more than one array element.
+ const auto *EmbedS = dyn_cast<EmbedExpr>(IE->IgnoreParenImpCasts());
+ if (EmbedS && EmbedS->getDataElementCount() > 1) {
----------------
akash-manna-sky wrote:
Sorry for the confusion — since `_Complex` isn't integer/floating,
`HandleEmbed` never takes the multi-element path for it, so f13's `limit(2)`
embed is sliced by Sema into two *single-element* `EmbedExpr`s, each wrapped in
`IntegralRealToComplex`. Those are what reach this loop: without the count
check they take this branch and `EmitScalarConversion` asserts on the complex
destination (the crash this check originally fixed); with it they go through
`StoreAnyExprIntoOneUnit`, where the cast does the conversion.
Agreed it would be cleaner if Sema didn't create single-element `EmbedExpr`s at
all — but it does today for sliced embeds (the `EE(3rd element)` example in
`Expr.h`), so that looks like the representation cleanup Eli suggested doing
separately; with it this check can go away. Should I add an explicit `limit(1)`
complex test and a clarifying comment here if you'd like?
https://github.com/llvm/llvm-project/pull/218262
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
