[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

6753–6757

Note that that the computation for nothrow is incorrect

[aaron.ballman]

clang/include/clang/Basic/DiagnosticASTKinds.td

356

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

6544–6546

Unnecessary changes.

6753–6757

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

"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

6753–6757

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

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

6753–6757

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

 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Bug Fixes to Attribute Support
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Bug Fixes to C++ Support
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
+- Clang limits the size of arrays it will try to evaluate at compile time
+  to avoid memory exhaustion.
+  This limit can be modified by `-fconstexpr-steps`.
+  (`#63562 <https://github.com/llvm/llvm-project/issues/63562>`_)
+
 Bug Fixes to AST Handling
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Miscellaneous Bug Fixes
 ^^^^^^^^^^^^^^^^^^^^^^^
 
 Miscellaneous Clang Crashes Fixed
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

clang/docs/UsersManual.rst

 
 .. option:: -fconstexpr-depth=N
 
   Sets the limit for constexpr function invocations to N. The default is 512.
 
 .. option:: -fconstexpr-steps=N
 
   Sets the limit for the number of full-expressions evaluated in a single
-  constant expression evaluation.  The default is 1048576.
+  constant expression evaluation. This also controls the maximum size
+  of array and dynamic array allocation that can be constant evaluated.
+  The default is 1048576.
 
 .. option:: -ftemplate-depth=N
 
   Sets the limit for recursively nested template instantiations to N.  The
   default is 1024.
 
 .. option:: -foperator-arrow-depth=N
 

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/include/clang/Basic/DiagnosticASTKinds.td

 def note_constexpr_new_placement : Note<
   "this placement new expression is not yet supported in constant expressions">;
 def note_constexpr_placement_new_wrong_type : Note<
   "placement new would change type of storage from %0 to %1">;
 def note_constexpr_new_negative : Note<
   "cannot allocate array; evaluated array bound %0 is negative">;
 def note_constexpr_new_too_large : Note<
   "cannot allocate array; evaluated array bound %0 is too large">;
+def note_constexpr_new_exceeds_limits : Note<
+  "cannot allocate array; evaluated array bound %0 exceeds the limit (%1); "
+  "use '-fconstexpr-steps' to increase this limit">;
 def note_constexpr_new_too_small : Note<
   "cannot allocate array; evaluated array bound %0 is too small to hold "
   "%1 explicitly initialized elements">;
 def note_constexpr_new_untyped : Note<
   "cannot allocate untyped memory in a constant expression; "
   "use 'std::allocator<T>::allocate' to allocate memory of type 'T'">;
 def note_constexpr_new_not_complete_object_type : Note<
   "cannot allocate memory of %select{incomplete|function}0 type %1">;

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 CheckArraySize(SourceLocation Loc, unsigned BitWidth,
+                        uint64_t ElemCount, bool Diag) {
+      // 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 (BitWidth > ConstantArrayType::getMaxSizeBits(Ctx) ||
+          ElemCount > uint64_t(std::numeric_limits<unsigned>::max())) {
+        if (Diag)
+          FFDiag(Loc, diag::note_constexpr_new_too_large) << ElemCount;
+        return false;
+      }
+
+      // FIXME: GH63562
+      // Arrays allocate an APValue per element.
+      // We use the number of constexpr steps as a proxy for the maximum size
+      // of arrays to avoid exhausting the system resources, as initialization
+      // of each element is likely to take some number of steps anyway.
+      uint64_t Limit = Ctx.getLangOpts().ConstexprStepLimit;
+      if (ElemCount > Limit) {
+        if (Diag)
+          FFDiag(Loc, diag::note_constexpr_new_exceeds_limits)
+              << ElemCount << Limit;
+        return false;
+      }
+      return true;
+    }
+
     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 = {}) {
+  return Info.CheckArraySize(
+      CAT->getSizeExpr() ? CAT->getSizeExpr()->getBeginLoc() : CallLoc,
+      CAT->getNumAddressingBits(Info.Ctx), CAT->getSize().getZExtValue(),
+      /*Diag=*/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())
       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.
static bool HandleDestruction(EvalInfo &Info, SourceLocation Loc,
   if (Info.EvalStatus.HasSideEffects)
     return false;
 
   LValue LV;
   LV.set({LVBase});
   return HandleDestructionImpl(Info, Loc, LV, Value, T);
 }
 
-/// Perform a call to 'perator new' or to `__builtin_operator_new'.
+/// Perform a call to 'operator new' or to `__builtin_operator_new'.
 static bool HandleOperatorNewCall(EvalInfo &Info, const CallExpr *E,
                                   LValue &Result) {
   if (Info.checkingPotentialConstantExpression() ||
       Info.SpeculativeEvaluationDepth)
     return false;
 
   // This is permitted only within a call to std::allocator<T>::allocate.
   auto Caller = Info.getStdAllocatorCaller("allocate");
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.CheckArraySize(E->getBeginLoc(), ByteSize.getActiveBits(),
+                           Size.getZExtValue(), /*Diag=*/!IsNothrow)) {
     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());
   Result.addArray(Info, E, cast<ConstantArrayType>(AllocType));
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.CheckArraySize(ArraySize.value()->getExprLoc(),
+                             ConstantArrayType::getNumAddressingBits(
+                                 Info.Ctx, AllocType, ArrayBound),
+                             ArrayBound.getZExtValue(), /*Diag=*/!IsNothrow)) {
       if (IsNothrow)
         return ZeroInitialization(E);
-
-      Info.FFDiag(*ArraySize, diag::note_constexpr_new_too_large)
-        << ArrayBound << (*ArraySize)->getSourceRange();
       return false;
     }
 
     //   -- the new-initializer is a braced-init-list and the number of
     //      array elements for which initializers are provided [...]
     //      exceeds the number of elements to initialize
     if (!Init) {
       // No initialization is performed.

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++20 -verify -fconstexpr-steps=1024 -Wvla %s
+
+namespace std {
+  using size_t = decltype(sizeof(0));
+}
+
+void *operator new(std::size_t, void *p) { return p; }
+
+namespace std {
+  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);
+    }
+  };
+  template<typename T, typename ...Args>
+  constexpr void construct_at(void *p, Args &&...args) { // #construct
+    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); // #construct_call
+    }
+    constexpr T operator[](std::size_t i) const {
+      return data[i];
+    }
+
+    constexpr ~S() {
+        alloc.deallocate(data);
+    }
+    std::allocator<T> alloc;
+    T* data;
+};
+
+constexpr std::size_t s = S<std::size_t>(1099511627777)[42]; // expected-error {{constexpr variable 's' must be initialized by a constant expression}} \
+                                           // expected-note@#call {{in call to 'this->alloc.allocate(1099511627777)'}} \
+                                           // expected-note@#alloc {{cannot allocate array; evaluated array bound 1099511627777 is too large}} \
+                                           // expected-note {{in call to 'S(1099511627777)'}}
+// Check that we do not try to fold very large arrays
+std::size_t s2 = S<std::size_t>(1099511627777)[42];
+std::size_t s3 = S<std::size_t>(~0ULL)[42];
+
+// We can allocate and initialize a small array
+constexpr std::size_t ssmall = S<std::size_t>(100)[42];
+
+// We can allocate this array but we hikt the number of steps
+constexpr std::size_t s4 = S<std::size_t>(1024)[42]; // expected-error {{constexpr variable 's4' must be initialized by a constant expression}} \
+                                   // expected-note@#construct {{constexpr evaluation hit maximum step limit; possible infinite loop?}} \
+                                   // expected-note@#construct_call {{in call}} \
+                                   // expected-note {{in call}}
+
+
+
+constexpr std::size_t s5 = S<std::size_t>(1025)[42]; // expected-error{{constexpr variable 's5' must be initialized by a constant expression}} \
+                                   // expected-note@#alloc {{cannot allocate array; evaluated array bound 1025 exceeds the limit (1024); use '-fconstexpr-steps' to increase this limit}} \
+                                   // expected-note@#call {{in call to 'this->alloc.allocate(1025)'}} \
+                                   // expected-note {{in call}}
+
+
+// Check we do not perform constant initialization in the presence
+// of very large arrays (this used to crash)
+
+template <auto N>
+constexpr int stack_array() {
+    [[maybe_unused]] char BIG[N] = {1};  // expected-note  3{{cannot allocate array; evaluated array bound 1025 exceeds the limit (1024); use '-fconstexpr-steps' to increase this limit}}
+    return BIG[N-1];
+}
+
+int a = stack_array<~0U>();
+int c = stack_array<1024>();
+int d = stack_array<1025>();
+constexpr int e = stack_array<1024>();
+constexpr int f = stack_array<1025>(); // expected-error {{constexpr variable 'f' must be initialized by a constant expression}} \
+                                       //  expected-note {{in call}}
+void ohno() {
+  int bar[stack_array<1024>()];
+  int foo[stack_array<1025>()]; // expected-warning {{variable length arrays are a C99 feature}} \
+                                // expected-note {{in call to 'stack_array()'}}
+
+  constexpr int foo[stack_array<1025>()]; // expected-warning {{variable length arrays are a C99 feature}} \
+                                          // expected-error {{constexpr variable cannot have non-literal type 'const int[stack_array<1025>()]'}} \
+                                          // expected-note {{in call to 'stack_array()'}}
+}
+
+}