aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/AST/ExprConstant.cpp
AgeCommit message (Collapse)AuthorFilesLines
2019-09-27For P0784R7: add support for explicit destructor calls andRichard Smith1-30/+98
pseudo-destructor calls in constant evaluation. llvm-svn: 373122
2019-09-27Fix use-after-free found in Clang's testsuite.Richard Smith1-3/+6
We need to discard all remaining cleanups if an earlier cleanup failed, otherwise we may try to rerun the remaining cleanups later, potentially after the scope containing the object is destroyed. (This can happen when checking a potential constant expression.) llvm-svn: 373042
2019-09-27For P0784R7: add support for new (std::nothrow).Richard Smith1-11/+33
llvm-svn: 373037
2019-09-27For P0784R7: Add support for dynamic allocation with new / delete duringRichard Smith1-51/+438
constant evaluation. llvm-svn: 373036
2019-09-23For P0784R7: add support for constexpr destructors, and call them asRichard Smith1-101/+448
appropriate during constant evaluation. Note that the evaluator is sometimes invoked on incomplete expressions. In such cases, if an object is constructed but we never reach the point where it would be destroyed (and it has non-trivial destruction), we treat the expression as having an unmodeled side-effect. llvm-svn: 372538
2019-09-20Remove outdated FIXME.Richard Smith1-4/+0
llvm-svn: 372438
2019-09-20Fix assertion failure when constant evaluation of a switch jumps over anRichard Smith1-0/+27
uninitialized variable in an init-statement of a 'for' or 'if'. llvm-svn: 372437
2019-09-18[c++20] P1331R2: Allow transient use of uninitialized objects inRichard Smith1-106/+187
constant evaluation. llvm-svn: 372237
2019-09-13[Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker1-263/+143
Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 371834
2019-09-10When evaluating a __builtin_constant_p conditional, always enterRichard Smith1-63/+41
constant-folding mode regardless of the original evaluation mode. In order for this to be correct, we need to track whether we're checking for a potential constant expression or checking for undefined behavior separately from the evaluation mode enum, since we don't want to clobber those states when entering constant-folding mode. llvm-svn: 371557
2019-09-04Revert "[Clang Interpreter] Initial patch for the constexpr interpreter"Roman Lebedev1-147/+265
Breaks BUILD_SHARED_LIBS build, introduces cycles in library dependency graphs. (clangInterp depends on clangAST which depends on clangInterp) This reverts r370839, which is an yet another recommit of D64146. llvm-svn: 370874
2019-09-04[Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker1-265/+147
Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370839
2019-09-02Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker1-147/+265
This reverts r370636 (git commit 8327fed9475a14c3376b4860c75370c730e08f33) llvm-svn: 370642
2019-09-02[Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker1-265/+147
Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370636
2019-08-31Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker1-147/+265
This reverts r370584 (git commit afcb3de117265a69d21e5673356e925a454d7d02) llvm-svn: 370588
2019-08-31[Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker1-265/+147
Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370584
2019-08-30Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker1-145/+263
This reverts r370531 (git commit d4c1002e0bbbbab50f6891cdd2f5bd3a8f3a3584) llvm-svn: 370535
2019-08-30[Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker1-263/+145
Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370531
2019-08-30Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker1-145/+263
This reverts r370476 (git commit a5590950549719d0d9ea69ed164b0c8c0f4e02e6) llvm-svn: 370481
2019-08-30[Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker1-263/+145
Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370476
2019-08-29[NFC] Test commit - sorted headers.Nandor Licker1-1/+1
llvm-svn: 370412
2019-08-09Add SVE opaque built-in typesRichard Sandiford1-0/+3
This patch adds the SVE built-in types defined by the Procedure Call Standard for the Arm Architecture: https://developer.arm.com/docs/100986/0000 It handles the types in all relevant places that deal with built-in types. At the moment, some of these places bail out with an error, including: (1) trying to generate LLVM IR for the types (2) trying to generate debug info for the types (3) trying to mangle the types using the Microsoft C++ ABI (4) trying to @encode the types in Objective C (1) and (2) are fixed by follow-on patches but (unlike this patch) they deal mostly with target-specific LLVM details, so seemed like a logically separate change. There is currently no spec for (3) and (4), so reporting an error seems like the correct behaviour for now. The intention is that the types will become sizeless types: http://lists.llvm.org/pipermail/cfe-dev/2019-June/062523.html The main purpose of the sizeless type extension is to diagnose impossible or dangerous uses of the types, such as any that would require sizeof to have a meaningful defined value. Until then, the patch sets the alignments of the types to the values specified in the link above. It also sets the sizes of the types to zero, which is chosen to be consistently wrong and shouldn't affect correctly-written code (i.e. code that would compile even with the sizeless type extension). The patch adds the common subset of functionality needed to test the sizeless type extension on the one hand and to provide SVE intrinsic functions on the other. After this patch, the two pieces of work are essentially independent. The patch is based on one by Graham Hunter: https://reviews.llvm.org/D59245 Differential Revision: https://reviews.llvm.org/D62960 llvm-svn: 368413
2019-07-06Treat the range of representable values of floating-point types as [-inf, ↵Richard Smith1-9/+13
+inf] not as [-max, +max]. Summary: Prior to r329065, we used [-max, max] as the range of representable values because LLVM's `fptrunc` did not guarantee defined behavior when truncating from a larger floating-point type to a smaller one. Now that has been fixed, we can make clang follow normal IEEE 754 semantics in this regard and take the larger range [-inf, +inf] as the range of representable values. In practice, this affects two parts of the frontend: * the constant evaluator no longer treats floating-point evaluations that result in +-inf as being undefined (because they no longer leave the range of representable values of the type) * UBSan no longer treats conversions to floating-point type that are outside the [-max, +max] range as being undefined In passing, also remove the float-divide-by-zero sanitizer from -fsanitize=undefined, on the basis that while it's undefined per C++ rules (and we disallow it in constant expressions for that reason), it is defined by Clang / LLVM / IEEE 754. Reviewers: rnk, BillyONeal Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63793 llvm-svn: 365272
2019-07-03Fix -Wcast-qual const warning. NFCI.Simon Pilgrim1-1/+1
llvm-svn: 365031
2019-07-03Fix MSVC "not all control paths return a value" warnings. NFCI.Simon Pilgrim1-0/+2
llvm-svn: 365012
2019-07-02[C++2a] Add __builtin_bit_cast, used to implement std::bit_castErik Pilkington1-6/+505
This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a bit_cast from a value v to a type T. This expression can be evaluated at compile time under specific circumstances. The compile time evaluation currently doesn't support bit-fields, but I'm planning on fixing this in a follow up (some of the logic for figuring this out is in CodeGen). I'm also planning follow-ups for supporting some more esoteric types that the constexpr evaluator supports, as well as extending __builtin_memcpy constexpr evaluation to use the same infrastructure. rdar://44987528 Differential revision: https://reviews.llvm.org/D62825 llvm-svn: 364954
2019-06-25[cxx2a] P1236R1: the validity of a left shift does not depend on theRichard Smith1-1/+3
value of the LHS operand. llvm-svn: 364265
2019-06-21[clang] Small improvments after Adding APValue to ConstantExprGauthier Harnisch1-0/+2
Summary: this patch has multiple small improvements related to the APValue in ConstantExpr. changes: - APValue in ConstantExpr are now cleaned up using ASTContext::addDestruction instead of there own system. - ConstantExprBits Stores the ValueKind of the result beaing stored. - VerifyIntegerConstantExpression now stores the evaluated value in ConstantExpr. - the Constant Evaluator uses the stored value of ConstantExpr when available. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63376 llvm-svn: 364011
2019-06-15[clang] perform semantic checking in constant contextGauthier Harnisch1-14/+45
Summary: Since the addition of __builtin_is_constant_evaluated the result of an expression can change based on whether it is evaluated in constant context. a lot of semantic checking performs evaluations with out specifying context. which can lead to wrong diagnostics. for example: ``` constexpr int i0 = (long long)__builtin_is_constant_evaluated() * (1ll << 33); //#1 constexpr int i1 = (long long)!__builtin_is_constant_evaluated() * (1ll << 33); //#2 ``` before the patch, #2 was diagnosed incorrectly and #1 wasn't diagnosed. after the patch #1 is diagnosed as it should and #2 isn't. Changes: - add a flag to Sema to passe in constant context mode. - in SemaChecking.cpp calls to Expr::Evaluate* are now done in constant context when they should. - in SemaChecking.cpp diagnostics for UB are not checked for in constant context because an error will be emitted by the constant evaluator. - in SemaChecking.cpp diagnostics for construct that cannot appear in constant context are not checked for in constant context. - in SemaChecking.cpp diagnostics on constant expression are always emitted because constant expression are always evaluated. - semantic checking for initialization of constexpr variables is now done in constant context. - adapt test that were depending on warning changes. - add test. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62009 llvm-svn: 363488
2019-05-30Fix constexpr __builtin_*_overflow issue when unsigned->signed operand.Erich Keane1-4/+2
As reported here https://bugs.llvm.org/show_bug.cgi?id=42000, it was possible to get the constexpr version of __builtin_*_overflow to give the wrong answer. This was because when extending the operands to fit the largest type (so that the math could be done), the decision on whether to sign/zero extend the operands was based on the result signedness, not on the operands signedness. In the reported case, (unsigned char)255 - (int)100 needed to have each extended to the int in order to do the math. However, when extending the first operand to 'int', we incorrectly sign extended it instead of zero extending. Thus, the result didnt fit back into the unsigned char. The fix for this was simply to choose zero/sign extension based on the sign of the operand itself. Differential Revision: https://reviews.llvm.org/D62665 llvm-svn: 362157
2019-05-30[c++2a] Fix assertion failure if we would walk over more than one levelRichard Smith1-1/+2
of derived-to-base conversion path when implicitly starting union subobject lifetimes in constant evaluation. llvm-svn: 362147
2019-05-23Fix hang during constant evaluation of union assignment.Eric Fiselier1-3/+2
HandleUnionActiveMemberChange forgot to walk over a nop implicit conversion node and got stuck in the process. As a cleanup I changed the declaration of `E` so it can't be accidentally accessed after the loop. llvm-svn: 361571
2019-05-22Fixed a -Wunused-variable warning when assertions are disabledDmitri Gribenko1-0/+1
llvm-svn: 361353
2019-05-21[c++20] P1330R0: permit simple-assignments that change the active memberRichard Smith1-7/+195
of a union within constant expression evaluation. llvm-svn: 361329
2019-05-21Refactor: split Uninitialized state on APValue into an "Absent" stateRichard Smith1-13/+16
representing no such object, and an "Indeterminate" state representing an uninitialized object. The latter is not yet used, but soon will be. llvm-svn: 361328
2019-05-20Fix compilation warning about unused variable [NFC]Mikael Holmen1-1/+1
Without the fix at least clang 3.6 complains with ../tools/clang/lib/AST/ExprConstant.cpp:90:24: error: unused variable 'TI' [-Werror,-Wunused-variable] if (TypeInfoLValue TI = B.dyn_cast<TypeInfoLValue>()) ^ 1 error generated. llvm-svn: 361145
2019-05-17[c++20] P1327R1: Support for typeid applied to objects of polymorphicRichard Smith1-6/+22
class type in constant evaluation. This reinstates r360977, reverted in r360987, now that its rerequisite patch is reinstated and fixed. llvm-svn: 361067
2019-05-17Added an assertion to constant evaluation enty points that prohibits ↵Dmitri Gribenko1-0/+50
dependent expressions Summary: Constant evaluator does not work on value-dependent or type-dependent expressions. Also fixed bugs uncovered by these assertions. Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61522 llvm-svn: 361050
2019-05-17Fix crash if, during evaluation of __builtin_object_size, we try to loadRichard Smith1-0/+5
through an invalid base. llvm-svn: 360998
2019-05-17Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith1-11/+36
object rather than tracking the originating expression. This is groundwork for supporting polymorphic typeid expressions. (Note that this somewhat regresses our support for DR1968, but it turns out that that never actually worked anyway, at least in non-trivial cases.) This reinstates r360974, reverted in r360988, with a fix for a static_assert failure on 32-bit builds: force Type base class to have 8-byte alignment like the rest of Clang's AST nodes. llvm-svn: 360995
2019-05-17Revert Refactor constant evaluation of typeid(T) to track a symbolic ↵Chris Bieneman1-36/+11
type_info object rather than tracking the originating expression. This reverts r360974 (git commit 7ee4307bd4450022c3c8777f43a40cc4f0ccc009) llvm-svn: 360988
2019-05-17Revert [c++20] P1327R1: Support for typeid applied to objects of polymorphic ↵Chris Bieneman1-22/+6
class type in constant evaluation. This reverts r360977 (git commit f51dc8d2f98f4029247552bc45ef53628ab3b6b9) llvm-svn: 360987
2019-05-17[c++20] P1327R1: Support for typeid applied to objects of polymorphicRichard Smith1-6/+22
class type in constant evaluation. llvm-svn: 360977
2019-05-17Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith1-11/+36
object rather than tracking the originating expression. This is groundwork for supporting polymorphic typeid expressions. (Note that this somewhat regresses our support for DR1968, but it turns out that that never actually worked anyway, at least in non-trivial cases.) llvm-svn: 360974
2019-05-16Implement __builtin_LINE() et. al. to support source location capture.Eric Fiselier1-4/+33
Summary: This patch implements the source location builtins `__builtin_LINE(), `__builtin_FUNCTION()`, `__builtin_FILE()` and `__builtin_COLUMN()`. These builtins are needed to implement [`std::experimental::source_location`](https://rawgit.com/cplusplus/fundamentals-ts/v2/main.html#reflection.src_loc.creation). With the exception of `__builtin_COLUMN`, GCC also implements these builtins, and Clangs behavior is intended to match as closely as possible. Reviewers: rsmith, joerg, aaron.ballman, bogner, majnemer, shafik, martong Reviewed By: rsmith Subscribers: rnkovacs, loskutov, riccibruno, mgorny, kunitoki, alexr, majnemer, hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D37035 llvm-svn: 360937
2019-05-15[c++20] For P1327R1: support dynamic_cast in constant expressionRichard Smith1-54/+199
evaluation. llvm-svn: 360806
2019-05-13[c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith1-22/+220
evaluation. This reinstates r360559, reverted in r360580, with a fix to avoid crashing if evaluation-for-overflow mode encounters a virtual call on an object of a class with a virtual base class, and to generally not try to resolve virtual function calls to objects whose (notional) vptrs are not readable. (The standard rules are unclear here, but this seems like a reasonable approach.) llvm-svn: 360635
2019-05-13Revert r360559 "[c++20] P1064R0: Allow virtual function calls in constant ↵Hans Wennborg1-207/+21
expression evaluation." This caused Chromium builds to hit the new "can't handle virtual calls with virtual bases" assert. Reduced repro coming up. llvm-svn: 360580
2019-05-13PR41854: Don't assert when constant-evaluating a member function call on an ↵Richard Smith1-0/+3
invalid designator. llvm-svn: 360560
2019-05-13[c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith1-21/+207
evaluation. llvm-svn: 360559
generated by cgit v1.1 at 2025-10-06 18:32:35 +0000