summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/ExprConstant.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [ExprConstant] Look through ExprWithCleanups for `allocsize`George Burgess IV2018-03-061-1/+5
| | | | llvm-svn: 326766
* [Attr] Fix parameter indexing for several attributesJoel E. Denny2018-03-021-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch fixes a number of bugs related to parameter indexing in attributes: * Parameter indices in some attributes (argument_with_type_tag, pointer_with_type_tag, nonnull, ownership_takes, ownership_holds, and ownership_returns) are specified in source as one-origin including any C++ implicit this parameter, were stored as zero-origin excluding any this parameter, and were erroneously printing (-ast-print) and confusingly dumping (-ast-dump) as the stored values. * For alloc_size, the C++ implicit this parameter was not subtracted correctly in Sema, leading to assert failures or to silent failures of __builtin_object_size to compute a value. * For argument_with_type_tag, pointer_with_type_tag, and ownership_returns, the C++ implicit this parameter was not added back to parameter indices in some diagnostics. This patch fixes the above bugs and aims to prevent similar bugs in the future by introducing careful mechanisms for handling parameter indices in attributes. ParamIdx stores a parameter index and is designed to hide the stored encoding while providing accessors that require each use (such as printing) to make explicit the encoding that is needed. Attribute declarations declare parameter index arguments as [Variadic]ParamIdxArgument, which are exposed as ParamIdx[*]. This patch rewrites all attribute arguments that are processed by checkFunctionOrMethodParameterIndex in SemaDeclAttr.cpp to be declared as [Variadic]ParamIdxArgument. The only exception is xray_log_args's argument, which is encoded as a count not an index. Differential Revision: https://reviews.llvm.org/D43248 llvm-svn: 326602
* Remove redundant casts. NFCGeorge Burgess IV2018-03-011-1/+1
| | | | | | | | | | | | | | | | | | | So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and `dyn_cast`s for fun. This is a portion of what it found for clang; I plan to do similar cleanups in LLVM and other subprojects when I find time. Because of the volume of changes, I explicitly avoided making any change that wasn't highly local and obviously correct to me (e.g. we still have a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading is a thing and the cast<Bar> did actually change the type -- just up the class hierarchy). I also tried to leave the types we were cast<>ing to somewhere nearby, in cases where it wasn't locally obvious what we were dealing with before. llvm-svn: 326416
* [ExprConstant] Fix crash when initialize an indirect field with another field.Volodymyr Sapsai2018-02-231-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* In C++14 onwards, it is permitted to read mutable members in constantRichard Smith2018-02-211-10/+22
| | | | | | | | | 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
* [AST] Refine the condition for element-dependent array fillersIvan A. Kosarev2018-02-141-2/+23
| | | | | | | | | | | | This patch fixes clang to not consider braced initializers for aggregate elements of arrays to be potentially dependent on the indices of the initialized elements. Resolves bug 18978: initialize a large static array = clang oom? https://bugs.llvm.org/show_bug.cgi?id=18978 Differential Revision: https://reviews.llvm.org/D43187 llvm-svn: 325120
* Track in the AST whether the operand to a UnaryOperator can overflow and ↵Aaron Ballman2018-01-091-48/+41
| | | | | | then use that logic when evaluating constant expressions and emitting codegen. llvm-svn: 322074
* Add support for a limited subset of TS 18661-3 math builtins.Benjamin Kramer2018-01-061-2/+8
| | | | | | | | | | | | | | | | | These just overloads for _Float128. They're supported by GCC 7 and used by glibc. APFloat support is already there so just add the overloads. __builtin_copysignf128 __builtin_fabsf128 __builtin_huge_valf128 __builtin_inff128 __builtin_nanf128 __builtin_nansf128 This is the same support that GCC has, according to the documentation, but limited to _Float128. llvm-svn: 321948
* Fix an assertion failure regression in isDesignatorAtObjectEnd forAlex Lorenz2017-12-201-1/+4
| | | | | | | | | | | | | | __builtin_object_size with incomplete array type in struct The commit r316245 introduced a regression that causes an assertion failure when Clang tries to cast an IncompleteArrayType to a PointerType when evaluating __builtin_object_size. rdar://36094951 Differential Revision: https://reviews.llvm.org/D41405 llvm-svn: 321222
* Silence a bunch of implicit fallthrough warningsAdrian Prantl2017-12-191-5/+6
| | | | llvm-svn: 321115
* [c++20] P0515R3: Parsing support and basic AST construction for operator <=>.Richard Smith2017-12-141-0/+1
| | | | | | | | | | | | | | | Adding the new enumerator forced a bunch more changes into this patch than I would have liked. The -Wtautological-compare warning was extended to properly check the new comparison operator, clang-format needed updating because it uses precedence levels as weights for determining where to break lines (and several operators increased their precedence levels with this change), thread-safety analysis needed changes to build its own IL properly for the new operator. All "real" semantic checking for this operator has been deferred to a future patch. For now, we use the relational comparison rules and arbitrarily give the builtin form of the operator a return type of 'void'. llvm-svn: 320707
* 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
OpenPOWER on IntegriCloud