summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/ExprConstant.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Emit CCEDiags when evaluating a const variable.George Burgess IV2016-12-271-1/+4
| | | | | | This addresses post-review feedback from r290577. llvm-svn: 290584
* Fix problems in "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare ↵Egor Churaev2016-12-231-0/+2
| | | | | | | | | | | | | | operand." Summary: Fixed warnings in commit: https://reviews.llvm.org/rL290171 Reviewers: djasper, Anastasia Subscribers: yaxunl, cfe-commits, bader Differential Revision: https://reviews.llvm.org/D27981 llvm-svn: 290431
* Add the alloc_size attribute to clang, attempt 2.George Burgess IV2016-12-221-183/+433
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a recommit of r290149, which was reverted in r290169 due to msan failures. msan was failing because we were calling `isMostDerivedAnUnsizedArray` on an invalid designator, which caused us to read uninitialized memory. To fix this, the logic of the caller of said function was simplified, and we now have a `!Invalid` assert in `isMostDerivedAnUnsizedArray`, so we can catch this particular bug more easily in the future. Fingers crossed that this patch sticks this time. :) Original commit message: This patch does three things: - Gives us the alloc_size attribute in clang, which lets us infer the number of bytes handed back to us by malloc/realloc/calloc/any user functions that act in a similar manner. - Teaches our constexpr evaluator that evaluating some `const` variables is OK sometimes. This is why we have a change in test/SemaCXX/constant-expression-cxx11.cpp and other seemingly unrelated tests. Richard Smith okay'ed this idea some time ago in person. - Uniques some Blocks in CodeGen, which was reviewed separately at D26410. Lack of uniquing only really shows up as a problem when combined with our new eagerness in the face of const. llvm-svn: 290297
* Revert "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand."Daniel Jasper2016-12-201-2/+0
| | | | | | | | | | This reverts commit r290171. It triggers a bunch of warnings, because the new enumerator isn't handled in all switches. We want a warning-free build. Replied on the commit with more details. llvm-svn: 290173
* [OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand.Egor Churaev2016-12-201-0/+2
| | | | | | | | | | | | Summary: Enabling the compression of CLK_NULL_QUEUE to variable of type queue_t. Reviewers: Anastasia Subscribers: cfe-commits, yaxunl, bader Differential Revision: https://reviews.llvm.org/D27569 llvm-svn: 290171
* Revert r290149: Add the alloc_size attribute to clang.Chandler Carruth2016-12-201-434/+182
| | | | | | | | | | | | | | | This commit fails MSan when running test/CodeGen/object-size.c in a confusing way. After some discussion with George, it isn't really clear what is going on here. We can make the MSan failure go away by testing for the invalid bit, but *why* things are invalid isn't clear. And yet, other code in the surrounding area is doing precisely this and testing for invalid. George is going to take a closer look at this to better understand the nature of the failure and recommit it, for now backing it out to clean up MSan builds. llvm-svn: 290169
* Add the alloc_size attribute to clang.George Burgess IV2016-12-201-182/+434
| | | | | | | | | | | | | | | | | | | | This patch does three things: - Gives us the alloc_size attribute in clang, which lets us infer the number of bytes handed back to us by malloc/realloc/calloc/any user functions that act in a similar manner. - Teaches our constexpr evaluator that evaluating some `const` variables is OK sometimes. This is why we have a change in test/SemaCXX/constant-expression-cxx11.cpp and other seemingly unrelated tests. Richard Smith okay'ed this idea some time ago in person. - Uniques some Blocks in CodeGen, which was reviewed separately at D26410. Lack of uniquing only really shows up as a problem when combined with our new eagerness in the face of const. Differential Revision: https://reviews.llvm.org/D14274 llvm-svn: 290149
* Re-commit r289252 and r289285, and fix PR31374Yaxun Liu2016-12-151-15/+42
| | | | llvm-svn: 289787
* [c++1z] Permit constant evaluation of a call through a function pointer whoseRichard Smith2016-12-151-1/+4
| | | | | | | type differs from the type of the actual function due to having a different exception specification. llvm-svn: 289754
* Revert 289252 (and follow-up 289285), it caused PR31374Nico Weber2016-12-141-42/+15
| | | | llvm-svn: 289713
* Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann2016-12-141-2/+2
| | | | | | | | | | | | | At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
* Align EvalInfo in ExprConstant to avoid PointerUnion assertionsReid Kleckner2016-12-131-1/+1
| | | | | | | | | 32-bit MSVC doesn't provide more than 4 byte stack alignment by default. This conflicts with PointerUnion's attempt to make assertions about alignment. This fixes the problem by explicitly asking the compiler for 8 byte alignment. llvm-svn: 289575
* Add two new AST nodes to represent initialization of an array in terms ofRichard Smith2016-12-121-0/+60
| | | | | | | | | | | | | | | | | | | | initialization of each array element: * ArrayInitLoopExpr is a prvalue of array type with two subexpressions: a common expression (an OpaqueValueExpr) that represents the up-front computation of the source of the initialization, and a subexpression representing a per-element initializer * ArrayInitIndexExpr is a prvalue of type size_t representing the current position in the loop This will be used to replace the creation of explicit index variables in lambda capture of arrays and copy/move construction of classes with array elements, and also C++17 structured bindings of arrays by value (which inexplicably allow copying an array by value, unlike all of C++'s other array declarations). No uses of these nodes are introduced by this change, however. llvm-svn: 289413
* Add support for non-zero null pointer for C and OpenCLYaxun Liu2016-12-091-15/+42
| | | | | | | | | | | | | | | | | | In amdgcn target, null pointers in global, constant, and generic address space take value 0 but null pointers in private and local address space take value -1. Currently LLVM assumes all null pointers take value 0, which results in incorrectly translated IR. To workaround this issue, instead of emit null pointers in local and private address space, a null pointer in generic address space is emitted and casted to local and private address space. Tentative definition of global variables with non-zero initializer will have weak linkage instead of common linkage since common linkage requires zero initializer and does not have explicit section to hold the non-zero value. Virtual member functions getNullPointer and performAddrSpaceCast are added to TargetCodeGenInfo which by default returns ConstantPointerNull and emitting addrspacecast instruction. A virtual member function getNullPointerValue is added to TargetInfo which by default returns 0. Each target can override these virtual functions to get target specific null pointer and the null pointer value for specific address space, and perform specific translations for addrspacecast. Wrapper functions getNullPointer is added to CodegenModule and getTargetNullPointerValue is added to ASTContext to facilitate getting the target specific null pointers and their values. This change has no effect on other targets except amdgcn target. Other targets can provide support of non-zero null pointer in a similar way. This change only provides support for non-zero null pointer for C and OpenCL. Supporting for other languages will be added later incrementally. Differential Revision: https://reviews.llvm.org/D26196 llvm-svn: 289252
* DR1295 and cleanup for P0135R1: Make our initialization code more directlyRichard Smith2016-12-091-2/+2
| | | | | | | | | | | | | | | mirror the description in the standard. Per DR1295, this means that binding a const / rvalue reference to a bit-field no longer "binds directly", and per P0135R1, this means that we materialize a temporary in reference binding after adjusting cv-qualifiers and before performing a derived-to-base cast. In C++11 onwards, this should have fixed the last case where we would materialize a temporary of the wrong type (with a subobject adjustment inside the MaterializeTemporaryExpr instead of outside), but we still have to deal with that possibility in C++98, unless we want to start using xvalues to represent materialized temporaries there too. llvm-svn: 289250
* [c++17] P0135R1: Guaranteed copy elision.Richard Smith2016-12-061-0/+3
| | | | | | | | When an object of class type is initialized from a prvalue of the same type (ignoring cv qualifications), use the prvalue to initialize the object directly instead of inserting a redundant elidable call to a copy constructor. llvm-svn: 288866
* DR1213: element access on an array xvalue or prvalue produces an xvalue. In theRichard Smith2016-12-051-3/+3
| | | | | | | | | | | | | | latter case, a temporary array object is materialized, and can be lifetime-extended by binding a reference to the member access. Likewise, in an array-to-pointer decay, an rvalue array is materialized before being converted into a pointer. This caused IR generation to stop treating file-scope array compound literals as having static storage duration in some cases in C++; that has been rectified by modeling such a compound literal as an lvalue. This also improves clang's compatibility with GCC for those cases. llvm-svn: 288654
* Support constant expression evaluation for wchar_t versions of simple stringRichard Smith2016-11-291-30/+72
| | | | | | functions, in order to support constexpr std::char_traits<wchar_t>. llvm-svn: 288193
* Outline evaluation of calls to builtins to avoid inflating stack usage for theRichard Smith2016-11-161-1/+19
| | | | | | | common case of a call to a non-builtin, particularly for unoptimized ASan builds (where the per-variable stack usage can be quite high). llvm-svn: 287066
* Fix PR28366: Handle variables from enclosing local scopes more gracefully ↵Faisal Vali2016-11-131-2/+13
| | | | | | | | | | | | | | | | | | during constant expression evaluation. Only look for a variable's value in the constant expression evaluation activation frame, if the variable was indeed declared in that frame, otherwise it might be a constant expression and be usable within a nested local scope or emit an error. void f(char c) { struct X { static constexpr char f() { return c; // error gracefully here as opposed to crashing. } }; int I = X::f(); } llvm-svn: 286748
* [c++1z] Support constant folding for __builtin_strchr and __builtin_memchr.Richard Smith2016-11-121-3/+62
| | | | llvm-svn: 286699
* [c++1z] Add constant-folding support for strcmp, strncmp, and memcmp, toRichard Smith2016-11-111-0/+50
| | | | | | support constexpr char_traits. llvm-svn: 286678
* Remove move constructors that are identical to the generated default move ctor.Benjamin Kramer2016-10-211-3/+1
| | | | llvm-svn: 284856
* AST: Prefer LLVM_NODISCARD to LLVM_ATTRIBUTE_UNUSED_RESULTJustin Bogner2016-10-171-1/+1
| | | | llvm-svn: 284366
* Un-tabify source files, NFC.Yaron Keren2016-10-081-2/+2
| | | | llvm-svn: 283657
* Reorder initializers in CallStackFrame so that we don't get a warning.Samuel Antao2016-09-191-2/+2
| | | | llvm-svn: 281923
* Remove excessive padding from the struct CallStackFrameAlexander Shaposhnikov2016-09-191-6/+6
| | | | | | | | | | | The struct CallStackFrame is in lib/AST/ExprConstant.cpp inside anonymous namespace. This diff reorders the fields and removes excessive padding. Test plan: make -j8 check-clang Differential revision: https://reviews.llvm.org/D23901 llvm-svn: 281907
* [Sema] Fix PR30346: relax __builtin_object_size checks.George Burgess IV2016-09-121-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes us act more conservatively when trying to determine the objectsize for an array at the end of an object. This is in response to code like the following: ``` struct sockaddr { /* snip */ char sa_data[14]; }; void foo(const char *s) { size_t slen = strlen(s) + 1; size_t added_len = slen <= 14 ? 0 : slen - 14; struct sockaddr *sa = malloc(sizeof(struct sockaddr) + added_len); strcpy(sa->sa_data, s); // ... } ``` `__builtin_object_size(sa->sa_data, 1)` would return 14, when there could be more than 14 bytes at `sa->sa_data`. Code like this is apparently not uncommon. FreeBSD's manual even explicitly mentions this pattern: https://www.freebsd.org/doc/en/books/developers-handbook/sockets-essential-functions.html (section 7.5.1.1.2). In light of this, we now just give up on any array at the end of an object if we can't find the object's initial allocation. I lack numbers for how much more conservative we actually become as a result of this change, so I chose the fix that would make us as compatible with GCC as possible. If we want to be more aggressive, I'm happy to consider some kind of whitelist or something instead. llvm-svn: 281277
* Explicitly generate a reference variable to hold the initializer for aRichard Smith2016-08-141-84/+37
| | | | | | | | tuple-like decomposition declaration. This significantly simplifies the semantics of BindingDecls for AST consumers (they can now always be evalated at the point of use). llvm-svn: 278640
* P0217R3: Constant expression evaluation for decomposition declarations.Richard Smith2016-08-121-0/+62
| | | | llvm-svn: 278447
* [OpenCL] Generate opaque type for sampler_t and function call for the ↵Yaxun Liu2016-07-281-0/+2
| | | | | | | | | | | | | | | | initializer Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type. This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer. Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions. This patch is partially based on Alexey Sotkin's work in Khronos Clang (https://github.com/KhronosGroup/SPIR/commit/3d4eec61623502fc306e8c67c9868be2b136e42b). Differential Revision: https://reviews.llvm.org/D21567 llvm-svn: 277024
* Fix some minor issues found by Coverity.Richard Smith2016-07-181-0/+2
| | | | llvm-svn: 275925
* [NFC] Header cleanupMehdi Amini2016-07-181-1/+0
| | | | | | | | | | Summary: Removed unused headers, replaced some headers with forward class declarations Patch by: Eugene <claprix@yandex.ru> Differential Revision: https://reviews.llvm.org/D20100 llvm-svn: 275882
* [ObjC] Implement @available in the Parser and ASTErik Pilkington2016-07-161-0/+1
| | | | | | | | | | | | | | | | This patch adds a new AST node: ObjCAvailabilityCheckExpr, and teaches the Parser and Sema to generate it. This node represents an availability check of the form: @available(macos 10.10, *); Which will eventually compile to a runtime check of the host's OS version. This is the first patch of the feature I proposed here: http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html Differential Revision: https://reviews.llvm.org/D22171 llvm-svn: 275654
* P0305R0: Semantic analysis and code generation for C++17 init-statement for ↵Richard Smith2016-07-141-0/+10
| | | | | | | | | | 'if' and 'switch': if (stmt; condition) { ... } Patch by Anton Bikineev! Some minor formatting and comment tweets by me. llvm-svn: 275350
* [Refactor NFC] Rename the (non-CCE, fold-failure) Diag during constant ↵Faisal Vali2016-07-021-102/+112
| | | | | | | | | | | | expression evaluation as FFDiag. Currently, we have CCEDiags (C++11 core constant expression diags) and Fold failure diagnostics [I don't claim to yet fully understand exactly why we need the difference]. This patch explicitly replaces Info.Diag (whose use always represents a fold failure diag within the file) with Info.FFDiag. This makes it more easily greppable in the file, and just like the name Info.CCEDiag, it gives the reader slight further insight into the nature of the diagnostic (as opposed to Info.Diag). This patch is a preliminary refactoring step in an effort to allow support for compatibility-warnings and extensions (such as constexpr lambda) during constant expression evaluation. All regressions pass. llvm-svn: 274454
* Use the same type for adjacent bit field members.Akira Hatanaka2016-06-301-4/+4
| | | | | | | | | MSVC doesn't pack the bit field members if different types are used. This came up in a patch review. http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160627/163107.html llvm-svn: 274190
* P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:Richard Smith2016-06-281-20/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class llvm-svn: 274049
* [ExprConstant] Fix PR28314 - crash while evluating objectsize.George Burgess IV2016-06-271-10/+18
| | | | | | | | | | | | | | | | | | | | | This fixes a crash in code like: ``` struct A { struct B b; char c[1]; } int foo(struct A* a) { return __builtin_object_size(a->c, 0); } ``` We wouldn't check whether the structs we were examining were invalid, and getting the layout of an invalid struct is (unsurprisingly) A Bad Thing. With this patch, we'll always return conservatively if we see an invalid struct, since I'm assuming the presence of an invalid struct means that our compilation failed (so having a conservative result isn't such a big deal). llvm-svn: 273911
OpenPOWER on IntegriCloud