summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/ExprConstant.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* [OPENCL] Fix wrongly vla error for OpenCL array.Xiuli Pan2016-06-071-1/+4
| | | | | | | | | | | | | | | | | Summary: OpenCL should support array with const value size length, those const varibale in global and constant address space and variable in constant address space. Fixed test case error. Reviewers: Anastasia, yaxunl, bader Subscribers: bader, cfe-commits Differential Revision: http://reviews.llvm.org/D20090 llvm-svn: 271978
* Revert "[OPENCL] Fix wrongly vla error for OpenCL array."Xiuli Pan2016-06-071-4/+1
| | | | | | | | Test case break on system-z. This reverts commit 9a7212e1e87f1396952d74f8c62314a775ccbb1c. llvm-svn: 271975
* [OPENCL] Fix wrongly vla error for OpenCL array.Xiuli Pan2016-06-071-1/+4
| | | | | | | | | | | | | Summary: OpenCL should support array with const value size length, those const varibale in global and constant address space and variable in constant address space. Reviewers: Anastasia, yaxunl, bader Subscribers: bader, cfe-commits Differential Revision: http://reviews.llvm.org/D20090 llvm-svn: 271971
* Sema: do not attempt to sizeof a dependent typeSaleem Abdulrasool2016-06-041-0/+5
| | | | | | | | | We would attempt to evaluate the sizeof a dependent type to check for an integral overflow. However, because the dependent type is not yet resolved, we cannot determine if the expression would overflow. Report a failure to perform a symbolic evaluation of a constant involving the dependent type. llvm-svn: 271762
* PR27989: only enqueue binary operators into the data recursive int expressionRichard Smith2016-06-041-1/+3
| | | | | | evaluator if they are actually int expressions. llvm-svn: 271754
* [Sema] Use the failure bits introduced by r270781.George Burgess IV2016-05-251-17/+17
| | | | | | | | | | r270781 introduced the ability to track whether or not we might have had unmodeled side-effects during constant expression evaluation. This patch makes the constexpr evaluator use that tracking. Reviewed as a part of D18540. llvm-svn: 270784
* [Sema] Note when we encounter a problem in ExprConstant.George Burgess IV2016-05-251-33/+106
| | | | | | | | | | | | | | | | | | | | 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
* Fix rejects-valid on constexpr function that accesses a not-yet-defined 'externRichard Smith2016-05-251-3/+8
| | | | | | | const' variable. That variable might be defined as 'constexpr', so we cannot prove that a use of it could never be a constant expression. llvm-svn: 270774
* Refactor constant expression evaluation of CXXConstructExpr to reduce ↵Richard Smith2016-05-121-35/+18
| | | | | | duplication between array and class initialization. llvm-svn: 269367
* Split interesting warnings off from -Wfloat-conversionRichard Trieu2016-04-211-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Restructure the implict floating point to integer conversions so that interesting sub-groups are under different flags. Breakdown of warnings: No warning: Exact conversions from floating point to integer: int x = 10.0; int x = 1e10; -Wliteral-conversion - Floating point literal to integer with rounding: int x = 5.5; int x = -3.4; -Wfloat-conversion - All conversions not covered by the above two: int x = GetFloat(); int x = 5.5 + 3.5; -Wfloat-zero-conversion - The expression converted has a non-zero floating point value that gets converted to a zero integer value, excluded the cases falling under -Wliteral-conversion. Subset of -Wfloat-conversion. int x = 1.0 / 2.0; -Wfloat-overflow-conversion - The floating point value is outside the range of the integer type, exluding cases from -Wliteral conversion. Subset of -Wfloat-conversion. char x = 500; char x = -1000; -Wfloat-bool-conversion - Any conversion of a floating point type to bool. Subset of -Wfloat-conversion. if (GetFloat()) {} bool x = 5.0; -Wfloat-bool-constant-conversion - Conversion of a compile time evaluatable floating point value to bool. Subset of -Wfloat-bool-conversion. bool x = 1.0; bool x = 4.0 / 20.0; Also add EvaluateAsFloat to Sema, which is similar to EvaluateAsInt, but for floating point values. llvm-svn: 267054
* [OpenCL] Move OpenCLImageTypes.def from clangAST to clangBasic library.Alexey Bader2016-04-131-1/+1
| | | | | | | | | | Putting OpenCLImageTypes.def to clangAST library violates layering requirement: "It's not OK for a Basic/ header to include an AST/ header". This fixes the modules build. Differential revision: http://reviews.llvm.org/D18954 Reviewers: Richard Smith, Vassil Vassilev. llvm-svn: 266180
* [OpenCL] Complete image types support.Alexey Bader2016-04-081-12/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I. Current implementation of images is not conformant to spec in the following points: 1. It makes no distinction with respect to access qualifiers and therefore allows to use images with different access type interchangeably. The following code would compile just fine: void write_image(write_only image2d_t img); kernel void foo(read_only image2d_t img) { write_image(img); } // Accepted code which is disallowed according to s6.13.14. 2. It discards access qualifier on generated code, which leads to generated code for the above example: call void @write_image(%opencl.image2d_t* %img); In OpenCL2.0 however we can have different calls into write_image with read_only and wite_only images. Also generally following compiler steps have no easy way to take different path depending on the image access: linking to the right implementation of image types, performing IR opts and backend codegen differently. 3. Image types are language keywords and can't be redeclared s6.1.9, which can happen currently as they are just typedef names. 4. Default access qualifier read_only is to be added if not provided explicitly. II. This patch corrects the above points as follows: 1. All images are encapsulated into a separate .def file that is inserted in different points where image handling is required. This avoid a lot of code repetition as all images are handled the same way in the code with no distinction of their exact type. 2. The Cartesian product of image types and image access qualifiers is added to the builtin types. This simplifies a lot handling of access type mismatch as no operations are allowed by default on distinct Builtin types. Also spec intended access qualifier as special type qualifier that are combined with an image type to form a distinct type (see statement above - images can't be created w/o access qualifiers). 3. Improves testing of images in Clang. Author: Anastasia Stulova Reviewers: bader, mgrang. Subscribers: pxli168, pekka.jaaskelainen, yaxunl. Differential Revision: http://reviews.llvm.org/D17821 llvm-svn: 265783
* Move local helper class into anonymous namespace.Richard Smith2016-04-041-0/+2
| | | | llvm-svn: 265364
* [Cxx1z-constexpr-lambda-P0170R1] Support parsing of constexpr specifier ↵Faisal Vali2016-03-261-1/+17
| | | | | | | | | | | | | | | | | | | | | | (and its inference) on lambda expressions Support the constexpr specifier on lambda expressions - and support its inference from the lambda call operator's body. i.e. auto L = [] () constexpr { return 5; }; static_assert(L() == 5); // OK auto Implicit = [] (auto a) { return a; }; static_assert(Implicit(5) == 5); We do not support evaluation of lambda's within constant expressions just yet. Implementation Strategy: - teach ParseLambdaExpressionAfterIntroducer to expect a constexpr specifier and mark the invented function call operator's declarator's decl-specifier with it; Have it emit fixits for multiple decl-specifiers (mutable or constexpr) in this location. - for cases where constexpr is not explicitly specified, have buildLambdaExpr check whether the invented function call operator satisfies the requirements of a constexpr function, by calling CheckConstexprFunctionDecl/Body. Much obliged to Richard Smith for his patience and his care, in ensuring the code is clang-worthy. llvm-svn: 264513
* P0184R0: Allow types of 'begin' and 'end' expressions in range-based for ↵Richard Smith2016-03-201-1/+4
| | | | | | loops to differ. llvm-svn: 263895
* Update for new argument to scalbnMatt Arsenault2016-03-131-4/+6
| | | | llvm-svn: 263371
* P0017R1: In C++1z, an aggregate class can have (public non-virtual) base ↵Richard Smith2016-03-081-3/+24
| | | | | | classes; these are initialized as if they were data members. llvm-svn: 262963
* [MSVC Compat] Don't evaluate member base expressions w/o side effectsDavid Majnemer2016-02-261-3/+12
| | | | | | | | | | | | A member expression's base doesn't always have an impact on what the member decl would evaluate to. In such a case, the base is used as a poor man's scope qualifier. This fixes PR26738. Differential Revision: http://reviews.llvm.org/D17619 llvm-svn: 261975
* PR26449: Fixes for bugs in __builtin_classify_type implementationAndrey Bokhanko2016-02-151-30/+126
| | | | | | | | | | | | | | | This patch fixes the following bugs in __builtin_classify_type implementation: 1) Support for member functions and fields 2) Same behavior as GCC in C mode (specifically, return integer_type_class for enums and pointer_type_class for function pointers and arrays). Behavior in C++ mode didn't changed. Also, it refactors the whole implementation, by replacing a sequence of if-else-if with a couple of switches. Differential Revision: http://reviews.llvm.org/D16846 llvm-svn: 260881
OpenPOWER on IntegriCloud