summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaCXX/constant-expression-cxx1y.cpp
Commit message (Collapse)AuthorAgeFilesLines
* PR43674: fix incorrect constant evaluation of 'switch' where no caseRichard Smith2019-10-151-0/+6
| | | | | | label corresponds to the condition. llvm-svn: 374954
* Fix checking for permitted results of constant expressions.Richard Smith2019-09-291-0/+19
| | | | | | | | | In the presence of mutable state, we need to check whether temporaries involved in a constant expression have permissible values at the end of the overall evaluation, rather than at the end of the evaluation of the initializer of the temporary. llvm-svn: 373160
* [c++20] P1331R2: Allow transient use of uninitialized objects inRichard Smith2019-09-181-2/+3
| | | | | | constant evaluation. llvm-svn: 372237
* Treat the range of representable values of floating-point types as [-inf, ↵Richard Smith2019-07-061-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +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
* PR39728: When completing a class, complete the destructor first.Richard Smith2019-05-311-0/+16
| | | | | | | | | We need to know whether the destructor is trivial in order to tell whether other parts of the class are valid (in particular, this affects whether the type is a literal type, which affects whether defaulted special members can be declared constexpr or are implicitly constexpr). llvm-svn: 362184
* Fix handling of objects under construction during constant expressionRichard Smith2019-05-121-0/+46
| | | | | | | | | | | | | 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-46/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix handling of objects under construction during constant expressionRichard Smith2019-05-101-0/+46
| | | | | | | | | | 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
* DR1872: don't allow any calls to virtual functions in constantRichard Smith2019-05-091-1/+1
| | | | | | | | evaluation. Not even in cases where we would not actually perform virtual dispatch. llvm-svn: 360370
* [8.0 Regression] Fix handling of `__builtin_constant_p` inside template ↵Eric Fiselier2019-03-081-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ExprConstant] Handle compound assignment when LHS has integral type and RHS ↵Tan S. B.2018-12-181-0/+8
| | | | | | | | | | has floating point type Fixes PR39858 Differential Revision: https://reviews.llvm.org/D55413 llvm-svn: 349444
* Fix test after -Wstring-plus-int warning was enabledReid Kleckner2018-12-131-1/+1
| | | | | | Use array indexing instead of addition. llvm-svn: 349085
* Simplify the __builtin_constant_p test that was used to catch rC347417 failureFangrui Song2018-11-291-5/+2
| | | | | | | | | | | | Reviewers: rsmith, void, shafik Reviewed By: void Subscribers: kristina, cfe-commits Differential Revision: https://reviews.llvm.org/D54964 llvm-svn: 347895
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-281-0/+8
| | | | | | | This was reverted in r347656 due to me thinking it caused a miscompile of Chromium. Turns out it was the Chromium code that was broken. llvm-svn: 347756
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-271-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused a miscompile in Chrome (see crbug.com/908372) that's illustrated by this small reduction: static bool f(int *a, int *b) { return !__builtin_constant_p(b - a) || (!(b - a)); } int arr[] = {1,2,3}; bool g() { return f(arr, arr + 3); } $ clang -O2 -S -emit-llvm a.cc -o - g() should return true, but after r347417 it became false for some reason. This also reverts the follow-up commits. r347417: > Re-Reinstate 347294 with a fix for the failures. > > Don't try to emit a scalar expression for a non-scalar argument to > __builtin_constant_p(). > > Third time's a charm! r347446: > The result of is.constant() is unsigned. r347480: > A __builtin_constant_p() returns 0 with a function type. r347512: > isEvaluatable() implies a constant context. > > Assume that we're in a constant context if we're asking if the expression can > be compiled into a constant initializer. This fixes the issue where a > __builtin_constant_p() in a compound literal was diagnosed as not being > constant, even though it's always possible to convert the builtin into a > constant. r347531: > A "constexpr" is evaluated in a constant context. Make sure this is reflected > if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347656
* A "constexpr" is evaluated in a constant context. Make sure this is reflectedBill Wendling2018-11-261-0/+8
| | | | | | if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347531
* PR39628 Treat all non-zero values as 'true' in bool compound-assignmentRichard Smith2018-11-121-1/+25
| | | | | | in constant evaluation, not just odd values. llvm-svn: 346699
* [ExprConstant] Use an AST node and a version number as a key to createAkira Hatanaka2018-04-101-3/+2
| | | | | | | | | | | | | | | an APValue and retrieve it from map Temporaries. The version number is needed when a single AST node is visited multiple times and is used to create APValues that are required to be distinct from each other (for example, MaterializeTemporaryExprs in default arguments and VarDecls in loops). rdar://problem/36505742 Differential Revision: https://reviews.llvm.org/D42776 llvm-svn: 329671
* [ExprConstant] Fix crash when initialize an indirect field with another field.Volodymyr Sapsai2018-02-231-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | When indirect field is initialized with another field, you have MemberExpr with CXXThisExpr that corresponds to the field's immediate anonymous parent. But 'this' was referring to the non-anonymous parent. So when we were building LValue Designator, it was incorrect as it had wrong starting point. Usage of such designator would cause unexpected APValue changes and crashes. The fix is in adjusting 'this' for indirect fields from non-anonymous parent to the field's immediate parent. Discovered by OSS-Fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4985 rdar://problem/36359187 Reviewers: rsmith, efriedma Reviewed By: rsmith Subscribers: cfe-commits, jkorous-apple Differential Revision: https://reviews.llvm.org/D42498 llvm-svn: 325997
* Add a test to ensure we don't permit mutable access on temporaries outside ↵Richard Smith2018-02-231-2/+3
| | | | | | the evaluation in which they were created. llvm-svn: 325854
* In C++14 onwards, it is permitted to read mutable members in constantRichard Smith2018-02-211-0/+23
| | | | | | | | | expressions, if their lifetime began during the evaluation of the expression. This is technically not allowed in C++11, though we could consider permitting it there too, as an extension. llvm-svn: 325663
* [ExprConstant] Allow constexpr ctor to modify non static data membersErik Pilkington2017-10-041-0/+33
| | | | | | | | Fixes PR19741. Differential revision: https://reviews.llvm.org/D38483 llvm-svn: 314865
* PR34161: support evaluation of 'void()' expressions in C++14 onwards.Richard Smith2017-08-171-0/+6
| | | | llvm-svn: 311115
* Improve fix for PR28739Richard Smith2017-01-311-1/+1
| | | | | | | | | | | | | | | Don't try to map an APSInt addend to an int64_t in pointer arithmetic before bounds-checking it. This gives more consistent behavior (outside C++11, we consistently use 2s complement semantics for both pointer and integer overflow in constant expressions) and fixes some cases where in C++11 we would fail to properly check for out-of-bounds pointer arithmetic (if the 2s complement 64-bit overflow landed us back in-bounds). In passing, also fix some cases where we'd perform possibly-overflowing arithmetic on CharUnits (which have a signed underlying type) during constant expression evaluation. llvm-svn: 293595
* PR28739: Check that integer values fit into 64 bits before extracting them ↵Richard Smith2017-01-301-0/+5
| | | | | | | | | | | | | as 64 bit values for pointer arithmetic. This fixes various ways to tickle an assertion in constant expression evaluation when using __int128. Longer term, we need to figure out what should happen here: either any kind of overflow in offset calculation should result in a non-constant value or we should truncate to 64 bits. In C++11 onwards, we're effectively already checking for overflow because we strictly enforce array bounds checks, but even there some forms of overflow can slip past undetected. llvm-svn: 293568
* Emit CCEDiags when evaluating a const variable.George Burgess IV2016-12-271-8/+11
| | | | | | This addresses post-review feedback from r290577. llvm-svn: 290584
* Add a test for `const` folding introduced by r290297. NFC.George Burgess IV2016-12-271-0/+17
| | | | | | | AFAICT, we didn't add a test targeted at the new "const can sometimes act as constexpr" behavior introduced by r290297. llvm-svn: 290577
* PR27989: only enqueue binary operators into the data recursive int expressionRichard Smith2016-06-041-0/+8
| | | | | | evaluator if they are actually int expressions. llvm-svn: 271754
* [Sema] Note when we encounter a problem in ExprConstant.George Burgess IV2016-05-251-4/+15
| | | | | | | | | | | | | | | | | | | | Currently, the constexpr evaluator is very conservative about unmodeled side-effects when we're evaluating an expression in a mode that allows such side-effects. This patch makes us note when we might have actually encountered an unmodeled side-effect, which allows us to be more accurate when we know an unmodeled side-effect couldn't have occurred. This patch has been split into two commits; this one primarily introduces the bits necessary to track whether we might have potentially hit such a side-effect. The one that actually does the tracking (which boils down to more or less a rename of keepEvaluatingAfterFailure to noteFailure) is coming soon. Differential Revision: http://reviews.llvm.org/D18540 llvm-svn: 270781
* Replace bitwise AND with logical AND in an expression that already had ↵Craig Topper2015-12-081-1/+1
| | | | | | another logical AND. NFC llvm-svn: 255006
* C11 _Bool bitfield diagnosticRachel Craik2015-09-141-1/+1
| | | | | | | | | | | | Summary: Implement DR262 (for C). This patch will mainly affect bitfields of type _Bool Reviewers: fraggamuffin, rsmith Subscribers: hubert.reinterpretcast, cfe-commits Differential Revision: http://reviews.llvm.org/D10018 llvm-svn: 247618
* Fix bug where a trivial constexpr copy/move operation couldn't copy from anRichard Smith2014-11-191-0/+28
| | | | | | | empty non-constexpr object. Such a copy doesn't break any of the constexpr rules. llvm-svn: 222387
* Improve -Wuninitialized to take into account field ordering with initializerRichard Trieu2014-09-231-2/+1
| | | | | | | lists. Since the fields are inititalized one at a time, using a field with lower index to initialize a higher indexed field should not be warned on. llvm-svn: 218339
* Don't reject dependent range-based for loops in constexpr functions. The loopRichard Smith2013-11-151-0/+13
| | | | | | variable isn't really uninitialized, it's just not initialized yet. llvm-svn: 194767
* PR17615: A delegating constructor initializer is a full-expression. Don'tRichard Smith2013-11-071-0/+11
| | | | | | forget to clean up temporaries at the end of it. llvm-svn: 194213
* More constant evaluation cleanup, and fix an issue where we'd override anRichard Smith2013-11-061-3/+3
| | | | | | | earlier 'non-constant' diagnostic with a later one if the earlier one was from a side-effect we thought we could evaluate past. llvm-svn: 194117
* PR16755: When initializing or modifying a bitfield member in a constantRichard Smith2013-08-061-0/+17
| | | | | | expression, truncate the stored value to the size of the bitfield. llvm-svn: 187782
* C++1y: track object lifetime during constexpr evaluation, and don't allowRichard Smith2013-07-241-0/+56
| | | | | | | objects to be used once their lifetimes end. This completes the C++1y constexpr extensions. llvm-svn: 187025
* More of N3652: don't add an implicit 'const' to 'constexpr' member functions ↵Richard Smith2013-06-251-0/+24
| | | | | | when checking for overloads in C++1y. llvm-svn: 184865
* PR16377: Allow evaluation of statement expressions in constant evaluation,Richard Smith2013-06-201-0/+25
| | | | | | why not. Apparently GCC supports this. llvm-svn: 184396
* PR12086, PR15117Richard Smith2013-06-121-0/+40
| | | | | | | | | | | | | | | | | | | Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
* Model temporary lifetime-extension explicitly in the AST. Use this model toRichard Smith2013-06-051-0/+10
| | | | | | | | | handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
* PR16090: C++1y: treat undeduced 'auto' as a literal type, so that constexprRichard Smith2013-05-211-0/+7
| | | | | | function templates can use it as a return type. llvm-svn: 182433
* Use only explicit bool conversion operatorDavid Blaikie2013-05-151-2/+3
| | | | | | | | | | | | | | | | | | | The most common (non-buggy) case are where such objects are used as return expressions in bool-returning functions or as boolean function arguments. In those cases I've used (& added if necessary) a named function to provide the equivalent (or sometimes negative, depending on convenient wording) test. DiagnosticBuilder kept its implicit conversion operator owing to the prevalent use of it in return statements. One bug was found in ExprConstant.cpp involving a comparison of two PointerUnions (PointerUnion did not previously have an operator==, so instead both operands were converted to bool & then compared). A test is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix (adding operator== to PointerUnion in LLVM). llvm-svn: 181869
* C++1y: support for 'switch' statements in constexpr functions. This is somewhatRichard Smith2013-05-121-0/+114
| | | | | | | | inefficient; we perform a linear scan of switch labels to find the one matching the condition, and then walk the body looking for that label. Both parts should be straightforward to optimize. llvm-svn: 181671
* C++1y constant expression evaluation: compound assignment support for ↵Richard Smith2013-05-071-13/+54
| | | | | | floating-point and pointer types. llvm-svn: 181376
* C++1y constant expression evaluation: support for compound assignments on ↵Richard Smith2013-05-071-3/+55
| | | | | | integers. llvm-svn: 181287
* C++1y: an assignment operator is implicitly 'constexpr' if it would only ↵Richard Smith2013-05-071-0/+43
| | | | | | call 'constexpr' assignment operators for a literal class type. llvm-svn: 181284
* C++1y: support range-based for loops in constant expressions.Richard Smith2013-05-061-0/+54
| | | | llvm-svn: 181184
* C++1y: support 'for', 'while', and 'do ... while' in constant expressions.Richard Smith2013-05-061-20/+71
| | | | llvm-svn: 181181
OpenPOWER on IntegriCloud