[Clang] Improve the handling of large arrays evaluation.

[cor3ntin]

Summary

This is a temporary fix (for clang 17) that caps the size of
any array we try to constant evaluate:

There are 2 limits:
  * We cap to UINT_MAX the size of ant constant evaluated array,
    because the constant evaluator does not support size_t.
  * We cap to `-fconstexpr-steps` elements the size of each individual
    array and dynamic array allocations.
    This works out because the number of constexpr steps already limits
    how many array elements can be initialized, which makes this new
    limit conservatively generous.
    This ensure that the compiler does not crash when attempting to
    constant-fold valid programs.

If the limit is reached by a given array, constant evaluation will fail,
and the program will be ill-formed, until a bigger limit is given.
Or, constant folding will fail and the array will be evaluated at runtime.

Fixes #63562

[shafik]

Did you evaluate trying to use StepsLeft at all to limit the allocation? Should the limit be setable via the command line like what we do with steps via -fconstexpr-steps?

[cor3ntin]

• Use -fconstexpr-steps to limit the size of the array.
• Aply the logic to both constant evaluation and constant folding as is constant evaluation fail the limit can now be increased.

[cor3ntin]

clang/lib/AST/ExprConstant.cpp

6768–6772

Note that that the computation for nothrow is incorrect

[aaron.ballman]

clang/include/clang/Basic/DiagnosticASTKinds.td

356 ↗

