summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/ExprConstant.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* Don't crash when passing &@selector to a _Nonnull parameter. Fixes PR24774.Nico Weber2015-09-151-2/+3
| | | | | | | | | The root cause here is that ObjCSelectorExpr is an rvalue, yet it can have its address taken. That's kind of awkward, but fixing this is awkward in other ways, see https://llvm.org/bugs/show_bug.cgi?id=24774#c16 . For now, just fix the crash. llvm-svn: 247740
* Fix a bug in __builtin_object_size cast removalGeorge Burgess IV2015-09-041-3/+10
| | | | | | | | | | | Apparently there are many cast kinds that may cause implicit pointer arithmetic to happen. In light of this, the cast ignoring logic introduced in r246877 has been changed to only ignore a small set of cast kinds, and a test for this behavior has been added. Thanks to Richard for catching this before it became a bug report. :) llvm-svn: 246890
* Increase accuracy of __builtin_object_size.George Burgess IV2015-09-041-35/+96
| | | | | | | | | | | | | | | | | | | Improvements: - For all types, we would give up in a case such as: __builtin_object_size((char*)&foo, N); even if we could provide an answer to __builtin_object_size(&foo, N); We now provide the same answer for both of the above examples in all cases. - For type=1|3, we now support subobjects with unknown bases, as long as the designator is valid. Thanks to Richard Smith for the review + design planning. Review: http://reviews.llvm.org/D12169 llvm-svn: 246877
* [AST] Don't crash when comparing incomplete objectDavid Majnemer2015-08-291-1/+7
| | | | | | | | | | We cannot tell if an object is past-the-end if its type is incomplete. Zero sized objects satisfy past-the-end criteria and our object might turn out to be such an object. This fixes PR24622. llvm-svn: 246359
* PR24597: Fix in-place evaluation of call expressions to provide a proper "this"Richard Smith2015-08-281-17/+51
| | | | | | pointer to an RVO construction of a returned object. llvm-svn: 246263
* [OPENMP 4.0] Initial support for array sections.Alexey Bataev2015-08-251-0/+1
| | | | | | | | Adds parsing/sema analysis/serialization/deserialization for array sections in OpenMP constructs (introduced in OpenMP 4.0). Currently it is allowed to use array sections only in OpenMP clauses that accepts list of expressions. Differential Revision: http://reviews.llvm.org/D10732 llvm-svn: 245937
* Make __builtin_object_size always answer correctlyGeorge Burgess IV2015-08-191-43/+88
| | | | | | | | | | | | | | | | | | __builtin_object_size would return incorrect answers for many uses where type=3. This fixes the inaccuracy by making us emit 0 instead of LLVM's objectsize intrinsic. Additionally, there are many cases where we would emit suboptimal (but correct) answers, such as when arrays are involved. This patch fixes some of these cases (please see new tests in test/CodeGen/object-size.c for specifics on which cases are improved) Resubmit of r245323 with PR24493 fixed. Patch mostly by Richard Smith. Differential Revision: http://reviews.llvm.org/D12000 This fixes PR15212. llvm-svn: 245403
* Revert r245323, it caused PR24493.Nico Weber2015-08-181-82/+44
| | | | llvm-svn: 245342
* Make __builtin_object_size always answer correctlyGeorge Burgess IV2015-08-181-44/+82
| | | | | | | | | | | | | | | | | __builtin_object_size would return incorrect answers for many uses where type=3. This fixes the inaccuracy by making us emit 0 instead of LLVM's objectsize intrinsic. Additionally, there are many cases where we would emit suboptimal (but correct) answers, such as when arrays are involved. This patch fixes some of these cases (please see new tests in test/CodeGen/object-size.c for specifics on which cases are improved) Patch mostly by Richard Smith. Differential Revision: http://reviews.llvm.org/D12000 This fixes PR15212. llvm-svn: 245323
* -Wdeprecated: Job objects are stored in a vector yet are not really ↵David Blaikie2015-08-121-2/+8
| | | | | | copyable, make them movable instead llvm-svn: 244829
* [OPENMP] Introduced type trait "__builtin_omp_required_simd_align" for ↵Alexey Bataev2015-07-021-0/+7
| | | | | | | | | default simd alignment. Adds type trait "__builtin_omp_required_simd_align" after discussions here http://reviews.llvm.org/D9894 Differential Revision: http://reviews.llvm.org/D10597 llvm-svn: 241237
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-8/+8
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-8/+8
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* Implementing C99 partial re-initialization behavior (DR-253)Yunzhong Gao2015-06-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Based on previous discussion on the mailing list, clang currently lacks support for C99 partial re-initialization behavior: Reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029188.html Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_253.htm This patch attempts to fix this problem. Given the following code snippet, struct P1 { char x[6]; }; struct LP1 { struct P1 p1; }; struct LP1 l = { .p1 = { "foo" }, .p1.x[2] = 'x' }; // this example is adapted from the example for "struct fred x[]" in DR-253; // currently clang produces in l: { "\0\0x" }, // whereas gcc 4.8 produces { "fox" }; // with this fix, clang will also produce: { "fox" }; Differential Review: http://reviews.llvm.org/D5789 llvm-svn: 239446
* Fix PR21945: Crash in constant evaluator.Jonathan Roelofs2015-06-011-0/+5
| | | | | | Patch by Косов Евгений! llvm-svn: 238758
* PR23373: A defaulted union copy constructor that is not trivial must still beRichard Smith2015-04-291-6/+5
| | | | | | emitted as a memcpy. llvm-svn: 236142
* Make helper functions static. NFC.Benjamin Kramer2015-03-091-3/+4
| | | | | | Found by -Wmissing-prototypes. llvm-svn: 231668
OpenPOWER on IntegriCloud