summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/ExprConstant.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Support constant evaluation for member calls on std::initializer_listRichard Smith2014-12-171-0/+3
| | | | | | temporaries. llvm-svn: 224449
* Improve handling of value dependent expressions in ↵Nick Lewycky2014-12-161-1/+2
| | | | | | __attribute__((enable_if)), both in the condition expression and at the call site. Fixes PR20988! llvm-svn: 224320
* AST: Limit zero-sized constexpr behavior to array typesDavid Majnemer2014-12-141-1/+3
| | | | | | | Restricting this "extension" to array types maximizes our standards conformance while not miscompiling real-world programs. llvm-svn: 224215
* AST: Incomplete types might be zero sizedDavid Majnemer2014-12-111-3/+7
| | | | | | | | Comparing the address of an object with an incomplete type might return true with a 'distinct' object if the former has a size of zero. However, such an object should compare unequal with null. llvm-svn: 224040
* AST: Don't assume two zero sized objects live at different addressesDavid Majnemer2014-12-091-0/+10
| | | | | | | | Zero sized objects may overlap with each other or any other object. This fixes PR21786. llvm-svn: 223852
* [OpenCL] Implemented restrictions for pointer conversions specified in ↵Anastasia Stulova2014-11-261-0/+1
| | | | | | | | | | | | OpenCL v2.0. OpenCL v2.0 s6.5.5 restricts conversion of pointers to different address spaces: - the named address spaces (__global, __local, and __private) => __generic - implicitly converted; - __generic => named - with an explicit cast; - named <=> named - disallowed; - __constant <=> any other - disallowed. llvm-svn: 222834
* Fix bug where a trivial constexpr copy/move operation couldn't copy from anRichard Smith2014-11-191-4/+31
| | | | | | | empty non-constexpr object. Such a copy doesn't break any of the constexpr rules. llvm-svn: 222387
* Fix assert/crash on invalid with __builtin_constant_p conditionals in ↵Richard Smith2014-11-131-1/+5
| | | | | | constant expressions. llvm-svn: 221942
* [c++1z] N4295: fold-expressions.Richard Smith2014-11-081-0/+1
| | | | | | | | | | | | | | | | This is a new form of expression of the form: (expr op ... op expr) where one of the exprs is a parameter pack. It expands into (expr1 op (expr2onwards op ... op expr)) (and likewise if the pack is on the right). The non-pack operand can be omitted; in that case, an empty pack gives a fallback value or an error, depending on the operator. llvm-svn: 221573
* Add the initial TypoExpr AST node for delayed typo correction.Kaelyn Takata2014-10-271-0/+1
| | | | llvm-svn: 220692
* PR21327 / C++ DR1652 / C++ DR73: comparing a past-the-end pointer for oneRichard Smith2014-10-211-0/+28
| | | | | | | | complete object to a pointer to the start of another complete object does not evaluate to the constant 'false'. All other comparisons between the addresses of subobjects of distinct complete objects still do. llvm-svn: 220343
* [complex] Teach the other two binary operators on complex numbers (==Chandler Carruth2014-10-111-5/+17
| | | | | | | | | | | | | | | | | and !=) to support mixed complex and real operand types. This requires removing an assert from SemaChecking, and adding support both to the constant evaluator and the code generator to synthesize the imaginary part when needed. This seemed somewhat cleaner than having just the comparison operators force real-to-complex conversions. I've added test cases for these operations. I'm really terrified that there were *no* tests in-tree which exercised this. This turned up when trying to build R after my change to the complex type lowering. llvm-svn: 219570
* [complex] Teach Clang to preserve different-type operands to arithmeticChandler Carruth2014-10-111-52/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
* Fix for bug http://llvm.org/PR17427.Alexey Bataev2014-10-091-3/+5
| | | | | | | | Assertion failed: "Computed __func__ length differs from type!" Reworked PredefinedExpr representation with internal StringLiteral field for function declaration. Differential Revision: http://reviews.llvm.org/D5365 llvm-svn: 219393
* constexpr evaluation for __builtin_assume_alignedHal Finkel2014-10-031-37/+98
| | | | | | | | | | | | | | | | | Richard noted in the review of r217349 that extra handling of __builtin_assume_aligned inside of the expression evaluator was needed. He was right, and this should address the concerns raised, namely: 1. The offset argument to __builtin_assume_aligned can have side effects, and we need to make sure that all arguments are properly evaluated. 2. If the alignment assumption does not hold, that introduces undefined behavior, and undefined behavior cannot appear inside a constexpr. and hopefully the diagnostics produced are detailed enough to explain what is going on. llvm-svn: 218992
* Revert useless part of r217349Hal Finkel2014-10-031-1/+0
| | | | | | | | | | Adding handling of __builtin_assume_aligned to IntExprEvaluator does not make sense because __builtin_assume_aligned returns a pointer (not an integer). Thanks to Richard for figuring out why this was not doing anything. I'll add this back in a better place (PointerExprEvaluator perhaps). llvm-svn: 218958
* Fix evatuated value of __builtin_object_size according to itsFariborz Jahanian2014-09-221-2/+14
| | | | | | | 'type' argument when it cannot be determined which objects ptr points to at compile time. rdar://18334276 llvm-svn: 218258
* Reject a slightly-sneaky way to perform a read of mutable state from within aRichard Smith2014-09-161-0/+66
| | | | | | | | | constexpr function. Part of this fix is a tentative fix for an as-yet-unfiled core issue (we're missing a prohibition against reading mutable members from unions via a trivial constructor/assignment, since that doesn't perform an lvalue-to-rvalue conversion on the members). llvm-svn: 217852
* Add __builtin_assume and __builtin_assume_aligned using @llvm.assume.Hal Finkel2014-09-071-0/+2
| | | | | | | | | | | This makes use of the recently-added @llvm.assume intrinsic to implement a __builtin_assume(bool) intrinsic (to provide additional information to the optimizer). This hooks up __assume in MS-compatibility mode to mirror __builtin_assume (the semantics have been intentionally kept compatible), and implements GCC's __builtin_assume_aligned as assume((p - o) & mask == 0). LLVM now contains special logic to deal with assumptions of this form. llvm-svn: 217349
* Simplify creation of a bunch of ArrayRefs by using None, makeArrayRef or ↵Craig Topper2014-08-271-3/+3
| | | | | | just letting them be implicitly created. llvm-svn: 216528
* C++1y is now C++14!Aaron Ballman2014-08-191-10/+10
| | | | | | Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording. llvm-svn: 215982
* PR18097: Support initializing an _Atomic(T) from an object of C++ class type TRichard Smith2014-07-311-0/+5
| | | | | | | or a class derived from T. We already supported this when initializing _Atomic(T) from T for most (and maybe all) other reasonable values of T. llvm-svn: 214390
* Replace r213816's fix with a different one. It's not meaningful to callRichard Smith2014-07-231-3/+2
| | | | | | | isOnePastTheEnd on an invalid designator, so assert and push the check into the one caller that wasn't already checking. llvm-svn: 213820
* Add a missing Invalid check to SubobjectDesignator::isOnePastEnd()Reid Kleckner2014-07-231-0/+2
| | | | | | | | | | | The class seems to have an invariant that Entries is non-empty if Invalid is false. It appears this method was previously private, and all internal uses checked Invalid. Now there is an external caller, so check Invalid to avoid array OOB underflow. Fixes PR20420. llvm-svn: 213816
* Handle __assume in the VoidExprEvaluatorHal Finkel2014-07-171-0/+10
| | | | | | | | This is a follow-up to an IRC conversation with Richard last night; __assume does not evaluate its argument, and so the argument should not contribute to whether (__assume(e), constant) can be used where a constant is required. llvm-svn: 213267
* Handle __builtin_clzs and __builtin_ctzs in the constant expression evaluator.Anders Carlsson2014-07-071-2/+4
| | | | llvm-svn: 212464
* Add an explicit diagnostic for the case where an expression is not a constantRichard Smith2014-07-071-2/+7
| | | | | | expression because it uses 'this'. Inspired by PR20219 comment#2. llvm-svn: 212433
* Remove llvm:: from uses of ArrayRef.Craig Topper2014-06-281-1/+1
| | | | llvm-svn: 211987
* Don't allow dllimport variables in constant initializersHans Wennborg2014-06-251-10/+3
| | | | | | | | | | | | | | | | | This is a follow-up to David's r211677. For the following code, we would end up referring to 'foo' in the initializer for 'arr', and then fail to link, because 'foo' is dllimport and needs to be accessed through the __imp_?foo. __declspec(dllimport) extern const char foo[]; const char* f() { static const char* const arr[] = { foo }; return arr[0]; } Differential Revision: http://reviews.llvm.org/D4299 llvm-svn: 211736
* AST: Initialization with dllimport functions in CDavid Majnemer2014-06-251-8/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The C++ language requires that the address of a function be the same across all translation units. To make __declspec(dllimport) useful, this means that a dllimported function must also obey this rule. MSVC implements this by dynamically querying the import address table located in the linked executable. This means that the address of such a function in C++ is not constant (which violates other rules). However, the C language has no notion of ODR nor does it permit dynamic initialization whatsoever. This requires implementations to _not_ dynamically query the import address table and instead utilize a wrapper function that will be synthesized by the linker which will eventually query the import address table. The effect this has is, to say the least, perplexing. Consider the following C program: __declspec(dllimport) void f(void); typedef void (*fp)(void); static const fp var = &f; const fp fun() { return &f; } int main() { return fun() == var; } MSVC will statically initialize "var" with the address of the wrapper function and "fun" returns the address of the actual imported function. This means that "main" will return false! Note that LLVM's optimizers are strong enough to figure out that "main" should return true. However, this result is dependent on having optimizations enabled! N.B. This change also permits the usage of dllimport declarators inside of template arguments; they are sufficiently constant for such a purpose. Add tests to make sure we don't regress here. llvm-svn: 211677
* AST: Address of dllimport functions isn't constantDavid Majnemer2014-06-241-1/+4
| | | | | | | | | | | | | | | | The address of dllimport functions can be accessed one of two ways: - Through the IAT which is symbolically referred to with a symbol starting with __imp_. - Via the wrapper-function which ends up calling through the __imp_ symbol. The problem with using the wrapper-function is that it's address will not compare as equal in all translation units. Specifically, it will compare unequally with the translation unit which defines the function. This fixes PR19955. llvm-svn: 211570
* AST: Address of dllimport variables isn't constantDavid Majnemer2014-06-241-0/+3
| | | | | | | | | | | | | The address of dllimport variables isn't something that can be meaningfully used in a constexpr context and isn't suitable for evaluation at load-time. They require loads from memory to properly evaluate. This fixes PR19955. Differential Revision: http://reviews.llvm.org/D4250 llvm-svn: 211568
* Add missing "non-constant" diagnostic for a member call on a temporary ofRichard Smith2014-06-111-0/+1
| | | | | | non-literal class type. llvm-svn: 210696
* Related to PR19992: when the GNU alignof-expression extension is applied to anRichard Smith2014-06-101-3/+4
| | | | | | | expression of array-of-unknown-bound type, don't try to complete the array bound, and return the alignment of the element type rather than 1. llvm-svn: 210608
* [C++11] Use 'nullptr'. AST edition.Craig Topper2014-05-121-55/+58
| | | | llvm-svn: 208517
* PR19346: Adding 0 to a null pointer has defined behavior in C++. Allow it in ↵Richard Smith2014-04-081-2/+2
| | | | | | constant expressions. llvm-svn: 205757
* [C++11] Replacing CompoundStmt iterators body_begin() and body_end() with ↵Aaron Ballman2014-03-171-3/+2
| | | | | | iterator_range body(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 204040
* Fix a crash (assertion failure) in EvaluateAsRValue.James Dennett2014-03-141-0/+10
| | | | | | | | | | | | | | | | Summary: Gracefully fail to evaluate a constant expression if its type is unknown, rather than failing an assertion trying to access the type. Reviewers: klimek Reviewed By: klimek CC: chandlerc, cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D3075 llvm-svn: 203950
* [C++11] Replacing DeclStmt iterators decl_begin() and decl_end() with ↵Aaron Ballman2014-03-141-3/+2
| | | | | | iterator_range decls(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203947
* [C++11] Replacing CXXRecordDecl iterators init_begin() and init_end() with ↵Aaron Ballman2014-03-131-11/+10
| | | | | | iterator_range inits(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203819
* Reverting llvm::distance changes to use std::distance with iterators ↵Aaron Ballman2014-03-101-4/+5
| | | | | | | | instead, per post-commit review feedback. Replacing llvm::copy changes with SmallVector range-based construction which is a considerably cleaner approach. llvm-svn: 203461
* [C++11] Replacing RecordDecl iterators field_begin() and field_end() with ↵Aaron Ballman2014-03-081-14/+10
| | | | | | iterator_range fields(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203355
* Renaming the chains() ranged iterator to chain() per suggestion by Richard ↵Aaron Ballman2014-03-071-2/+2
| | | | | | Smith. llvm-svn: 203262
* [C++11] Replacing IndirectFieldDecl iterators chain_begin() and chain_end() ↵Aaron Ballman2014-03-071-7/+4
| | | | | | with iterator_range chains(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203261
* PR19010: Make sure we initialize (empty) indirect base class subobjects whenRichard Smith2014-03-051-23/+12
| | | | | | evaluating trivial default initialization of a literal class type. llvm-svn: 203025
* [AST] Follow-up for r201468, move the check to the caller and add an assertion.Argyrios Kyrtzidis2014-02-201-4/+8
| | | | | | Suggested by Richard Smith. llvm-svn: 201753
* [Sema] Fix assertion hit while trying to do constant evaluation for a ↵Argyrios Kyrtzidis2014-02-151-0/+2
| | | | | | | | | | dependent expression inside a GNU statement expression. rdar://16064952 llvm-svn: 201468
* PR18283: If a const variable of integral or enumeration type isRichard Smith2014-01-251-1/+11
| | | | | | | | initialized from a constant expression in C++98, it can be used in constant expressions, even if it was brace-initialized. Patch by Rahul Jain! llvm-svn: 200098
* Rename getResultType() on function and method declarations to getReturnType()Alp Toker2014-01-251-1/+1
| | | | | | | | | | | | | | | A return type is the declared or deduced part of the function type specified in the declaration. A result type is the (potentially adjusted) type of the value of an expression that calls the function. Rule of thumb: * Declarations have return types and parameters. * Expressions have result types and arguments. llvm-svn: 200082
* Add a new attribute 'enable_if' which can be used to control overload ↵Nick Lewycky2014-01-111-4/+85
| | | | | | resolution based on the values of the function arguments at the call site. llvm-svn: 198996
OpenPOWER on IntegriCloud