summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/ExprConstant.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add SVE opaque built-in typesRichard Sandiford2019-08-091-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
* Treat the range of representable values of floating-point types as [-inf, ↵Richard Smith2019-07-061-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
* Fix -Wcast-qual const warning. NFCI.Simon Pilgrim2019-07-031-1/+1
| | | | llvm-svn: 365031
* Fix MSVC "not all control paths return a value" warnings. NFCI.Simon Pilgrim2019-07-031-0/+2
| | | | llvm-svn: 365012
* [C++2a] Add __builtin_bit_cast, used to implement std::bit_castErik Pilkington2019-07-021-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
* [cxx2a] P1236R1: the validity of a left shift does not depend on theRichard Smith2019-06-251-1/+3
| | | | | | value of the LHS operand. llvm-svn: 364265
* [clang] Small improvments after Adding APValue to ConstantExprGauthier Harnisch2019-06-211-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
* [clang] perform semantic checking in constant contextGauthier Harnisch2019-06-151-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
* Fix constexpr __builtin_*_overflow issue when unsigned->signed operand.Erich Keane2019-05-301-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
* [c++2a] Fix assertion failure if we would walk over more than one levelRichard Smith2019-05-301-1/+2
| | | | | | | of derived-to-base conversion path when implicitly starting union subobject lifetimes in constant evaluation. llvm-svn: 362147
* Fix hang during constant evaluation of union assignment.Eric Fiselier2019-05-231-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
* Fixed a -Wunused-variable warning when assertions are disabledDmitri Gribenko2019-05-221-0/+1
| | | | llvm-svn: 361353
* [c++20] P1330R0: permit simple-assignments that change the active memberRichard Smith2019-05-211-7/+195
| | | | | | of a union within constant expression evaluation. llvm-svn: 361329
* Refactor: split Uninitialized state on APValue into an "Absent" stateRichard Smith2019-05-211-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
* Fix compilation warning about unused variable [NFC]Mikael Holmen2019-05-201-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
* [c++20] P1327R1: Support for typeid applied to objects of polymorphicRichard Smith2019-05-171-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
* Added an assertion to constant evaluation enty points that prohibits ↵Dmitri Gribenko2019-05-171-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
* Fix crash if, during evaluation of __builtin_object_size, we try to loadRichard Smith2019-05-171-0/+5
| | | | | | through an invalid base. llvm-svn: 360998
* Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith2019-05-171-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
* Revert Refactor constant evaluation of typeid(T) to track a symbolic ↵Chris Bieneman2019-05-171-36/+11
| | | | | | | | type_info object rather than tracking the originating expression. This reverts r360974 (git commit 7ee4307bd4450022c3c8777f43a40cc4f0ccc009) llvm-svn: 360988
* Revert [c++20] P1327R1: Support for typeid applied to objects of polymorphic ↵Chris Bieneman2019-05-171-22/+6
| | | | | | | | class type in constant evaluation. This reverts r360977 (git commit f51dc8d2f98f4029247552bc45ef53628ab3b6b9) llvm-svn: 360987
* [c++20] P1327R1: Support for typeid applied to objects of polymorphicRichard Smith2019-05-171-6/+22
| | | | | | class type in constant evaluation. llvm-svn: 360977
* Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith2019-05-171-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
* Implement __builtin_LINE() et. al. to support source location capture.Eric Fiselier2019-05-161-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
* [c++20] For P1327R1: support dynamic_cast in constant expressionRichard Smith2019-05-151-54/+199
| | | | | | evaluation. llvm-svn: 360806
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-131-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
* Revert r360559 "[c++20] P1064R0: Allow virtual function calls in constant ↵Hans Wennborg2019-05-131-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
* PR41854: Don't assert when constant-evaluating a member function call on an ↵Richard Smith2019-05-131-0/+3
| | | | | | invalid designator. llvm-svn: 360560
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-131-21/+207
| | | | | | evaluation. llvm-svn: 360559
* Reject attempts to call non-static member functions on objects outsideRichard Smith2019-05-121-33/+122
| | | | | | | | | | | | | | | | their lifetime in constant expressions. This is undefined behavior per [class.cdtor]p2. We continue to allow this for objects whose values are not visible within the constant evaluation, because there's no way we can tell whether the access is defined or not, existing code relies on the ability to make such calls, and every other compiler allows such calls. This reinstates r360499, reverted in r360531. llvm-svn: 360538
* Fix handling of objects under construction during constant expressionRichard Smith2019-05-121-88/+153
| | | | | | | | | | | | | evaluation. It's not enough to just track the LValueBase that we're evaluating, we need to also track the path to the objects whose constructors are running. This reinstates r360464 (reverted in r360531) with a workaround for an MSVC bug that previously caused the Windows bots to fail. llvm-svn: 360537
* Revert rL360499 and rL360464 from cfe/trunk:Simon Pilgrim2019-05-111-267/+113
| | | | | | | | | | | | | | | | | | | | | | | | Reject attempts to call non-static member functions on objects outside their lifetime in constant expressions. This is undefined behavior per [class.cdtor]p2. We continue to allow this for objects whose values are not visible within the constant evaluation, because there's no way we can tell whether the access is defined or not, existing code relies on the ability to make such calls, and every other compiler allows such calls. ........ Fix handling of objects under construction during constant expression evaluation. It's not enough to just track the LValueBase that we're evaluating, we need to also track the path to the objects whose constructors are running. ........ Fixes windows buildbots llvm-svn: 360531
* Reject attempts to call non-static member functions on objects outsideRichard Smith2019-05-111-33/+122
| | | | | | | | | | | | | | their lifetime in constant expressions. This is undefined behavior per [class.cdtor]p2. We continue to allow this for objects whose values are not visible within the constant evaluation, because there's no way we can tell whether the access is defined or not, existing code relies on the ability to make such calls, and every other compiler allows such calls. llvm-svn: 360499
* Fix handling of objects under construction during constant expressionRichard Smith2019-05-101-88/+153
| | | | | | | | | | evaluation. It's not enough to just track the LValueBase that we're evaluating, we need to also track the path to the objects whose constructors are running. llvm-svn: 360464
* Improve interface of APValuePathEntry.Richard Smith2019-05-101-42/+25
| | | | llvm-svn: 360463
* Delete write-only HasQualifiers after rC360370Fangrui Song2019-05-101-2/+0
| | | | llvm-svn: 360408
* DR1872: don't allow any calls to virtual functions in constantRichard Smith2019-05-091-6/+8
| | | | | | | | evaluation. Not even in cases where we would not actually perform virtual dispatch. llvm-svn: 360370
* Disallow the operand of __builtin_constant_p from modifying enclosingRichard Smith2019-05-041-15/+28
| | | | | | | | | | | | | | state when it's encountered while evaluating a constexpr function. We attempt to follow GCC trunk's behavior here, but it is somewhat inscrutible, so our behavior is only approximately the same for now. Specifically, we only permit modification of objects whose lifetime began within the operand of the __builtin_constant_p. GCC appears to have effectively the same restriction, but also some unknown restriction based on where and how the local state of the constexpr function is mentioned within the operand (see added testcases). llvm-svn: 359958
* Remove else-after-returnDavid Blaikie2019-05-031-5/+4
| | | | llvm-svn: 359913
* Fix -Wunsequenced false-positives in code controlled by a branch onRichard Smith2019-05-021-3/+6
| | | | | | | | | | __builtin_constant_p. If the operand of __builtin_constant_p is not constant and has side-effects, then code controlled by a branch on it is unreachable and we should not emit runtime behavior warnings in such code. llvm-svn: 359844
* Reinstate r359059, reverted in r359361, with a fix to properly preventRichard Smith2019-04-271-36/+43
| | | | | | | | | | | | | | | | | | | | | | | us emitting the operand of __builtin_constant_p if it has side-effects. Original commit message: Fix interactions between __builtin_constant_p and constexpr to match current trunk GCC. GCC permits information from outside the operand of __builtin_constant_p (but in the same constant evaluation context) to be used within that operand; clang now does so too. A few other minor deviations from GCC's behavior showed up in my testing and are also fixed (matching GCC): * Clang now supports nullptr_t as the argument type for __builtin_constant_p * Clang now returns true from __builtin_constant_p if called with a null pointer * Clang now returns true from __builtin_constant_p if called with an integer cast to pointer type llvm-svn: 359367
* Revert Fix interactions between __builtin_constant_p and constexpr to match ↵Jorge Gorbe Moya2019-04-271-35/+28
| | | | | | | | current trunk GCC. This reverts r359059 (git commit 0b098754b73f3b96d00ecb1c7605760b11c90298) llvm-svn: 359361
* [Builtins] Implement __builtin_is_constant_evaluated for use in C++2aEric Fiselier2019-04-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements `__builtin_is_constant_evaluated` as specifier by [P0595R2](https://wg21.link/p0595r2). It is built on the back of Bill Wendling's work for `__builtin_constant_p()`. More tests to come, but early feedback is appreciated. I plan to implement warnings for common mis-usages like those belowe in a following patch: ``` void foo(int x) { if constexpr (std::is_constant_evaluated())) { // condition is always `true`. Should use plain `if` instead. foo_constexpr(x); } else { foo_runtime(x); } } ``` Reviewers: rsmith, MaskRay, bruno, void Reviewed By: rsmith Subscribers: dexonsmith, zoecarver, fdeazeve, kristina, cfe-commits Differential Revision: https://reviews.llvm.org/D55500 llvm-svn: 359067
* Fix interactions between __builtin_constant_p and constexpr to matchRichard Smith2019-04-241-28/+35
| | | | | | | | | | | | | | | | | | current trunk GCC. GCC permits information from outside the operand of __builtin_constant_p (but in the same constant evaluation context) to be used within that operand; clang now does so too. A few other minor deviations from GCC's behavior showed up in my testing and are also fixed (matching GCC): * Clang now supports nullptr_t as the argument type for __builtin_constant_p * Clang now returns true from __builtin_constant_p if called with a null pointer * Clang now returns true from __builtin_constant_p if called with an integer cast to pointer type llvm-svn: 359059
* [8.0 Regression] Fix handling of `__builtin_constant_p` inside template ↵Eric Fiselier2019-03-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | arguments, enumerators, case statements, and the enable_if attribute. Summary: The following code is accepted by Clang 7 and prior but rejected by the upcoming 8 release and in trunk [1] ``` // error {{never produces a constant expression}} void foo(const char* s) __attribute__((enable_if(__builtin_constant_p(*s) == false, "trap"))) {} void test() { foo("abc"); } ``` Prior to Clang 8, the call to `__builtin_constant_p` was a constant expression returning false. Currently, it's not a valid constant expression. The bug is caused because we failed to set `InConstantContext` when attempting to evaluate unevaluated constant expressions. [1] https://godbolt.org/z/ksAjmq Reviewers: rsmith, hans, sbenza Reviewed By: rsmith Subscribers: kristina, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59038 llvm-svn: 355743
* [ObjC] Emit a boxed expression as a compile-time constant if theAkira Hatanaka2019-03-081-0/+4
| | | | | | | | | | | | | | | | | | expression inside the parentheses is a valid UTF-8 string literal. Previously clang emitted an expression like @("abc") as a message send to stringWithUTF8String. This commit makes clang emit the boxed expression as a compile-time constant instead. This commit also has the effect of silencing the nullable-to-nonnull conversion warning clang started emitting after r317727, which originally motivated this commit (see https://oleb.net/2018/@keypath). rdar://problem/42684601 Differential Revision: https://reviews.llvm.org/D58729 llvm-svn: 355662
* Inline asm constraints: allow ICE-like pointers for the "n" constraint (PR40890)Hans Wennborg2019-03-061-6/+5
| | | | | | | | | | | | Apparently GCC allows this, and there's code relying on it (see bug). The idea is to allow expression that would have been allowed if they were cast to int. So I based the code on how such a cast would be done (the CK_PointerToIntegral case in IntExprEvaluator::VisitCastExpr()). Differential Revision: https://reviews.llvm.org/D58821 llvm-svn: 355491
* [Fixed Point Arithmetic] Fixed Point and Integer ConversionsLeonard Chan2019-03-061-0/+30
| | | | | | | | | This patch includes the necessary code for converting between a fixed point type and integer. This also includes constant expression evaluation for conversions with these types. Differential Revision: https://reviews.llvm.org/D56900 llvm-svn: 355462
* [Fixed Point Arithmetic] Fixed Point ComparisonsLeonard Chan2019-02-211-0/+16
| | | | | | | | | This patch implements fixed point comparisons with other fixed point types and integers. This also provides constant expression evaluation for them. Differential Revision: https://reviews.llvm.org/D57219 llvm-svn: 354621
* [Builtins] Treat `bcmp` as a builtin.Clement Courbet2019-02-141-5/+11
| | | | | | | | | | | | | | | | | Summary: This makes it consistent with `memcmp` and `__builtin_bcmp`. Also see the discussion in https://reviews.llvm.org/D56593. Reviewers: jyknight Subscribers: kristina, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58120 llvm-svn: 354023
OpenPOWER on IntegriCloud