summaryrefslogtreecommitdiffstats
path: root/clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [analyzer] Escape symbols conjured into specific regions during a ↵Gabor Horvath2019-12-111-3/+3
| | | | | | | | | | conservative EvalCall This patch introduced additional PointerEscape callbacks after conservative calls for output parameters. This should not really affect the current checkers but the upcoming FuchsiaHandleChecker relies on this heavily. Differential Revision: https://reviews.llvm.org/D71224
* [analyzer] Fix analyzer warnings on analyzer.Artem Dergachev2019-08-281-2/+1
| | | | | | | | | Write tests for the actual crash that was found. Write comments and refactor code around 17 style bugs and suppress 3 false positives. Differential Revision: https://reviews.llvm.org/D66847 llvm-svn: 370246
* [C++2a] Add __builtin_bit_cast, used to implement std::bit_castErik Pilkington2019-07-021-0/+1
| | | | | | | | | | | | | | | | | | This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a bit_cast from a value v to a type T. This expression can be evaluated at compile time under specific circumstances. The compile time evaluation currently doesn't support bit-fields, but I'm planning on fixing this in a follow up (some of the logic for figuring this out is in CodeGen). I'm also planning follow-ups for supporting some more esoteric types that the constexpr evaluator supports, as well as extending __builtin_memcpy constexpr evaluation to use the same infrastructure. rdar://44987528 Differential revision: https://reviews.llvm.org/D62825 llvm-svn: 364954
* [analyzer] ExprEngine: Escape pointers in bitwise operationsCsaba Dabis2019-06-251-0/+4
| | | | | | | | | | | | | | | | | | Summary: After evaluation it would be an Unknown value and tracking would be lost. Reviewers: NoQ, xazax.hun, ravikandhadai, baloghadamsoftware, Szelethus Reviewed By: NoQ Subscribers: szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63720 llvm-svn: 364259
* PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of typeRichard Smith2019-06-141-1/+6
| | | | | | | | | | | nullptr_t does not access memory. We now reuse CK_NullToPointer to represent a conversion from a glvalue of type nullptr_t to a prvalue of nullptr_t where necessary. This reinstates r363337, reverted in r363352. llvm-svn: 363429
* Revert 363295, it caused PR42276. Also revert follow-ups 363337, 363340.Nico Weber2019-06-141-6/+1
| | | | | | | | Revert 363340 "Remove unused SK_LValueToRValue initialization step." Revert 363337 "PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of type" Revert 363295 "C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue conversion applied to a member access or similar not-quite-trivial lvalue expression." llvm-svn: 363352
* PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of typeRichard Smith2019-06-131-1/+6
| | | | | | | | | | | | nullptr_t does not access memory. We now reuse CK_NullToPointer to represent a conversion from a glvalue of type nullptr_t to a prvalue of nullptr_t where necessary. This reinstates r345562, reverted in r346065, now that CodeGen's handling of non-odr-used variables has been fixed. llvm-svn: 363337
* [analyzer] PR37501: Disable assertion for logical op short circuit evaluation.Artem Dergachev2019-03-291-2/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The transfer function for the CFG element that represents a logical operation computes the value of the operation and does nothing else. The element appears after all the short circuit decisions were made, so they don't need to be made again at this point. Because our expression evaluation is imprecise, it is often hard to discriminate between: (1) we don't know the value of the RHS because we failed to evaluate it and (2) we don't know the value of the RHS because it didn't need to be evaluated. This is hard because it depends on our knowledge about the value of the LHS (eg., if LHS is true, then RHS in (LHS || RHS) doesn't need to be computed) but LHS itself may have been evaluated imprecisely and we don't know whether it is true or not. Additionally, the Analyzer wouldn't necessarily even remember what the value of the LHS was because theoretically it's not really necessary to know it for any future evaluations. In order to work around these issues, the transfer function for logical operations consists in looking at the ExplodedGraph we've constructed so far in order to figure out from which CFG direction did we arrive here. Such post-factum backtracking that doesn't involve looking up LHS and RHS values is usually possible. However sometimes it fails because when we deduplicate exploded nodes with the same program point and the same program state we may end up in a situation when we reached the same program point from two or more different directions. By removing the assertion, we admit that the procedure indeed sometimes fails to work. When it fails, we also admit that we don't know the value of the logical operator. Differential Revision: https://reviews.llvm.org/D59857 llvm-svn: 357325
* [CFG] [analyzer] pr41142: C++17: Skip transparent InitListExprs in ExprEngine.Artem Dergachev2019-03-261-1/+1
| | | | | | | | | | | | | | | | | | | r356634 didn't fix all the problems caused by r356222 - even though simple constructors involving transparent init-list expressions are now evaluated precisely, many more complicated constructors aren't, for other reasons. The attached test case is an example of a constructor that will never be evaluated precisely - simply because there isn't a constructor there (instead, the program invokes run-time undefined behavior by returning without a return statement that should have constructed the return value). Fix another part of the problem for such situations: evaluate transparent init-list expressions transparently, so that to avoid creating ill-formed "transparent" nonloc::CompoundVals. Differential Revision: https://reviews.llvm.org/D59622 llvm-svn: 356969
* [Fixed Point Arithmetic] Fixed Point and Integer ConversionsLeonard Chan2019-03-061-1/+3
| | | | | | | | | This patch includes the necessary code for converting between a fixed point type and integer. This also includes constant expression evaluation for conversions with these types. Differential Revision: https://reviews.llvm.org/D56900 llvm-svn: 355462
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [analyzer] Pass the correct loc Expr from VisitIncDecOp to evalStoreRafael Stahl2019-01-071-2/+2
| | | | | | | | | | | | | | Summary: The LocationE parameter of evalStore is documented as "The location expression that is stored to". When storing from an increment / decrement operator this was not satisfied. In user code this causes an inconsistency between the SVal and Stmt parameters of checkLocation. Reviewers: NoQ, dcoughlin, george.karpenkov Reviewed By: NoQ Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D55701 llvm-svn: 350528
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-301-2/+3
| | | | | | | | | It seems the two failing tests can be simply fixed after r348037 Fix 3 cases in Analysis/builtin-functions.cpp Delete the bad CodeGen/builtin-constant-p.c for now llvm-svn: 348053
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Fangrui Song2018-11-301-3/+2
| | | | | | | | | | Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp while we are investigating why the following snippet fails: extern char extern_var; struct { int a; } a = {__builtin_constant_p(extern_var)}; llvm-svn: 348039
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-281-2/+3
| | | | | | | This was reverted in r347656 due to me thinking it caused a miscompile of Chromium. Turns out it was the Chromium code that was broken. llvm-svn: 347756
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-271-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused a miscompile in Chrome (see crbug.com/908372) that's illustrated by this small reduction: static bool f(int *a, int *b) { return !__builtin_constant_p(b - a) || (!(b - a)); } int arr[] = {1,2,3}; bool g() { return f(arr, arr + 3); } $ clang -O2 -S -emit-llvm a.cc -o - g() should return true, but after r347417 it became false for some reason. This also reverts the follow-up commits. r347417: > Re-Reinstate 347294 with a fix for the failures. > > Don't try to emit a scalar expression for a non-scalar argument to > __builtin_constant_p(). > > Third time's a charm! r347446: > The result of is.constant() is unsigned. r347480: > A __builtin_constant_p() returns 0 with a function type. r347512: > isEvaluatable() implies a constant context. > > Assume that we're in a constant context if we're asking if the expression can > be compiled into a constant initializer. This fixes the issue where a > __builtin_constant_p() in a compound literal was diagnosed as not being > constant, even though it's always possible to convert the builtin into a > constant. r347531: > A "constexpr" is evaluated in a constant context. Make sure this is reflected > if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347656
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-211-2/+3
| | | | | | | | | Don't try to emit a scalar expression for a non-scalar argument to __builtin_constant_p(). Third time's a charm! llvm-svn: 347417
* Revert r347364 again, the fix was incomplete.Nico Weber2018-11-211-3/+2
| | | | llvm-svn: 347389
* Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-201-2/+3
| | | | | | | EvaluateAsInt() is sometimes called in a constant context. When that's the case, we need to specify it as so. llvm-svn: 347364
* Revert r345562: "PR23833, DR2140: an lvalue-to-rvalue conversion on a ↵Richard Smith2018-11-031-6/+1
| | | | | | | | | | | | glvalue of type" This exposes a (known) CodeGen bug: it can't cope with emitting lvalue expressions that denote non-odr-used but usable-in-constant-expression variables. See PR39528 for a testcase. Reverted for now until that issue can be fixed. llvm-svn: 346065
* Fix clang -Wimplicit-fallthrough warnings across llvm, NFCReid Kleckner2018-11-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch should not introduce any behavior changes. It consists of mostly one of two changes: 1. Replacing fall through comments with the LLVM_FALLTHROUGH macro 2. Inserting 'break' before falling through into a case block consisting of only 'break'. We were already using this warning with GCC, but its warning behaves slightly differently. In this patch, the following differences are relevant: 1. GCC recognizes comments that say "fall through" as annotations, clang doesn't 2. GCC doesn't warn on "case N: foo(); default: break;", clang does 3. GCC doesn't warn when the case contains a switch, but falls through the outer case. I will enable the warning separately in a follow-up patch so that it can be cleanly reverted if necessary. Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu Differential Revision: https://reviews.llvm.org/D53950 llvm-svn: 345882
* PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of typeRichard Smith2018-10-301-1/+6
| | | | | | | | | nullptr_t does not access memory. We now reuse CK_NullToPointer to represent a conversion from a glvalue of type nullptr_t to a prvalue of nullptr_t where necessary. llvm-svn: 345562
* [Fixed Point Arithmetic] Fixed Point to Boolean CastLeonard Chan2018-10-231-1/+2
| | | | | | | | | | This patch is a part of https://reviews.llvm.org/D48456 in an attempt to split the casting logic up into smaller patches. This contains the code for casting from fixed point types to boolean types. Differential Revision: https://reviews.llvm.org/D53308 llvm-svn: 345063
* [OpenCL][NFC] Unify ZeroToOCL* cast typesAndrew Savonichev2018-10-231-2/+1
| | | | | | | | | | | | Reviewers: Anastasia, yaxunl Reviewed By: Anastasia Subscribers: asavonic, cfe-commits Differential Revision: https://reviews.llvm.org/D52654 llvm-svn: 345038
* [Fixed Point Arithmetic] FixedPointCastLeonard Chan2018-10-151-1/+2
| | | | | | | | | | | | | This patch is a part of https://reviews.llvm.org/D48456 in an attempt to split them up. This contains the code for casting between fixed point types and other fixed point types. The method for converting between fixed point types is based off the convert() method in APFixedPoint. Differential Revision: https://reviews.llvm.org/D50616 llvm-svn: 344530
* Remove trailing spaceFangrui Song2018-07-301-1/+1
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [analyzer] pr37270: Track constructor target region, even if just a variable.Artem Dergachev2018-06-141-14/+2
| | | | | | | | | | | | | | | | | | | | | | The very idea of construction context implies that first the object is constructed, and then later, in a separate moment of time, the constructed object goes into scope, i.e. becomes "live". Most construction contexts require path-sensitive tracking of the constructed object region in order to compute the outer expressions accordingly before the object becomes live. Semantics of simple variable construction contexts don't immediately require that such tracking happens in path-sensitive manner, but shortcomings of the analyzer force us to track it path-sensitively as well. Namely, whether construction context was available at all during construction is a path-sensitive information. Additionally, path-sensitive tracking takes care of our liveness problems that kick in as the temporal gap between construction and going-into-scope becomes larger (eg., due to copy elision). Differential Revision: https://reviews.llvm.org/D47305 llvm-svn: 334681
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-1/+1
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* [analyzer] pr37209: Fix casts of glvalues to references.Artem Dergachev2018-05-041-0/+7
| | | | | | | | | | | | | | | Many glvalue expressions aren't of their respective reference type - they are simply glvalues of their value type. This was causing problems when we were trying to obtain type of the original expression while evaluating certain glvalue bit-casts. Fixed by artificially forging a reference type to provide to the casting procedure. Differential Revision: https://reviews.llvm.org/D46224 llvm-svn: 331558
* [analyzer] When we fail to evaluate a pointer cast, escape the pointer.Artem Dergachev2018-04-191-2/+5
| | | | | | | | | | | | | | If a pointer cast fails (evaluates to an UnknownVal, i.e. not implemented in the analyzer) and such cast is in fact the last use of the pointer, the pointer symbol is no longer referenced by the program state and a leak is (mis-)diagnosed. "Escape" the pointer upon a failed cast, i.e. inform the checker that we can no longer reliably track it. Differential Revision: https://reviews.llvm.org/D45698 llvm-svn: 330380
* [Analyzer] More accurate modeling about the increment operator of the ↵Henry Wong2018-03-061-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | operand with type bool. Summary: There is a problem with analyzer that a wrong value is given when modeling the increment operator of the operand with type bool. After `rL307604` is applied, a unsigned overflow may occur. Example: ``` void func() { bool b = true; // unsigned overflow occur, 2 -> 0 U1b b++; } ``` The use of an operand of type bool with the ++ operators is deprecated but valid untill C++17. And if the operand of the increment operator is of type bool, it is set to true. This patch includes two parts: - If the operand of the increment operator is of type bool or type _Bool, set to true. - Modify `BasicValueFactory::getTruthValue()`, use `getIntWidth()` instead `getTypeSize()` and use `unsigned` instead `signed`. Reviewers: alexshap, NoQ, dcoughlin, george.karpenkov Reviewed By: NoQ Subscribers: xazax.hun, szepet, a.sidorin, cfe-commits, MTC Differential Revision: https://reviews.llvm.org/D43741 llvm-svn: 326776
* [analyzer] Relax the assert used when traversing the node graph.George Karpenkov2018-02-231-1/+5
| | | | | | | | | | | | | | The assertion gets exposed when changing the exploration order. This is a quick hacky fix, but the intention is that if the nodes do merge, it should not matter which predecessor should be traverse. A proper fix would be not to traverse predecessors at all, as all information relevant for any decision should be avilable locally. rdar://37540480 Differential Revision: https://reviews.llvm.org/D42773 llvm-svn: 325977
* [analyzer] Fix false negative on post-increment of uninitialized variable.Roman Lebedev2017-11-301-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently clang static analyzer does warn on: ``` int x; x+=1; x-=1; x=x+1; x=x-1; ``` But does warn on: ``` int x; x++; x--; --x; ++x; ``` This differential should fix that. Fixes https://bugs.llvm.org/show_bug.cgi?id=35419 Reviewers: dcoughlin, NoQ Reviewed By: dcoughlin Subscribers: NoQ, xazax.hun, szepet, cfe-commits, a.sidorin Tags: #clang Differential Revision: https://reviews.llvm.org/D40463 llvm-svn: 319411
* [analyzer] pr34766: Fix a crash on explicit std::initializer_list constructor.Artem Dergachev2017-11-271-1/+1
| | | | | | | | | | | | | | | | We didn't support the following syntax: (std::initializer_list<int>){12} which suddenly produces CompoundLiteralExpr that contains CXXStdInitializerListExpr. Lift the assertion and instead pass the value through CompoundLiteralExpr transparently, as it doesn't add much. Differential Revision: https://reviews.llvm.org/D39803 llvm-svn: 319058
* [analyzer] [NFC] Minor ExprEngineC refactoringGeorge Karpenkov2017-11-091-15/+22
| | | | | | | | Move a repeated block of code into a function. Differential Revision: https://reviews.llvm.org/D39584 llvm-svn: 317849
* [analyzer] Fix a crash on logical operators with vectors.Artem Dergachev2017-11-081-0/+10
| | | | | | | | | | | | | | | | | Do not crash when trying to compute x && y or x || y where x and y are of a vector type. For now we do not seem to properly model operations with vectors. In particular, operations && and || on a pair of vectors are not short-circuit, unlike regular logical operators, so even our CFG is incorrect. Avoid the crash, add respective FIXME tests for later. Differential Revision: https://reviews.llvm.org/D39682 rdar://problem/34317663 llvm-svn: 317700
* [analyzer] [NFC] very minor ExprEngineC refactoringGeorge Karpenkov2017-11-031-4/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D39577 llvm-svn: 317294
* [analyzer] Fix logical not for pointers with different bit widthDaniel Marjamaki2017-06-191-3/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D31029 llvm-svn: 305669
* [analyzer] Fix symbolication for unknown unary increment/decrement results.Artem Dergachev2017-03-281-1/+1
| | | | | | | | | | | | | | | If the value is known, but we cannot increment it, conjure a symbol to represent the result of the operation based on the operator expression, not on the sub-expression. In particular, no longer crash on comparing a result of a LocAsInteger increment to a constant integer. rdar://problem/31067356 Differential Revision: https://reviews.llvm.org/D31289 llvm-svn: 298927
* [analyzer] Add LocationContext as a parameter to checkRegionChangesAnna Zaks2017-01-131-3/+4
| | | | | | | | | | | This patch adds LocationContext to checkRegionChanges and removes wantsRegionChangeUpdate as it was unused. A patch by Krzysztof Wiśniewski! Differential Revision: https://reviews.llvm.org/D27090 llvm-svn: 291869
* Fix for PR15623 (corrected r290413 reverted at 290415). The patch eliminates ↵Anton Yartsev2016-12-251-17/+7
| | | | | | | | | unwanted ProgramState checker data propagation from an operand of the logical operation to operation result. The patch also simplifies an assume of a constraint of the form: "(exp comparison_op expr) != 0" to true into an assume of "exp comparison_op expr" to true. (And similarly, an assume of the form "(exp comparison_op expr) == 0" to true as an assume of exp comparison_op expr to false.) which improves precision overall. https://reviews.llvm.org/D22862 llvm-svn: 290505
* Fix problems in "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare ↵Egor Churaev2016-12-231-0/+1
| | | | | | | | | | | | | | 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
* Revert changes made by r290413 until regression is fixed.Anton Yartsev2016-12-231-7/+17
| | | | llvm-svn: 290415
* Fix for PR15623. The patch eliminates unwanted ProgramState checker data ↵Anton Yartsev2016-12-231-17/+7
| | | | | | | | | propagation from an operand of the logical operation to operation result. The patch also simplifies an assume of a constraint of the form: "(exp comparison_op expr) != 0" to true into an assume of "exp comparison_op expr" to true. (And similarly, an assume of the form "(exp comparison_op expr) == 0" to true as an assume of exp comparison_op expr to false.) which improves precision overall. https://reviews.llvm.org/D22862 llvm-svn: 290413
* [analyzer] Add a new SVal to support pointer-to-member operations.Devin Coughlin2016-12-151-42/+119
| | | | | | | | | | | Add a new type of NonLoc SVal for C++ pointer-to-member operations. This SVal supports both pointers to member functions and pointers to member data. A patch by Kirill Romanenkov! Differential Revision: https://reviews.llvm.org/D25475 llvm-svn: 289873
* DR1213: element access on an array xvalue or prvalue produces an xvalue. In theRichard Smith2016-12-051-9/+1
| | | | | | | | | | | | | | 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
* [analyzer] Model base to derived casts more precisely.Gabor Horvath2016-08-081-2/+23
| | | | | | | | | | | | | | Dynamic casts are handled relatively well by the static analyzer. BaseToDerived casts however are treated conservatively. This can cause some false positives with the NewDeleteLeaks checker. This patch alters the behavior of BaseToDerived casts. In case a dynamic cast would succeed use the same semantics. Otherwise fall back to the conservative approach. Differential Revision: https://reviews.llvm.org/D23014 llvm-svn: 277989
* [OpenCL] Generate opaque type for sampler_t and function call for the ↵Yaxun Liu2016-07-281-0/+1
| | | | | | | | | | | | | | | | 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
* [Bugfix] Fix ICE on constexpr vector splat.George Burgess IV2016-01-131-0/+4
| | | | | | | | | | | | | 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
* [analyzer] Evaluate integral casts as cast symbols if truncations are detected.Pierre Gousseau2016-01-121-1/+8
| | | | | | | | | | | | | The current workaround for truncations not being modelled is that the evaluation of integer to integer casts are simply bypassed and so the original symbol is used as the new casted symbol (cf SimpleSValBuilder::evalCastFromNonLoc). This lead to the issue described in PR25078, as the RangeConstraintManager associates ranges with symbols. The new evalIntegralCast method added by this patch wont bypass the cast if it finds the range of the symbol to be greater than the maximum value of the target type. The fix to RangeSet::pin mentioned in the initial review will be committed separately. Differential Revision: http://reviews.llvm.org/D12901 llvm-svn: 257464
OpenPOWER on IntegriCloud