summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/ExprConstant.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* PR35214: don't crash if we see an array of unknown bound added to an empty ↵Richard Smith2017-11-151-4/+5
| | | | | | but invalid designator. llvm-svn: 318258
* Unnamed bitfields don't block constant evaluation of constexpr ctorsJordan Rose2017-10-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | C++14 [dcl.constexpr]p4 states that in the body of a constexpr constructor, > every non-variant non-static data member and base class sub-object shall be initialized However, [class.bit]p2 notes that > Unnamed bit-fields are not members and cannot be initialized. Therefore, we should make sure to filter them out of the check that all fields are initialized. Fixing this makes the constant evaluator a bit smarter, and specifically allows constexpr constructors to avoid tripping -Wglobal-constructors when the type contains unnamed bitfields. Reviewed at https://reviews.llvm.org/D39035. llvm-svn: 316408
* Implement current CWG direction for support of arrays of unknown bounds inRichard Smith2017-10-201-27/+66
| | | | | | | | | | | | | | | | | constant expressions. We permit array-to-pointer decay on such arrays, but disallow pointer arithmetic (since we do not know whether it will have defined behavior). This is based on r311970 and r301822 (the former by me and the latter by Robert Haberlach). Between then and now, two things have changed: we have committee feedback indicating that this is indeed the right direction, and the code broken by this change has been fixed. This is necessary in C++17 to continue accepting certain forms of non-type template argument involving arrays of unknown bound. llvm-svn: 316245
* [OpenMP] Implement omp_is_initial_device() as builtinJonas Hahnfeld2017-10-171-0/+3
| | | | | | | | This allows to return the static value that we know at compile time. Differential Revision: https://reviews.llvm.org/D38968 llvm-svn: 316001
* [ExprConstant] Allow constexpr ctor to modify non static data membersErik Pilkington2017-10-041-3/+30
| | | | | | | | Fixes PR19741. Differential revision: https://reviews.llvm.org/D38483 llvm-svn: 314865
* Revert "Improve constant expression evaluation of arrays of unknown bound."Martin Bohme2017-08-301-59/+26
| | | | | | | | This reverts commit r311970. Breaks internal tests. llvm-svn: 312108
* Improve constant expression evaluation of arrays of unknown bound.Richard Smith2017-08-291-26/+59
| | | | | | | | The standard is not clear on how these are supposed to be handled, so we conservatively treat as non-constant any cases whose value is unknown or whose evaluation might result in undefined behavior. llvm-svn: 311970
* PR34161: support evaluation of 'void()' expressions in C++14 onwards.Richard Smith2017-08-171-0/+2
| | | | llvm-svn: 311115
* Fix undefined behavior that is caused by not always initializing a bool.Daniel Jasper2017-08-171-0/+1
| | | | | | | The fix in r310994 is incomplete, as moveFromAndCancel can set the pointer without initializing OldIsSpeculativelyEvaluating. llvm-svn: 311070
* Fix a UBSan failure where this boolean was copied when uninitialized.Chandler Carruth2017-08-161-1/+1
| | | | | | | | | When r310905 moved the pointer and bool out of a PointerIntPair, it made them end up uninitialized and caused UBSan failures when copying the uninitialized boolean. However, making the pointer be null should avoid the reference to the boolean entirely. llvm-svn: 310994
* Avoid PointerIntPair of constexpr EvalInfo structsReid Kleckner2017-08-151-13/+11
| | | | | | | | | | | | | | They are stack allocated, so their alignment is not to be trusted. 32-bit MSVC only guarantees 4 byte stack alignment, even though alignof would tell you otherwise. I tried fixing this with __declspec align, but that apparently upsets GCC. Hopefully this version will satisfy all compilers. See PR32018 for some info about the mingw issues. Should supercede https://reviews.llvm.org/D34873 llvm-svn: 310905
* [MS] Don't statically initialize dllimport member function pointersReid Kleckner2017-07-071-0/+16
| | | | | | | | | | | | | | | | | | | | Summary: r306137 made dllimport pointers to member functions non-constant. This is correct because a load must be executed to resolve any dllimported data. However, r306137 did not account for the use of dllimport member function pointers used as template arguments. This change re-lands r306137 with a template instantiation fix. This fixes PR33570. Reviewers: rnk, majnemer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D34714 llvm-svn: 307446
* fix trivial typos in comments; NFCHiroshi Inoue2017-07-051-2/+2
| | | | llvm-svn: 307123
* Revert r301742, which caused us to try to evaluate all full-expressions.Richard Smith2017-06-261-9/+4
| | | | | | | | | | | | | | Also add testcases for a bunch of expression forms that cause our evaluator to crash. See PR33140 and PR32864 for crashes that this was causing. This reverts r305287, which reverted r305239, which reverted r301742. The previous revert claimed that buildbots were broken, but did not add any testcases and the buildbots have lost all memory of what was wrong here. Changes to test/OpenMP are not reverted; another change has triggered those tests to change their output in the same way that r301742 did. llvm-svn: 306346
* Revert "[MS] Don't statically initialize dllimport member function pointers"Reid Kleckner2017-06-231-16/+0
| | | | | | | | | | | | | | | | | | | This reverts commit r306137. It has problems on code like this: struct __declspec(dllimport) Foo { int a; int get_a() { return a; } }; template <int (Foo::*Getter)()> struct HasValue { int operator()(Foo *p) { return (p->*Getter)(); } }; int main() { Foo f; f.a = 3; int x = HasValue<&Foo::get_a>()(&f); } llvm-svn: 306175
* [MS] Don't statically initialize dllimport member function pointersReid Kleckner2017-06-231-0/+16
| | | | | | | | | | | | We were already applying the same rules to dllimport function pointers. David Majnemer added that logic back in r211677 to fix PR20130. We failed to extend that logic to non-virtual member function pointers, which are basically function pointers in a struct with some extra offsets. Fixes PR33570. llvm-svn: 306137
* Revert "Revert r301742 which made ExprConstant checking apply to all ↵Diana Picus2017-06-131-4/+9
| | | | | | | | | full-exprs." This reverts commit r305239 because it broke the buildbots (the diag-flags.cpp test is failing). llvm-svn: 305287
* Revert r301742 which made ExprConstant checking apply to all full-exprs.Nick Lewycky2017-06-121-9/+4
| | | | | | This patch also exposed pre-existing bugs in clang, see PR32864 and PR33140#c3 . llvm-svn: 305239
* Revert r303316, a change to ExprConstant to evaluate function arguments.Nick Lewycky2017-06-121-28/+5
| | | | | | The patch was itself correct but it uncovered other bugs which are going to be difficult to fix, per PR33140. llvm-svn: 305233
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-031-0/+3
| | | | llvm-svn: 304650
* Create valid LValue to represent null pointers in constant exprsTim Northover2017-05-261-6/+14
| | | | | | | | | | | | We were leaving the SubobjectDesignator in a surprising situation, where it was allegedly valid but didn't actually refer to a type. This caused a crash later on. This patch fills out the SubobjectDesignator with the pointee type (as happens in other evaluations of constant pointers) so that we don't crash later. llvm-svn: 303957
* The constant expression evaluator should examine function arguments for ↵Nick Lewycky2017-05-171-5/+28
| | | | | | non-constexpr function calls unless the EvalInfo says to stop. llvm-svn: 303317
* Revert r301822 (and dependent r301825), which tried to improve theDaniel Jasper2017-05-021-136/+106
| | | | | | | | | | | | | | | | | | | | | | | | handling of constexprs with unknown bounds. This triggers a corner case of the language where it's not yet clear whether this should be an error: struct A { static void *const a[]; static void *const b[]; }; constexpr void *A::a[] = {&b[0]}; constexpr void *A::b[] = {&a[0]}; When discovering the initializer for A::a, the bounds of A::b aren't known yet. It is unclear whether warning about errors should be deferred until the end of the translation unit, possibly resolving errors that can be resolved. In practice, the compiler can know the bounds of all arrays in this example. Credits for reproducers and explanation go to Richard Smith. Richard, please add more info in case my explanation is wrong. llvm-svn: 301963
* Revert r301785 (and r301787) because they caused PR32864.Nick Lewycky2017-05-021-7/+1
| | | | | | The fix is that ExprEvaluatorBase::VisitInitListExpr should handle transparent exprs instead of exprs with one element. Fixing that uncovers one testcase failure because the AST for "constexpr _Complex float test2 = {1};" is wrong (the _Complex prvalue should not be const-qualified), and a number of test failures in test/OpenMP where the captured stmt contains an InitListExpr that is in syntactic form. llvm-svn: 301891
* Silence unused variable warning. NFC.Benjamin Kramer2017-05-011-1/+1
| | | | llvm-svn: 301825
* Improve handling of arrays of unknown bound in constant expressions.Richard Smith2017-05-011-106/+136
| | | | | | | | | | | | | | Do not spuriously reject constexpr functions that access elements of an array of unknown bound; this may later become valid once the bound is known. Permit array-to-pointer decay on such arrays, but disallow pointer arithmetic (since we do not know whether it will have defined behavior). The standard is not clear on how this should work, but this seems to be a decent answer. Patch by Robert Haberlach! llvm-svn: 301822
* Handle expressions with non-literal types like ignored expressions if we are ↵Nick Lewycky2017-05-011-1/+7
| | | | | | | | supposed to continue evaluating them. Also fix a crash casting a derived nullptr to a virtual base. llvm-svn: 301785
* Remove Sema::CheckForIntOverflow, and instead check all full-expressions.Nick Lewycky2017-04-291-4/+9
| | | | | | | | CheckForIntOverflow used to implement a whitelist of top-level expressions to send to the constant expression evaluator, which handled many more expressions than the CheckForIntOverflow whitelist did. llvm-svn: 301742
* ObjCBoxedExpr can't be evaluated by the constant expression evaluator.Nick Lewycky2017-04-291-2/+5
| | | | | | | | A boxed expression evaluates its subexpr and then calls an objc method to transform it into another value with pointer type. The objc method can never be constexpr and therefore this expression can never be evaluated. Fixes a miscompile boxing expressions with side-effects. Also make ObjCBoxedExpr handling a normal part of the expression evaluator instead of being the only case besides full-expression where we check for integer overflow. llvm-svn: 301721
* In the expression evaluator, visit the index of an ArraySubscriptExpr even ↵Nick Lewycky2017-04-271-3/+8
| | | | | | if we can't evaluate the base, if the evaluation mode tells us to continue evaluation. llvm-svn: 301522
* In the expression evaluator, descend into both the true and false ↵Nick Lewycky2017-04-271-1/+7
| | | | | | expressions of a ConditionalOperator when the condition can't be evaluated and we're in an evaluation mode that says we should continue evaluating. llvm-svn: 301520
* Apply clang-tidy's performance-unnecessary-value-param to parts of clang.Benjamin Kramer2017-03-211-5/+8
| | | | | | No functionality change intended. llvm-svn: 298443
* Honor __unaligned in codegen for declarations and expressionsRoger Ferrer Ibanez2017-03-081-0/+2
| | | | | | | | | | | This patch honors the unaligned type qualifier (currently available through he keyword __unaligned and -fms-extensions) in CodeGen. In the current form the patch affects declarations and expressions. It does not affect fields of classes. Differential Revision: https://reviews.llvm.org/D30166 llvm-svn: 297276
* [coroutines] Add DependentCoawaitExpr and fix re-building CoroutineBodyStmt.Eric Fiselier2017-03-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The changes contained in this patch are: 1. Defines a new AST node `CoawaitDependentExpr` for representing co_await expressions while the promise type is still dependent. 2. Correctly detect and transform the 'co_await' operand to `p.await_transform(<expr>)` when possible. 3. Change the initial/final suspend points to build during the initial parse, so they have the correct operator co_await lookup results. 4. Fix transformation of the CoroutineBodyStmt so that it doesn't re-build the final/initial suspends. @rsmith: This change is a little big, but it's not trivial for me to split it up. Please let me know if you would prefer this submitted as multiple patches. Reviewers: rsmith, GorNishanov Reviewed By: rsmith Subscribers: ABataev, rsmith, mehdi_amini, cfe-commits Differential Revision: https://reviews.llvm.org/D26057 llvm-svn: 297093
* PR32034: Evaluate _Atomic(T) in-place when T is a class or array type.Richard Smith2017-02-221-12/+37
| | | | | | | | This is necessary in order for the evaluation of an _Atomic initializer for those types to have an associated object, which an initializer for class or array type needs. llvm-svn: 295886
* Silence sign compare warning. NFC.Benjamin Kramer2017-02-161-6/+6
| | | | | | | | | ExprConstant.cpp:6344:20: warning: comparison of integers of different signs: 'const size_t' (aka 'const unsigned long') and 'typename iterator_traits<Expr *const *>::difference_type' (aka 'long') [-Wsign-compare] llvm-svn: 295320
* [OpenCL] Correct ndrange_t implementationAnastasia Stulova2017-02-161-1/+0
| | | | | | | | | | | | | | | Removed ndrange_t as Clang builtin type and added as a struct type in the OpenCL header. Use type name to do the Sema checking in enqueue_kernel and modify IR generation accordingly. Review: D28058 Patch by Dmitry Borisenkov! llvm-svn: 295311
* [cxx1z-constexpr-lambda] Implement captures - thus completing implementation ↵Faisal Vali2017-02-161-7/+101
| | | | | | | | | | | | | | of constexpr lambdas. Enable evaluation of captures within constexpr lambdas by using a strategy similar to that used in CodeGen: - when starting evaluation of a lambda's call operator, create a map from VarDecl's to a closure's FieldDecls - every time a VarDecl (or '*this) that represents a capture is encountered while evaluating the expression via the expression evaluator (specifically the LValueEvaluator) in ExprConstant.cpp - it is replaced by the corresponding FieldDecl LValue (an Lvalue-to-Rvalue conversion on this LValue representation then determines the right rvalue when needed). Thanks to Richard Smith and Hubert Tong for their review and feedback! https://reviews.llvm.org/D29748 llvm-svn: 295279
* Don't let EvaluationModes dictate whether an invalid base is OKGeorge Burgess IV2017-02-101-37/+57
| | | | | | | | | | | | What we want to actually control this behavior is something more local than an EvalutationMode. Please see the linked revision for more discussion on why/etc. This fixes PR31843. Differential Revision: https://reviews.llvm.org/D29469 llvm-svn: 294800
* Fix typo. NFCGeorge Burgess IV2017-02-021-1/+1
| | | | llvm-svn: 293871
* Handle ObjCEncodeExpr in extractStringLiteralCharacter.Akira Hatanaka2017-01-311-1/+8
| | | | | | | | | This fixes an assertion failure that occurs later in the function when an ObjCEncodeExpr is cast to StringLiteral. rdar://problem/30111207 llvm-svn: 293596
* Improve fix for PR28739Richard Smith2017-01-311-69/+87
| | | | | | | | | | | | | | | 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-30/+42
| | | | | | | | | | | | | 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
* PR0091R3: Implement parsing support for using templates as types.Richard Smith2017-01-261-0/+1
| | | | | | | | | | | | | | | This change adds a new type node, DeducedTemplateSpecializationType, to represent a type template name that has been used as a type. This is modeled around AutoType, and shares a common base class for representing a deduced placeholder type. We allow deduced class template types in a few more places than the standard does: in conditions and for-range-declarators, and in new-type-ids. This is consistent with GCC and with discussion on the core reflector. This patch does not yet support deduced class template types being named in typename specifiers. llvm-svn: 293207
* P0426: Make the library implementation of constexpr char_traits a little easierRichard Smith2017-01-201-0/+2
| | | | | | | | | by providing a memchr builtin that returns char* instead of void*. Also add a __has_feature flag to indicate the presence of constexpr forms of the relevant <string> functions. llvm-svn: 292555
* Allow constexpr construction of subobjects unconditionally, not just in C++14.David L. Jones2017-01-091-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Per https://wg21.link/CWG1677, the C++11 standard did not clarify that constant initialization of an object allowed constexpr brace-or-equal initialization of subobjects: struct foo_t { union { int i; volatile int j; } u; }; __attribute__((__require_constant_initialization__)) static const foo_t x = {{0}}; Because foo_t::u has a volatile member, the initializer for x fails. However, there is really no good reason, because this: union foo_u { int i; volatile int j; }; __attribute__((__require_constant_initialization__)) static const foo_u x = {0}; does have a constant initializer. (This was triggered by musl's pthread_mutex_t type when building under C++11.) Reviewers: rsmith Subscribers: EricWF, cfe-commits Differential Revision: https://reviews.llvm.org/D28427 llvm-svn: 291480
* Add the diagnose_if attribute to clang.George Burgess IV2017-01-091-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `diagnose_if` can be used to have clang emit either warnings or errors for function calls that meet user-specified conditions. For example: ``` constexpr int foo(int a) __attribute__((diagnose_if(a > 10, "configurations with a > 10 are " "expensive.", "warning"))); int f1 = foo(9); int f2 = foo(10); // warning: configuration with a > 10 are expensive. int f3 = foo(f2); ``` It currently only emits diagnostics in cases where the condition is guaranteed to always be true. So, the following code will emit no warnings: ``` constexpr int bar(int a) { foo(a); return 0; } constexpr int i = bar(10); ``` We hope to support optionally emitting diagnostics for cases like that (and emitting runtime checks) in the future. Release notes will appear shortly. :) Differential Revision: https://reviews.llvm.org/D27424 llvm-svn: 291418
* [cxx1z-constexpr-lambda] Implement constant evaluation of non-capturing ↵Faisal Vali2017-01-091-0/+19
| | | | | | | | | | | | | | | lambda expressions. Add a visitor for lambda expressions to RecordExprEvaluator in ExprConstant.cpp that creates an empty APValue of Struct type to represent the closure object. Additionally, add a LambdaExpr visitor to the TemporaryExprEvaluator that forwards constant evaluation of immediately-called-lambda-expressions to the one in RecordExprEvaluator through VisitConstructExpr. This patch supports: constexpr auto ID = [] (auto a) { return a; }; static_assert(ID(3.14) == 3.14); static_assert([](auto a) { return a + 1; }(10) == 11); Lambda captures are still not supported for constexpr lambdas. llvm-svn: 291416
* [cxx1z-constexpr-lambda] Make conversion function constexpr, and teach the ↵Faisal Vali2017-01-081-6/+40
| | | | | | | | | | | | expression-evaluator to evaluate the static-invoker. This patch has been sitting in review hell since july 2016 and our lack of constexpr lambda support is getting embarrassing (given that I've had a branch that implements the feature (modulo *this capture) for over a year. While in Issaquah I was enjoying shamelessly trying to convince folks of the lie that this was Richard's fault ;) I won't be able to do so in Kona since I won't be attending - so I'm going to aim to have this feature be implemented by then. I'm quite confident of the approach in this patch, which simply maps the static-invoker 'thunk' back to the corresponding call-operator (specialization). Thanks! llvm-svn: 291397
* Re-add objectsize function/incomplete type checks.George Burgess IV2017-01-031-2/+8
| | | | | | | I accidentally omitted these when refactoring this code. This caused problems when building parts of the test-suite on MacOS. llvm-svn: 290916
OpenPOWER on IntegriCloud