summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/ExprConstant.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Fix ICE with constexpr and friend functionsOlivier Goffart2016-02-121-7/+9
| | | | | | | | | | | | | Fix a crash while parsing this code: struct X { friend constexpr int foo(X*) { return 12; } static constexpr int j = foo(static_cast<X*>(nullptr)); }; Differential Revision: http://reviews.llvm.org/D16973 llvm-svn: 260675
* Update for LLVM function name change.Rui Ueyama2016-01-141-1/+1
| | | | llvm-svn: 257802
* [Bugfix] Fix ICE on constexpr vector splat.George Burgess IV2016-01-131-1/+6
| | | | | | | | | | | | | In {CG,}ExprConstant.cpp, we weren't treating vector splats properly. This patch makes us treat splats more properly. Additionally, this patch adds a new cast kind which allows a bool->int cast to result in -1 or 0, instead of 1 or 0 (for true and false, respectively), so we can sanely model OpenCL bool->int casts in the AST. Differential Revision: http://reviews.llvm.org/D14877 llvm-svn: 257559
* [TrailingObjects] Convert OffsetOfExpr.James Y Knight2015-12-291-5/+5
| | | | | | That necessitated moving the OffsetOfNode class out of OffsetOfExpr. llvm-svn: 256590
* Clean ExprConstant/CGExprConstant up a bit. NFC.George Burgess IV2015-12-111-9/+9
| | | | llvm-svn: 255314
* Explicitly permit undefined behavior in constant initializers for globalRichard Smith2015-12-081-6/+38
| | | | | | | | variables in C, in the cases where we can constant-fold it to a value regardless (such as floating-point division by zero and signed integer overflow). Strictly enforcing this rule breaks too much code. llvm-svn: 254992
* Don't assert if evaluation of an expression that we're syntactically requiredRichard Smith2015-12-041-1/+5
| | | | | | | to treat as an ICE results in undefined behavior. Instead, return the "natural" result of the operation (signed wraparound / inf / nan). llvm-svn: 254699
* PR17381: Treat undefined behavior during expression evaluation as an unmodeledRichard Smith2015-12-031-51/+64
| | | | | | | | | | | | | | | | | | | | | side-effect, so that we don't allow speculative evaluation of such expressions during code generation. This caused a diagnostic quality regression, so fix constant expression diagnostics to prefer either the first "can't be constant folded" diagnostic or the first "not a constant expression" diagnostic depending on the kind of evaluation we're doing. This was always the intent, but didn't quite work correctly before. This results in certain initializers that used to be constant initializers to no longer be; in particular, things like: float f = 1e100; are no longer accepted in C. This seems appropriate, as such constructs would lead to code being executed if sanitizers are enabled. llvm-svn: 254574
* Add the `pass_object_size` attribute to clang.George Burgess IV2015-12-021-12/+56
| | | | | | | | | | | | | `pass_object_size` is our way of enabling `__builtin_object_size` to produce high quality results without requiring inlining to happen everywhere. A link to the design doc for this attribute is available at the Differential review link below. Differential Revision: http://reviews.llvm.org/D13263 llvm-svn: 254554
* [MSVC] 'property' with an empty array in array subscript expression.Alexey Bataev2015-11-251-0/+1
| | | | | | | | | | | | MSVC supports 'property' attribute and allows to apply it to the declaration of an empty array in a class or structure definition. For example: ``` __declspec(property(get=GetX, put=PutX)) int x[]; ``` The above statement indicates that x[] can be used with one or more array indices. In this case, i=p->x[a][b] will be turned into i=p->GetX(a, b), and p->x[a][b] = i will be turned into p->PutX(a, b, i); Differential Revision: http://reviews.llvm.org/D13336 llvm-svn: 254067
* Move global classes into anonymous namespaces. NFC.Benjamin Kramer2015-10-281-0/+2
| | | | llvm-svn: 251528
* [coroutines] Creation of promise object, lookup of operator co_await, buildingRichard Smith2015-10-271-0/+3
| | | | | | of await_* calls, and AST representation for same. llvm-svn: 251387
* Make __builtin_object_size more conservativeGeorge Burgess IV2015-10-161-22/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | r246877 made __builtin_object_size substantially more aggressive with unknown bases if Type=1 or Type=3, which causes issues when we encounter code like this: struct Foo { int a; char str[1]; }; const char str[] = "Hello, World!"; struct Foo *f = (struct Foo *)malloc(sizeof(*f) + strlen(str)); strcpy(&f->str, str); __builtin_object_size(&f->str, 1) would hand back 1, which is technically correct given the type of Foo, but the type of Foo lies to us about how many bytes are available in this case. This patch adds support for this "writing off the end" idiom -- we now answer conservatively when we're given the address of the very last member in a struct. Differential Revision: http://reviews.llvm.org/D12169 llvm-svn: 250488
* Pass ArrayRef by value. NFC.Craig Topper2015-09-291-1/+1
| | | | llvm-svn: 248773
OpenPOWER on IntegriCloud