summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/ExprConstant.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [8.0 Regression] Fix handling of `__builtin_constant_p` inside template ↵Eric Fiselier2019-03-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | arguments, enumerators, case statements, and the enable_if attribute. Summary: The following code is accepted by Clang 7 and prior but rejected by the upcoming 8 release and in trunk [1] ``` // error {{never produces a constant expression}} void foo(const char* s) __attribute__((enable_if(__builtin_constant_p(*s) == false, "trap"))) {} void test() { foo("abc"); } ``` Prior to Clang 8, the call to `__builtin_constant_p` was a constant expression returning false. Currently, it's not a valid constant expression. The bug is caused because we failed to set `InConstantContext` when attempting to evaluate unevaluated constant expressions. [1] https://godbolt.org/z/ksAjmq Reviewers: rsmith, hans, sbenza Reviewed By: rsmith Subscribers: kristina, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59038 llvm-svn: 355743
* [ObjC] Emit a boxed expression as a compile-time constant if theAkira Hatanaka2019-03-081-0/+4
| | | | | | | | | | | | | | | | | | expression inside the parentheses is a valid UTF-8 string literal. Previously clang emitted an expression like @("abc") as a message send to stringWithUTF8String. This commit makes clang emit the boxed expression as a compile-time constant instead. This commit also has the effect of silencing the nullable-to-nonnull conversion warning clang started emitting after r317727, which originally motivated this commit (see https://oleb.net/2018/@keypath). rdar://problem/42684601 Differential Revision: https://reviews.llvm.org/D58729 llvm-svn: 355662
* Inline asm constraints: allow ICE-like pointers for the "n" constraint (PR40890)Hans Wennborg2019-03-061-6/+5
| | | | | | | | | | | | Apparently GCC allows this, and there's code relying on it (see bug). The idea is to allow expression that would have been allowed if they were cast to int. So I based the code on how such a cast would be done (the CK_PointerToIntegral case in IntExprEvaluator::VisitCastExpr()). Differential Revision: https://reviews.llvm.org/D58821 llvm-svn: 355491
* [Fixed Point Arithmetic] Fixed Point and Integer ConversionsLeonard Chan2019-03-061-0/+30
| | | | | | | | | 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
* [Fixed Point Arithmetic] Fixed Point ComparisonsLeonard Chan2019-02-211-0/+16
| | | | | | | | | This patch implements fixed point comparisons with other fixed point types and integers. This also provides constant expression evaluation for them. Differential Revision: https://reviews.llvm.org/D57219 llvm-svn: 354621
* [Builtins] Treat `bcmp` as a builtin.Clement Courbet2019-02-141-5/+11
| | | | | | | | | | | | | | | | | Summary: This makes it consistent with `memcmp` and `__builtin_bcmp`. Also see the discussion in https://reviews.llvm.org/D56593. Reviewers: jyknight Subscribers: kristina, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58120 llvm-svn: 354023
* Fix buildbot failure from r353569.Eli Friedman2019-02-091-1/+8
| | | | | | | I assumed lvalue-to-rvalue conversions of array type would never happen, but apparently clang-tidy tries in some cases. llvm-svn: 353598
* [Sema] Make string literal init an rvalue.Eli Friedman2019-02-081-44/+25
| | | | | | | | | | | | | | | | | | | | | | | This allows substantially simplifying the expression evaluation code, because we don't have to special-case lvalues which are actually string literal initialization. This currently throws away an optimization where we would avoid creating an array APValue for string literal initialization. If we really want to optimize this case, we should fix APValue so it can store simple arrays more efficiently, like llvm::ConstantDataArray. This shouldn't affect the memory usage for other string literals. (Not sure if this is a blocker; I don't think string literal init is common enough for this to be a serious issue, but I could be wrong.) The change to test/CodeGenObjC/encode-test.m is a weird side-effect of these changes: we currently don't constant-evaluate arrays in C, so the strlen call shouldn't be folded, but lvalue string init managed to get around that check. I this this is fine. Fixes https://bugs.llvm.org/show_bug.cgi?id=40430 . llvm-svn: 353569
* Add a new builtin: __builtin_dynamic_object_sizeErik Pilkington2019-01-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This builtin has the same UI as __builtin_object_size, but has the potential to be evaluated dynamically. It is meant to be used as a drop-in replacement for libraries that use __builtin_object_size when a dynamic checking mode is enabled. For instance, __builtin_object_size fails to provide any extra checking in the following function: void f(size_t alloc) { char* p = malloc(alloc); strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", __builtin_object_size(p, 0)) } This is an overflow if alloc < 7, but because LLVM can't fold the object size intrinsic statically, it folds __builtin_object_size to -1. With __builtin_dynamic_object_size, alloc is passed through to __builtin___strcpy_chk. rdar://32212419 Differential revision: https://reviews.llvm.org/D56760 llvm-svn: 352665
* 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
* [Fixed Point Arithmetic] Fixed Point Addition Constant Expression EvaluationLeonard Chan2019-01-181-49/+148
| | | | | | | | This patch includes logic for constant expression evaluation of fixed point additions. Differential Revision: https://reviews.llvm.org/D55868 llvm-svn: 351593
* [Fixed Point Arithmetic] Add APFixedPoint to APValueLeonard Chan2019-01-161-0/+3
| | | | | | | | This adds APFixedPoint to the union of values that can be represented with an APValue. Differential Revision: https://reviews.llvm.org/D56746 llvm-svn: 351368
* [AST] Remove ASTContext from getThisType (NFC)Brian Gesiak2019-01-111-1/+1
| | | | | | | | | | | | | | | | | | | | | Summary: https://reviews.llvm.org/D54862 removed the usages of `ASTContext&` from within the `CXXMethodDecl::getThisType` method. Remove the parameter altogether, as well as all usages of it. This does not result in any functional change because the parameter was unused since https://reviews.llvm.org/D54862. Test Plan: check-clang Reviewers: akyrtzi, mikael Reviewed By: mikael Subscribers: mehdi_amini, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D56509 llvm-svn: 350914
* [ExprConstant] Handle compound assignment when LHS has integral type and RHS ↵Tan S. B.2018-12-181-7/+19
| | | | | | | | | | has floating point type Fixes PR39858 Differential Revision: https://reviews.llvm.org/D55413 llvm-svn: 349444
* [Clang] Add __builtin_launderEric Fiselier2018-12-141-1/+2
| | | | | | | | | | | | | | | | | Summary: This patch adds `__builtin_launder`, which is required to implement `std::launder`. Additionally GCC provides `__builtin_launder`, so thing brings Clang in-line with GCC. I'm not exactly sure what magic `__builtin_launder` requires, but based on previous discussions this patch applies a `@llvm.invariant.group.barrier`. As noted in previous discussions, this may not be enough to correctly handle vtables. Reviewers: rnk, majnemer, rsmith Reviewed By: rsmith Subscribers: kristina, Romain-Geissler-1A, erichkeane, amharc, jroelofs, cfe-commits, Prazek Differential Revision: https://reviews.llvm.org/D40218 llvm-svn: 349195
* [ExprConstant] Improve memchr/memcmp for type mismatch and multibyte element ↵Hubert Tong2018-12-121-22/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | types Summary: `memchr` and `memcmp` operate upon the character units of the object representation; that is, the `size_t` parameter expresses the number of character units. The constant folding implementation is updated in this patch to account for multibyte element types in the arrays passed to `memchr`/`memcmp` and, in the case of `memcmp`, to account for the possibility that the arrays may have differing element types (even when they are byte-sized). Actual inspection of the object representation is not implemented. Comparisons are done only between elements with the same object size; that is, `memchr` will fail when inspecting at least one character unit of a multibyte element. The integer types are assumed to have two's complement representation with 0 for `false`, 1 for `true`, and no padding bits. `memcmp` on multibyte elements will only be able to fold in cases where enough elements are equal for the answer to be 0. Various tests are added to guard against incorrect folding for cases that miscompile on some system or other prior to this patch. At the same time, the unsigned 32-bit `wchar_t` testing in `test/SemaCXX/constexpr-string.cpp` is restored. Reviewers: rsmith, aaron.ballman, hfinkel Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55510 llvm-svn: 348938
* [constexpr][c++2a] Try-catch blocks in constexpr functionsBruno Cardoso Lopes2018-12-101-0/+3
| | | | | | | | | | | | | | | | | | | | | | Implement support for try-catch blocks in constexpr functions, as proposed in http://wg21.link/P1002 and voted in San Diego for c++20. The idea is that we can still never throw inside constexpr, so the catch block is never entered. A try-catch block like this: try { f(); } catch (...) { } is then morally equivalent to just { f(); } Same idea should apply for function/constructor try blocks. rdar://problem/45530773 Differential Revision: https://reviews.llvm.org/D55097 llvm-svn: 348789
* Misc typos fixes in ./lib folderRaphael Isemann2018-12-101-3/+3
| | | | | | | | | | | | | | Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned` Reviewers: teemperor Reviewed By: teemperor Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D55475 llvm-svn: 348755
* Specify constant context in constant emitterBill Wendling2018-12-011-0/+1
| | | | | | | The constant emitter may need to evaluate the expression in a constant context. For exasmple, global initializer lists. llvm-svn: 348070
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-301-45/+102
| | | | | | | | | 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-102/+45
| | | | | | | | | | 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
* [ExprConstant] Try fixing __builtin_constant_p after D54355 (rC347417)Fangrui Song2018-11-301-1/+0
| | | | | | | | | | | Summary: Reinstate the original behavior (Success(false, E)) before D54355 when this branch is taken. This fixes spurious error of the following snippet: extern char extern_var; struct { int a; } a = {__builtin_constant_p(extern_var)}; llvm-svn: 348037
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-281-45/+103
| | | | | | | 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-103/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* A "constexpr" is evaluated in a constant context. Make sure this is reflectedBill Wendling2018-11-261-0/+2
| | | | | | if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347531
* isEvaluatable() implies a constant context.Bill Wendling2018-11-241-2/+4
| | | | | | | | | | 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. llvm-svn: 347512
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-211-43/+97
| | | | | | | | | 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-97/+43
| | | | llvm-svn: 347389
* Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-201-43/+97
| | | | | | | EvaluateAsInt() is sometimes called in a constant context. When that's the case, we need to specify it as so. llvm-svn: 347364
* Revert 347294, it turned many bots on lab.llvm.org:8011/console red.Nico Weber2018-11-201-61/+24
| | | | llvm-svn: 347314
* Use is.constant intrinsic for __builtin_constant_pBill Wendling2018-11-201-24/+61
| | | | | | | | | | | | | | | | Summary: A __builtin_constant_p may end up with a constant after inlining. Use the is.constant intrinsic if it's a variable that's in a context where it may resolve to a constant, e.g., an argument to a function after inlining. Reviewers: rsmith, shafik Subscribers: jfb, kristina, cfe-commits, nickdesaulniers, jyknight Differential Revision: https://reviews.llvm.org/D54355 llvm-svn: 347294
* PR39628 Treat all non-zero values as 'true' in bool compound-assignmentRichard Smith2018-11-121-2/+3
| | | | | | in constant evaluation, not just odd values. llvm-svn: 346699
* Compound literals, enums, et al require const exprBill Wendling2018-11-091-0/+2
| | | | | | | | | | | | | | | | | | Summary: Compound literals, enums, file-scoped arrays, etc. require their initializers and size specifiers to be constant. Wrap the initializer expressions in a ConstantExpr so that we can easily check for this later on. Reviewers: rsmith, shafik Reviewed By: rsmith Subscribers: cfe-commits, jyknight, nickdesaulniers Differential Revision: https://reviews.llvm.org/D53921 llvm-svn: 346455
* [OpenCL] Add support of cl_intel_device_side_avc_motion_estimation extensionAndrew Savonichev2018-11-081-0/+3
| | | | | | | | | | | | | | | | | | Summary: Documentation can be found at https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_device_side_avc_motion_estimation.txt Patch by Kristina Bessonova Reviewers: Anastasia, yaxunl, shafik Reviewed By: Anastasia Subscribers: arphaman, sidorovd, AlexeySotkin, krisb, bader, asavonic, cfe-commits Differential Revision: https://reviews.llvm.org/D51484 llvm-svn: 346392
* Revert r346326 [OpenCL] Add support of ↵Andrew Savonichev2018-11-071-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | cl_intel_device_side_avc_motion_estimation This patch breaks Index/opencl-types.cl LIT test: Script: -- : 'RUN: at line 1'; stage1/bin/c-index-test -test-print-type llvm/tools/clang/test/Index/opencl-types.cl -cl-std=CL2.0 | stage1/bin/FileCheck llvm/tools/clang/test/Index/opencl-types.cl -- Command Output (stderr): -- llvm/tools/clang/test/Index/opencl-types.cl:3:26: warning: unsupported OpenCL extension 'cl_khr_fp16' - ignoring [-Wignored-pragmas] llvm/tools/clang/test/Index/opencl-types.cl:4:26: warning: unsupported OpenCL extension 'cl_khr_fp64' - ignoring [-Wignored-pragmas] llvm/tools/clang/test/Index/opencl-types.cl:8:9: error: use of type 'double' requires cl_khr_fp64 extension to be enabled llvm/tools/clang/test/Index/opencl-types.cl:11:8: error: declaring variable of type 'half' is not allowed llvm/tools/clang/test/Index/opencl-types.cl:15:3: error: use of type 'double' requires cl_khr_fp64 extension to be enabled llvm/tools/clang/test/Index/opencl-types.cl:16:3: error: use of type 'double4' (vector of 4 'double' values) requires cl_khr_fp64 extension to be enabled llvm/tools/clang/test/Index/opencl-types.cl:26:26: warning: unsupported OpenCL extension 'cl_khr_gl_msaa_sharing' - ignoring [-Wignored-pragmas] llvm/tools/clang/test/Index/opencl-types.cl:35:44: error: use of type '__read_only image2d_msaa_t' requires cl_khr_gl_msaa_sharing extension to be enabled llvm/tools/clang/test/Index/opencl-types.cl:36:49: error: use of type '__read_only image2d_array_msaa_t' requires cl_khr_gl_msaa_sharing extension to be enabled llvm/tools/clang/test/Index/opencl-types.cl:37:49: error: use of type '__read_only image2d_msaa_depth_t' requires cl_khr_gl_msaa_sharing extension to be enabled llvm/tools/clang/test/Index/opencl-types.cl:38:54: error: use of type '__read_only image2d_array_msaa_depth_t' requires cl_khr_gl_msaa_sharing extension to be enabled llvm-svn: 346338
* [OpenCL] Add support of cl_intel_device_side_avc_motion_estimation extensionAndrew Savonichev2018-11-071-0/+3
| | | | | | | | | | | | | | | | | | Summary: Documentation can be found at https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_device_side_avc_motion_estimation.txt Patch by Kristina Bessonova Reviewers: Anastasia, yaxunl, shafik Reviewed By: Anastasia Subscribers: arphaman, sidorovd, AlexeySotkin, krisb, bader, asavonic, cfe-commits Differential Revision: https://reviews.llvm.org/D51484 llvm-svn: 346326
* Reapply Logging: make os_log buffer size an integer constant expression.Tim Northover2018-11-021-0/+7
| | | | | | | | | | | | The size of an os_log buffer is known at any stage of compilation, so making it a constant expression means that the common idiom of declaring a buffer for it won't result in a VLA. That allows the compiler to skip saving and restoring the stack pointer around such buffers. This also moves the OSLog and other FormatString helpers from libclangAnalysis to libclangAST to avoid a circular dependency. llvm-svn: 345971
* Revert "Reapply Logging: make os_log buffer size an integer constant ↵Tim Northover2018-11-011-7/+0
| | | | | | | | expression." Still more dependency hell. llvm-svn: 345871
* Reapply Logging: make os_log buffer size an integer constant expression.Tim Northover2018-11-011-0/+7
| | | | | | | | | | | | The size of an os_log buffer is known at any stage of compilation, so making it a constant expression means that the common idiom of declaring a buffer for it won't result in a VLA. That allows the compiler to skip saving and restoring the stack pointer around such buffers. This also moves the OSLog helpers from libclangAnalysis to libclangAST to avoid a circular dependency. llvm-svn: 345866
* Replace two fallthrough annotations after covered switch with unreachableReid Kleckner2018-11-011-4/+2
| | | | | | | | | | | | | Both preceding switches handle all possible enumerators, so the fallthrough is actually unreachable. This strengthens that to an assertion. The first instance had a comment from 2010 indicating that fallthrough was possible, but that was back when we had a unary operator for offsetof. Now it is its own expression kind, so the annotation was stale. llvm-svn: 345862
* Revert "Logging: make os_log buffer size an integer constant expression.Tim Northover2018-11-011-7/+0
| | | | | | | | This also reverts a couple of follow-up commits trying to fix the dependency issues. Latest revision added a cyclic dependency that can't just be patched up in 5 minutes. llvm-svn: 345846
* Logging: make os_log buffer size an integer constant expression.Tim Northover2018-11-011-0/+7
| | | | | | | | | The size of an os_log buffer is known at any stage of compilation, so making it a constant expression means that the common idiom of declaring a buffer for it won't result in a VLA. That allows the compiler to skip saving and restoring the stack pointer around such buffers. llvm-svn: 345828
* Create ConstantExpr classBill Wendling2018-10-311-2/+5
| | | | | | | | | | | | | | | | A ConstantExpr class represents a full expression that's in a context where a constant expression is required. This class reflects the path the evaluator took to reach the expression rather than the syntactic context in which the expression occurs. In the future, the class will be expanded to cache the result of the evaluated expression so that it's not needlessly re-evaluated Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D53475 llvm-svn: 345692
* PR26547: alignof should return ABI alignment, not preferred alignmentRichard Smith2018-10-261-10/+27
| | | | | | | | | | | | Summary: - Add `UETT_PreferredAlignOf` to account for the difference between `__alignof` and `alignof` - `AlignOfType` now returns ABI alignment instead of preferred alignment iff clang-abi-compat > 7, and one uses _Alignof or alignof Patch by Nicole Mazzuca! Differential Revision: https://reviews.llvm.org/D53207 llvm-svn: 345419
* [Fixed Point Arithmetic] Fixed Point to Boolean CastLeonard Chan2018-10-231-0/+9
| | | | | | | | | | 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-4/+2
| | | | | | | | | | | | Reviewers: Anastasia, yaxunl Reviewed By: Anastasia Subscribers: asavonic, cfe-commits Differential Revision: https://reviews.llvm.org/D52654 llvm-svn: 345038
* [Diagnostics] Check for integer overflow in array size expressions David Bolvansky2018-10-181-0/+13
| | | | | | | | | | | | | | Summary: Fixes PR27439 Reviewers: rsmith, Rakete1111 Reviewed By: rsmith Subscribers: Rakete1111, cfe-commits Differential Revision: https://reviews.llvm.org/D52750 llvm-svn: 344759
* [Fixed Point Arithmetic] FixedPointCastLeonard Chan2018-10-151-0/+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
* ExprConstant: Make __builtin_object_size use EM_IgnoreSideEffects.James Y Knight2018-10-101-24/+7
| | | | | | | | | | | | | | | | | | | | | | | And, since EM_OffsetFold is now unused, remove it. While builtin_object_size intends to ignore the presence of side-effects in its argument, the EM_OffsetFold mode was NOT configured to ignore side-effects. Rather it was effectively identical to EM_ConstantFold -- its explanatory comment notwithstanding. However, currently, keepEvaluatingAfterSideEffect() is not always honored -- sometimes evaluation continues despite it returning false. Therefore, since the b_o_s code was only checking the return value from evaluation, and not additionally checking the HasSideEffects flag, side-effects _were_ in many cases actually being ignored. This change is a prerequisite cleanup towards fixing that issue. Differential Revision: https://reviews.llvm.org/D52924 llvm-svn: 344110
* Emit CK_NoOp casts in C mode, not just C++.James Y Knight2018-10-051-5/+1
| | | | | | | | | | | | Previously, it had been using CK_BitCast even for casts that only change const/restrict/volatile. Now it will use CK_Noop where appropriate. This is an alternate solution to r336746. Differential Revision: https://reviews.llvm.org/D52918 llvm-svn: 343892
OpenPOWER on IntegriCloud