================ @@ -732,8 +732,8 @@ static llvm::Value *EmitCXXNewAllocSize(CodeGenFunction &CGF, // Emit the array size expression. // We multiply the size of all dimensions for NumElements. // e.g for 'int[2][3]', ElemType is 'int' and NumElements is 6. - numElements = - ConstantEmitter(CGF).tryEmitAbstract(*e->getArraySize(), e->getType()); + numElements = ConstantEmitter(CGF).tryEmitAbstract( ---------------- erichkeane wrote:
Do you have a lit test that shows where this would be wrong? Typically in cases like this we count on the AST to have given us the correct type. Also, it isn't clear to my WHY we expect it to be size-type? Also, `size_t` isn't guaranteed to be the same size as the pointer, so this could actually be a breaking change on those platforms. By standard, we don't actually have a type that makes that guarantee, though `intptr_t` and `uintptr_t` might be the closest. Still don't really see a situation where this is troublesome though. https://github.com/llvm/llvm-project/pull/123433 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