(On Diff #543472)

I think use of %0 twice here is a bit of a surprise. The first time it's telling you the array bounds, but the second time it's telling you a step limit; these are different things (array bounds contribute to the step limit but there's no reason to assume that setting the step limit to the array bounds will fix anything (or even be larger than the current step limit).

clang/lib/AST/ExprConstant.cpp

1039

6558–6561

Unnecessary changes.

6768–6772

Good catch -- are you planning to fix in a follow-up? If not, can you file an issue so we don't lose track of this? (Bonus points for a test case showing that we get this wrong.)

clang/test/SemaCXX/cxx2a-constexpr-dynalloc-limits.cpp

2

53

The wording of this note is a bit unfortunate given that there's no loop in sight. :-(

60

If you set the limit to 1025 do you actually succeed?

80–83

[cor3ntin]

clang/include/clang/Basic/DiagnosticASTKinds.td

356 ↗

(On Diff #543472)

"use '-fconstexpr-steps' to increase this limit" then?

(The idea was that fconstexpr-steps needs to be at least that value, i agree that the program could still fail a few instructions later)

clang/lib/AST/ExprConstant.cpp

6768–6772

I'll file an issue because it's unclear to me whether this is the only problem with nothrow allocation, or how they should work in general.
Assuming we fix that (T*) new(TOO_BIG, nothrow) still complain about casting a void* ptr.

Ie, i already looked into it and decided it was way out of scope.

clang/test/SemaCXX/cxx2a-constexpr-dynalloc-limits.cpp

53

Line 32. ie, that the case where the allocation succeeds but we can't do much to the array.

60

Yes... but no, see previous comment :)
Maybe I can add constexpr S<std::size_t> s4(100); that would have no error at all

[aaron.ballman]

clang/include/clang/Basic/DiagnosticASTKinds.td

356 ↗

(On Diff #543472)

Yeah, I think this is a case where it's better to just mention the option but not suggest a value.

clang/lib/AST/ExprConstant.cpp

6768–6772

SGTM!

clang/test/SemaCXX/cxx2a-constexpr-dynalloc-limits.cpp

2

Should we add -Wvla to show when constant folding fails we're getting a VLA?

53

Ahhh, I see. Hmm, okay, not as bad as I had thought.

60

I think that'd be a good test to add as well, yes,

[cor3ntin]

Address Aaron's comments and add documentation

[cor3ntin]

Add some VLA tests

[cor3ntin]

Add more Vla tests

[danilaml]

clang/lib/AST/ExprConstant.cpp

1026

1027

[aaron.ballman]

The changes generally seem reasonable to me, but I'm not 100% sure of the impacts of tying this to constexpr steps. That's a vague measure that was used mostly as an escape hatch for recursive constexpr evaluation. It seems reasonable to also tie it to array initialization (where each element of the array is one "step"), but it's not clear to me whether we're going to start rejecting code we used to accept or not. Because this is fixing a crash with code that's becoming more common (mostly through STL constexpr constructors), I see the appeal to getting this into Clang 17 and I think the current changes (tying to the max constexpr steps instead of constexpr steps remaining) are pretty conservative. However, because it's not a regression (this problem has existed for quite a while in Clang) and because we branch tomorrow, I think the most conservative approach would be to land this just after the Clang 17 branch. If post-commit testing doesn't bring up surprises before we start getting closer to putting out release candidates, we can cherry-pick this onto the release branch for early rc testing to widen the coverage and hopefully get the changes in 17. WDYT CC @tstellar @thieta

[efriedma]

The UINT_MAX thing seems like a straightforward bug; if we have time to fix it properly, I'd prefer not to add weird workarounds.

The release note says "unless they are part of a constant expression", but I don't see any code in the implementation that distinguishes folding from constant expression evaluation. Unless this is just referring to the fact that bailing out of folding doesn't produce an error? We might want to consider using a stricter bound for optional folding, though.

How likely is it that we could add some sort of optimization for new expressions so we don't represent each element separately in memory? I know there's no solution in general, but in the cases people actually care about, all/almost all the elements are identical.

[cor3ntin]

In D155955#4528571, @efriedma wrote:

The UINT_MAX thing seems like a straightforward bug; if we have time to fix it properly, I'd prefer not to add weird workarounds.

Note sure what you mean. Making sure we use size_t for all array extents is not something that can be fixed overnight but more importantly, it does not help:
Would it not overflow, the allocation would still fail.

The release note says "unless they are part of a constant expression", but I don't see any code in the implementation that distinguishes folding from constant expression evaluation. Unless this is just referring to the fact that bailing out of folding doesn't produce an error? We might want to consider using a stricter bound for optional folding, though.

I need to update the release notes/commit message they are no reflective of the current design which always look at fconstexpr-steps in all modes of evaluation. It's much cleaner that way.

How likely is it that we could add some sort of optimization for new expressions so we don't represent each element separately in memory? I know there's no solution in general, but in the cases people actually care about, all/almost all the elements are identical.

I don't think that would make sense in actual code, and having some sort of sparse array is something I considered. And we already delay allocation in some cases, but we do need to create elements to destroy them, read them, etc. So while it may be possible, it seems... complicated.
I think a more viable long term fix might be to not crash on allocation failure, and/or to have a way to limit the allocation to some portion of the available memory.

[cor3ntin]

Update release notes and commit message

[efriedma]

Note sure what you mean. Making sure we use size_t for all array extents is not something that can be fixed overnight but more importantly, it does not help: Would it not overflow, the allocation would still fail.

Oh, right, it would be sizeof(APValue) * UINT_MAX, which would break in any practical usage.

I don't think that would make sense in actual code, and having some sort of sparse array is something I considered. And we already delay allocation in some cases, but we do need to create elements to destroy them, read them, etc. So while it may be possible, it seems... complicated.

Definitely not simple, sure.

I think a more viable long term fix might be to not crash on allocation failure, and/or to have a way to limit the allocation to some portion of the available memory.

Making the compiler's behavior depend on the amount of memory installed in the user's computer seems like a non-starter. I think we just have to stick with some combination of:

• Try to reduce excessive memory usage in constant folding.
• Add strict limits memory usage limits for optional constant folding
• Maybe consider disobeying the standard slightly in certain cases: the standard requires that we constant-fold the initializers for all global variables, but that might not really be viable for globals that are expensive to evaluate.

[aaron.ballman]

In D155955#4528792, @efriedma wrote:

Note sure what you mean. Making sure we use size_t for all array extents is not something that can be fixed overnight but more importantly, it does not help: Would it not overflow, the allocation would still fail.

Oh, right, it would be sizeof(APValue) * UINT_MAX, which would break in any practical usage.

I don't think that would make sense in actual code, and having some sort of sparse array is something I considered. And we already delay allocation in some cases, but we do need to create elements to destroy them, read them, etc. So while it may be possible, it seems... complicated.

Definitely not simple, sure.

I think a more viable long term fix might be to not crash on allocation failure, and/or to have a way to limit the allocation to some portion of the available memory.

Making the compiler's behavior depend on the amount of memory installed in the user's computer seems like a non-starter. I think we just have to stick with some combination of:

• Try to reduce excessive memory usage in constant folding.

100% agreed

• Add strict limits memory usage limits for optional constant folding

This seems reasonable to me, but I think this should be user controllable so that users with different resource constraints can override whatever default value we pick.

• Maybe consider disobeying the standard slightly in certain cases: the standard requires that we constant-fold the initializers for all global variables, but that might not really be viable for globals that are expensive to evaluate.

If we can use an existing implementation limit (http://eel.is/c++draft/implimits) to justify our decision, great; otherwise, I think we should ask WG21 for an official escape hatch so that we don't have conformance issues.

[cor3ntin]

In D155955#4532385, @aaron.ballman wrote:

In D155955#4528792, @efriedma wrote:

Note sure what you mean. Making sure we use size_t for all array extents is not something that can be fixed overnight but more importantly, it does not help: Would it not overflow, the allocation would still fail.

Oh, right, it would be sizeof(APValue) * UINT_MAX, which would break in any practical usage.

I don't think that would make sense in actual code, and having some sort of sparse array is something I considered. And we already delay allocation in some cases, but we do need to create elements to destroy them, read them, etc. So while it may be possible, it seems... complicated.

Definitely not simple, sure.

I think a more viable long term fix might be to not crash on allocation failure, and/or to have a way to limit the allocation to some portion of the available memory.

Making the compiler's behavior depend on the amount of memory installed in the user's computer seems like a non-starter. I think we just have to stick with some combination of:

• Try to reduce excessive memory usage in constant folding.

100% agreed

• Add strict limits memory usage limits for optional constant folding

This seems reasonable to me, but I think this should be user controllable so that users with different resource constraints can override whatever default value we pick.

• Maybe consider disobeying the standard slightly in certain cases: the standard requires that we constant-fold the initializers for all global variables, but that might not really be viable for globals that are expensive to evaluate.

If we can use an existing implementation limit (http://eel.is/c++draft/implimits) to justify our decision, great; otherwise, I think we should ask WG21 for an official escape hatch so that we don't have conformance issues.

Forgot to reply to that, it's already conforming

• A variable or temporary object o is constant-initialized if [..] the full-expression of its initialization is a constant expression http://eel.is/c++draft/expr.const#2
• An expression E is a core constant expression unless [...] it would exceed the implementation-defined limits http://eel.is/c++draft/expr.const#5
• Limits may constrain quantities that include those described below or others. http://eel.is/c++draft/implimits#2.sentence-1

On the last point, i think a *explicit* limit would be nice but i chatted with core and they agreed the current wording was sufficient - and they didn't seem super enthusiastic about adding limits.

[aaron.ballman]

In D155955#4532433, @cor3ntin wrote:

In D155955#4532385, @aaron.ballman wrote:

In D155955#4528792, @efriedma wrote:

Note sure what you mean. Making sure we use size_t for all array extents is not something that can be fixed overnight but more importantly, it does not help: Would it not overflow, the allocation would still fail.

Oh, right, it would be sizeof(APValue) * UINT_MAX, which would break in any practical usage.

I don't think that would make sense in actual code, and having some sort of sparse array is something I considered. And we already delay allocation in some cases, but we do need to create elements to destroy them, read them, etc. So while it may be possible, it seems... complicated.

Definitely not simple, sure.

I think a more viable long term fix might be to not crash on allocation failure, and/or to have a way to limit the allocation to some portion of the available memory.

Making the compiler's behavior depend on the amount of memory installed in the user's computer seems like a non-starter. I think we just have to stick with some combination of:

• Try to reduce excessive memory usage in constant folding.

100% agreed

• Add strict limits memory usage limits for optional constant folding

This seems reasonable to me, but I think this should be user controllable so that users with different resource constraints can override whatever default value we pick.

• Maybe consider disobeying the standard slightly in certain cases: the standard requires that we constant-fold the initializers for all global variables, but that might not really be viable for globals that are expensive to evaluate.

If we can use an existing implementation limit (http://eel.is/c++draft/implimits) to justify our decision, great; otherwise, I think we should ask WG21 for an official escape hatch so that we don't have conformance issues.

Forgot to reply to that, it's already conforming

Oh, excellent!

• A variable or temporary object o is constant-initialized if [..] the full-expression of its initialization is a constant expression http://eel.is/c++draft/expr.const#2
• An expression E is a core constant expression unless [...] it would exceed the implementation-defined limits http://eel.is/c++draft/expr.const#5
• Limits may constrain quantities that include those described below or others. http://eel.is/c++draft/implimits#2.sentence-1

On the last point, i think a *explicit* limit would be nice but i chatted with core and they agreed the current wording was sufficient - and they didn't seem super enthusiastic about adding limits.

"or others" is an amazing amount of latitude for Core to give us, how handy! :-D

FWIW, I personally think having explicit limits is far better than relying on "or others" to do the heavy lifting, but we've got what we need at least.

[cor3ntin]

@efriedma You still have objection to landing that now with the goal to backport later in the release process? Thanks!

[efriedma]

The general approach seems fine. The multiplier for constexpr vs. constant folding can be left for a followup, and we can continue to consider other possible improvements elsewhere.

I guess I have one remaining question here: how does this interact with SFINAE? In other words, if we hit the limit analyzing the signature of a function, do we print an error, or silently remove the function from the overload list?

[cor3ntin]

In D155955#4537145, @efriedma wrote:

The general approach seems fine. The multiplier for constexpr vs. constant folding can be left for a followup, and we can continue to consider other possible improvements elsewhere.

I guess I have one remaining question here: how does this interact with SFINAE? In other words, if we hit the limit analyzing the signature of a function, do we print an error, or silently remove the function from the overload list?

SFINAE https://godbolt.org/z/8can1q7GW (there is no difference between constant expression invalid because they exceed limits, or because they are not constant for other reasons)

[efriedma]

That's scary: it means we can silently behave differently from other compilers in a way that's hard to understand. Is there some way we can provide a diagnostic?

That said, it looks like that's an existing issue, so I'm fine with addressing it separately.

[cor3ntin]

In D155955#4539698, @efriedma wrote:

That's scary: it means we can silently behave differently from other compilers in a way that's hard to understand. Is there some way we can provide a diagnostic?

That said, it looks like that's an existing issue, so I'm fine with addressing it separately.

It might be worth asking the committee for input, i agree with you that it's probably not a desirable behavior

[cor3ntin]

@efriedma I sent a mail to core last night, some discussion is happening. @rsmith made some good point so hopefully we will be able to produce some hard error in that case,
But given this is preexisting, I'm going to land that and hopefully we can merge it in the 17 branch in the next few weeks. Thanks!

[cor3ntin]

Rebase

[antmo]

Hi, clang-armv8-quick bot now fails on Clang::cxx2a-constexpr-dynalloc-limits.cpp

https://lab.llvm.org/buildbot/#/builders/245/builds/11764

Could you please look at this ?

[cor3ntin]

In D155955#4542531, @antmo wrote:

Hi, clang-armv8-quick bot now fails on Clang::cxx2a-constexpr-dynalloc-limits.cpp

https://lab.llvm.org/buildbot/#/builders/245/builds/11764

Could you please look at this ?

I landed https://reviews.llvm.org/D156542, which should fix the issue. I'm keeping an eye on it!

[cor3ntin]

It seems to have done the trick! https://lab.llvm.org/buildbot/#/builders/245/builds/11766

clang/docs/ReleaseNotes.rst

- Don't generate virtual tables if the class is defined in another module units
   (`#61940 <https://github.com/llvm/llvm-project/issues/61940>`_)
 - Fix false postive check for constrained satisfaction in standard C++ modules.
   (`#62589 <https://github.com/llvm/llvm-project/issues/62589>`_)
 - Serialize the evaluated constant values for variable declarations in standard
   C++ modules.
   (`#62796 <https://github.com/llvm/llvm-project/issues/62796>`_)
 - Merge lambdas in require expressions in standard C++ modules.
   (`#63544 <https://github.com/llvm/llvm-project/issues/63544>`_)
-
 - Fix location of default member initialization in parenthesized aggregate
   initialization.
   (`#63903 <https://github.com/llvm/llvm-project/issues/63903>`_)
+- Clang no longer tries to evaluate at compile time arrays that are large
+  enough to cause resource exhaustion, unless they are part of a constant
+  expression.
+  (`#63562 <https://github.com/llvm/llvm-project/issues/63562>`_)
 
 Bug Fixes to AST Handling
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 - Preserve ``namespace`` definitions that follow malformed declarations.
 
 Miscellaneous Bug Fixes
 ^^^^^^^^^^^^^^^^^^^^^^^

clang/include/clang/AST/Type.h

public:
   QualType desugar() const { return QualType(this, 0); }
 
   /// Determine the number of bits required to address a member of
   // an array with the given element type and number of elements.
   static unsigned getNumAddressingBits(const ASTContext &Context,
                                        QualType ElementType,
                                        const llvm::APInt &NumElements);
 
+  unsigned getNumAddressingBits(const ASTContext &Context) const;
+
   /// Determine the maximum number of active bits that an array's size
   /// can require, which limits the maximum size of the array.
   static unsigned getMaxSizeBits(const ASTContext &Context);
 
   void Profile(llvm::FoldingSetNodeID &ID, const ASTContext &Ctx) {
     Profile(ID, Ctx, getElementType(), getSize(), getSizeExpr(),
             getSizeModifier(), getIndexTypeCVRQualifiers());
   }

clang/lib/AST/ExprConstant.cpp

bool CheckCallLimit(SourceLocation Loc) {
       }
       if (CallStackDepth <= getLangOpts().ConstexprCallDepth)
         return true;
       FFDiag(Loc, diag::note_constexpr_depth_limit_exceeded)
         << getLangOpts().ConstexprCallDepth;
       return false;
     }
 
+    bool IsArrayTooLarge(unsigned BitWidth, uint64_t ElemCount) {
+      if (BitWidth > ConstantArrayType::getMaxSizeBits(Ctx))
+        return true;
+
+      // FIXME: GH63562
+      // APValue stores array extents as unsigned,
+      // so anything that is greater that unsigned would overflow when
+      // constructing the array, we catch this here.
+      if (ElemCount > std::numeric_limits<unsigned>::max())
+        return true;
+
+      // FIXME: GH63562
+      // Arrays allocate an APValue per element.
+      // When constant folding avoid allocating arrays larger than 100MB to
+      // avoid running out of memory when compiling reasonable programs.
+      // Constant Expression evaluation can still exhaust the sytem resources
+      // and crash the compiler.
+      bool RequiresConstantEvaluation =
+          !(checkingPotentialConstantExpression() ||
+            EvalMode == EvalInfo::EM_IgnoreSideEffects ||
+            EvalMode == EvalInfo::EM_ConstantFold);
+      if (RequiresConstantEvaluation) {
+        // Check whether we are performing constant initialization
+        if (const auto *VD = dyn_cast_if_present<VarDecl>(
+                EvaluatingDecl.dyn_cast<const ValueDecl *>());
+            VD && VD->hasGlobalStorage()) {
+          RequiresConstantEvaluation =
+              VD->isConstexpr() || VD->hasAttr<ConstInitAttr>();
+        }
+      }
+      if (ElemCount * sizeof(APValue) > 100'000'000 &&
+          !RequiresConstantEvaluation)
+        return true;
+
+      return false;
+    }
+
     std::pair<CallStackFrame *, unsigned>
     getCallFrameAndDepth(unsigned CallIndex) {
       assert(CallIndex && "no call index in getCallFrameAndDepth");
       // We will eventually hit BottomFrame, which has Index 1, so Frame can't
       // be null in this loop.
       unsigned Depth = CallStackDepth;
       CallStackFrame *Frame = CurrentCall;
       while (Frame->Index > CallIndex) {
case EvalInfo::EvaluatingDeclKind::Dtor:
     // subobjects of such objects that are themselves declared const.
     QualType T = getType(Base);
     return T.isConstQualified() || T->isReferenceType();
   }
 
   llvm_unreachable("unknown evaluating decl kind");
 }
 
+static bool CheckArraySize(EvalInfo &Info, const ConstantArrayType *CAT,
+                           SourceLocation CallLoc = {}) {
+  if (Info.IsArrayTooLarge(CAT->getNumAddressingBits(Info.Ctx),
+                           CAT->getSize().getZExtValue())) {
+    Info.FFDiag(CAT->getSizeExpr() ? CAT->getSizeExpr()->getBeginLoc()
+                                    : CallLoc,
+                 diag::note_constexpr_new_too_large)
+        << CAT->getSize().getZExtValue();
+    return false;
+  }
+  return true;
+}
+
 namespace {
 /// A handle to a complete object (an object that is not a subobject of
 /// another object).
 struct CompleteObject {
   /// The identity of the object.
   APValue::LValueBase Base;
   /// The value of the complete object.
   APValue *Value;
if (ObjType->isArrayType()) {
         return handler.failed();
       }
 
       ObjType = CAT->getElementType();
 
       if (O->getArrayInitializedElts() > Index)
         O = &O->getArrayInitializedElt(Index);
       else if (!isRead(handler.AccessKind)) {
+        if (!CheckArraySize(Info, CAT, E->getExprLoc()))
+          return handler.failed();
+
         expandArray(*O, Index);
         O = &O->getArrayInitializedElt(Index);
       } else
         O = &O->getArrayFiller();
     } else if (ObjType->isAnyComplexType()) {
       // Next subobject is a complex number.
       uint64_t Index = Sub.Entries[I].getAsArrayIndex();
       if (Index > 1) {
static bool HandleDestructionImpl(EvalInfo &Info, SourceLocation CallLoc,
   // FIXME: We shouldn't need to do this.
   OpaqueValueExpr LocE(CallLoc, Info.Ctx.IntTy, VK_PRValue);
 
   // For arrays, destroy elements right-to-left.
   if (const ConstantArrayType *CAT = Info.Ctx.getAsConstantArrayType(T)) {
     uint64_t Size = CAT->getSize().getZExtValue();
     QualType ElemT = CAT->getElementType();
 
+    if (!CheckArraySize(Info, CAT, CallLoc))
+      return false;
+
     LValue ElemLV = This;
     ElemLV.addArray(Info, &LocE, CAT);
     if (!HandleLValueArrayAdjustment(Info, &LocE, ElemLV, ElemT, Size))
       return false;
 
     // Ensure that we have actual array elements available to destroy; the
     // destructors might mutate the value, so we can't run them on the array
     // filler.
-    if (Size && Size > Value.getArrayInitializedElts())
+    if (Size && Size > Value.getArrayInitializedElts()) {
       expandArray(Value, Value.getArraySize() - 1);
+    }
 
     for (; Size != 0; --Size) {
       APValue &Elem = Value.getArrayInitializedElt(Size - 1);
       if (!HandleLValueArrayAdjustment(Info, &LocE, ElemLV, ElemT, -1) ||
           !HandleDestructionImpl(Info, CallLoc, ElemLV, Elem, ElemT))
         return false;
     }
 
     // End the lifetime of this array now.
Info.FFDiag(E->getExprLoc(),
                 diag::note_constexpr_new_not_complete_object_type)
         << (ElemType->isIncompleteType() ? 0 : 1) << ElemType;
     return false;
   }
 
   APSInt ByteSize;
   if (!EvaluateInteger(E->getArg(0), ByteSize, Info))
     return false;
   bool IsNothrow = false;
   for (unsigned I = 1, N = E->getNumArgs(); I != N; ++I) {
     EvaluateIgnoredValue(Info, E->getArg(I));
     IsNothrow |= E->getType()->isNothrowT();
   }
 
   CharUnits ElemSize;
   if (!HandleSizeof(Info, E->getExprLoc(), ElemType, ElemSize))
     return false;
   APInt Size, Remainder;
   APInt ElemSizeAP(ByteSize.getBitWidth(), ElemSize.getQuantity());
   APInt::udivrem(ByteSize, ElemSizeAP, Size, Remainder);
   if (Remainder != 0) {
     // This likely indicates a bug in the implementation of 'std::allocator'.
     Info.FFDiag(E->getExprLoc(), diag::note_constexpr_operator_new_bad_size)
         << ByteSize << APSInt(ElemSizeAP, true) << ElemType;
     return false;
   }
 
-  if (ByteSize.getActiveBits() > ConstantArrayType::getMaxSizeBits(Info.Ctx)) {
+  if (Info.IsArrayTooLarge(ByteSize.getActiveBits(), Size.getZExtValue())) {
     if (IsNothrow) {
       Result.setNull(Info.Ctx, E->getType());
       return true;
     }
-
     Info.FFDiag(E, diag::note_constexpr_new_too_large) << APSInt(Size, true);
     return false;
   }
 
   QualType AllocType = Info.Ctx.getConstantArrayType(ElemType, Size, nullptr,
                                                      ArrayType::Normal, 0);
   APValue *Val = Info.createHeapAlloc(E, AllocType, Result);
   *Val = APValue(APValue::UninitArray(), 0, Size.getZExtValue());
if (ArrayBound.isSigned() && ArrayBound.isNegative()) {
 
       Info.FFDiag(*ArraySize, diag::note_constexpr_new_negative)
           << ArrayBound << (*ArraySize)->getSourceRange();
       return false;
     }
 
     //   -- its value is such that the size of the allocated object would
     //      exceed the implementation-defined limit
-    if (ConstantArrayType::getNumAddressingBits(Info.Ctx, AllocType,
-                                                ArrayBound) >
-        ConstantArrayType::getMaxSizeBits(Info.Ctx)) {
+    if (Info.IsArrayTooLarge(ConstantArrayType::getNumAddressingBits(
+                                 Info.Ctx, AllocType, ArrayBound),
+                             ArrayBound.getZExtValue())) {
       if (IsNothrow)
         return ZeroInitialization(E);
 
       Info.FFDiag(*ArraySize, diag::note_constexpr_new_too_large)
         << ArrayBound << (*ArraySize)->getSourceRange();
       return false;
     }
 

clang/lib/AST/Type.cpp

SizeExtended = SizeExtended.extend(std::max(SizeTypeBits,
                                               SizeExtended.getBitWidth()) * 2);
 
   llvm::APSInt TotalSize(llvm::APInt(SizeExtended.getBitWidth(), ElementSize));
   TotalSize *= SizeExtended;
 
   return TotalSize.getActiveBits();
 }
 
+unsigned
+ConstantArrayType::getNumAddressingBits(const ASTContext &Context) const {
+  return getNumAddressingBits(Context, getElementType(), getSize());
+}
+
 unsigned ConstantArrayType::getMaxSizeBits(const ASTContext &Context) {
   unsigned Bits = Context.getTypeSize(Context.getSizeType());
 
   // Limit the number of bits in size_t so that maximal bit size fits 64 bit
   // integer (see PR8256).  We can do this as currently there is no hardware
   // that supports full 64-bit virtual space.
   if (Bits > 61)
     Bits = 61;

clang/test/SemaCXX/cxx2a-constexpr-dynalloc-limits.cpp

+// RUN: %clang_cc1 -std=c++2a -verify %s
+// RUN: %clang_cc1 -std=c++2a -verify=constexpr %s -DCONSTEXPR
+// expected-no-diagnostics
+
+namespace std {
+  using size_t = decltype(sizeof(0));
+  template<typename T> struct allocator {
+    constexpr T *allocate(size_t N) {
+      return (T*)operator new(sizeof(T) * N); // #alloc
+    }
+    constexpr void deallocate(void *p) {
+      operator delete(p);
+    }
+  };
+}
+void *operator new(std::size_t, void *p) { return p; }
+
+namespace std {
+  template<typename T, typename ...Args>
+  constexpr void construct_at(void *p, Args &&...args) {
+    new (p) T((Args&&)args...);
+  }
+}
+
+namespace GH63562 {
+
+template <typename T>
+struct S {
+    constexpr S(unsigned long long N)
+    : data(nullptr){
+        data = alloc.allocate(N);  // #call
+        for(std::size_t i = 0; i < N; i ++)
+            std::construct_at<T>(data + i, i);
+
+    }
+    constexpr ~S() {
+        alloc.deallocate(data);
+    }
+    std::allocator<T> alloc;
+    T* data;
+};
+
+#ifdef CONSTEXPR
+constexpr S<std::size_t> s(1099511627777); // constexpr-error {{constexpr variable 's' must be initialized by a constant expression}} \                                            // expected-note@#alloc {{annot allocate array; evaluated array bound 1099511627777 is too large}} \
+                                           // constexpr-note@#call {{in call to 'this->alloc.allocate(1099511627777)'}} \
+                                           // constexpr-note@#alloc {{cannot allocate array; evaluated array bound 1099511627777 is too large}} \
+                                           // constexpr-note {{in call to 'S(1099511627777)'}}
+#else
+// Check that we do not try to fold very large arrays
+S<std::size_t> s2(1099511627777);
+S<std::size_t> s3(~0ULL);
+#endif
+
+// Check we do not perform constant initialization in the presence
+// of very large arrays (this used to crash)
+
+constexpr int stack_array(auto N) {
+    char BIG[N];
+    return 0;
+}
+
+int a = stack_array(~0U);
+int b = stack_array(~0ULL);
+
+}
+